Does Newton enable floating point exceptions?

[JoeJ]

I have the problem that my program causes debug break in both debug/release, e.g. if i do floating point division by zero.
I have floating point exceptions off, but it happens regardless, and it drives me crazy.

Now i just found out i get those exceptions only in Newton 'callbacks', actually ndModel Update().
I use this code to test it:

Code: Select all

void Update (ndWorld* const world, ndFloat32 timestep)
{
{float a = 1.f; float b = 0.f; float c = a/b; SystemTools::Log ("div0 %f\n", c);}
// raises exception: Unhandled exception at 0x00007FF625D663A8 in Realtime.exe: 0xC000008E: Floating-point division by zero (parameters: 0x0000000000000000, 0x0000000000009D24).


I do not link to Newton dll, but include the whole source to my project.
And i did not find that you enable exceptions, e.g. using _controlfp.

But maybe you do? Or you have any idea what could cause this?

[Julio Jerez]

the class is this

Code: Select all

class ndFloatExceptions
{
   public:
   #ifdef _MSC_VER
      #define D_FLOAT_EXECTIONS_MASK   (EM_INVALID | EM_DENORMAL | EM_ZERODIVIDE)
   #else
      #define D_FLOAT_EXECTIONS_MASK   0
   #endif

and is use at the beginning of each thread function, also in the demos is used at the meginning of main.
or somewhere before the main loop.

in addition the constructor enforces _MM_FLUSH_ZERO_MASK which is very important on x86 cpus. since they do not round to zero denormal value and instead do a software exception call back to resolve denormal


since you use the code, instead of linking the lib, you can just made
D_FLOAT_EXECTIONS_MASK 0

and that will be disabled it, but a better solution is to just fox the device by zero, in the code.
that way you get cleaner code.

[JoeJ]

since you use the code, instead of linking the lib, you can just made
D_FLOAT_EXECTIONS_MASK 0

Ahhh great, this works

I have never used fp exceptions before, but i see it's very useful to find issues.
Because my inverted pendulum controllers are not final yet and cause nans all the time, i really have to turn it off to test my old code.

Ideally i would want to disable the exceptions only for my inverted pendulum test ndModel.
I tried this:

void Update (ndWorld* const world, ndFloat32 timestep)
{
//ndFloatExceptions noExp (0); // does not disable
ndFloatExceptions noExp (~0); // does not disable

But did not work. Exceptions still thrown.

Not really a problem. I can disable globally until work on controller is completed.
But let me know if there is a way.

[Julio Jerez]

hey Joe, speaking of controller.

As you know I am try to get one using a neural net that will act as a magic function that given the state of the model, it will just tell where to move the effectors.

that in the simplest explanation that I can come up with.
for that, there are many algorithms from simple to more complex,
I am starting from the simplest of all which is called Q learning.
it is not good for continue spaces, like a ragdoll moved by effectors.
but it is good as entry level test.
I am reading a lot of literature before I start doing it, because there are many ways to make mistakes and few to be right, but without a good foundation of the theory, you just get frustration.
here is a good description of the method,
https://en.wikipedia.org/wiki/Q-learning
and this happen to be at the core of almost all more sophisticated methods.

anyway. before I get there, I need to have a good reliable environment which I have been working for few days now.

work on that I just discover a huge fatal flaw, on the ik effector method.
It turns out that using the IK effector to calculate joint acceleration or torque, do work kinematically but does not work dynamically.

since the dynamics solution is the kinematic solution that minimized the energy, or toral momentum on the system, this seem to work for a while until the amount of movement added is no longer manageable.

that when I found that last week, it seemed to be a huge blow, to using the IK joints. but after a working the code, to see how can I make the kinematic solution abide but the conservation of momentum, the more I studied the disappointment I was getting.

them I start to think what if I use the kinematic joint just to calculate the joint accelerations, and not using them as part of the rig.
this is made possible by the principle of virtual work. and it is what the ndIkSolver does.

so I decide to test if that was right, and guess what it is 100% correct.

I added two test to verify this.

if you sync and try it here are the tests:

test one show the error. which is what is committed, shows the disastrous result of attaching the effector to the rig. if you try to move the limb, you will see that after a while the model rotates.
but that is impossible because the model has zero momentum, and there are no external forces or torque, so no matter how any internal part move, the overall momentum should be zero,
so using this on a controller, will probably work but will be very chaotic.

the secund demo, is the same model, but I just connected one limb that is control by an actuators joint,
if you move that limb, you will see that the upper body react in the opposite way to counter the momentum needed to move the limb, this is the expected behavior not withstanding numerical errors. but numerial errors can be controlled by small amount of damping.

those tow demos expose the problem, but do not really solve it.
the idea is to use the IK for simplicity but have it physically plausible.

so today I was ready to set that experiment but then I remember that I already have that experiment even in more complex setting. that is the ndAdvancedIndustrialRobot

all I had to do was detach it from the fix base, and let is float on the air.
I was not expecting to work, but to my amazement,
It just worked better than wildest expectation.
that model is a long chain of linked bodies, and it does no add any all the degree of freedom act just as expected.
so I am very, very happy about this result, so I will just go a head, and set the secund biped like that.

I still live the effector as possible joints, because for most rig this is not really a problem, is the rig is stable and has support, like is resting on the floor with a stable support, them the IK solution will be the same as the dynamic's solution, because there will be only one.
This is a problem only when there are multiple solutions like indifferent and unstable equilibrium, which is what a walk creature is. you do not what the movement to add momentum to the articulated body.

any way I just want to mention that.

[Julio Jerez]

al right I now made the secund humanoid using the IK solve, and does not disappoint.
Behaves as is expected.

two clue, that confirm the method is right are:
it does no add angular or linear momentum when we move the body part, that's a hugely important thing. and I believe now it has been one of the problems that I suffer in the pass.
I remember seen that when I move one body part that like a foot, if it was one the ground hold by friction. It always got that unexpected angular momentum on the top body.

the secund point and this is actually quite impressive, is that is you spins the body, and you retract the leg, you can get it to spin faster, than is you extend the legs, the spin slows down.
and it all emerge from the simulation, that surprised me a lot.

the other demo, test_biped 1, is the same demo, but the ik effector are part of the model.
and with this you can immediately see that that just retrieving and extending the legs, just after few tries, the model change orientation and even worse is gain some angular momentum, and that along is just prove that it is just wrong to use ik to calculate PD motors.

anyway, I will later le the gravity on, and try to import the mocap.

them one model will just play the walking cycle.
I suspect that this model should behave a lot better and should need very little correction before it falls. My justification is that the skeleton and the animation are both anatomically correct, therefore the physics should replicate the behavior.
but for that I have to write the mopcap converter for bvh to fbx, so it will probably next week.
them iof all goes well, is on to the neural net balance controller.

edit:
there is a small problem that when the body part self-collide, the body can gain angular momentum, I am not too worry about that for now, because that can be control by limits and contact filters that disable so body part collision, so for nwo I leave alone.

[JoeJ]

Haha, let's call this the 'astronaut test'
I did this all the time when i worked on my own physics engine.
I did not know about the concept of momentum conversation, and that i could calculate it to do proofs. So i always turned gravity off and watched if it starts spinning or even moving when solving constraints.
Looks very nice!
I really like the modeling of spine section with rounded boxes. Seems much better than the capsules i have used.

Remember when you tried to balance some pogo stick model, and i said this should not work - there must be some external force? Maybe your finding does shed some new light in this discussion.

[Julio Jerez]

Yeah. The zero gravity test is very useful to verify conservation of momentum.

[Julio Jerez]

al right, I now enabled gravity again, and after setting the hinge limit to no be zero, since at an exact zero, the solution could be positive of to the front of the back of the kneed.
With direct OK, the solver can handle that, which seemed nice, but ultimately incorrect.
but setting the min limit to be some small positive value, they on the secund pass the solve can determine which side of the solution is the valid one. I which there was a better way to do this, but aft ethe IK find the joint acceleration, in the engine rigid body pass, these value all god to the full solver, and everything is result together with the rest for the scene. at the point the gravity, and all the eternal force can make so that the leg flexes on the wrong direction. just because the ok acceleration what zero or near zero and any residual value is just enough to make it butch.

anyway, after I set the model, when moving the legs with the control panel, the model react very natual and predictable. even when try violent movements the model reacts with natual plausible motion.

in fact, if you try the roll slider, it just takes a few trials to get it to balance.
and this is where conservation of moment plays such a huge important roll, when the leg moves, the entire body react to counterbalance the momentum, the fact that the feet are locked by gravity does not really matter that much, and that was always a big challenge.

Ok wit this I am now ready to move on.
the next two test are.
1-make add a DQN controller to biper_2
2-make biped_1 drive the effector, but a motion capture walk cycle,

2 will take some time, but given that now when moving the leg the model responds predictable, I suspect that when I get the motion capture animation, the player will respond quite nicely. At least that my suspicion and intuition, but we will now when we have it. for now, it is on to balancing again

[JoeJ]

I also ended up limiting the hinges to keep the bend < 0 degrees for the IK solver.
It's a pity. It seems characteristic especially for women that they often can way 'overbend', but i did not want to spend so much work on such a special case. At this point it's not worth it.

My sister can do such stuff, really extreme with the fingers. They can go 90 degrees into the wrong direction. Looks really painful.
However, this is possible only by external force, e.g. by pushing the body against some obstacle to force the bend. Internal muscle forces can not cause it.

But i doubt anybody will miss such things for a long time.
If so, it's surely motivated from art direction, which is still free to modify the physics output if needed.

I noticed IK results tend to change very aggressively when this angle goes close to zero, so limiting to a small number really helps to keep stuff smooth and natural.
I think we can be fine with this limitation.

I see a green face. Long live programmer art!
(I need this too, later, when working on basic AI, so we can see where the character is looking at.)
Physics feel right and natural. But remember: This was possible probably many years before i came here. I got the same thing with motors even with the old joints.

It's about time the sleeping princess of physics simulation shall awake...

[Julio Jerez]

Oh yes this is possible by controlling joint torque. With pd, we support that quite well.
But my claim is that doing with the effectors should be simpler.

For example, if the human was a 2d character standing on one leg. You only need one variable to control the leg, but if you are controlling the joints, you need two.

So the control of the effector is lineal, while controlling joint torque is not.

In fact almost any controll method i' seem, the large majority of the effor goes to get stable cordinated joints angles, while this method you just need to worry about not moving outsize the work space of the effector.

[JoeJ]

Well, yes. But i guess IK was used even before realtime physics, so that's nothing new either.
I just wonder why no games ever tried to use robotics, although the concept of static animation does not fuse fuse at all with the goal of dynamic games.
I guess game devs suffer from some kind of Stockholm Syndrome, being in love with restrictive and expensive animation oh so much.

Is there something special you could tell me about body.GetAccel()?

To set up my IP controller, i need to predict linear acceleration of the upper body caused by the joint motor at the foot body for the next update.
I don't know what i do wrong, but my results fail to predict resulting contact forces accurately.
Now i tried to use GetAccel instead my prediction math, and then results match very closely.
But doing this, i'd be one frame late, which feels pretty wrong. Instead doing the correct thing, i might instead end up replicating a kind of inaccuracy caused by the physics simulation, beside the delay.

One confusing thing i see with GetAccel is that the result jumps to a zero vector while the pendulum swings back and forth, instead the expected smooth changes. That's probably such simulation inaccuracy.
Still, the error of my own prediction math seems much larger than that. According to my math, the pendulum should already tip over in cases where the simulation remains stable.

Edit: Interestingly the confusion only rises for the linear part. My prediction works fine for angular acceleration. Though, to test this, i have to use a pendulum of zero length, so just one body spinning centered around the other. That's much simpler to simulate.

[Julio Jerez]

Yes I know, but my contention is that using ik to predict joint position is not right.
What happens is that most people use it disregarding mass distribution, which means the body parts are considered static as some other move.
This works for animations, because in those cases, an artist can position the other bodies, by using other constraints as part of the rig.

When people use in physics to calculate joints, the case is similar, and I believes this is why results are very robotic and never satisfactory.

The reason is that ik is not derived from the principle of action reaction which obey conservation of momentum, instead is derived from a least square optimization, which does not.

It took me some time to realized that. But now it is very clear. I am using the ik to get joint local acceleration, them these acceleration are not used to move the joint, there are placed on the constraint solver to be resolve all at once, so they can be modified.

The simplex example is the a simple two wings jointed by a hinge floating gravity less environment.

If both wings are equal mass, some ik will move both wings equally, this agree with the physics. But some ik will just move one wing, to varios degrees.
Let us now assume one wing is heavier than the other.
The ik will still move both wing the same way, but the physics will move the heaviest wing less so that thier product of mass and vocity are equal and opssite.

In the extreme case, if one body is fix. Them the second will get all the motion. And this is what most iterative ik systems provide. That's why, most animation systems that use ik to place foot effectors, seem to work, but are ultimately wrong and look robotic at best, the ik simply accommodate the location of parts disregarding conservation of momentum.

The method I am using is not ik, I named ik solver, but it is an inverse dynamic solver. It does one Inverse pass to get the accerations, them one open loop pass that uses those acceration as motors, in is this pass that enforces conservation of momentum.
The other method, I was just attaching the effectors to the chain, and that acts as an ik system, but the interior joints are not constrained to obey action reaction.

Anyway, regardless of how any body did it before, I am satisfied that I now have a biable solution that is physically sound.

On body get accelration, that a result after the solver, not before.

Imagine a body falling, if yo call get acceleration just before hit the ground you will read the gravity. But after the solver tge acceration should be zero, if restitution was zero.
So using accelration for a controller will yield very unreliable measurements. Since the body is older constraint permanently.

[JoeJ]

Yes I know, but my contention is that using ik to predict joint position is not right.

Agreed, but you can still use existing IK algorithms to calculate the relative offset of the bodies, and let the physics joint care about proper momentum conversation.
Even i can do this, a self thought amateur. I don't say it's easy, or that we could match cutscene mocap with low effort, or that any physics engine could do it robustly out of the box.
But i do say the games industry completely missed a low hanging fruit in this regard.
Even if expected results are only robotic, there are plenty of robots in games. And 10 years ago the standard of animation was much lower than now as well. So they missed it, did not care, and there is no excuse.

Found the reason for my acceleration problem. Angular part is equally affected too, but i did not spot it because the simpler test case. The reason is that the joint motor applies less acceleration than i set.
Not really a problem.
It just means that i can not use Newton to verify my math in this regard.

[Julio Jerez]

Found the reason for my acceleration problem. Angular part is equally affected too, but i did not spot it because the simpler test case. The reason is that the joint motor applies less acceleration than i set.
Not really a problem.
It just means that i can not use Newton to verify my math in this regard.

are you using PD joints?

that's the kind of problems that I claim the inverse dynamics solves, if you want to get an accurate measure of the acceleration the invDynamcic was designed for that.
It will gives accurate joint force and toque, and the net body accelerations.
try looking at the demos, you will see they are not that hard follow.
believe, over the year I have read some many papers that the large majority of what the do is to solver for that, and I am still yet has not found one that does it right. this is simply because the problem is a close system. we have it, you might a well using it.

anyway I am now adding the metric that the AI controller will use to tray to balance the model.
I will first try just two d, just to flesh out the algorithm, them extend to three d.

if you sync you will see that the model show tow points,
one in the middle of the like that connect the two effectors.

the other one is the zero moment point, the gal of the controller is to move the center of mass to fall as close as possible to that line.

in this demo if you move the roll slider, it is possible to find the balance point after a few tries.

the balance point does no look natural, because the upper board pas is bend backload.
in fact a better balance point would be the with the body bending slightly to the front.

but that much harder to find because for that, the feet has to move to the back to provoke the body to keep falling forward. them stop and moves back to align the zero moment point.

for that the controller will have an object functions that reward the zero moment point but also the upper body alignments to gravity.
what I expect to happens is that the controller will find a local minimal like a humane does.
but as it keep trainings, and some point there will be a gradient that will move outside and try to find a point we even higher score simply because the body will be more alimented to the vertical.

at least that is what I hope.
so I will be working on that this week, but there is a lot of setting up still.

[JoeJ]

are you using PD joints?

Meaning proportional differential controller?
No. My joint has a point to point constraint as usual, plus an angular motor.
The target for the motor is either relative angular velocity or relative rotation for the two bodies.
I'm using angular velocity for the test.
Posting code for the motor. But i'm not done yet with porting it to use Newton math lib, so it looks a bit messy. Also i avoid to construct basis vectors in an arbitrary way, using the basis from the previous step to get a new one, which is confusing.

Code: Select all

   void AddAngularMotor (ndConstraintDescritor& desc, const sQuat &q0, const sQuat &q1)
   {
      //ndFloat32 &timestep = desc.m_timestep;
      ndFloat32 &invTimestep = desc.m_invTimestep;

      sVec3 vErr;
      if (angMotor_useVelTarget) // <- using this mode
      {
         vErr = targetAngvel;
      }
      else // target is a rotation offset
      {
         sQuat qt0 = q1 * targetOrn;
         sQuat qErr = QuatFromAToB (q0, qt0);
         qErr.Normalize();
         vErr = QuatToAngVel (qErr);
         vErr *= invTimestep;
      }

      sVec3 avel0, avel1;
      ndVector w0 = m_body0->GetOmega();
      ndVector w1 = m_body1->GetOmega();
      avel0 = (sVec3&)w0;
      avel1 = (sVec3&)w1;

      sVec3 avelR = vErr * angMotor_reduceError - (avel0 - avel1);   

      sMat3 basis;
      sVec3 mainAxis = vErr; // less jitter
      //sVec3 mainAxis = avelR;

      float sql = mainAxis.SqL();
      if (sql < FP_EPSILON2)
      {
         sQuat oldSpace = q1 * cSpaceA; // constraint space is fixed to parent bone
         basis.FromQuat (oldSpace);
         mainAxis = basis[0];
      }
      else
      {
         mainAxis /= sqrt (sql);
         sVec3 align = q1.Unrotate (mainAxis);
         if (align.Dot(cSpaceA.XAxis()) < 0.0f) align *= -1.0f;
         sQuat q; q.FromVecToVec (cSpaceA.XAxis(), align);
         
         cSpaceA = q * cSpaceA;
         cSpaceA.Normalize();

         sQuat smoothSpace = q1 * cSpaceA; // constraint space is fixed to parent bone
         basis.FromQuat (smoothSpace);
      }

      sVec3 relAcc_ = avelR * angMotor_accFactor * invTimestep;

      if (0)
      {
         sVec3 com = (sVec3&)m_body1->GetGlobalGetCentreOfMass();
         RenderArrow (com, -relAcc_, 0.1f,   1,0,0);
         RenderLabel (com - relAcc_,         1,0,0, "joint relAcc_");
      }
      ndVector relAcc (relAcc_[0], relAcc_[1], relAcc_[2], 0.f);
         
      //for (int n=0; n<3; n++)
      for (int n=2; n>=0; n--) // using skeleton, we must first stabilize axis - seems more sensible to the order rows are added
      {
         // calculate the desired acceleration
         ndVector axis (basis[n][0], basis[n][1], basis[n][2], 0.f);
         ndFloat32 relAccel = relAcc.DotProduct(axis).GetScalar();

         AddAngularRowJacobian (desc, axis, 0.f);
         SetMotorAcceleration (desc, relAccel);
         SetLowerFriction (desc, -maxMotorTorque);
         SetHighFriction (desc,  maxMotorTorque);
      }
   }


Currently i use this joint only for the one legged hopper and the inverted pendulum. Both models have only two bodies and one joint. I have no ragdoll yet, but so far the joint seems fine.

The angular acceleration it generates is often only 50% from the target for my test, but if we look at velocity, it is pretty accurate. Like with a real world motor, i do not expect it's 100% accurate and responsive.
Still, i run the test with 4 substeps and 12 solver iterations. So maybe i do something wrong and it should be more accurate.