openmobilityfoundation
Clearer support for AV taxis (Robotaxis) and stop events
Is your feature request related to a problem? Please describe.
MDS 2.0 already supports all kinds of passenger services, including robotaxis, and the OMF has a blog post on the topic. However, the description of the mode lists these use cases:
Passenger Services refers to taxis, transportation network companies (TNCs), commercial transport apps (CTAs), and private hire vehicles (PHVs). Passenger Services typically have a driver, one or more passengers, and multiple passengers may be on different trips
and focuses more on the taxis vs TNCs use cases.
Additionally, it's not entirely clear when an AV operator should use which vehicle state for planned and unplanned or emergency stops. The existing states and event types need to be updated with clearer descriptions, and possibly a new states added for unplanned/emergency stopping, and human interventions.
Describe the solution you'd like
Clearer support for AV taxis (aka robotaxis) use cases within the Passenger Services mode, and appropriate vehicle states.
Also with the abilities of AV sensors and technologies, other clarifications and new abilities in MDS need to be utilized, including full support for real-time Policy, clear support for real-time emergency response for Policy, and crash information, both historic and real-time (#613). These items will be addressed in other issues here.
Make sure the spec is clear on planned and unplanned stopping definitions for devices.
Is this a breaking change
- No, not breaking
Additional context
Our public working groups have been discussing some of these issues in 2023 (Jul 6, Oct 26, Dec 7) and 2024 (Jun 6) and other webinars, conferences, board discussions, and events.
See these public meeting notes from Jul 6 2023:
How can MDS capture location, duration, and reason for AV pax services unplanned stops (e.g., AV stops on rail tracks) and planned stops (e.g., pick-up/drop-off events)
- Could be captured as events, which would allow for capturing durations.
- Capturing reasons currently not captured but it's possible. Depends on what information is available to operator.
- May need to consider latency of data - more information might be available later.
- Modifications to MDS can be made, tested, and proposed for inclusion in the formal spec via GitHub.
- Could also associate with Telemetry data, e.g., data from companies like Drover can indicate if micromobility device is on sidewalk.
From the July 11 WG:
Something that can communicate data on if the vehicle is autonomously controlled, remotely controlled, remote assistance, or human driver, etc. Possible https://github.com/openmobilityfoundation/mobility-data-specification/blob/main/modes/passenger-services.md#trip-attributes
Good to know this info to see why the issue or intervention happened, and how to take corrective action, eg to infrastructure.
Maybe include Delivery Robots mode as part of this as well. Teledriving vehicles in Las Vegas, FYI.
If we want this to make it to the MDS 2.1 release, we are going to need someone to make a PR in the next month or two so that it can be discussed and reviewed by the steering committee and working group.
DC is interested in advancing this topic. We are planning to require MDS for AV testing, which is not clearly one of the existing modes since those trips are not actually "trips" in a sense - they aren't moving anything but the vehicle (and a safety operator) generally.
We would like particularly to know the routes driven and who/what was driving the vehicle so we can understand rates of human intervention and where and when the vehicles are doing better or worse so we can see what contexts are challenging. We'd want the framework to also work for capturing where vehicles get stuck and how fast they are rescued.
The trip schema includes a trip_type field that could be expanded to include testing trips. The current set of passenger services values is here: https://github.com/openmobilityfoundation/mobility-data-specification/blob/2.0.1/modes/passenger-services.md#trip-type
We will be discussing AV trip types and unplanned stops at at this week's public MDS Working Group meeting.
For testing trips, I agree we could add a trip_type of testing to capture these pretty easily.
For unplanned stops, we may want to add an event type of unplanned_stop to capture these. From there the trip can continue to trip_resume, trip_stop, trip_end, or a cancellation event.
Unplanned stops could also connect to the general concept of an incident, of which an unplanned_stop is one of many incident types. See this discussion.
From the MDS Working Group meeting:
- Maybe need 'trip_purpose' Trip attribute to define something like 'mapping' as part of a testing trip type or more detail about a trip.