Rosanswers logo

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 http://kos.informatik.uni-osnabrueck.de/uos-ros-pkg.git
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.

Originally posted by Martin Günther on ROS Answers with karma: 11816 on 2011-10-04

Post score: 1

Original comments

Comment by mbj on 2011-10-16:
@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. (http://www.youtube.com/watch?v=SCFir5kbW0M)

Comment by mbj on 2011-10-14:
@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.

Comment by hsu on 2011-10-13:
@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.

Comment by mbj on 2011-10-13:
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.

Comment by hsu on 2011-10-10:
not for now, thanks for the launch commands to reproduce, that'll be handy for trying to figure out what's gone wrong. thanks.

Comment by Martin Günther on 2011-10-09:
@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?

Comment by Martin Günther on 2011-10-04:
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.

Comment by hsu on 2011-10-04:
Can you check if there's any changes in the model (XML/URDF)? This way we can isolate the problem. Thank you.


1 Answer 1


Rosanswers logo

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.

Originally posted by hsu with karma: 5780 on 2011-10-12

This answer was ACCEPTED on the original site

Post score: 2

Original comments

Comment by Martin Günther on 2011-10-12:
Thanks a lot for all your help, it's working perfectly now.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.