RE: 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