RE: First draft of "OROCOS II" proposal...

Hello Herman,

may I try an intermediary summary and ask some questions?

What I interprete from the last-month's exchanges is the feeling that there
is indeed a great need for OROCOS II at a larger scope. It seems that
robotics related or control people dominate, the mechatronics scope you aim
for seems fitting. If I'd be a reviewer I expect to see more mechatronics or
distributed manufacturing people. I'd also expect to see perception
represented at a more complex level (but I am biased in this point, since a
mechatronics systems without sensors is like a blind robot).

While I think your point is correct that the EU wants to see a large
community taking up the open source initiative, I am not certain where this
initial point is. As you heard, for vision people it is at present a long
way and not yet sure if it will be useable. At the moment we have a nice RPC
framework for vision, dynamic component selection, services, .... I know
from several others that they use similar custom-designed software.
Bielefeld is investigating OROCOS@KTH, and maybe at one point we hear it is
worth switching over. I do not see how a STREP on "OROCOS4vision" could help
if it is not included in OROCOS II, since a tight interfacing would be
needed. What I beleive is needed is a concerted effort, which I think is
also needed to make OROCOS take off in an open source sense. I'm happy to
contribute to such a part of OROCOS II, if wanted. I think such an
application case would be perfect for an IP.

The very best wishes


Markus




> -----Original Message-----
> From: Herman Bruyninckx [mailto:[email protected]]
> Sent: Friday, July 04, 2003 11:07 AM
> Cc: Open RObot COntrol Software
> Subject: RE: [Orocos] First draft of "OROCOS II" proposal...
> 
> 
> On Fri, 4 Jul 2003 [email protected] wrote:
> 
> [...]
> > 1. Control.
> > Control can be reduced to collect and redistribute 
> data/commands. When I see
> > the discussion about classical methods I have this view. 
> For us it includes
> > the complete sensor/actor system. While the actor side got 
> some attention
> > (robots, kinematics), I have not yet seen too much on the 
> sensor side and
> > the specific requirements of sensors (not angular encoders, 
> but rather laser
> > scanner or cameras). Our experience is that as soon as some 
> more complex
> > sensors come into play (the most demanding being vision) several new
> > requirements are imposed on the framework, e.g., lot's of 
> data in short time
> > (images) and the wish to process these on the same HW. 
> 
> Indeed, this "streaming" kind of hardware interfacing is something we
> should care for.
> 
> > Maybe this is implicitly taken care of. If yes, see below 
> item 2. If not, we
> > are interested to be a user and test/extend OROCOS in this 
> dimension. In
> > particual the development of middleware and the service 
> level, service
> > parameters is of interest to us. I cannot see intelligent 
> robotics without
> > these sensors. I also see this as major exploitation 
> factor: all machines
> > using these sensors will wait for a framework that makes it 
> possible to put
> > sensors and machines together for new applicaitons without 
> writting all
> > setup and interfaces anew. 
> 
> My expectation is that this kind of middleware will be done much
> faster and better by other communities, like telecom. Probably it's
> already done, in some of the CORBA based middleware projects, such as
> TAO...?
> 
> [...]
> > 2. User involvement.
> > I fully agree with your point to have a strong design team. 
> I also think an
> > IP also needs to have a wide spread of interested users to 
> have the impact
> > expected. Personally, I see two ways to do this: (1) to make perfect
> > finished tools that are easy to use, or (2) involve 
> interested partners to
> > get to this stage.
> 
> I think (1) _and_ (2) are needed! But (2) not all of the time, full
> time. That's why I propose about ten sub-contract projects, especially
> targeted towards this user involvement.
> 
> > 
> > >From what I know of OROCOS I, (1) is not easy to reach, 
> while (2) is an
> > option for an IP.
> > To be more concrete, and please do not take it as negative 
> critique but as
> > feedback on how to make things used by others/us (maybe 
> other teams had more
> > patience or skills than us). Presently there are 4 OROCOS versions. 
> 
> There are several _complementary_ activities, not "versions" :-)
> 
> > Since RT
> > is not interesting for us, Genom seems too far out of 
> reach, we looked more
> > closely at SmartSoft and OROCOS@KTH. OROCOS@KTH seemed most 
> fitting. On
> > testing there were several difficulties, the largest (in 
> several senses) is
> > TAO, but also a problem is documentation. To reach option 
> (1) it needs
> > substantially more work, expecting people want to download 
> and work. And, to
> > have sufficient time for option (2) it is required to have 
> some minimal
> > resources allocated.
> > SmartSoft is well developed, has a little better 
> documentation. It seems
> > difficult to influence further developments and adaptations 
> to our needs. It
> > also has the same problem of demanding huge resouces and 
> long set-up times
> > (TAO). I remember Henrik stating at the very first meeting 
> "TAO only over my
> > dead body" or something similar.
> > 
> > What we ended up with is to develop our own middleware 
> (based on rtf, at the
> > moment purely for Linux but efficent and easy to use), 
> which is at the
> > moment suited for ActIPret, but does not help to make many 
> steps beyond.
> > Hence, our persistent interest in OROCOS.
> 
> I think it's time to give the Ulm and KTH developments some more
> critical mass and start discussing technical details with them. Only
> in this way they will get better (and merge maybe some time :-)
> 
> > In conclusion, what I wuold like to point out is that the 
> result of OROCOS
> > is / could be great.
> "could" :-)
> 
> > I think design and development needs strong user
> > involvement. And I think users need resources to provide 
> useful input and
> > not only such short and superficial comments/critique as I 
> did above.
> He, one should start somewhere, isn't it! It's always good to know
> that people care about developments, even if they have not (yet)
> participated in the development. 
> 
> Herman
> 
> -- 
>   K.U.Leuven, Mechanical Engineering, Robotics Research Group
> <http://people.mech.kuleuven.ac.be/~bruyninc> Tel: +32 16 322480
> 
> _______________________________________________
> Orocos mailing list
> [email protected]
> http://mail.mech.kuleuven.ac.be/mailman/listinfo/orocos
>