Featherstone's solver for articulations

I got the following setup, which is mostly working, but I have a question.

0 - root (not shown here, but everything sits on a larger hierarchy)
-1 - rev joint
--2 - prismatic, which drives everything
---3 - rev
----b1 - rev (back leg)
-----b2 - rev
----f1 - rev (front legs)
-----f2 - rev

There are two legs in the front and one in the back. The second front leg is not set up yet, but it is not important as the movement is only in one axis as you can see in the video and it's not relevant to the question anyway.
The legs have small cubes (blue) attached on f2 and b2, that are kept in place by the yellow cubes (attached to root). In this way I got them working ok-ish as supports. But I was wondering, if there is another way to do supports for an arrangement like this with articulation bodies or is just not possible? Because it doesn't seem right and it's also not unproblematic as the cube can just snap out when you put too much force on it too fast.
(I just realized that I probably could just use spheres instead of the cubes and the lower rev joints. It would be a bit like an actual bearing even in this case.)

 

GetJointPositions, SetDriveTargets, and GetDriveTargets...
are they using values in degrees or radians? the documentation is unspecific.
I'd really like them to be degrees, same as the joint upper and lower limits.

 

this sounds great, do you know which Unity versions this will be integrated to? Only latest 2023.1 alpha, or also older versions?

 

I can confirm demand but I know Unity was very strict about backporting. Would be cool if possible.

 

Is it possible to simulate force torque sensors for each joint in an articulation chain that react to external collisions? Haven't found a solution yet.

 

Is there a tutorial for this anywhere? I'm trying to get UltraLeap ir 170 to work with XR interactions and the interaction toolkit but the Interaction Behavior makes objects disappear. If full physics hands with articulation bodies can be done I have made a lot of VR projects but I'm still having issues with leap, still I would love to test this out if there is a demo or tutorial on how to set it up.

Thanks.

 

https://docs.ultraleap.com/ultralab/physicshands-preview-blogpost.html

 

