Max rows limit of 8 in dgBilateralConstraint.h

[JoeJ]

//#define DG_BILATERAL_CONTRAINT_DOF 8
#define DG_BILATERAL_CONTRAINT_DOF 10

Hi Julio,

For the powered cone twist joint i need at least 9 rows. No way to go below that.
For the powered hinge i currently use 10 rows (not yet optimized for row count).
I also tried a super joint with both powered rotation and translation... not stable for ragdoll but maybe useable for low body count objects - 10 rows.

Can you increase your limit?
If you have a good reason for the limit - would it make sense to decouple limiting from powering?
Meaning 2 Joints for each pair of bodies, but less rows per joint... i guess it's no difference.


EDIT:
I've reserved one row more to experiment with the joints, so you can subtract 1 from my numbers and i'd be happy with a limit of 9.

[Julio Jerez]

Oh, not no reason other than saving memory, that value was 32, but I changed to 8, in fact it should be 6
but for joint with non bilateral constraint like contacts and some special one like the vehicle joint that I had in core 200 it can be more than 6.

even if it was set it to 8 the code should deal with count larger that 8, by allocation the memory
are you guetting this assert?

file : ...\newton-dynamics\coreLibrary_300\source\newton\NewtonClass.cpp

Code: Select all

NewtonUserJoint::NewtonUserJoint (dgWorld* world, dgInt32 maxDof, NewtonUserBilateralCallback callback, NewtonUserBilateralGetInfoCallback getInfo, dgBody *dyn0, dgBody *dyn1)
   :dgUserConstraint (world, dyn0, dyn1, 1)
{
   m_rows = 0;
   m_maxDOF = dgUnsigned8(maxDof);
   m_jacobianFnt = callback;
   m_getInfoCallback = getInfo;

   dgAssert (world);
   m_forceArray = m_jointForce;
   if (m_maxDOF > DG_BILATERAL_CONTRAINT_DOF) {
      dgAssert (0);
      m_forceArray = (dgForceImpactPair*) world->GetAllocator()->Malloc (dgInt32 (m_maxDOF * sizeof (dgForceImpactPair)));
   }
   memset (m_forceArray, 0, m_maxDOF * sizeof (dgFloat32));
}

try comment out the assert and see if it works.

The reason I did that is that I am adding an extra information on the reported force.
Newton repost the force on each contact, but the force is a bad metric to use for deciding a some effect.

for example for deciding if an impact was strong enough to break collision, a force gives inconsistent information
however the strongest impulse is more in direct correlation with the impact. for that I nee to add and extra column of floats to each contact, but contact are joints, so each joint also get that information.
as that increases that memory foot print of the constraint class, but I realize that bilateral joint do no really need 32 row when almost all of then only use 6 or less.

so I change that to 8,

I chek in the code without th assert please see if if work before we change the limit form 8 to something higher.

[Julio Jerez]

I am curios as to how can you make a hinge with more than restrict movement alone more than 6 degree of freedom.

I believe that leads to a Jacobian mass matrix witch will have a singular comatrix, meaning that there will be one of more column that will be a linear combination of some other column.

I newton 1.xx I have a singular value decimation test that was used to remove any row that made a block matrix ill conditioned. I have it set that Is the condition number of a sub matrix was 200 of higher then is called that function to removed
the worse row, this made the engine very slow, but in return there is not nee to jilter contacts,

for core 200 and up I removed that and instead the contact pruner is responsible for filtering contacts , but that does no do anything for joints.
Maybe after I am done with the thong I am doing now, I can add that function to the use joint so that you can call to see if the matrix is ill condition. kind of like a debug code for joints.

[JoeJ]

For hinge i have 3 linear rows for point to point,
1 angular row to limit twist,
1 angluar row for a plane constraint
1 angular row to limit hinge angle
1 angular row for powering
--------
7 rows... oops sorry! (If i remember right you need one row less for your hinge, so i may change that...)

Same for the experimental super joint:
3 powered angular rows,
3 powered linear rows
1 linear row for distance limit
-----
7 rows

So my request was result of lazy constructor updating,
i reserved enough rows to play around, but did not fix that number afterwards.
Sorry and forget about it

Also, for powered ragdoll i submit only rows if their limit is violated,
meaning that powering will try to avoid hurting limits, so in practice >90% of the time
only 6 rows will be submitted, for both hinge and cone twist.
My ik solver uses a threshold to keep the power target some degrees away from the limits in any case.

