Reduce /<robot_name>/pose topic bandwidth

[iche033]

Addresses issue #338, and potentially #389 and #261

Depends on ign-gazebo pull request 65 and ros_ign pull request 67

New SDF params were added to the pose publisher system to help reduce bandwidth of the /<robot_name>/pose topic. The system now:

• subscribes to the new /<robot_name>/pose_static topic for static transforms (non-latched, published at 1Hz)
• changes the message type of the /<robot_name>/pose[_static] topics from geometry_msgs/TransformStamped to tf2_messages/TFMessage that consists a vector of transforms. This significantly reduces the number of messages that need to be transmitted over the pose topic, e.g. for X1_C1, the publishing rate reduced from 2000Hz to 250Hz.

Note: The message type change is a breaking change but the /<robot_name>/pose topic is not an API that's publicly documented in https://github.com/osrf/subt/wiki/api.

The changes address the critical / intermittent TF data loss issue for me. More tests are required to confirm whether or not this resolves #261 but with these changes I have not yet been able to reproduce the issue with message drops or delays on other topics.

This PR also includes a heartbeat logger in BridgeLogger to help detect delays in messages.

Some ideas for testing:

• run subt and monitor /tf topic. Before the change, I see the the publishing rate slowly reduces and becomes intermittent
• look for Error: No messages received or Error: Missed message(s) in ~/.ros.
• Add the pose topic here to the list of topics monitored by BridgeLogger. Interestingly with this change, I start to see error messages about dropped messages in ~/.ros within a few minutes of running subt.

[nkoenig]

How about moving this heartbeat check to a separate callback that is triggered by a ROS timer? I think this code will work as long as some sensor data comes through. If all sensor data stops, then we won't get a heartbeat error.

[iche033]

yep done. Moved heartbeat check into its own thread. 296de9e

[pauljurczak]

Is it included in 2020-04-21 release? I updated and I don't see these changes.

[nkoenig]

No, this is not in the 2020-04-21 release. Please refer to the release notes on the wiki.

[mjcarroll]

Do we need to add a migration note somewhere? There are other third-party model PRs in flight that probably don't incorporate these changes.

[iche033]

I can add a Migration.md guide for keeping track of changes like this one between circuits if that helps?

[nkoenig]

We have been putting release notes on the wiki. I'll add a note there when this gets released.

[zwn]

Is there any time frame for when this will be released? I hope it will help with #415. I am not worried about migration since the original solution is not working reliably. If this indeed fixes the problems, I believe the teams will be more than happy to make any necessary adjustments.

[nkoenig]

Is there any time frame for when this will be released? I hope it will help with #415. I am not worried about migration since the original solution is not working reliably. If this indeed fixes the problems, I believe the teams will be more than happy to make any necessary adjustments.

We are getting close. There are/were a few upstream releases that had to be deployed before this PR can be merged. Timeframe is likely this week.