weak btHingeConstraint - axes not matching

[Gickl]

Hi,

i have some btHingeConstraints with vertical axes. if for example one body is static and the other side is the beginning of a leg, the axes are not matching as could be seen in the picture. the yellow and the red line are the axes defined for the rigid bodies.

i adapted the weight of the dynamic body and played with the damping and the relaxation, softness and bias factor of the constraint but i think it's only for rotational aspects. so what can i do to get the axes matched all the time?

Thanks in advance
Gickl

[Basroil]

I'm going　to guess three things about your hexapod simulation here:

1) Those are RX-28/MX-28 servos scaled up to 1 unit
2) The gravity was compensated by scaling to 98 (rather than 9.
3) Iterations are left at default

If those are matched, then it's 100% identical to an issue i had. Basically, PGS implementation in Bullet is great for simple things, but horrible for long joint chains and powered joints. You can offset that issue though by increasing the number of iterations (joint iteration override is the best in terms of speed for accuracy gain), well above the default of 10. I personally use 50+ iterations in conjunction with faster physics frame-rate, but there's possibly other, more stable solutions too.

[Gickl]

yes the objects are scaled with the factor 10 and the iterations are left at default. but gravity is still 9.8!

i increased the number of iterations with constraint->setOverrideNumSolverIterations(100);, was that what you meant?

now the simulation is "better" but although not working as it should. both the horizontal and vertical constraints are very weak and the objects drift away from each other...it is not even possible to get the hexapod to stand still on the ground.
i'm not sure if it is possible in any way to simulate a hexapod with bullet or if it is pointless trying to get it to work. What do you mean?

[Basroil]

It's really difficult to know exactly what's going on in your specific case without code. The joint iteration increase is good, but you also need to increase simulation frequency if the joints seem weak. I've actually been researching that issue for a while, and it's quite annoying as there's nothing that jumps out in the internal code that would make everything so weak.

On top of iterations, try a simulation frequency of ~200Hz, I find that that tends to improve motor strength while keeping down ill effects from ERP calculations.

[Gickl]

at the moment i scale the whole scene with the factor 1000. that was the only way to get the joints strong enough.
so now it is almost working perfectly

but when i turn one leg down for example so that the body is raised the whole robot starts rotating (without cause) no matter what collision shape i use for the (flat) ground (btBvhTriangleMeshShape or btBoxShape). for the robot i just use box shapes and spheres for the feet, so it's nothing special...do you have any idea what causes the problem?

[Basroil]

I've had that issue with a snake like robot with AX12 motors (but not a quadruped ), so there's definitely something in the code. You can always try to redo the simulation code, perhaps there's some random glitch there.

[Gickl]

i just found out, that i did not calculate friction inside a custom callback that i use to adjust internal edges....so now it is working without sliding around!