Edge Mapping: Our Journey from Trains to Self-Driving Cars

By Sravan Puttagunta, Co-founder & CEO of Civil Maps

The story of Civil Maps did not begin with cutting-edge self-driving cars, but with old-fashioned trains. The story is worth sharing, as it helps explain our unique approach to solving many of the toughest mapping and localization challenges facing the autonomous driving industry today. Specifically, our early experiences influenced how we think about scalability and usability with regards to our cognition software and how it would be deployed under very real constraints such as cost, storage, bandwidth, and energy use. Within the industry, these constraints are gradually gaining more attention, as CFOs scrutinize spending in AV program budgets. They are seeing that recurring mapping and localization related-efforts quickly add up to hundreds of millions of dollars each year just to collect, process, and distribute map data between cars and over the air. While HD maps and localization are critical to safe autonomous driving and surely deserve significant resource investments, we think there are more efficient, cost-effective ways to achieve these goals.

Railroad Operators, Our Early Adopters

In 2013, we secured our first contracts with railroad companies who were dealing with serious data management issues while trying to create 3D maps for their train control algorithms. Back then, we were a team of only five people, sharing desk space at accelerator programs run by U.C. Berkeley (SkyDeck) and Stanford (StartX). Our heavy-industry customers with small-scale deployments were generating roughly a few terabytes of data each day. Their internal R&D and information technology teams were not prepared to handle this, and they were falling behind their processing schedules. When working with us, they would send our team the collected point cloud data on hard drives or they would upload it to our cloud infrastructure. While our platform was faster than manual/human processing, we soon discovered that even cloud-based infrastructure logistics were overwhelmed by the large amounts of inbound 3D point cloud data. Throughout the railroad industry as well as other heavy industries, this kind of raw, geospatial data often sat in warehouses for months and the delays affected safety, since the data could not be processed fast enough to produce accurate, up-to-date maps. The environment would change between the period of the data collection and when the maps were actually published. Consequently, they were not able to achieve certain Positive Train Control milestones (U.S. law passed by Congress for train safety).

From Cloud-Based, Asynchronous Processing Towards the Edge

In response, we made a pivotal decision to shift our product roadmap from a cloud-based mapping solution to edge-based map creation, processing the map data in-vehicle, near the actual source. With autonomous vehicle research programs ramping up in the U.S. and Asia, we soon found a new type of client beyond railroad operators — automakers and mobility companies. Seeing the greater challenge with the millions of miles in public roads and millions of cars versus thousands of miles of train tracks and thousands of locomotives, we decided to focus our technology on enabling self-driving cars. Specifically, we set out to develop software that could provide autonomous vehicles with cognition, similar to the mental routines in biological cognition.

At this time, these new clients were dependent on very data-heavy base maps. Many companies use base maps to help their cars localize and navigate. They are known throughout the industry as the “building blocks” upon which data layers can be added, such as map updates. A “heavy” map of a city can easily consist of several terabytes of data. For example, a map of San Francisco, which is only about 4,000 kilometers, can take up to 4 terabytes. While it is certainly possible to process large amounts of data for maps in the cloud or the edge, it requires a more substantial, ongoing investment in infrastructure, such as server farms and/or expensive compute capabilities. Based on experiences, we didn’t consider that to be a practical solution. We knew that edge processing with a leaner base map would be a better methodology for the long term. For short term needs in small, drivable research areas, spending money on extensive infrastructure overhead can make sense. However, once any budget pressure sets in and the need to refresh the map increases while scaling, the cost quickly becomes difficult to justify.

For example, conventional base map creation using LiDAR is an expensive and slow process, taking weeks and sometimes months to build an acceptable base map. A trained data-collection driver must go out on a survey trip using an expensive mapping car, equipped with in-vehicle storage arrays to harvest the data. Upon return, the storage system must be physically removed and shipped to a data center for processing.

Data-Rich, Operationally Poor

We consider this method to be “data-rich, but operationally poor.” Though one can collect a wealth of data from a lot of powerful sensors to enable mapping and localization, the data itself makes the undertaking operationally poor; it is difficult and inefficient to collect and manage. It necessitates heavy, in-car compute resources as well as a sizable investment in storage and bandwidth, consequently leading to high energy requirements to power the system. We do not expect these methods to scale.

Map or Go Home

Moreover, the impracticality of conventional systems will actually hinder widespread adoption and full autonomy — the car being able to drive with no human intervention wherever it needs to go. This is because conventional base maps actually restrict the scale of autonomous vehicle operations by limiting where the car can drive itself.

In addition, a passenger’s travel options are tied to how much base map data can be physically stored in the vehicle. Let’s look at a scenario involving an autonomous ride-sharing business under these conditions. Passengers in San Francisco who want to be driven 50 miles south to San Jose will not be able to do so if the robo-taxi does not have a map of San Jose already stored in the car. Driving around with a map of San Francisco and all the cities needed to travel through in order to get to San Jose would mean the vehicle could need ~10–20 terabytes of map data to transport the passenger to his or her destination and any impromptu stops along the way. All that data must be updated at least daily, if not more often. Road infrastructure and traffic rules change day-to-day (sometimes hourly), and a map for an autonomous vehicle must reflect that, otherwise it becomes a significant safety issue, as it did for our early railroad clients.

Lightweight, Fingerprint Base Map

This is one of the problems that Civil Maps is addressing, and this is where edge-processing really shines. Instead of producing a multi-terabyte base map of San Francisco that has to be processed at a data center, we can create a Fingerprint Base Map of only ~400 megabytes for that same region. Using depth data gathered from a vehicle, we extract that critical map data, process it in-vehicle, and transform it into lightweight, environmental “fingerprints.” Because we are taking gigabytes of map data and reducing them to kilobytes, we can then send our fingerprint data to the cloud over existing cellular networks (3G & 4G) for map aggregation and for sharing with other vehicles in our network. Changes detected on the edge can also be sent over air. The vehicle uses our fingerprints for localization, which we are able to achieve in 6 degrees of freedom (6DoF).

Civil Maps’ advantage is that our localization software can use a much lighter base map to accomplish this task. Whenever a different or new base map is needed, the car can download it while driving and use it immediately. For example, if the vehicle is in Tahoe City, California and it needs a map of Nevada to cross the state line and get to Incline Village, our system enables the car to download the area map of Nevada while on the go.

Towards the Edge: Trains Moving Faster than Cars

This is the future we are working towards. A few years ago, our early railroad customers saw their predicament and began moving to edge-based, scalable map creation. We see the same thing happening to the autonomous vehicle industry, and Civil Maps is preemptively preparing for that transition. In our industry today, what we have is exponential growth in depth data generation, aggravated by the fact that our ability to process this data is only growing linearly. It doesn’t have to be this way, and we are confident that our solutions will enable truly scalable autonomous driving.

Originally published at Civil Maps.