shift in the map of gmapping

asked 2011-06-18 08:39:35 -0600

gong
164 ●9 ●9 ●13

updated 2014-01-28 17:09:52 -0600

ngrennan
1 ●1 ●1

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?

Thank you for your attention.

image description

edit retag flag offensive close merge delete

add a comment

0

answered 2011-07-04 20:29:33 -0600

gong
164 ●9 ●9 ●13

updated 2011-07-05 00:00:17 -0600

I make a experiment as follow.

the robot is static.
provide corridor laser information like this:
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:

image description

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

edit flag offensive delete link

add a comment

2

answered 2011-06-18 09:58:38 -0600

dornhege

31395 ●134 ●284 ●498

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.

edit flag offensive delete link

Comments

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.

gong ( 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.

gong ( 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!

dornhege ( 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.

gong ( 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.

dornhege ( 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

gong ( 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).

gong ( 2011-06-22 02:18:51 -0600 )edit

By the way, what's the meaning of (make srr,str wider) you said.

gong ( 2011-06-22 02:19:31 -0600 )edit

see more comments

0

answered 2011-06-27 19:07:38 -0600

gong
164 ●9 ●9 ●13

updated 2011-06-27 19:24:41 -0600

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. image description

This is the map which replay used the bag file. image description

edit flag offensive delete link

add a comment

0

answered 2011-06-21 02:25:15 -0600

gong
164 ●9 ●9 ●13

updated 2011-06-21 03:13:18 -0600

move straight forward: image description

image description

rotation: turn left 36degree

image description

rotation: turn left 18degree

image description

edit flag offensive delete link

add a comment

0

answered 2011-06-21 14:37:16 -0600

gong
164 ●9 ●9 ●13

moving straight:

image description

rotation for 45degrees and 90degrees:

image description

edit flag offensive delete link

add a comment

0

answered 2011-07-01 12:02:54 -0600

Brian Gerkey
2916 ●22 ●23 ●34

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.

edit flag offensive delete link

Comments

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

gong ( 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.

gong ( 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.

dornhege ( 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.

gong ( 2011-07-04 20:34:11 -0600 )edit

add a comment

0

answered 2011-07-03 12:32:54 -0600