Ask Your Question

Gazebo model: wheels slip after upgrade to Electric

asked 2011-10-04 05:44:07 -0500

updated 2011-10-12 21:53:53 -0500

Dear Gazebo gurus,

after switching to Electric, my robot model seems to lose friction with the ground in Gazebo. The wheels are still turning, but the robot doesn't move forward. The same code works perfectly in Diamondback.

Steps to reproduce:

git clone
rosmake kurt_gazebo kurt_teleop_key
roslaunch kurt_gazebo kurt_wg_world.launch
rosrun kurt_teleop kurt_teleop_key

Now use the w,q,e,s keys to send cmd_vel commands.

Update 1: Here's a short video of that behaviour:

Update 2: It's not a problem with my custom controller. In order to isolate the problem, I removed the gazebo_ros_kurt controller from kurt_description/bases/kurt_indoor.urdf.xacro and applied a body wrench to one wheel:

rosservice call gazebo/apply_body_wrench '{body_name: "kurt::left_front_wheel_link" , wrench: { force: { x: 0.0, y: 0.0, z: 0.0 } , torque: { x: 0.0, y: 14.0 , z: 0.0 } }, duration: -1 }'

In Diamondback, this makes the robot turn; in Electric, for all y torques below ~13, nothing seems to happen; from ~14 on upwards, the robot jumps violently around.

Here's a video of that, too:

Update 3: Thanks to @hsu, this was fixed in commit 1eafb56786b1f22f67967d1d821f687ac7c827f3, so if you want to reproduce the bug make sure to get an earlier commit than that.

edit retag flag offensive close merge delete


Can you check if there's any changes in the model (XML/URDF)? This way we can isolate the problem. Thank you.
hsu gravatar image hsu  ( 2011-10-04 10:58:14 -0500 )edit
I assume you mean if there are changes between the URDF I use in Diamondback and Electric? No, as I said, the exact same model and controller work in Diamondback, but not Electric.
Martin Günther gravatar image Martin Günther  ( 2011-10-04 20:23:39 -0500 )edit
@hsu: I'm still having this problem. I guess there were some changes to Gazebo which mean that I have to change my URDF file to work with Electric, but I have no idea how to proceed. Could you reproduce the bug? Is there anything I can do to help?
Martin Günther gravatar image Martin Günther  ( 2011-10-09 21:14:04 -0500 )edit
not for now, thanks for the launch commands to reproduce, that'll be handy for trying to figure out what's gone wrong. thanks.
hsu gravatar image hsu  ( 2011-10-10 13:45:40 -0500 )edit
Hi. I had the same problem when I updated my ROS to the Electric version. I tested changing the mu1, mu2 and other friction values, and furthermore, I tried to change the wheels. I solved temporaly the problem using the Erratic robot wheels that works fine, but there isn't a correct solution, I will test this solution soon.
mbj gravatar image mbj  ( 2011-10-13 02:22:44 -0500 )edit
@mbj: if what you are experiencing turns out to be a different problem, please open a new question with instructions for reproducing the problem. thanks.
hsu gravatar image hsu  ( 2011-10-13 13:01:38 -0500 )edit
@hsu: hi john, monday I'll try to reproduce the problem, that is just the contrary that in the diamondback version. The robot turns over itself correctly but it not goes forward/backwards.
mbj gravatar image mbj  ( 2011-10-14 00:52:11 -0500 )edit
@hsu: Before open a new question about my problem I tried, basing on the @Martin Günther problem/solution, to view my robot contacts and bounding boxes. As I can saw, the base_footprint link was contacting with the floor, so I rised up a little this link . In Diamondback version, this fact doesn't cause any problem, but in Electric it makes imposible that the robot can't move forward/backward but it be able to rotate over itself (is ODE more restrictive in this version of Gazebo?). Here is a video where the problem is solved. (
mbj gravatar image mbj  ( 2011-10-16 21:20:47 -0500 )edit

1 Answer

Sort by » oldest newest most voted

answered 2011-10-12 08:03:05 -0500

hsu gravatar image

updated 2011-10-12 08:32:46 -0500

I noticed some extra contacts on the ground between the wheels (see photo below), turns out the laptop_structure.dae is touching the ground view below has contacts view enabled. The problem is also visible if you also enable the bounding box visualization under view.

image description

replacing laptop_structure.dae under collision with a small box fixed the problem, but I suspect something might have gone awry with the assimp dae mesh loader.

<?xml version="1.0"?>

  <include filename="$(find kurt_description)/parts/sick_lms200.urdf.xacro" />

  <link name="laptop_structure">
        <mesh filename="package://kurt_description/meshes/laptop_structure.dae" />
        <mesh filename="package://kurt_description/meshes/laptop_structure.dae" />
        <box size="0.01 0.01 0.01"/>
      <mass value="2.0" />
      <origin xyz="-0.005401183 0.0 0.141356018" />
      <inertia ixx="0.022277280" ixy="-0.000000004" ixz="-0.001009999" 
        iyy="0.017783837" iyz="0.0" 
        izz="0.025523417" />

  <joint name="top_to_structure" type="fixed">
    <parent link="base_link" />
    <child link="laptop_structure" />
    <origin xyz="-0.05 0 0.03" rpy="0 0 0" />

  <joint name="structure_to_laser" type="fixed">
    <parent link="laptop_structure" />
    <child link="laser" />
    <origin xyz="0.195 0 0.08" rpy="0 0 0" />

alternatively, loading laptop_structure.dae with meshlab and saving it as a stl mesh, then modifying urdf collision to use the new stl (keep visual with dae for better aesthetics) also fixes this problem.

This deserves a ticket.

edit flag offensive delete link more


Thanks a lot for all your help, it's working perfectly now.
Martin Günther gravatar image Martin Günther  ( 2011-10-12 21:56:41 -0500 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower


Asked: 2011-10-04 05:44:07 -0500

Seen: 1,889 times

Last updated: Oct 12 '11