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

Fri Sep 14 13:12:15 CEST 2012

2012/9/14 Matthias Goldhoorn <matthias.goldhoorn at dfki.de>

>  Few remarks to the Simulation.
>
>
> On 14.09.2012 11:29, Sylvain Joyeux wrote:
>
> 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.
>
> UWSim was labelb by our students as an "dead" project, without any good
> documentation, afaik this was the reason to don't use this.
>
>   ****
>
> 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.
>
> Morse as we looked to it also the capabilitys for external connections was
> low.
>

What do you mean there? I would be very interesting in understanding the
issues you have with MORSE, or the limitations you found.
Which version of MORSE did you try?

Charles.

>
> I'm not direkct in the evaluation, but this is what i have in mind, maybe
> (cc't) some of our students could also give some remaks to this.
>
>  --
> 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
> -----------------------------------------------------------------------
>
>
>
> _______________________________________________
> Rock-dev mailing listRock-dev at dfki.dehttp://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
>
>
>
> --
>  Dipl.-Inf. Matthias Goldhoorn
>  Space and Underwater Robotic
>
>  Universität Bremen
>  FB 3 - Mathematik und Informatik
>  AG Robotik
>  Robert-Hooke-Straße 5
>  28359 Bremen, Germany
>
>  Tel.:     +49 421 178 45-4193
>  Zentrale: +49 421 178 45-6550
>  Fax:      +49 421 178 45-4150
>  E-Mail:   matthias.goldhoorn at uni-bremen.de
>
>  Weitere Informationen: http://www.informatik.uni-bremen.de/robotik
>
>
> _______________________________________________
> Rock-dev mailing list
> Rock-dev at dfki.de
> http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.dfki.de/pipermail/rock-dev/attachments/20120914/b3f5b14a/attachment-0001.htm 