What it means to be “AV-first” when designing a new mobility platform — part 1/2
At Bestmile we like to say we have built our platform with Autonomous Vehicles (AVs) first in mind. Unlike many of the existing mobility solutions today, which are coming from a world where drivers are the main actors, we think the design should start with AVs, but stay human-friendly and connect drivers when necessary.
That does not mean we do not like human drivers. We simply think that a modern, elastic, flexible mobility solution should help enable our vision of mobility first, where autonomous, electric, shared vehicles are the key elements. When humans are necessary (and they will be for still many years!), we help them blend with that new paradigm through apps, on top of an AV-first platform.
This paradigm shift has obvious, but also very subtle impacts in how we build our APIs and services, specify our products, and design our interfaces.
“What would a robotaxi do?”
Something we hear a lot in design sessions at Bestmile.
Some behaviors seem obvious to us. If you ever had to “pick up” someone with your car, or to take a taxi, you know what should happen without thinking. One specific example is the “idling time”:
- While you wait for your friend at the promised meeting place, you park your car and go grab a coffee if you are early.
What would a robotaxi do? or more precisely, what should the orchestrating platform behind a fleet of robotaxis plan for that case? If we park a robotaxi and let it wait for their passenger for too long, we are missing out on the promised future where less cars are supposed to do more work. Plus, you probably prefer electricity over coffee, if you are like most of the AVs out there…
Today, the behavior of vehicles is mostly derived from the human inside.
- We cannot drive for more than 2–3h without feeling tired.
- We use more cars than we should (the “shared mobility vision”), and it creates a need for parking spots and street space.
- We have natural mandatory needs, like eating, drinking, and finding clean WCs.
Those behaviors are defining the questions that we ask, such as
- Location and timing of the breaks for professional drivers — where should the vehicle be, and at what time, for the drivers to be able to get what they need?
- What should be the location of “service areas” where humans can repair, and refuel their vehicles?
- What is the maximum distance and time that a vehicle can be moving?
Moving to a driverless world
If we remove the constraints inherent to human beings, we realize there is no reason vehicles should park too often. The main remaining constraints would be:
- Energy (electricity most likely)
- Maintenance or cleaning (planned, and incidental)
…but when they need to park — and they might need to, for a few years still — then the question is: who decides where and how to park?
The manufacturer of the AV should provide some artificial intelligence and mechanisms of course. But most likely, it’s the orchestration platform (the control tower), that will be the only actor with the required information to make such a decision in various part of the world, for various regulations and situations. In the end, idling duration and location are part of the fleet’s operational efficiency.
If manufacturers need to make sure their AVs know how to park safely, when and where are the operator’s problem, and the answers will most likely be common to whatever brands and models compose the operated fleet of AVs.
When drivers would implicitly know how, and what to look for when idling, it’s now the dispatch, and the orchestration platform behind the robotaxi that will be in the best position to handle that use case.
This small difference between how a driver and a robotaxi might be able to handle parking has a big impact, for instance, in the way we build our “missions” for the vehicles at Bestmile. We need to plan for each “parking missions” carefully, where human drivers would have instinctively looked for a service area, or a restaurant without receiving instructions.
AV optimization vs. human UX, practical example
In an on-demand setup, when planning idling time in the vehicle’s plan between two bookings, there is no specific incentive to plan it just after the ride, or just before the next one — if the rides are spaced enough in time unless of course if there are specific constraints (such as parking constraints, charging, or other non-transport necessities).
The following plan is an example of how “drive times” (blue continuous lines) and “idle time” (dashed lines) can be arranged. From an AV perspective, this is perfectly fine.
It is however not ideal if we introduce an additional factor (e.g. the driver) to the equation — as drivers have specific needs. At Bestmile, we adapted the driving interface (the Driver App) to make sure the driver and the underlying protocol can understand each other.
In this case, even if the “drive” mission should happen in the future, the driver still has the choice to start it early. This is something an AV would probably not do anyway.
Summary
- Drivers have implicit “fallback” mechanism, or can be trained for some behaviors. For AVs, each and every second needs to be planned by someone, either the manufacturer or the orchestrating platform.
- Behaviors today are driven by human needs. Without the humans, operational needs will change, but nobody is completely sure how much the needs will change yet.
- Different drivers have similar behaviors. AVs will most likely be very different across brands. Which makes the need for orchestration bigger and the challenge of designing for AVs first more complex.
Can robots and humans share a common language?
One of the main value proposition of the Bestmile platform is its “vehicle agnosticity”. Read: be compatible with any vehicle, whatever their brand, model, or capability.
But what about vehicles that are “augmented with a device” aimed at human drivers (a.k.a. a Driver app)?
For simplification and interoperability reasons, it is important for Bestmile to still handle the communication the same way. That’s why the Hermes protocol is celebrating 2 versions, and 5 years of existence and many deployments across the world.
Hermes’s goal is to model the subset of information exchange needed for any vehicle to be compatible with an orchestration platform, and to be operable in a modern transport operation setup.
But Hermes is built for AVs first (as is the platform). A few features are not built-in, and Bestmile had to cover for those directly in its mobile apps. These features give good insight about what is needed to orchestrate vehicles vs. what is needed to support human drivers.
- Plan foresight and idling time: A human driver cares about what comes later for their shift, even if they cannot influence it, and even more if it dynamically changes through the day. It comes back to what is described above — for instance: where am I going to have lunch?
- Traveler-driver communication: how do you ensure the traveler can find its ride, and the driver can validate their travellers are entitled to travel?
The driver cares about the name, identity and the destination of its traveler. Drivers want to provide a good service, by doing things like calling passengers if they are not at the meeting point. A robot, on the other hand, will only care about validating some travel authorization token, or going on with its plan if the traveler is late — even if they are only 15 seconds late…
With humans in the loop, someone running for the stop because they’re a bit late might influence the plan — what was planned for the whole fleet by the platform — directly through the driver’s empathy. Robots will most probably just obey whatever timestamp and command is sent.
Hermes is designed to cope with those “real life situations”, where the vehicle might not always do what it is asked to do, for many reason (a passenger is late, accidents, last minute closed roads, etc…)
The difference is in the reasons and type of non-compliance. Hermes here doesn’t provide for those details, but provides a nice, stateless design to cope with it at the planning level for the whole fleet.
Getting the information about “why” a vehicle is running late will require different channels:
- For humans, getting information through the apps, to the platform, and vice-versa.
- For AVs, extracting information through the gigabytes of events and logs sent to the platform, and prioritizing those
(e.g.: “doors not closing” logs at a pickup location might indicate that someone was holding the door… or it might indicate a malfunction).
Learn more about Hermes (v2), a stateless, agnostic protocol for orchestrating AVs on our developer portal
Summary
- When it comes to sending the right vehicle, at the right time and to the right place, there is a common underlying language between AVs and drivers connected to an orchestration platform.
- When it comes to understand why this vehicle needs to (or cannot) go here, at that moment, and for what reason , the differences between humans (also those seated in the control tower) and the AVs require different interfaces, and additional mechanisms.
Different levels of “smartness”, different languages
AVs are not all equal. While some of them — advertised heavily on the Internet by tech leaders — are impressive in terms of autonomy, others can barely follow a very limited set of commands in a very tightly controlled environment. In reality most of these robots today are operating in a very specific transportation setup, with little to no interaction with other transportation systems.
Comparing again with human drivers, if you had to drive in a foreign country, you would quickly realize that the rules are similar. Behaviors can vary a lot with culture, but what is expected from a professional driver operating for a transport company is usually quite similar.
The main differences between two drivers who live in very different countries might boil down to the language of the interface (i18n feature).
- Routing providers for humans (GPS navigator) have very similar features across the world. With some difference in data quality, the experience of the driver usually complete the gap if any.
- If you need a specific routing constraint, like avoiding streets too small for your vehicles, you can “train drivers” or in larger operations: provide infrastructure (signage, road marking, …) to ensure that there will be no incident.
When it comes to differences between models of AVs from different manufacturers, the difference can be staggering!
Summary
- For humans, years of experience, plus mature tooling makes it simple to port a solution from one human to another, even if the cultural differences are big.
- For AVs, immaturity of some tech stacks, lack of common tooling, non-existing or different regulations, or again IP protection, to cite only those points, make it very difficult to design a solution to fit all brands and models. Bestmile has been forced to adapt by providing a common protocol for orchestration (Hermes), but also building adapters to take into account differences between vehicle integrations and the manufacturers’ development capacity.
- While all those different vehicles are being integrated with our platform, adding the human to the equation is only a small and easy stretch in comparison.
The second half of the story can be found here.
