Meshcat animation playback broken due to coupled joints

[xEnVrE]

I am running the robot-log-visualizer on some data recorded in simulation with the ergoCub robot.

The data is there - as I can see it from the plots - however the robot animation inside the Meshcat plugin is not moving.

While looking at the output inside the terminal I noticed the following:

[ERROR] Model :: getJointIndex : jointName l_thumb_oc not found in the model.
[ERROR] SubModelDecomposition::splitModelAlongJoints error :  requested to split the model along joint l_thumb_oc but no joint with that is in the model. 
[ERROR] createReducedModel error :  error in splitting models across joints.

Not sure if that is happening at the Meshcat level or somewhere else, e.g. when evaluating the pose of the meshes using the forward kinematics.

Nonetheless, the error makes sense as the joint l_thumb_oc, as many others in ergoCubSN000 and ergoCubSN001, is just the name of a quantity that the user can control via YARP causing the motion of two distinct physical joints, namely l_thumb_prox and l_thumb_dist. Indeed, these are also the name of such joints inside the URDF, as can be seen here and here.

The solution to the above problem is probably connected to https://github.com/robotology/yarp/pull/3026, whose implementation has just kicked off. Meanwhile, do you think it makes sense to provide something like a workaround?

Thank you

cc @GiulioRomualdi

[GiulioRomualdi]

Hi @xEnVrE. I'm pretty happy you also use the visualizer ;) The problem here is related to iDynTree which cannot find the joint of the model. 😢

A possible solution is to load only the joints that can be actually found in the urdf model. Still, it is not clear to me how it can be done since we do not know the joints in advance

[xEnVrE]

It is a bit convoluted as we would accept to lose the animation of the joints for which there is a missing counterpart in the URDF while still showing all the others for which the joint name exists in the URDF. At the moment, instead, the tool stops working for all of them, of course.

Do you think that including an optional list of joints to be excluded, to be populated by the user, is too much?

[GiulioRomualdi]

Hi @xEnVrE, thanks for #70. If you load a dataset with recorded coupled joints, you should now be able to see the robot animation move correctly. Since we're not storing the joint coupling law, we've decided to only move the non-underactuated joints.

[xEnVrE]

Thanks @GiulioRomualdi.

cc @PasMarra