CRUISE - BUILDING SELF-DRIVING HARDWARE AT SCALE

A famous and frequently paraphrased truism is that if you’re really serious about software, you should make your own hardware. At Cruise, we’re serious about both.

I lead the Autonomous Vehicle Hardware Systems organization here at Cruise. Our team designs, develops, and commoditizes the hardware and architectures — such as sensors, compute, and associated subsystems — in support of Cruise’s business needs. Working tightly with our software, systems, and product customers, our team develops modular, safe, and scalable architectures to support our vehicle platforms and business cases and brings them through production with our world-class partners.

In this blog post, we’ll introduce you to the hardware systems team at Cruise, our philosophy on hardware development, and how we deliver self-driving hardware at scale.

Our hardware development philosophy at Cruise

Given the state of the market and outsized publicity that new entrants and announcements attract, I am often asked: “What are the ‘right’ sensors or computers for self-driving cars?”

The practical reality is that all of the groups currently grappling with this autonomous challenge are essentially solving the same physics problems of sensing, perception, processing, and kinematics — and there are several ways that you can attack these problems.

Military and aerospace-grade sensor and compute packages have been deeply developed over the last century and are remarkably effective at sensing the environment — but at a cost point that is prohibitive to the massive scale required to achieve our goals in the self-driving space. Autonomous trucks have been operating for years in industrial mining applications under similar constraints.

But there is a cleverness required to build a system that can conduct real-time, safety-critical sensing and perception tasks at scale. I think this is a remarkably exciting problem that can have a profound impact on not only how we get around, but also potentially reducing the number of needless deaths and injuries that occur daily on our roads.

An x-ray view of Cruise’s autonomous vehicle hardware system

The answer to the “right hardware” question is therefore a little nuanced — the best hardware for self-driving cars is not necessarily the best sensor or compute, but rather the best system. The right perception and processing system must be tuned to the specific software used to meet the stringent performance, safety, cost, scale, and reliability requirements of this space.

It is indeed an exciting time in this industry with the emergence of a large number of burgeoning sensor and technology startups/companies.

So why invest in making hardware at all? Can’t you just buy everything you need?

While an amazing amount of development has occurred across the industry, significant amounts of work are still required in order to truly commoditize a hardware system of sufficient performance at the scale required by the business case. The initial conditions of each self-driving company — such as the time, environment, and background — play a critical role in the shape of the hardware and software stack.

Thanks to developments in the sensor market, autonomous vehicle companies that began tackling this problem in the last few years have a huge temporal advantage — you can simply buy a self-driving kit and get started. This was the field that Cruise started out with several years ago, and these initial conditions allowed the software development to proceed unencumbered by the long and expensive hardware development lifecycle. As the software matures, the hardware can become more specialized and optimized for the system.

To be successful in self-driving, your hardware needs to be successful along three axes at once:

> Safety. A broad word that distills many concepts, including functional safety, system performance, reliability, and graceful degradation.

> Performance. Performance requirements must be met to succeed.

> Cost. This includes not only piece part cost but also development, maintenance and reliability.

Only a few companies are able to exert the resources — monetary and otherwise — to go after the difficult hardware projects that are required to make a meaningful disruptive impact on the hardware landscape for autonomous vehicles. For us at Cruise, those hard problems are existential to our business.

On the other side of the coin, one can go too far in vertical integration. We at Cruise strive to leverage developments in the industry as much as we can, and focus our investments on the components and technologies that offer outsized value for our mission- the “minimum necessary” technologies core to our self-driving system.

That minimum is still challenging. At each step of the hardware development cycle, we must conduct a make/buy study. Of the over 30 modules that are custom for the autonomous vehicles that you can currently see driving around the streets of San Francisco, about two-thirds are fully bespoke; this percentage is closer to 75% for our next iteration of vehicle. These components include things that you would expect — like fully custom cameras and radars and our compute modules, but also many of the back end telematics, networking, and interface modules as well.

For the remainder, we deeply partner with the companies making these components to co-develop them to our specifications and needs.

Developing self-driving cars at scale

It is extremely easy and common to underestimate the difficulty of scale and reliability in the face of a daunting performance challenge. However, much like driving in difficult weather, these manufacturing hurdles cannot be “added on” once the system works; instead, they must be designed in from the start on both system and component levels. There is also an additional element to this equation: the ability to iterate rapidly without sacrificing any of our performance metrics.

These areas are where our deep partnership with GM is crucial. Current Cruise self-driving cars are based on the Chevy Bolt platform, but are executed as a different, unique vehicle within the GM system to enable them to roll off the line hardware complete — which required a significant redesign of the production process.

While traditional automotive manufacturing typically requires a multi-year process to develop a vehicle, that timeline is too slow to respond to our iterations and keep up the momentum for advancing this technology.

Over several years of working together, we have consciously developed teams and processes to impedance match the safety and manufacturing mindset of one of the world’s biggest automakers with the high speed and rapid iteration of Silicon Valley.

This partnership is not an easy thing to develop, and most certainly does not come for free with an OEM partnership; we have had to practice to get good at it. Each major vehicle revision is considered a new “track” of vehicles — the track you can see driving around San Francisco is the third iteration with GM (“Track 3”).

If you look very carefully, however, nearly every sensor and almost all autonomous vehicle components were either modified, replaced, repositioned, or updated (and sometimes, all of the above) between the beginning of Track 3 about a year and a half ago and the current vehicles. What’s more, all of them have rolled off the factory line without sacrificing the reliability of our components or systems — a critically important detail.

This allows us to rapidly switch out and modify systems on our production vehicles in response to the availability of better components and to continued learning at the system level. We are able to accomplish this by keeping flexibility and modularity in key strategic areas of the vehicle, and by the nature of our end-to-end control of the whole vehicle from the design phase to the production line.

While there is no replacement for actual, real world testing — and we do quite a bit of that — we have also invested significantly in our tools and simulation to enable extremely fast (yet reliable) development, evaluation and optimization of new sensor architectures. These include not only high-fidelity, photorealistic 3D simulations, which enables us to run our full software stack on proposed sensor layouts to check efficacy, but also in physics modeling of electromagnetic propagation to answer difficult placement and weather questions.

This brings us full loop to our hardware development philosophy above and enables us to quickly identify what are the right things to develop. We are just beginning to see the fruits of this labor with some of our next-generation vehicles, and we envision this philosophy will become industry standard as we move from point designs to architectures on the way to solving the engineering challenge of our generation.

Author: Brendan Hermalyn - Director of Autonomous Vehicle Hardware Systems, Cruise