Rosanswers logo

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>

Originally posted by Yannis on ROS Answers with karma: 88 on 2012-07-30

Post score: 1

Original comments

Comment by joq on 2012-07-31:
Why is this a problem? I would not expect a simulator to be deterministic. Real robots are even less deterministic.


1 Answer 1


Rosanswers logo

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

Originally posted by hsu with karma: 5780 on 2012-07-30

This answer was ACCEPTED on the original site

Post score: 4

Original comments

Comment by Yannis on 2012-07-30:
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 ?

Comment by Yannis on 2012-07-30:
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


Your Answer

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