Let us talk about a smart self balancing ragdoll

A place to discuss everything related to Newton Dynamics.

Moderators: Sascha Willems, walaber

Re: Let us talk abput a smart self balancing Ragdoll

Postby JoeJ » Mon Oct 31, 2016 9:23 am

Ok, found it. The stiffness value has a much different effect as in older Newton.
Changing it from 0.9 to 0.99 fixed my issues :roll:
User avatar
JoeJ
 
Posts: 1453
Joined: Tue Dec 21, 2010 6:18 pm

Re: Let us talk abput a smart self balancing Ragdoll

Postby Julio Jerez » Mon Oct 31, 2016 10:17 am

Ha, yes you are right I might have intruded some changes there a while back when trying to model springs. hopefully that's no a big issue now that you know.

anyway how are the results?

I am converting the vehicle to a 100% newton joint based articulated model.
The results so far are very encouraging.

in the pass I have to make a hybrid where some parts where newton bodies and other where build on the controller manager. Stuff like engine, gear box and differential always has big issues because
the have very small masses and they spin a really high speed.
so I have to add post process passes hacks to correct solver errors.

Now, I did not even have to add that pass because there error is so small that the vehicle behave well.
The tire model seems to function as expected.
You are right, I was never sure is the smudgy behavior was because of mistake on the Langragian derivation of the drive train or because of the lags in the solver. It seems that is was lags coming form the solver. Now I am able to actually find out if I made a mistake by testing against control cases where I know the results and that way I can debug the model.
I also let me work in a modular way where a new components do not change the behavior of other components.

I still have some more work on the vehicle but after that I will start the self balancing ragdoll.
Julio Jerez
Moderator
Moderator
 
Posts: 12249
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: Let us talk abput a smart self balancing Ragdoll

Postby JoeJ » Mon Oct 31, 2016 3:11 pm

