Robotics StackExchange | Archived questions

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=F8pdObV_df4

Here is an example of Correct and Broken in my office using the equipment we have:

Good Map Bad Map

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:

  1. How catastrophically-ruined a map gets when it is broken even just once.
  2. 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 marginal improvement of 2% in reliability is not worth it; spending $400 to get a 50% improvement in reliability is definitely worth it.

Perhaps it is as simple as changing some of the hokuyo_mode parameters or improving some code...


We are running ROS indigo on Lubuntu 14.04.3 LTS on a Thinkpad T500 and the latest ros-indigo-hector-slam and ros-indigo-hokuyo-node. Everything has all the latest updates as of 2016-01-17.

Our only node is the Hokuyo UTM-30LX scanning laser range finder. If we are going to use an IMU, it will almost certainly be the Bosch BNO055 fusion IMU that runs about $40 and connects via I2C or UART.

The launch file we are currently using contains these parameters for the hokuyo_node:

cluster: 1 skip: 0 (I understand this selects 40Hz instead of the usual 20Hz when skip = 1) intensity: false minang: -2.2689 maxang: 2.2689


Thanks in advance!

Asked by dchang0 on 2016-01-17 05:04:29 UTC

Comments

Any update?

Asked by JamesWell on 2016-06-03 09:15:00 UTC

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.

Asked by dchang0 on 2016-06-03 11:12:46 UTC

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.

Asked by dchang0 on 2016-06-03 16:32:55 UTC

Is there any update?

Asked by LeoFSto on 2018-03-04 05:05:13 UTC

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

Asked by dchang0 on 2018-03-04 06:32:48 UTC

Any update so far?

Asked by ermanas on 2019-12-25 01:57:08 UTC

have same issue here, no update?

Asked by Ridy on 2020-08-13 22:58:12 UTC

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.

Asked by dchang0 on 2020-08-14 01:47:22 UTC

Answers