Featherstone's solver for articulations

Hey!
Do you mean an absolutely separated gameObject with Rigidbody parented in world? I will try it now. Thanks!

UP
It seems to work! Thank you so much for quick reply!

 

That is clearly because you are getting inverse collisions. That would happen most likely with normal colliders and joints as well.

 

@yant Can maxLinearVelocity and maxAngularVelocity be used to limit the velocity from the force of a drive on a prismative/revolute joint? I've tried setting them to a low value but they have no effects. (I can provide a test project and submit a bug if needed).

I'm directly setting the target values on the ArticulationBodies but they are moving too fast and I would like to limit the speed. Is it ok to set the target values of the drives directly or should I be interpolating to the desired target during FixedUpdate?

 

I'm also interested in this! So far I've successfully limited just the root of articulation body by setting these properties. Looks like they have no effect on the rest of the art bodies in the chain.

 

@yant We will appreciate it if you elaborate more on the status of the inverse dynamic.

In the 2021.2.0b, I saw the jacobian matrix is now available; I have tested it, but still, it doesn't have any elements, and the force vector is zero. Do you have any specific roadmap on this important feature?

We are working on a research project related to Unity3d and robotics, and this is one of the crucial requirements for our research. We are eager to evaluate robotic reinforcement learning in Unity3d. As we have a Force/Torque sensor on the robot wrist, we should be able to get this simulated force/torque information from the physics.

Although there are other available options like bullet, Mujoco, etc., for Unity3d, we really can't switch the whole project to the other engines. We are eager to stick to Nvidia PhysX because we also used Flex for non-rigid object manipulation.

This is our current development with the Kinova Movo platform: https://github.com/cxdcxd/RRS.

 

Well let me get the ball rolling... How can I apply Inverse Dynamics to game scenarios? what are the benefits over classic ragdolls and the likes we have now - and what are your initial plans? Thanks

 

Hi there,

For some reason, when I dynamically add a child articulationBody to an existing articulation hierarchy at runtime, all the articulation bodies in the whole hierarchy get reset (their orientation reverts instantly back to the original state).. is this an expected behavior?

Example, Imaging a door with articulation body that rotates 90 degrees. if you open that door then attach any articulation body as a child it will instantly close again..

