OROCOS and ROS

Hi all,<br><br>For some time now, I&#39;ve been periodically and unsuccessfully searching (web, papers) for a comparison of the features and design decisions of OROCOS and Willow Garage&#39;s ROS. Now that RTT 1.8 is out (and some cool ideas for 2.0), and considering the recent release of ROS 0.4, I&#39;d like to publicly state my unanswered questions, and hopefully get some feedback either in the form of objective statements or subjective opinions ;-)<br>
If someone is familiar with both frameworks, I&#39;d like to have a clearer idea of the extent up to which their main objectives overlap, and in which areas one or the other could be a more reasonable alternative, e.g., seamless communication between modules, real-time support, robotics-oriented functionalities (à la OCL, KDL, BFL), support for existing scripting languages like Python or Perl, etc.<br>
Also, an opinion on the pros and cons of each project&#39;s design decisions would be appreciated (e.g., Corba vs. XML-RPC for inter-process communication, used synchronization primitives, etc.).<br>I believe that discussing these topics helps to put in context the value of a project and helps the process of chossing the tool that best fits your needs (especially for newcomers).<br>
<br>Thanks in advance,<br><br>Adolfo Rodríguez Tsouroukdissian<br><br>P.S. I know the people in this list probably are not ROS experts (I am certainly not one), so their knowledge on the subject may be limited, but any comments would be greatly appreciated.<br>
<br>Robotics engineer<br>PAL ROBOTICS S.L<br><a href="http://www.pal-robotics.com">http://www.pal-robotics.com</a><br>Tel. +34.93.414.53.47<br>Fax.+34.93.209.11.09<br>

OROCOS and ROS

On Friday 20 February 2009 15:56:36 Adolfo Rodríguez Tsouroukdissian wrote:
> Hi all,
>
> For some time now, I've been periodically and unsuccessfully searching
> (web, papers) for a comparison of the features and design decisions of
> OROCOS and Willow Garage's ROS. Now that RTT 1.8 is out (and some cool
> ideas for 2.0), and considering the recent release of ROS 0.4, I'd like to
> publicly state my unanswered questions, and hopefully get some feedback
> either in the form of objective statements or subjective opinions ;-)

I'd love to spend a week on ROS or any other hot robotics framework to learn
it's advantages and disadvantages. Unfortunately, I only have time to read
their websites (and in the best case look at some code.)

That said, these are my subjective opinions on what robotics middleware should
offer to component/modules/nodes/... developers:

* Data flow interface. We're doing control after all, read-calculate-write is
the accepted solution for that
* A client/server interface. Component A requests service S from component B;
ie a request-response interface
* A configuration (key,value) interface,

These are the core concepts you'll find back in most modern component
frameworks for control (Autosar, Orocos, ROS,...) These frameworks differ
however in how they (allow to) implement these interfaces. Orocos is very
specific in one way, ROS in another.

For example, ROS implements properties in a central server. In Orocos,
everything is a component: If you require a central repository, you need to
write such a component (with a truckload of properties) which becomes peer of
every component that needs it.

Another one: The client server architecture of ROS is actually setting up two
data ports (send/receive) with two messages (request/response). This is bound
to go through a socket, so there's no use in running multiple threads in one
process, it would be equally efficient as running it in multiple processes. In
Orocos, client/server knows three manifestations: method, command, event.
which makes explicit how synchronisation is done. Also, Orocos uses the most
efficient implementation possible: in-process, plain C++ method calls, inter-
process: socket based messages. Orocos will always get much higher throughput
on local machines, but as someone put it, if your code is buggy, this is less
safe and makes recovery worse.

Orocos is used by machine builders that require absolute real-time behaviour.
ROS has none of those guarantees (afaik).

Orocos components are fully generic (they don't link with each other) and run-
time inspectable. I don't know if/how ROS offers this.

ROS does have a larger team working on tooling and implementations. But so was
Player/Stage, Genom and maybe even ORCA(2). People didn't massively switch to
those (neither did they massively switch to Orocos !). Times are different now
but I believe Orocos is still unique in the way it tries to solve the control
problem. On the other hand, I'd rather have this 'uniqueness' only in the way
things are implemented and not in the way 'the universal component for control
looks like': When people settle on how the thing should look like, all
'modern' frameworks should offer compatible communication interfaces and have a
(high) degree of interoperability. At least to the point where they can use
each other services, data flow and configuration settings (see above). But
that's clearly not going to be my personal coding. I just don't scale that
well :-). So I'm counting on the people who benefit from both frameworks to
see/propose how things could be glued/move together. And even then, two or
more comparable frameworks might hapily live next to each other. As someone
once put it: a bit of duplication is always healthy in Open Source.

