How to handle the physical joints and actuated axis in YARP/ROS2

[Nicogene]

This question came out after trying to visualize iCub tfs on rviz2, we noticed that robot_state_publisher cannot publish the tf for the frames of the eyes and hands since they are underactuated (physical joints > actuated axis) and it does not know the coupling laws.

YARP and analogously ROS2 nws publishes on /joints_state only actuated axis, probably we need an additional layer that handles these coupling laws.

Somehow related to robotology/gazebo-yarp-plugins#470

cc @pattacini @traversaro @xEnVrE @randaz81 @elandini84

[Nicogene]

@traversaro said:

Based on my knoledge, I think it is useful to strictly separate:

• Physical joints, i.e. the revolute or prismatic constraints between physical rigid bodies.
• Actuated axis, i.e. the quantities that are controlled by the low level position control loops.

The nomenclature is definitely not homogenous across software and publications, so feel free to propose better names if you like (it would be great to have a better name for physical joint, as "joint" is an extremly overloaded name). The two concepts are quite similar if for each joint you have a single actuated axis, so in those context the difference is not considered. However, as soon as we have either fully actuated mechanisms (i.e. more and less number of joints == number of actuated axis), but in which the actuated axis does not match the physical joints (such as in the case of the iCub's eyes) or under actuated mechanism, i.e. more and less number of joints > number of actuated axis, such as iCub's hand) it is important to fully distinguish the two concepts, starting from the documentation of the mechanism (see robotology/icub-models#30 (comment)).

A related concept (but I do not think there is a direct connection) is the transmission_interface feature of ros_control.

In this case, it seems to me that (but it is just an intuition based on the introspection):

- ROS's joint state message and URDF's historically deals with physical joints (how can you model an "actuated axis" in URDF otherwise?)
- YARP's IAxisInfo and IEncoders interface deal with actuated axis

If my assumptions are true, then it does not make a lot of sense to publish actuated axis on /joint_state, but we should rather publish physical joints values (if we have them) on /joint_state, perhaps changing something on the YARP side, for example adding an interface to the devices to exposing physical joints metadata (names) and values, that seems easier then adding a way to expose coupling laws.

If my assumptions are true, then it does not make a lot of sense to publish actuated axis on /joint_state, but we should rather publish physical joints values (if we have them) on /joint_state, perhaps changing something on the YARP side, for example adding an interface to the devices to exposing physical joints metadata (names) and values, that seems easier then adding a way to expose coupling laws.

An additional note on this: for under-actuated mechanisms, even if you have the values of the actuated axis and the coupling laws, in general you cannot reconstruct the exact value of the physical joints, that instead may be available in some other way (for example via additional encoder sensors, as the MAIS sensors in iCub 1/2 hands).

so feel free to propose better names if you like (it would be great to have a better name for physical joint, as "joint" is an extremly overloaded name).

A possible alternative name for "physical joint" is "kinematic pair" (see en.wikipedia.org/wiki/Kinematic_pair), that for sure is less ambigous but also less intuitive to understand what it is.

[traversaro]

If my assumptions are true, then it does not make a lot of sense to publish actuated axis on /joint_state, but we should rather publish physical joints values (if we have them) on /joint_state, perhaps changing something on the YARP side, for example adding an interface to the devices to exposing physical joints metadata (names) and values, that seems easier then adding a way to expose coupling laws.

@randaz81 in robotology/yarp-devices-ros2#48 (comment) suggested an alternative idea to avoid the need to define new interfaces, that I think it is quite interesting. Basically, he suggested to create new separated YARP devices to represent physical joints, and then used those combined with the controlboardremapper to compose a whole-body representation of physical joints, that then you can use with the controlBoard_nws_ros2.

For example, in the case of the iCub 2 we could define two new YARP devices:

• iCubPhysicalJointsHead
• iCubPhysicalJointsArm

These devices could attach to the existing devices of the iCub that provide useful information (such as head's controlboard for iCubPhysicalJointsHead and arms's controlboards and mais for iCubPhysicalJointsArm), and expose via the usual controlboard interfaces (mainly IAxisInfo and IEncoders) the required informations. The only doubts that I have is that we should be sure that everything works fine even if these devices to not implement any control-related interface.

[traversaro]

By the way, by discussing this I realized robotology/icub-main#851 .