Issue with setting tf in gmapping

gmapping

asked 2011-03-08 21:32:27 -0600

Aravindhan K Krishnan
125 ●5 ●9 ●16

updated 2011-03-09 17:29:09 -0600

Eric Perko

8406 ●73 ●90 ●144 http://ericperko.com/

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

edit retag flag offensive close merge delete

Comments

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.

Eric Perko ( 2011-03-09 16:50:15 -0600 )edit

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

Aravindhan K Krishnan ( 2011-03-09 17:06:07 -0600 )edit

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

Aravindhan K Krishnan ( 2011-03-09 17:08:18 -0600 )edit

DEBUG] [1299740215.593122446, 1299651569.985552372]: MessageFilter [target=/odom ]: Added message in frame laser at time 1299651569.978, count now 5

Aravindhan K Krishnan ( 2011-03-09 17:09:11 -0600 )edit

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?

Eric Perko ( 2011-03-09 17:10:52 -0600 )edit

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

Aravindhan K Krishnan ( 2011-03-09 17:24:18 -0600 )edit

I fixed up your formatting a bit and was able to get your "Debug" Messages to display in the question.

Eric Perko ( 2011-03-09 17:29:40 -0600 )edit

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?

Eric Perko ( 2011-03-09 17:30:31 -0600 )edit

see more comments

2 Answers

Sort by » oldest newest most voted

answered 2011-03-09 16:29:26 -0600

Eric Perko

8406 ●73 ●90 ●144 http://ericperko.com/

updated 2011-03-09 17:21:09 -0600

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.

edit flag offensive delete link

Comments

Tried... Still the same warning.!!

Aravindhan K Krishnan ( 2011-03-09 16:47:05 -0600 )edit

add a comment

answered 2011-03-09 01:44:34 -0600

Ivan Dryanovski

4954 ●52 ●70 ●86 http://robotics.ccny.cuny.edu/

updated 2011-03-09 04:47:55 -0600

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.

edit flag offensive delete link

add a comment

Issue with setting tf in gmapping

Comments

2 Answers

Comments

Question Tools

Stats

Related questions

Issue with setting tf in gmapping edit

Comments

2 Answers

Comments

Question Tools

Stats

Related questions

Issue with setting tf in gmapping