Refactoring joints

by **Julio Jerez** » Sun Jan 14, 2018 12:11 pm

you are right, Joe
but I rather have most joint sharing the base code, and will can always special case any joint that does can no be realize using that base.

I see how the 2 axis hinge (which I erroneously called universal) seem weaker. that the existing one, even of the angle are the same.
by I knwo why that is.

the reason is that in the engine the solver is not using a penalty that is proportional to the error, intead is use a constant velocity to reduce the error, and i count on tha the erro will be small.

whe yo uhave spinning objecet with skew inertia like the in he stand demo, the side torque generate is huge, the universal joint and specil code to deal with that to a point, but I di dno added that yet.
we can deal with that in case by case bases.
for now I want to get constiency in all joints.
for exampel in the new system all joint that spin along one axis, teh axis is x on eh child. tshi is no the case for all joints, but now it is for tha one I converted already.

this will brak almost all demos, inclding teh vehicle but I rather do that keeping making variance a of a joint for each functionality.
an example of this is that when I was doing the balancing character i want to make so joint fix, and sine the way to make a fix joint is by using a hinge, I have to actually change the demo because the joint do not share a common base class, and that's a lot of work.
it would be nice if by just setting so option on the base class teh joint can be manipulated.

these, I have converted so far, there few more still to do before I get to the ragdoll motor.

they are not fully done by, I will continue going from the simple to the more complex ones.
I guess this is another week delay until this is all completed.

by **Julio Jerez** » Mon Jan 15, 2018 10:18 am

one of the advantages is that right away we see many joint variance that become irrelevant.
since they do no do anythong special and can be made by disabling the proper row.
so far I removed

by **Julio Jerez** » Tue Jan 16, 2018 8:52 am

ok Joe I think I now added the code for recovering from gimbal lock,

I put the more challenging joint which is a ball an socked without limit or friction.
This is no true completlly becuase for teh 6dof to show limits the has to be anable so I made teh limit 1000 degree on each direction.
and the drictionm is the default angular drag that body has,
I believe these are acceptable conditions.

I spinned it around with the mouse on all direction, and seem stable with not weird rotations.
please check it out and see if this is ok for you.

note: if you pullet apart the still dismember but that because the pull code too strong, but I believe I can correct that as well, but that need some testing if I do no want to make teh mass matrix stiff.

anyway when you have time please try it out, and let me know what you think.

by **Julio Jerez** » Tue Jan 16, 2018 9:50 am

* still broken, I do not think there is a way to about the flipping
the only way is to impose the limited that the roll angle be less between +-90
the convetion I am using is matrix = pitch * roll * yaw
so the middle angle is the one that cause the flip each time is passed +-90 dregess.

here is trace of the angle as the get generated and you can see a flip where tow angle jump for 3.5 to about 43 degrees, that a big discontinuity. I have to get that working

teh onle way to make a full 360 in all three direction is by using the quaternion by that does not allow to do motor as funtion of angles.
thsi proble has lingring for years, and still hard to solve.

Note: oh, oh hold I forget one thing.
not sure is that will fix it by is the very thong I wrote to solve this problem and I forget to code it.

note: I committed the same test but with limit and the roll angle is +- 80 degrees, this seems ok to move on until I get to deal wit the issue, maybe we do no have to, since we can circumvent that problem by use clever ignition orientations.

by **JoeJ** » Tue Jan 16, 2018 12:41 pm

Julio Jerez wrote:teh onle way to make a full 360 in all three direction is by using the quaternion by that does not allow to do motor as funtion of angles.
thsi proble has lingring for years, and still hard to solve.

Note: oh, oh hold I forget one thing.
not sure is that will fix it by is the very thong I wrote to solve this problem and I forget to code it.

Could you handle it by making the free rotation motor an internal joint and handle it special also by IK?
So you could deal with axis and angle, which seems the only correct way to me so far. (And the only way that worked for me at all)

The user should be able to define the limits with a callback, and maybe another callback to set max torques, but you could handle the motor just internally. (Probably converting the limits to this single axis and angle motor as well to avoid extra limit rows.)

I tried to get my ragdoll working again - still needs work, but i saw that i use only one joint (like JoesRagdoll), also for hinges - i just project the target to the limit plane. I planned the same for the cone limits as well, sure it works nicely.

Edit: Did the update and i can see the flipping issues. But what you might not think about is that this configuration has a rectangular limit shape in spherical space, which is not very natural. (Just to point out - not really a big problem)

