Friction disregarding surface friction coefficients

[TheUncivil]

Environment

• Ubuntu 22.04
• Running DART in Ignition Gazebo 6.12

Expected Behavior

When colliding two objects, the simulator should take the friction coefficients of both into account. According to gazebo documentation, it should use the lower friction coefficient of the two.

Current Behavior

The simulator only seems to use the friction coefficient of the moving object, while the surface along which it is moving is disregarded.

Elaboration

I ran into this issue while attempting to model an AGV moving through an environment where the floor might have varying surface friction as a result of stains or dirt. I spent some time verifying this behavior, by sliding a few cubes along a sloped plane and changing the friction of both the cubes and the plane, as detailed below.

Note that the planes are coloured red and green. The red part of the plane has a friction coefficient of 20 and the green part has a friction coefficient of 0.2. The middle part of the slope has both overlapping, because I wanted to see how the simulator would handle that.

GIF 1: The cubes have equal friction coefficients of 1. Despite the varying friction coefficient of the slope beneath them, they all move exactly the same.

GIF 2: The cubes have been assigned different values for friction, from left to right: 20, 1, and 0.2. This affects their movement as would be expected if the friction of the slope was the same everywhere. However, that is not the case.

I also briefly experimented with driving my AGV around on a surface with a friction coefficient of 0, which I did not record. The AGV was able to move normally on a frictionless surface, contrary to expectations. When I set the friction coefficient of its wheels to 0, however, the AGV was unable to move due to the complete absence of grip, which aligns with my expectations.

I've also tried using Bullet to run this simulation, and Bullet does not have this issue (but is unsuitable for my project due to other limitations). Therefore, I believe the issue lies with DART or its implementation into Gazebo.

[scpeters]

I'm not sure what I would expect to happen when colliding with two overlapping planes. Do you have an SDFormat world file to reproduce this behavior?

I would consider moving this bug report to gz-physics until we can confirm that it is an issue with dartsim

[mxgrey]

I feel that from a mathematical point of view this falls into some kind of "undefined behavior" territory because physically speaking this isn't a thing that can happen in reality. In physical reality the object can only be in contact with one plane.

I think this falls on the person setting up the simulation environment to partition these two overlapping planes into three separate planes and assign each of those planes the appropriate friction parameters.

[TheUncivil]

I have SDFormat files I used to test this, how do I upload them here?

I've also reported this bug to gazebo, but haven't yet received a response from them.

Behaviour surrounding overlapping planes really isn't much of a concern for me, I did it here because I was curious to see what would happen. I agree that this should be handled by whoever set up the simulation.

[scpeters]

I feel that from a mathematical point of view this falls into some kind of "undefined behavior" territory because physically speaking this isn't a thing that can happen in reality. In physical reality the object can only be in contact with one plane.

I think this falls on the person setting up the simulation environment to partition these two overlapping planes into three separate planes and assign each of those planes the appropriate friction parameters.

I have SDFormat files I used to test this, how do I upload them here?

Behaviour surrounding overlapping planes really isn't much of a concern for me, I did it here because I was curious to see what would happen. I agree that this should be handled by whoever set up the simulation.

you should be able to attach the files to this issue by following the GitHub documentation, but I'm guessing that we will close this issue as won't fix and advise folks to set up the SDFormat file with multiple non-overlapping boxes / planes