Cartographer_ros: Global SLAM vs Local SLAM

Created on 3 Aug 2018  Â·  17Comments  Â·  Source: cartographer-project/cartographer_ros

Hi,
I have a conceptual doubt. Let us consider the following scenario.
I setPOSE_GRAPH.optimize_every_n_nodes = 100
and TRAJECTORY_BUILDER_2D.submaps.num_range_data = 1e11

i.e. by setting the second parameter very high, I make sure that in my environment there is only one submap which coincides with the global map. I do so because, for the moment, I just want to concern myself with Local SLAM.

How is POSE_GRAPH.optimize_every_n_nodes going to affect the overall pipeline? If I set this 0 then it means I am not doing any global slam and just relying on the local slam. But if I set it to some non zero positive integer(say 100). What does it mean? Will it try to do some loop closure within the only submap present? For me it deteriorates the result and the result looks better with this param set to 0. Can some one please explain why is it so?

Besides this I have normally seen in most of the demo files that, the above two parameters are normally set to be equal, is it something which is generally expected?

Most helpful comment

Yes, but that's local SLAM. The weights I was talking about are the weights for odometry in the pose graph. Cartographer uses odometry/imu data twice: first during local SLAM, in the _pose extrapolator_ which outputs a prior for scan matching. The second use is in global SLAM, when optimizing the pose graph. My experience is that local SLAM (_intra_ submap constraints) + loop closures (_inter_ submap constraints) alone are better than also using odometry during pose graph optimization.

All 17 comments

Loop closures are not the only thing affecting the optimization problem. In this case you certainly don’t have any. You also have IMU and odometry data, along with local slam poses, which are inserted as „intra“ constraints.

Having a single submap is weird, though. You can also set the constraint builder sampling ratio to zero to disable generating loop closures, while still having regularly sized submaps.

Check out the following lines:
https://github.com/googlecartographer/cartographer/blob/b841ebf170ad4e8c5d8dc731bd28c2fece1ad005/configuration_files/pose_graph.lua#L66-L71

E.g. the rotation and acceleration weight parameters affect how strongly the IMU is used to smooth out the trajectory initially built by local SLAM.

Thanks @ojura for your prompt answer! But for me, using no submaps and turning off global optimization gives better results. Is there any guide on tuning the parameters mentioned in :
https://github.com/googlecartographer/cartographer/blob/b841ebf170ad4e8c5d8dc731bd28c2fece1ad005/configuration_files/pose_graph.lua#L66-L71

My range scan has a very low FOV (60 degree) and I use just wheel odometry at the moment, do you have any tuning guide for such a scenario?

And I took your suggestion of setting POSE_GRAPH.constraint_builder.min_score = 0.0
And

POSE_GRAPH.optimize_every_n_nodes = 100
TRAJECTORY_BUILDER_2D.submaps.num_range_data = 100

And I see some sort of global optimization taking place which screws the map with time.
I have normally seen in most of the demo files that, the above two parameters are normally set to be equal, is it something which is generally expected?

From my experience with a Pioneer P3-DX without an IMU, using odometry in the pose graph sucks. Try setting odometry_*_weight to zero.

But for me, using no submaps and turning off global optimization gives better results.

Yeah, but using a single submap still makes little sense. Trajectory optimization should be a no-op if you have many submaps and no loop closures. As I mentioned, try setting the odometry weights in pose graph to zero, it should behave sanely then.

Also, I was referring to setting the constrain builder sampling ratio to zero, not the min score. Setting min score to zero will give you the opposite effect, lots of loop closure constraints!

Makes sense. Let me try with these suggestions.

For the record, I am using the real time correlative scan matcher also because it gave me superior results. And I dont trust my prior to the local SLAM scan matcher so I set

TRAJECTORY_BUILDER_2D.ceres_scan_matcher.translation_weight = 5
TRAJECTORY_BUILDER_2D.ceres_scan_matcher.rotation_weight = 0.1

Isn't it same as giving low preference to Odometry?

Yes, but that's local SLAM. The weights I was talking about are the weights for odometry in the pose graph. Cartographer uses odometry/imu data twice: first during local SLAM, in the _pose extrapolator_ which outputs a prior for scan matching. The second use is in global SLAM, when optimizing the pose graph. My experience is that local SLAM (_intra_ submap constraints) + loop closures (_inter_ submap constraints) alone are better than also using odometry during pose graph optimization.

I have some follow up questions.

First, the pose extrapolator: does it contain the odometry pose or the cartographer optimized pose? Or till time t-1 it has the optimized pose and at time t(at which the odometry comes in) it has the odometry pose?

Second, I thought that the global slam does not use any odometry result and just uses the local slam optimized scan position, the associated scans and the submap position. Why does the global slam use odometry?

Pose extrapolator is simply filled up with IMU/odometry measurements. During scan matching, it provides a prior pose.

For your second question, here's the PR which introduced that, maybe you'll understand their motivation: https://github.com/googlecartographer/cartographer/pull/456. I remember that one well because I had to patch it out, since it yielded worse results for me.

@ojura also I think the local slam pose estimate is pushed into the extrapolator, https://github.com/googlecartographer/cartographer/blob/3f3428e8d437f5d8172238dddec1878efe82f671/cartographer/mapping/internal/2d/local_trajectory_builder_2d.cc#L244

Thanks for referencing me to the second link, I will take a look.

@ojura If we just consider Local SLAM, Wouldn't the following block diagram broadly summarize the logical flow of the process. Submap is named as Map here.
capture

Yes, that's it. The terminology for the scan matched pose would be a "local pose" (we call optimized poses those which have been optimized by global SLAM). The map updater is a "range data inserter".

Also, each scan is inserted into two most recent submaps (except at the beginning, when we only have one submap). Scan matching is performed against the second last submap (the more complete one).

There's a similar diagram here: https://google-cartographer.readthedocs.io/en/latest/

Okay that's cool!
Although I understand why the scan matching is done against the second last submap, I don't understand why the range scan is also inserted to the second last submap? Shouldn't it be only inserted into the last submap? And if the range is inserted into both the last and second last submap, then at the end of local slam process, are both the submaps updated or only the last one is updated?

Inserting the scan is the same as updating the submap, not sure what you mean by „updating at the end of the local SLAM process“.

Inserting the scan to two submaps ensures there‘s a nice overlap between them. If the submap size is 100 scans, it will look something like this:

Scan no. | Event
0 Submap 0 started
50 Submap 1 started
100 Submap 0 finished, submap 2 started
150 Submap 1 finished, submap 3 started
Etc.

So each submap shares 50% of its scans with the previous submap and the other 50% with the next submap. When global SLAM closes loops, the submaps are repositioned and reoriented, and I think having them overlap with each other yields less artifacts at submap borders, when you display the complete map made by superimposing all submaps. Perhaps there‘s another reason, one of the maintainers might know more.

Thank you! This answers a lot of questions. I do understand that inserting a scan is same as updating a submap. But I didn't know about the overlap thing. Thanks.

Thanks, @ojura, for sharing your knowledge. I am closing this as answered.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

cagataysari picture cagataysari  Â·  6Comments

woshidaye picture woshidaye  Â·  5Comments

gaschler picture gaschler  Â·  8Comments

aalapshah12297 picture aalapshah12297  Â·  5Comments

shreyasgokhale picture shreyasgokhale  Â·  5Comments