# Revision history [back]

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.