Joints stiffness

[Sweenie]

Oh, it's much easier to steer now

The treads slide off when turning though as you said.
Couldn't you just add a constraint to the links preventing them from moving sideways(relative to the chassis that is)?

Or if your sticky contact is working maybe that could be used to simulate steering pins on the powered wheels? That is, as soon as the front and rear wheel comes in contact with a link plate, create a sticky contact that "glues" them together.
Wait, scratch the last idea, that won't work, how would the simulation know when to delete the contact...

[Julio Jerez]

Or if your sticky contact is working maybe that could be used to simulate steering pins on the powered wheels? That is, as soon as the front and rear wheel comes in contact with a link plate, create a sticky contact that "glues" them together.
Wait, scratch the last idea, that won't work, how would the simulation know when to delete the contact...

you have the same ide I had, and yes that won't work.
I tried few things, it I now that easy, because it has to attack each link to the main body,
The way real tanks do it is that the tracks and the tire has some kind a grub that fix into each other

what I am thinking to do is to make the main body a compound collision and place an invisible thin plank on each side that to can serve as fenders and in the contact callback I make the contact frictionless.
I believe that will do it, but I would not be surprised of some else comes up after that.
I will also remove the little suspension, and make the while move up and down.
and I believe that will make robust enough for a demo.

[godlike]

(checked out the demo yesterday and the tank behaves and looks amazingly good, if you exclude the fact that the tracks go out in some turns. Great job!)

[Julio Jerez]

I checked in the model with the fender geometry to protect the thread for falling off the track.
Those planks will be invisible and will only have friction less contact with the track.

this will by the a way to mode the grubs between link ate Cog of real tracks vehicles. It is no far from reality.

Because If I was going to model that realistically I would make each Cog a compound wheel shape, made of two pare ally shape to model the female part, and each link also a compound with the male grub in the center.
I check it is so that you can see how it the internal will be.

[Julio Jerez]

Bingo !!
Guys please take it for a spin.

Now I only need to finish the upper part

[Sweenie]

It's awesome!

I think you will need a fender on the inside of the treads as well though, i managed to wrap one tread around the chassis, or maybe if the tread was a little bit tighter this won't happen...

[Julio Jerez]

yes you are right.
I run for awhile over the logs, and it behaved nice so I checked it in, then as soon as I checked it in, in next test, I got the thread just the way you showed in the picture. yes it need fenders in the inside as well
Also I think the fenders are good for prevent the Logs from getting inside the treads. I managed to get that too. I will let the fender collision on with invisible mesh.

Remember this is jus a stress test to see how much the joint solver can be pushes.
My guess that the people in Sketcuopt is the use this can mu amassing stuff. because the play at a much higher fps.

[Julio Jerez]

double fender is in now,
I was able to drag it with the mouse for the first time, but not too strong (it is my baby)
I am sure it will brake if any one want to.
however I claim the force that brake this simulations will brae any real vehicle much easier.

Let us see what else we find next.

[JoeJ]

That's not only impressive, but real fun to drive now

If you have a cheap way to detect the tracks are in trouble (because a bad guy dragged them with the mouse), you could add a callback so the user can break the joints in that case.

[Julio Jerez]

Ok I think I now have a demo that is good enough to show what's new in 3.14
the demo is not for game stuff, is just to show the stability and versatility of the engine.

Yes adding some heuristic that can brakes the thread is a good copout, but I am counting that the people that will see the demo will now what that demo is about. I am sure there will be the expert that will demonstrate that he can brake it, but I am no worry about those anymore. Those are trolls that any zero positive contribution.

I am now going to finish part tow of the solve, the unilateral row, when the row are present the solver become soft, and that turn out to be a bigger problem than I though it could be. and we can no have that. fortunately it is solvable problem but I how to go again over the derivation of the math again.
Later I will make a video.

[JoeJ]

I just figured out the primary reason why hard joints did not seem to work for my ragdoll.
The old controller i use does not calculate maximum possible acceleartion, it simply calculates ankle torque from error times user given gain value.
Simply reducing that gain from 1500 to 150 and balancing works with hard joints now

Still, everything looks too stiff - ragdoll can not keep resting contact on moving platforms well,
but it's stable now and a good test case to improve the controller to work with both soft and hard joints...

Guess there is a lot of work left until i can go to what i'd really like to do.
My real problem is i can't move com fast enough beween both feet to start walking.
This is really the hardest problem - i still don't know why humans can do this so fast.
Strange the problem is not mentioned in any robotics paper i have read.
I'm sure walking and running becomes very easy when this is solved.

