[Rock-dev] Fwd: RE: Avalon's Middleware

Fri Sep 14 11:16:37 CEST 2012

><Hello Jan. Thanks for the feedback and the interest in the project! ><

I am interested in your project since I like the way you do things. It is
professional. I think what you need is first, a set of tools which makes
your system more ergonomic, and second, a community (like ROS) of people
which use and improve your system. In my opinion, the second comes naturally
after completing the first. 

>< http://www.rock-robotics.org/stable/documentation/about/others.html><

Nice comparison site.  I have a comment about the first point of your
comparison. The cost of the connection based model is a big number of
connections. If I got it right you can use Roby to have graphical
representation of your system (The components and their connections i.e. the
connection graph). 

Have you thought of some graphical tools to assist you with creating this
connection graph (like Matlab-Simulink)? Or do you find that not necessary.

>< On that front, it might be of interest for you that we are currently
helping MARUM to run a new AUV (and in the future, all their systems) using
Rock. The drivers and control software will be released as open source. ><

When do you think you will finish that code? It is just to have an idea when
you will start releasing reusable components on your website (which helps to
make Rock more attractive).

>< [snip new module creation examples]
In practice, component creation is a process that will take 2% of the
overall development time. It is, as you point out, very important to attract
new users (and we are interested in comments on how to improve it), but has
very little effect on the overall development times. ><

I would like to stress out that attracting users is what makes the system
live. If the potential users are lost in the complexity they will decide to
abandon (unless they have motivation - such as big community - tutorials - a
set of working systems 
 However, all that comes from the community which
might not be created in the first place due the complexity). Of course, this
does not concern professional users which are used to complexity and their
focus is the technical specifications.

An idea for improving Rock and at the same time attract the users is to
create a game made only using Rock components (The “game of Rock”). The game
should use the maximum of reusable components (ex Vizkit for visualization).
The best game might be one with moving vehicles/robots since it is close to
the robot context. It can be a manual fight - with joystick/keyboard
interfacing components. We could also imagine a fight between algorithms if
the purpose is to create autonomous competing vehicles

><I would also add: the developer of a node can anytime add a new topic. If
not careful (or -- in case of reusing nodes, if he/she does not know about
your system), the new topic name might clash with an existing one and boom.
Additionally, having explicit connections allows disconnecting dataflow and
reconnecting it. The first one is important for safety reasons, as one can
isolate a rogue component from the rest of the system. The second one is the
cornerstone of behavior switching in Rock (we switch behaviors by
starting/stopping new components and rewiring the connections). ><

That is why I am interested in your system.

><

·         Do you have a simulator?

As Thomas mentioned, we have our own simulator that just got released as
open source. However, while it kind-a works for underwater applications, it
is not ideal. We did look pretty hard for a good open source underwater
simulator, but never found one. Would you have any pointer in that respect?
><

I have found many open simulators but still didn’t test any of them. 

