Constrain the list of topics bridge_logger subscribes to to only those actually published by some vehicle_topics.launch file #757
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.
If bridge_logger is meant to only record statistics for topics published from the bridge container (a.k.a. vehicle_topics.launch of some robot), it actually records more than that. This could be a possible performance problem. And it's very easy to run into it and make it even worse.
The basic problem is that BridgeLogger detects the topics of interest by plain substring matching:
subt/subt_ros/src/BridgeLogger.cc
Lines 124 to 132 in 2af07e8
This matches too much. This is an example list of topics recorded on our EXPLORER_X1_SENSOR_CONFIG_2 robot (called X1):
I see there our own internal topics
*_rgbd/points_slow[_filtered]
,imu_pose
,other_viewpoints
,viewpoints
androbot_data/X1/points_slow_filtered_planner/draco
(yes, even therobot_data
namespace matches!). And if I run the simulation with our h264 image transport package, it even subscribes to the*_rgbd/image_raw/h264
and*_rgbd/depth/image_raw/h264
topics which is bad because they are pretty computationally intensive and we don't normally use them all the time.So, instead of the generic substring matching, I rewrote the logger do the matching much more tightly - mostly using
EndsWith()
orHasPart()
(which matches whole strings between slashes). This results in matching more closely just the sets of bridge-related topics.To make sure no "proper" bridge topic gets lost, I went through all submitted models examining exactly what would the previous rules match, and making sure they would match them too with this PR. I did that by calling the following command in submitted_models folder for each of the substituted lines:
front_scan
points
image_raw
depth
Most of it gets covered by suffixes `points`, `depth` and `image_raw`. Just Explorer R2 has `depth/image` which is made a special case in this PR.imu
magnetic_field
air_pressure
battery_state
The previous implementation also matched a few camera_info topics, but as
OnSensorMsg
doesn't have a CameraInfo handler, they got ignored anyways (but subscribed). I chose to ignore them, but it's easy to add these to the bridge logger, too.I also removed the whole section of code that ignored topics like
parameter_updates
etc. - it's no longer needed.This PR solves #595 (as a side-effect).