Inverse Dynamics Robot demo questions

A place to discuss everything related to Newton Dynamics.

Moderators: Sascha Willems, walaber

Re: Inverse Dynamics Robot demo questions

Postby Julio Jerez » Thu Dec 28, 2017 8:29 pm

btw I am having a hard time adding the limits, I stripped the six axis demo to a simple hinge joint to see if I can find out what is wrong but and still do not see what it is.

In the process I made changes that seem to screw the engine big time, so I will revert back to where i stated last week, something very basics is still wrong.
I can see how there will be discrepancy between the acceleration calculated by forward dynamics and the one calculated by inverse dynamics, but overall behavior should be very similar and I do not see that happening.
we need to have a solver that is reliable at all time.
Julio Jerez
Moderator
Moderator
 
Posts: 11147
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: Inverse Dynamics Robot demo questions

Postby Julio Jerez » Thu Dec 28, 2017 10:30 pm

This was getting so convoluted that I decided to go back to where I started when I decided to try again.
This time I am making an even simpler demo, last time I started with the robot arm and I did not even made a comparative test, I saw it working and I, arrogantly, thought I was going to able to fix all the problems by simple inspection, but now I know it is not that simple.
so I decided to make a test starting from the simplest of all cases, a simply joint with one dof.
In case you guys want to followed the theoretical background, this is based on a generalized principle of virtual work. This is an awesome theorem that allowed us to apply any imaginary force or forces to a configuration and calculate the needed internal reactions to balance the effect.
https://www.youtube.com/watch?v=4t0KvJXF1Bc

There are other ways to do his with pure math using Legendre transformations, but the Legendre method is a pure math framework that deal only with varibles in one sytem and variable on another system and its derivatives. is it for more complex and general. the virtual work and generalized forces which is a special case seem a sufficient and powerfull tool for these problems.

now I am making literally the example the professor is solving on the black board.
basically he is converting the forces applied to a rigid body, to the joint torque needed to counter that forces, he also do some other examples but this is good start to compare.

I also added two demos, the one of the left do the inverse dynamics conversion, the one of the right does the forward dynamics.
we can see immidiatlly the although they behave similarly, it is clear that they diverge a lot as if the ik solution is not taking into account the viscous friction (drad) but i know is not that.
It would seem that the IK solution is better, however moving on with a discrepancy like that is what causes malfunction the first time. So I need to figure out what is wrong there for real.

also it might be tenting to think why is the IK really needed if the forward dynamic can do the same, the answer is that not they do not do the same thing. They are doing the same on these examples but on the present of other external forces the befavior is quite different and the forward dynamics will never be right because it cannot separates internal from external forces.
basically inverse dynamics calculate joint acceleration based of the kinematics of the joints configuration then the behavior of the system is independent of what those accelerations are.

The trick is how to get the to agree with each other at all time and all situations.
Julio Jerez
Moderator
Moderator
 
Posts: 11147
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: Inverse Dynamics Robot demo questions

Postby Julio Jerez » Fri Dec 29, 2017 4:08 pm

ok now doing the baby steps, I migrated the six axis robot demo to the build on top of the
dCustomRagdollMotor joints

the two joint behave almost identical at a macro level, but not at the micro level,
and this is what I expect.
you will see that the joint has a small jitter when it hit teh limit, or when it can move outside the work space, but that is expected. before these error was totally unacceptable.

Now I will move to the second demo, the two degree of freedom arm with limits se if that works as expected.
so far everyu thong is going the way we want and I hope I can get both demos before the year end.
Julio Jerez
Moderator
Moderator
 
Posts: 11147
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: Inverse Dynamics Robot demo questions

Postby Julio Jerez » Fri Dec 29, 2017 4:28 pm

the two dof robot with joint limit check out without problems.

you can see how there are some differences when the end effector is in some position near the boundary of the world space, but the result so far are better that even I was expecting.
remember the model on the left is predicting the joint accelerations that the model on the right is calculating.
To make interesting, I rotated the forward dynamics model on the right by 180 degrees, this will make it that they will collide in some places. When they collide you can see how the Inverse dynamics model dominates the forward dynamics which an example of what I was trying to explain before, here you can see how the torque adapt to what is needed as along as there is friction to draw from the friction limit.
the forward dynamics can only predict where the effector tell it to go, but since it is not aware of the other external forces, it always comes short. That's the big different with the system that I had seen.

Now moving to the three dof model (the rotation base) :shock: 8) :lol: :x :P :idea:
Julio Jerez
Moderator
Moderator
 
Posts: 11147
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: Inverse Dynamics Robot demo questions

Postby JoeJ » Fri Dec 29, 2017 4:42 pm