In my app while picking and dragging a body i can press a key and then the picking joint becomes static, so i can pick and drag again with the mouse from another angle while the static joint is still active. Until i press another key to remove all picking joints. This is quite nice to test things out - not as good as real hands, but better than having just one finger to poke things around

And my picking joint also can optionally constrain orientation (euler angles from sliders, also max torque slider). That stuff is really useful to test for robustness.

by **Julio Jerez** » Tue Jan 16, 2018 4:28 pm

Oh yes, good point, I think you are right the Cartesian decomposition will introduce and discontinuity each time I hit a corner. That explains why is in fine when there are no angle limit and flip bad when there are .

The ball and socket can address that by making a cone from teh ya and roll angle, it is eassy to do,
I will run the same test when I get that done. let us check again

In any case, the joint is already good for the Inverse dynamics because this is what we need for that, but let us see if we can make more stable, and we know the limitations more.

by **Julio Jerez** » Thu Jan 18, 2018 12:46 pm

hey Joe, going with the theme of making sure the basics are right, I added a flywheel test to see if the engine reproduce the correct effect.

in the pass I had the Gyro torques generated in the for dgBody class and it was applied the same way the vicious drag was, but that was a mistake because it only calculated the torque the first time derivative are calculated, intermediate derivatives where either ignoring it or re using the same value and the result was that the Gyro toque were either too weak or too strong, never the right amount. So I commented out the function on the body and moved to the Joint, so now is permanent at all time.

Now Newton can easily reproduce with accuracy these things. :mrgreen:

https://www.youtube.com/watch?v=XPUuF_dECVI

this is a good test to demonstrated that the joint are so far correct.

The next test is to make a joint where instead of a torque been applied to the z axis (this is what gravity does in this demo), a rotation equal to the one generated by the precesion is applied to the y axis and see if the joint generates the exact torque that the gravity is generating.
If this works the for any speed it should general the correct gyro torque.

by **Julio Jerez** » Thu Jan 18, 2018 3:59 pm

I traced the result and is quiet ramarble, how it conserves both angular momentum and angular energy

this is a remarkable result. you can see that the velocity around the y axis is accurate to three decimal places, after it stabilizes fire frames after it start.
you can see that the first frame the angular velocity is 100 r/s
and it still some momentum to covert it to the angular linear momentum.

also you can check see that both angular momentum and angular energy are conserve at all time.
and that is what Eulers equation predict.
you can see that the y and z value of eth angular momentum oscillates a little buy that was the problem I had that is the joint doing corrections. which before was doing only a the beginning of the update. No doing those corrections and the wheel wobble.
let us now see how this act when constraining joint angle angles.

finally I added three setting, one the spins at 100 r/s one that spin at 50 r/s and one that does no spins.
the 50 r/s process twice as fast than the 100 r/s :mrgreen:

you can see how inertia navigational systems works, basically the y axis is controlled by a servo motor, and the z axis is attached to sensor, so when they want to turn in space the simply spin the servo on the frame rotation is zero, because the sensors has set the thrusters to spin the entire ship at the same precessing rate. That will be one direction, the remarkable thing is that it works in 3d as well.

by **Julio Jerez** » Thu Jan 18, 2018 6:35 pm

and one more thing.
Notice that neither body loses it angular momentum ever, that another problem that was bothering me for a long time.
before joint always lose momentum even when the drag is to zero but now they swindle almost for ever
this is not necessarily a good thing, because we know that more complex arrangement will acquire angular energy because of the numerical linear integration, but we can control that with Drag and Joint stiffness.
It is better to work with something we know is right and tweak it, than use black magic to tune stuff and not be able to make predictions of the behavior. because some time would work and some other will not, with this if it does not works then we probably know why and how to control it.

by **JoeJ** » Fri Jan 19, 2018 1:34 pm

Sounds nice, so i did an update also in my own project.
There seems one bug introduced however, my ragdoll feet now sink into the kinematic platform bodies.
But no problem on the ground, which is a dynamic body with zero mass.
The version i used before had no such issues and dates back to a time before you renamed folders from 'core' to 'dgCore'.
(note that my ragdoll still uses default contacts.)
Maybe you remember any recent change that has not been applied to kinematic bodies.

: sinking.JPG (23.72 KiB) Viewed 6635 times

