[Rock-dev] joint_dispatcher

Dennis Mronga dennis.mronga at dfki.de
Thu Oct 10 13:32:34 CEST 2013


On 09.10.2013 15:31, Sylvain Joyeux wrote:
> On 09/30/2013 02:16 PM, Jakob Schwendner wrote:
>>
>> On September 25, 2013 at 5:28 PM Dennis Mronga 
>> <dennis.mronga at dfki.de> wrote:
>> > Hi,
>> >
>> > I recently stumbled across the joint_dispatcher component, which
>> > "nearly" seems to be what I need. However, it seems a bit 
>> complicated to
>> > configure and I think it does not cover the following cases:
>> I can second the complicated to configure bit :) Since I got it 
>> working, it was working fine for my case.
>>
>> >
>> > 1. Send only a subset of all available joints to the input ports and
>> > dispatch them correctly to the outputs, instead of always expecting 
>> all
>> > available joints. Right now, the component crashes with an unhandled
>> > exception, if you do not send all joints to the input port.
>> 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.
>>
>> >
>> > 2. Get input from different sources and dispatch arbitrary subsets of
>> > the inputs. E.g. if you have the joint state of the wheels and the 
>> joint
>> > state of the manipulator as inputs and you want to output the port
>> > "odometry" containing only the wheels, "manipulator" containing 
>> only the
>> > manipulator and "full_joint_state" containing all joints.
>> Yes, this I couldn't get working either, and would have needed. 
>> Currently I am running two components in parallel to get this behaviour.
>>
>> >
>> > Generally I think it would be nicest, if you just have to configure 
>> the
>> > input and output ports with the corresponding joint names and the
>> > distribution of the joint states is done by the component according to
>> > the joint names. However, I think that would reduce a bit the
>> > capabilities of the component!?
>> Yes, would have thought the same. It gets a little complicated 
>> because of the duality of the names/index mechanism in the Joints class.
>> 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.
>>
>> >
>> > Before creating a branch and adding the functionality that I need, I
>> > would like to know if anyone of you has used the joint_dispatcher and
>> > has some remarks!?
>> 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.
>> My preferred configuration would be something like:
>> struct DispatchOutput
>> {
>> string name; // name of dynamic port
>> vector<string> jointNames; // list of joint names
>> vector<string> internalNames; // list of internal names for the joints
>> }
>> struct DispatchInput
>> {
>> string name; // name of dynamic port
>> vector<string> internalNames; // list of internal names for the joints
>> vector<string> jointNames; // list of external joint names
>> }
>> module
>> {
>> vector<DispatchInput> inputs;
>> vector<DispatchOutput> outputs;
>> }
>> 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?
> I quite like the idea of assigning internal names.
>
> 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.
>
> I had an alternative proposal in mind, so there it is:
>
>   /** Description of the set of joints on a single input
>    *
>    * If both byIndex and byName are empty, the whole input is selected
>    */
>   struct Input
>   {
>       /** Name of the input port */
>       std::string name;
>       /** Selection of the joints by index */
>       std::vector<int> byIndex;
>       /** Selection of the joints by name */
>       std::vector<std::string> byName;
>   };
>
>   /** Description of a dispatched output */
>   struct Dispatch
>   {
>      /** Name of the output port */
>      std::string outputName;
>      /** (optional) Name of the joints on the output.
>          If empty, simply copy the names from the inputs */
>      std::vector<std::string> jointNames;
>      /** Description of where the joints should be copied from */
>      std::vector<Input> joints;
>   };

Looks fine to me and would sufficiently cover our cases.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.dfki.de/pipermail/rock-dev/attachments/20131010/30a32c8a/attachment.htm 


More information about the Rock-dev mailing list