1.      uMVS : MOOS 2D simulator. I think there are others but I don’t know
if they are open source (like M. E. West, T. R. Collins, J. R. Bogle, A.
Melim and M. Novitzky, "An Overview Of Autonomous Underwater Vehicle Systems
And Sensors At Georgie Tech".). 

2.      UWsim: developed by IRSLab (Jaume-I University, Castellón).

3.      MORSE: 3D Simulator from the LAAS - France (Bullet physical engine
based) (http://www.openrobots.org/morse/doc/stable/morse.html). It is
multi-purpose.  It might be interesting to collaborate with them to make one
simulator for all the environments. 

Ciao,

-----------------------------------------------------------------

Jan SLIWKA

Dr. Eng. Contractor at ETD CMRE

Software engineering, algorithms, robotics

web: www.jan-sliwka.net <http://www.jan-sliwka.net/> 

From: Sylvain Joyeux [mailto:sylvain.joyeux at dfki.de] 
Sent: Friday, September 14, 2012 9:14 AM
To: Jan Sliwka
Cc: 'Thomas Roehr'; rock-dev at dfki.de
Subject: Re: [Rock-dev] Fwd: RE: Avalon's Middleware

Hello Jan. Thanks for the feedback and the interest in the project !

On 08/17/2012 02:03 PM, Jan Sliwka wrote:

I would like first to talk about the context. You know, you’re facing the
famous ROS and my question would be: what are the points in which you are
equal and those where you surpass ROS. 

http://www.rock-robotics.org/stable/documentation/about/index.html
http://www.rock-robotics.org/stable/documentation/about/others.html

I would say that first; your strong point might be the AUV world. Currently,
there are very few components related to the AUV in ROS. I think the second
strong point is the use of Orocos which enable better control of the
application (more suitable for fine control when resources are lacking).
However, the cost of better control is higher complexity. 

On that front, it might be of interest for you that we are currently helping
MARUM to run a new AUV (and in the future, all their systems) using Rock.
The drivers and control software will be released as open source.

[snip new module creation examples]
In practice, component creation is a process that will take 2% of the
overall development time. It is, as you point out, very important to attract
new users (and we are interested in comments on how to improve it), but has
very little effect on the overall development times.

ROS runs a parameter server which you can initialize using a “.yaml” file.
The parameters are accessible through the functions “setParam/getParam. The
difference with Rock is that the server is centralized but you handle one
config per component which is maybe better.  

You also have access to parameters directly on the components through the
property interface (for e.g. change parameters at runtime).

The components are naturally connected through topic names. The connection
graph can be even remapped using ROS remapping capability. However, this is
not necessarily good since the connection graph is not necessarily defined
in a single file.  In the case of Rock all the interconnections are visible
in the same file. 

I would also add: the developer of a node can anytime add a new topic. If
not careful (or -- in case of reusing nodes, if he/she does not know about
your system), the new topic name might clash with an existing one and boom.
Additionally, having explicit connections allows to disconnect dataflow and
reconnect it. The first one is important for safety reasons, as one can
isolate a rogue component from the rest of the system. The second one is the
cornerstone of behaviour switching in Rock (we switch behaviours by
starting/stopping new components and rewiring the connections).

I personally find ROS more ergonomic but Rock having more potential. To be
honest I still didn’t use Rock but it is the impression I have from reading
the documentation.

I have some questions with regards to the modules you offer:

·         What is the list of communication devices you handle:
Serial/I2C/CAN/Bluetooth?

Depends on what you mean by "handle".

The base class for all our device drivers can handle serial and bluetooth
(since bluetooth is seen as a network device on linux). There is a dedicated
CAN component for CAN devices. On top of that, for underwater systems, we
have drivers for the schilling DTS.

·         Do you have a simulator?

As Thomas mentioned, we have our own simulator that just got released as
open source. However, while it kind-a works for underwater applications, it
is not ideal. We did look pretty hard for a good open source underwater
simulator, but never found one. Would you have any pointer in that respect ?

-- 
Sylvain Joyeux (Dr.Ing.)
Senior Researcher

Space & Security Robotics
Underwater Robotics

!!! Achtung, neue Telefonnummer!!!

Standort Bremen:
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Straße 5
28359 Bremen, Germany

Phone: +49 (0)421 178-454136
Fax:   +49 (0)421 218-454150
E-Mail: robotik at dfki.de

Weitere Informationen: http://www.dfki.de/robotik
-----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.:    DE 148646973
Steuernummer:  19/673/0060/3
----------------------------------------------------------------------- 

**********************************************************************************************
*** PRIVILEGED AND CONFIDENTIAL ***

Centre for Maritime Research and Experimentation (CMRE, formerly NURC)

The information contained in this e-mail message (including any attached files)
is intended for the use of the addressee(s) only and is privileged information.
The information should neither be posted to the Internet, nor published in any
other public domain, without the express permission of the sender. If you are
not the intended recipient(s) or the recipient's representative, you are hereby
notified that any use, disclosure, copying or distribution of this communication
is prohibited. If you have received this communication in error please notify us
immediately at postmaster at cmre.nato.int and remove this message from 
your system.
**********************************************************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.dfki.de/pipermail/rock-dev/attachments/20120914/ab5ff951/attachment-0001.htm 