MDS Working Group

• Every other Thursday at 9am PT, 12pm ET, 5/6pm CET

Zoom Registration Link: https://us02web.zoom.us/meeting/register/tZAscOmhpjIuHNakPx6CNbACpjUjw1Gsucr4

One tap mobile: +19294362866,,84170989462#,,,,*612987# US (New York) - though we encourage Zoom

Note: Attendees register upon entry into the Zoom meeting. An attendee count will be posted here after the meeting:

22 Attendees

Main Topics

• Delivery Mode deep dive
  • discuss a draft of the new Delivery Robot mode and solicit feedback from Working Group
  • Delivery draft PR #787 by Tristan at Blue Systems with Kiwibot.
  • Delivery Robots draft feature branch based on PR #787 but limited to robots only
  • Issue #782
  • See prior meeting on delivery robots for slides, recording, and notes
• Slide Presentation
• Meeting Recording - Password: s2$33ShQ

Part of Modes Month.

• Prior delivery robot meeting

WGSC Meeting Organizers

• Host: Steve Brining, Blue Systems
• Facilitator: Michael Schnuerle, OMF
• Outreach: Michael Schnuerle, OMF
• Note taker: Nivedya Madankara Kottayi, SANDAG

1. Switch the events in the slide -DELIVERY ROBOTS: NEW STATES AND EVENTS
2. May change "Trip_stop" to "Trip pause"

Welcome by Steve Brining (Blue Systems)

New member:

• John Brazil, City of San Jose
• Jacob Sherman -- Portland DOT

Housekeeping from Angela Giacchetti:

• ITS World Congress, next week

Presentation: MDS modes month Delivery Robots mode adding MDS 2.0,

Agenda: Overview oof modes

Michael Schnuerle: Topic is delivery robots deep drive.  September is MDS 2.0 modes month. Specific recommendation for the 2.0 release. In October for wrap and discuss the gaps.

Delivery robots:

Discussed a month ago, what kind of uses cases is needed for delivery robots

Have no human driver or passenger on board, an have multiple good deliveries on different trips

• Use cases and data

• Discussion area -- If you are an operator for an agency, a government agency, or a software/hardware service provider in the delivery robot space, please leave your detailed use cases here as a comment.

• Meeting today incorporates DDOT and Blue Systems/San Jose use case comments

• First things is how deep do we have to go with delivery robots. Each come with privacy, complexity, and rider information

• Rebalancing scooters-- how to control remotely, not delivering except the scooter itself

• It is covered in MDS

• Delivery Robots (DR)-- Small goods delivery. Sidewalk/street. Remotely piloted/autonomous. eg kiwiot, this is our focus for 2.0, we did round table, and some learning

• APV (Autonomous Passenger Vehicles) This is kind of covered under Passenger Service mode work

• FGF (Food, Goods, Freight) delivery -- Moving goods. On street. Varied vehicle types. Contract or full-time driver eg. Fedex, Doordash

• Passenger services (PS) -- complexity and privacy issues multiple humans involved and covered by PS mode

• Gray areas are APV and FGF delivery

• Consensus: Delivery is the focus, and other areas could be tackled next release

• Two areas of work - main work done by Tristen from Blue Systems via Kiwiboat and San Jose

• Delivery to all forms

• Take his pull request and just DR referring to autonomous driven goods

We need a consensus from the WG and SC

TC: Include other forms, since same type of data, work with other operators, no complexity is added, easy to widen the scope and allowing operators to keep sending the data

MS: When you get to Amazon, door dash, some of the info in the PS about the drivers, need to at least acknowledge it is a driver and some info about the driver. Already jurisdictions have authority to collect the info. For delivery it is much similar, different from remotely driven vehicle

Jacob Sherman: there is no regulatory authority, and that field can be optional, some operation can keep fields as options. There might not be diff in functionally, PS and DR. may return different fields. Boarder delivery focus than focusing on robot delivery. Lot of cities interested in this space and might an opportunity there.

Meg Young: Some cities require DL to operate this. Some cities require someone to operate and then it becomes autonomous. What operator assigned if they check in regularly.

MS: Some cities may want to know who the driver is, if it is robots only, it is a good decision to have

