Apex.AI Does the Invisible Work That Will Make Self-Driving Cars Possible

Autonomous cars are some of the most complex mobile robots ever developed. And like any other complex robot, there's an enormous amount of work required to get them to the point where they can even begin to solve the problems that you actually want to solve.

With autonomous driving, the interesting problems are in perception and decision making, but any self-driving platform first has to get a car's worth of hardware working with a robotics lab's worth of sensors, and that's hard to do. Robotics in general has struggled with this problem for decades: It takes a huge amount of time and effort to just get a basic robotic system working reliably, and once you do, there's no guarantee that anything you've come up with will work on hardware that's even slightly different.

About a decade ago, Willow Garage attempted to solve this problem with the Robot Operating System (ROS), an open-source software framework that manages hardware and software integration and communications while also providing libraries, drivers, and software packages for common robot functionality. The goal was to make it so that a researcher could focus on solving a cutting-edge robotics problem without first having to worry about whether their robot would turn on or not, and once that problem was solved, anyone else using ROS could apply that solution to their robot as well. ROS has been very successful, and it's now used in research and development by many companies working on autonomous cars.

Apex.AI is a startup that's taking everything that's great about ROS and adding the reliability, stability, and security that's required to use it as a software framework for commercial autonomous cars. Founded by some of the folks who were involved with ROS from the very beginning, Apex.AI wants to handle all of the complicated and boring stuff so that car companies can make progress on everything else.

Much of the robotics development currently done with ROS is intended for research environments, where security is not much of a concern and if your system crashes from time to time, that's okay. ROS can be such a development accelerator that many companies seem to accept these constraints, but (as the video says) trying to build this stuff in later when you're starting to think about commercial viability is a major headache.

Furthermore, ROS itself isn't intended for those sorts of deployments, and is simply missing many of the features that might otherwise be necessary, like verifiable real-time operation. A new version of ROS is currently under development that does include these features, but it's nowhere near ready to be used in a product. This is where Apex.AI comes in—taking the early framework of ROS 2, and building a system on top of it that automotive companies can develop today with confidence that they'll be able to deploy it.

Just like ROS, the Apex OS (called, er, Apex.OS) makes it easy to use lots of different kinds of hardware, as well as different pieces of software if you want to use your own perception or decision-making software. Doing so doesn't jeopardize the integrity of the system as a whole, though—Apex.OS makes sure that all the safety-critical stuff keeps running so that if your in-progress perception stack goes belly up, the car can still brake. 

For more details, we spoke with Jan Becker, CEO of Apex.AI.

IEEE Spectrum: What is Apex.AI doing differently than other companies working on autonomous vehicle technology?

Jan Becker: We do not reinvent the wheel. Instead, we take ROS, which is a great and established open framework for robotics and autonomous systems R&D, and make it robust and reliable for use in automotive and other safety-critical applications. Specifically, we provide Apex.OS as a robust and reliable version of ROS 2 for safety-critical systems including adequate certification and professional support, both of which is outside of the scope of an open-source project.

Based on what we saw at ROSCon late last year, ROS 2 seems very much like a work in progress. What's your experience been like making stable commercial software in ROS 2?

The first full release of ROS 2 was published in January 2018. ROS 2 is now taking robotic open-source software to the next level by adopting a cleaner architecture, creating a smaller and more optimized code base, and most importantly, by adopting an established and standardized middleware architecture. 

We need to distinguish between ROS 2 core and applications built with ROS 2, such as the widely popular navigation stack. We expect ROS 2 core to have full ROS 1 feature parity by June 2019. Porting of applications and tools to ROS 2 will indeed take longer. However, you can run ROS 1 and ROS 2 applications concurrently in the transition period. Even the current ROS 2 Bouncy release has enough features to start development of product applications. 

We think that ROS 2 is the only viable base for a production framework for autonomous vehicles.

Why do you think ROS is a good way to go for autonomous vehicle software?

ROS is the de facto standard robotics SDK, because it solves common and recurring challenges that every roboticist started to encounter over 10 years ago: Multiple sensors generate large amounts of data, which needs to be transferred to multicore computers for processing, and the data is then sent to multiple actuators. The autonomous driving industry has this problem now, but can simply reuse the wheels that were invented for robotics before.

Practically all of academia, and by far most automotive companies, use ROS for R&D. ROS comes with a complete ecosystem of tools, such as visualization, simulation, build tools, and, most important, a large community.

Due to the aforementioned reasons (cleaner architecture, creating a smaller and more optimized code base, and the adoption of an established and standardized middleware architecture), ROS 2 is well-suited to then be modified to an automotive-grade framework. 

Improvements we are making from ROS 2 to Apex.OS include: 

• Production code quality (with thorough testing on all levels of the software stack)

• Hard real-time support

• Process-level security

• Support for automotive ECUs and sensors

• Functional safety certification

How is your software robust to failure in ways that other companies aren't already doing, and why do you think this hasn't been more of a focus in the autonomous vehicle space?

We use established automotive software development practices which have been used for years in the development of software for small microcontroller-based vehicle computers, such as engine ECUs. We apply these practices to software problems running on larger, more complex compute hardware. In a nutshell, we combine practices for the development of safe and secure software with complex robotics and autonomous driving software development. 

Apex.AI closed a US $15.5 million Series A round a few months ago, and they've also got a license to test their own autonomous vehicle on public roads in California, which sounds like a promising combination to me.