0
$\begingroup$

Rosanswers logo

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


Originally posted by gong on ROS Answers with karma: 164 on 2011-06-18

Post score: 0

$\endgroup$

2 Answers 2

0
$\begingroup$

Rosanswers logo

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.


Originally posted by dornhege with karma: 31395 on 2011-06-18

This answer was NOT ACCEPTED on the original site

Post score: 2


Original comments

Comment by gong on 2011-06-27:
Thank you for your adverse. I have been record a bag and post the data and result in the following answer. By the way, in my robot the scan topic is named /scan. Here the robot is moving forward straight. Thank you for your attention.

Comment by Brian Gerkey on 2011-06-24:
If you record a bag (see http://www.ros.org/wiki/slam_gmapping/Tutorials/MappingFromLoggedData#Making_your_own_bag), and post it, then we can try running it to look for the problem.

Comment by gong on 2011-06-24:
I make ssr and str to be 0.5, but the drift still be happened.

Comment by gong on 2011-06-22:
By the way, what's the meaning of (make srr,str wider) you said.

Comment by gong on 2011-06-22:
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).

Comment by gong on 2011-06-22:
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

Comment by dornhege on 2011-06-21:
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.

Comment by gong on 2011-06-21:
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.

Comment by dornhege on 2011-06-21:
For those tests you should not use mapping/gmapping at all. I.e. do every display only using odometry in the /odom frame!

Comment by gong on 2011-06-21:
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.

Comment by gong on 2011-06-21:
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.

$\endgroup$
0
$\begingroup$

Rosanswers logo

I make a experiment as follow.

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

image description

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


Originally posted by gong with karma: 164 on 2011-07-04

This answer was ACCEPTED on the original site

Post score: 0

$\endgroup$

Your Answer

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