0
$\begingroup$

Rosanswers logo

I'm using a fork of slam_gmapping package for ROS2: https://github.com/Project-MANAS/slam_gmapping

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; 
    tf_broadcaster1_->sendTransform(transformStamped);

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 view_frames.py 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 https://github.com/ros-perception/slam_gmapping for ROS1, but not officially supported as https://github.com/SteveMacenski/slam_toolbox.


Originally posted by nigeno on ROS Answers with karma: 76 on 2022-01-31

Post score: 0

$\endgroup$

1 Answer 1

0
$\begingroup$

Rosanswers logo

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.


Originally posted by nigeno with karma: 76 on 2022-02-02

This answer was ACCEPTED on the original site

Post score: 0

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.