Julio Jerez wrote:when the collide you can see how the Inverse dynamics model dominate the forward dynamics which is the example I was try to explain before, here you can see how the torque adapt to what is needed as along as there is friction to draw from teh friction limit.
teh forward IK can only predict where the effect tell, but since it is no aware of the other external forces it always comes short. That teh big different wit the system to all system I had seem.


Ha, didn't look yet but i was always worried about such things, so i hear you... :mrgreen:
User avatar
JoeJ
 
Posts: 1160
Joined: Tue Dec 21, 2010 6:18 pm

Re: Inverse Dynamics Robot demo questions

Postby Julio Jerez » Fri Dec 29, 2017 6:16 pm

Ha, didn't look yet but i was always worried about such things, so i hear you..

like the Chinese say a demo is better that a thousand words 8) .

Hey Joe notice that the forward dynamics robot is also quite cool.
the only problem with it is that it is the kind of thing that people will complain perpetually if the try to use it and you end up on a endless tirade of tweaks, that do not really work it just move the bug to another situation.

please sync again if you can, now I added a fully operational Kuka robot.
as before there are tow version teh inverse and forward. and so far they seem fine with not major discrepancies.

only the arm is implemented, the end effector code to handle angular rotations is commented out.
is no a big deal to get it going so we can put that on hold for latter.

now I will move to the hexapod demo, and see if I can make to stand on teh ground but it own joints.
that will expose some more peculiarities or problems if there are still any hidden one.

for the most part converting angular desire location to other angular acceleration is easier that conversion position to angular accel.
anyway it seem that now we are in a good track to get this system going with some reliability
Julio Jerez
Moderator
Moderator
 
Posts: 11147
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: Inverse Dynamics Robot demo questions

Postby Julio Jerez » Sat Dec 30, 2017 10:34 am

ok guys, now I added a small demonstration of phase three.
It passed the test that worried me a little, and that was that inverse dynamics and forward dynamics would agree on the whole but not on the small details and as result there will always be jitter, specially on complex arrangements.
but to be delight this is so stable that I have to fight to keep it from going to sleep. somehow the inverse dynamic has an stabilizing effect of the forward dynamics. you can see that even when the error is huge, the legs always come some equilibrium state.

Remember I described three phases when we started.
1- the physics rigid body solver and collision calculate joint torques.
2- the inverse dynamics solver that calculate internal joints accelerations.
3- the control system that only operates on the geometry of the system.

phase three is where the user has more control,
in the first demo I was reading parameters from a pane and directly manipulation the root effector.
now this is more formalized by making a vector of position and orientation where the a pose is calculated, similar to how animation systems work.

in this simple case I only set the base pose, and in each frame is sets the same base pose as the target location. since these poses are vector, they can be: interpolated, blended, calculated procedurally, or mapped to some user input.
basically the same way games make animation trees to blend animations.
the difference is that we do it with end effectors.

hope you gys can see why I envisioned that this system unify physically based, procedural, and IK, all in one.
By combining inverse with forward dynamics the system can do anything possible the most natural way.

In this demo, you can pick and drag the creature, and you can see how the legs react to both environment and imput acceleration.
It seem too weak at times, but that either because of calibration or because the grab force is actually yoo strong.

anyway at this point and I now undecided if we should try the biped, or eleborate more on the walker.
a reason I would like to try the biper is because is a good candidate for a procedural animation, mainlly the pelvis pose is mapped to the inverted pendulum, while the feet are mapped the ground.
it also present another case torward the formalization of the system.

on the other hand makind the hexapod walk seem like a very attractive thing to do and also present some more challanges.
Julio Jerez
Moderator
Moderator
 
Posts: 11147
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: Inverse Dynamics Robot demo questions

Postby JoeJ » Sat Dec 30, 2017 11:00 am

Looks fantastic! :shock: :mrgreen:

I'd continue with the hexapod first (to keep focused, balancing the biped is another problem on its own maybe.)
User avatar
JoeJ
 
Posts: 1160
Joined: Tue Dec 21, 2010 6:18 pm

Re: Inverse Dynamics Robot demo questions

Postby JoeJ » Sat Dec 30, 2017 1:05 pm

