Our Alpha riders told us to build a better “turn-by-turn navigation” experience
While ferrying our alpha riders in Sacramento, I had a hunch that there would be significant usability friction for drivers using turn-by-turn navigation without an integrated in-app experience. This was particularly felt when a new ride request was added to existing vehicle pooling route plans in our service. Drivers receive a push notification from Go360 that their vehicle plan has changed and were required to switch back to the Go360 app from Google Maps navigation to regenerate a new route on Google Maps by clicking the deep link in the vehicle plan.
Since both iOS and Android sandboxed applications are prevented from manipulating 3rd party apps, the driver has to constantly switch between the apps and using deep links. Existing turn-by-turn navigation functionality is a closed loop ecosystem with walled gardens because Google, Waze, and Apple Maps refuse to let third party apps use their turn-by-turn navigation experience. Google, Uber and Apple Maps protect this functionality like it’s their first child.
This results in a scenario where developers that need to update turn-by-turn navigation have to account for the context overhead of switching from the app they are building to an app like Google Maps. Unfortunately this switching requires tactile feedback and does not work without the driver touching the mobile device while driving. Mandating an inhouse turn-by-turn navigation experience as part of the Go360 roadmap was now becoming a reality after watching the drivers operate the app in a cumbersome way.
Since Google Maps only allows deep links from third party applications, it’s pertinent to have a viable solution that can use Go360 to seamlessly update the turn-by-turn navigation experience for the driver. Switching between Google Maps and Go360 for navigation purposes is a non starter and my hypothesis about the user friction in the experience turned out to be true.
On top of the awkward communication between apps for turn-by-turn navigation, urban canyons pose additional complexity by making it more difficult to localize the vehicle. In places like downtown San Francisco, I routinely faced poor GPS reception which translated into high location error.
Frequently, the position data from my phone would place me 1–2 blocks away from my true position. This made it difficult to locate passengers or drivers when operating a transportation network. The position of the driver and rider affects the turn-by-turn navigation instructions. In the example below, a driver on Bush street might be placed on Sutter street. In the same way, a rider requesting a ride from Bush street might be placed on Montgomery street. In busy downtown areas, being on different sides of the street can also cause inefficiency in pairing the correct driver with rider.
This GPS error not only causes discomfort for the rider, but decreases the operational efficiency of the service, often turning an estimated ETA of 1–2 mins to 7–12 mins as the passenger and driver struggle to find each other. To address this hassle for the riders, we decided to build our own turn-by-turn navigation solution that works both on the rider and driver apps.
Process for creating turn-by-turn navigation
The first step towards creating a turn-by-turn navigation is to create a 3D structure using a sensor kit.
By ingesting 3D structure data into a multistage data pipeline, relevant features are extracted and converted into a routing graph. Then the metadata is added to the routing graph with information such as street names, directionality of lanes, speed limits, POI data, upcoming intersection and other context pertinent to navigation and routing.
The routing graph is then ingested into route optimization algorithms to create a route plan between an origin and destination. These are called OD pairs. The route optimization algorithms are multidimensional. One dimension can be distance and another can be the complexity of the vehicle maneuver and another can be the average speed on a particular road or in a specific lane. In case of road closures, the dimension of “average speed” is close to 0, and hence that particular road will be ignored by the route optimization algorithm.
There are additional complexities to take into account when implementing a pooling based approach. The route plan of each OD pair is not enough but the combinatorial plan of all the different OD pairs as a set has to be considered. The additional layer increases the complexity and requires some smart engineering to be compute efficient. There are further complexities when you are required to manage state across each iteration of optimization to ensure that passengers assigned to a vehicle are paired with the same vehicle next time. The output of the route optimization is a vehicle plan. This is the input that is required by the turn-by-turn navigation module.
How we ingest vehicle plans to create a turn-by-turn experience
For our turn-by-turn navigation for each stage of a vehicle plan, we have to localize the vehicle and determine which lane it is occupying in the spatial graph. After continuously monitoring the location of the vehicle, we have to trigger audio and visual feedback at the right moment. One example is “stay in the left lane to turn on Main St in 300 feet”. In that instruction, we have to analyze where the vehicle is, how many lanes there are on the road, and how the driver should manipulate the vehicle to be in a position to execute the next turn. We specify the name of the street on which the turn has to be executed and we inform the driver of the relative distance between their current location and the location of the turn onto Main st. The goal is to reduce the cognitive load on drivers’ brains so they can focus on driving, while minimizing the number of decisions the driver has to make to go from pickup to drop off.
The visuals comprise of the car’s location and computed route rendered on a lane level map. Based on the current location, we enrich the information for the driver by showing metadata such as:
- Road name
- Geometry of the road
- Time to destination
- Distance to destination
- POI information
- Speed limit
- Distance till next intersection
- Guidance on when to change the lane to prepare for a turn or merge
The visuals are supported by synthetic voice modulation which guides the driver on their vehicle plan and alerts them on events such as change of lane, pick up, drop off or an approaching intersection. The alerts are based on the current vehicle location on the computed route. If a driver moves away from the computed route, then the route plan is re-computed and the navigation plan is updated. A state machine on our backend is monitoring the current location of the cars and re-computes the route plan if there is deviation from the route plan, addition of a new trip or completion of an existing trip in a vehicle plan. This state machine runs at 10 Hz in our backend and sends the updated vehicle plans to cars.
Further turn-by-turn navigation helps us define pickups and drop offs that are easily accessible by both drivers and riders. This is helpful in large building complexes such as malls or office complexes where there might be multiple entry and exit points for a given POI name.
Coming back to our original pain point of the situation when a new ride is added to the vehicle plan while the vehicle is ferrying a rider. With our turn-by-turn navigation, we notify the driver through voice and visual alerts about the change in vehicle plan. We then render the new route plan in the visuals to accommodate the new ride request. The in app turn-by-turn navigation allows the driver to have their complete focus on driving and ensures a safe and anxiety-free trip for the riders.
How we update the spatial graph for turn by turn navigation
The turn-by-turn navigation will be used as long as the underlying data layers are correct. If the data changes, for example, in the case of construction or road closure due to events, then the drivers will avoid using our turn-by-turn navigation.
To update the lane level speeds, we first use the Go360 vehicle speed and its lane level location to get the speed for its current lane. We then get relative speed of vehicles in adjacent lanes of the Go360 car through Multi Vehicle Tracking (MVT). MVT is different from the traditional approach of crowdsourcing lane level speeds through GPS traces of vehicles. In the traditional approach, one vehicle on the road updates one vehicle’s speed on a road level. With Multi Vehicle Tracking, a single vehicle can update the speed of multiple vehicles in its surroundings on a per lane level.
This allows us to have the most up to date lane level data of cities where Go360 operates its subscription services while utilizing a fraction of the cars used by the traditional approach.
It is akin to radio communication between the cab drivers in major cities and having an understanding of different shortcuts for special events or time of the day or any real time traffic congestion or temporary road closures. Besides lane level speed information, we can update information such as temporary road or lane closures, change in signal or signage and any other change in physical infrastructure that might affect route planning.
It’s a technological challenge and monetary investment to create and maintain the infrastructure for creating turn-by-turn navigation. However, given the constraints of existing products and our focus on the luxury ride-hailing experience, we have prioritized turn-by-turn navigation in our roadmap. As technology is advancing quickly, we are excited to be on the front end of offering the most precise and efficient navigational design that will result in better, faster ride-hailing in this new age of transportation.
VP of Growth at Go360