ROS Notes: Hector SLAM Creates 2D Map From 3D Motion

hector_slam
page detailing multiple frames of reference for a robot base. It turned out to be unnecessary for the GMapping algorithm I'm currently using for Phoebe, but it made me curious enough to take a closer look.
I have yet to try using hector_slam
on Phoebe. I'm only aware of it as an alternative SLAM algorithm to gmapping
. The two systems make different trade-offs and one might work better than the other under different circumstances. I knew hector_slam
was the answer when some people asked if it's possible to perform SLAM without wheel odometry data, but I knew there had to be more to it. The requirements for multiple frames is my entry point to understand what's going on.
My key takeaway after reading the paper: gmapping
is designed for a robot working strictly in flat 2D. In contrast, hector_slam
is designed for platforms that may move about in 3 dimensions. Not just flat 2D, but also ground vehicles traversing rough terrain (accounting for pitch and roll motions) and even robotic aircraft. Not requiring wheel odometry data is obvious a big part of supporting air vehicles!
But if hector_slam
is so much more capable, why isn't everyone using it? That's when we get to the flip side: for good results it requires a LIDAR with high scan rate and high accuracy. Locating robot position without wheel odometry is made possible by frequent distance data refreshes (40 Hz was mentioned in the paper). Unfortunately, this also dims prospect for use aboard Phoebe as the Neato LIDAR is neither fast (4 Hz) or accurate.
And despite its capability to process 3D data from robotic platforms that have 3D motion, hector_slam
generates a 2D map. This implies the mapping navigation algorithms will not have access to captured 3D data. Plotting a path with this data, a short and rough route would look better than a longer smooth flat route. This makes me skeptical hector_slam
will be interesting for Sawppy, but that's to be determined later.