Bad map on rviz using gmapping

Question

Hello,

I'm quite new with ROS and it's been a few weeks that I'm actually facing a problem I can't manage to solve. I'm trying to creta a map from a robot's sensors data and visualize it on rviz, so nothing especially exotic.

As it is for test purpose, I simulate the robot on my computer. The data seem correct as well as the tf tree. However, when I try to see the result on rviz I get something wrong. The test map is actually a simple straigth corridor and the robot is just moving forward until the end. What I get on rviz is not so far from the actual map but there are holes between the segment, just like if it creates the map only at each new square of the grid. I unfortunately can't post pictures for now (I need 5 points or something ?)

I've read tons of topics on the subjects but I did not find anything that helped me solving this problem. If feel rather desperate about it.

If anyone can see what goes wrong, you would help me a lot !

Thank you.

---

Originally posted by Pandacool on ROS Answers with karma: 16 on 2017-04-23

Post score: 0

---

Original comments

Comment by Geoff on 2017-04-23:
Is your map just a blank corridor? No doors or any obstacles? Such a map lacks enough features for good localisation and map building, which may explain what you're seeing. It's hard to tell without pictures or seeing your source. Can you post your launch files, map, etc.?. Use dropbox or something.

Comment by Pandacool on 2017-04-24:
Thank you for answer. It is actually a blank corridor with nothing else than the walls and the ground. Here is a screenshot of rviz. https://drive.google.com/open?id=0B1cH0l8kxYjZR2lORldfaG96d3M As you can see, the odometry ans the display of the map seem correct but there are those "holes".

Comment by Geoff on 2017-04-24:
The map looks very odd. Can you post your source files so we can test it out?

Comment by Pandacool on 2017-04-25:
Unfortunately, we use a locally developped simulator to simulate the robot so you won't be able to use most of the code. Here is a part of the ros related code, concerning the messages sent trough ros. https://drive.google.com/open?id=0B1cH0l8kxYjZY3daQklkLXpJcnc

Comment by Pandacool on 2017-04-25:
I think that if the error comes from the code, it can only comes from this part. The tf transform works and is correct (I can add it if you need) and the messages are sent to ros without any error. Also, concerning odometry, the simulator cannot simulate it yet so I just made it simply move forward.

Comment by Pandacool on 2017-04-25:
I thought maybe the problem comes from odometry but it looks fine on rviz so I don't know wath goes wrong. I checked the values of my sensors and they seem correct (near 0 on the sides because of the walls and 1 in front and in the back)

Comment by Geoff on 2017-04-26:
Since you can't post the simulator, can you instead record a bag file of all topics and post that? Also, we need to see your full source, not extracts, so that people can try to replicate your problem.

Comment by Pandacool on 2017-04-27:
Sorry for the delay. Here is the code https://drive.google.com/open?id=0B1cH0l8kxYjZTmgtdXpTY1JXYk0 and here is the bag file https://drive.google.com/open?id=0B1cH0l8kxYjZbjF2ZUVYZHZUNlk

Comment by Geoff on 2017-04-28:
I am curious if the bag files are the complete system. The transforms between odom and the laser scan frame are missing, and nothing is ever published on /tf or /tf_static. Are you recording everything? Could you post your complete system setup?

Comment by Pandacool on 2017-05-02:
Sorry I missed the comment. And sorry again, I only recorded odom and laser scan, do you also want me to record the tf ? I can also post my tf tree if you need it.

Comment by Pandacool on 2017-05-02:
here is a bag with the tf https://drive.google.com/open?id=0B1cH0l8kxYjZdUt3UXR1ZlpvMEE

Answer 1

Hello,

I'm still stuck with this problem. I found out that if I specify _linearUpdate:=0.5 when running gmapping the result is slightly better but there are still holes and if I ty to set some lower values like 0.3 or something it does not work anymore. I really don't understand why rviz obstinate itself to show the update every meter (or half-meter with 0.5) which is what produces holes because my robot is very small.

If anyone has an idea, don't hesitate.

EDIT: ok so I tested with a fake robot that just produces the data I want (to simulate a robot moving at constant speed in the straight corridor) and there is still this gap problem. So as the code is the same as in the tutorials and I produce myself the data, I guess there is a problem with gmapping options. Is there something to force the update like in real time ?

EDIT 2: ok I found what was wrong, the scans were either very good or very bad, I ran gmapping with minimumScore = 50 and everything worked fine

---

Originally posted by Pandacool with karma: 16 on 2017-05-21

This answer was ACCEPTED on the original site

Post score: 0

---

Original comments

Comment by Humpelstilzchen on 2017-05-21:
Can you provide a video?

Comment by chwimmer on 2017-05-22:
Your are right. GMapping is only updating the map when you drive a minimum distance specified by the parameter linearUpdate (float, default: 1.0) Process a scan each time the robot translates this far

What happens actually when you set it lower than 0.3? What doesnt work?

Comment by Pandacool on 2017-05-22:
Here it is https://drive.google.com/open?id=0B1cH0l8kxYjZNzg1MkIzY0V6Z00 the size of the map on rviz corresponds more or less to the size of the map in the simulator if you wonder about that.

Comment by Pandacool on 2017-05-22:
if I try to set the parameter to 0.3 only the first scan appears on rviz then nothing else

Comment by Pandacool on 2017-05-23:
actually to be more precise, when I try with 0.1 for example, it seems that all scans are printed on top of each other on rviz so it is completely mixed up