Peter

--
Peter Soetens -- FMTC -- <http://www.fmtc.be>
--
Orocos-Users mailing list
Orocos-Users [..] ...
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users

OROCOS and ROS

On Sat, Feb 21, 2009 at 11:59 PM, Peter Soetens <peter [dot] soetens [..] ...> wrote:

[...]
> more comparable frameworks might hapily live next to each other. As someone
> once put it: a bit of duplication is always healthy in Open Source.

I'm not going to say much in this discussion, apart from this:
1/ A bit of duplication might be healthy. Too much is always too much
though, and that seems to be a very unhealthy property of OS: people
seem to be reinventing the same stuff all over instead of bundling
efforts.
2/ Since the ROS project has started much later than orocos and
writing a middleware is not a one-night-job, I guess they must have
done an evaluation of existing frameworks, and have a good reason why
they started their own middleware project. I would be nice to know
these (AFAIR I never saw a post about this from someone from WG?),
since it might be stuff where orocos can improve.

Klaas

OROCOS and ROS

On Fri, 20 Feb 2009, Adolfo Rodríguez Tsouroukdissian wrote:

> For some time now, I've been periodically and unsuccessfully searching (web,
> papers) for a comparison of the features and design decisions of OROCOS and
> Willow Garage's ROS. Now that RTT 1.8 is out (and some cool ideas for 2.0),
> and considering the recent release of ROS 0.4, I'd like to publicly state my
> unanswered questions, and hopefully get some feedback either in the form of
> objective statements or subjective opinions ;-)

Great! Thanks...

> If someone is familiar with both frameworks, I'd like to have a clearer idea
> of the extent up to which their main objectives overlap, and in which areas
> one or the other could be a more reasonable alternative, e.g., seamless
> communication between modules, real-time support, robotics-oriented
> functionalities (à la OCL, KDL, BFL), support for existing scripting
> languages like Python or Perl, etc.

Orocos starting point is to provide a _framework_ in which concrete
functionalities can be plugged in, and where realtime and "cross-cutting"
instrumentation are important. In that sense, it could (should!) be
integrated with other frameworks, to serve that part of the overall
application for which it is better.

In addition, Orocos wants to go beyong object-oriented programming, and
deal with components (which are halfway between OO and SOA).

> Also, an opinion on the pros and cons of each project's design decisions
> would be appreciated (e.g., Corba vs. XML-RPC for inter-process
> communication, used synchronization primitives, etc.).

Orocos has _never_ made the decision to support only CORBA! While ROS has
decided to base everything on RPC, if I am not mistaken. This _could_ be
unfortunate, but _only_ if they couple the RPC decision somewhere into the
other modules of their software without really knowing. In principle Orocos
can also support RPC for Data Port connection, but of course you will then
not be able to reach the same performance as with the C++ connections.

> I believe that discussing these topics helps to put in context the value of
> a project and helps the process of chossing the tool that best fits your
> needs (especially for newcomers).
I fully agree with this point of view. And it are certainly not only the
newcomers that will profit from this discussion! :-)

My summary: ROS and OROCOS are very much complementary, in scope,
implementation and functionality. However, both will inevitably move more
towards overlapping each other, _unless_ there are people from both
projects overseeing the evolution and optimizing complementarity whenever
possible or relevant...

K.U.Leuven is partner in the upcoming BRICS project, that wants to achieve
much of the above-mentioned "best practicies combination" of existing open
source robotics software, _plus_ working with the existing projects towards
refactoring to reach a much improved overall, system-wide,
application-independent interoperability and richness in functionality.
Sounds too good to be true :-)

Herman

> Thanks in advance,
>
> Adolfo Rodríguez Tsouroukdissian
>
> P.S. I know the people in this list probably are not ROS experts (I am
> certainly not one), so their knowledge on the subject may be limited, but
> any comments would be greatly appreciated.
>
> Robotics engineer
> PAL ROBOTICS S.L
> http://www.pal-robotics.com
> Tel. +34.93.414.53.47
> Fax.+34.93.209.11.09
>
>

