What is the status of mimic joint support?

[costashatz]

Hello,

Thanks for the nice library.

What is the current status of support for mimic joints?

If I use for example forwardDynamics() with a robot that has mimic joints, will it ensure that the mimic joints try to follow their "parent" joints?

Thanks a lot!

[jcarpent]

Hi @costashatz,

The current version of Pinocchio is not completely able to handle mimic joints (explicit loop constraint on joint motions). We are about to release soon a new version of Pinocchio (3.0) able to handle any loop constraint in an easy and robust way.

The remaining question is in terms of API and remains an open question to me. Do you want for instance that the configuration vector and velocity appears or not in the whole configuration vector and velocity of the robot kinematics? Could you give us some feedback on your case study?

Thanks in advance.

[jcarpent]

Related to #1274.

[costashatz]

The current version of Pinocchio is not completely able to handle mimic joints (explicit loop constraint on joint motions). We are about to release soon a new version of Pinocchio (3.0) able to handle any loop constraint in an easy and robust way.

Great! How close is soon? (I know when I say soon I mean 1-12 months :stuck_out_tongue:)

Could you give us some feedback on your case study?

So my usage would be the following:

• Define a robot with mimic joints
• I get/set joint positions/velocities/accelerations/torques: here it'd be nice if there is a helper function to filter out mimic/locked joints (we are doing something similar in robot_dart, see here, and here, where we can basically query all the dofs with names or specific characteristics and then all getters/setters accept dof_names/indices as input to help the user)
• I want to call algorithms (fk, fd, id) and get the expected behavior: for example, in FK I'd expect my input to mimic joints to be ignored and the constraints to be followed; or in FD the input torques to mimic joints to be ignored and the generated accelerations to be computed such that the joint tries to follow the constraint. I hope this is clear: I tend to write big sentences.

I think this is it for now (I'll come back if I think of something more).

Thanks for the fast reply!

[jcarpent]

As joint-mimic are simple explicit constraint linking a referent joint to a mimic joint, we may imagine that the information of the current joint configuration, velocity, acceleration or torque should not be supplied by the end-user, but directly deduced from the referent joint. I think this description is going in the sense of your way of proceeding in your previous example.

Concerning Pinocchio's policy on fixed joint, we remove them from the kinematic tree and keep its information as a dedicated Frame. In this way, we avoid unecessary computations and storage.

For the release of the new code, we may expect to release the code in few weeks, less than one month from today I would say.

[costashatz]

I think this description is going in the sense of your way of proceeding in your previous example.

Indeed. You can completely remove them from the end-user.

Concerning Pinocchio's policy on fixed joint, we remove them from the kinematic tree and keep its information as a dedicated Frame. In this way, we avoid unecessary computations and storage.

Yes this makes sense. In robot_dart we allow online changes of types of joints, and we do not want to lose track of them (this is allowed by DART actually), but for control locked joints are useless and we have this map to remove them easily. This map also allows us to connect different libraries more easier (we just need to connect names of dofs).

For the release of the new code, we may expect to release the code in few weeks, less than one month from today I would say.

Great!

[costashatz]

@jcarpent do you want me to close this? I am satisfied with your responses..

[jcarpent]

No problem to keep this issue opened ;)

[jelavice]

Hi, thanks for open sourcing this great library :)

I was wondering what is the status on the mimic joint support? If I am not mistaken, the functionality has not been implemented yet.

If you have any suggestions on possible workarounds that would be great.

[jcarpent]

@jelavice What would be your typical usage? Could you provide a tiny example?

[jelavice]

Thanks for your reply @jcarpent

My use case would be similar to what costashatz has described. Run the algorithms (I am mainly interested in FK and IK) without mimic joints exposed in the state.

For example you can set the robot state (generalized coordinates) of all the non-mimic joints and the FK ensures that all the constraints introduced by the mimic joints are followed. Or being able to get Jacobians without mimic joints in the state.

If I am not mistaken, this can all be achieved with some extra code for indexing on the user side.