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

Dear all,

I would like to add some comments to the discussion between
Markus Vincze and Herman Bruyninckx concentrating on
the needs/views/perspectives of application-oriented
projects with respect to OROCOS. I will add my comments
from the view of a system integrator that needs a framework.
(so I am not referring to issues related to an OROCOS II-IP!)

I strongly agree with Markus that vision-oriented projects
sometimes have other requirements and differently
to Herman's opinion I cannot currently see an 
obvious solution to realize complex vision systems.
From past experiences with realizing complex vision systems,
I think that the limited usability and high complexity of
CORBA is a problem for application developers.

We at Bielefeld University are dealing with integrating several vision 
components, e.g. in the IST-project VAMPIRE. 
As we also have a mobile robot, we ended up testing OROCOS@KTH 
which was indeed non-trivial to get running on our linux machines. 
But finally we got it to work and we are now in the process of evaluating how
well it fits our needs. Although OROCOS@KTH is work in progress, we have the 
impression that it might be very well suited as middleware solution.

However, I agree with Markus that currently documentation is a problem.
Also, OROCOS@KTH is being developed focussing on robotics.
Therefore, there is currently no separation of concerns
in the framework regarding robot-specific functionality and 
the communication framework itself.

For us at Bielefeld as 'vision and robotics' application developers,
we would be very interested in a reliable and simple to use framework that 
could be used to integrate systems in both domains.
I am therefore very curious about seeing the current activities at
ULM and KTH getting some critical mass! 
And, as pointed out above, I am already trying to contribute to
this by evaluating the properties of OROCOS@KTH for use in a vision project.
If other people working with OROCOS@KTH are using it to realize vision
architectures I would be very happy to get in contact!  

Best wishes,

  Sebastian


On Friday 04 July 2003 09:51, [email protected] wrote:
> Dear Herman,
>
> also in Vienna we have been following the interesting discussions following
> your proposal.
> From the meetings you know that our interest is in intelligent robotics
> (using your definition of a workable approach from June 27). In particular
> sensing for robotics.
> From this perspectives let me add two comments.
>
> 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.
> 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.
>
> To give you a little of our background, we are interested in OROCOS because
> in the ActIPret EU project we develop a framework based on dynamic service
> calls. The ActIPret task is to select sensor processing components for
> interpreting activites of humans handling objects, e.g., interpreting a
> person that takes a CD and puts it into the CD player. If you are
> interested a high-level description, please see deliverable 1 on
> http://actipret.infa.tuwien.ac.at/.
> (http://actipret.infa.tuwien.ac.at/Sites/deliverables.htm).
>
>
> 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.
>
> 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.
> 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.
>
>
> In conclusion, what I wuold like to point out is that the result of OROCOS
> is / could be great. 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.
> Finally, I'd love to see more sensing in control, since I do not believe
> that intelligent robots (and future factory agents) will be able to be
> useful without them. If we can help great. If we get a great middleware,
> great, too.
>
> Finally, I would like to express my gratitude for your great efforts, I
> appriciate your initiative very much and enjoy following the discussions.
>
> Best wishes
>
>
> Markus

-- 
Dipl.-Inform. Sebastian Wrede	    Phone: (+49 521) 106-4894
Universitaet Bielefeld		      Fax: (+49 521) 106-2992
Technische Fakultaet		    EMail: [email protected]
AG Angewandte Informatik	SnailMail: Postfach 100131, 33501 BIELEFELD