Open 5p00kk opened 9 months ago
mjcarroll
commented
8 months ago In general, I believe that our sensor systems are guarded with logic like this: https://github.com/gazebosim/gz-sim/blob/c158287d6f8556112d86d6e4188c39784364bd40/src/systems/imu/Imu.cc#L154-L166
There has been discussion of a set of system callbacks that could fire at particular rates, but there are some intricacies to consider with the potential of rewinding or jumps in time.
5p00kk
commented
8 months ago Probably it's two approaches as the following call includes the same check (if forcing=False, the sensor will update itself only if it's time), the sensor's implementation is very similar to the guard in the system:
Regardless, the way OdometerSystem is implemented right now is incorrect because there is neither System level check or call to Sensor's class Update function that would check if it's time to update. Right now the direct Update implementation is being called, which results in Custom Sensor's update being called at the simulation rate.
Description
In the implementation of a system for the custom sensor, the sensor is updated calling custom sensor's Update() method: https://github.com/gazebosim/gz-sim/blob/c158287d6f8556112d86d6e4188c39784364bd40/examples/plugin/custom_sensor_system/OdometerSystem.cc#L103 This will result in sensor update for at each simulation step and the system will ignore the sdf's update_rate attribute.
To avoid it the parent (gz::sensors::Sensor) Update() function should be called that executes the update at given update_rate (if force flag is false). For instance:
sensor->gz::sensors::Sensor::Update(_info.simTime, false);