Hi,
We are using the reduced coordinate pipeline with very good results so far for our game Plasma ( https://store.steampowered.com/app/1409160 )
The main drawback is not being able to use cylinders (ex: wheels), we have tried with different tessellation count (32, 64,128 edges etc.) but the main problem across the board is hard bounces when edges hit which causes plenty of jittering.
I came across this thread on the PhysX github https://github.com/NVIDIAGameWorks/PhysX/issues/50 where they talk about using 'rest offset' parameters to smooth the edges a bit, although I'm pretty sure this is something that isn't exposed on the Unity side.
Would it be possible to consider adding this feature so we can have smooth cylinders when using articulations?
Thanks!
Patrick

 

Thanks Anthony, I'll look forward to the native cylinder implementation with patience

 

Hi,
I would also like to support the request for exposing the 'rest offset' parameter on colliders.
Over the years, I've seen numerous threads on these forums asking for help related to bodies hitting collider seams when sliding (some recent examples: 1, 2, 3, 4).

From PhysX documentation and developer comments, it seems like one of the simplest way to mitigate the issue is to increase the 'rest offset' for the participating colliders.

https://gameworksdocs.nvidia.com/Ph...xguide/Manual/AdvancedCollisionDetection.html

https://github.com/NVIDIAGameWorks/PhysX/issues/50

https://gameworksdocs.nvidia.com/Ph...xShape.html#a413afb25b39a7a0cf0981aa01c6d7f8b

I have created a simple scene to test the effect of the rest offset setting on another engine, and recorded the results in the PhysX Visual Debugger.

In the video, both yellow ramps are made from a number of same-sized cubes placed next to each other.
The cubes making up the ramp that is further away from the camera have a 'rest offset' setting of zero, while
the ones making up ramp that is closest have 'rest offset' that is larger than zero.
The sliding green cubes hit every seam between colliders in the first ramp, but slide smoothly on the closest one with the non-zero rest offset.

 

Thanks for all the hard work and ongoing support of the articulation pipeline.
I was also hoping there are plans to implement adding a 'soft' constrain in an articulation to form loops, I understand this is something PhysX supports (of course that joint isn't accurate like the rest of the articulation links) but not implemented Unity side yet.
The articulation approach is awesome for so many reasons, but the lack of being able to make loops can be a real killer for gameplay in a physics sandbox (from the point of view of the player that is).
Here's hoping this is on the radar.
Thanks,
Patrick

 

Hi Augustinas,

Would you be able to provide an update on the increase to 256 links limit in a tree?
It doesn't seem to be in the release notes for 2013.1a yet, and we would LOVE to have it backported to 2022.2b so that we can use it in our upcoming game without the inherent risk of using an alpha release of Unity.

Thanks,
Patrick

 

Well that's great news! We would LOVE to see this backported to 2022.2, I'll cross my fingers and hold my breath until we find out!

 

Awesome! Thanks for letting us know, is there a planned release date for 2022.2.2f1?

 

Still no plans for interpolation? I don't really want to run all of the physics faster just to have smooth movement of articulations in certain cases.

 

+1 for interpolation. This is very much needed to use Articulation Bodies in game context.

 

The initial mass isn't respected if there isn't a collider present, it will behave as if it has a mass of 1... though if you change the mass at runtime, the new mass will be used.

 

I'm not sure if this is only relevant to Articulations, but there seems to have been a change made to how linear damping is applied.
In the two GIFs below, the top Cube has linear damping value of 2, the bottom has the default value of 0.05.
Both cubes have a slight impulse added to them for a frame and have no gravity applied.
The top GIF is from Unity 2021.3, the bottom GIF is the behavior seen from 2022.1 and forwards.
Is this a known/intentional change? I couldn't find any information anywhere about it.
Thanks,
Patrick

 

It might be due to the Unity 2022 being the most bugged Unity of all times. Pro tip : don't use it.

 

Looks like a bug to me. I'd recommend you to file a bug report that repro scene.

 

I just encountered this misbehaviour (2021.3.18f1). It seems the damping value is randomly not initalized correctly. When changing the value from the inspector (at runtime), to some other value and back to the initial value, it behaves as expected.

 

I currently use a workaround, so (i have to be honest that) i'll probably forget to report it as i have too much else to do, sorry. But, the workaround is to also just set linear/angular damping, joint friction and mass to some slightly different values and back in Start() or Awake().

 

Is there a working solution for disabling an articulation hierarchy? I've tried various combinations of zero'ing out velocities, disabling/enabling the AB Component none of which seem to work in a stable manner.

I basically have an articulation hierarchy which gets pulled around by a Rigidbody via configurable joint.

For performance, I need to disable the entire AB hierarchy and re-enable it at a later time. When I do this, I'm attempting to use TeleportRoot on the AB root to move it back into a valid position, and then re-create the configurable joint.

However the root AB always ends up in the right place but with an incorrect orientation. If I repeat these steps at runtime (Disable/Enable repeat), the orientation continues to diverge and visually the root AB appears to have an increasing rotation, even though in the TeleportRoot call, I'm passing the same/fixed rotation.

 

That's.. partially correct yeah. The hieararchy looks like:
-Empty Wrapper
-- Rigidbody (Configurable Joint on this game object, targeting the sibling root AB)
-- ArticulationRoot
--- ArticulationChild1
---- More AB Children
--- ArticullationChild2
---- More AB Children

If the case the above is unclear, the Rigidbody and the root ArticulationBody are siblings under the same empty game object. But outside of that they arn't connected in any way and the empty wrapper above them isn't used or moved.

Yep, I'm currently in the process of testing this on a scaled down easy to repro test case. Will open a bug once I can confirm its occurring in this test case.

 

I’ve been having a similar problem.
I'm using a FixedJoint, not ConfigurableJoint, and I'm seeing translational offsets, not rotations, but it's otherwise similar.
I’m sitting on a minimal repro project, but haven't contacted anyone yet as I'm not yet sure it isn't me doing something silly
I found (but am in the process of properly confirming) that adding a collider (box collider in my case, will try convex mesh later) to the root articulation made everything behave properly when I disabled and enabled the root container object.
May be related to https://issuetracker.unity3d.com/is...s-behavior-after-attaching-a-trigger-collider
(Although adding a *trigger* didn't help with my enable/disable problem: it seems to want a proper collider)
(I already had a box collider that the Rigidbody was "using", it seemed like I needed to add another to the articulation root to make it behave)

In my Googling I've come across a couple of links, but I've not got anything working yet (since I discovered this collider thing just now)
http://anja-haumann.de/unity-preserve-articulation-body-state/
https://forum.unity.com/threads/how...ble-articulation-chains.1184662/#post-7582714

 

Hey all! I've only just started looking at this stuff. Is there a way to enable interpolation on Articulations like with Rigidbodies? I'm on 2021.3.23. I have an articulation chain connected to a rigidbody with a FixedJoint and while the physical behaviour is exactly as wanted, the meshes attached on the articulations jitter around, since our physics step and frame rate don't match, and we're moving at considerable speed.
I guess I could at some point try stepping physics at a variable rate to eventually land on synced transforms, but I'm rather hesitant to try that as a solution to an otherwise working scenario.

 

We've been doing manual interpolation like this in our game for a while, seems to work OK (Rigidbody connected via FixedJoint to articulation hierarchy too!)
@Augustinas-Simkus would you consider sharing your script? I'd share mine, but I kindof quickly threw it together and it's at the point where "it looks like it works, probably" I get that yours is a quick experiment too, but I think PhysX is your specialty, whereas I kindof do a bit of everything, never quite convinced that I know what I'm doing

 

Right, well I don't know why I didn't even consider that. Will try this next week.

 

Hi,

Should ArticulationBody.index change when you disable and then enable the root parent GameObject?
I don't see anything in the documentation about how index is determined (or if it's deterministic, or kindof arbitrary)?

In the attached project (2021.3.5f1 LTS, Windows 11):
I set up a simple hierarchy in the editor (body index seems to get assigned kindof arbitrarily depending on the order I add stuff);
You can see the body indicies in the editor before running;
There's a simple script that logs the indicies: this matches the editor values in first OnEnable;
The script disables and re-enables the hierarchy every 2s;
OnDisable logs all indicies as -1 (fine, I guess);
Next OnEnable has different indicies logged (and these different values are shown in the editor);
Subsequent disable/enable cycles preserve these different indicies.

GetDofStartIndices also returns a different array after the first enable/disable; but, the index it's giving me into JointPositions (etc) is different to the one it gave on startup.
What I'm trying to do is cache the joint positions in FixedUpdate, and then restore them in OnEnable (similar to this http://anja-haumann.de/unity-preserve-articulation-body-state/): but I can't do that if the indicies change between FixedUpdate -> OnDisable -> OnEnable?
Now that I understand what's going on, I can workaround, but I thought I should ask if it's intended behaviour (or, if I'm misunderstanding something

It'd be *really nice* if you could just disable/enable the GameObject, and it'd correctly pick up it's previous configuration (joint positions, velocities, everything), rather than zeroing/rebuilding

I'm getting analogous behaviour in my main project, where I add the articulations from code in the first run of OnEnable.

Same behaviour in Unity 2022.2.16f1, 2023.1.0.b13, 2023.2.0a11

 

Hello, I am working on a project using the Articulation Drive in prismatic and revolute joints. I have used the URDF importer to import a robot (3DOF, 1 prismatic along the x axis and 2 revolute joints rotating about the y axis with an offset from each other). When using position only control (where damping is 0), the joints behave as expected, except for the 2nd joint, where it deviates from the desired position by about 8%. When I have tried to implement velocity and position based control (damping is 1/4th of the stiffness value) with the intention to reduce instantaneous accelerations, this 2nd joint only behaves worse. Furthermore, I have found that the values of joint.jointPosition and joint.jointVelocity don't match as expected.

What I mean by this is that if I read out the position at each time step and compare it with the velocity from each time step, it does not match. These discrepancies can be seen in the images attached. Examples include:

1. A positive velocity over a number of seconds leads to a negative position (but not always! and only seen in joint 2, where the value of the velocity * delta time != position)
2. Joint 2 also appears to require a constant non-zero velocity in order to maintain a constant non-zero position
3. A certain magnitude of velocity over a certain period of time results in the expected position change in joint 1. However, when parasitic movement of joint 1 is seen when moving joint 3, the same magnitude of velocity over the same amount of time results in a tiny fraction of the original movement of joint 1.

Are there any known issues that may be causing this? Or ideas what to look at to fix this? I have also tested this with a 7DOF all revolute joint robot, and I had no issues there. Position based control had no significant issues. Velocity/position based control with damping at 1/4th of the stiffness value worked as expected as well, so I am at a loss on what the difference and the issue is with the 3DOF robot. I appreciate any and all insight on this.

 

Hey guys, I was wondering if anyone has encountered a similar issue with ArticulationBodies twitching.

Some context: I have an active ragdoll character using ABs as character joints. It's built using two skeletons, an underlying and hidden animated/ik skeleton upon which animations are played. And the visible skeleton which has the Articulation Bodies. The animated bone rotations from skeleton 1 are passed to the matching AB's on skeleton 2 as reduced space joint targets.
This has all worked flawlessly for me so far, for all types of animation including locomotion (the most troublesome in this situation in my opinion). I've also had no trouble using Unity's AnimationRigging (IK solution) on the underlying skeleton and the AB skeleton following along just fine.

I recently grabbed the FinalIK product from the asset store and gave their FullBodyBipedIK component a go. It works as advertised on the underlying animated skeleton, no issues what so ever as seen in this gif: https://imgur.com/a/APUfoWq (if it seems choppy, its because I was manipulating the Y position of the target sphere in the inspector).

With the above situation, the AB skeleton has odd twitching/oscillating between extreme rotational values on certain axis and on random joints. See gif: https://imgur.com/a/22AkHyq

Some things worth mentioning, this components IK Solver is processed in LateUpdate and I don't believe it would work anywhere else. That being said, I wouldnt expect that to affect the AB's.

I've tried a few random tweaks and adjustments to see if I could remedy or even minimize the issue such as adjusting the physics timestep, changing the ArticulationBody settings for the bodies that are twitching. I've also tried freeing up connected Ab's and their settings but nothing seems to remedy this. And I'm not too surprised by that because this setup works for everything else and is very stable atm.

Here is a gif of the thigh ArticulationBody component during twitching: https://imgur.com/a/RILEjKr You can see the rotational target for both drives jumping. The rotational values for the matching bone on the animated skeleton are not jumping at all. So my first assumption was that my method for calculating the joint targets was wrong but then it works for normal animations and everything else which leaves me stumped. I mean its also working for half of the 'twitch' if that makes sense.

 

Hello! I am working on a project that involves a chain of articulation bodies. A few of them have revolute joints and the rest are fixed. the root of the articulation chain is suspended from above and the end of it is supposed to drag on the floor. I need to get the contact force and friction between the ending link of the articulation chain and the floor.

However, the contact force I got using contact.Impulse is a few times larger than what I expected from my physics calculation. And interestingly, when I manually uncheck and check "use gravity" in each of the ArticulationBodies, the contact force gradually decreases back to the value I expect. Most of the intermediate ArticulationBodies have a mass of 10e-7, and I realized that toggling the gravity of links further from the pivot point (suspension point) decreases the contact force by a larger amount.

I have experimented slightly more and found out that from the inspector, toggling the ArticulationBody component, or setting the mass to an arbitrarily large value and then setting it back will also decrease the contact force back to normal. However, doing the same thing automatically in a script does not work.

I find this issue really bizarre and suspect that it might be a bug. Does anyone have any suggestions on where I should look into? Or any other possible ways to bypass this? Thank you!