Closed Nicogene closed 1 year ago
Based on my knoledge, I think it is useful to strictly separate:
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 https://github.com/robotology/icub-models/issues/30#issuecomment-659972373).
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):
IAxisInfo
and IEncoders
interface deal with actuated axisIf 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.
Anyhow, I am afraid that this topic may deserve an in-person discussion.
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 https://en.wikipedia.org/wiki/Kinematic_pair), that for sure is less ambigous but also less intuitive to understand what it is.
fyi @giulioromualdi @S-Dafarra, this is also related to your attempts of building a visualized for the iCub's hand.
icub gazebo was originally configured to expose 4 joints [there is a section coupled joints in the control board ini file), one for the coupled joints, one for the physical one. In this way the rempaper&nws should be attached only the physical joints. On the real robot a similar trick can be used, considering also that the position of the fingers are exposed through different interfaces, not related to motion control (i.e. analog sensors/PSC board)
[This is not an issue related to this repo, it should be moved elsewhere. Please put here a link]
Today I tried to run
robot_state_publisher
withiCubGazeboV2_5_visuomanip
urdf model but openingrviz2
I got these errors:(same thing for the right part)
I suspected that there were issues in the kinematic chains, but this might not be the case since @Xenvre and @pattacini used this model for grasping for a while (https://robotology.github.io/icub-gazebo-grasping-sandbox/). Then chatting with @Xenvre we realized that the problem is that the topic
/joints_state
publish the position, velocity, and effort of, for example,eye_version
butrobot_state_publisher
does not know the coupling law for computing the tf ofl_eye
andr_eye
given that joint value over time. Same thing for the fingers.I am not aware of how is usually handled the under actuation in ros/ros2, maybe the coupling laws should be provided by the device and then used by the nws in order to publish also the joint values of the decoupled joints.
Somehow related to https://github.com/robotology/gazebo-yarp-plugins/issues/470
Here are some images from rqt
cc @pattacini @traversaro @Xenvre @randaz81 @elandini84