Gazebo | Ignition | Community
Ask Your Question

Are mu and mu2 in the direction of the world frame, or collision frame?

asked 2016-01-23 15:11:25 -0600

updated 2016-01-23 15:41:49 -0600

I'm trying to do model some basic 4-wheel robots, and they having difficulty turning. My first attempt was to mess with <mu> and <mu2>, thinking that they would be in relative to the surface of the wheel. For instance, if my wheel is rotating around the Y axis, the <mu> would point along the tangent of rotation, and <mu2> would point perpendicular.

So, I did a little experiment and set <mu>1<mu> and <mu2>0.4<mu2> [which resulted in this behavior]

I'm providing constant turning force, yet it slips more and more as the robot aligns with the X axis

( What frame are these in? The best I could find is the ODE documentation here, which looks great doesn't help at all (x y or z are never referenced...)

edit retag flag offensive close merge delete


Hey Peter, did you every gain any insight into this? I've also noticed this behavior, and am working to track it down as well.

jwhite gravatar imagejwhite ( 2016-10-08 16:17:34 -0600 )edit

I'm pretty confident this is true, but I can't prove it and haven't debugged it. definitely comment here or give an answer if you confirm it somehow

Peter Mitrano gravatar imagePeter Mitrano ( 2016-10-09 18:37:19 -0600 )edit

I've created a scenario that seems to illustrate the issue. This video shows a cart sideways on a hill; friction holds it in place: This video shows the exact same cart and ramp, changed only to rotate them 90 degrees, and this time, the cart slides down hill: The world files in question are stick: slide:

jwhite gravatar imagejwhite ( 2016-10-11 20:48:32 -0600 )edit

I suspect I'm just fundamentally not understanding how the ODE engine works, particularly relative to this type of object. I've instrumented gazebo/gazebo/physics/ode/; the Collide() method, to try to gain more insight. The normal vector for the 'stick' case is (0,-.3,.95); the normal for the 'slide' case is (0.3,0.0.95). mu is friction 'perpendicular to the normal'. To some extent, that almost suggests that the mu2/mu distinction is essentially irrelevant.

jwhite gravatar imagejwhite ( 2016-10-11 20:58:28 -0600 )edit

1 Answer

Sort by ยป oldest newest most voted

answered 2016-10-14 07:30:47 -0600

jwhite gravatar image

I believe I can answer this question, at least for ODE, with what I've learned from studying and instrumenting the code. First, note that the answer to 'Explain Gazebo Friction Coeefficients mu and mu2' is probably the more 'correct' overall answer to this issue. As reported there, ODE officially documents mu/mu2 as having 'unspecified' direction. Of course, this is computer software, so nothing is truly unspecified; there must be some clear way these work. I started digging in the code to try to determine that.

The summary: if no fdir1 is provided, then there are two cases, based on the contact normal vector. If it's 'mostly' z, mu will end up being applied in a direction perpendicular to the normal, but in the y-z plane. For example, in the typical wheels on the ground situation, the contact normal is just a (0 0 1) vector. That then results in a mu vector of (0 -1 0). The mu2 vector is the cross; or (1 0 0) in our example. (The second case, where it is not mostly in z, results in mu being chosen in the x/y plane).

So, yes, you should find that any effect of mu/mu2 would appear to be in world coordinates, correlating to planes perpendicular to the collision normal. For wheels on a flat surface, that would break into x/y in world coordinates. The bottom line is that I don't think mu/mu2 are meant to be used to simulate the behavior of a tire. :-(.

I found the code to be illuminating and relatively easy to follow. In case it helps others, here are the bread crumbs I've used to come to this conclusion:

This block of code shows how Gazebo structures the contact collision joint for ODE.

In the case that fdir1 is not set, then we rely on the underlying ODE engine to compute the direction of friction, which appears to be mostly this code

Which shows that it eventually devolves into a call to dPlaneSpace which I think I've described, in my summary.

And, finally, I have successfully used an fdir1 of (1 0 0) to get my robot to drive somewhat more rationally. It's probably worth being aware of this bug, but I haven't found a case where that bug affects my robot yet.

edit flag offensive delete link more
Login/Signup to Answer

Question Tools

1 follower


Asked: 2016-01-23 15:11:25 -0600

Seen: 499 times

Last updated: Oct 14 '16