D6 Joint: A good choice?

[FlimFlamm]

Hey all. Looking for thoughts/opinions/perspective on the D6 joint as a mainstay in robot rigs.

In older version of physX (specifically Unity3D's "ConfigurableJoint") it's really the most powerful kind of joint (with practically no drawbacks assuming you know how to configure it). but I haven't yet seen the D6 used anywhere in omniverse, and I've read that it has some behavioural issues with the TGS solver, So im wondering if there are difficulties or issues with it that might make it a poor choice for socket and ball joints that also have a bit of twist capability (and a few other niche use cases that call for all 6 drives to be used at once). I like to build exotic and sometimes physically unrealistic rigs (eg: a 6DOF disembodied hand/wrist), but if anyone has reasons why it's not a good long term choice, I'd love to hear them, as i'm somewhat of an omniverse/isaac beginner!

[FlimFlamm]

So far I found at least one issue pretty quickly once i started toying around (high confidence it's not my own error).

Imagine you had a turret and you wanted to set targets based on azimuth and elevation (an imaginable use case for this configuration); you'd have to have a revolute joint spin the base, and then another to angle the turret up and down. I tried to do both with a single D6 joint... But:

Here is a D6 joint with linear displacements fully limited. The X axis (twisting in this configuration) is also fully limited, the Y axis is limited to -45 and +45, and the Z axis (which is the axis it is swiveling around), is not limited whatsoever. It's makes for a revolute joint with some play in the up and down (Y axis). Stiffness in the Y drive is keeping it from going limp/drooping down.

After a full revolution, the issue visible in the video emerges (which is most likely some kind of gimbal type problem happening to the articulation's internal record of current position). If the Y axis is also fully limited (making it approximate a revolute joint) then the issue goes away, but I suspect that the underlying cause still persists (possibly screwing with force calculations), but just can't show itself due to the soft/hard limits that keep the Y rotation happy.

I also tried reorienting the joint such that it's the Y axis doing the rotation, and the Z axis with some play, but it leads to identical results, which I think rules out a simple issue with internal XYZ ordering.

This might be an issue for the IsaacSim forums, but since I'm using the IsaacLab Articulation class (robot.set_joint_position_targets() ), I figured I'd post it here to see if anyone has an idea. (plus it's relevant to my above topic, so maybe this will be helpful for someone down the road).

Once I get a better and more fulsome hang of all my options for joint control, I'll post an update!

note: the fact that the limb does start to twist slightly in the X axis as it rotates (and gets worse the more it progresses through the swivel) probably points to the root cause...

note 2 (PARTIAL WORKAROUND): curiously, but not surprisingly, if I unconstrain the X axis (so only the up and down axis has limits in this case), and use an angular drive to hold the twisting axis steady at 0, then the problem goes away and it behaves like it should. I think this means that the way limits are tracked are somehow bugged.

EDIT: Seems like an IsaacSim native gimbal problem inside of the D6. Easy way to reproduce this is to make a D6 joint with constrained linear displacements, one partially constrained rotational axis (-45 and +45 range is sufficient to see the problem), and one fully unconstrained rotational axis. 1) set the unconstrained rotational axis to +179 degrees at play time. 2) set the partially constrained rotational drive to + or - 45). 3) set the (currently 179 degrees) unconstrained axis drive back to 0. 4) set the partially constrained drive back to 0 (so now all your drives are targeting 0 degrees) 5) see that your joint is NOT aligned how it should be (it will be twisted in the axis that is supposed to be fully constrained).

I'll make a post about this in the IsaacSim forums!

Screencast.from.2024-10-31.01-45-41.webm

[FlimFlamm]

Made a post about the above bug on the PhysX github, with simplified reproduction steps (it's definitely a gimbal style problem accumulating error in the joint limits). Hopefully they can address it because I love me my D6 TT

[FlimFlamm]

Went to check if the spherical joint had the same problems, but it seems like it's not even a drivable joint in IsaacSim... 🤔

Perhaps I'll just make everything out of prismatics and revolutes like most/all of the rigs I've seen (and maybe some fancier stuff with tendons?). Advice or clarification would be much appreciated!

[StrainFlow]

Revolute and Prismatic joints are the only two that can be vectorized and driven as part of an articulation, so for now they are the only joints that are supported. If you need to drive a higher DOF joint like a spherical bearing, you can either put two revolute joints on top of each other, or can tweak your kinematic geometry so that all spherical bearings are parallel and model each with a single revolute joint (this is what I do).

[FlimFlamm]

Revolute and Prismatic joints are the only two that can be vectorized and driven as part of an articulation, so for now they are the only joints that are supported. If you need to drive a higher DOF joint like a spherical bearing, you can either put two revolute joints on top of each other, or can tweak your kinematic geometry so that all spherical bearings are parallel and model each with a single revolute joint (this is what I do).

Thanks for pointing this out; I had assumed that all the joints on GPU would scale similarly well/were supported.

Stacking two revolute joints makes perfect sense, but I don't quite understand what you mean by parallelizing spherical bearings in a way that a single revolute joint could model each. Any chance you could elaborate?

[StrainFlow]

Yeah, take a look at this ackermann robot template:

https://cad.onshape.com/documents/836767cd08a2800e8a9d4cb0/w/91eb0ff38b3ab8b03ea0db77/e/1ac0a6f836294dbcaeeda21a?renderMode=0&uiState=6724ecef7b10297873e30092

It's a template you can make match a remote control car's suspension geometry. An instance modeled after a traxxas slash ultimate is available in the Isaac Sim robot assets. https://docs.omniverse.nvidia.com/isaacsim/latest/features/environment_setup/assets/usd_assets_robots.html

On real cars, the suspension arms on a given corner are not parallel and there is typically a spherical bearing between the arms and the wheel. This allows the wheel to move and twist as the suspension articulates, which can give favorable handling to the car. So, for those end points my choice when I built this template was either to stack two revolute joints or make the upper and lower arms parallel so that the spherical joint could be modeled as a revolute joint.

I find that the two stacked revolute joints can be a little jittery, fudging the suspension geometry so that the arms are parallel doesn't model the suspension geometry exactly. In this case I decided that fudging the suspension geometry was the better approximation.