Yarp: Specified assumed motor serialization in YARP motor interfaces

Created on 8 Oct 2018  路  3Comments  路  Source: robotology/yarp

Is your feature request related to a problem? Please describe.
For motor-related YARP interfaces (such as IMotorEncoder ) there is no way to know to which motor the measured quantities are relative to. This implicit information is quite obvious for robots with direct coupling (one motor always actuates one joint) but it is a common source of errors for coupled joints (such as the iCub 1/2's torso and shoulder).

Describe the solution you'd like
Possible solutions:

Library - YARP_dev FeaEnh Req

Most helpful comment

To quickly recap our f2f meeting:

  • it's ok to add getMotorName (int motor, std::string &motorName) in a new interface IMotorInfo馃憤
  • if we need to get the list of motors associated to a particular joint, this should not be in IMotorInfo, since the input is a joint and not a motor, and it would be nice to avoid promiscuous interfaces. i.e. all the methods belonging to an interface should have, if possible, consistent inputs (joints ids OR motors ids). So this method should belong to IAxiaInfo (or another interface).

All 3 comments

uhm, in the first case (IAxisInfo), the interface works on a joint basis. What is the return value of getMotorName that you recommend in the case of a coupled joint? An array of ids?

uhm, in the first case (IAxisInfo), the interface works on a joint basis. What is the return value of getMotorName that you recommend in the case of a coupled joint? An array of ids?

I was thinking of having some methods working on a joint basis (getAxisName/getJointType) and another working on a motor-basis, something like bool getMotorName (int motor, std::string &motorName)=0 . Perhaps this is too confusing, and that would be a point in favor of a separate IMotorInfo.

To quickly recap our f2f meeting:

  • it's ok to add getMotorName (int motor, std::string &motorName) in a new interface IMotorInfo馃憤
  • if we need to get the list of motors associated to a particular joint, this should not be in IMotorInfo, since the input is a joint and not a motor, and it would be nice to avoid promiscuous interfaces. i.e. all the methods belonging to an interface should have, if possible, consistent inputs (joints ids OR motors ids). So this method should belong to IAxiaInfo (or another interface).
Was this page helpful?
0 / 5 - 0 ratings

Related issues

lornat75 picture lornat75  路  4Comments

Nicogene picture Nicogene  路  4Comments

drdanz picture drdanz  路  3Comments

CarlottaSartore picture CarlottaSartore  路  3Comments

traversaro picture traversaro  路  4Comments