Same thing happens when I change the joint type of any of the child articulations e.g. fixed to revolute. (but I'm more concerned with adding dynamic children)

Please help

 

@JuozasK Thanks for the reply.

Then from what you have mentioned, can we expect it this year?

I have also found an alternative solution to this, an unofficial preview plugin for PhysX 4.1 from Nivida. You can find it from this thread. I tested it, and all low-level functions are there.

One question is, how can we connect this low-level, let's say, pure programming solution with Unity3D's current physics. For example, I mean a unity3d rigid body cube can collide with an articulation body in this plugin. From what I saw, there is no UI connection even to rotate or translate the objects created on the programming side, and it's like two different worlds.

I am sure it should be a way for it, like not to render anything from this plugin and have another render loop to only update a current unity object with the position and orientation of the calculated object on the programming side.

We really need the Force/ Torque sensor information in our research project, and I will appreciate it if you guide me through any hacks or alternative directions to get it even before the unity3d's official support.

The target use case for sure is Robotics. My main concern is now by having Omnivers from Nvidia robotic; people tend to use it rather than Uniy3d. For sure, we are expecting the robotic Gym support in Unit3d as well, and with ML-agent, it has a huge potential to have everything in one platform. One other nice integration also is to support Nvidia Flex natively.

 

I have been trying to use articulating bodies to attach robot arms to a moving vehicle but it is not possible for me at the moment due to two bugs.
My first attempt was to keep the vehicle a rigidbody and use a fixed joint to attach the arm, but the fixed joint doesn't work. I created a bug report a while ago (case 1339597) about it. The example project i included did not really show how bad the problem is. This is what happens for me in my project:
The two cylinders are articualting bodies connected to the ship (rigid body), one with a fixed joint, the other with a configurable joint with all motions set to fixed (same result)

So my other attempt was to change my vehicle to be an articulating body instead. The arm stays in place then but then an other bug appeared that makes articulating bodies unusable for me.
Calling AddForce or AddForceAtPosition more than once on an articulating body within the same fixed update overwrites the previous force.
So for example calling these two lines in fixed update (can be different files)
body.AddForce(Vector3.up, ForceMode.Impulse);
body.AddForce(0.001f*Vector3.up, ForceMode.Impulse);
Only the 0.001f force will be applied.
I created a bug report for this (case 1349587)

I also have a question about the indented behavior of setting the velocity and/or angular velocity of an articulating body directly.
With a chain of rigidbodies connected with hinge joints it is possible to set the velocity of any of the bodies in the chain and all bodies will react accordingly. (For example if a body in the middle gets a velocity perpendicular to the chain length, the chain will "bend", pulling the edges towards the middle)
However with a chain of articulating bodies two things can happen. If the velocity is set to the root the whole chain will get the velocity. If the velocity is set to any of the children nothing happens.

 

Here's a video for the bug I mentioned above. All articulations in the hierarchy reset to the original orientation then quickly move back to the correct orientation when adding a new articulation body child.

 

@JuozasK My simulation requires attaching arms at runtime to the articulation tree. Someone gave me a workaround for it by saving joint position before attaching and reverting them after attaching, which works great.

The new issue I'm seeing now, is if the dynamically attached arm has limits that are equal (e.g. lowerBound == upperBound) the whole articulation tree explodes and keeps rotating around itself.. I was using limits to be able to dynamically freeze and adjust the the constraints at runtime, but it's not working as I expected, is this a known issue? looks like the arm is producing a huge torque and trying to catch its own tail.

 

I think I found the issue, it was in the way I was calculating the rotation delta in the code, I think articulation bodies don't take -ve angles.

Thanks

 

Hello,

For some reason when trying to disconnect a joint from an articulationBody temporarily by setting connectedArticulationBody to null, I get this error "A joint can't connect the body to itself."

And I noticed while debugging that after executing this line, the connectedArticulationBody still has the same value, even after yield return new WaitForEndOfFrame().

Am I doing something wrong?

 

I'll abstract the repro in a small project this weekend and send it. but for context the reason I'm doing this set to null then back to the original object is a workaround for what I believe is a bug. basically if you have a Joint connected to an ArticulationBody "body1", then at runtime you set parent of this "body1" to be "body2", the Joint holding body1 will not be functional anymore, and you need to set the connected body to null and set it again, or recreate the whole joint again.

 

I cant get Physics.IgnoreCollision to work propertly - its almost as if I have to wait till physics step updates. I have script disables collsion OnCollisionStay as I cant do it from Start - which is what I want todo.

Using Unity 2021.1.11f1 (64-bit)

If I disable the capsule collider I get the desired joint behaviour.

Is it possible that because I have 2 capsule components(on the same transform) slightly overlapping the joint with just one capsule collider ?

Edit

I updated to Unity 2021.1.16f1 (64-bit) // this change dident matter.
removing one of the multi colliders from the joint and now everything works.

Is this intended ? Can articulate bodies not function correctly if joints that have overlapping
colliders - where one of the joints have multiple colliders on it ?

 

Initial post
Any news when this bug will be fixed. Tried the latest 2020.3.x and 2121.1.x unity version, the bug is still there!

 

No, I haven't repotted this issue.

 

I'm training a model using ml-agents to imitate reference motion using the ArticulationBody components and I found that the ArticulationBody component is somehow making force against gravity. I'm only setting drive targets of some spherical joints and revolute joints and I don't understand that this is possible. AFAIK, the drive targets are making only drive torques and it should not make any force against gravity. Can anybody guess what did I wrong?

 

Hi, Have you found the solution?

 

Hi,

Thanks for exposing ArticulationBodies - I've been using to great effect in my robot building game!

One issue I'm having is that child ArticulationBodies don't collide with their parents. Is there (or will there be) a way to enable these kinds of self-collisions, similar Joint.enableCollision? At the moment I have to create an intermediate fixed ArticulationBody with no colliders to get the collisions I'm after.

 

Sorry for the late reply. Unfortunately not. In some cases we are using BioIK, in other cases we get our joint values over network from a remote custom IK. Still very interested in using those articulations.

 

I have a similar problem to yours. The good news is I know exactly where that minimum limit is. The bad news is ... well its hard-coded in PhysX 4.1.

Specifically here: https://github.com/NVIDIAGameWorks/...ics/src/DyFeatherstoneForwardDynamic.cpp#L149

See that commented out /*PX_EPS_REAL*/? Changing 1e-5f to PX_EPS_REAL fixes this issue. But I do not know the consequences of doing that.

@yant I added an issue to NVIDIA's PhysX 4.1 repo hoping to get some insights from their engineers to why there is that arbitrary limit here: https://github.com/NVIDIAGameWorks/PhysX/issues/484 I would REALLY REALLY REALLY appreciate it if that fix is applied and back-ported! (Case id: 1372972)

I know this fix works because I'm currently using PhysX via the plugin in this thread: https://forum.unity.com/threads/nvidia-physx-plugin-preview.645004/page-3#post-7398107 and I compiled my own fork of PhysX with the fix.

I the meantime, I would advise changing the revolute joint to a spherical one with the other two axes locked, since that limit does not apply to spherical joints.

 

That is great news! Thank you! 2020.3 LTS would be perfect.

 

I just tried out 2021.2.0b15 and joints seem to be working as expected now. Thank you!

One bit of feedback: This should be documented. If you go unreasonably low in mass/inertia it still hits the new limit.

 

This explains a lot of discrepancies I've been experiencing. Thank you. Is there an ETA for when the backports land?

And more importantly, would multiplying force limits by dt (Time.fixedDetlaTime) make sense as a temporary fix?

Oh I just got what you meant. You're suggesting the temporary fix to convert the force limits into actual force limits.

 

Is there a specific reason why the drive values are not editable in a Prefab? They seem to update between instances in the hierarchy when I change a value and apply. So it must be saved in the Prefab at least.
I also had some buggy behaviour with anchor points and Prefabs or didn't fully understand what was happening, but haven't done more investigations there.

 

ooh, my bad. Now I noticed/realized that the child articulation body becomes a root if you only make the child into a prefab. I guess, that makes sense. Of course, you don't have any drives anymore, if it's the root. Interesting though that it still keeps the values of the drive.
This might also be related to my small issue with the anchor points then. However, for the moment it's working. So I won't bother looking at it until next time I have to edit it.

I don't see anything yet on the issue tracker.

Thanks for your help!

 

Hello!

I have a robot arm that is attached to an end (the shoulder), can attach its other end (the wrist) somewhere else, and then detach the original point so that the wrist becomes the shoulder. This allow the arm to travel from anchor to anchor. FYI this is how the new generation of real robot arms work in space stations.

Due to the top-bottom organisation of the articulation bodies, the fact that this whole hierarchy reset upon any change, and the root of the hierarchy being the only possible immovable body, it seems hard to implement this.

Can you think of any reliable solution?

 

Thanks for your answer.

I've already implemented the suggestion from @MKaramDev to retrieve the pose of the joints after a change in hierarchy like this:

Code (CSharp):

1. // we save the joints poses before changing the hierarchy
2. foreach (var ab in GetComponentsInChildren<ArticulationBody>()) {
3.     jointStates.Add(ab.jointPosition);
4. }
5.  
6. // change the joint hierarchy
7. // for example jointToAttach.transform.parent = tipJoint.transform;
8.  
9. // we apply the saved joint poses back
10. int i = 0;
11. foreach (var ab in GetComponentsInChildren<ArticulationBody>()) {
12.     if (i >= jointStates.Count) continue;
13.     ab.jointPosition = jointStates[i];
14.     i++;
15. }
16.  

The "jointPosition" field seems to be accessible only for this purpose because none of its members is accessible. Nonetheless, this feels like a hack and it is not mentioned in the doc AFAIK. I believe that there could be a boolean "resetOnHierarchyChange" defaulted to true, that one could set to false to prevent the joint from reseting when the hierarchy changes (or a method ResetHierarchy() that one could manually call when they change the hierarchy and want it to be safe, limit wise).

Also, out of curiosity, how is it possible that it occurs immediately? The ArticulationBody somehow reacts to the transform.parent change, like it is listening to an event from Transform (my first naive attempt was to set the saved positions back in the next FixedUpdate ^^). I don't see any reason why not, except that things usually don't work like this in Unity or ECS in general, but I was wondering if it was possible to do the same in our scripts.

My concerns about the arm being inverted is that I'm relying on the immovable field, that can only be changed for the root of the hierarchy. I must say that I haven't done much digging on the subject yet so I will post my progress here if you are interested.

 

Are there any plans to improve the prefab mode of articulation bodies? Sometimes I make only a piece of a larger hierarchy to a prefab and when I want to edit it in isolation/context then the root is missing and the bodies in the prefab become a root. Then I can't edit values like the targets anymore. It's not extremely important to me. But it would be a nice to have

 

Maybe it was a bit unclear. This is what I mean:
GameObject1 has the root articulation body. GameObject2 has some articulation joint on it.
Make GO2 a prefab and look at it in isolation. It shows the articulation as root.


Of course, whether the prefab is part of a hierarchy is not known beforehand. But maybe you could put something like a virtual root, when it's meant to have one, or if it's in context viewing mode, it could even use the actual parent maybe?
After all, even if it doesn't show the joint values, it still stores them.