<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">Hi, <br>
      there is also a use_deployment statement:<br>
      define('eslam_mapping', Cmp::Eslam.<br>
      &nbsp;&nbsp;&nbsp; use('filtered_laser', 'xsens_imu', 'stereo',
      'sweeping_laser').<br>
      &nbsp;&nbsp;&nbsp; use_frames('lcamera'=&gt;'lcamera',
      'odometry'=&gt;'odometry')).<br>
      &nbsp;&nbsp;&nbsp; use_conf('mapping').<br>
      &nbsp;&nbsp;&nbsp; use_deployments(/mapping/)<br>
      Greetings<br>
      &nbsp;&nbsp;&nbsp; Janosch<br>
      <br>
      On 20.08.2012 18:24, Chris Mueller wrote:<br>
    </div>
    <blockquote cite="mid:503264AA.9050000@dfki.de" type="cite">
      <meta http-equiv="content-type" content="text/html;
        charset=ISO-8859-1">
      Hi Roby-Users,<br>
      <br>
      i've currently met another magic behaviour in roby that is
      probably not known for everyone and i think personally not very
      obvious, especially<br>
      for new roby users. The documentation mentioned this feature
      indeed, but i would recommend to add more concret details for it.
      <br>
      <br>
      I've already mentioned in the past, that it was not clear for
      myself how roby is choosing the correct physical deployment <br>
      if there exists more than one deployment providing a specific
      Orocos Task. This issue is documented in:<br>
      <meta http-equiv="content-type" content="text/html;
        charset=ISO-8859-1">
      <a moz-do-not-send="true"
href="http://rock-robotics.org/master/documentation/system/subsystem_design.html">http://rock-robotics.org/master/documentation/system/subsystem_design.html</a>
      (Topic: Orocos Deployments)<br>
      <br>
      It says this is usually a policy issue and especially for roby
      devices there is clear rule how it works. <br>
      <br>
      "If the task context is a device driver, i.e. needs to access
      hardware, ambiguities are not acceptable (one deployment might
      have access to the required hardware while the other has not). In
      this case, the deployment that has the same name than the device
      will be used (if there is one), or an error will be generated."<br>
      <br>
      If have currently some trouble to use this description for the
      concret implemention.<br>
      <br>
      Here is a short example. Assume you have the following
      deployments:<br>
      <br>
      simple_deployment("pwm_led", "pwm_gumstix::Task")<br>
      simple_deployment("pwm_servo", "pwm_gumstix::Task")<br>
      <br>
      In your config/ directory you have a ruby file that defines all
      robot devices. e.G:<br>
      <br>
      Robot.devices do<br>
      &nbsp; device(Dev::PwmControl, :as =&gt; "led").with_conf("led")<br>
      &nbsp; device(Dev::PwmControl, :as =&gt; "servo").with_conf("servo")<br>
      end<br>
      <br>
      With driver_mapping in models/orogen/pwm_gumstix.rb:<br>
      <br>
      class PwmGumstix::Task<br>
      &nbsp; driver_for "Dev::PwmControl" do<br>
      &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; provides Srv::AnyService<br>
      &nbsp; end<br>
      end<br>
      <br>
      The concret problem is now: How can Roby match the correct
      deployment process to the right device and if you try to
      instanciate the current model<br>
      for this example you get an error of the form:<br>
      &nbsp;&nbsp; multiple deployments for Dev::PwmControl:&nbsp;&nbsp; pwm_led, pwm_servo<br>
      <br>
      The solution is very simple: the ":as" property is not only an
      internal identifier for the roby devices.&nbsp; The name of this
      property must also match the<br>
      name of a existing deployment. This is some explicit mapping
      mechanism that was completely unknown for myself and its very
      helpful to know, <br>
      if your system has several devices using the same TaskContext
      type.<br>
      <br>
      Here is the simple fix for this problem:<br>
      &nbsp; device(Dev::PwmControl, :as =&gt; "pwm_led").with_conf("led")&nbsp; #
      for deployment pwm_led<br>
      &nbsp; device(Dev::PwmControl, :as =&gt;
      "pwm_servo").with_conf("servo") # for deployment pwm_servo<br>
      <br>
      Hope you are not struggling about that like I did.<br>
      <br>
      Chris<br>
      <meta http-equiv="content-type" content="text/html;
        charset=ISO-8859-1">
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
Rock-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Rock-dev@dfki.de">Rock-dev@dfki.de</a>
<a class="moz-txt-link-freetext" href="http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev">http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev</a>
</pre>
    </blockquote>
    <br>
    <br>
    <pre class="moz-signature" cols="72">-- 
 Dipl. Inf. Janosch Machowinski
 SAR- &amp; Sicherheitsrobotik
 
 DFKI Bremen
 Robotics Innovation Center
 Robert-Hooke-Stra&szlig;e 5
 28359 Bremen, Germany
 
 Phone: +49 (0)421 178 45-6614
 Fax:   +49 (0)421 178 45-4150
 E-Mail: <a class="moz-txt-link-abbreviated" href="mailto:robotik@dfki.de">robotik@dfki.de</a>
 
 Weitere Informationen: <a class="moz-txt-link-freetext" href="http://www.dfki.de/robotik">http://www.dfki.de/robotik</a>
 -----------------------------------------------------------------------
 Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
 Firmensitz: Trippstadter Stra&szlig;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>
  </body>
</html>