Handle re-setting of simulation-time more gracefully about geometry2

[svenlr]

Hello,
we have wrapped all our transform buffers in transform listeners and nevertheless experience a similar issue on ROS melodic with rosbag play --clock --loop and use_sim_time set to true. Warnings similar to the one below usually start to fill the console when the bag is repeated for the first time. However, it appears that there is about a small chance for a bag repetition without problems.

Warning: TF_OLD_DATA ignoring data from the past for frame base_link at time 1.54928e+09 according to authority /odometry
Possible reasons are listed at http://wiki.ros.org/tf/Errors%20explained
         at line 277 in /tmp/binarydeb/ros-melodic-tf2-0.6.5/src/buffer_core.cpp

Accompanying these errors, the lookup_transform calls in a node always failed. This could be "fixed" by checking for negative time difference and a consecutive manual buffer.clear(). Before applying the workaround, again, there was a small chance for a bag loop without problems.
The above warning messages continue to appear despite the workaround. However, it is hard to tell what is producing them as there is no such information in them.

[furushchev]

I manually compiled entire geometry2 package from source, and it now clears cache without any problem.
Strange...

cd /path/to/catkin_ws/src/
wstool set -u ros/geometry2 https://github.com/ros/geometry2 -v 0.5.15
catkin b geometry2
source ../devel/setup.bash

[trainman419]

+1 to getting this fixed.

[tfoote]

Fixed in 619a132 ported forward from #68

[furushchev]

Hi, was this already fixed on indigo?
I still have the same problem when executing rosbag play with option --loop --clock.

Warning: TF_OLD_DATA ignoring data from the past for frame odom at time 1.49284e+09 according to authority unknown_publisher
Possible reasons are listed at http://wiki.ros.org/tf/Errors%20explained
         at line 273 in /tmp/binarydeb/ros-indigo-tf2-0.5.15/src/buffer_core.cpp
Warning: TF_OLD_DATA ignoring data from the past for frame odom at time 1.49284e+09 according to authority unknown_publisher
Possible reasons are listed at http://wiki.ros.org/tf/Errors%20explained
         at line 273 in /tmp/binarydeb/ros-indigo-tf2-0.5.15/src/buffer_core.cpp
Warning: TF_OLD_DATA ignoring data from the past for frame odom at time 1.49284e+09 according to authority unknown_publisher
Possible reasons are listed at http://wiki.ros.org/tf/Errors%20explained
         at line 273 in /tmp/binarydeb/ros-indigo-tf2-0.5.15/src/buffer_core.cpp
Warning: TF_OLD_DATA ignoring data from the past for frame base_footprint_wheel at time 1.49284e+09 according to authority unknown_publisher
Possible reasons are listed at http://wiki.ros.org/tf/Errors%20explained
         at line 273 in /tmp/binarydeb/ros-indigo-tf2-0.5.15/src/buffer_core.cpp
Warning: TF_OLD_DATA ignoring data from the past for frame base_footprint at time 1.49284e+09 according to authority unknown_publisher
Possible reasons are listed at http://wiki.ros.org/tf/Errors%20explained
         at line 273 in /tmp/binarydeb/ros-indigo-tf2-0.5.15/src/buffer_core.cpp
Warning: TF_OLD_DATA ignoring data from the past for frame odom at time 1.49284e+09 according to authority unknown_publisher
Possible reasons are listed at http://wiki.ros.org/tf/Errors%20explained
         at line 273 in /tmp/binarydeb/ros-indigo-tf2-0.5.15/src/buffer_core.cpp

rosversion tf2
0.5.15

CC: @tfoote

[tfoote]

I don't know of any differences re source vs binary. If you can provide a simple example I can try to reproduce.

[pryre]

No to dig up an old issue, but I think I have an example that may help with this. From what I have found, it may be linked to not using a listener with the buffer. Currently running on Kinetic: rosversion tf2 - 0.5.17

My setup involves interfacing with a tf2_ros::Buffer manually, using setTransform(...) to push data from a pose message into the buffer, and lookupTransform("...", "...", ros::Time(0)) to pull the latest common pose back out.

Issue seems to arise when trying to set a transform that is older than the buffers cache_time. I have a bag file on loop putting out a clock message, and use the -u flag on rosbag to adjust the replay duration. As soon as the loop performs a reset that's longer than the 10 second default, I get Warning: TF_OLD_DATA ignoring from the past.... As soon as the clock is back within the cache_time bounds, warnings stop and behavior is as normal.

Example:

• Set rosbag too loop data with a duration of 15 seconds and publish clock
• Set use_sim_time to true
• Start node using buffer as described with cache_time left at the default 10 seconds
• No errors will occur until clock reset
• Errors will stop at exactly t=5 seconds, when clock time is back within the cache time range (from the last recorded time on the cache which is 15 seconds)

Adjusting either the rosbag duration to be less than the cache time, or extending the cach_time to be longer than the loop duration causes the set data to behave as expected.

I have a feeling that this may be "intended behavior" if not using a tf2 listener, as perhaps the listener is the one that is managing clearing the cache.

[tfoote]

Yes that is expected behavior if you're just using a buffer it only expects time to progress forward, the linked commit above is specific to the listener.

The buffer itself does not have any sense of time. When time jumps backwards the data must be cleared. using the clear() method like:

geometry2/tf2_ros/src/transform_listener.cpp

Lines 102 to 109 in acb62b8

	void TransformListener::subscription_callback_impl(const ros::MessageEvent<tf2_msgs::TFMessage const>& msg_evt, bool is_static)
	{
	ros::Time now = ros::Time::now();
	if(now < last_update_){
	ROS_WARN_STREAM("Detected jump back in time of " << (last_update_ - now).toSec() << "s. Clearing TF buffer.");
	buffer_.clear();
	}
	last_update_ = now;

[pryre]

I'm not sure if this will assist too much @svenlr (or others), but for me, the issue was self-induced, as I was pushing my own data into the buffer manually in a timer function for visualization. The following code may help with your issues:

My timer function that pushes in custom data (see check_update_time() at the start: here.

The check_update_time() function and "resetting" function.