Gazebo | Ignition | Community
Ask Your Question

jwhite's profile - activity

2017-10-16 12:45:11 -0600 received badge  Favorite Question (source)
2017-01-09 11:10:13 -0600 received badge  Famous Question (source)
2016-10-21 09:49:27 -0600 received badge  Nice Answer (source)
2016-10-14 15:36:29 -0600 received badge  Necromancer (source)
2016-10-14 15:36:29 -0600 received badge  Teacher (source)
2016-10-14 07:30:47 -0600 answered a question Are mu and mu2 in the direction of the world frame, or collision frame?

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.

2016-10-14 07:10:27 -0600 received badge  Enthusiast
2016-10-11 20:58:28 -0600 commented question Are mu and mu2 in the direction of the world frame, or collision frame?

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.

2016-10-11 20:48:32 -0600 commented question Are mu and mu2 in the direction of the world frame, or collision frame?

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:

2016-10-08 16:17:34 -0600 commented question Are mu and mu2 in the direction of the world frame, or collision frame?

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.

2016-10-08 15:53:49 -0600 commented answer How to set friction direction in gazebo

I believe there is a fairly obvious bug introduced in 2014; I've added more details in the issue report.

2016-09-30 06:35:51 -0600 received badge  Notable Question (source)
2016-09-28 18:19:10 -0600 received badge  Popular Question (source)
2016-09-28 18:15:37 -0600 commented answer Exploding robot, trying to learn how to diagnose

1) Inertia was critical; that has made a huge difference. Ironically, I had a nicely generated inertia for the wheels, generated by the SolidWorks plugin, which I had removed as an experiment in attacking friction. 2) How are you seeing that? 3) I set self_collide to 0 and that made no difference. (And, actually, I'm not seeing self_collide work; the idea is that the battery keeps the arm from going down, but it's not actually happening. But that's a different problem...). Thanks!

2016-09-28 01:06:10 -0600 received badge  Student (source)
2016-09-27 15:56:00 -0600 asked a question Exploding robot, trying to learn how to diagnose

I'm a mentor with a high school robotics team. FIRST has put together a Gazebo based tool kit to make it possible to model competition robots using Gazebo. Our team had a pretty complex robot, so I thought it would be an excellent test and learning tool to get our robot up and operational.

I've fought my way through a fair number of challenges, with more to go, but I have one recurring challenge that I cannot diagnose: my robot will, with some frequency, simply take off; bouncing high into the sky, going akimbo. And the way I fix it always seems strange; I tweak the intake roller geometry, and it stops, or I rebuild my chassis to be one piece, instead of three.

This happens at odd times, particularly as I operate the robot. However, I've got a fixed test case that I think shows the problem, and I'm hoping someone can help me to understand how to diagnose this problem.

I've placed all the files I believe to be relevant here:

Recently, I have added two geometric 'ballast' shapes. And now, when I place the robot on the world, I get a nice consistent failure. That is, the robot always starts 5-10 cm off the world plane, and when I place it, it drops. Normally, it settles in nicely. But in the failure mode, it goes crazy. Currently, with the right ballast link in place, the problem occurs. If I move that ballast, the drop doesn't cause it, but operating the robot will.

In that folder, there is an explosion movie showing the moment of impact, when the robot lands and I step through the resulting bounce. I cannot figure out any mechanism to explain to me exactly what is going on. Another movie shows a typical 'operating' launch system (that one predates the ballast).

The model file is in robots/Sideshot.sdf. It is easy to reproduce the problem; simply insert Sideshot into the default world and watch it fly :-/.

I would really appreciate insight and guidance; I'd particularly appreciate feedback on how to troubleshoot this myself.