<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">On 09.10.2013 15:31, Sylvain Joyeux
wrote:<br>
</div>
<blockquote cite="mid:52555AC9.6040903@dfki.de" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<div class="moz-cite-prefix">On 09/30/2013 02:16 PM, Jakob
Schwendner wrote:<br>
</div>
<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> </div>
<div> <br>
On September 25, 2013 at 5:28 PM Dennis Mronga <a
moz-do-not-send="true" class="moz-txt-link-rfc2396E"
href="mailto:dennis.mronga@dfki.de"><dennis.mronga@dfki.de></a>
wrote: <br>
> Hi, <br>
> <br>
> I recently stumbled across the joint_dispatcher
component, which <br>
> "nearly" seems to be what I need. However, it seems a bit
complicated to <br>
> 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>
> <br>
> 1. Send only a subset of all available joints to the
input ports and <br>
> dispatch them correctly to the outputs, instead of always
expecting all <br>
> available joints. Right now, the component crashes with
an unhandled <br>
> 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>
<div> <br>
> <br>
> 2. Get input from different sources and dispatch
arbitrary subsets of <br>
> the inputs. E.g. if you have the joint state of the
wheels and the joint <br>
> state of the manipulator as inputs and you want to output
the port <br>
> "odometry" containing only the wheels, "manipulator"
containing only the <br>
> 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>
> <br>
> Generally I think it would be nicest, if you just have to
configure the <br>
> input and output ports with the corresponding joint names
and the <br>
> distribution of the joint states is done by the component
according to <br>
> the joint names. However, I think that would reduce a bit
the <br>
> 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>
<div> <br>
> <br>
> Before creating a branch and adding the functionality
that I need, I <br>
> would like to know if anyone of you has used the
joint_dispatcher and <br>
> 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> </div>
<div> My preferred configuration would be something like: </div>
<div> </div>
<div> struct DispatchOutput </div>
<div> { </div>
<div> string name; // name of dynamic port </div>
<div> vector<string> jointNames; // list of joint names </div>
<div> vector<string> internalNames; // list of internal
names for the joints <br>
} </div>
<div> </div>
<div> struct DispatchInput </div>
<div> { </div>
<div> string name; // name of dynamic port </div>
<div> vector<string> internalNames; // list of internal
names for the joints </div>
<div> vector<string> jointNames; // list of external joint
names </div>
<div> } </div>
<div> </div>
<div id="ox-signature"> module </div>
<div> { </div>
<div> vector<DispatchInput> inputs; </div>
<div> vector<DispatchOutput> outputs; </div>
<div> } </div>
<div> </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>
</blockquote>
I quite like the idea of assigning internal names.<br>
<br>
For people using joint names, we could allow internalNames to be
empty (in which case internal names = actual names). People that
are not using names at all could leave jointNames empty, in which
case the joint-to-internal assignation would be done by index.<br>
<br>
I had an alternative proposal in mind, so there it is:<br>
<br>
/** Description of the set of joints on a single input<br>
*<br>
* If both byIndex and byName are empty, the whole input is
selected<br>
*/<br>
struct Input<br>
{<br>
/** Name of the input port */<br>
std::string name;<br>
/** Selection of the joints by index */<br>
std::vector<int> byIndex;<br>
/** Selection of the joints by name */<br>
std::vector<std::string> byName;<br>
};<br>
<br>
/** Description of a dispatched output */<br>
struct Dispatch<br>
{<br>
/** Name of the output port */<br>
std::string outputName;<br>
/** (optional) Name of the joints on the output.<br>
If empty, simply copy the names from the inputs */<br>
std::vector<std::string> jointNames;<br>
/** Description of where the joints should be copied from */<br>
std::vector<Input> joints;<br>
};<br>
</blockquote>
<br>
Looks fine to me and would sufficiently cover our cases.<br>
<br>
</body>
</html>