Another Force Mystery

[JoeJ]

In the video you can see 2 joint powered models producing similar motion without gravity.
At each bottom body i attach another point to point joint and measure its force using NewtonUserJointGetRowForce.
I display that as green vector, my goal is to calculate this force.

On the right i use a powered linear row (maybe the same as a newton slider).
Here the force goes up and down as expected, and i am able to calculate it myself in two ways:
1. Velocity-difference with previous frame -> accel -> force.
2. using current velocity and joint target, so i can predict the result from powering. All fine.

On the left there's a powered hinge (powering from single angular row).
Notice that the force required to lock the lower body now only goes upwards, it looks there is another magic force acting - but that's not the case.
I totaly fail to predict the generated force, which is bad because i need to know ground reaction force ahead to control ragdoll balance.
I don't have any idea what is causing this mysterious joint force - a unknown physics law? Some Newton internals?


http://www.youtube.com/watch?v=8Xuvrwo82UI&feature=youtu.be

[JoeJ]

I found that the result from NewtonUserJointGetRowForce is not what i've expected (i expected it to be the force calculated during previous timestep).
I made a copy of the hinge powered model and applied joint target and resulting force from the original one timestep later.
The copied model moves upwards and can't replicate the original behaviour.

So NewtonUserJointGetRowForce is not useful for me to proof my math is right.
I think what is going on is that for the slider model anything gets solved in one substep, so the result is correct.
And for the hinge model the force gets modified during multiple substeps, and the function returns only a incomplete result?

Is this a bug that can be easily fixed?

[Julio Jerez]

I found that the result from NewtonUserJointGetRowForce is not what i've expected (i expected it to be the force calculated during previous timestep)....
Is this a bug that can be easily fixed?

yes you are rioght correct, that was correct in earlly versions Newton 2.xx and lower and for the exact solver.
Netwon 2.08 (I beleive) uses a runge kuta order 4 solver/integrator for the iterative solver.
a RK 4 will do four sub steps and it requires calcualtion of the the partical derivative of the joint, for predicting the joint veleocity
at 1/4, 1/2 and 3/4 of teh tiem step.
those wierd numbers that you see in the functions that calculate the joint derivative comes from the calculation these derivative.
for contacts is more dificult because the contacts are discotinieus functions so that partial derivative can not tbe compute analitically,
but it can be stamated numarically by making some asumptions.
Bascially I asume that an island will not generate contacts doring an integration step and teh contact position position changes linearally,
this allowes me to predict the contacts velocity form teh first derivative and teh coeftion of restitution or friction.
what you are seeing is the force that was calculated at the last sub step.
The reason I save that is because that force is used to set the initial guess for the solution of the next integeration step.
The effect of and KR4 is that is smooth the forces acrosss the time step.

when I was doing the destrution demo, I faced a simular problem, I was never getting the correct impulse,
so I added an extra member to the contact joint for saving the largest parcial force of the integration step.
That function is exposed as NewtonMaterialGetContactMaxNormalImpact(material);
I use it in this function

Code: Select all

   void SimulationPostListener(DemoEntityManager* const scene, DemoEntityManager::dListNode* const mynode, dFloat timeStep)
   {
      // see if the net force on the body comes fr a high impact collision
      dFloat breakImpact = 0.0f;
      for (NewtonJoint* joint = NewtonBodyGetFirstContactJoint(m_myBody); joint; joint = NewtonBodyGetNextContactJoint(m_myBody, joint)) {
         for (void* contact = NewtonContactJointGetFirstContact (joint); contact; contact = NewtonContactJointGetNextContact (joint, contact)) {
            dVector contactForce;
            NewtonMaterial* const material = NewtonContactGetMaterial (contact);
            dFloat impulseImpact = NewtonMaterialGetContactMaxNormalImpact(material);
            if (impulseImpact > breakImpact) {
               breakImpact = impulseImpact;
            }
         }
      }

The value is an impulse, but it can eassy be converted to the average force by deviding by the time step.
maybe you can use that.

[JoeJ]

Ah yes, that might become useful.
For now i made a force based point to point to proof my math. Not as stiff and stable as a real joint, but good enough to feel right.

Thanks.

[Julio Jerez]

one of the thingsis that you try to use force to control your joint, and that's not really correct for a reduce cordenate system engine.
you should use the velocity and acceleration.

The reason is that forces are global values, while velocity and accelrration are local values.

take for example a stack of 10 spheres resting the floot, if you measure the force at the base,
the force will be 10 time the weight of a single ball. if you measure the acceleration it will be will be amost zero.

as you move up the stack the force will be changing while the velocity and acceleration will remain almost constacts.

this is why for constrained dynamics (using reduced condinate system) you should always use acceleration and velocity are feedback.
Generalatized codinate system (like Featheston) and Penality methods (like spring mass systems) you use forces for feeback.

That's the main root of your problem you are tring to use the joint force for feeback of a constroller.
try re thinking your controller in terms of joint acceleration and joint velocity.
Thust me it will be simpler and more predictable, it will also be more relistic,
because a real sensors can easylly measure accelleration and velocicy, by very hard to measure forces with the exeption of a scale or a spring..

[JoeJ]

That the main root of you problem you are truin to use teh joit force for feeback of a controller.
try re thing your controller in terms of joint acceleration and joint velocity.

So far my controllers input is usually based on COM vel/acc.
The reason i want the ground reaction force now is to know if i'll loose static friction or contact at all.
I do not use neither joint force measurement or force based fake joint at runtime, i use this only temporary to see if my calculations are right.

To handle the multibody problem i use this trick to avoid dealing with constrained dynamics:
Calculate relative acceleration at foot contact locally.
Then treat the 2 body pendulum model as a single virtual rigid body.
Calculate force / torque to drive rel accel to zero for this virtual body.
Proof: Map this f/t to each real body accordingly. Because it works, does not raise energy etc., i should know that the force is a good approx. for what will really happen.

Because the pendulum is powered all the time so pretty stiff, the virtual body method should be accurate enough for my purpose.

I never thought about using joint acc/vel directly to drive a controller, but i do it in an indirect way, because COM vel/acc is a result of those.

[JoeJ]

Ok, tried a controller based on joint vel / acc and it works very well - thanks for the tip!