Configurable Joint Target Velocity

I have a very simple air cylinder made of two objects: cylinder body, cylinder rod.

I have a Configurable Joint component on the body. Connected body is the rod. Z Axis is the direction of actuation. I have X & Y motion locked, Z motion limited (limit is the cylinder stroke), all angular motion locked.

I have Z Drive set to velocity mode, position spring and damper set to 0, max force at maximum.

I believe I am supposed to be able to change 'Target Velocity' Z component and watch the rod extend or retract, but it does nothing. Changing target velocity values results in zero motion. If I set position spring or damper to something other than 0, then target velocity makes the rod move. But, the documentation says spring and damper are only used in position mode... It is not behaving like I want, and I don't think it is behaving as the developers intended.

Am I doing something wrong, or is there a bug in PhysX?

Thanks

 

Is the system completely at rest when the simulation starts? I've had trouble with bodies that were sleeping, and where applying motor force wouldn't wake them up. Using body.WakeUp() regulary solved that for me.

I am also still confused as to when the various spring and dampening parameters are used, as it does seem to be different from Unity 4.

 

The items move due to gravity when the simulation starts, so I don't think they should be asleep. I'm not able to test it right now but I will try WakeUp() when I get a chance.

Thanks

 

I just re-created my scene in Unity 3.5.7 and it works as expected. There is definitely an issue with the Configurable Joint in Unity 5.

 

Yep, I'm also seeing this bug in Unity 5 (including 5.1, just tested today). Velocity drives (i.e. x / y / z drive set to mode "velocity") don't work at all for me. In Unity 4.X they work fine. I submitted a bug for this a while ago (http://fogbugz.unity3d.com/default.asp?684298_r56ma0u8rclrvqnm), but no response so far.

If anyone discovers a workaround for this I'd love to know, but I suspect it's a case of waiting and hoping they fix it eventually. One of the last remaining issues holding me back from a Unity 5 upgrade...

 

Not to revive a thread from the grave, but I just spent the better part of a day trying to get a target velocity working on a configurable drive, and this thread popped up many times in my searching. I finally found this:
https://issuetracker.unity3d.com/is...-object-unless-position-damper-greater-than-0

Essentially, you must supply some "Damper" to get the target velocity to work. Mathematically, I understand the "by design" response and how it all works. In my opinion. the term "Damper" being used to define a value that helps you reach a target velocity other than zero is confusing at best when looking at any definition of the term.

This is documented under "Drive forces" here:
https://docs.unity3d.com/Manual/class-ConfigurableJoint.html

But I honestly did not fully understand this until I found the equation in the issue tracker above. I wish this was detailed much better in the documentation, particularly on the "Target Velocity" description.

Hope this helps someone in the future coming across this thread.

 

Yeah, the Unity documentation isn't much help. I found the PhysX docs to be more useful in figuring this stuff out:-

• http://docs.nvidia.com/gameworks/content/gameworkslibrary/physx/guide/Manual/Joints.html#d6-joint (see under "Drives").
• http://docs.nvidia.com/gameworks/co...hysx/guide/Manual/MigrationFrom28.html#joints

By the way, here's some interesting / odd behaviour I found. I wanted to configure JointDrives to work in a similar way to the old Unity 4 velocity drive. In other words, to be limited in strength only by maximumForce, not by positionDamper at all.

So I tried setting positionDamper to Mathf.Infinity which worked fine, except with rigidbodies with small masses, where the velocity drive would no longer work for some reason. In the end I set positionDamper to a smaller (but still very large) value. I've no idea what's going on internally to cause this, very strange!

 

From the issuetracker link above, the drive's force is equated as follows (for later reference):
force = spring * (targetPosition - position) + damping * (targetVelocity - velocity)

We needed the velocity drive to use realistic forces that could be held back by large masses, and we eventually managed to get what we needed by modulating the speed until the actual speed was what we wanted. Doing this, we were able to lift heavy objects with even very small velocity targets (which would normally produce forces that are too small to overcome gravity, and the object would actually FALL as a result). So we request a velocity of 0.01 to our class, but our class adds to the drive's targetVelocity until the actual speed is 0.01 (the targetVelocity may actually be 0.3 to produce enough force to get going in an upward direction at 0.01). We then clamp our drive's targetVelocity versus the actual velocity to being within +/- 1 m/s so the force never exceeds what you supply to the damper (see equation above).

If you just want to maintain a certain speed without regard to external force effects, I would probably just use the spring/position, and update the position every frame to achieve your velocity. I wonder if the issues you were seeing with infinite force (which I believe is the same as float.MaxValue) come from when you try to apply a target velocity > 1? I could see the resulting force value being larger than a float can hold (per the equation) and giving unexpected results. That doesn't really explain small masses vs large masses. I suppose a mass < 1 with a force applied at float.MaxValue would achieve a velocity higher than a float can hold, which could also cause issues.

 

Good lord, thank you so much. TL;DR if the Damper is zero, setting a Target Angular Velocity does nothing. #Unity2019

 

2022 and the doc is still garbabe.
I've been trying to wrap my head around the ConfigurableJoint for a day now. E.g it says

Pretty sure this is what X Angular Drive is for...
Also:

Yeah, these properties don't exist anymore.

At least the formula now is in the doc, pretty much the most important info on the whole page, if you read past all the incoherent nonsense.