| ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
I was trying to use gmapping to build a map, I've checked the odometry it was accurate.But the map was like this:
I also tried hector mapping,(with odometry and without odometry both),and the map was good.I'd like to find out what's wrong with gmapping?
the bag file can be downloaded link text
I think the problem lies in your rotated laser scanner. You have turned the frame of the scanner 90 degrees clockwise around the z-axis and changed the min_ and max_angle of your laserscan message so that the center is still pointing forward. I am just trying if i am able to fix gmapping to work under that conditions, but i am not sure, if i will succeed.
Is there any reason for that rotated laserframe? I would suggest changing your laserscan driver (btw: which model and driver do you use?) to have the x-axis pointing forward and having the range readings symmetrical to the left and right of the zero yaw-angle.
Edit: I found the real problem: Your scanner reports a field of view of 270 degrees and an angle increment of 0.5 degrees (like you mentioned). So you would expect about 540 rays per scan. But in reality there are 1081 readings in each message! So gmapping tries matching a 540 degrees field of view... There must be something wrong with your laser driver. The first 540 readings are correct, but there are another 540 zero-readings in each laserscan message.
Sorry, I didn't quite catch ya. I m using SICK LMS100 laser range finder, with 270 degree laser coverage and resolution of 0.5 degree. I checked the laser dots shown in the rviz, they fit the environment quite well after I turn the scanner frame 90 degree clockwise about the z-axis.
Yes, thats because your scanner returns this values in the message: "angle_min: -0.785398185253 angle_max: 3.92699074745" But GMapping assumes that a laser scan is centered around the x-axis of the laser-frame. Thats why its messed up. Could you post your sick-driver launch file?
GMapping is a little messy with the angles. The underlying routines dont know anything about min- and max-angles. They calculate them solely by the number of readings and the reported angle increment. This isnt very robust... (And it assumes the centered scans like i already mentioned)
Hi,Kent,i am doing 2D hector mapping,i have the same problem as the picture you posted.but your map with hector mapping was good,may i know how you did it ,especially the tf tree.btw, i have a hokuyo URG-04LX and mircostrain 3DM-GX3-25 imu,thank you in advance^^
I do not have any experiences in using the imu with hector mapping, whatever, hector mapping can be utilized without odometry but with laser data only. U may check http://www.ros.org/wiki/hector_slam/Tutorials.
the reason why my mapping overlaps is that the laser scan does not match, but i know hector mapping no need laser scan match node right? is there any way to solve it ?really appreciate you reply^^thank you.And my email is : elva2011@hotmail.sg, hope to hear from you by email:)
the problem i am facing is as long as i do not give yaw, pitch and roll motion to the lidar, the map is good but when i give these motions the map starts to overlap.... someone has told me to use the IMU with Lidar but i dnt know how to incorporate IMU data into Lidar. is there any solution ??
Asked: 2013-01-13 17:06:15 -0500
Seen: 4,016 times
Last updated: Mar 27 '13
ROS Answers is licensed under Creative Commons Attribution 3.0 Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.
Try the troubleshooting under section 2.2 here : http://ros.org/wiki/navigation/Tutorials/Navigation%20Tuning%20Guide and make sure your odometry looks good.
Could you provide a bag file of a short drive-around containing only the laser, odometry and tf information?
yep, u can download the bag at http://l3.yunpan.cn/lk/QvjJE3xNW7ABY
Dear Kent, Can you please tell me how did you check the odometry accuracy ? thanks.