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.
Hello!
This PR is adjacently related to this issue that I reported. However it does not directly fix that. While I was debugging the issue, I found that the
aruco_detect
node was also consuming CPU when the autodock algorithm was idle. Screenshot ofhtop
shown below showsaruco_detect
CPU consumption when IDLE:Ideally, we should not be detecting/looking for aruco markers until an
AutoDock
action itself is started. But it seems like on default config, thearuco_detect
is always on and looking for these markers resulting in high CPU consumption. Looking into this further, thearuco_detect
node DOES have a neat service called/enable_detections
that lets us enable/disable detections. So without touching the source code foraruco_detect
, we will be able to manage the state of these detections from the autodock node itself.This PR primarily helps implement this with the following changes:
Some screenshots below from interactive testing with Turtlebot sim:
Below, you can see that
aruco_detect
consumption has reduced when the autodock is idle:On startup itself, we disable detections so when the sim is launched with the
rviz
, we will NOT see any images from the/fiducial_images
topic:Below, you can see that
aruco_detect
is back to normal consumption when autodock is in progress:Now we start seeing images on the
/fiducial_images
topic:When autodock fails:
When autodock succeeds:
Note that in
rviz
, once the docking action is complete, the image will look "frozen". That is because, we disable detections at the end of the action andaruco_detect
will stop publishing to the/fiducial_images
topic.Points to ponder:
debug
flag is passed for ease of debugging which in essence will turn off this feature and go back to previous default behavior?/enable_detections
service succeeding. In the event of failure of this service, we rely on theAutodock
action's built-in retry mechanism to re-call the service instead of its own retry. I thought it was easier to keep track of the retries this way and conceptually consider that enabling/disabling detections is part of the docking algorithm itself.