Ask Your Question
0

Problem using gmapping slam MessageFilter[target=odom]

asked 2018-11-24 13:33:00 -0500

RobinB gravatar image

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]
 * /map_metadata [nav_msgs/MapMetaData]
 * /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
    * to: /base_link_to_laser4 (http://ubiquityrobot.local:44841/)
    * direction: inbound
    * transport: TCPROS
 * topic: /tf
    * to: /odometry_computation (http://10.42.0.224:40363/)
    * direction: inbound
    * transport: TCPROS
 * topic: /tf
    * to: /odom_to_base_link (http://10.42.0.224:46723/)
    * 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 flag offensive close merge delete

Comments

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

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

1 Answer

Sort by ยป oldest newest most voted
0

answered 2019-02-21 05:09:26 -0500

RobinB gravatar image

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

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower

Stats

Asked: 2018-11-24 13:33:00 -0500

Seen: 1,367 times

Last updated: Feb 21 '19