Using Open Source Frameworks in Autonomous Vehicle Development -Part 1

The open-source community for Autonomous Vehicle technology has been picking up steam recently, with Apollo and Autoware teams being the lead contributors.

With aggressive timelines cooling down (Tesla being an exception) and with many industry experts advocating that L4 autonomy at scale, though inevitable will take it’s time to go mainstream, an open-source autonomous vehicle technology might flourish more in the coming days. More teams can come together to share and standardize on the relatively solved components of the stack like mapping, localization, communication architecture, etc. while developing their internal niche to tackle the unsolved long-tail problems of true L4.

Apollo and Autoware are the two prime open-source self-driving car repositories, that have end-end modules ranging from high-level components like perception and planning to low-level components like controls and vehicle interface.

In this multi-part article, we’ll address what it takes for a self-driving car research team, to start using these open source frameworks in their stack. There are broadly three aspects one has to deal with to start testing an external open-source framework with their stack.

• Message communication
• Map format porting
• Configuration changes to adapt to your internal vehicle and sensor stack

The current part describes an open-source C++ bridge we built to enable message communication between Apollo’s CyberRT and ROS.

Apollo ROS Bridge 

We are open-sourcing a message communication bridge we built between Apollo and ROS. 

Apollo’s (www.apollo.auto) releases come in every six months and they have been consistently growing the capabilities and the number of useful modules and tools, with every release. Although Apollo started with a modified version of ROS, they moved to a new runtime framework called CyberRT since their 3.5 release. Many teams developing self-driving cars, both within the industry and academia, are using ROS as their core framework, including us at Ridecell Auro.

Hence, we built a message communication bridge between ROS and Apollo’s CyberRT. It is designed to help the self-driving car research teams using ROS as their middleware, in testing Apollo’s rich features and modules without having to move away from ROS or their existing stack. It might be required to port to CyberRT or native ROS for performance, but this bridge could easily help in initial prototyping, checking out the advantages of either side or connecting with different simulators and community ROS projects.

The bridge can be downloaded from https://github.com/AuroAi/apollo_ros_bridge.

Apollo-ROS bridge is a software package with a pre-built docker environment that enables communication between Apollo modules and ROS modules. The current version of the bridge converts CyberRT messages to ROS messages and vice-versa, following the YAML-based configuration files and custom callback functions written by the user to suit their application.

Main components of the bridge

• yaml_defs/*.yaml: a configuration file (YAML) for the user to list down the CyberRT and ROS topics that need conversion
• launch/*.launch: Launch file to start the bridge node with a list of configuration files consisting of topics and parameter information
• core/cyber_ros_bridge_core.cpp: Core class of the bridge containing structures for storing Apollo data and ROS data, template callback functions for Apollo and ROS msgs, subscribers and publishers
• core/parse_yaml.cpp: To parse config files and fill in the data structures of Apollo and ROS topics
• lib/cyber_ros_bridge_lib.hpp: A library consisting of math/conversion functions that can be reused while adding new topic conversions. These functions handle coordinate frame conversions, sl-frame to waypoint conversions, etc.
• cyber_ros_bridge_node.cpp: The main executable that creates both cyber and ROS node handles for initiating the subscription and publishing of messages on both sides

Design choices

1. Modularity: The bridge has launch files and configuration files to initiate different configurations of topic conversions for testing different modules of Apollo. For example, one configuration can be where only Apollo Planner is running with corresponding modules of your stack. Another possible configuration can be where Apollo Routing + Planner + Prediction is running with corresponding modules of your stack.
2. Library of converter functions for re-usability: Topic conversions with Apollo are rarely based on 1:1 mapping. Hence, we’re writing re-usable math functions as a library for converting to or from Apollo topics handling coordinate frame conversions, sl-frame to waypoint conversions, etc.
3. Docker Environment with pre-built dependencies: We built a docker environment for the bridge where the cyber, ROS core (header) dependencies, the apollo cyber msgs, and ROS msgs are pre-built into the image. The bridge node resides in this docker container. But, if the user prefers, the bridge can be run from Apollo docker itself.

Steps for extending the bridge to your own stack/topics are mentioned in the GitHub repo.

In the next part of this article, we’ll talk about the map format conversions that are required between the HD map format used by the open-source framework and the team’s internal format.