Rosanswers logo

I am trying to create a simulation of my lab along with some of the robots we use. Some preliminary work in open space works fine. However collisions on the wall can results in incorrect simulation. I've managed to reproduce this with both the Erratic robot as well as a PR2 (see video link).

http://zweb.cs.utexas.edu/users/piyushk/share/gazebo.ogv The errors in simulation happens at 0:18 and 0:42, but does not happen at 0:32 when crashing into a wall. Typically the simulation terminates as the pose of the robot becomes NaN.

Replicating this for a PR2 was a bit more difficult. On most occasions the PR2 exhibited realistic behavior when crashing into the wall. The error can potentially be reproduced by the following commands:

roslaunch gazebo_worlds wg_collada_world.launch
roslaunch pr2_gazebo pr2.launch
roslaunch pr2_teleop teleop_keyboard.launch

Any suggestions to prevent this from happening will be greatly appreciated.

Originally posted by piyushk on ROS Answers with karma: 2871 on 2012-08-18

Post score: 2


1 Answer 1


Rosanswers logo

I've found 2 reasons (empirically) for this problem so far. After resolving both issues, I have not seen any problems (tested under ROS Groovy + Gazebo 1.2.5)

  1. All my meshes were made in sketchup or blender, and I managed to invert a few faces and the mesh did not close properly. This affects Gazebo in weird ways. Some of these errors may not be visible in sketchup/blender, but were visible in meshlab.
  • Output of a "good" mesh in meshlab. All collisions in this mesh were fine, irrespective of whether the colliding surfaces had surface properties defined or not.
  • Output of a "bad" mesh. the top part is not completely closed. This mesh would cause problems in the middle of the room - which is empty.
  • Resolution: It is easier making the meshes in sketchup while making sure none of the faces were inverted (check in meshlab). Also DO NOT export 2 sided faces - the robot was unable to move inside of the room.
  1. The erratic differential drive plugin changes the location of the model in the simulator instead of simply imparting the appropriate velocity to the wheel. Consequently the robot would overlap a tiny amount with a wall and bad things happen.
  • Resolution: This problem went away by improving the plugin to only impart joint velocities (see here)

Somebody familiar with Gazebo might be able to provide a better explanation on why an incomplete mesh failed.

Originally posted by piyushk with karma: 2871 on 2013-01-04

This answer was ACCEPTED on the original site

Post score: 0


Your Answer

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