openmobilityfoundation/mobility-data-specification

Clearer support for AV taxis (Robotaxis) and stop events

Opened this issue · 2 comments

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.

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)

  1. Could be captured as events, which would allow for capturing durations.
  2. Capturing reasons currently not captured but it's possible. Depends on what information is available to operator.
  3. May need to consider latency of data - more information might be available later.
  4. Modifications to MDS can be made, tested, and proposed for inclusion in the formal spec via GitHub.
  5. 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.