The Self-Driving Taxi Explained
Thoughts on Business Model, Technology and the Go-To-Market Strategy
Uber has irreversibly changed consumer expectations on travel. We expect travel to arrive on demand, be reliable, multi modal, save us expenses and seamlessly integrate with the rest of our lives. And this new mobility paradigm coupled with the race to build an autonomous vehicle has led to the emergence of — ‘The Robotaxi’.
Simply put, this is a taxi driven autonomously. And over the last decade a number of startups, tech giants and auto industry incumbents have taken a stab at bringing them to reality. But we are just starting to scratch the surface. There are several hurdles before such taxis become the norm.
Why are so many companies building Robotaxis?
What are the technical challenges and trade-offs to navigate?
How is it different from any other application of self-driving technology?
All serious and difficult questions.
But once answered, will unlock the doors to forever change the way we live and travel. And that attracts everyone — from the very best engineers to the deepest pocket VCs. Interesting times are ahead!
The RoboTaxi Business Model
The goal of any business is to make money. The promise of higher margins and recurring revenue is alluring. Let’s take a closer look at how this happens.
Revenue Model
Before diving into the details, I’d like to make a series of assumptions.
- Fully Electric. Sharing not just with other humans, but also the environment is important for sustainability. And with governments across the globe pushing for climate friendly policies, there’s no reason not to invest in sustainable transport. Besides, low maintenance costs and shifting consumer preferences will also accelerate the move to fully electric robotaxis.
- Price per Ride. Taxi rides vary by distance and time. A ride to a far away airport can easily bring in excess of a $100. But shorter trips can inch towards the low double digits. For our analysis, we will assume a typical distance of 6 miles, covered in 20 minutes (includes pick up, drop off), that charges the user $16. And let’s also assume it’s just one user per trip. This translates to a revenue of ~$50 over ~20 miles of driving in one hour.
- Battery. Besides driving, other factors such as traffic patterns, road characteristics, weather, climate control etc. will determine the actual battery consumption. We will assume a 30 mile pull on the battery every hour.
- Range. The latest Tesla Model Y offers an EPA estimated range of 316 miles. And the Model S crossed the 400 mile mark recently. A Robotaxi range of ~350 miles on a Model Y sized vehicle is not out of reach.
- Charging. With V3 charging, a Tesla can ingest charge at rates of 250kW or add-on 75 miles in 5 minutes. But as the battery replenishes, the time taken to add another mile increases exponentially. As an estimate, I suspect one would have to wait ~45 minutes to restore up to 300 miles on the battery. And there’s of course the over head of driving to and from the charging station, availability at the station, traffic and other factors. Lumping that into 30 mins. These assumptions give us a down time of about 75 minutes for a charging session.
- Daily Operations. Let’s assume that the Robotaxi is operational for 18 hours each day and the remaining time is used for charging (2+ stops easily accommodated), maintenance and idle time during periods of low demand. Note that after about 8–10 of hours of operation, the Robotaxi will need a charging session. So 18 hours of driving is well within reach.
Putting all this together, in a single day, a Robotaxi will drive 18 hours on the road over 54 trips and earn $900 in revenue. That translates to annual revenues of $900 * 365 = $328.5k.
Taxi Demand
Including visitors (10%) and residents (90%), there’s about a million people in San Francisco on average. Say half the visitors need two taxi trips and about 1% of the resident population on average takes 1.5 trips per day. This translates to a demand of (2 * 0.5 * 0.1 + 0.9 * 0.01 * 1.5)* 1M = 100k +135K = 235k trips per day.
To serve all this demand, we’d need 235k/54 = 4,350 robotaxis in San Francisco. But of course there will be competition from established players and new entrants. And for a third of market share, that requirement falls to 1,450 Robotaxis in the city, with an annual revenue of 1,450 * $328.5k ~ $476M.
But that’s just one city. There are 15 other cities just in the US with more population than San Francisco. That quickly makes this a multi-billion dollar business in the United States alone. Also, given shifting consumer preferences, the market is only bound to expand. And that explains why we have so many players vying for a piece of this.
Robotaxi Self-Driving Challenges — Hardware
Hardware is hard. — Sundar Pichai.
The Google CEO famously made that statement. And the self-driving challenge is no different when it comes to hardware. Companies navigate a bunch of trade-offs the first of which is the decision to manufacture their own vehicle.
Vehicle Design
Do you build a new vehicle from the ground up? Or partner with someone who’s already setup to do that?
Central to answering this question is what kind of a Robotaxi future do you envision? A shared pod for a dozen people riding together. Or a two seater with a coffee table? Do you expect people to dine, work, play or just commute? Are you transporting people or packages or both?
Zoox for instance has gone all the way in to make their own taxis. Their belief is that autonomy is a fundamental part of the taxi. So a taxi that drives itself, needs to be purpose built with autonomy at its core. The decision offers Zoox maximum flexibility, with the gift of full vertical integration. But the downside is it’s a capital intensive endeavor for any startup.
The other extreme is to only build the driver that can turn any vehicle into a Robotaxi. Aurora is working on this approach. They want their driver to fit into as many self-driving applications as possible. But building a vehicle agnostic driver has its own set of problems. For instance, the planning and control module, that sends the acceleration, braking and steering commands, needs to be designed in a modular fashion to accommodate for different vehicle architectures.
Orthogonal to those examples, Nuro is building a vehicle that only carries packages, including groceries. Their problem statements include the last ten feet (climbing stairs, cobbled road etc.), refrigeration and storage space among others.
But the bulk of companies probably fall somewhere in between. They either partner up with an incumbent auto maker, supplier or hope for such a partnership in the future.
It goes without saying that auto makers have an inherent advantage here. Years of making cars has allowed them to build an ecosystem of suppliers, dealerships and third party vendors. But how that advantage plays out is another story as this will still be an expensive project.
Automotive Sensors
When Google started working on self-driving tech, lidars did not exist in the automotive market. Radars were only meant to detect large metal objects, i.e. other vehicles on the road. And cameras were not all that prevalent. And Google solved this problem by building their own sensors from scratch.
This made sense for several reasons. First, a traditional sensor maker would not have been incentivized to build this. Suppliers expect volume. Else, such custom engineering projects cost a fortune. And that wouldn’t have made enough sense for Google.
Second, closely controlling the sensor design meant they could optimize their self-driving software. For instance, the software could request specific radar scans to develop a high resolution view of a certain region of interest. Such an optimization would increase the accuracy of perception systems. And in turn help Waymo drive farther, faster.
Third, a disadvantage of being an early mover was that they were solving problems nobody else was looking into. At the time, there were no high definition maps. You need accurate laser scans to create such maps. And that meant designing and building such scanners from the ground up.
But we’ve seen similar behavior with other Robotaxi companies as well. Even as the self-driving ecosystem continues to mature. For instance, Cruise acquired Strobe in the hopes of bringing lidar costs down. And Aurora acquired Blackmore.
But besides costs, such moves could also be about controlling your own destiny. Not being beholden to schedules. Or perhaps the fear of missing out.
But, there are downsides to this approach.
Manufacturing demands volume to bring costs down. And it would be very expensive for an individual Robotaxi player to setup an entire production line just to serve its needs. It’s probably why Waymo decided to sell its sensors in adjacent markets.
Also, it takes a different talent pool to design sensors. Imaging scientists, signal processing PhDs, analog gurus, device and material experts and a sensor market know-how to bring it all to production. It’s unclear whether it makes sense for a Robotaxi startup to take on this challenge today.
Hardware Testing and Production
The next steps after a design are testing and production.
Testing requires investment in test equipment, building relations with test facilities and certification agencies. The designs will need to be tested for environmental conditions, extreme thermal conditions, mechanical shocks and vibration and reliability. And the passing criteria for such tests are determined by a slew of automotive and industrial standards.
A company could either partner with a traditional automotive tier-1, that has decades of experience or contract with manufacturing facilities. Either case, this requires hiring the right experts, multiple trips to China or wherever the facilities are and patience for a slow ramp up. As it will be hard to get it all right at once.
Robotaxi Self-Driving Challenges — Software
The Operational Design Domain or ODD, which is a set of conditions under which the vehicle can drive itself, is pretty challenging for a Robotaxi. For instance, consider type of roads — one of the attributes describing an ODD. Robotaxis need to drive on crowded downtown roads, freeways, one way streets, custom designed intersections, roundabouts, in tunnels, over bridges—the list is endless and complex. So writing the software that seamlessly orchestrates this is no walk in the park.
Map the ODD
One approach is to pre-bake as much of useful information as possible into highly accurate maps. Such maps could store breadcrumbs to help with perception, planning and control. For instance, maps can store the location of traffic lights. So, the vehicle now only needs to classify a traffic light as red or green, but not have to detect its presence, because it knows precisely where to look.
But such an optimization introduces a new problem. As cities are dynamic and constantly changing. Temporary construction zones, human-led traffic control, closed routes, digital signs etc. which makes maintaining such maps up to date a challenge.
Perception Challenges
The traditional perception challenge is always presented as how far and clearly can the robot see. But in a crowded downtown area, where pedestrians and obstacles are at times centimeters away, perception at the vehicle periphery becomes important.
Imagine a camera capturing what looks like a zoomed in view of pedestrians. Would the neural network be able to accurately classify those as humans? In a crowded narrow downtown street, the radar signals have plenty to bounce off, returning dense noise signatures that need to be accurately filtered. Signal interference between multiple Robotaxis in a narrow street could also be an issue.
And if the perception stack outputs are noisy and unreliable, the control algorithms will have to trade-off comfort for safety. This could result in a jerky drive, with more brakes than needed. And a drive that takes longer and becomes more expensive for the rider.
Another challenge is to find enough examples to train DNNs. But the catalogue of objects and contexts can quickly shoot up for a Robotaxi operation. And some examples can be very hard to find and train. For instance, people in halloween costumes, pieces of luggage, pets and animals etc. Data augmentation and simulation techniques can help to an extent.
Traffic Patterns
Besides detection and classification, the Robotaxi also needs to understand the intent of various agents on the road. The software usually builds up a probabilistic model over several predictions to accurately judge an agent’s intent. But in certain scenarios time is of essence and the Robotaxi will have to act fast. For instance, pedestrians can change course at the last minute or another vehicle can stop abruptly or cut in.
Also, every city is unique in the way people drive. Hand gestures and yells can be more common in some places. The road is shared not just with cars and pedestrians but also vehicles such as trams, trains, scooters, mopeds and others.
Now image having to do all that successfully at night, in the rain, next to a busy arena. Driving safely with the hustle and bustle of city traffic is no easy engineering feat.
Robotaxi Go-To-Market Strategy
It will be a while before regulatory approval, social preferences and technology maturity all align, and we see Robotaxis swarm the streets. But companies aren’t waiting for the future, they are actively designing and shaping it today.
A number of strategies are being employed to book short term revenues, expand partnerships and educate the regulators and onboard the general public.
Experimenting with existing Fleets
Some companies are using the existing data collection and testing fleet for transporting passengers and goods. Cruise has partnered with DoorDash for food delivery in San Francisco. May Mobility and Voyage operate shuttles that ferry passengers. Waymo One, is a taxi service run by Waymo in Phoenix.
Besides the technology, companies are also focussed on building the end-to-end user experience. How will people get in and out of a taxi without the driver? How does the taxi know it picked up the right passenger, and what would it do in case of an emergency?
Slow Rollout
The hardest challenge is to scale the technology to work in different cities. The Robotaxi launch will be orders of magnitude slower than Uber’s geographic expansion. And companies need to be sufficiently capitalized to play this out patiently.
By definition, a Robotaxi bears all responsibility of driving within the geo-fenced area. So the billion dollar question is how safe is safe enough for Robotaxis. And what will convince cities to allow these taxis on the road. The answer probably lies at the intersection of theoretical mathematical modeling, empirical results, citizens’ preferences and the industry’s approach to liability.
Final Thoughts
The sheer unpredictability and dynamism of driving conditions in cities presents interesting challenges for designing a Robotaxi. And the solutions are not easily scalable. Which implies there will be multiple winners, across geographies. The race is on!