Maybe after I am done with the thong I am doing now, I can add that function to the use joint so that you can call to see if the matrix is ill condition. kind of like a debug code for joints.

What i'd put above that on my personal wish list is your powered rotation joint idea.
I think i'll get soon the first real problem with my 3 angle technique.
At the moment i'm implementig a ankle controller based on research from robotics guys.
The idea is to control the com position by moving the 'center of pressure' constrained inside the foot support polygon.
I tried this on a simple two body inverted pendulum and it works very well - i can move com with maximum speed while keeping foot flat on the floor.

The problem is, to move the center of pressure, i need to set joint targets that will lead to a precise amount of torque.
My model works perfect with a stiff powered hinge, but the 3 angles cone twist starts to jitter badly using that.
The cone twist i use for ragdoll has to use low stiffness to stay stable, and i can't use hinge for ankles.
Maybe i can simply overpower the outpot from control algorithm and get good results.
I'll see but first i need to fix my math for a more complex model - i have trouble with joint - foot com offset and mass ratio other than 1:1...

[Julio Jerez]

basically now there is a class called CustomArcticulatedTransformManager.h
what is does is that for articulated structures that but nature have a forest structure, (ex articulated creatures like humans or vehicles)
you can use a trick based on teh secudn part of the Featherstone algorithm.

basically you let the general solver calculate all the acceleration and velocities of the contraction. Then you can do two passes.
The first pass is bottom up calculating the relative velocity, angular velocity and local position and orientation of each child body relative to the parent body.
while doing that, for each child body the code project the velocity and position to the local axis that define the joint and removinmg the small error generate by the general solver.

The in the second pass is top down, and what is does is that for each child, it calculates the new velocity, angular velocity and matrix of each child body based of the global velocity position, velocity and angular velocity of the paren an dthe local values calculated on the previous pass.
since all values are local, all child will move to the new project position an carry with him all of it childrem.
As long as the errors are small in each step, then the calculation is almost 100% correct.
The reason is that in each step small error are removed, and are never accumulated.

when not doing that error from previous steps are integrated to the next step, and they get amplified,
with this new method in each step errors are so small that they can removed by projection,
therefore each step does not integrate the error from the previous step.

this method differ from the Featherstone in that Featherstone calculates the acceleration of each body in local space bycalcation the apparent inertia matrix of each child body as seen from the parent. Bu tehi sis a diffclt problem an dyou need to write specail code for eact tyope of jopint.
also these method does not deal with limited constraints since the calculation of the aparent inertia matyrix presume continues and smooth partial derivateives. Plasth even gerrin teh parical derivative fro the different joints type is hard.

For my method we have a general solver that can calculated with very good approximation, the acceleration in global space,
all we need to do is rotate it to the parent body, and sinc eteh secudn pass of Fethresot in teh kenematic part, then the teh problem is solve quiet nicelly.

The two procedures are equivalent and I beleiev that I can even be prove it mathematically for articulated strutures with no loops.

To me my metod is mor epefulf an dmore flexible, because it is is not limited to articulation without loops,
in those cases you just do, is not add loop joint as connection as articulation manager.
I made a demo that play a forklift, it has very high mass ratios, and it is rock solid and can lift heavy object.

there only problem with this is that each joint has to have its own method for reducing the error,
and it is not that easy to get it right the first time, but much simpelr proble than writing Fethreatons paracial derivatoves,
so far I handle Hinges, slider and universal. I will also added for eth 6DOF joint.

Please check that out, I believe it is the solution to the soft joint problem you has.

[JoeJ]

Ah yes, i understand much better now. Sounds like it really is solution for those problems.
I'll finish controller stuff first and then check it out...

Note that in forklift demo i can not steer vehicle or lift (WASD moves camera), and there is no object to lift up. Work in progress?

Convex shatter is awesome

[Julio Jerez]

yes I have not added the controlled code yet,
I will do soon alone with some object to play around.

