Ask Your Question

"SearchDir angle change too large" kills hector_mapping

asked 2013-05-03 20:08:41 -0500

Ernest gravatar image


I've noticed that when sharp pose changes occur on my laser frame, the following error sometimes appears & kills hector_mapping:

SearchDir angle change too large

I was wondering: what exactly causes this, and if it is indeed linked to an unfeasible change of pose or laser scan data, what are the precise constraints on hector_mapping?

Thank you very much!


edit retag flag offensive close merge delete

3 Answers

Sort by ยป oldest newest most voted

answered 2013-05-04 01:44:50 -0500

Specifying precise constraints is hard, as there are a multitude of factors that influence performance and can lead to things going well or not so well. The error message generally indicates that the scan alignment optimization step produces a unusually large angle change, making it very likely that it ends up with a wrong pose estimate. This normally shouldn't happen, but depends on the environment, sensors and motion of the platform. As seen here, the system works largely without problems even in challenging environments for us. For this reason, not a lot of work was put into catching scan matching failures. There certainly is some room for improvement in that regard, though and you could look into improving things for your robot.

What kind of sensors do you use and when do you see issues?

edit flag offensive delete link more


Hi Stefan, yes I'm a big fan of that video! We are using a Hokuyo UTM-30LX. The problem happens when the LiDAR is subject to sharp pose changes, like when our platform runs into an obstacle... we're hoping we'll be able to avoid that situation (from HM's map & a Kinect) but in case it does:

Ernest gravatar image Ernest  ( 2013-05-07 15:15:15 -0500 )edit

do you have any tips to save the "state" of hector mapping & restart it?

Ernest gravatar image Ernest  ( 2013-05-07 16:11:28 -0500 )edit

The full internal state consists of the (multi-level) map and the current pose estimate of the robot. You could occassionally copy that and revert back to an earlier state if you detect a problem. Probably makes sense to either mail me directly or start new question about that.

Stefan Kohlbrecher gravatar image Stefan Kohlbrecher  ( 2013-05-07 20:28:01 -0500 )edit

OK - I have started a new question about that here: Thank you very much for your time, Ernest

Ernest gravatar image Ernest  ( 2013-05-08 10:03:29 -0500 )edit

answered 2017-08-11 09:42:29 -0500

Goldie gravatar image

updated 2017-08-11 12:52:36 -0500

Hi, even tho this question is pretty old, I had the same struggle and couldn't find something helpful. I solved the problem now and I hope I can help other people by sharing my solution:

probably your tf to scanmatch is too slow (static_transform_publisher x y z yaw pitch roll frame_id child_frame_id period_in_ms) and you simply have to set a lower value for period_in_ms than before, e.g.

<node pkg="tf" type="static_transform_publisher" name="map_scanmatcher_broadcaster" args="0 0 0 0 0 0 map scanmatcher_frame 5"/>
edit flag offensive delete link more

answered 2018-03-07 04:18:21 -0500

Alaa Hesham gravatar image

updated 2018-03-07 04:19:46 -0500

I was facing the same problem , the solution was I removed ros::spin(); from the function that I am subscribing to and just left the (ros::spin()) in my main function. What makes me think of this solution is that ros::spin() makes the loop repeats more frequently and since hector was flying , the data have not its enough time to be processed so to make the data takes its time to grasp the change I have removed ros::spin().

edit flag offensive delete link more


where is the ros::spin() function?

fyi gravatar image fyi  ( 2019-04-24 11:21:05 -0500 )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


Asked: 2013-05-03 20:08:41 -0500

Seen: 2,789 times

Last updated: Mar 07 '18