My 2c

David Austin wrote:

Dear all,

I would like to give some comments based on practical knowledge gained
in
our projects.

When we started in 1997 we thought about using CORBA but at that time
CORBA was not available in its current level of development. Therefore,
we decided to use peer-to-peer socket communication and implement
communication templates which provide predefined communication
mechanisms
to hide all the socket stuff. To be independent of the operating system
we use ACE (Doug Schmidt, freeware) as wrapper for the operating system.

These templates now allow to access other modules via proxy patterns and

allow to communicate objects. In some sense, we reimplemented the very
basic level of CORBA without big overhead, but additionally wrapped the
communication mechanisms into easy usable templates. A main concept in
our framework is to


    - define communication patterns which have to be used to have a
clear
and understandable module interface.
    - strictly separate communication and algorithmic aspects by using
proxy patterns for module interaction and hide all communication details

(messages, synchronisation, ...) by a separate "system" thread in each
module
    - provide a configuration class which allows to
configure/enable/disable etc. a module even if a user thread is hanging
in a wait for a query reply.


Now, I would think about replacing the lowest level of the communication

patterns by CORBA, but I currently have no need to do that big step  ...

Our experience showed that in particular with projects with many
different groups and levels of coding experience, a clearly structured
software framework is the key to success. Our students were not afraid
of
the complexity of needed tools (all freeware on linux) as long as their
parts are straight and easy. We provided a hands-on tutorial to learn
how
to write a module and the infrastructure of the software framework
provided a comfortable shell.

Since the framework requires to use predefined software patterns our
students benefit from the experience coded in those patterns and they do

not waste time with reimplementing communication, synchronisation and
other things and end up in deadlocks. Since we also provide a task class

(active object) thread programming becomes very easy and everybody so
far
appreciated that.

Therefore, I would like to state that in particular modern concepts of
software engineering, middleware and threading allows to implement
powerful frameworks. A good framework then is one where the user is
guided by the provided patterns and does not have to have deep knowledge

on parallelism and robotic software architectures. Using the framework
should end up automatically at the right place. Then everybody will be
glad because implementing new ideas and changing modules can be done
easily without being afraid of changing a running system.


Christian Schlegel


> 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
>
> _______________________________________________
> Orocos mailing list
> [email protected]
> http://mail.mech.kuleuven.ac.be/mailman/listinfo/orocos


--

---------------------------------------------------------------------
Christian Schlegel
FAW Ulm (Research Institute for Applied Knowledge Processing)
PO Box 2060
D-89010 Ulm
Germany

Tel. : ++49 (731) 501 8949
Fax  : ++49 (731) 501 999
email: [email protected]
WWW  : http://www.faw.uni-ulm.de/
---------------------------------------------------------------------