<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    On 30.09.2013 14:16, Jakob Schwendner wrote:
    <blockquote
cite="mid:1837010020.18244.1380543388209.JavaMail.open-xchange@ox6.dfki.de"
      type="cite">
      <meta content="text/html; charset=ISO-8859-1"
        http-equiv="Content-Type">
      <div> &nbsp; </div>
      <div> <br>
        On September 25, 2013 at 5:28 PM Dennis Mronga
        <a class="moz-txt-link-rfc2396E" href="mailto:dennis.mronga@dfki.de">&lt;dennis.mronga@dfki.de&gt;</a> wrote: <br>
        &gt; Hi, <br>
        &gt; <br>
        &gt; I recently stumbled across the joint_dispatcher component,
        which <br>
        &gt; "nearly" seems to be what I need. However, it seems a bit
        complicated to <br>
        &gt; configure and I think it does not cover the following
        cases: </div>
      <div> I can second the complicated to configure bit :) Since I got
        it working, it was working fine for my case. </div>
      <div> <br>
        &gt; <br>
        &gt; 1. Send only a subset of all available joints to the input
        ports and <br>
        &gt; dispatch them correctly to the outputs, instead of always
        expecting all <br>
        &gt; available joints. Right now, the component crashes with an
        unhandled <br>
        &gt; exception, if you do not send all joints to the input port.
      </div>
      <div> I guess this could be easily fixed in the component. In my
        opinion the best way would be to make this configurable, e.g.
        AllowPartialJointUpdate = true or something similar. </div>
    </blockquote>
    <br>
    I'm strongly against something like these flags, this makes it
    impossible for the supervision to make sre the system is in an valid
    state.<br>
    One component should eitehr write to ALL joints or only to a subset
    of joints where it is resposible for.<br>
    <br>
    e.G. there are clear components for e.g. controlling a leg, these
    components write only to leg's..., for the legs should be then one
    dispatch call done. The actuator component then makes sure that:<br>
    &nbsp;&nbsp;&nbsp; a) all dimensions/joints are controllers<br>
    &nbsp;&nbsp;&nbsp; b) no double-control is done b other components.<br>
    <br>
    If you allow spare-inputs, how would you handle separations between
    controllers?. Would you allow double-inputs?. Then we are back to
    publisher-subscriber which we don't want do to in rock.<br>
    <br>
    The supervision helps the customers to provide dataServices, the
    users should create TorsoActuatorControllerSrv which then -- if
    connect from syskit's view, results in a dispatch on the driver
    level.<br>
    <br>
    <br>
    <br>
    <br>
    <blockquote
cite="mid:1837010020.18244.1380543388209.JavaMail.open-xchange@ox6.dfki.de"
      type="cite">
      <div> <br>
        &gt; <br>
        &gt; 2. Get input from different sources and dispatch arbitrary
        subsets of <br>
        &gt; the inputs. E.g. if you have the joint state of the wheels
        and the joint <br>
        &gt; state of the manipulator as inputs and you want to output
        the port <br>
        &gt; "odometry" containing only the wheels, "manipulator"
        containing only the <br>
        &gt; manipulator and "full_joint_state" containing all joints. </div>
      <div> Yes, this I couldn't get working either, and would have
        needed. Currently I am running two components in parallel to get
        this behaviour. </div>
      <div> <br>
        &gt; <br>
        &gt; Generally I think it would be nicest, if you just have to
        configure the <br>
        &gt; input and output ports with the corresponding joint names
        and the <br>
        &gt; distribution of the joint states is done by the component
        according to <br>
        &gt; the joint names. However, I think that would reduce a bit
        the <br>
        &gt; capabilities of the component!? </div>
      <div> Yes, would have thought the same. It gets a little
        complicated because of the duality of the names/index mechanism
        in the Joints class. </div>
      <div> But, even when you don't want to use names in the Joints
        port, it would imo be ok to name them for the sake of the
        dispatcher. </div>
    </blockquote>
    <blockquote
cite="mid:1837010020.18244.1380543388209.JavaMail.open-xchange@ox6.dfki.de"
      type="cite">
      <div> <br>
        &gt; <br>
        &gt; Before creating a branch and adding the functionality that
        I need, I <br>
        &gt; would like to know if anyone of you has used the
        joint_dispatcher and <br>
        &gt; has some remarks!? <br>
        I had a discussion with Sylvain on this subject, which I guess
        would have been good to put on the mailing list. The agreement
        was, though, that changing the way the module is configured
        would be nice. </div>
      <div> &nbsp; </div>
      <div> My preferred configuration would be something like: </div>
      <div> &nbsp; </div>
      <div> struct DispatchOutput </div>
      <div> { </div>
      <div> string name; // name of dynamic port </div>
      <div> vector&lt;string&gt; jointNames; // list of joint names </div>
      <div> vector&lt;string&gt; internalNames; // list of internal
        names for the joints <br>
        } </div>
      <div> &nbsp; </div>
      <div> struct DispatchInput </div>
      <div> { </div>
      <div> string name; // name of dynamic port </div>
      <div> vector&lt;string&gt; internalNames; // list of internal
        names for the joints </div>
      <div> vector&lt;string&gt; jointNames; // list of external joint
        names </div>
      <div> } </div>
      <div> &nbsp; </div>
      <div id="ox-signature"> module </div>
      <div> { </div>
      <div> vector&lt;DispatchInput&gt; inputs; </div>
      <div> vector&lt;DispatchOutput&gt; outputs; </div>
      <div> } </div>
      <div> &nbsp; </div>
      <div> the linking between input and output would be done on the
        internal names. For the index based Joints structs (e.g. no
        names), this would name the joints internally. The reason for
        not just using a single names vector per input/output is that
        you could have a configuration where the joint names are the
        same two different input ports, or that you would want to rename
        the output ports. On the other hand, maybe we should just not
        allow this... Thoughts? </div>
      <div> &nbsp; </div>
      <div> cheers, </div>
      <div> &nbsp; </div>
      <div> Jakob </div>
      <div> &nbsp; </div>
      <div> &nbsp; </div>
      <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. Matthias Goldhoorn 
 Space and Underwater Robotic

 Universit&auml;t Bremen
 FB 3 - Mathematik und Informatik
 AG Robotik
 Robert-Hooke-Stra&szlig;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:   <a class="moz-txt-link-abbreviated" href="mailto:matthias.goldhoorn@uni-bremen.de">matthias.goldhoorn@uni-bremen.de</a>

 Weitere Informationen: <a class="moz-txt-link-freetext" href="http://www.informatik.uni-bremen.de/robotik">http://www.informatik.uni-bremen.de/robotik</a></pre>
  </body>
</html>