Cartographer_ros: Using Cartographer without an odometry source

[musi00]

Hello Cartographer Team,

This issue is a follow up on the closed issue #628.
We are trying to optimise cartographer's parameters to run on several bags of different size maps. Our robot does not have an IMU so the only sensors we can use are differential odometry and laser scans. Our problem is that odometry has significant error during turns. The suggestions that you made in (https://github.com/googlecartographer/cartographer_ros/issues/628) of decreasing the number of scans per submap did not work in all cases. In particular in this fairly small map there were double walls and it seemed to get worse as I decreased the num scans/submap:
30 scans/submap

5 scans/submap

Off course, reducing the laser max range to 10m as you had suggested in #628 improves the results a little but the double walls are still present. However, we would like to keep the range at the actual laser max range of 20 as this gives better results in wide open spaces.

In order to deal with the odometry error, I have the online scan matcher enabled so in theory any errors in odometry should be corrected. I've tried the following parameters:

use_online_correlative_scan_matching = true,
real_time_correlative_scan_matcher = {
    linear_search_window = 0.1,
    angular_search_window = math.rad(30.),
}

I've also tried linear_search_window of 0.2 and angular_search_window of 60 degrees but did not notice any improvement.

Throwing out Odometry

The next solution I tried is to ignore odometry and just rely on the online scan matcher (real time correlative) to provide visual odometry instead. This solved the double wall issue for this bag file as the image shows:

Here are the parameters I used:

use_online_correlative_scan_matching = true,
real_time_correlative_scan_matcher = {
   linear_search_window = 0.1,
   angular_search_window = math.rad(5.),
}
submaps = {
    angular_search_window = math.rad(30.),
}

However, I tried to use the same parameters on a much larger map and the result was very poor:

Related Questions

1. I wanted to confirm my understanding of how the submaps are built. Basically scan1 comes in forming initializing the submap, scan 2 is added to the submap after using the ceres-scan-matcher to find the pose of the scan relative to the submap. Now scans 1 and 2 form the submap and the process repeats until the configured number of scans / submap is reached. Offcourse extra information maybe used as an initial estimate to the ceres-scan-matcher such as odometry/imu or if the use_online_correlative_scan_matching is on then this will be used for every scan prior to using the ceres-scan-matcher. Is this correct?
2. Why is the result so bad when odometry is ignored. Shouldn't the real_time_correlative scan matcher act as a source of visual odometry which should be pretty accurate? Is it returning wrong poses due to some symmetry in the environment? Any suggestions on parameter turning are welcome.
3. Why can't the online scan matcher correct the odometry error? Probably the same answer as the previous question

Required Data

1. Gist Files: Bag files look ok, the gist of the cartographer bag validate for the the small map and large map are includd below: I am only using the front laser.

Gist for small map:
https://gist.github.com/musi00/1467d203e4341035a91f15aa5382dca1

Gist for big map:
https://gist.github.com/musi00/a99f7f911cd22d77a87dcfa0387b2540

1. Link to repo: I have a catkin package that has all the configuration files that were changed along with a map saving node. You could launch it using:
   roslaunch avidbots_cartographer_mapping offline_mapping.launch bag_filenames:=${bag_file_name}
   https://github.com/musi00/cartographer_mapping

2. Bag files:
   Small map: https://drive.google.com/file/d/1_qqyGnofPWqAA7MMvWe72O5DzetH-Sz-/view?usp=sharing
   Big map: https://drive.google.com/drive/folders/176GzjRjfo0hIFcQl8tXC5HLBk8tJKUax

[MichaelGrupp]

Here are a few cents from my side (I'm not a maintainer though):

1. This is more or less how it works. See also the documentation about the scan matchers.

2. If you set use_online_correlative_scan_matching = true, the initial guess (pose prior) for the Ceres scan matcher is based on a scan to submap match (see docs) instead of an extrapolated pose. This approach can fail for example if there are ambiguities in your local environment (i.e. not enough distinct, robust features) that yield a wrong search result of the real time correlative scan matcher. I also wouldn't call it visual odometry (visual odometry is commonly used as a term for motion estimation from camera images).

3. Your map of the large environment seems to have a big area of free space, where your laser scanners are likely to approach the limit of their range? This would be a typical environment where it's probably more reliable to trust a pose prior from extrapolated odometry/IMU data instead of the real time correlative scan matcher. The Ceres scan matcher is quite sensitive to bad priors.

Also: Did the large jumps in the map occur during global optimization? Or did you deactivate the global optimization as suggested in the tuning guide?

[musi00]

According to the tuning guide: "This scan matcher is very expensive and will essentially override any signal from other sensors but the range finder". It seems to be saying that if use_online_correlative_scan_matching = true then odometry is simply ignored. However, I get different results when I use odometry + real time scan matching vs when I only use real time scan matching. If the configuration is documented correctly, I should be getting the same result since the scan matcher overrides the odometry pose (I assume that is what you mean by the extrapolated pose).

[MichaelGrupp]

This is probably because the odometry data is still used in the optimization problem. See also our RFC draft where we discuss whether to change this: https://github.com/googlecartographer/rfcs/pull/9

[ojura]

"Essentially" is a bit wrong term there. You _can_ use online correlative scan matching to "improve" bad odometry, as this odometry is fed to the pose extrapolator. The pose predicted by the pose extrapolator is used as the initial pose in the correlative scan matcher.

Also read this for some more insight:
https://github.com/googlecartographer/cartographer/issues/690

[gaschler]

Agree with @MichaelGrupp, please tune for local slam only first as documented in http://google-cartographer-ros.readthedocs.io/en/latest/tuning.html

Another thing is you say you are only using "the front laser". Cartographer will perform better if it can see in (almost) every direction. Use all lasers you have.

I am closing this as answered. Feel free to re-open.