# Problem using gmapping slam MessageFilter[target=odom]

Hi everyone, I'm currently building my own robot, and I want to implement a slam algorithm. Whenever I try to run gmapping, I get this error:

[ WARN] [1543086745.282958810]: MessageFilter [target=odom ]: Dropped 100.00% of messages so far. Please turn the [ros.gmapping.message_notifier] rosconsole logger to DEBUG for more information.


The debug logger just says that all messages are dropper. I know that it's a problem of message synchronization, or a problem in the TF tree but I didn't managed to find the error. I have a lidar broadcasting scan data linked to /laser_frame , I compute the odometry data by integrating the wheel's encoder values, and publish it in a /odom topic and through a tf broadcaster. To make it work I've added two static transform to my launch file.

Here is the detail of the gmapping node :

user@user-G551JM:~\$ rosnode info /slam_gmapping
--------------------------------------------------------------------------------
Node [/slam_gmapping]
Publications:
* /map [nav_msgs/OccupancyGrid]
* /rosout [rosgraph_msgs/Log]
* /slam_gmapping/entropy [std_msgs/Float64]
* /tf [tf2_msgs/TFMessage]

Subscriptions:
* /scan [sensor_msgs/LaserScan]
* /tf [tf2_msgs/TFMessage]
* /tf_static [tf2_msgs/TFMessage]

Services:
* /dynamic_map
* /slam_gmapping/get_loggers
* /slam_gmapping/set_logger_level

contacting node http://10.42.0.224:33867/ ...
Pid: 4043
Connections:
* topic: /rosout
* to: /rosout
* direction: outbound
* transport: TCPROS
* topic: /tf
* to: /slam_gmapping
* direction: outbound
* transport: INTRAPROCESS
* topic: /tf
* to: /tf2_web_republisher
* direction: outbound
* transport: TCPROS
* topic: /map
* to: /rviz
* direction: outbound
* transport: TCPROS
* topic: /tf
* to: /slam_gmapping (http://10.42.0.224:33867/)
* direction: inbound
* transport: INTRAPROCESS
* topic: /tf
* to: /robot_state_publisher (http://ubiquityrobot.local:38101/)
* direction: inbound
* transport: TCPROS
* topic: /tf
* direction: inbound
* transport: TCPROS
* topic: /tf
* to: /odometry_computation (http://10.42.0.224:40363/)
* direction: inbound
* transport: TCPROS
* topic: /tf
* direction: inbound
* transport: TCPROS
* topic: /tf_static
* to: /robot_state_publisher (http://ubiquityrobot.local:38101/)
* direction: inbound
* transport: TCPROS
* topic: /scan
* to: /ydlidar_node (http://ubiquityrobot.local:37987/)
* direction: inbound
* transport: TCPROS


I don't understand the purpose of the /tf_static topic , maybe it plays a role in this. Here is my tf tree, the raspicam is included by default on the ubiquity robot image I use on my raspberry pi.

Thank you for your help !

edit retag close merge delete

I have been facing the same issue for a while now and couldnt find anything. If you found a solution to this, please share.

( 2019-02-21 00:28:47 -0500 )edit

Sort by » oldest newest most voted

Actually I did find the solution for my specific problem, I was using a raspberry pi as a broadcaster of odometry, scan and, and another computer to run the gmapping package and the static tf messages of my tf tree. The thing is there is no time synchronization implemented in ROS, my computer time was slightly deviating from my computer by a tiny amount, and the topic synchronizer in gmapping responsible for making sure that the odometry, the tf messages and scan data are within a very small time margin in order to be consistent. My fix for this was to resynchronize everyday both my raspberry and my laptop to a time reference using the ntp protocol. Make some researches about it, the clean way to do it is to have either your computer or the raspberry running an ntp server, and the other one just asking for the time so that both can share the same time reference. But I got lazy and just synchronize both to another ntp server on the internet, which works fine. Another fix can be to use simulated time in roslaunch, make some researches about it, but essentially you create a node that broadcast time data on a topic /clock and use it as a reference on the other system. It didn't work for me, I don't really know why, even if I checked and that it was as precise as using ntp. That remains a mystery to me. Anyway just try sudo apt-get install ntpdate And then sudo ntpdate 1.ro.pool.ntp.org on both systems Then post the time difference on the forum and tell me if it fixed it

more