Replies: 3 comments 2 replies
-
Thank you for the detailed report and snippet! We will have a look. Internal Tracking: PX-4649 |
Beta Was this translation helpful? Give feedback.
-
I see the issue but I don't see the solution yet. We need a ground truth source for computing the geometric error, so we cannot use the world-space rotations like the solver does, since they would include the error we wish to correct. A potential workaround would be to omit the setHinges call:
This is only used to compute & update the geometric error. If you omit that call the gear joints still work, but they never try to correct potential drift (which means the gear teeth can start overlapping after errors accumulate). If you omit that call in your snippet, I think you get the behavior you expect. Another thing: I am not sure why you create another joint here:
You could just add the drive to the already existing pJointB1 joint:
(same for motor/pJointB) It does not change anything but I got confused by this setup. I did not try planetary gears but I can see why the issue you pointed out could make them difficult to achieve. I think we'll need more time to come up with a good solution to this issue. |
Beta Was this translation helpful? Give feedback.
-
Closing for now, please reopen if there is more to discuss. |
Beta Was this translation helpful? Give feedback.
-
In gear constraint, I believe that from line 269 to line 270 constraints the absolute velocities (or global velocities) of two rigid bodies. (https://github.com/NVIDIA-Omniverse/PhysX/blob/main/physx/source/physxextensions/src/ExtGearJoint.cpp#L269-L270).
But when I continue to look at the logic of calculating
con.geometricError
in the functionGearJoint::updateError()
, then jump to line 156(https://github.com/NVIDIA-Omniverse/PhysX/blob/main/physx/source/physxextensions/src/ExtGearJoint.cpp#L156), I found that it obtains the angle from the relative position relationship of the joints.This means that for the two joints that make up a gear, if the other rigid, which does not belong to the gear, of the joint is also moving, then the calculation of the above geometric error is incorrect.
To illustrate this problem more specifically, I have provided a snippet of code.
In this snippet, dynamicA and dynamicB make up a gear. DynamicB is rotation around dynamicB1, while dynamicB1 is also rotating.
I believe that under this gear constraint, dynamicA should not rotate, but in the simulation, it does rotate.
Also, I wonder if future versions will support planetary gears? It seems impossible to design a constraint for a planetary gear using the existing gear constraints.
Thanks!
Library and Version
PhysX v5.3.0
Code Snippet
Beta Was this translation helpful? Give feedback.
All reactions