Navigation stack test: GMapping vs Hector Slam

After first failed test of Geduino navigation stack using GMapping as SLAM algorithm I was curious to make tests with Hector Slam that, as shown by RoboPeak on its youtube video, works really well.

I registered real sensor data (using rosbag) from Geduino and play it running GMapping and Hector Slam in order to compare their behaviour on same data. Those are the results:

The map generated by GMapping

The map generated by Hector Slam

I was really surprised of this result: Hector Slam performs really better than GMapping!

Those two algorithms differ from the information sources used for localization and mapping: GMapping uses odometry and laser scan; Hector Slam, instead, uses the laser scan only. Theoretically GMapping should perform better then Hector Slam expecially on environments that cause laser scan estimated pose to be ambiguous (large space or long hallway without features): in those scenario GMapping can rely on odometry for robot localization. By other hand Hector Slam does not require odometry (so its a forced choice if robot does not provide it); another big advantage is that Hector Slam can work with laser mounted not planar to ground (as required by GMapping).

You can find more info on this benchmark of slam algorithm in ROS.

Since Hector Slam works fine we can assume laser scan data is ok, so I focused on odometry test: a good guide for this purpose can be found here.

This the result of this test:

The RViz output of odometry test

The robot starts from the position shown on the picture and travel to other side of the room and gone back. As shown on the picture laser scan impressions overlap quite well: this means that odometry data is consistent.

In conclusion theory is not according with real world: GMapping should perform better than Hector Slam but tests demonstrate the opposite. I will spend some time in order to study this case and found a solution since Geduino is designed to use GMapping.