--
K.U.Leuven, Mechanical Eng., Mechatronics & Robotics Research Group
<http://people.mech.kuleuven.be/~bruyninc> Tel: +32 16 322480
Coordinator of EURON (European Robotics Research Network)
<http://www.euron.org>
Open Realtime Control Services <http://www.orocos.org>

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

OROCOS and ROS

>Orocos starting point is to provide a _framework_ in which concrete
>functionalities can be plugged in, and where realtime and "cross-cutting"
>instrumentation are important. In that sense, it could (should!) be
>integrated with other frameworks, to serve that part of the overall
>application for which it is better.

This is also very much a goal of ROS. We have made a very concrete separation between our infrastructure and the functionality integrated within in it (hosted in two separate repositories), and have been incorporating strong open-source libraries into the system (including both BFL and KDL) wherever possible. Connecting ROS and Orocos systems together makes a lot of sense.

The ROS take on real-time performance has been that only a small subset of a robotic system has a hard real-time requirement (closed-loop controllers, safety systems, etc.). Most of the rest of the system (e.g. vision in most cases, planners, human interfaces, etc.) is operating "in real time", but is in a complex enough system that guaranteeing realtime performance is impossible. Since a framework must make significant compromises to support hard real-time behavior everywhere, the ROS communication layer is not hard real-time compatible, but individual processes within the system can have components operating under a hard realtime operating system. In principle, one of the best ways to implement the ROS component(s) operating in hard realtime would be to use OROCOS within that part of the system, since it provides more tools for realtime interaction within components, but ROS relies on the facilities of the underlying OS and the ability of the programmer to use them properly.

>Orocos has _never_ made the decision to support only CORBA! While ROS has
>decided to base everything on RPC, if I am not mistaken. This _could_ be
>unfortunate, but _only_ if they couple the RPC decision somewhere into the
>other modules of their software without really knowing. In principle Orocos
>can also support RPC for Data Port connection, but of course you will then
>not be able to reach the same performance as with the C++ connections.

ROS actually uses XML-RPC only for configuration information, not for communication of data in a running system. Within a running system, high-performance communication is used, via both a publish-subscribe mechanism and a high-performance RPC implementation, and the transport layers are selectable at runtime. This allows low-latency communication (although obviously limited by the network or IPC mechanism), as well as efficient support for large bandwidth communication, such as un-compressed video streams.

>My summary: ROS and OROCOS are very much complementary, in scope,
>implementation and functionality. However, both will inevitably move more
>towards overlapping each other, _unless_ there are people from both
>projects overseeing the evolution and optimizing complementarity whenever
>possible or relevant...

I agree. The design of ROS is explicitly trying to work effectively with other robot middleware, and we follow the pattern of creating ROS-independent libraries and then hooking them together with ROS for integration throughout our implementation of new capabilities. We also make extensive use of currently available code, and have integrated with Player/Stage (supporting hardware drivers and contributing improvements back upstream where possible), OpenRAVE, EusLISP from University of Tokyo, OROCOS through the use of BFL and KDL, Graspit, and OpenCV (which we rely on for our vision code, and are currently the primary maintainers of), to name a few.

We are very intersted in finding ways to make sure our tools are benefiting the entire community, and to make the best use of currently available resources, and would be interested in working with OROCOS to coordinate development in the future.

OROCOS and ROS

On Thu, 2 Apr 2009, berger [..] ... wrote:

>> Orocos starting point is to provide a _framework_ in which concrete
>> functionalities can be plugged in, and where realtime and "cross-cutting"
>> instrumentation are important. In that sense, it could (should!) be
>> integrated with other frameworks, to serve that part of the overall
>> application for which it is better.
>
> This is also very much a goal of ROS. We have made a very concrete
> separation between our infrastructure and the functionality integrated
> within in it (hosted in two separate repositories), and have been
> incorporating strong open-source libraries into the system (including
> both BFL and KDL) wherever possible. Connecting ROS and Orocos systems
> together makes a lot of sense.
>
> The ROS take on real-time performance has been that only a small subset
> of a robotic system has a hard real-time requirement (closed-loop
> controllers, safety systems, etc.).

I absolutely agree: realtime should be a _very, very_ limited part of any
application. Hence, I think integration will _technically_ be easy, while I
expect most problems at the _semantic_ level: exact meaning of terms, etc.