I did the update,
forced-picking-arm-jitter has reduced (it's no issue at all, happens only with stiffness 1.0 - I use 0.98 for now).
Cycling joint for picking works well.

I noticed 2 things that are not perfect:

T-Posed Ragdoll lying on its back flat on the ground: Starts sliding at low constant speed.

Joint-picking the ragdoll and lift up: Ragdoll does not come to rest and turns around the picking joint.
This has always been typical for the skeleton.

No big problems, but it would force us to do things like 'turn skeleton off if dead'.
I'll add reproducing this to the joints demo... maybe you can add some damping or whatever to limit those effects.
User avatar
JoeJ
 
Posts: 1453
Joined: Tue Dec 21, 2010 6:18 pm

Re: Let us talk abput a smart self balancing Ragdoll

Postby Julio Jerez » Mon Oct 31, 2016 3:49 pm

JoeJ wrote:I noticed 2 things that are not perfect:
T-Posed Ragdoll lying on its back flat on the ground: Starts sliding at low constant speed.
Joint-picking the ragdoll and lift up: Ragdoll does not come to rest and turns around the picking joint.
This has always been typical for the skeleton.
No big problems, but it would force us to do things like 'turn skeleton off if dead'.
I'll add reproducing this to the joints demo... maybe you can add some damping or whatever to limit those effects.


Ha but is it is a problem, that should be resolve. fist thing first.
on this one: Joint-picking the ragdoll and lift up
I assume you adding the picking joint when you what to puck the skeleton and the remove what done.
using this
Code: Select all
int NewtonSkeletonContainerAttachCyclingJoint (NewtonSkeletonContainer* const skeletonPtr, NewtonJoint* const jointPtr)


if are doing that then yes there is a way to fix that problem for real. but first I like to see what you done. I had similar problem in the tank thread and hanging bridge demo, the track where jetting and I added the damping rows and it became rick solid stable, and fast.

The second problem I will add the and option auto collect contacts, which because will check when the skeleton is colliding with static object and add the automatically first exact solution.

But again I like to see when you done before doing this.
If you can recreate that test case in the standard joint test that will be great!!
Julio Jerez
Moderator
Moderator
 
Posts: 12249
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: Let us talk abput a smart self balancing Ragdoll

Postby JoeJ » Mon Oct 31, 2016 6:57 pm

Here is code for joint demo: http://pastebin.com/KsxLdAJ0

I have modified AddJoesPoweredRagDoll() to create star shapes with some randomness.
(EDIT: Also added quaternion normalization in SubmitConstr.() to prevent div by zero)
After the stars finish falling down, they start jittering on ground.
That's worse than the sliding with my ragdoll, but probably the same issue.

But there is no problem with picking in sandbox.
Here is my code, maybe you can spot something - my joint should be the same as a ball socket (orientation is disabled).
I'll check tomorrow if it's some difference like max friction rows.

Code: Select all
bool PickBody ()
   {
//...
      if (!kineJoint.m_joint)
      {
         kineJoint.m_body0 = pickedBody;
         kineJoint.m_joint = NewtonConstraintCreateUserJoint (world->world, 6, KCJointCallback, 0, pickedBody, 0);
         NewtonJointSetUserData (kineJoint.m_joint, &kineJoint);
         NewtonBodySetAutoSleep (pickedBody, 0);

         skel = NewtonBodyGetSkeleton(pickedBody);
         if (skel) NewtonSkeletonContainerAttachCyclingJoint (skel, kineJoint.m_joint);
      }
      return 1;
   }


Code: Select all
void ReleaseBody ()
   {
//...

      if (kineJoint.m_joint)
      {
         if (skel) NewtonSkeletonContainerRemoveCyclingJoint (skel, kineJoint.m_joint);
         skel = 0;
         NewtonJointSetUserData (kineJoint.m_joint, NULL); 
         NewtonJointSetDestructor (kineJoint.m_joint, NULL); 
         NewtonDestroyJoint(world->world, kineJoint.m_joint);
         kineJoint.m_joint = 0;
         kineJoint.m_body0 = 0;      
      }
   }
User avatar
JoeJ
 
Posts: 1453
Joined: Tue Dec 21, 2010 6:18 pm

Re: Let us talk abput a smart self balancing Ragdoll

Postby Julio Jerez » Tue Nov 01, 2016 1:46 pm

JoeJ wrote:...After the stars finish falling down, they start jittering on ground.
That's worse than the sliding with my ragdoll, but probably the same issue.

wow, I agree, that's quite unacceptable. I am working on the solution now, I will commit it tonight.

Basically what it will do is that the skeleton will have a contact joint buffer that will be used to collect the contact in proximity with the skeleton, and issue those as cycling joints. the it will clear the array after the simulation update. This should be very easy to handle.
Thank for the repro test case.
Julio Jerez
Moderator
Moderator
 
Posts: 12249
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: Let us talk abput a smart self balancing Ragdoll

Postby JoeJ » Tue Nov 01, 2016 4:53 pm

Ah good - i thought you'd already using cycling joints for contacts.

One improvement from older Newton i've noticed is that ragdoll contact forces are much smoother now when not using the skeleton.
So maybe a similar improvement is coming to skeleton with this.


I have not found the reason for my picking joint problem yet.
Tried removing max friction rows from my joint and large mass ratios, but still can't reproduce in sandbox.
Maybe it's because i add / remove the joint at runtime, but more probably the ragdoll behaves different than the star shapes.
I'll add the star shapes to my project to test this...
User avatar
JoeJ
 
Posts: 1453
Joined: Tue Dec 21, 2010 6:18 pm

Re: Let us talk abput a smart self balancing Ragdoll

Postby Julio Jerez » Wed Nov 02, 2016 12:00 am

No I did no added the contact on the last commit. I just finish that and it seem to add some improvement, but those not really fix the problem, plus is really work very bad with arrangement where there are multiple skeletons together like the tracked vehicle why is made of three skeletons.
I think that problem is because the have an exact solve the only work on some of the joint cause the there error tp be all allocate to the rest of the joints. so the discrepancy look much worse.
I think is a bad idea to add the contacts unless we add them all, and that make to unacceptable slow.


Where I see the jitter, it look to me that this is des to some more than the error solver error.
I believe this is because the expression you use to solve the joint error is this.
dVector angAcc = (errorAngVel.Scale(m_reduceError) - (angVel0 - angVel1)).Scale(invTimestep);

basically this is a stiff spring system with no damper. Think about if the angVel0 - angVel1 is some small value which is inevitable since we still use a Euler integration. then
then the value (angVel0 - angVel1)).Scale(invTimestep) because a huge acceleration that cause the solve to correct the entire error. however this strong correction make the correction to overshot.

But overshooting is no only on a couple of joints it is in all joint cause a application of the frequency of oscillation for the entire system.

I think I can modified the joint so that the correction uses an implicitly version of the of the error, this is, we calculate the velocity at the end of the time step by using the derives of the contact and we using as the slope of the relative velocity and position error.

