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:
getMotorName method to the IAxisInfo interfaceIMotorInfo interface, that contains the getMotorName method? This IMotorInfo could also provide coupling information (the OPC UA Companion Specification for Robotics draft, Section 7.4 PowerTrainType contains an information model for coupling, we could copy its semantics to avoid engineering a custom solution). 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:
getMotorName (int motor, std::string &motorName) in a new interface IMotorInfo馃憤 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).
Most helpful comment
To quickly recap our f2f meeting:
getMotorName (int motor, std::string &motorName)in a new interfaceIMotorInfo馃憤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).