Articulation type "Maximal coordinate articulation "

[mlp1802]

In PhysX 5 I could not find any documentation for this. Has it been taken out?

[preist-nvidia]

Correct, maximal coordinate articulations have been removed: https://github.com/NVIDIA-Omniverse/PhysX/blob/release/104.1/physx/CHANGELOG.md#removed-4

[mlp1802]

Ok thanks is there a specific reason for this? In our game we use spring/damper and a quat orientation to drive the articulation towards global targets, that functionality is absent in the min coordinate articulation it seems..is it possible to achieve that in some other way?

[preist-nvidia]

Sorry I am not very familiar with the max. coordinate articulations. But if I understand correctly, you can attach a D6 joint with drives to the reduced-coordinate link and use it to drive the articulation link toward a goal orientation.

[mlp1802]

That doesn't sound like a very good solution.
Changelog says:

The maximal coordinate articulations have been removed with the equivalent functionality exposed through the newer reduced coordinate articulations.

A bit misleading since the equivalent functionality is not available in the reduced coordinate articulation. The upgrade guide mentions nothing on articulations as well. Some explanation on this is needed, I can't be the only one with this problem.

[preist-nvidia]

Can you please be a bit more specific about how you were driving articulations towards global targets before / what you are trying to achieve?

[mlp1802]

On the joints yo can set a target orientation along with spring damper. That orientation is local, but converted to a global orientation I can make my character reach for things in the world, point in global directions etc.

[preist-nvidia]

Right, got it - you should be able to use the PxArticulationReducedCoordinate::packJointData (see here) to convert to reduced coordinates.

The reduced-coordinate articulation joint drives provide spring-damper drives as well.

Let me know if this helps, and if you run into issues. I agree this should have made it into the migration guide, I will add a ticket for this.

[mlp1802]

Thanks, but I'm not sure what that means, I saw a conversion from real to real in that snippet. The orientation I'm talking about is a quaternion.
EDIT sorry if I wasn't clear about that: the drive is using a quaternion.

[preist-nvidia]

Ok, this will work:

1. Setup the articulation with a spherical joint with three dofs, and a joint drive for each dof
2. Make sure the quat represents the shortest rotation and is in the parent joint frame
3. Convert it to a rotation vector
4. Set the dof targets of the spherical joint drive to the rotation vector elements

[mlp1802]

Ok, this will work:

1. Setup the articulation with a spherical joint with three dofs, and a joint drive for each dof
2. Make sure the quat represents the shortest rotation and is in the parent joint frame
3. Convert it to a rotation vector
4. Set the dof targets of the spherical joint drive to the rotation vector elements

That sounds like it would work, for sure. Thanks for your help!

[mlp1802]

In what way are min coordinates articulation better than max coord? the 4.x documentation has some abstract explantions, but what is the layman version?

[mlp1802]

Ok did the conversion (but the app can now run in both modes, so if all fails, it can still run using the Max Coordinate articulation). This somewhat works, but in many cases not, with no clear reason why. I assume gimbal lock, and a lot of information is lost when you convert a full 3D orientation to 3 numbers. The documentation states that in case of a spherical joint, quaternions are used internally to drive the joint anyway, so is there any good reason why a method like setTarget(quat) is not available? Perhaps there is a real good reason, but I couldn't find anything mentioning it. I kind of build the entire application using quaternions and can absolutely not do without..is the alternative perhaps inverse kinematics?

[preist-nvidia]

Hi @mlp1802 - but the approach above with converting a quat to a rotation vector should work with quats directly. How does it fail? If you can repro a failure reliably, we can analyze it.

I agree that we could consider adding a quat->spherical joint drive target helper following the rotation vector approach.

[mlp1802]

Hi @mlp1802 - but the approach above with converting a quat to a rotation vector should work with quats directly. How does it fail? If you can repro a failure reliably, we can analyze it.

I agree that we could consider adding a quat->spherical joint drive target helper following the rotation vector approach.

It fails in the way that the pose of the articulation is different from what it is in the Max Coord version. Sometimes they are identical, sometimes completely different.

So it works for some poses, for others not. I follow the same euler angle decompesiton order as when the Quat was created..in general I just think it's not possible to accurately describe a 3d rotation with only 3 numbers..why would we have 3d matrices and quats if that was possible? there's workarounds, I would have to remake the poses in some way, but I want to keep the max coord version until I know there's a real benefit using reduced coordinates, meaning I would have to maintain two sets of poses (and there are close to a hundred now, and many blend with others, using quaternion operations and other math operations..not easy to do that with euler angles) I will give it another go later and post the result here. If you could include the target quat function that would just be awesome though!

[preist-nvidia]

Wait, you should not decompose the quat into euler angles but a rotation vector. You can follow this recipe, and make sure you use the shortest rotation before conversion: https://www.mathworks.com/help/fusion/ref/quaternion.rotvec.html

[mlp1802]

Wait, you should not decompose the quat into euler angles but a rotation vector. You can follow this recipe, and make sure you use the shortest rotation before conversion: https://www.mathworks.com/help/fusion/ref/quaternion.rotvec.html

Ah ok thanks!. I've never heard about this operation before..I will try it and post the result here.

[mlp1802]

It's the same result..I suspect that method does the same as my euler angle method. But the problems are minor somehow. It's only the arms_1 joint that causes problems, from what I can see so far, so I guess I can get that working somehow. You can see the result below, first picture is max coord, second is reduced coord.
It seems to me that the joint is "born" with the axes pointing in different direction than the max coordinate joint.

[mlp1802]

SOLVED! Looking at the two pictures side by side it struck me that the problem could be with the forearms instead, which are revolute joints. I used Swing2 as axis for the revolute joint when it should have been Swing1 (any reason why these axes cannot be called X,Y,Z?). So it's solved, for now at least. Thank you for your help and patience!

[preist-nvidia]

Yay, glad you found the issue!

(any reason why these axes cannot be called X,Y,Z?)

Yes I would prefer that as well but we can't really change this at this point.