Gazebo | Ignition | Community
Ask Your Question

ConnectWorldUpdateBegin vs. ConnectWorldUpdateEnd in model plugins?

asked 2014-06-28 09:31:24 -0500

Johannes Meyer gravatar image

As documented in many tutorials and posts (e.g. this one) model plugins should connect to the WorldUpdateBegin event by registering an update callback using event::Events::ConnectWorldUpdateBegin(...).

As there is also a ConnectWorldUpdateEnd(...) method and from looking at the implementation details in the World::Update() function in I wonder if it might be better for some model plugins to run at the end of the world update instead of at the beginning? This is especially the case for model plugins that simulate sensors, like the IMU or P3D plugin in the gazebo_plugins package for ROS.

If I understand the implementation of the world update correctly it basically

  1. Updates the sim time
  2. Processes the worldUpdateBegin event
  3. Updates the physics, handles collisions etc.
  4. Processes the worldUpdateEnd event

If this is true then plugins like the gazebo_ros_imu plugin should run after the physics update and have access to the updated model data valid for the current time step to not introduce an delay. It all depends if the physics update at time step t_k integrates over time interval t_(k-1) to t_k or t_k to t_(k+1).

This does not affect sensor plugins like laser or camera as they are triggered by new data being available for the sensor they are attached to. Is there a guarantee that if a sensor runs with an update rate of 500 Hz and the physics engine at 1000 Hz that the measurements represent the world state of exactly every 2nd world update?

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted

answered 2014-07-03 09:03:54 -0500

nkoenig gravatar image

The physics update at time step tk integrates over the time interval tk to t_(k+1).

I believe you have a good point about when some plugins should be updated. Currently the sim time associated with the world update begin event does not match the state of simulation. Whereas, the world update end does.

We can resolve this by moving the world update begin event to happen before the simulation time is updated (swap steps 1 and 2 in your list above).

edit flag offensive delete link more


The proposed solution sounds okay, but I don't know enough about Gazebo's internals to fully understand the consequences. Additionally, independent of the simulation time issue in WorldUpdateBegin, it confirms that plugins that output sensor data should connect to WorldUpdateEnd to minimize the (simulated) delay and data is published when it is valid and not in the next update step.

Johannes Meyer gravatar imageJohannes Meyer ( 2014-07-10 04:35:15 -0500 )edit

Question Tools

1 follower


Asked: 2014-06-28 09:31:24 -0500

Seen: 2,507 times

Last updated: Jul 03 '14