ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | Q&A
Ask Your Question

slam_gmapping Message Filter dropping message with dynamic trasform [closed]

asked 2022-01-31 12:19:53 -0500

nigeno gravatar image

I'm using a fork of slam_gmapping package for ROS2:

As we all know, it requires the odometry tf transformation. Specifically, it requires the following transforms:

  cloud => base_link (where "cloud" is my laser_base frame)
  base_link => odom

As an output SLAM provides

odom => map transform

I was able to make it working with static transformations. So, I provided cloud => base_link and base_link => odom transforms and everything worked just fine. This is situation when my laser is static/no motion.

The following step was going to be pretty simple, but turned out to be not easy as I expected. If my laser is moving, then the solution to it is to leave the cloud => base_link as a static transform, and to add a dynamic transform base_link => odom, initiated either with the wall time (let's say 100ms) or as a callback to /odom message.

    now = this->get_clock()->now();
    transformStamped.header.stamp = now;
    transformStamped.header.frame_id = "odom";
    transformStamped.child_frame_id = "base_link";
    transformStamped.transform.translation.x = 0.0;
    transformStamped.transform.translation.y = 0.0;
    transformStamped.transform.translation.z = 0.0;
    transformStamped.transform.rotation.x = 0.0;
    transformStamped.transform.rotation.y = 0.0;
    transformStamped.transform.rotation.z = 0.0;
    transformStamped.transform.rotation.w = 1.0; 

I tried different combinations and methods, no luck so far. My guess is that it might related to how the tf transforms are timed. I don't quite understand yet how this message filter is working, that's what it gives:

[slam_gmapping-1] [INFO] [1643650251.253186111] [slam_gmapping]: Message Filter dropping message: frame 'cloud' at time 1640201165.546 for reason 'Unknown

I cannot upload the pic of tf tree (given with ros2 run tf2_tools command), but it looks good to me: map => odom => base_link => cloud.

So, probably my question would boil down to the following: why having the static transforms everything works fine, and exchanging one transform (odom => base_link) would result in such an error. How specifically I can check that the transform is carried out properly and expected for the slam_gmapping algorithm.

PS: the forked gmapping looks the same as popular for ROS1, but not officially supported as

edit retag flag offensive reopen merge delete

Closed for the following reason the question is answered, right answer was accepted by nigeno
close date 2022-03-25 15:36:25.138329

1 Answer

Sort by ยป oldest newest most voted

answered 2022-02-02 09:49:07 -0500

nigeno gravatar image

updated 2022-02-02 11:34:53 -0500

Solved. The issue was that I was playing the bag file on the /scan topic. Definitely, the messages had old time stamps. So, converting the messages with the now() time stamps resolved the issue. You can see it in the message filter error message (that's how I figured it):

[slam_gmapping-1] [INFO] [1643650251.253186111] [slam_gmapping]: Message Filter dropping message: frame 'cloud' at time 1640201165.546 for reason 'Unknown

1643650251 - January 2022 in Unix time; 1640201165 - Dec 2021

To answer my original question, the difference between the static transform and dynamic in this particular case. That's what happened. When publishing static tf transforms odom => base_link and base_link => cloud, the time stamps of the /scan messages were disregarded by the message filter. Whereas, when I tried to use dynamic odom => base_link transform, it did matter. So the issue came about. Not intuitive, but good to know.

edit flag offensive delete link more

Question Tools

1 follower


Asked: 2022-01-31 12:19:53 -0500

Seen: 116 times

Last updated: Feb 02 '22