[Rock-dev] assumptions in joint_dispatcher -- NamedVector

Steffen Planthaber Steffen.Planthaber at dfki.de
Fri Mar 7 09:42:20 CET 2014


Am 07.03.2014 09:16, schrieb Jakob Schwendner:
> Hi,
>
>> If an (named) element does not exist, it should be created when using the
>> operator[](std::string name).
> I am against this, as it will then result in a silent failure when the joint is read.

Good point, only saw the writing, not the reading aspect.

>
>> This way motion controllers do not have to initialize the size of the vector in
>> configuration state, which again eliminates the need to put the joint names
>> or the number of total joints into an configuration file
>> (.yml) for the controller at all (one place less where they are defined).
> This imo breaks the modeling aspect, that we are so proud to have in rock. You should let the model define what the component generates, or should generate. This way you can do verification if e.g. a joint is not available, even though it should be.

Well, when writing the values in a controller, you have to write the 
values in cpp nevertheless. So whats the point of having an additional 
model which tells the controller something which is already hard-coded 
in the sources?

> I know that there is a case, where you have joint drivers, that don't reliably put out all joints at the same time, especially at startup. [...]

This is not the issue, the issue is a config file containing this:

config:
   wheelRadius: 0.21
   zeroPose:
     names:
       - FL_thorax
       - FL_basal_a
       - FL_basal_b
       - FL_wheel_tilt
       - FL_wheel_angleofattack
       - FL_wheel_direction
       - FL_wheel_speed
       - FR_thorax
       - FR_basal_a
       - FR_basal_b
       - FR_wheel_tilt
       - FR_wheel_angleofattack
       - FR_wheel_direction
       - FR_wheel_speed
       - RL_thorax
       - RL_basal_a
       - RL_basal_b
       - RL_wheel_tilt
       - RL_wheel_angleofattack
       - RL_wheel_direction
       - RL_wheel_speed
       - RR_thorax
       - RR_basal_a
       - RR_basal_b
       - RR_wheel_tilt
       - RR_wheel_angleofattack
       - RR_wheel_direction
       - RR_wheel_speed
       - man_motor1
       - man_motor2
       - man_motor3
       - man_motor4
       - man_motor5
       - man_motor6

For a motion controller, which then writes the values directly in cpp 
regardless of the configuration (e.g. joints["wheel"].speed = 0.5;). 
Here you would have also to define that wheel exists in the .yml, even 
when the controller was programmed to just control the "wheel" (the 
controller knows that wheel exists).


So you define the Joint names twice:
a) In the code when writing the values
b) In the configuration above just to check whether the controller 
writes existent values (controller should know which joints to contol).

For components where base::commands::joint values are written, the 
definition of joints is just doubled.



Kind regards,

Steffen


>
> Cheers,
>
> Jakob
>
>


-- 
  Steffen Planthaber
  Weltraumrobotik

  Besuchsadresse der Nebengeschäftstelle:
  DFKI GmbH
  Robotics Innovation Center
  Robert-Hooke-Straße 5
  28359 Bremen, Germany

  Postadresse der Hauptgeschäftsstelle Standort Bremen:
  DFKI GmbH
  Robotics Innovation Center
  Robert-Hooke-Straße 1
  28359 Bremen, Germany

  Tel.:     +49 421 178 45-4125
  Zentrale: +49 421 178 45-0
  Fax:      +49 421 178 45-4150 (Faxe bitte namentlich kennzeichnen)
  E-Mail:   Steffen.Planthaber 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
  -----------------------------------------------------------------------



More information about the Rock-dev mailing list