Trying to connect an articulating body to a rigidbody with a fixed joint yield completely different results than connecting two rigid bodies.
The fixed joint only seem to be able to keep the distance properly, not the “tangental” position, in this direction there is a very springy force applied instead.
I created a test scene, in the video I have two large rigidbodies. Each large rigidbodies have two smaller boxes connected with fixed joints. The two small on the right are articulating bodies and the two on the left are rigid bodies.
As you can see the one the side on the right box wobbles up and down instead of being fixed.
jadedoblongblowfish
Tried on:
2021.2.0a19
2021.1.7f1
2020.3.0f1
2020.3.10f1
Created bug report case 1339597
Also tried switching to the Temporal Gauss Seidel solver. A bit snappier but still way more springier than Rigidbody-Rigidbody.
readydismalhackee
Hi, I’m facing this issue too in Unity2022.1.23. I’m trying to simulate the motion of a modular aquatic snake robot. With the ArticulationBody hierarchy everything works fine. Since the plug-in for the liquid simulation that will be introduced can only interface with Rigidbody components I tried to connect a RigidBody and an ArticulationBody with the fixed joint. Unfortunately this led to incredibily high values in the torques estimation through the ArticulationBody.GetDriveForces (I assume due to the small oscillations generated). Have you any idea of how to fix this inconvenient? Thank you very much
Nope sorry, I gave up on the whole articulating body
I have a Rigidbody parent connected to a child ArticulationBody (with its own ArticulationBody children) via a FixedJoint.
Both bodies have the same mass, and the same centerOfGravity.
(I’m doing this because I’m using some 3rd-party stuff that wants a Rigidbody in the root).
This seems to be working OK for me (my application is real-world vehicles), and my “hybrid” behaves similarly to the “pure” Rigidbody (except, if inertiaTensorRotation is non-zero, I’ve not figured out what’s going on there).
I’m still using Projected Gauss-Seidel (and timestep of 120Hz, with cranked solver & solver velocity iterations, but I don’t think you’ll need those).
Very late reply, sorry, I came across this thread when I was looking for something else:)