[Rock-dev] Proposal for adding velocity information in base::actuators::Status

[Sylvain Joyeux]

On 04/05/2012 01:41 PM, Matthias Goldhoorn wrote:
> On 05.04.2012 13:39, Sylvain Joyeux wrote:
>> On 04/05/2012 12:03 PM, Javier Hidalgo Carrió wrote:
>>> Hello rocks,
>>>
>>> In Sherpa robot we are receiving angular position and angular velocity
>>> information of every joints in the robot every 40ms coming from the
>>> lower level (FPGA and Monster).
>>>
>>> The rock data type base:actuators::Status is the data type in rock for
>>> joint information, which contains:
>>>
>>>                struct MotorState {
>>>                 int      current;  //! current in mA
>>>                 double   position; //! position in radians
>>>                 double   positionExtern; //! position of external encoder
>>> in radians
>>>                 float    pwm;      //! duty cycle in [-1; 1]
>>>
>>>                 MotorState()
>>>                     : current(0), position(0), positionExtern(0), pwm(0) {}
>>>             };
>>>
>>> I was wondering which is the correct data type to store joint velocities
>>> information and if any what about include it in base:actuators::Status
>>>
>>> Any suggestion?
>> 1/ do not add it to Status
>> 2/ my suggestion is: let's try to rationalize all that stuff.
>>       Obviously, the current Status type does not scale.
>> 3/ velocity and position information are redundant (since you can
>>       compute one from the other). Since joint sensors are usually
>>       position, we went for position. Is there a direct velocity joint
>>       measurement on Sherpa ? What is the point of having both values ?
>>
> If we cleanup this "think" we should also remove the separation between
> internal and external encoders, this Sounds really asguard specific...
That's what I thought at the beginning, but it is actually not. One very 
often have the distinction between the actuator part of the joint and 
the actuated part, because there is often play or flexible parts in 
between. Having both measurements is not uncommon, and makes sense.

Now, I'm not saying that they should be managed in this data structure. 
That's what should be re-thought.

One way to think about it is here:

 
http://people.mech.kuleuven.be/~tdelaet/geometric_relations_semantics/doc/geometric_semantics/html/annotated.html

I personally like the general approach, but I feel that the overall 
implementation is pretty overkill ... But YMMV.
-- 
Sylvain Joyeux (Dr.Ing.)
Space & Security 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
-----------------------------------------------------------------------