This article is part of TechXchange: ROS: Robot Operating System and TechXchange Talks
What you'll learn:
- Why is the Robot Operating System being used in the car?
- How is Apex.OS related to ROS 2?
- How Apex.OS and Apex.Middleware address safety and security in automotive applications.
The Robot Operating System (ROS) has been utilized for robotics and self-driving car research for many years. ROS 2 is the latest incarnation that was designed to be robust and suitable to real-world applications where safety is an issue. It's built on a standard publish/subscribe model.
Apex.AI has hardened ROS 2 implementation to meet automotive safety requirements.
I spoke with Apex.AI's Joe Speed about the company's ROS 2 implementation and matching middleware to see how it fits with the real-world requirements of automotive manufacturers.
Links
Transcript
Wong: If you're working with robots or autonomous vehicles, there's a platform called ROS 2. It's open source but if you are on to production, you might try something a little bit different.
So, Joe, can you tell us who Apex.AI is and what you guys do?
Speed: Sure. Happy to. So Apex.AI is a software company. Our co-founders are people who have been working in ROS for a long time.They've contributed a great deal to ROS. Jan Becker, our co-founder, has been doing autonomous driving since 1998. They've been working on agriculture and autonomous driving and actually worked with Open Robotics to design, architect, and develop ROS 2. Basically taking all the things that are great about ROS 1, ROS Classic, and making it scalable, distributed, and have the architecture to enable you to progress towards the kinds of things that you need to make it safe.
Wong: Okay. So what products does Apex.AI actually offer?
Speed: Sure. So we refer to ourselves as a vehicle OS company. We don't develop the operating system. We don't develop the real-time OS, but what we do develop is the SDK. The framework and the middleware is what you develop on top of.
As a company, I would say our specialty is our being able to take open source and fork it and harden it so make it real-time, deterministic, and functionally safe to create all of the traceability artifacts. It's okay to have 100% code coverage for all the code in the open source and to go certify it.
Our first product was Apex.OS. This is our first hardened and functionally safe ROS 2 distro. It is like Red Hat. Red Hat takes Linux and hardens it. It's a commercial-supported hardened Linux distro. Apex.OS is a commercial hard and commercial ROS 2 distro.
We built it within our second product Apex.OS with the Apex.Middleware. We have Apex.OS and Apex.OS Cert. Apex.OS Cert is the version that is safety certified by TUV NORD to ISO 26262 ASIL-D, which is the highest level of automotive safety.
Wong: Well, I see you're focusing on automotive. What problems are you actually solving by providing Apex.OS?
Speed: What people don't realize is most of the automakers are using ROS (1) and ROS 2 to prototype new features whether it's autonomous driving, a dashboard cockpit, or different kinds of things. When they decide they want to take it to production, they hand it to another group who throws that away the first prototype and develops a pilot implementation. Once that is accepted, they throw that away and a third group develops the automotive grade, one that'll go into production.
The problem with developing the same feature three times is this is a process that takes many years. It's not unusual for it to be eight years from conception to seeing a new feature in a production vehicle.
What we help them do is basically skip all of that and streamline the process so that you've got your prototype and ROS 2. Then you can do implementation with Apex.OS and it will be functionally safe and have the traceability artifacts so that it can be safety certified (Fig. 1).
We give them the way to go from prototype to production and we give them the way to go from a prototype to a functionally safe implementation very fast. That is a huge improvement.
I hesitate to put a number on it, but if I said order of magnitude, I don't know that that would be terribly wrong. We could quibble about which side of order magnitude it is, but I think that kind of puts you in the ballpark. So this is a really big deal for them.
One of our customers had a lane-centering, car-following, ADAS application they had been prototyping in ROS 2, but they had to develop on these big powerful workstations. When they went to put it into an automotive computer, like a Raspberry Pi class machine, it doesn't fit. They moved it onto Apex.OS and had huge improvements.
They had us help iterate the design and streamline some of it. This included things around the executor optimization that we provide, such as where you put all the nodes. That process took weeks.
Wong: So what is Apex.OS? It’s essentially ROS. What are the major components?
Speed: The major architectural elements include the RCL, RCPP, the Arm-W interface to the middleware, and then you have your nodes with your packages on top. That's your actual application. The bit that does something.
When you show the ROS 2 and Apex architecture side-by-side, they look similar at the 10,000 foot level.
ROS 1 was a very monolithic thing. ROS 2 is decomposed into these nodes, packages, and those can be run as individual processes. You can collapse them together and run them in one process with the Arm-w or ROS middleware interface where you can have your own sub-implementation underneath.
There are several of the most common ones. The default is ROS 2 Galactic with the Eclipse Cyclone DDS. This is an Eclipse Foundation open-source project that we contribute to which has the built-in iceoryx middleware. All this runs on Linux.
With Apex.OS, we've forked the code, we've hardened it, made it functionally safe, and we give the support if you want to run it on the QNX RTOS or the Green Hills Integrity or Cisco or PikeOS, and things like Linux with preempt RTC, the real-time kernel patch.
A lot of people like Red Hat, SUSE, Linux Foundation, and many others are working on how to take Linux and actually make it functionally safe. I think they're initially targeting ASIL-B. That would be appropriate for some in-vehicle systems. That would not include steering, braking, or any safety functions, but there's a lot of progress going in that direction.
Wong: Okay. Now there's been talk about essentially software-defined vehicles. Are you providing that kind of framework and are you a virtualization provider, something like that? How does that work?
Speed: Yeah. So we don't provide virtualization, but we're very good friends.
If you think of yin and yang, there's something like the Scalable Open Architecture for Embedded Edge (SOAFEE), which is from the likes of Arm, AWS, Bosch, Red Hat, SUSE, Toyota, and Continental.They're really focused around how do you take these best practice of virtualization and DevOps deployment practices from the cloud.
With a cloud process, I change the code, I write new code in the morning, I test it at launch, I deploy it in the afternoon, right. That's a normal cloud process.
In the automotive process, I develop it in 2022, I test it in 2024, and it goes into the 2026 model year. The automotive architecture is moving from like 150 to 170 microcontrollers and ECUs in the vehicle and they're trying to collapse that together and cope with all the supply-chain issues (Fig. 3). That is accelerating the process.
Because of COVID, automakers are working on how can I have fewer parts that are hard-to-obtain parts in the vehicle. If I designed for a part and then that part ceases to be available, how can I quickly move my code to a different part. This is consolidation, but it is also portability. That's something that ROS was designed for from the beginning, because every robot is different.
I need to be able to take functions like a map stack from my vacuum cleaner and run it on a forklift. ROS has got that kind of portability with all the hardware abstractions. With virtualization, this topic goes hand-in-hand.
I can collapse systems down to a small number of what they call domain controllers and make it work like one big computer for each function. So we can have one computer for driving, one computer for infotainment, one computer for this, that, and the other. There are also zonal architectures.
There is a crazy amount of wires in a car. Something like 400 pounds of wires in a car. If I put the computer closer to the thing that needs control, then I don't need as much wiring and I simplify the wiring architecture in the car. Just imagine if I put a computer and the left front, right front, left rear, right rear. Then the sensors, the braking, and all of those other things could be much shorter. You reduce the wire path length and then also centralize the compute.
What you're doing is you're taking functions that previously were in 150 different pieces of hardware with their own software, with their own toolchain, their own operating system, and you're collapsing that together.
How do you virtualize this? One of the things that really helps is if you can have a common SDK that's safe and easy to develop with. I can begin to develop multiple automotive functions and that's what's happened to us.
When we started, our thought was that everyone's going to work on autonomous driving. Everyone needs safe-based vehicle software to develop with, and that's what we will provide (Fig. 4). What surprised us is our customers were taking our software sideways into other domains.
So now Apex.OS is being used in ADAS, adaptive cruise control, automatic emergency braking, power train, cockpit telematics, and all kinds of different domains.
Well, if you've got kind of some common tools and common toolchain, and I want to put them in different hypervisors or dockerize them, I am able to more easily manage them and even develop and test in the cloud.
I'm like a big fan of virtual ECUs and the cloud to deploy a physical ECU, so you can do software in the loop and then your hardware in the loop testing. This ultimately brings the project into the vehicles deployed with over-the-air updates. Our software, we're designed to be able to do that. We just don't provide those other functions. We work with our partners AWS, Arm, and others. They're working really hard on that piece and we just fit with it like hand in glove.
Wong: Excellent. Well, it sounds like adoption is going quite well. Can you tell us a little bit about the future plans of the company?
Speed: So we're hiring, wherever you are. Contact me. We've already got offices in Palo Alto, Munich, Stuttgart, Berlin, and we have people now in Italy, in Spain, in Israel, in other cities in the U.S., in Japan. We're growing rather quickly. We've got amazing customers doing amazing things and a lot more of it will be public soon.
Automakers are notoriously cagey about what they're working on as competitive secrets, but if you just look at who are our investors are, I think it gives you a hint of how important we are to the industry. We have Toyota, Continental, ZF, Jaguar, Land Rover, Volvo, Halla, AGCO, and Airbus. I challenge you to tell me an industry, you name it, and we can figure out somebody who's using ROS.
As a company you have to start somewhere. Automotive seemed to be a market in most need of help. They move to electrification as they radically changed the vehicle architectures. They need new tools and new solutions. You don't want to just be dragging the last hundred years of legacy with you into your new vehicle architecture, but we're already spreading out beyond automotive. There will be more news coming on that.
One thing I forgot to tell you is about iceoryx that I mentioned earlier. It does a trick called zero copy.I get a point cloud or I get a camera image coming in and it takes the data and writes it to shared memory. It then publishes the handle and up pops the handle, so all the other processes in the computer can get it but they don't have to make a copy.
This is a rather radical improvement in performance. An orders of magnitude improvement in the latency and reduction of jitter and a very radical improvement in the reduction of CPU cost.
The reason this is important is in automotive you get an image that shows you are going to hit somebody unless I make a decision and take action. I have to do that within so many milliseconds. If we can give the program more time for other more interesting tasks, you can use the time to do additional functions like more sophisticated perception processing. You can do more sophisticated path planning.
So that's a really big thing. The iceoryx zero copy is built-in and it is an Eclipse Foundation project. It's built into Eclipse Cyclone DDS and we've developed it to be automotive grade. If you want to certify it for automotive use, then you just get it from us.
Wong: Excellent. Thanks very much.
Speed: Yeah, fun stuff. Thank you so much.