MY: Driver assigned/not assigned what other info is gathered from this

MS: part of the question, I don't know the use cases, what data to be collected or

Real world exp already using MDS to fulfill the needs of the modes

We need to do that to expand. May be push the release back more, good delivery generic space

Who has authority to regulate - we don't have an answer for that

MM: DR and PS is done in pilot cities,

Can ask Vendors -- alpha version, as a pilot study

MS: Work will still happen; it is visible, and City can look at that and work on it later than taking a decision now

Vladimir G: DR incident where there was yellow tape passing, call the company and ask about the driver and history, Struggle is it open the security reasons, so we need tracking, human way is by putting some IDs

MS: Remote operator identifier

Scope of work: id we get into FGF delivery, and it is creating like some mode which covers everything.  we can have optional field for passenger. If that is route and it is duplicating PS. Confusing where the lines are. Don't want to get to it right now. Probably delaying the release. Separate call or email. Feel free object. Continue work on it, more participants, and more use cases

Slide: What is in MDS and what is not possible now

With MDS policy req juris can society which fields are necessary, optional or don't want etc. for testing out new modes or due to privacy concerns. This is a feature in MDS

Trip types of list in the slide. Do you see any gaps in the list:

New states are added. Instead of trip stop or trip pause

Peter Panov definition about the event in slide.

TC: Whether robots go to restaurant to deliver for food and stops for the food order. Drop off, wait for the customer for the pickup

MS; trip attributes:

Does not include info about if device is loaded or unloaded, or anything about the category of cargo, or contents of cargo. More about the kind of trip or if it has in it or not.

Meg: From regulatory standpoint, good to know loaded or unloaded.

MS: maybe one can infer

PP: If the delivery cancels and brings back to home base.

MS: incident where the goods were stolen,

JS: may be the operator could report back and need not represented in the data

MY: Need no details

MS: propose not having any info about the things in it

Fare attributes:

JS; this is the price the consumer will pay or is this regulatory surcharges or taxes

MS: There are some fields in the MDS:

Info about the std cost, this is the link https://github.com/openmobilityfoundation/mobility-data-specification/tree/feature-modes-delivery-robots/provider#trips

We had 10 payment attributes added in a mode, may be overall cost and have optional for if the jurisdictions needed that

JS: we do not have in the ROW, having it optional reg surcharges

MS: For PS, an exhaustive list. HHs to be added can be added as an comment

VG: in LA - Special operation zone or equity zones

Vehicle attributes:

Does not include info required in some jurisdictions now about fully autonomous, remotely driven, camera locations, wheels, size, weight, height, battery, etc. But that is required in some jurisdictions. Some can point it out as the comment and can be officially added.

Jacob Sherman: these attributes are looked once, may not be included every time, for every vehicle.

MS; It may be specified for trip start

MM; That info can move around

MS; good point, It will not be redundant and can be looked up for that vehicle

Accessibility: Audio visual cues, or opened remotely, debates can go this fields. If you have scenarios, thinks about commenting

Discussion starters in the round table, need feedback

No info about that in the spec reg package and cargo details

Steve Brining:  what about alcohol 

Camilo C: company deliver alcohol, match and identify if  the age is above 21yr old. We need regulation for that.

MS: How to confirm. It is a tricky problem

CC: we are the middlemen but who is responsible

MS: how will these work for delivery. Not sure

VG: We restricted in downtown, medicine deliver can have policy priority, operator can make the communication about the delivery. It needs to be added as the field comes along with the trip

Schedule and next steps:

Leave our comments, spend some time in the area#782

https://github.com/openmobilityfoundation/mobility-data-specification/issues/782

Closing thoughts

From chat:

Camilo Cabrera: In case someone's interested, this is the case that was mentioned before about a robot crossing by the police yellow line: https://www.instagram.com/reel/CihlgOkjUUI

Jacob Sherman:"Age restricted items"... but I'm also not sure how that data is used/why its used

Peter Panov (Lacuna): Instacart makes deliveries of alcohol.

Jacob Sherman: GoPuff too

Camilo Cabrera: Do instacart or gopuff have any protocol to validate age?

Alex Demisch: GoPuff checks ID at delivery