In part 1 of this series we introduced a bridge between the ubiquitous ROS framework, and the newer Apollo Cyber RT, which was created for the Apollo autonomous driving platform. In part 2, we are happy to open-source a bridge between the popular Carla simulation platform and Apollo. Read on to find out more about:
- HD maps (an essential component for most self-driving car stacks) and the current popular open source HD map formats
- Process of converting OpenDRIVE maps (a format used by many ADAS and AV companies, including Carla) to Apollo maps.
- Our integration between Carla and Apollo, including Carla towns converted to Apollo maps and the long-awaited Carla-Apollo bridge!
What is an HD Map?
As the name suggests, an HD map is a highly detailed description of a road network. It’s a database of all the lanes, the relationships between them, coordinates describing their boundaries and center-lines, as well as the locations of crosswalks, speed bumps, traffic signs, and traffic lights. In contrast to geographical datasets such as OpenStreetMap’s, which often rely on satellite imagery, our HD maps are generated from high resolution LiDAR and camera data collected from the mapped area. This gives us the centimeter-level accuracy that many of our software modules demand.
Why we use HD Maps
Some self-driving systems are striving to work anywhere, and since they cannot map the whole world, they are faced with the challenges of inferring details about the road from sensor data in real time. Since we are developing an L4 system in an area that we can map in advance, we are able to take advantage of the benefits HD maps offer. For example, our motion planning module can plan relative to the lane center line further ahead than we could detect with sensor data, and around occlusions. Our perception module can segment sensor data based on the map to make better detections. Our prediction module can make better predictions about the intentions of detected vehicles, pedestrians, and so on.
Widely used formats
Although HD maps are not new, the recent rapid development of self-driving technology has led to the development of different formats to suit different needs. There are efforts to develop standards though, such as the Autoware Foundation’s Map Data and Formats working group, and ASAM’s project to develop a concept for OpenDRIVE 2.0.
Lanelet2
The lanelet format is proving useful in self-driving and is becoming more popular due to its simplicity, as well as powerful tools for handling them, such as the Lanelet2 framework. As seen in the diagram below, a Lanelet2 map is comprised of a database of points. Those points are grouped into Linestrings, which are then grouped to form Lanelets. Lastly, the relationships between Lanelets is described, allowing routing along the map.
Example map showing the internal structure of a Lanelet2 map [source]
OpenDRIVE
Another common format currently in use is OpenDRIVE. It has been used in simulation for some time, but more recently, has been adopted by the autonomous driving industry. VectorZero’s RoadRunner, a software tool for designing road networks, exports to OpenDRIVE. And the developers of the open source simulator, Carla, use RoadRunner to create maps.
Unlike Lanelet2 maps, OpenDRIVE maps don’t contain points, and instead use geometric primitives to describe their geometry. An OpenDRIVE map consists of a list of roads, each with geometric primitives which describe the reference line of the road.
OpenDRIVE element hierarchy
The roads are divided into lane sections, which contain the details of the borders of each lane with respect to the reference line.
OpenDRIVE lane sections
Apollo Maps
Finally, Baidu uses a modified version of the OpenDRIVE format for its Apollo self-driving software stack. Instead of using geometric primitives (like lines, spirals and arcs), they use sequences of points to represent road elements. There are other minor differences as well, but the hierarchical structure of roads, lanes, lane-sections, etc. is still maintained.
Converting OpenDRIVE Maps to Apollo
OpenDRIVE describes reference lines using geometric primitives such as lines, curves, and spirals. Then every lane line on the road is described relative to some reference line. This enables the storage of a high resolution representation of the lane lines without bloating the file size, but it comes at the expense of extra processing when using the map in real time. On the other hand, Apollo stores each reference line as a sequence of points (like Lanelet2), which is what Apollo’s routing and planning modules need. This is the primary difference between OpenDRIVE and Apollo map formats.
Relationships between lanes are also handled somewhat differently. OpenDRIVE has a strict system where each road can have a single successor and predecessor, and if more than one is needed, a junction element is created to handle all the connections. Apollo handles relationships at the lane level and allows many predecessors and successors per lane. This obsoletes OpenDRIVE’s junction object, and removes some of the processing needed to traverse an OpenDRIVE road network.
With the goal of reducing real-time processing of the map, Apollo’s format adds a few other features which can be pre-processed. For example, the Apollo format contains lane and road width at every point along the reference line. Also the “overlap” sections introduced in the Apollo format quickly describe what features (such as crosswalks and traffic lights or signs) are associated with each lane element.
To use the Apollo software stack with the Carla simulator at Auro, we created a bridge that manages the communication between the two. We also converted Carla town maps from OpenDRIVE to the Apollo format. And we are happy to share the bridge as well as the converted maps with the open source community! Instructions on how to run the CARLA-Apollo bridge can be found here. The maps are available on our dockerhub, and can be used by mounting them to the Apollo docker container. We’ve provided a modified version of Apollo, which takes care of this for you, here.
Click image to view CARLA-Apollo bridge in action
Connecting open-source initiatives
At Ridecell, we believe that we can accelerate the development of autonomous vehicles by adopting tools and frameworks that are openly available, and building state-of-the-art technology to address unsolved problems. Building bridges and converting data to appropriate formats helps us connect these initiatives, and extract the most value out of them.
If you’re passionate about developing autonomous vehicle technology, and want to join us on this exciting journey, check out our careers page and see how you can contribute!
