Evaluate Potential Ride#

When a Ride is requested, there are a number of considerations that should be made before this Ride can be accepted. These include:

  • Vehicle being available for new Rides

  • Vehicle being able to stop near to the requested location/s

  • Vehicle being able to route between identified Stoppable Locations (route possible and timely).

The relevant functionality for evaluating a proposed Ride is explained in more detail below. The example in this guide only evaluates if a proposed Ride can be fulfilled by a specific Vehicle for simplicity. This can be translated to any Vehicle in a fleet and can be optimized depending on the operation mode.

Check Vehicle State#

To check whether a Vehicle with id vehicle_id can fulfill a potential Ride, we first need to retrieve the Vehicle’s state by calling the GetVehicle endpoint.

grpcurl -H "authorization: Bearer $ACCESS_TOKEN" -import-path . -proto fleet_state.proto -emit-defaults \
-d "{ \"vehicle_id\": \"$VEHICLE_ID\" }" \
fleet-api.trip.int.moia-group.io:443 moia.fleet.state.v1beta4.FleetStateService/GetVehicle

Based on the data in the response, operation mode and requirements of the potential Ride we then need to answer the following questions:

  • Is the Vehicle currently available for new Rides?

  • Is the Ride feasible with the current Mission? Can the Ride be added to the Vehicle’s Mission without conflicting with other Waypoints and Waypoint Actions?

  • Is the Vehicle close enough to the requested pick-up location to arrive in time?

Select Stoppable Locations#

A potential ride includes requested pick-up and drop-off locations. However, Vehicles can only stop at specific locations, which we refer to as Stoppable Locations. We can check for Stoppable Locations near each of the requested locations by calling the ListStoppableLocations method. We execute the call for each of the requested locations (i.e. pickup and dropoff) and select a Stoppable Location from the given list based on our needs. By setting the radius in the request (i.e. 100 m) we can configure how far passengers at most should walk from their requested pick-up or drop-off locations to the Stoppable Locations.

grpcurl -H "authorization: Bearer $ACCESS_TOKEN" -import-path . -proto maps.proto  --emit-defaults \
-d "{\"desired_location\": {\"latitude\": $lat1, \"longitude\": $long1, \"heading\": $heading1}, \"radius_meters\": 100 }" \
fleet-api.trip.int.moia-group.io:443 moia.fleet.maps.v1beta1.MapService/ListStoppableLocations

If the call returns an empty list of Stoppable Locations we can either repeat the call with a larger radius or decline the potential ride because the Vehicle cannot stop nearby.

The results are sorted by distance to the desired location. Since this endpoint uses pagination the returned list might be incomplete, to get all the results we can repeat the request until next_page_token in the response is empty. However, the first page already includes the closest Stoppable Locations, which should be sufficient for most use cases.

Compute Route#

Having selected a Stoppable Location for pickup and dropoff, we are now ready to calculate an AD Route between the current location of the Vehicle and the Stoppable Locations. Assuming we have a Vehicle that is currently located at (long1, lat1, heading1), a Stoppable Location for the pickup at (long2, lat2, heading2) and Stoppable Location for the dropoff at (long3, lat3, heading3), we can use the ComputeRoute method to check if a route for Current Vehicle Location -> Pick-Up Stoppable Location -> Drop-Off Stoppable Location is permitted and feasible in terms of time.

grpcurl -H "authorization: Bearer $ACCESS_TOKEN" -import-path . -proto routing.proto  --emit-defaults \
-d "{\"origin\": {\"latitude\": $lat1, \"longitude\": $long1, \"heading\": $heading1}, \"destination\": {\"latitude\": $lat3, \"longitude\": $long3, \"heading\": $heading3}, \"via\": [{\"latitude\": $lat2, \"longitude\": $long2, \"heading\": $heading2}], \"vehicle_configuration\": {\"self_driving\": \"true\"} }" \
fleet-api.trip.int.moia-group.io:443 moia.fleet.routing.v1beta1.RoutingService/ComputeRoute

In the response, we check if a route could be computed and if that route contains no violations (meaning the route does not contain any leg with violations). If either of these cases occur, the Ride either needs to be fulfilled by a different Vehicle or needs to be rejected.

Assuming we have received a route without validations, we can use this information to decide if the Vehicle should fulfill the Ride. Considerations to be made here are for example whether the Vehicle can be at the pick-up and drop-off locations at the requested time given the estimated travel times for the legs.

If we now come to the conclusion that the Ride can be fulfilled by a Vehicle, we can accept it and move on with provisioning a Ride.