Why do developers showcase their prototypes in half a dozen cities around the world, but not their own backyard, the suburbs around their HQ? Industry players are already looking for solutions to scale their technology globally. However, what you are scaling from is the most important part of the equation.
It’s easy to spot the differences between a European city center, a US highway and endless rural roads. However, the most fundamental factor behind our design strategy for both technology and safety is the nominal traveling speed. We all know from our driving lessons that visibility, traffic density, road conditions and collective driver behavior affect how we assess driving situations. We compensate for the limitations of our reaction time by adjusting the vehicle’s speed. When a car conducts emergency braking 100 meters in front of us on a highway at 130 km/h (80 mi/h) it requires an immediate reaction – provided that we can see the car, road conditions allow us to stop in time and we do not cause greater harm to other actors in traffic.
Some things don’t change – Let’s stop here for a moment. A L5 self-driving car will have to solve every traffic situation regardless of speed. This requires an ultimate sensor setup, general algorithms and processing hardware that can run it all real-time. No matter the environment, the tasks are the same: recognition, localization, motion planning and execution. Traveling at 40 km/h, a car emergency braking 100 m in front of a self-driving vehicle isn’t of immediate concern, or if it is, the system has 3 times longer to react than on a highway. More importantly: at low speeds, hitting the brakes hard is still less of a risk. The question is, how do you step out of the comfort zone when scaling a system to higher speeds?
Know your limits – Why start the development in high-speed environments? That’s where you realize the need to push your detection, planning and control capabilities to the limits. The system has to be accurate, robust and safe. If the software can detect cars 150 meters away on a highway, it will be able to do so in a city as well. If it can handle latency in environment reconstruction and motion planning in rush hour traffic on a freeway traffic, it will have no problems doing so in a calm residential neighborhood. If it can provide a smooth driving experience at 130 km/h with bumps, aggressive human drivers and noisy detections, it will offer even more comfort at 40 km/h.
Boundaries on both sides – You could, of course, try doing it the other way around. Just put a faster PC in the car to reduce reaction time, or use a higher resolution camera to increase detection range. That could theoretically solve upscaling. In practice, though, self-driving software design is a strictly optimized process. In the past, fulfilling performance requirements with a single approach was out of question, as the state-of-the-art and hardware capabilities were way below the requirements. While we have reached a point where hardware solutions can run the software in cars real-time, processing platforms are still a firm upper barrier; one constantly pushed from below by the ever-rising performance requirements These force developers to aim for a small working area in between. It’s impossible to double detection resolution or computational capacity just yet.
Nevertheless, the world is not black and white. Cities are diverse environments with challenging intersections, rule-breaking drivers, unpredictable corners and road works. Most of these factors affect highway driving very rarely. But the demand on components from recognition to control are there, and the best way to understand and address them is to challenge the limits with high-speed testing. With a well-established simulation-accelerated development pipeline and by making testing safety an absolute priority, this our path towards a global self-driving future.Back