Simulation Time Management

[osrf-migration]

Original report (archived issue) by Christopher Hong (Bitbucket: Christopher Hong).

---

One of Gazebo's primary limitations its inflexible manner of dealing with simulation time. In its current implementation, Gazebo relies on the physics engine to drive time, which has a number of issues:

1. Sensors are not able to coordinate with the physics engine to render at the desired rate. For example, a user may want a camera to render at 60 fps. However, the hardware may only enable an average render rate of 20 fps. Thus, in order to prevent frame loss, the user must slow down the physics simulation to a fixed rate which reflects the highest possible render time per frame much lower than 20 fps. A pull request was made a while ago to fix this issue: https://osrf-migration.github.io/gazebo-gh-pages/#!/osrf/gazebo/pull-requests/2502/make-sure-cameras-fps-is-strictly-applied/diff

2. Simulations cannot run as fast as possible without coordination issues. Faster-than-real-time simulation is a desired feature for automated testing, regression testing, and reinforcement learning. In order to properly enable faster-than-real-time, the physics engine and sensor manager must coordinate so that event and render timings are accurate, which goes back to issue 1. In addition, the simulation must allow coordinating time with an external entity, which represents simulation components outside of Gazebo (ex. ROS nodes in a simulation should be able block simulation time to enforce their update rates). If Gazebo's time cannot be externally driven, then a faster-than-real-time simulation may create a chain of events with temporally incorrect causality. For example, the rate of processing of sensor input in the simulation may not reflect the real world.

3. Gazebo may not be able to interact with external simulation components. Users may want to add additional simulation components outside of Gazebo. However, there is currently no way to coordinate time with external components.

I was hoping to be able to work on adding time management features to Gazebo, which may involve the addition of new fundamental classes and an overhaul of how Gazebo is set up and run. Concretely, these features are:

1. Adding modes of driving time, including: a. A mode that reflects the current way time is run (by the physics engine) b. A mode that enables faster-than-real-time and time coordination between the physics engine, sensor manager and external entity
2. An external api of some kind that allows the external entity to coordinate with Gazebo's time

[osrf-migration]

Original comment by Christopher Hong (Bitbucket: Christopher Hong).

---

• Edited issue description

[osrf-migration]

Original comment by Christopher Hong (Bitbucket: Christopher Hong).

---

• changed kind from "task" to "enhancement"

[osrf-migration]

Original comment by Christopher Hong (Bitbucket: Christopher Hong).

---

• Edited issue description

[osrf-migration]

Original comment by Christopher Hong (Bitbucket: Christopher Hong).

---

• Edited issue description

[osrf-migration]

Original comment by Christopher Hong (Bitbucket: Christopher Hong).

---

• Edited issue description