Prevent broken/overlapping maps w/ hector_slam & Hokuyo UTM-30LX?
We are working on mapping indoor spaces like office buildings at walking speeds, first with humans, much later with semi-autonomous carts, and much, much later with fully-autonomous ground robots. We are using hector_slam with a Hokuyo UTM-30LX without any IMU at this time. Odometry will never be available to the humans. Our goal is to produce accurate 2D floor plans including furniture and semi-permanent obstacles like plants, etc.
It is crucial that we don't break the map--ever. By breaking the map, I mean when some event occurs during a run that ruins what is supposed to look like a 2D architectural floor plan when the whole floor has been mapped. A perfect run would produce an unbroken map like in this video:
https://www.youtube.com/watch?v=F8pdO...
Here is an example of Correct and Broken in my office using the equipment we have:
We broke this map on purpose by rotating the Hokuyo a bit too quickly for it to handle. (The red area in the Correct map is a false positive from a mirror on the wall. This may or may not cause breaks in the map--we haven't tried to figure that out yet.)
The axes in both images are the same spot, but due to the broken map's overlapping rotations, it looks like the axes are in the wrong spot.
What is surprising to us is:
- How catastrophically-ruined a map gets when it is broken even just once.
- How easy it is to break a map (any sharp movement, walking too fast, tilting the LIDAR too far, etc.)
What this means is that in one run of a large office, we could make one mistake, break the map, and end up having to start all over, wasting valuable time.
So, we are wondering: are there ways to protect against or prevent breaking the map? Right now, assume that we are constrained to using human walkers walking 1.5m/s holding the LIDAR in their hands or wearing them on a backpack or chest rig, and odometry is not available. We're not expecting perfect protection, just reasonable protection. For example, if the human walker trips and falls over, that's a do-over run.
I am assuming the addition of an IMU (especially the accelerometer) may add some protection against sudden, sharp, fast movements, but I do not know if this is true. If anyone can confirm this, please do.
We are also considering breaking up the mapping into shorter segments where ruining one segment does not ruin the rest, but we would have to "stitch" the good runs together into a complete 2D floor plan at the end, and we have no idea how to do this.
Any ideas are welcome to basically make the mapping run more robust/resilient. We're open to adding equipment within reason so long as it gets us more "insurance" against breaking the map without breaking the bank. Spending $5000 on an additional sensor to get a ...
Any update?
Yes and no.
We never found any settings that magically made the mapping more resilient.
But, I did figure out that persons moving around the mapper or persons moving close to the mapper would dramatically break the map. We defeated this by raising the LIDAR up above most humans' heads.
I also confirmed that the skip: 0 results in 40Hz scanning and that this is a good thing (unless intensity is true). The min_ang and max_ang shown are apparently the hector_slam defaults. The setting that seemed to produce the largest change in map resilience was map_resolution.
Is there any update?
There's no fix for this per se.
HOWEVER, we did learn quite a few tips that kept the maps from breaking:
1) watch out for mirrors or other reflective surfaces 2) slow down your walking and rotational speeds 3) make sure there are no other moving objects/persons around
Any update so far?
have same issue here, no update?
No update. We gave up on the project before we bought an IMU. I suspect that the IMU would have helped quite a bit, but it would not have prevented all breaking of the map. We also looked at the Google backpack and they used two Hokuyo LIDARs and a high-end IMU. I think their solution is the minimum to solve the problem. We didn't have the budget to match their equipment.