What is ROS?
ROS stands for Robot Operating System, but it’s not really an operating system. It is better understood as a meta-operating system or Software Development Kit (SDK) that is used to develop robotics applications: it provides open source software, libraries, and tools that are needed to develop, debug, test, and deploy your robotics application. ROS is developed and maintained by
What is Apex.Autonomy?
Apex.Autonomy is a library of software components or building blocks that is based on Apex.OS and provides functionality for autonomous driving. Currently available is a library for 3D point cloud processing. Localization, planning and control components will be added in 2019.
Are you working on a full-stack for autonomous driving?
We believe that developing safe and secure autonomous driving systems is an incredibly challenging problem. We further believe that this challenge requires a diverse eco-system of technologies, components, systems, products, and of course companies building these. We strive for an open eco-system in which customers can select best-in-class hardware components, software modules, computers, sensors, actuators, and services, and combine these into a stack that works best for their individual problem. We are providing components for this eco-system, and not a closed full-stack system.
ROS 2 seems to be 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 adopts 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. ROS 2 core is at ROS 1 feature parity with the ROS 2 D release in 2019.
We think that ROS 2 is the only viable base for a production framework for autonomous vehicles; ROS 2 has a clean architecture, a small and optimized code base, and most of all it is based on an established and standardized middleware architecture. We have posted a popular article titled Porting Algorithms from ROS 1 to ROS 2 to make the transition easier for developers. In that, we describe the design considerations for an application to achieve production readiness using the features of the ROS 2 framework.
In general, 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 provides efficient solutions to common and recurring challenges in robotics. A decade ago, the robotics industry was presented with the challenge of large amounts of data generated by a multitude of sensors which had to be transferred to multi-core computers for processing, and which had to control multiple actuators. The solutions to these problems were implemented in ROS. Today, the autonomous driving industry has ROS at its disposal to solve complex problems.
Practically all of academia and most automotive companies use ROS for R&D. ROS comes with a complete eco-system of tools, such as visualization, simulation, build-tools, and most importantly a large community.
Due to the aforementioned reasons (cleaner architecture, creating a smaller and more optimized code base, and most importantly the adoption an established and standardized middleware architecture), ROS 2 is well suited to be then modified to an automotive-grade framework.
Improvements we are making from ROS 2 to Apex.OS include:
Production code quality, e.g. elimination all unsafe code construct and thorough testing on all levels of the software stack
Hard real-time support, e.g. elimination of all dynamic memory allocation
Complete documentation including examples, tutorials, and design articles
Support for automotive ECUs and sensors
Functional safety certification (ISO 26262, SEooC up to ASIL D, to be completed in 2019)
Generation of binaries, secure signing, and shipping
Can you describe the testing that you've already done and are currently doing?
We have added a significant number of tests, including but not limited to unit tests, regression tests, integration tests, stress tests, performance tests, and MC/DC tests (Modified condition/decision coverage). We support specific automotive ECUs, real-time kernels, and communication buses; we test on these combinations of hardware and software. We support and certify only what we have tested thoroughly in our test lab. When all lab tests have passed, we then also take the software and test it in our autonomous street vehicle, as we are one of the companies permitted to do road testing on public roads in California.
What is Apex.OS and how is Apex.OS different from ROS?
Apex.OS is a fork of ROS 2 that has been made so robust and reliable that it can be used for development and production of highly-safety critical systems such as autonomous vehicles, robots, and aerospace applications. Apex.OS is API-compatible to ROS 2. In a nutshell, Apex.OS is a SDK for autonomous driving software and other safety-critical mobility applications.
What is functional safety certification?
Safety of functionality of technical systems is described in technical norms, i.e. IEC 61508 in general, ISO 26262 for automotive, and DO-178B for aerospace systems. These norms stipulate the required safety level depending on the safety criticality of the intended functionality and the development process to get to that level.
Apex.OS and Apex.Autonomy are software components to be used as parts in safety-critical autonomous mobility systems. Apex.OS will be certified as a Safety Element out of Context (SEooC) up to ASIL D which represents the highest functional safety level in ISO 26262. ASIL stands for Automotive Safety Integrity Level.
Apex.AI is working with
TÜV NORD, one of the most reputable assessors in the field, to achieve certification for Apex.OS.
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, e.g. as described in part 6 the automotive functional safety norm ISO 26262, which has been employed for years in the development of software for small micro-controller based vehicle computers, such as engine ECUs or ESP ECUs.
We are now applying the rigorous software development standards for automotive software to the development of highly complex robotics and autonomous driving software. In practice, this means that we have substantial experience in writing software with static memory, non-blocking synchronization primitives, and real-time logging while also knowing how to abstract them away behind easy-to-use ROS 2 APIs.
Why is functional safety certification required?
If you are working on a demo or R&D prototype, then you likely do not require certification. If you are working on a product, then you may (or may not) require certification depending on the regulatory and product liability related requirement in your market.
Independent from obtaining actual certification, you (presumably) will want to achieve robustness and reliability of both a) your software implementation (as described in ISO 26262 part 6 and 8) and b) your functional performance (as described in ISO/PAS 21448:2019), so that your work product fulfills your customer expectations.
While building a complex robotic system that has a robust, reliable, and real-time capable software stack you will likely find that a set of implementation requirements, coding requirements, and guidelines is required. You will also find that those requirements and guidelines are very similar to ours and hence similar to the ones described in functional safety guidelines and best practices.
You could of course also choose to reinvent the software wheel, come up with all those requirements and guidelines on your own, and spend a multiple of the amount of time and resources, or you could use the collected wisdom of years of automotive functional safety expertise and follow what others have written down for you in ISO 26262, part 6 and 8. Whether you then choose to also get certification (besides following the guidelines that lead to certification) is again your choice.
The Apex.OS value proposition is that the complexity of these (admittedly) tedious software implementation best practices is abstracted into easy to use APIs from Apex.OS, so that you and your developers don’t have to be an expert in embedded, real-time, and functionally safe programming, but can rather focus on creating functional performance.
How can I get access to Apex.AI products?
Apex.OS, Apex.Autonomy, and MARV.Automotive can be licensed from Apex.AI. Please send us an email to
firstname.lastname@example.org with details on your project and we will be happy to respond with information on our products and license.
What’s the business model?
Apex.AI licenses software to automakers, automotive suppliers, robo-taxi companies, sensor manufacturers, startups, and even to aerospace companies.
What is the history of Apex.AI? How did Apex.AI get started?
Apex.AI, Inc. was founded by Jan and Dejan in 2017. Jan has been working on autonomous vehicles since starting his Ph.D. work in 1997 and Dejan has been working on robotics and software frameworks since 2008. Both Jan and Dejan have contributed to ROS since its inception in 2008: During his Ph.D. work at TU Munich Dejan developed ROS-based software. Later, after joining Bosch in Palo Alto, he worked closely with Willow Garage on the core ROS code base. During that time, Jan was at the helm of Bosch's robotics and autonomous driving labs in Palo Alto. He coordinated Bosch's contribution to ROS in the PR2 Beta program of Willow Garage, and his lab was the only corporate contestant that was awarded a PR2 platform for research.
Based on the observation that many companies apply ROS to safety-critical systems without having a thorough understanding of the requirements and implications, the duo decided to start Apex.AI to provide Apex.OS as a robust and reliable version of ROS 2 for safety-critical systems including functional safety certification and professional support.
What is Apex.AI doing differently than other companies working on autonomous vehicle technology?
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.
Is the company called Apex?
The correct spelling of our company name is Apex.AI. The full legal name of our US entity is Apex.AI, Inc. and the full legal name of our German entity is Apex.AI GmbH. Apex.AI GmbH is a wholly-owned subsidiary of Apex.AI, Inc.
What does “Apex" mean?
In Latin, the word Apex means 'summit, peak, tip, top, extreme end, or highest honors’ (
In geometry, an apex (plural apices) is the vertex which is in some sense the "highest" of the figure to which it belongs (
In motorsport, when driving the optimal racing line, the apex is the point at which an inner tire of the vehicle touches the inner edge of a curve (
In ecosystems, Apex species are central to the functioning of ecosystems and the maintenance of biodiversity (