Custom sensor system example ignoring sdf's update rate

[5p00kk]

Description

In the implementation of a system for the custom sensor, the sensor is updated calling custom sensor's Update() method:

gz-sim/examples/plugin/custom_sensor_system/OdometerSystem.cc

Line 103 in c158287

sensor->Update(_info.simTime);

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);

[mjcarroll]

In general, I believe that our sensor systems are guarded with logic like this:

gz-sim/src/systems/imu/Imu.cc

Lines 154 to 166 in c158287

	for (auto &it : this->dataPtr->entitySensorMap)
	{
	if (it.second->NextDataUpdateTime() <= _info.simTime &&
	it.second->HasConnections())
	{
	needsUpdate = true;
	break;
	}
	}
	if (!needsUpdate)
	return;
	this->dataPtr->Update(_ecm);

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]

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:

gz-sim/src/systems/imu/Imu.cc

Line 171 in c158287

it.second->Update(_info.simTime, false);

https://github.com/gazebosim/gz-sensors/blob/d522779693916a81aac6360b049286e7ebb6cdb3/src/Sensor.cc#L456C4-L461C1

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.