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

Fri Sep 14 12:11:23 CEST 2012

><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.

Agreed. This is why we do have tutorials ;-) Do you think that the current
level of complexity of the Rock tutorials would make new users go away ? ><

I cannot give a definitive answer since I did not implement those tutorials
myself, Besides the content of the website has evolved (and improved) since
the last time I saw it (By the way, there are some html errors now but I
guess you are currently modifying it) . The tutorials are well made . There
is an introduction, at the end of each tutorial you summarize what did the
user do and what did he learn and so. However, I got the impression that
there are a lot of things to concentrate on. I got the impression that there
is no common example which might help the users to focus. (like the turtle
example from the ROS).  

Sometimes it is just details like for example the fact that you are based
Orocos. As a beginner I would go and read about Orocos and maybe say “oh,
that’s so complicated, If I have to learn how to use Orocos and Rock I will
never make it
” ß this is just a simulation . Another detail (but you can’t
help it and I find it fine), there are two languages to which you have to
integrate the code: C++ and Ruby. ROS uses only one.   

Anyhow, I am closely following your project. 

Tell me when you have a Pdf version of the manual.

I am sure I’ll have some questions later on (An interesting point would be
integrating into the Rock framework the components executing on a
microcontroller connected to the linux computer – can Rock do that?).

Ciao, 

Jan

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

Jan SLIWKA

Dr. Eng. Contractor at ETD CMRE (ex-Nurc)

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 11:30 AM
To: Jan Sliwka
Cc: 'Thomas Roehr'; rock-dev at dfki.de
Subject: Re: [Rock-dev] Fwd: RE: Avalon's Middleware

On 09/14/2012 11:16 AM, Jan Sliwka wrote:

>< 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.

You have the same cost with topics, as -- when reusing components and/or
when your system grows -- you need to start remapping topic names (which, in
effect, has the same complexity than explicit 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.

We have thought about it and it is definitely on the "must-have" list, but
we unfortunately have no ressources for that these days (might change in Q2
2013). I am currently approaching the BRIDE developers (from the BRICS
european project) to see if we could have cooperation there. Additionally,
building such a tool from the current Roby visualization code is on my
pet-project list.

>< 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).

I plan to release driver components ASAP (as we already agreed with MARUM
that these components should be made public). On the control side, we 

>< [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.

Agreed. This is why we do have tutorials ;-) Do you think that the current
level of complexity of the Rock tutorials would make new users go away ?

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

That would be a very nice addition to the current tutorials :P

><

·         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).

I think it has been evaluated by the Avalon team and rejected. Don't know
the specifics however.

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. 

That and gazebo are definitely on the list of "needs to be checked out more
thoroughly". However, the issue with MORSE so far is the integration with
Blender. We would like to move towards headless simulation engines (with
associated GUIs !!!) as it enables interesting research prospects.

-- 
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/098c6ab9/attachment-0001.htm 