shift in the map of gmapping

Hello everybody! This is a map in RVIZ.

we can see there is a shift from left to right in the map. The shift lead to a wrong result. I have been test the odometry data, it's ok. And the tf between /odom and /base_link is ok. Where would be the problem cause this wrong result?

edit retag close merge delete

Sort by » oldest newest most voted

I make a experiment as follow.

1. the robot is static.
2. provide corridor laser information like this:
3. suppose the robot move following x-axis from (0, 0) as a speed 0.2m/s, and provide the odom data to simulate the process. In this case, the direction of the robot is always 0 degree.

However, the result is:

If the robot have enough time for running, the trajectory would be a circle. Unbelievable!

more

If you have a structured environment (looks like it) and well behaving odometry - it should work.

So my guess is, the odometry is not OK. What did you do, when you said you tested it? Can you run the tests is this document: Navigation Tuning Guide, especially section 2.2.

more

The information you provide is very useful. I'm test the odom, as you said. The result is below here.From the figure, when can see when the robot is moving straight the odom have a drift to left. When the robot rotate 36 degree, there are two maps of an same scene.
( 2011-06-21 02:17:19 -0600 )edit
While the rotation degree is 27\18\9, there would be only a map. However, the information is not complete. The area of new sense would not display. I think the laser data may be have trouble. But the laser data is publishing without any blockade.
( 2011-06-21 03:15:02 -0600 )edit
For those tests you should not use mapping/gmapping at all. I.e. do every display only using odometry in the /odom frame!
( 2011-06-21 04:09:26 -0600 )edit
I'm readed the Guide again. You are right. I post the result below here. It seems while the robot do rotation there are something wrong with the laser data.
( 2011-06-21 14:37:06 -0600 )edit
It doesn"t look that bad. I think gmapping should be able to cope with that, otherwise you can adjust the motion model params (make srr,str wider). Is the jumping effect happening quite often? Maybe your can take a bag file of the data and review the odometry, when this happens.
( 2011-06-21 23:33:15 -0600 )edit
The jumping effect happened about every 20 seconds(it is not very precise). So if the Gmapping is working, the map will have drift at intervals. As the question's figure shows and the Guide your said, I guess the odometry between /base_link and /odom is not have a big problem. But why the tf
( 2011-06-22 02:17:41 -0600 )edit
between /map and /odom have so much drift.(I ask the question here:http://answers.ros.org/question/1269/the-tf-between-map-and-odom-is-not-static).
( 2011-06-22 02:18:51 -0600 )edit
By the way, what's the meaning of (make srr,str wider) you said.
( 2011-06-22 02:19:31 -0600 )edit

The bag file named mydata02.bag. Here is the link: https://skydrive.live.com/?cid=be9affb6b505ae53&sc=documents#cid=BE9AFFB6B505AE53&id=BE9AFFB6B505AE53!115&sc=documents

This is the map in Rviz.

This is the map which replay used the bag file.

more

So, at least one problem is that you're getting a lot of ground hits. At about 4.5m from the robot, your laser is seeing the floor. That kind of thing will cause problems with both mapping and localization. Try tilting your laser up a little bit, maybe with a small shim. Just a small adjustment should do it. Post another bag with the shimmed laser, and I'll have a look.

But I have to admit that it should be possible to filter out those ground hits with the ~maxRange and ~maxUrange parameters in gmapping, and I was unable to make that work. So there may be something else going on.

more

As you said I'm tilting the laser up. I put the bag file in the following answer. However, it seems it's not the problem of ground hits. The first reason, if that happened the map of laser would be wrong when robot is static. The second reason, as you said the ~maxRange and ~maxUrang would
( 2011-07-03 12:51:04 -0600 )edit
filter out that data.(Here the ~maxRange and ~maxUrange are 3 meters.) So, I do agree with you that there may be something else going on.
( 2011-07-03 12:53:29 -0600 )edit
Odometry in the logfile is only at 2Hz. Can you increase that frequency? tf can interpolate, but I am not sure, how gmapping handles that.
( 2011-07-04 03:28:12 -0600 )edit
I'm increased the frequency to 5 and 25Hz, but it seems do not help. I make a experiment which described at the following answer.
( 2011-07-04 20:34:11 -0600 )edit

moving straight:

rotation for 45degrees and 90degrees:

more

move straight forward:

rotation: turn left 36degree

rotation: turn left 18degree

more

This is the bag file which I'm create in my robot: https://skydrive.live.com/?cid=be9affb6b505ae53&sc=documents#!/?cid=be9affb6b505ae53&permissionsChanged=1&id=BE9AFFB6B505AE53%21115 (the file is about 15M, after several time to upload failed I put the file in skydrive.)

This is the map in Rviz.

This is the map which replay used the bag file.

more