GMapping not parallel corridors
Hi,
I am using GMapping to map a floor that has two parallel corridors. I have set the linearUpdate=0.05, angularUpdate=0.05 and the map_update_interval=2.0. Otherwise I have left all of the remaining parameters as default values. When I mapped these two corridors I got this result:
As you can see, the two corridors that are supposed to be parallel are very much not. Furthermore, I must add that at the beginning of each corridor, there is a ramp that is inclined at, perhaps 15 degrees from the plane. Of course, this is not captured in the 2-D map, but I thought perhaps it is affecting my odometry and thus the error accumulates to create these skewed corridors.
What can I do to resolve this? I read that maybe I should lower the values of srr, srt, str and stt, or perhaps tweak the sigma parameter...but I haven't understood probably what these are supposed to do. So I appreciate any help to help me figure out what these are used for and how they can help me reduce my error in mapping this environment.
Thanks a lot. RND.
This pretty much depends on your odometry data. What laser sensor are you using. What is the range. You can try to increase the number of particles in the gmapping node to around 200 and try again. It will be good to save a bag file and try different values for parameters in gmapping by playing bck.
the odometry data seems to work fine in other scenarios (such as mapping our lab gave me no trouble). I tried to do as you said and increase the particles but the situation got worse and one of the corridors had a huge kink in it. Can this be because I have no loop closure in this environment?
@AlexR can you please help me understand why moving forward and turning on the spot by 360 degrees produces this result? Any help is very much appreciated.
The corridors are always a tricky area for mapping. Because of similar wall features and repetitive pattern the mapping is affected. A good solution to solve such problem is to use a long range sensor with a good odometry estimate and other sensors like the gyro to compensate for the wrong feature .
.. matching. You can also try to use the Hector mapping package which is a odometry free mapping and produces good results. Also I would suggest you to put boxes around the corridors, and try to close the loop to see how much the map drifts. Also make sure to move the robot very slowly.
Thanks a lot! so it's due to scan-matching that when the robot turns by 360 on its own axis, the map is messed up and ruined? I cannot understand why I cannot revisit certain places without the map being ruined. Is this bad odometry? I've checked and my odometry estimates seem accurate.
I am not sure what might be wrong with your system. Typically, p3dx has a good odometry and with a long range sensor produces quality maps. I can recommend you to try calibrating your robot's odometry.