> Most of the rest of the system (e.g.
> vision in most cases, planners, human interfaces, etc.) is operating "in
> real time", but is in a complex enough system that guaranteeing realtime
> performance is impossible. Since a framework must make significant
> compromises to support hard real-time behavior everywhere, the ROS
> communication layer is not hard real-time compatible,

That seems to be an unfortunate decision, and locking yourself in into one
specific communication mechanism (RCP in ROS case, if I am not mistaken)
is not necessary, even.

> but individual
> processes within the system can have components operating under a hard
> realtime operating system. In principle, one of the best ways to
> implement the ROS component(s) operating in hard realtime would be to use
> OROCOS within that part of the system, since it provides more tools for
> realtime interaction within components, but ROS relies on the facilities
> of the underlying OS and the ability of the programmer to use them
> properly.

>> Orocos has _never_ made the decision to support only CORBA! While ROS has
>> decided to base everything on RPC, if I am not mistaken. This _could_ be
>> unfortunate, but _only_ if they couple the RPC decision somewhere into the
>> other modules of their software without really knowing. In principle Orocos
>> can also support RPC for Data Port connection, but of course you will then
>> not be able to reach the same performance as with the C++ connections.
>
> ROS actually uses XML-RPC only for configuration information, not for
> communication of data in a running system. Within a running system,
> high-performance communication is used, via both a publish-subscribe
> mechanism and a high-performance RPC implementation, and the transport
> layers are selectable at runtime. This allows low-latency communication
> (although obviously limited by the network or IPC mechanism), as well as
> efficient support for large bandwidth communication, such as
> un-compressed video streams.

Okay, replace "RPC" by "IPC" in my comment above :-) To what extend is this
choice of communication technology a _hard_ dependency?

>> My summary: ROS and OROCOS are very much complementary, in scope,
>> implementation and functionality. However, both will inevitably move more
>> towards overlapping each other, _unless_ there are people from both
>> projects overseeing the evolution and optimizing complementarity whenever
>> possible or relevant...
>
> I agree. The design of ROS is explicitly trying to work effectively with
> other robot middleware,

What does that mean technically speaking?

> and we follow the pattern of creating
> ROS-independent libraries and then hooking them together with ROS for
> integration throughout our implementation of new capabilities.

What is your "integration paradigm"? Java or .NET like "remoting"?
CORBA-like component-based interaction? ...?

> We also
> make extensive use of currently available code, and have integrated with
> Player/Stage (supporting hardware drivers and contributing improvements
> back upstream where possible), OpenRAVE, EusLISP from University of
> Tokyo, OROCOS through the use of BFL and KDL, Graspit, and OpenCV (which
> we rely on for our vision code, and are currently the primary maintainers
> of), to name a few.

Again I have the same question: what is technical aspect of this
"integration"?

> We are very intersted in finding ways to make sure our tools are
> benefiting the entire community, and to make the best use of currently
> available resources, and would be interested in working with OROCOS to
> coordinate development in the future.

Me too!

Practically speaking, two Orocos people (Ruben and myself) will visit
Willow Garage in the near future, and have constructive brainstormings :-)

Herman

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

OROCOS and ROS

On Fri, 10 Apr 2009, Eric Berger wrote:

>>> Most of the rest of the system (e.g.
>>> vision in most cases, planners, human interfaces, etc.) is operating "in
>>> real time", but is in a complex enough system that guaranteeing realtime
>>> performance is impossible.  Since a framework must make significant
>>> compromises to support hard real-time behavior everywhere, the ROS
>>> communication layer is not hard real-time compatible,
>>
>> That seems to be an unfortunate decision, and locking yourself in into one
>> specific communication mechanism (RCP in ROS case, if I am not mistaken)
>> is not necessary, even.
>
> ROS isn't locked into a particular communications mechanism (raw TCP
> sockets, UDP, shared memory, or more exotic options like Infiniband
> could all be used) and also supports both reliable and unreliable
> anonymous publish-subscribe message semantics, as well as RPC-style
> communication.

Great! Then I must have been misinterpreting the recent message on the ros
mailinglist about using XML-RPC for _configuration_ :-) Sorry about that!

