Add set_rate service to all sensors #95
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New feature
Helps with issue #81 and osrf/subt#680 (for some users).
Summary
This PR adds an Ignition Transport service
~/set_rate
to all sensors. This is to allow users to selectively slow down some sensors if they do not need them running at full rate. This is extremely helpful with rendering sensors when you can anyways process only 6 Hz or similar, but the sensors run on 30.I also made the service check if the caller doesn't want to set a higher rate than the value of
<update_rate>
in the sensor's SDF. Such attempts are ignored (with the exception of zero update rate in SDF, which allows to set any rate via this service).I added a unit test and also tested it running the SubT simulator with EXPLORER_X1_SENSOR_CONFIG_2. This robot has 4 RGBD cameras, and the set_rate service worked for all of them. A single call to set_rate slows down both RGB and D cameras in the RGBD sensor. The real-time ratio of the SubT simulator with the robot was about 20-30% when spawned, and increased to about 90% when I slowed down all 4 cameras to 6 Hz. This might possibly save a lot of money for running Cloudsim :)
I decided to not limit the PR to rendering sensors, where the benefit is obvious, but as
<update_rate>
is a generic property of all sensors, I also added the service at this level.Test it
Terminal 1:
Terminal 2:
Terminal 3:
Running the bridge makes sure all cameras have a subscriber and generate data. This should slow down the simulation to sub-realtime. When you call the services to slow down the cameras, simulation speed should attack real time. You'll also see this in the simulator console:
Checklist
codecheck
passed (Seecontributing)
test coverage)
another open pull request
to support the maintainers
Note to maintainers: Remember to use Squash-Merge