I think that's a better solution that try to consider the contacts as cycling joints.
Julio Jerez
Moderator
Moderator
 
Posts: 12249
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: Let us talk abput a smart self balancing Ragdoll

Postby Julio Jerez » Mon Nov 07, 2016 4:04 pm

hey joe, I am taking some time because I realize that this issue is related to the general solver.
I am doing the second part for that, basically what is going on Is that is you have an array of joints and a the solver try to resolve the joint acceleration, in each iteration the average acceleration error is distribute across all joints, however of you have sub set of those joints that use a solve the drive the acceleration to zero, the acceleration becomes higher.
this is counter intuitive, but it is really not, because if the exact solve joint are very stiff, then the each generate the exact solve operate of these joint the generate huge forces to drive the acceleration to zero, but then when a soft joint touches any of the bodies the fell those huge change of forces which the soft solve is incapable to drive to zero.

this is similar to when a kinematic body touches a dynamics body. if the kinematic body has infinite mass they can have unlimited energy to apply to the other body, this is why in Newton kinematic bodies do has mass.

similarity and exact solver actin on sole of eh join but not all act as in body with unlimited energy.
to improve this I have to make the general solve better.
and I am working on that now.
Julio Jerez
Moderator
Moderator
 
Posts: 12249
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: Let us talk abput a smart self balancing Ragdoll

Postby Julio Jerez » Wed Nov 09, 2016 10:47 pm

Hey Joe, I committed a improvement to the general solver.
Wit the same setting, I believe is resolve the jitter, the thong is that we can increase the convene rate on per joint bases, although I have not expose that yet, I hope is not necessary.

The one thing I noticed is that the cross shape rag doll, the joint seem to have a net internal acceleration that me the while strong spring as come velocity, This may has being the source of the jitter combined with the poor convergence, butt that the is more predictable it is clear that the joint seem to have a build in motor.

Please if you have time sync and tell what you think. I will continue on some more tweaking. But this is close to the final product for 3.14.
soon I will move to complete the Vehicle and the self Balancing rag doll.
Julio Jerez
Moderator
Moderator
 
Posts: 12249
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: Let us talk abput a smart self balancing Ragdoll

Postby JoeJ » Thu Nov 10, 2016 8:10 am

Hmm, i did the update but can't see a noticeable differences about the jitter, neither in sandbox nor my own testbed. Are you sure anything is activated / up to date? (Demo sandbox started with box stacks.)

I copied the star shapes to my sandbox, there i have some addtional options in the joint:
* Limiting target acceleration to a given max value - no big difference.
* Instead of Gramm Schmidt, cache old constraint space and rotate it to the new error axis to prevent 'random tangents' - this converts the spinning motion of the regular cross shape to usual jitter, so a little improvement.

Comparing skeleton / off, there are issues anyways - especially the cross shape seems a real worst case test. For ragdolls it won't become a problem in pracitce, because dead bodies turn off their motors.


The 'adding energy' behaviour when joint picking my ragdoll is much worse than in the hanging star i made for demo sandbox. I believe the reason is the ragdoll structure and mass ratios.
In sandbox it's not noticable, but probably there as well - otherwise the hanging star would come to rest after time because of angular damping.
(Just to mention - should be no big problem in practice as well)

Julio Jerez wrote:the thong is that we can increase the convene rate on per joint bases, although I have not expose that yet, I hope is not necessary.

If 'exposing' means just adding the interface without performance costs i'd be interested :)
User avatar
JoeJ
 
Posts: 1453
Joined: Tue Dec 21, 2010 6:18 pm

Re: Let us talk abput a smart self balancing Ragdoll

Postby Julio Jerez » Thu Nov 10, 2016 3:48 pm

Oh ye I see it, I start to believe that this is not a bug,
It is hard to explain but it seem that the concatenation of many stiff joints and a multiplicative vibration effect. I run some test using firm one segment coming out form the center, and that fine, then doing tow segment take a little longer to settle but is does it, three link seem to be at the edge where is take a while to go to rest, after for element per link them the residual acceleration never goes to zero, and its gets worse form there. the strange thing is that that when I measure the acceleration between each constraint the are, is virtually zero, so the solver is doing what must.

what I think is happenings is that each indivual stiffness combine with the other to make and even stiffer problem. I still need to investigate more.
JoeJ wrote:* Instead of Gramm Schmidt, cache old constraint space and rotate it to the new error axis to prevent 'random tangents' - this converts the spinning motion of the regular cross shape to usual jitter, so a little improvement.