> We still have hard realtime components, and communication between them
> and the rest of the system, we just don't provide hard realtime
> guarantees on most of the system, because most of those components
> aren't realtime anyway.
>
>>> but individual
>>> processes within the system can have components operating under a hard
>>> realtime operating system.  In principle, one of the best ways to
>>> implement the ROS component(s) operating in hard realtime would be to use
>>> OROCOS within that part of the system, since it provides more tools for
>>> realtime interaction within components, but ROS relies on the facilities
>>> of the underlying OS and the ability of the programmer to use them
>>> properly.
>>
>>>> Orocos has _never_ made the decision to support only CORBA! While ROS has
>>>> decided to base everything on RPC, if I am not mistaken. This _could_ be
>>>> unfortunate, but _only_ if they couple the RPC decision somewhere into
>>>> the
>>>> other modules of their software without really knowing. In principle
>>>> Orocos
>>>> can also support RPC for Data Port connection, but of course you will
>>>> then
>>>> not be able to reach the same performance as with the C++ connections.
>>>
>>> ROS actually uses XML-RPC only for configuration information, not for
>>> communication of data in a running system.  Within a running system,
>>> high-performance communication is used, via both a publish-subscribe
>>> mechanism and a high-performance RPC implementation, and the transport
>>> layers are selectable at runtime.  This allows low-latency communication
>>> (although obviously limited by the network or IPC mechanism), as well as
>>> efficient support for large bandwidth communication, such as
>>> un-compressed video streams.
>>
>> Okay, replace "RPC" by "IPC" in my comment above :-) To what extend is this
>> choice of communication technology a _hard_  dependency?
>
> When I said "IPC" I just meant whatever form of interprocess
> communication is being used in the system. ROS has completely
> switchable transport mechanisms.

Again, I'm glad to read this :-) In the same context, which ROS webpage is
the best to read to lear more about ROS' communication design and
implementation? (There are sooooo many pages already... :-))

>>>> My summary: ROS and OROCOS are very much complementary, in scope,
>>>> implementation and functionality. However, both will inevitably move more
>>>> towards overlapping each other, _unless_ there are people from both
>>>> projects overseeing the evolution and optimizing complementarity whenever
>>>> possible or relevant...
>>>
>>> I agree.  The design of ROS is explicitly trying to work effectively with
>>> other robot middleware,
>>
>> What does that mean technically speaking?
> Several things. Partially, it's just the mindset we use to make
> decisions, but concretely:
>
> 1) We write our code to be libraries that are independent of ROS, and
> then integrate them in ROS, which means pieces of functionality
> (drivers or algorithms) can be taken out of the ROS source tree and
> used elsewhere

Ok. Such interoperability is indeed _the_ number one concern. But I think
it needs some level of _standardization_ on the objects, terminology,... to
be used. There are no such "standards" yet, so what is Willow Garage's
policy/stands/plans/... on this topic?

Personally, I am leading the "harmonization" work package in the BRICS
project, which wants to work with the robotics community to come up with
such 'standards'. (We don't call them standards, since we think that coming
up with interfaces and definitions that can be made interoperable by some
simple wrapping would be fine too.)

> 2) We don't dictate the structure of the code running in ROS - ROS is
> a library which can be linked in to essentially any application and
> provide capabilities, but we don't require control over execution of
> the code, or put other constraints on what can be done by the program.
> In one summary of this philiosphy we "don't wrap your main()", which
> means that integrating ROS functionality into an application or
> library doesn't require restructuring that library (so that
> application be e.g. a full OROCOS system that exposes some
> functionality to be used from ROS from within a component, or takes
> advantage or functionality elsewhere that is exposed over ROS)

Good design! But I need some more information: you speak about "provide
capabilities" which is "Computation" in our view on design; what about ROS'
design of the other three "concerns": "configuration", "communication" and
"coordination"? I mean, what requirements does ROS have (implicitly and
explicitly) in the domain of these three concerns, for code libraries to be
"ROS compatible"?

> 3) We are licensing the core as BSD so that the ROS code licensing is
> compatible with the licensing of essentially all other systems out
> there and is easy / possible to integrate
>
> 4) We are using code from other middleware projects. The biggest
> examples of this have been drivers and navigation components from the
> Player project, simulators from Stage and Gazebo, and the KDL from
> OROCOS. By re-using code from other systems we're hoping to make
> integration and switching between platforms easier, so if e.g. ROS and
> OROCOS components are combined in a system, the shared KDL
> representations of the robot will make communication between the two
> easier.