[Julio Jerez]

I believe you are fighting with a bug in newton. This week I will complete the part that handle unilateral rows.
I thought that I could solve that by doing pair by pair iterations, but this is not the case.
Basically the problem is this.

The iterative solver drive the acceleration between to bodies connected by a joint to zero.
These method of solving linear systems are called stationary because the effect is localized to the row and column that they affect. (Guass sidle, Jackobi, Lemkel, Simplex and Danzig) all these methods are stationary.
The exact solver is a line search method, this is on each step it computed a vector the update all the variable a the same time. all of the Gradient descend method fall on the category.

Line search methods are very fast but they do not work well with unilateral joints. if a unilateral joint break a limit, then that limit has to be removed and mass matrix must be restarted.

My mistake is that I am using the second method to solve a subset of joints and if they have unilateral joint, I am fixing the error bay calling the iterative method and I am never restarting the mass matrix.
what I have to do is that I have to write a way to incrementally reconstruct the mass matrix.
The is on the code here

Code: Select all

dgFloat32 dgSkeletonContainer::CalculateJointForce (dgJointInfo* const jointInfoArray, const dgBodyInfo* const bodyArray, dgJacobian* const internalForces, dgJacobianMatrixElement* const matrixRow) const
{
   dgFloat32 retAccel = CalculateJointAccel(jointInfoArray, internalForces, matrixRow);
   dgFloat32 jointAccel = retAccel;
   for (int i = 0; (i < 4) && (jointAccel > dgFloat32 (1.0e-2f)); i ++) {
      SolveFoward ();
      SolveBackward ();
      UpdateForces(jointInfoArray, internalForces, matrixRow);
//jointAccel = CalculateJointAccel(jointInfoArray, internalForces, matrixRow);
//if (jointAccel > 1.0){
//dgAssert (0);
//dgTrace (("%f\n", jointAccel));
//}
      SolveUnilaterals (jointInfoArray, bodyArray, internalForces, matrixRow);

// this eventually converge to zero but too slow, I need to  reconstruct the mass matrix by removing the row and column the that violate the constrain, this is solvable but not a trivail problem
      jointAccel = CalculateJointAccel(jointInfoArray, internalForces, matrixRow);
   }
   return retAccel;
}

Give this week until I get that working, In the Tank demo, my work around was to made the joint bilateral when they are not violating the limit, but as soon as the do, the system show a unwanted Jerk. It took me a long time to figure that out.

If you look a the the code in lat submission I changed all the limit to a Huge number fo all custom joint.

[Sweenie]

Give this week until I get that working, In the Tank demo, my work around was to made the joint bilateral when they are not violating the limit, but as soon as the do, the system show a unwanted Jerk. It took me a long time to figure that out.

Is that what can be seen on the crane(palette)? It's twitching a little bit, that is, it's slowly raises a few inches then fall down and repeats.

[Julio Jerez]

It may be part for the problem yes, but I do not think so. I think It may be a problem with the special actuator a joint because. if you look carefully you will see that it is not a random jitter, it is a force that builds up and them pops with a periodic repetitive pattern. I am guessing it is a bug with one of the actuators joints that I changed a few day ago.

After I spent time last weekend debugging it, I decided to give some time and fix the solver bug before I go over the vehicle the demo again. one of the reasons I am confident it one of the actuator joints and not the solver is that when I change the joints for the twitch goes away.

Later for now I will remove the crane mechanism until I get the solver fixed the I will revisit the demo again.

[Julio Jerez]

Ok Joe I believe I now have the bug fixed. Later I can add some optimization because right now I opted for building the full mass matrix instead of doing and incremental reconstructions.
all skeletal joints are support to be strong.
I did not test much, it may have some bug still

@Sweenie it does not fixes the bug the Tank demo, but I suspected that. The seem to mean that the bug is in one of the joints.

I will test by hacking the joint and making the to act as fix joints until I find with one it is.

The model is made of three skeletal, the vehicle and the two threads, I thought the problem might be there, but that can be rule out because when removing the thread the bug is still there.

the U tough I might be the suspensions because thee are very stiff, by is not that either because removing the tire and the bug is still there.
any one of these cause would be a huge problem there solver, so is good news is not that.

so I am pretty sure it must be a bug in one or more joint, more that one because the copy and paste.
I will debug tonight again.

I was trying to pick one of the piece of wood, but the vehicle is such a poor model of a real life tool
that is hard as hell to get in position.
Now I know why heavy machinery do not have suspensions.
But the suspension are cool.