[Rock-dev] joint_dispatcher

[Sylvain Joyeux]

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;
  };

-- 
Sylvain Joyeux (Dr.Ing.)
Senior Researcher

Space & Security Robotics
Underwater Robotics

!!! Achtung, neue Telefonnummer!!!

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

Phone: +49 (0)421 178-454136
Fax:   +49 (0)421 218-454150
E-Mail: robotik at dfki.de

Weitere Informationen: http://www.dfki.de/robotik
-----------------------------------------------------------------------
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
----------------------------------------------------------------------- 

-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: http://www.dfki.de/pipermail/rock-dev/attachments/20131009/a5d7c9a2/attachment.htm