ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question
0

"SearchDir angle change too large" kills hector_mapping

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

Ernest gravatar image

Hi,

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!

Ernest

edit retag flag offensive close merge delete

3 Answers

Sort by ยป oldest newest most voted
2

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

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

Comments

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 -0600 )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 -0600 )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 -0600 )edit

OK - I have started a new question about that here: http://answers.ros.org/question/62407/how-to-save-the-state-of-hector_mapping-in-case-it-fails/ Thank you very much for your time, Ernest

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

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

Goldie gravatar image

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

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
0

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

Alaa Hesham gravatar image

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

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

Comments

where is the ros::spin() function?

fyi gravatar image fyi  ( 2019-04-24 11:21:05 -0600 )edit

Question Tools

Stats

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

Seen: 3,136 times

Last updated: Mar 07 '18