# Idle robot drifts due to tilted inertia

Hi, I have a turtlebot 2 with an arm and a superstructure with two 3D cameras. The arm is of course mobile, so gazebo calculates its own inertia. But the superstructure is not, and so Gazebo join all the weights (reasonably calculated, as far as I can tell) together with the base, hence the tilted inertia box. The following video makes all much clearer:

VIDEO

The kobuki base alone doesn't drift, so it makes sense that the tilted inertia causes the drift. Of course I can hack my URDF with a weightless superstructure, but I wanted to fix this in a more realistic way. I tried all I can think about, and all failed:

• use the generic diff-drive gazebo plugin (byt default I use the kobuki one)
• set force and effort limit to 0 in the plugin.
• adding friction to the wheel joints only works when I send non-zero velocity commands to the robot (see video at the end)
• setting damping makes gazebo crash and/or freeze

btw, looks like gazebo ignores these 2 parameters if set for the joints in the URDF (I added

<joint_properties damping="10000000.0" friction="10000000000.0"/>


to each joint). But when I check the values within the gazebo plugin, both are 0. So I tried to set directly in the code (works for friction, crashes with damping)

I have found other 2 similar questions, so looks like an old issue. But nothing there helped me:

I'm using gazebo 9.14.0 with melodic. My URDF is dispersed in 3 repos, so no easy to follow. Here's kobuki base xacro file, but I did some local modifications. The whole URDF (quite big)

UPDATE Following @nlamprian question (thanks!), I check if the wheels actually move, and... Gazebo never fails to surprise me; one spin, the other glide!!

VIDEO 2

I also have non-zero min depth and mu, except for the casters. See xacro.

UPDATE 2 I solved the drift! I attach the caster wheels with continuous instead of fixed joints. Base movements also look reasonable. BUT (always a but with gazebo), when I try to grasp anything, the following happens:

VIDEO 3

(with fixed caster base didn't move at all; also, the grasped cube has reasonable physics):

Looks like now none of the wheels offer any friction (though I have very high mu values, 200/100 for the 4 wheels). I tried adding damping to the motor wheels, but then the robot moves horribly bad, even with very small number.

For sure, the problem is to simulate the resistance to motion of the motors; there must be a way to do so

edit retag close merge delete

You want high friction for the wheels and no friction for the casters. Otherwise, the contacts are fighting each other.

( 2020-09-16 02:21:24 -0500 )edit

Sort by » oldest newest most voted

At the end I just needed to add a very small friction to the caster wheels and increase motor's one to compensate (see the commit).

more

Have a look underneath the robot, and confirm what exactly it is that it is drifting.

If it's the model that drifts (without any joints moving), then the problem is the surface parameters of the wheels (and casters). Start clean by removing all values you changed, and do the following:

• Set a non-zero min depth no matter what
• Increase friction (mu's) for the wheels; you can be generous here
• Focus on the casters. I've had success in the past by redefining my casters as sdf links with mu=0 and slip=1

If it's the wheel joints that drift, then go figure. I've had problems with that too on another robot, but I didn't find an answer in this case. I tried simplifying inertias, inflating inertias, setting damping and friction for the joints, increasing the effort limit, forcing zero force, zero velocity, or current position on the joints, but nothing. There would always be a residual velocity in the joints that would keep the robot moving. I ended up adding a calibration step in my controller to compensate for these velocities. That decreased (not eliminated) the drifting to an acceptable level.

more