Is OnContactGeneration callback meant to ADD new contacts by the user?
(I assumed i get access to contacts found by collision detection so i'm confused)
User avatar
JoeJ
 
Posts: 1160
Joined: Tue Dec 21, 2010 6:18 pm

Re: Inverse Dynamics Robot demo questions

Postby Julio Jerez » Sat Dec 30, 2017 1:09 pm

I think you are right let us work more on the hexa.
Later I will relate the user inputs to the pelvis.
this in on itself is a challenge because now there is not such this as reference frame. The reference has to be calculated based on the environment and that's contantly changing relative to the main body position, so let us see how we get that.
Moving a leg is quite trivial just move the target effector relative to the body.
Julio Jerez
Moderator
Moderator
 
Posts: 11147
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: Inverse Dynamics Robot demo questions

Postby JoeJ » Sat Dec 30, 2017 2:21 pm

Julio Jerez wrote:this in on itself is a challenge because now there is not such this as reference frame.


Global world space? I've done it this way (internally this causes some confusion, i have to calculate leg relative to pelvis but also the other way around all the time). Downside is e.g. if the character is on a moving platform the user needs to move the target continuously, but you could give him a suggestion or use a max offset to care for things like leaning against acceleration to maintain balance.

You could eventually extend this to waypoints: The user sets a target waypoint, which he can move / teleport around at will, and the creature has an auto mode where it cares for com and foot targets on its own. Of course this will get complicated if multiple actions are pending like walking to a target, maintaining balance, holding another characters hand, holding an explosive at the other hand etc. Maybe a simple priority weight per action might do it, but maybe it's best to let the user implement all this if no simple strategy turns out to be good for everything.
User avatar
JoeJ
 
Posts: 1160
Joined: Tue Dec 21, 2010 6:18 pm

Re: Inverse Dynamics Robot demo questions

Postby JoeJ » Sat Dec 30, 2017 2:49 pm

I've tried to generate my own contacts now simply with foot box corners and a static ground plane.
Indeed it solves my problem, the IP model now swings forever and does not tip over. :wink:
(Too bad i did not knew earlier - already tried to do this years ago but probably worked with process instead generate callback. My 'One contact' - idea should work too with this method, and there's no need to hack around in Newton as i did back then :roll: )

It is hard to believe that those minor instabilities in automatic contact generation have so a large impact on balancing.
Is contact caching still active when generating own contacts with code as below?



Code: Select all
   static int OnPendulumContactGeneration (const NewtonMaterial* const material,
      const NewtonBody* const body0, const NewtonCollision* const collision0,
      const NewtonBody* const body1, const NewtonCollision* const collision1,
      NewtonUserContactPoint* const contactBuffer, int maxCount, int threadIndex)
   {
      PhysicsTests *tests = (PhysicsTests*) NewtonMaterialGetMaterialPairUserData(material);
      MultiPendulumData &mpd = tests->mpd;
      const NewtonBody *footBody = tests->mpd.bodies[MP_REF0];

      sMat4 matrix; BodyGetMatrix (footBody, matrix);
      sVec3 corners[4] = {
         matrix.Transform( sVec3(  mpd.baseDim[0]*0.5f,  -mpd.baseDim[1]*0.5f,  mpd.baseDim[2]*0.5f ) ),
         matrix.Transform( sVec3( -mpd.baseDim[0]*0.5f,  -mpd.baseDim[1]*0.5f,  mpd.baseDim[2]*0.5f ) ),
         matrix.Transform( sVec3(  mpd.baseDim[0]*0.5f,  -mpd.baseDim[1]*0.5f, -mpd.baseDim[2]*0.5f ) ),
         matrix.Transform( sVec3( -mpd.baseDim[0]*0.5f,  -mpd.baseDim[1]*0.5f, -mpd.baseDim[2]*0.5f ) )
      };

      int count = 0;//min (4, maxCount);
      for (int i=0; i<4; i++)
      {   
         float penetration = -corners[i][1];
         if (count < maxCount && penetration > 0.001f)
         {
            contactBuffer[count].m_point[0] = corners[i][0];
            contactBuffer[count].m_point[1] = corners[i][1];
            contactBuffer[count].m_point[2] = corners[i][2];
            contactBuffer[count].m_point[3] = 1.0f;
            contactBuffer[count].m_normal[0] = matrix[1][0];
            contactBuffer[count].m_normal[1] = matrix[1][1];
            contactBuffer[count].m_normal[2] = matrix[1][2];
            contactBuffer[count].m_normal[3] = 0.0f;
            contactBuffer[count].m_penetration = penetration;
            contactBuffer[count].m_shapeId0 = 0;
            contactBuffer[count].m_shapeId1 = 0;
            count++;
         }
      }

      return count;
   }

User avatar
JoeJ
 
Posts: 1160
Joined: Tue Dec 21, 2010 6:18 pm

Re: Inverse Dynamics Robot demo questions

Postby Julio Jerez » Sat Dec 30, 2017 5:02 pm

JoeJ wrote:
(Too bad i did not knew earlier - already tried to do this years ago but probably worked with process instead generate callback. My 'One contact' - idea should work too with this method, and there's no need to hack around in Newton as i did back then :roll: )

It is hard to believe that those minor instabilities in automatic contact generation have so a large impact on balancing.
Is contact caching still active when generating own contacts with code as below

That functionality was not there before.
that's what I meant when I said that it was not enough to change material properties for contact, some time the contact itself has to be calculated in some way.
The vehicle was the case that convinced me that a more flexible contact system is needed.
Another example where I had to hacked my way like you did was the tank track demo where I learned the hard way that tank aspect ratio is an important factor in making threaded vehicle.
I end up doing more work than needed in the callback rejecting contacts based on heuristic, when I could simply calculated the desired contacts.
Anyway I think you get the idea now, want I mean is that I will try to normalized that trick for 3.15

Yes contact cache is still active when overloading the contact generation callback.

on teh last test when small changes on the imputs generate large changes on the output, you are experience what is known as the effect of signal to noise ration of stiff systems.
Not to be confused with the high gain factor.
The reason high stiffness is bad is because errors get amplyfied wit the input sometime you get a system that generates output even if the input is zero.
Julio Jerez
Moderator
Moderator
 
Posts: 11147
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: Inverse Dynamics Robot demo questions

Postby Julio Jerez » Sat Dec 30, 2017 6:53 pm

on the reference frame thing, yes of course if has to be world space orientation, but it is not as easy as it seems.
I wrote a quick hack function to apply the input angles to the target pose.
if we use the current pose the calculation initially goes into recursive feed back.
for example say teh ya angle is zero, and you ally a one degree offset, the each frame will try to rotate one degree, and quickly degenerate.
This is not bad or good, is just bad for this example.

In the code I simple commented out getting the matrix from the pelvis, and use a fix value.
teh it work fine.
however imaging this was a idle controller in which the pelvis rotates and as if rotate, the control trigger a limit and active a leg controller that lift some legs and move the to reach some other position, and keeps doing that as the system provide information.
what this tell me is that tree are many way to control a player, kind of like a state machine that activated pose controllers based on many inputs.
in eh example moving picking the player case what seems a malfunction since the target now is fixed by the body can go anywhere.
There are lot of unknown still.
if you sync you can now control the body orientation like before but not the offset position, not yet.

Code: Select all
   void UpdatePose()
   {
      //dMatrix rootMatrix(m_robot->m_effector->GetBodyMatrix());
      dMatrix xxxx(m_robot->m_effector->GetBodyMatrix());
      dMatrix rootMatrix(dGetIdentityMatrix());
      rootMatrix.m_posit = xxxx.m_posit;
      for (int i = 0; i < m_nodesCount; i++) {
         dHexapodNode* const node = m_poseArray[i].m_node;
         dMatrix poseMatrix (m_poseArray[i].m_rotation, m_poseArray[i].m_posit);
         dMatrix effectorMatrix(poseMatrix * rootMatrix);
         if (i == 0) {
            dMatrix offset (dPitchMatrix(m_robot->m_pitch) * dYawMatrix(m_robot->m_yaw)* dRollMatrix(m_robot->m_roll));
            effectorMatrix = offset * effectorMatrix;
         }
         node->m_effector->SetTargetMatrix(effectorMatrix);
      }
   }


I will try to make teh controller class that does this systematically starting from the basic pose generating and the concatenation modifiers nodes.
each node has one or more input vector, and output vector and operators, the we can make controller trees in which each do special stuff.

my goal, if to make the first one which is the pose generation that will produce just a desired pose, the there be a input modifier that will take the input of the pose generator and apply the user input.

then output of this modifier is the input to the enviromment modifirer which will take the current position and steer it to the input pose.
if this works, the result is that we should be able to modified the body orientation on any location on the map while still obeying user pick functionality. That's the idea anyway.
Julio Jerez
Moderator
Moderator
 
Posts: 11147
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: Inverse Dynamics Robot demo questions

Postby Julio Jerez » Sat Dec 30, 2017 7:09 pm

ok I added the ability of controlling both position and orientation.
if can go out of bound if you rattle it, but remember we do not have other controller that.

This is a step forward because now the creature a do what was doing before when the legs were constrained to fix position, now they constrained to contact points.

Now imagine the input is one generate by a pose generator that produce a walking basics animation,
the creature will be walking any way it want lean left, leaning right, lain low, with imposing attacking postures, and so on all for a simple basic walk. :shock: :o :) :D 8) :?: :!: :? :idea:
I guess some engines are better that others.
Julio Jerez
Moderator
Moderator
 
Posts: 11147
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

PreviousNext

Return to General Discussion

Who is online

Users browsing this forum: No registered users and 1 guest