Lookup would require extrapolation into the future on the same machine

Question

I get this error when trying to view my RPLidar A2 scan in rviz2. It’s on a differential drive robot controlled using arduino using Articulated Robotics’ code that I quickly ported to Humble, alongside the controller manager code. I am running everything on a laptop, no separate machines, on ROS2 humble. It’s connected to the base_link via the URDF but I tried a static transform publisher but the same thing occurred.

It shows perfectly fine when viewing the base_link frame, but with Odom the issue occurs.

Oddly enough when I use a YDLIDAR G4, it works intermittently but it loses transform often. When I use the rplidar it doesn’t work at all. This is my first time using ros2 so I am confused

[ERROR] [1668990540.121377402] [rviz2]: Lookup would require extrapolation into the future. Requested time 1668990540.179102 but the latest data is at time 1668990540.113331, when looking up transform from frame [laser_frame] to frame [odom]

Answer 1

It's not that the transform doesn't exist. It's that the node doesn't know about the transform yet when you query for the data.

With that small of a delta the usual problem is that the data gets there faster than the transform information can be communicated. You need to hold the data for ~ 0.01 seconds until the transforms are available.

The canonical way to do this is to subscribe to the topic via a tf2_ros::MessageFilter which will subscribe to your incoming topic and give you the callback when the data has arrived. There's a tutorial on the topic here

One reason you may see a slight difference between the two lidars could be that one may be providing the additional time resolution of interbeam distances in which case you'll want to use the tolerance parameter to make sure to cover that too.

Answer 2

I'm assuming that you're using this REPO for the ros2 humble rplidar.

I think the reason the scan is not showing up in rviz is because the timestamp in the header for the scan msg is different than the actual acquisition time of the first ray in the scan. Thus, using the same start_scan_time as the scan_msg.header.stamp will fix your problem

Here's what you need to add/change in the source code of this rplidar repo

file: rplidar_ros2/src/rplidar_node.cpp

1. Add start as a parameter to publish_scan method
2. Change header for the scan msg

line 142 
void rplidar_node::publish_scan(
  const double scan_time, ResponseNodeArray nodes, size_t node_count)
{
....
line 149
scan_msg.header.stamp = this->now();

Change it to this

line 142
void rplidar_node::publish_scan(
  const double scan_time, rclcpp::Time start, ResponseNodeArray nodes, size_t node_count)
{
.....

line 149
scan_msg.header.stamp = start; 

3. Change the locations publish_scan is called to include start_scan_time

line 368
publish_scan(scan_duration, start_scan_time, std::move(angle_compensate_nodes), angle_compensate_nodes_count);

line 386
publish_scan(scan_duration, start_scan_time, std::move(valid), end_node - start_node + 1);
    }

line 393
publish_scan(scan_duration, start_scan_time, std::move(nodes), count);

file: rplidar_ros2/include/rplidar_node.hpp

4. Change the method declaration to include rclcpp::Time start

line 87
void publish_scan(const double scan_time, rclcpp::Time start, ResponseNodeArray nodes, size_t node_count);

Hope this helps.

Answer 3

You need to synchronize the clocks on the host machines using tools like tzdata (for Linux hosts). This is not so much a code problem as it is a network/host problem. Make sure all devices are connected to the same wireless network and synchronize clocks.