Even after achieving perfect global consistency, we’d have to perform a global optimization on the entire map after every update to maintain it. This adds multiple steps to our pipeline, making the process computationally heavy. While that might be manageable now, it’s not practical at scale.
Fortunately, globally accurate maps simply aren’t necessary for self-driving. Our localization system, which determines the vehicle’s location in the Atlas, doesn’t require global consistency. In fact, we can reliably determine the vehicle’s position and orientation relative to content near the vehicle much more accurately than GPS can.
Further, our Driver hardly ever needs to reason about objects that are far away, so we’re not doing the long-distance comparisons of locations that make globally-consistent data important. Our Driver only ever needs to assemble small pieces of the Atlas at a time. For example, when you’re driving to work, you’re not picturing a map of the entire city as you think about what to do. Instead, you’re scanning the road for pedestrians and worrying about changing lanes for your next turn. Experience has taught us that a precise understanding of where nearby objects (200–300 meters) are in relation to the vehicle is far more important than a globally consistent picture.
Built to Scale
Given our approach using a relative map representation to preserve local accuracy, we don’t build one large map data structure. Instead, our Atlas is sharded into pieces that we stitch together to represent larger areas, like the city of Pittsburgh. These pieces are self-contained and decoupled from one another, giving us the flexibility to update small portions without making changes to the entire map. So when a new stop sign gets added, we can just update that single piece. For reference, each piece of the Atlas is about the size of one city block.
Beyond our sharded, locally accurate design, we’ve invested in developing pipelines and tools that make the Atlas efficient. These will be hugely beneficial as we expand the Aurora Driver to new cities. For example:
- Our maps are stored in a versioned database we call the Cloud Atlas that is specially designed to hold Atlas data. Cloud Atlas, which is reminiscent of source control tools like git, keeps a complete record of all Atlas versions and allows multiple map operators to draw and edit annotations concurrently. We’ve also developed accompanying command line tools that allow us to work with Atlas data more efficiently (generating a summary of the differences between versions, retrieving only the data layers we need, etc.).
- The annotation and world geometry data layers are updated independently. That means when a city erects a new building, we simply regenerate the geometry layer and lay the existing annotations on top.
- We build and maintain custom tools that help our operations team draw accurate annotations faster.
- We’ve developed machine learning models that allow us to generate some annotations, like traffic lights, automatically.
Each element of our design interlocks to enable the “broadly” part of our mission. We can rapidly build accurate, lightweight maps in new areas and push updates from the Aurora Cloud to the on-vehicle Atlas in near-real time. We’re investing now in a robust system because we know that our success hinges on producing a high-quality Atlas at scale. This is just one more way that we’re fueling the rockets and building a strong foundation for the Aurora Driver.