My 2c

Here are my thoughts on Orocos (as it stands today):

I totally support the idea of an open-source operating system for
robotics.  In fact, I've started my own system DROS,
(http://forde.anu.edu.au/~david/DROS/) but it is still several months
away from public release.  I think that it is vitally important for
the future of robotics that we begin to have some software re-use.  A
standard platform (operating system) will allow us to share code (and
to more easily run code on other robots for experimental validation).

However, I don't agree with some of the proposed directions for
Orocos. Mostly, I think that it is important to keep in mind who is
going to be using the system.  The vast majority of code written for
robotics is written by PhD students.  Therefore, I think that we
should try to avoid the use of "tools" unless they are really
fundamental, to save on learning time.  My biggest problems are with
CORBA and XML:

CORBA: CORBA is an interesting standard and provides much of the
functionality that we will require.  However, I'm wary of committing
to CORBA for a number reasons: 

 1) I don't think that it has reached maturity and become a widely
    accepted standard (many will argue with this but I say that we'll
    only truly know in another 5 years).
 2) I don't think that it will ever reach the real-time performance
    that we desire for the low-level control (a work-around would be
    to use a different method for the low-level stuff but why use two
    different standards?).
 3) While the standard is portable and can in theory be used on any
    software platform, reality is a little different.  CORBA would be
    another *major* software component to install on every computer in
    the lab
 4) It is a complex, abstract system that every PhD student would have
    to learn (yes, we could write wrappers to hide most of it but then
    the effort that we are expending is similar to implementing our
    own CORBA-like system)

XML: I think that XML is a total waste of time.  There are many
portable messaging schemes and the only difference with XML is that it
wastes more bandwith than all the others by using [almost]
human-readable messages. Note that whatever encoding scheme one uses,
it is still necessary to have knowledge of the semantics at both the
sender and the receiver.  XML doesn't help with this and it is hugely
wasteful of bandwidth.  XML is just the latest fancy buzzword that
managers like to use - there have been solutions to this problem for
decades! (see http://www.eetimes.com/story/OEG20010807S0038)

To facilitate coding by PhD students, we need to provide a system for
modular software development.  So, we need basic systems for
communication (using a variety of methods) and execution of processes
(across a number of CPUs).  Another issue that I believe is important
(though, more a matter of management than technology) is that the
interfaces between modules need to be well defined and change as
little as possible.  In the ISR system that I worked with in
Stockholm, we found that one person would change the format of a
particular message and that this would tend to propogate throughout
the system, necessitating a re-compile by evey user in the lab.  This
meant that everyone had a local copy of all of the binaries, creating
serious version issues and using up disk space like crazy.  These are
the areas that I've attempted to address with my system (DROS).

I will be attending the meeting at the start of September so we can
continue this discussion over a beer or two. :-)



David Austin

---
[email protected]

Robotic Systems Laboratory,                          Hiroshima '45  
Department of Systems Engineering,                   Chernobyl '86
RSISE, Australian National University                Windows '98