<br><br><div class="gmail_quote">2012/9/14 Matthias Goldhoorn <span dir="ltr">&lt;<a href="mailto:matthias.goldhoorn@dfki.de" target="_blank">matthias.goldhoorn@dfki.de</a>&gt;</span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

  
    
  
  <div bgcolor="#FFFFFF" text="#000000">
    Few remarks to the Simulation.<div class="im"><br>
    <br>
    On 14.09.2012 11:29, Sylvain Joyeux wrote:
    <blockquote type="cite">
      
      <div>On 09/14/2012 11:16 AM, Jan Sliwka
        wrote:<br>
      </div>
      <blockquote type="cite">
        
        
        
        <div><br>
          <p class="MsoNormal">&gt;&lt; <a href="http://www.rock-robotics.org/stable/documentation/about/others.html" target="_blank">http://www.rock-robotics.org/stable/documentation/about/others.html</a>&gt;&lt;<br>
            <br>
            <u></u><u></u></p>
          <p class="MsoNormal">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.</p>
        </div>
      </blockquote>
      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).<br>
      <blockquote type="cite">
        <div>
          <p class="MsoNormal">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). <u></u><u></u></p>
          <p class="MsoNormal">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.<br>
          </p>
        </div>
      </blockquote>
      We have thought about it and it is definitely on the &quot;must-have&quot;
      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.<br>
      <blockquote type="cite">
        <div>
          <p class="MsoNormal"><br>
            <u></u><u></u></p>
          <p class="MsoNormal">&gt;&lt; 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. &gt;&lt;<u></u><u></u></p>
          <p class="MsoNormal"><u></u> <u></u></p>
          <p class="MsoNormal">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).<u></u><u></u></p>
        </div>
      </blockquote>
      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 <br>
      <blockquote type="cite">
        <div>
          <p class="MsoNormal"><br>
            &gt;&lt; [snip new module creation examples]<br>
            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. &gt;&lt;<u></u><u></u></p>
          <p class="MsoNormal"><u></u> <u></u></p>
          <p class="MsoNormal">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.</p>
        </div>
      </blockquote>
      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 ?<br>
      <blockquote type="cite">
        <div>
          <p class="MsoNormal"><u></u><u></u></p>
          <p class="MsoNormal"><u></u> <u></u></p>
          <p class="MsoNormal">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… 
            <u></u><u></u></p>
        </div>
      </blockquote>
      That would be a very nice addition to the current tutorials :P<br>
      <br>
      <blockquote type="cite">
        <div>
          <p class="MsoNormal"><br>
            &gt;&lt;<u></u><u></u></p>
          <p><span style="font-family:Symbol"><span>·<span style="font:7.0pt &quot;Times New Roman&quot;">        

                </span></span></span>Do you have a
            simulator?<u></u><u></u></p>
          <p class="MsoNormal">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?<br>
            &gt;&lt;<u></u><u></u></p>
          <p class="MsoNormal"><u></u> <u></u></p>
          <p class="MsoNormal">I have found many open simulators but
            still didn’t test any of them. <u></u><u></u></p>
          <p><span><span>1.<span style="font:7.0pt &quot;Times New Roman&quot;">      </span></span></span><span>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, &quot;An Overview Of
              Autonomous Underwater Vehicle Systems And Sensors At
              Georgie Tech&quot;.). <u></u><u></u></span></p>
          <p><span><span>2.<span style="font:7.0pt &quot;Times New Roman&quot;">      </span></span></span><span>UWsim: developed by
              IRSLab (Jaume-I University, Castellón).</span></p>
        </div>
      </blockquote>
      I think it has been evaluated by the Avalon team and rejected.
      Don&#39;t know the specifics however.<br>
    </blockquote></div>
    UWSim was labelb by our students as an &quot;dead&quot; project, without any
    good documentation, afaik this was the reason to don&#39;t use this.<div class="im"><br>
    <blockquote type="cite">
      <blockquote type="cite">
        <div>
          <p><span><u></u><u></u></span></p>
          <p><span><span>3.<span style="font:7.0pt &quot;Times New Roman&quot;">      </span></span></span><span>MORSE: 3D Simulator
              from the LAAS - France (Bullet physical engine based) (<a href="http://www.openrobots.org/morse/doc/stable/morse.html" target="_blank">http://www.openrobots.org/morse/doc/stable/morse.html</a>).

              It is multi-purpose.  It might be interesting to
              collaborate with them to make one simulator for all the
              environments. </span></p>
        </div>
      </blockquote>
      That and gazebo are definitely on the list of &quot;needs to be checked
      out more thoroughly&quot;. 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.<br>
    </blockquote></div>
    Morse as we looked to it also the capabilitys for external
    connections was low.<br></div></blockquote><div><br>What do you mean there? I would be very interesting in understanding the issues you have with MORSE, or the limitations you found.<br>Which version of MORSE did you try?<br>
<br>Charles.<br><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
    <br>
    I&#39;m not direkct in the evaluation, but this is what i have in mind,
    maybe (cc&#39;t) some of our students could also give some remaks to
    this.<br>
    <br>
    <blockquote type="cite"><div><div class="h5">
      <pre cols="72">-- 
Sylvain Joyeux (Dr.Ing.)
Senior Researcher

Space &amp; Security Robotics
Underwater Robotics

!!! Achtung, neue Telefonnummer!!!

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

Phone: <a href="tel:%2B49%20%280%29421%20178-454136" value="+49421178454136" target="_blank">+49 (0)421 178-454136</a>
Fax:   <a href="tel:%2B49%20%280%29421%20218-454150" value="+49421218454150" target="_blank">+49 (0)421 218-454150</a>
E-Mail: <a href="mailto:robotik@dfki.de" target="_blank">robotik@dfki.de</a>

Weitere Informationen: <a href="http://www.dfki.de/robotik" target="_blank">http://www.dfki.de/robotik</a>
-----------------------------------------------------------------------
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
----------------------------------------------------------------------- </pre>
      <br>
      <fieldset></fieldset>
      <br>
      </div></div><pre>_______________________________________________
Rock-dev mailing list
<a href="mailto:Rock-dev@dfki.de" target="_blank">Rock-dev@dfki.de</a>
<a href="http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev" target="_blank">http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev</a>
</pre>
    </blockquote>
    <br>
    <br>
    <pre cols="72">-- 
 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.:     <a href="tel:%2B49%20421%20178%2045-4193" value="+49421178454193" target="_blank">+49 421 178 45-4193</a>
 Zentrale: <a href="tel:%2B49%20421%20178%2045-6550" value="+49421178456550" target="_blank">+49 421 178 45-6550</a>
 Fax:      <a href="tel:%2B49%20421%20178%2045-4150" value="+49421178454150" target="_blank">+49 421 178 45-4150</a>
 E-Mail:   <a href="mailto:matthias.goldhoorn@uni-bremen.de" target="_blank">matthias.goldhoorn@uni-bremen.de</a>

 Weitere Informationen: <a href="http://www.informatik.uni-bremen.de/robotik" target="_blank">http://www.informatik.uni-bremen.de/robotik</a></pre>
  </div>

<br>_______________________________________________<br>
Rock-dev mailing list<br>
<a href="mailto:Rock-dev@dfki.de">Rock-dev@dfki.de</a><br>
<a href="http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev" target="_blank">http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev</a><br>
<br></blockquote></div><br>