ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | Q&A
Ask Your Question

Gazebo simulations not repeatable

asked 2012-07-30 19:20:24 -0600

Yannis gravatar image

updated 2012-07-31 15:34:11 -0600

hsu gravatar image

I have been using an custom obstacle avoidance node in gazebo simulator with Turtlebot. It is based on image and poincloud inputs, and gives an angular velocity in output. I ran my code with two identical simulations (an big simulated room with one box) to study the repeatability of my algorithm. Each time, the trajectories are different. So to verify that it was not coming from my code, I fed the same recorded bag file of images and pointclouds to my code, an it produces exact same behaviour. So the simulator seems to bring some randomness, but I cannot figure out the precise source of the problem since there is not much documentation on how the world, objects and robot are simulated, how the simulated images and pointclouds are rendered. So I need your help, to help me narrow down the origin of randomness between simulations. Does it come from the image and pointcloud generation ? Or from the odometry from a model small inaccuracy ? Here are the parameters I use:

  <gravity>0 0 -9.8</gravity>


  <size>480 320</size>
  <pos>0 0</pos>
    <row height="100%">
      <camera width="100%">
        <xyz>0 0 10</xyz>
        <rpy>0 90 90</rpy>

  <ambient>1.0 1.0 1.0 1.0</ambient>

<model:physical name="gplane">
  <xyz>0 0 0</xyz>
  <rpy>0 0 0</rpy>

  <body:plane name="plane">
    <geom:plane name="plane">
      <normal>0 0 1</normal>
      <size>51.3 51.3</size>
      <segments>10 10</segments>
      <uvTile>100 100</uvTile>
edit retag flag offensive close merge delete


Why is this a problem? I would not expect a simulator to be deterministic. Real robots are even less deterministic.

joq gravatar image joq  ( 2012-07-31 14:25:37 -0600 )edit

1 Answer

Sort by ยป oldest newest most voted

answered 2012-07-30 20:09:48 -0600

hsu gravatar image

updated 2012-07-30 20:30:58 -0600

Couple of things I can think of:

  • ODE quickstep's parameter RANDOMLY_REORDER_CONSTRAINTS is set to true by default, unfortunately, it's not changeable without recompiling right now, but we can make that a configurable option down the road.
  • Other than that, physics and sensor generation are on separate threads (see Server::run()), so they are not synchronized.
  • Lastly, if your navigation code is running in its own process, it might not be synchronized with physics update and sensor generation as well.

To synchronize,

  • Without actually doing it, I imagine one could probably serialize World::Run() and merge it into the same while loop as sensors::run_once(true) inside of Server::run().
  • Also, one way to synchronize navigation and simulation is by putting navigation codes inside a plugin and connect its updates to gazebo::event::Events::ConnectWorldUpdateStart(...) to synchronize it with simulation.

Hope this helps. John

edit flag offensive delete link more


Thank you for the information. In order to minimize the randomness (except on randomly_reorder_constraints), is it possible for me to manually synchronize the physics and sensor generation ? Same thing for synchronizing my process with the others, how can I do it ?

Yannis gravatar image Yannis  ( 2012-07-30 20:16:00 -0600 )edit

Thank you very much for all the details, I am going to try to make it a little bit better, but it was mostly to understand the origin of the randomness, to explain it in my work report more than to solve it. That is very good to know, and I hope those points can be solved in the next versions

Yannis gravatar image Yannis  ( 2012-07-30 20:45:58 -0600 )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: 2012-07-30 19:20:24 -0600

Seen: 928 times

Last updated: Jul 31 '12