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>