In programming, an edge case typically involves input values that require special handling in an algorithm behind a computer program. As a measure for validating the behavior of computer programs in such cases, unit tests are usually created; they are testing boundary conditions of an algorithm, function or method.
The thought process I’m continuing to hear more and more in the autonomous vehicle industry is that automating 90% of driving is relatively easy, but the final 10% is still an incredibly difficult problem to solve for.
This concept proves out with things like Tesla’s Autopilot, which handles itself very well in less dynamic situations like highways or lower traffic areas at certain speeds, but often lacks the ability to easily navigate a densely populated city.
That is the 90% problem at work.
The 10% are what we call the edge-cases. Machine intelligence, especially when relating to dynamic autonomy, is largely about training data. How do you build out enough training data so that your 10% edge-cases fall to 5% and then to 1% and then to .0001%, eventually leading to a margin of error that OEMs (and consumers) are comfortable enough with to operate in full autonomy?
If you’re targeting mass consumer travel, you can do things like gathering data in controlled environments. You can also pre-feed data into the dataset to help lower reaction times and increase the chance of successfully navigating those edge cases. You operate in environments with hedged edge cases, or “hedge cases”.
A hedge case is a unique environment, restriction, or situation that enables entities to safely reduce edge cases from 10% to .0001% over time.
Many in the autonomous vehicle space tend to believe that Google and Uber will be first to market with commercially-viable fully autonomous travel. Hedge cases are the reason.
This is their hedge case.
They have been able to scale this out as more and more training data gets fed into their system, leading to that decrease in edge cases from 10%, to 5%, to 1%, and so on as I previously mentioned.
Uber will be able to similarly gather that edge case data as it will be able to choose when, where, and at what scale to deploy its autonomous fleet. This is Uber’s hedge case. This is economically viable because Uber will be able to monetize this autonomy almost immediately, charging riders as it builds out its data, something that Google (and most other companies) don’t have the luxury of doing.
What can other upstarts and emerging players do to create their own hedge cases?
They can set restrictions, as Tesla has done by limiting the speed at which cars travel based on different conditions, as well as by having the override function built in so that the vehicles are more semi-autonomous than fully autonomous.
They can manually optimize their autonomy via mapping. Other startups we’ve seen are choosing to pre-map given areas with 3D scans of cities, campuses, and more in order to greatly enhance the perception of their vehicles. The market quickly saw the value in such maps, whether 2D or 3D, when Nokia’s HERE maps assets were acquired for $3.1B by Audi, BMW, and Daimler in 2015.
They can narrow their use-case, as some autonomous vehicle startups have chosen to do, effectively limiting the number of “edge-cases” they must optimize for at a given time.
And the list goes on.
As the autonomous vehicle space continues to move forward from both a technology and regulatory aspect, I expect hedge cases to become more important among emerging players and incumbents. We’ll see a rise in testing across simulated/experimental cities, private property, and even public roads.
Companies that have amassed large proprietary datasets are going to be increasingly difficult to compete against, but building in markets and/or areas where edge cases are difficult to solve could prove a large moat for new entrants in the autonomous vehicle and more broadly, autonomous robotics space. And hedge cases will enable these moats.