Feature: Modes - Delivery #787
Conversation
Creation of a delivery.md file on the same basis as for the passenger-services.md file
…t-data/mobility-data-specification into feature-modes-deliverybot
Feature modes delivery
schnuerle
added
Modes
agency/README.md
Outdated
| @@ -373,6 +373,7 @@ The Trips endpoint serves two purposes: | |||
| |-------------------------------|--------------------------------|------------------------| ----------------- | | |||
| | trip_id | UUID | Required | UUID for the trip this payload pertains to | | |||
| | journey_id | UUID | Optional | A unique ID for associating collections of trips | | |||
| | trip_type | Enum | Optional | The type of the trip | | |||
There was a problem hiding this comment.
Here a trip_type is added in order to precise what kind of segment a vehicle is on (picking up the delivery, delivering, roaming, ...).
| | `unknown` | `reserved` | `reserved` | `comms_restored` | The vehicle has come back into comms while reserved by a customer | | ||
| | `unknown` | `stopped` | `stopped` | `comms_restored` | The vehicle has come back into comms while stopped | | ||
| | `on_trip` | `stopped` | `stopped` | `order_pick_up` | The vehicle has come to pick up the order at the restaurant | | ||
| | `on_trip` |`stopped` | N/A | `order_drop_off` | The vehicle is at the customer's place and is waiting for them | |
There was a problem hiding this comment.
here we add the possibility to give even more precision by tracking the waiting time (at the customer's place). Can be interesting but might not be necessary in the MDS 2.0. In any case, it remains optional.
|
Here is an example of the different workflows that can be used by the operators. |
| - `off_hours` | ||
| - `on_hours` | ||
| - `driver_cancellation` | ||
| - `order_drop_off` |
There was a problem hiding this comment.
2 event_types have been added : order_pick_up and order_drop_off.
Also, there is also the possiblity of adding an 'obstacle' event which would switch to 'stopped' status.
|
|
||
| In cases where there are multiple trips ongoing, please follow the trip state model pseudocode for determining what the vehicle state should be: | ||
| ``` | ||
| t = for the one vehicle, all on-going trips which are 'delivey' or undefined trips (we do not take into account 'roaming', 'return' or 'advertising' trips) |
There was a problem hiding this comment.
Here a choice was made : even if we want to track all the movements as trips, we do not consider as a roaming robot as being 'on trip'. Can be debated
| @@ -21,7 +23,7 @@ As with all MDS definitions, they should be described in a way that maximizes th | |||
| | `missing` | Missing | | |||
| | `off_hours` | Off hours - end of service | | |||
| | `on_hours` | On hours - start of service | | |||
| | `passenger_cancellation` | Passenger cancelled a trip | | |||
| | `customer_cancellation` | Customer cancelled a trip | | |||
There was a problem hiding this comment.
the notion of passenger does not fit the deliveries. Therefore, it has been replaced by the notion of customer
|
Per our public working group meeting last week, we will be putting this PR about just Delivery on hold, in favor of the more narrow Delivery Robots mode which is in progress on this feature branch. The WGSC agreed with this today during their planning meeting. We will be incorporating some of the ideas added here in to the new feature branch. |
|
|
|
@pierre-bouffort brought up in our steering committee meeting that MDS sidewalk robot delivery may be ready to be expanded into general delivery services, especially for food delivery. Though if so and when ready, we will need to create a new pull request off of MDS 2.0, as this PR is out of date and not usable now. |
Explain pull request
Work on deliveries to incorporate into Modes
Is this a breaking change
Impacted Spec
Which spec(s) will this pull request impact?
agencypolicyproviderAdditional Information
This draft is for all types of Delivery. For MDS 2.0 we chose to focus on sidewalk delivery robots and leave this broader scope of delivery for a future release.