0
$\begingroup$

Rosanswers logo

I logged laser scans from P3dx in a bag file and ran gmapping on the bag file. I get the following warning

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

I set up the following tf using static_transform_publisher.

map -> odom -> base_footprint -> base_link -> base_laser

This is the tf I got when I ran gmapping on the bag file given in slam_gmapping tutorial (gmapping is working perfectly on this bag file). So, I assume this is the right tf.

The bag file I created using p3dx was filtered to contain only the laser scans, and all the tfs were published through static_transform_publisher.

gmapping continues to give the warning. Any help?

Update 1 I get only odom -> base_link from the bag file I created. That forced me to use static_transform_publisher, which now I understand is not right. But the bag file I downloaded contains odom -> base_footprint -> base_link -> base_laser. How do I get this tf.?

To collect data on p3dx I use

rosrun p2os_driver p2os
rosbag record -O mylaserdata /base_scan /tf

Anything I should change to get the required tf?

Update 2 This is how I run gmapping now. I still get the same warning.

rosparam set /base_frame "/base_link"
rosrun tf static_transform_publisher 0 0 0 0 0 0 base_link base_laser 100
rosrun gmapping slam_gmapping scan:=base_scan
rosbag play gmapping_data.bag

Now the tf is map -> odom -> base_link -> base_laser

Update 3 Set the debug level of ros.gmapping.message_filter in slam_gmapping node to "Debug". I get this message now

[DEBUG] [1299740216.768663556, 1299651571.155978846]: MessageFilter [target=/odom ]: Removed oldest message because buffer is full, count now 5 (frame_id=laser, stamp=1299651570.618031)

[DEBUG] [1299740216.768820286, 1299651571.155978846]: MessageFilter [target=/odom ]: Added message in frame laser at time 1299651571.154, count now 5


Originally posted by Aravindhan K Krishnan on ROS Answers with karma: 125 on 2011-03-08

Post score: 1


Original comments

Comment by Eric Perko on 2011-03-14:
To note, there is now a patch attached to ros-pkg ticket #4856 that fixes this problem for gmpping with SICK's in 0.5 degree mode.

Comment by Aravindhan K Krishnan on 2011-03-09:
It works after changing the resolution. Thanks.!

Comment by Eric Perko on 2011-03-09:
See https://code.ros.org/trac/ros-pkg/ticket/4856 . I ran into a similar problem a few days ago. Switching the SICK to 1 degree mode when running gmapping will work just fine.

Comment by Aravindhan K Krishnan on 2011-03-09:
My scan resolution is 0.5 deg. Should I change it to 1 deg

Comment by Eric Perko on 2011-03-09:
Is your SICK in 0.5 degree mode? I.e. does it output 2 different scans, one with 181 points and the other with 180?

Comment by Eric Perko on 2011-03-09:
I fixed up your formatting a bit and was able to get your "Debug" Messages to display in the question.

Comment by Aravindhan K Krishnan on 2011-03-09:
I got over the warning now. gmapping starts, says "Registering First scan" and then I get an assertion error. slam_gmapping: rangereading.cpp:17: GMapping::RangeReading::RangeReading(unsigned int, const double*, const GMapping::RangeSensor*, double): Assertion `n_beams==rs->beams().size()' failed

Comment by Eric Perko on 2011-03-09:
It looks like your laser's frame_id is actually "laser", not "base_laser". I updated my answer to reflect that. Can you give it another go and see if anything changes?

Comment by Aravindhan K Krishnan on 2011-03-09:
DEBUG] [1299740215.593122446, 1299651569.985552372]: MessageFilter [target=/odom ]: Added message in frame laser at time 1299651569.978, count now 5

Comment by Aravindhan K Krishnan on 2011-03-09:
DEBUG] [1299740215.700796658, 1299651570.086301889]: MessageFilter [target=/odom ]: Removed oldest message because buffer is full, count now 5 (frame_id=laser, stamp=1299651569.550084)

Comment by Aravindhan K Krishnan on 2011-03-09:
Are you able to see my debug message I posted.. I am not able to see it posted but I can see when I click edit.! Anyway posting my Debug message here

Comment by Eric Perko on 2011-03-09:
Could you set the logger to "debug" as the warning states? You can do this with the rxconsole tool by using the Levels button. Select gmapping, then find the logger called "ros.gmapping.message_notifier" and set it to debug, then include those messages in an update to your question.

$\endgroup$

2 Answers 2

0
$\begingroup$

Rosanswers logo

In order for the timestamps of the transforms output by the static_transform_publisher to be valid, you'll need to set ROS to use simulation time and have rosbag output the clock when it plays back. To do that, do the following after starting up a roscore:

rosparam set use_sim_time true
rosrun tf static_transform_publisher 0 0 0 0 0 0 base_link laser 100
rosrun gmapping slam_gmapping scan:=base_scan
rosbag play --clock gmapping_data.bag

Note the setting of the use_sim_time parameter as well as the --clock option to rosbag. This way, all of ROS (until you kill that roscore or otherwise unset the use_sim_time parameter) will use the timestamps that match what was recorded in your bagfile instead of the current wall time.

Also, you should not need to set the ~base_frame on gmapping, since it defaults to base_link as documented on the gmapping wiki page.

You will also need to actual set the transform between base_link and laser or your output map may contain errors. The identity transform (what you specified) should be good enough for testing if gmapping will work at all though.


Originally posted by Eric Perko with karma: 8406 on 2011-03-09

This answer was ACCEPTED on the original site

Post score: 2


Original comments

Comment by Aravindhan K Krishnan on 2011-03-09:
Tried... Still the same warning.!!

$\endgroup$
0
$\begingroup$

Rosanswers logo

all the tfs were published through static_transform_publisher.

Do you literally mean all the tf's? If so, this is what the problem is. map->odom will be published by gmapping itself, and odom->base_footprint needs to be published by a source of odometry, so it can't really be static. The only static transforms are base_footprint->base_link and base_link->base_laser.

UPDATE:

Let's say you have a bag file which publishes a odom->base_link tf. You need to run gmapping with the "~base_frame" parameter set to base_link. When you were running with the bag file, it probably had the "~base_frame" set to base_footprint.


Originally posted by Ivan Dryanovski with karma: 4954 on 2011-03-09

This answer was NOT ACCEPTED on the original site

Post score: 5

$\endgroup$

Your Answer

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