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

[Sylvain Joyeux]

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

-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: http://www.dfki.de/pipermail/rock-dev/attachments/20120914/6f9939e5/attachment.htm