Skip to content

Experimental Lifelong Mapping Node

Steven Macenski edited this page Sep 18, 2019 · 1 revision

Lifelong mapping

Lifelong mapping is the automated process of not only being able to continue mapping from a prior map, or remapping a pre-mapped area, but also decaying extraneous, old, or otherwise redundant data from our pose-graph over time. This allows for a living, breathing map and removed the dependency on localization. It additionally goes hand-in-hand with a multirobot and cloud-based mapping solution to continue to refine a map over time with many agents in an environment for them all to share.

Cartographer will refer to lifelong mapping as just remaping / continue mapping an area. I give you that capability batteries included in the asynchronous and synchronous mapping modes. When I refer to lifelong mapping, I refer to that capability and the capabilities with the hueristics to remove "extra" information stored to bound computation time to search for loop closures, optimize, and scan match which would otherwise grow unbounded proportionally to the number and density of nodes in the pose-graph.

How?

Inside the lifelong mapping node, I've computed a heuristic as an objective function. This is a function of things like: amount of area overlap between the bounding region of readings, the amount of that area overlap as a proportion of laser readings, the intersect over union metric which is very popular in machine learning, the number of constraints on the candidate scan to decay, and the last score for a recursive update. If our scans have decayed below some threshold, we remove them and all of their constraints from the map.

Why so experimental?

Well this is hard, and very hard to generalize. I can't promise that it will work great in your environment, but I'm dedicated to making it work. Please file PRs and tickets with updates and problems so we can make it work the best it can. The heuristic was hand engineered and by no means perfect, if there's better/more information you'd like exposed to make a decision on scoring a candidate for removal, lets build that.

Additionally, there's an open question in my mind about what to do with the constraints on the nodes we decay. The state of the node today is that those constraints are lost when we remove the node, but that the objective function should be tuned such that nodes that act as key points aren't decayed as easily as to not lose structure in your map. However I'm not totally convinced that's the best way to go, potentially when we decay a node we assign its constraints to its neighbors to retain its information about relationships in the local neighborhood. If this sort of thing interests you feel free to reach out and lets collaborate on a solution.

Clone this wiki locally