Well... KDL is not really using/providing a 'standard' API (yet), and making
libraries interoperable two-by-two is not the best way to move forward.
(This connects to my remarks above about the need to get some
standardization/harmonization starting 'real soon now'....)

>> What is your "integration paradigm"? Java or .NET like "remoting"?
>> CORBA-like component-based interaction? ...?
> A running ROS system consists of many processes that all communicate
> with one another peer-to-peer.
>
> There are two main integration models for ROS packages - either
> libraries, or stand-along nodes.
>
> Libraries get linked in to the application, and may also provide a ROS
> interface for getting access to external data (e.g. "tf", our tool for
> spatial transforms), providing data to the external world (e.g.
> "diagnostics updater", which facilitates system-wide reporting of
> hardware status and diagnostics information, or just provide native
> linked code.
>
> ROS nodes are stand-alone processes that communicate with other ROS
> nodes over topics, service calls, and parameters.

Where can I find definitions of these terms? (" topics, service calls, and
parameters")

> The system supports
> a variety of methods for combining nodes into an application, mostly
> "roslaunch" is used, which fills a similar role to your deployer, I
> believe.
>
>>> We also
>>> make extensive use of currently available code, and have integrated with
>>> Player/Stage (supporting hardware drivers and contributing improvements
>>> back upstream where possible), OpenRAVE, EusLISP from University of
>>> Tokyo, OROCOS through the use of BFL and KDL, Graspit, and OpenCV (which
>>> we rely on for our vision code, and are currently the primary maintainers
>>> of), to name a few.
>>
>> Again I have the same question: what is technical aspect of this
>> "integration"?
>
> Player - We are compatible with player hardware drivers, and other
> components, as well as both Gazebo and Stage simulators
>
> OpenRAVE - OpenRave can communicate over ROS, and Rosen Diankov has
> built interfaces into ROS and OpenRAVE (including implementing an
> octave ROS client) which have allowed uses of the robot like using
> willow garage motor control, sensing, and 3d point cloud generation
> together with openRAVE's motion planning and vision processing to
> grasp objects in the presence of obstacles on a running robot.
>
> EusLISP - Prof. Inaba, Dr. and 4 graduate students from the
> university of Tokyo came to visit Willow Garage and wrote an interface
> layer between eusLISP and ROS. They used that to take advantage of
> our stack for sensor drivers, motor drivers and control loops,
> navigation stack functionality, and person-detection. They plugged
> those components into their capabilities for speech, top-level
> planning / scripting, motion planning, and a wii-mote interface to
> create a series of demos. We are continuing to work with them to
> integrate our systems more closely.

Same remark as above: hopefully the robotics community can do better than
two-by-two interoperability... We should organise a workshop on that topic,
I guess :-)

> OROCOS - We are using BFL in some components of the system, and KDL to
> compute jacobians, etc. within our motor control interface. This
> means that generating a KDL chain that represents an arm or other
> component from our robot description becomes just a function call.
>
> GraspIt - Peter Allen and Matei Ciocarlie have added ROS interfaces to
> graspit that allow it to read in data to be used for identifying grasp
> points directly from a running robot or from logfiles.
>
> OpenCV - Since so many people use OpenCV for vision processing, we
> encourage and support the use of OpenCV for vision processing within
> ROS. We provide easy conversion between our image message and the IPL
> image datatype used by OpenCV, and the data block of our image format
> is compatible with OpenCV's IPL, which revents extra copies or
> processing during transport. We also provide examples of integrating
> the two together, and we have been making changes such as switching
> OpenCV's build system over to CMake to make using the two systems
> together more seamless.
>
>>> We are very intersted in finding ways to make sure our tools are
>>> benefiting the entire community, and to make the best use of currently
>>> available resources, and would be interested in working with OROCOS to
>>> coordinate development in the future.
>>
>> Me too!
>>
>> Practically speaking, two Orocos people (Ruben and myself) will visit
>> Willow Garage in the near future, and have constructive brainstormings :-)
>
> I'm very much looking forward to your visit.
Me too :-)

Thanks _ a lot_ for taking the time to provide such an extensive answer!

Herman
> --Eric
>

--
K.U.Leuven, Mechanical Eng., Mechatronics & Robotics Research Group
<http://people.mech.kuleuven.be/~bruyninc> Tel: +32 16 322480
Coordinator of EURON (European Robotics Research Network)
<http://www.euron.org>
Open Realtime Control Services <http://www.orocos.org>