yes that is a good idea, that is the basis for the implementation of a 3DoF joint that use small angular approximation that I fail last time I tried.
his week end I will do two things.
1- make the small angular approximation power joint for ragdolls. we are going to need some very reliable for controlling joint torque using independent angles.

2- spent some time profiling 3.14 vs 3.13 I run a test last night and 3.14 is running over 50% slower that 3.13 when should be a least equal or better. 50% performance difference is too much.
I suspect it is on the broadphace, I knew those few most ago and I tough is was because of float denormals, but is not that.

anyway let me work on that joint to see if we can resolve this issue.
Julio Jerez
Moderator
Moderator
 
Posts: 12249
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: Let us talk abput a smart self balancing Ragdoll

Postby JoeJ » Thu Nov 10, 2016 4:24 pm

Julio Jerez wrote:three link seem to be at the edge where is take a while to go to rest, after for element per link them the residual acceleration never goes to zero, and its gets worse form there.


Did you try this with doubles as well? I would expect a big difference (all my code is hardcoded float, so i can't quickly test myself).

Have you ever thought of tackling the jitter problem with a unique approach independent from solver and even the laws of physics?
I mean, if the primary source of jitter is precission, this would become a problem more related to quantum physics than to classical mechanics when comparing simulation with reality - a perfect excuse to cheat :)
Something like: detect similar contact forces over time && similar user joint acceleration over time && it's possible to build a stable reference space over time -> damp that stuff to force it to rest.

I know from my own experience that this sounds simple but is badly compatible with realistic physics,
but i can't get rid of the idea...
User avatar
JoeJ
 
Posts: 1453
Joined: Tue Dec 21, 2010 6:18 pm

Re: Let us talk abput a smart self balancing Ragdoll

Postby Julio Jerez » Thu Nov 10, 2016 7:25 pm

JoeJ wrote:
Julio Jerez wrote:Have you ever thought of tackling the jitter problem with a unique approach independent from solver and even the laws of physics?


we have to differentiate between Jitter and Vibration. Jitter is vibration that is generate from random acceleration at the joints because of poor convergent in the solver.
Vibration me come form legitimate accelerations generated at the joint from the expression use to calculate the joint acceleration.
I suspect this is what is going on this case. The way to solve it is by using an implicit acceleration rather that an and explicit.
This is simple an explicit acceleration is what we are dong now giving the error in position and velocity we calculate the acceleration to reach the target, this is what is adding lot of energy to the system, because when the acceleration is of high, the solve now can generate a powerful force the satisfy the constraint by is doing so it add lot of energy to the system and net time around conservation of throw a monkey ranch at us.

implicit acceleration mean we pretend that every thing remain constant and we integrate the two body assuming they their velocity is constant, this will create a new different velocity and position at that contact point. and we use those to calculate the acieration such that at that new position the velocity and is zero out.
This can done using particle derivative which is what newton does internally, those funny numbers that you see in submit linear and angular rows, but when the joint make motors then those values are overwritten.
is hard to do it when the system canon be express analytically like motors, but can be done empirically by integration the object as I explained above.

I still do no what to try that, because I am still try to find out if we can make a better joint, but in the end this will be a good way to doing it.

BTW they one function that does that kind of calculating for a spring damper acceleration

the expression is this
Code: Select all
a = [ - ks (x2 - x1) - kd * (v2 - v1) - dt * ks * (v2 - v1)] / [1 + dt * kd + dt * dt * ks]


instead of
Code: Select all
a = - ks (x2 - x1) - kd * (v2 - v1)


you can see that as dt approaches zero the second equation become the first. buy when dt is no zero then the time step play and important roll in manipulation Ks and Kd to make sure that at the end of the time step v2 - v1 and x2 - x1 is zero.
Maybe I need to derive and function like that for motors.
Julio Jerez
Moderator
Moderator
 
Posts: 12249
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: Let us talk about a smart self balancing ragdoll

Postby Zetamun » Tue Jan 03, 2017 1:33 pm

The version of Newton I have is from 2011, it seems to have a bug where if you (the playercontroller) jump onto a crate you get stuck into half of it.
User avatar
Zetamun
 
Posts: 18
Joined: Tue Jan 03, 2017 1:19 pm

PreviousNext

Return to General Discussion

Who is online

Users browsing this forum: No registered users and 15 guests

cron