[Rock-dev] joint_dispatcher

[Matthias Goldhoorn]

On 30.09.2013 14:16, 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.

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.
One component should eitehr write to ALL joints or only to a subset of 
joints where it is resposible for.

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:
     a) all dimensions/joints are controllers
     b) no double-control is done b other components.

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.

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.




>
> >
> > 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?
> cheers,
> Jakob
>
>
> _______________________________________________
> Rock-dev mailing list
> Rock-dev at dfki.de
> http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev


-- 
  Dipl.-Inf. Matthias Goldhoorn
  Space and Underwater Robotic

  Universität Bremen
  FB 3 - Mathematik und Informatik
  AG Robotik
  Robert-Hooke-Straß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:   matthias.goldhoorn at uni-bremen.de

  Weitere Informationen: http://www.informatik.uni-bremen.de/robotik

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