ROS2 Foxy and Galactic. Rolling seems to be affected as well
Version or commit hash:
foxy-devel
Laser unit:
Ouster OS0
Steps to reproduce issue
Relaunch slam-toolbox, for example using online_async_launch.py
Expected behavior
The published map to odom transformation is not timestamped to the past
Actual behavior
On relaunch, the slam_toolbox publishes for a while the map to odom transformations with the timestamp of 0.0 + transform timeout. This causes lots of errors to be printed by multiple different nodes that rely on this transformation.
Additional information
This seems to happen due to time being taken from the scan message, which is initialized with 0.0 timestamp. Old transform is published until the first laserscan message is received.
I made a simple fix for this in my own fork by publishing the tf only if the scan time is larger than 0.0. I can create a pull request from it, if you agree that this is a good way to handle the problem.
Required Info:
Steps to reproduce issue
Relaunch slam-toolbox, for example using online_async_launch.py
Expected behavior
The published map to odom transformation is not timestamped to the past
Actual behavior
On relaunch, the slam_toolbox publishes for a while the map to odom transformations with the timestamp of
0.0 + transform timeout
. This causes lots of errors to be printed by multiple different nodes that rely on this transformation.Additional information
This seems to happen due to time being taken from the scan message, which is initialized with 0.0 timestamp. Old transform is published until the first laserscan message is received.
I made a simple fix for this in my own fork by publishing the tf only if the scan time is larger than 0.0. I can create a pull request from it, if you agree that this is a good way to handle the problem.