Implement JointLink

[omichel]

In order to be more scalable than #1359 and include non-motorized joints, the following design proposes joint links allowing to couple motorized and non-motorized joints.

We should implement the JointLink node as:

JointLink {
  field SFString endPointName ""    # name of the Solid end point of the linked joint
  field SFFloat multiplier     1    # gear/pulley ratio (may be negative to reverse motion)
  field SFFloat gain        0.95    # energy gain (should be < 1 for purely mechanical system)
  field SFInt32{1, 2, 3} jointId 1  # joint identifier
}

And we should add link fields to all joint types:

HingeJoint {
  field MFNode link [ ]
}

Hinge2Joint {
  field MFNode link  [ ]
  field MFNode link2 [ ]
}

BallJoint {
  field MFNode link  [ ]
  field MFNode link2 [ ]
  field MFNode link3 [ ]
}

SliderJoint {
  field MFNode link [ ]
}

Example usage:

Hinge2Joint {
  link2 [
    JointLink {
      endPointName "arm"
      jointId 1
    }
  ]
}

Hinge2Joint {
  endPoint Solid {
    name "arm"
  }
}

In the above example, the second axis of the first hinge2 joint is coupled to the first axis of the second hinge2 joint.

[DavidMansolino]

Once implemented, this should be used here:

webots/projects/robots/boston_dynamics/spot/protos/SpotLeftLeg.proto

Line 58 in 403fa19

name %{= "\"" .. legName .. " piston motor\"" }%

[DavidMansolino]

And here:

webots/projects/robots/fp_robotics/p-rob3/protos/P-Grip.proto

Line 283 in 017d6f5

DEF LEFT_FINGER HingeJoint {

[tlemarec]

My team and I would really appreciate this feature. Any news on the progress ?

[omichel]

We are reconsidering the design of this approach and will likely implement it in the form of coupled motors, e.g., several RotationalMotor and/or LinearMotor nodes with the same device name and with a single control interface. A multiplier parameter will be added to the Motor nodes to make them handle the same command differently.

[tlemarec]

What about the behaviour when no command is applied ? For example setTorque(0).
In this case wouldn't the joints behave like they were uncoupled ?

[omichel]

Yes.

[tlemarec]

The following robot uses a four bar linkage to keep similar joint angles between the elbow and the end effector :

This can be modelled no problem using the existing tools of Webots.

A similar behaviour can be achieved with a belt or a cable between the two joints. By actuating only one of them, the other moves as well. Their angles stays equals when the belt ratio is equal to one.
This solution allow a wider range of movement when compared to the four bar linkage : multiple turns are possible instead of less than half a turn.

Currently their is no way to model this behaviour in Webots.

I think the JointLink paradigm can be used to model that. I am not sure the Coupled Motor one would be able to.
Even when the motor of the coupled joints is off, they keep an equal angle because of the mechanical constraints between them.

What are your thoughts on that ?

[omichel]

I believe such a robot structure, including mechanical loops should be modeled using the SolidReference node, in a similar way as the Khepera3 Gripper:

https://www.youtube.com/watch?v=fWdvK0YrZO0

There is probably no need for coupled motors or JointLink.

[tlemarec]

Yes, the structure I showed in the image and Khepera3 gripper are identical in their mechanical structure.

But not the variation I explained after : when the two joints are coupled using a belt between their two axis. In this case the additional bodies used to create the parallel structure / closed loop are not present.

I don't see how to model this variation without JointLink.
One crude solution would be to add bodies to create a four bar linkage and recreate the mechanical constraint this way.

• This greatly increase the complexity of the model.
• And reduce its accessible movements : A four bar linkage structure because singular when flat so the amplitude of either of the two main joints is no more than 180 degrees.

For reference : In Bullet, ̀GearConstraints` can be used to model this behaviour. The belt system can be seen as a gear system of ratio +1

[omichel]

I see. In your case I believe you would need the JointLink as it is described here. However, its implementation with ODE is not trivial and we have no plan to implement it on the short term. Our priority now is to implement the coupled motors, which will not fully help you with this problem as it won't work in the passive case. However, if you absolutely need this feature and would like to sponsor the development of it, please contact sales@cyberbotics.com for an offer.

[tlemarec]

Ok, thanks for the discussion, we will probably contact the sales department then.

[omichel]

I am closing this issue as I believe we have made significant progresses with coupled motors in #2939.
For mechanically coupled passive devices, I believe the best is to implement mechanical systems involving possibly closed mechanical loops with SolidReference.

[tlemarec]

Hello, since #2939 is not enough to couple passive devices (see my comments above), was there any progress on pure joint links ?
For joints coupled by a belt for example ?

Thanks

[omichel]

No, I would recommend the SolidReference route for passive coupled devices.

[tlemarec]

Ok.
So it is still impossible to model belts in webots (see comment above).
We will check back in the future.