Ask Your Question
1

hector_slam w/ Hokuyo UTM-30LX breaks map when scanning chain link fence

asked 2016-02-14 03:54:23 -0600

dchang0 gravatar image

updated 2016-02-14 11:44:55 -0600

While testing our Hokuyo UTM-30LX with hector_slam, I ran into a peculiar problem. Every time I attempt to walk up to or along a chain-link fence, hector_slam gets confused and basically "wobbles" around the position where it first encounters the fence.

So, if the fence is 6 feet long, it basically cuts the 6 feet down to 0ft and only continues mapping after I have passed the section of chainlink fence.

Obviously the laser is occasionally hitting the thin wires of the fence and more often passing between them, and this is confusing the algorithm.

Is there a way to fix this? Perhaps it is by setting the Hokuyo's parameters differently (possibly the cluster parameter) or by changing the hector_mapping parameters...

We have also run into problems where a door opening or closing will break the map (I passed through a door opening it 60 degrees to walk through, and after I walked through when the door swung closed, it bent the map by 60 degrees). But this is not really a problem to be solved, since it is a moving object that just happens to look like a wall.

Thanks in advance!

EDIT: added photos/maps per Stefan's request. We have done five runs just like the above and had the map break at almost exactly the same point every time. The little purple "knot" where the "Always breaks here" bubble points is where the trajectory "wobbles" for a while until I get all the way to end of the walkway, after which it begins mapping properly again (but short about 6 feet).

image description image description image description

edit retag flag offensive close merge delete

Comments

Can you provide a screenshot of the mapping process and/or photo of the environment?

Stefan Kohlbrecher gravatar imageStefan Kohlbrecher ( 2016-02-14 09:44:02 -0600 )edit

Sure thing. I added the photos. I can post the launch files too, but they are fairly close to the defaults for hector_slam and hokuyo_node. The only big changes are skip = 0 (Hokuyo runs at 40Hz) and map_resolution = 0.100 (works best for our purposes, but we are open to change this if needed).

dchang0 gravatar imagedchang0 ( 2016-02-14 11:33:45 -0600 )edit

1 Answer

Sort by ยป oldest newest most voted
0

answered 2016-02-14 14:14:10 -0600

I think this would likely also happen if the chainlink fence was not in the scene and that the main problem is the low amount of features on the bland walls in that corridor. Motion is not observable from LIDAR alone in that part of the environment. There are a few things/tricks that can be looked into to try and improve performance (no silver bullet though):

  • Rotate the LIDAR a little to the left when traversing the corridor and make sure it sees the hedge close to the camera in the last photo
  • Put some barrels or some other features into the corridor :)
  • Increase maximum range for mapping (so parked cars or other side of street might get picked up)
  • Try to use higher resolutions for mapping as it might allow for picking up smaller features in the environment.
edit flag offensive delete link more

Comments

Thanks--when you say "higher resolutions," do you mean making map_resolution = a smaller number than the current setting of 0.100m or a larger number?

I'm guessing you mean lower (0.050m or 0.025m) and that by doing so, the laser can pick up the windows in the white wall (same height as Hokuyo).

dchang0 gravatar imagedchang0 ( 2016-02-14 14:31:26 -0600 )edit

BTW, our maximum range is the default of 60m. It SHOULD be picking up the Honda CRV in the photo, yet it is apparently not from the map. I will do another test run late tonight when fewer people and cars are moving around.

dchang0 gravatar imagedchang0 ( 2016-02-14 14:34:05 -0600 )edit

Hey, Stefan--I'm curious: would an IMU fed into hector_slam solve this problem of a featureless corridor? We could buy an IMU now but won't have odometry for at least 3 months due to circumstances. From the source code, it looks like no accelerometer readings are taken, so I am guessing no.

dchang0 gravatar imagedchang0 ( 2016-02-14 14:50:53 -0600 )edit

Odometry is not used by the system and IMU data is only used for the roll/pitch angles of the scanner. Properly integrating a constant velocity model could be done, but is quite a bit of work. Note you could try other solutions such as gmapping with laser_scan_matcher (but it might have same issue)

Stefan Kohlbrecher gravatar imageStefan Kohlbrecher ( 2016-02-14 15:42:46 -0600 )edit

Thanks, Stefan, for the answers! I'll run the test later tonight and post back soon.

dchang0 gravatar imagedchang0 ( 2016-02-14 16:00:41 -0600 )edit

No luck on any of these map_resolution values: 0.100, 0.050, 0.025. The map breaks in almost exactly the same spot in the narrow corridor with the chain link fence. Interestingly, it does not break in another corridor like it that does not have a chain link fence.

dchang0 gravatar imagedchang0 ( 2016-02-16 19:21:00 -0600 )edit

Mhh annoying :) I guess the best bed/easiest solution (if possible) is to rotate the sensor in a way that makes enough features in the environment visible.

Stefan Kohlbrecher gravatar imageStefan Kohlbrecher ( 2016-02-17 02:08:40 -0600 )edit

I'll give that a try next. All this makes me wonder--is it possible to handle this problem by using two UTM-30LXs? For instance, having "stereo scanning" or putting them back-to-back so that they achieve full 360-degree coverage?

dchang0 gravatar imagedchang0 ( 2016-02-17 02:28:28 -0600 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower

Stats

Asked: 2016-02-14 03:54:23 -0600

Seen: 323 times

Last updated: Feb 14 '16