if you wnat to see hwo it work you can synk to teh Ogre plugin, there is a exe that shoe teh controll and every thong.
basically if you p[lay it it feel like it was doen usen teh exact solver, in fact it fell more robust that teh exact solve.
and it like very heavy loads with the palletes.

[JoeJ]

Julio, the Articulated Joints demo is really fantastic!
That's the kind of physics that allow real interactive worlds - great work!

For my own work, the missing stiffness i've talked about above turned not out to be a problem, ankle controller works very good for ragdoll.
The remaining small problem is to make hip and ankle controller work together well.
Meaning i'll focus on finishing that AI stuff to get the walking ragdoll done with current physics.
But then i'll definitely learn to use this new functionality

[Julio Jerez]

Oh I am glad you like it, until now I only added the post error correction to three joints, Hinge, Universal and slider.
later I will added to the ball and socket, and the newer 6dof that will be based on small angular decomposition.

I will also later add a matrix error estimator for joint configuration.

This is a debug tool that given and array of bodies and joint, can calculated the general stability, of the system and will suggest which joint can be corrected and witch masses can be adjusted to improve ability.

Newton 1.xx had that but it has it for real time and it was only for block diagonal sub matrices, but that was very slow, and most people did no really inserted how I worked, so I took it out.
In newton 1.00 was used to filter bad contacts, no wI will added to fix joint, bodies contractions.

[Julio Jerez]

when I try to drive in first person, it is very hard to see where you are.

Wouldn't it be cool to have a virtual reality setup whe you can actually have a sence of 3d orientation?
just wishfull thinking

[JoeJ]

Back on topic, i still did not update my row count on joint construction (creating with 10 rows, but using only 6 or 7).
My app behaved like corrupting newton memory for unknown reasons, it seemed that physics are buggy in general.
After i have fixed the row count, everything is ok again.

You should add an assert or return 0 if someone tries to create a joint with too much rows.
I think that was in in the past, but actually there is no warning about it - maybe it's broken.

EDIT:
Counting the rows for my powered cone twist, there i have:
3 linear for P2P, 2 angular for cone and twist, 3 powered angular.
So i can confirm max 8 rows is good.
It might be worth to try to fuse powering and limiting to get down to 6 rows, but because the limits are rarely violated in practice id on't expect a real gain.

[Julio Jerez]

Like I said before a rigid body can only have 6 degrees of freedom,
a joint connect tow bodies by force the tow of the to share some of the freedom, by you can only cancel unto 6 of them regardless of ho clave you are passing them.

a Joint matrix is converted to a linear matrix, that can only be unto 6 x 6
when you pass more than 6 dof, that matrix become larger, and the solve will try to inverted it as if it was did not have any row that are linear combination of another row.

but in reality there will be some row that is fact are linear combination and three result will be that you get a bogus solution.
there reason you get a bogus solution instead of an explosion, is that the iterative solver only perform a fix number of iterations and terminate with whatever approximation of the solution found at that point.
but the solution will be very poor because the a n x n matrix with linear combination with k rows that are linear combination is in fact a matrix of rank (n - k) x (n - k)

such linear system, have a very poor convergence rate.

My recommendations is tat you need to make your joint with upto 6 dof. if you want more than that the some DOG must be limited by friction limit, so that the solver knows how to remove them from the matrix when the friction limit is reached.
do not cheat and pass huge friction limit, because it will not work.

[JoeJ]

Ok, i'm worried the 3 angle problem will make it problematic for my kind of 6dof,
because i build the constraint space orientation different for limits and powering.
But i'll add it on todo list below the walking.

The Hinge should be easy, but there's one detail that i'm not sure about.
Say it is currently at 20 degrees,
but the swing limit should force it to go back to 15 degrees,
and the powering target is 10 degrees.

At the moment i use two rows for that (you do that too for your hinge, but would it be possible to use just one?) :

Code: Select all

// swing limit
NewtonUserJointAddAngularRow (joint, -5, sharedAxis);
NewtonUserJointSetRowMaximumFriction (joint, 0.0f); // allow to enter swing range

// powering
NewtonUserJointAddAngularRow (joint, 0.0f, sharedAxis);
NewtonUserJointSetRowAcceleration (joint, AccelFrom20To10);
NewtonUserJointSetRowMinimumFriction (joint, -poweringFriction);
NewtonUserJointSetRowMaximumFriction (joint,  poweringFriction);


would it be correct to replace this with:

Code: Select all

// limit and powering
NewtonUserJointAddAngularRow (joint, -5, sharedAxis);
NewtonUserJointSetRowAcceleration (joint, AccelFrom20To10);
NewtonUserJointSetRowMinimumFriction (joint, -poweringFriction);
NewtonUserJointSetRowMaximumFriction (joint, 0.0f); // allow to enter swing range


Is it as easy as that?
I was believing it is not legal to set relativeAngle AND RowAcceleration for one row.
Should i calculate acceleration from 15 to 10 instead from 20 to 10, because relativeAngle already moves it to 15?

And finally, will setting minFriction to the powering constant make the limit as weak as the powering?
If so, would it make sense to lerp between limit and powering friction constants in relation to the angles?