What it means to be “AV-first” when designing a new mobility platform — part 1/2
By: David Geretti
Tags: Autonomous Vehicles, Engineering, Driverless, Fleet Orchestration, Product Design

“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.

Vehicle plan example, extracted from a live commercial operation in Switzerland

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.

Example of interface giving choices to the driver, despite the protocol having an opinion about when the mission should start

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