Gazebo | Ignition | Community
Ask Your Question
0

How to get rid of LCP internal error s<=0, not s=0.0000 (ODE message 3)?

asked 2021-11-29 07:39:24 -0600

differentiatingDuck gravatar image

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.

screenshot gazebo

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.

screenshot error msgs

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:

  1. (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

  2. Handtuning step size -> RTF down, error stays

  3. Recomputing the inertias, for the complex parts with CAD support -> model behaves physically about correct, but didn't solve the error

  4. 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.

  5. Running it on a faster PC -> well... no change but the RTF in simulation

Target is to run it as fast as possible ... (more)

edit retag flag offensive close merge delete

Comments

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.

azeey gravatar imageazeey ( 2021-11-29 12:51:00 -0600 )edit

The sdf type is cylinder/sphere, so i'm afraid they are as simple as can be already :/

differentiatingDuck gravatar imagedifferentiatingDuck ( 2021-11-30 01:24:48 -0600 )edit

1 Answer

Sort by ยป oldest newest most voted
0

answered 2021-11-30 11:03:33 -0600

differentiatingDuck gravatar image

Compiling gazebo 11 from source and looking at the force values returned by the LCP solver made obvious, that the issue was within the 2nd friction direction. The differences between the more or less similar ground contacts showed, that the second friction direction was most certainly over-constrained.

output console

Short expl. of format: "[text]:" [index of constraint in lambda list] [text] [joint type 5=contact] [value along normal] [value in dir fdir1] [value in dir fdir2]

Changing slip2 within the wheel links to 1e-9 made the issue vanish. Even when running into obstacles on the map the error doesn't show any more.

Thanks for listening to my TED talk.

P.S.: Would not recommend building gazebo 11 from source just to solve such a problem since it takes time to understand the code. I only did so after some days of trying to solve the issue by hand tuning values without finding helpful coherence between parameters and my problem.

Greetings dd.

edit flag offensive delete link more
Login/Signup to Answer

Question Tools

1 follower

Stats

Asked: 2021-11-29 07:39:24 -0600

Seen: 54 times

Last updated: Nov 30 '21