How to get rid of LCP internal error s<=0, not s=0.0000 (ODE message 3)?
Hi, found some similar questions already, however no real answer yet.
I have an issue with LCP errors popping up, when my wheeled rover model (picture below or attached) is standing on the edge between two faces of the ground mesh.
The 4 wheels in the front (2 each side) are connected to the rocker arm via rotational joints. The rocker arms themselves are connected to the rover platform (top part) likewise. Everything else is built as one body (except the LIDAR on top, but that's connected via fixed joint). The rear spheres on the ground are a simplification of caster wheels and are modeled with 0 friction coefficient. Model weight is 250 kg (target value) distributed on the parts. The rover shall be driven via skid steer, which is already implemented as self-written plugin in gazebo (does the same thing as the usual gazebo plugin just with benefits, no influence)
The contacts displayed in the picture are all stable and do not flicker around. When the wheel of the rover is standing or rolling on the edge of the mesh (Ground mesh simplified to 2 triangles) a stream of LCP error messages pops up, each stating that the LCP solver was not able to - well - solve/converge.
Besides from the (in more complex maps) constant flow of error messages this doesn't seem to effect the simulation a lot. However in 2 cases (of, like, 60 or so) the simulation also crashes and places the rover model in the center of the map and refuses to do anything more. Which is why I want to get rid of the error messages in the correct way, not just ignoring them. Usually the messages end after the model had some time to settle on a new point, however when the axes of two wheels are orthogonal (view along -z-axis) to the edge, the model can be observed to never settle but throw these errors indefinitely. So my guess would be that the collision of the colliders on the one mesh triangle and those on the other side are contradicting each other and thus the constraints are keeping the solver from finding a solution.
What I have tried already:
(Hand-)Tuning CFM, ERP, globally and locally -> It has an effect on how big the error gets and can be used to tune, how fast the convergence error (s value) goes towards a positive value. However error could not be eliminated
Handtuning step size -> RTF down, error stays
Recomputing the inertias, for the complex parts with CAD support -> model behaves physically about correct, but didn't solve the error
Changing solver type to quick. -> Model falls through floor Other solver types (DART, bullet, simbody) have different issues (param tuning, version errors, flying rover, ...) that I didn't want to start solving unless I know that it would be necessary.
Running it on a faster PC -> well... no change but the RTF in simulation
Target is to run it as fast as possible ...
Are the collision shapes for the wheels (sphere and cylinder) meshes or simple shapes in the SDFormat file? If you're using meshes, I highly recommend using simple shapes instead.
The sdf type is cylinder/sphere, so i'm afraid they are as simple as can be already :/