Edit: Bug presits after another update with the fix on spherical objects.
Feet stop after sinking in like in the picture, and it happens slowly (a second).

by **Julio Jerez** » Fri Jan 19, 2018 3:15 pm

I believe I know what that is, but let me ask first.
Are you moving the kinematic body and setting it velocity and angular velocity.

I am having a similar problem with the contact on the ground too. this is not easy to explain because
is not intuitive.
The problem is that by moving the calculation of velocity based accelerating to the Joint, not only gyros torque show up (which was done manually on the body as a external torque) but a whole bunch of other forces and torques also show up: Coriolis, Centripetal, Gyroscope and even more that has no name because mathematicians no longer give special names to forces that at the result of a partial derivatives.
In a nutshell the problem is that the contact joint is not doing the full derivative yet. I tried last night because if you look at the top. as nice as it look it is still wrong.
I you look at file ..\dgPhysics\dgContact.cpp line 350
and I switch to fix that other collision bug.

The reason is that at the contact point the normal acceleration is not the full weight of the body, it is the acceleration that the contact will have if the top flops.

here is how it works, the spin of the top generates side torques that cancel all torques on the body, is such way the angular momentum is preserved, therefore in the accent of torques at the contact point, the normal should be the full weight and therefore the should be stronger friction forces.
Instead what happen is that the acceleration is just a fraction of the weight and the friction is too weak to stop the horizontal translation.

so what happen is that the contact joint is try to zero out the contact velocity and the contact acceleration generated by external force and torque but is not considering the accelerations generated by change of direction of the velocity of the bodies. Again before this was added as external torque,.
I know is hard to understand or believe but that's the wonder for the law of physics
take a look at this video.
https://www.youtube.com/watch?v=EN38P8au1jQ&t=6s

you can see how by placing the flywheel on strategic locations he can manage some wheel to have zero weight.

when is all working right, I expect the top moving around a little in a circle only it loses enough energy that the friction force is suficient to keep it spinning in place without losing enegy or angular momentum.
As it stands now contact normal is a fraction of what should be so it keeps going on a circle and therefore losing kinetic energy slowly because of the kinetic friction until the motion degenerates and flop after few minutes.

wants we see that behavior then we take another look.

by **Julio Jerez** » Fri Jan 19, 2018 4:41 pm

I quickly try to get it going but still wrong.

I nwo has to write a small problem in paper where I knwo wh athe solution is a see where I am getting the result wrong.
if you sync and run the demo, if you uncomnet the lien wh ethe acceleratikon is calcuted and you run teh demo you will see that the tip of the top is buired on the ground, some how the acceleration is action the opposited.
the result it that when the top spins the reaction forces should be the weight of the top.
that a clue to check is the result in right.
anyway I will work on iot tomorrow.

by **Julio Jerez** » Fri Jan 19, 2018 7:14 pm

to make a test, I place the wheel with a 45 degree tilt and attacje to teh ball socket.

this is like a contact now, so we should be able to measure the acceleration that the is generation and compare then to what the contact is producing for the top, the should be identical (with in numerical tolerance) if they are not stronger than the friction.
so this is a good setup to see what is wrong in the calculation of the contact derivative.

there accelertion shoudl be 0 on the horziontal axis, and gravity on the vertical axis.
this is becacuse the objt is in equilibrium, the mean zero net torque and zero net force.

by **JoeJ** » Sat Jan 20, 2018 10:09 am

Julio Jerez wrote:I believe I know what that is, but let me ask first.
Are you moving the kinematic body and setting it velocity and angular velocity.

No, i disabled platform movement and do not touch velocity or matrix. Also the ragdoll does not move.

I tried to put a simple box without any joints on the platform and it sinks as well, allthough slower and it stops at less penetration.

by **Julio Jerez** » Sat Jan 20, 2018 10:39 am

oh that sound like a different bug them.
let me clear, you say that a dynamics object on top of a kinematic one will sink into it slowly?

that mean I broke something something with the chnges.

I will see if I can regrate that demo, to test it first.

Refactoring joints

Re: Self balancing biped

Re: Self balancing biped

Re: Self balancing biped

Re: Self balancing biped

Re: Self balancing biped

Re: Self balancing biped

Re: Self balancing biped

Re: Self balancing biped

Re: Self balancing biped

Re: Self balancing biped

Re: Self balancing biped

Re: Self balancing biped

Re: Self balancing biped

Re: Self balancing biped

Re: Self balancing biped

Who is online