[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