Support for Delivery Robots (remote operated or autonomous) Mode

[schnuerle]

Is your feature request related to a problem? Please describe.

As sidewalk robots (personal delivery devices, PDD, delivery robots, etc) are being used around the world in cities and universities, there is need to manage these devices in the public right of way by agencies, and the work on new modes in MDS could allow that.

Describe the solution you'd like

Add a new 'Delivery Robots' mode to MDS as part of the new MDS 2.0 Modes work.

Organizations and agencies like San Jose, Blue Systems, Kiwibot, etc are already using a modified version of MDS to support the operation of MDS for delivery robots. We'd like to take their learnings and incorporate them back into the next version of MDS. Gathering public feedback from other orgs in the ecosystem is also welcome and required.

Is this a breaking change

• Yes, breaking

Impacted Spec

For which APIs is this feature being requested?

• All APIs potentially

Describe alternatives you've considered

A clear and concise description of any alternative solutions or features you've considered.

Additional context

This was connected to issue #521 previously, but it is now obviously distinct enough to warrant its own discussion here, allowing for a concrete place for organizations to leave feedback. Includes interest from Kiwibot, Blue Systems, Lacuna, Populus, San Jose, SFMTA, DDOT, Pittsburgh, SANDAG, Detroit, Portland

[schnuerle]

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. This will help ensure MDS can be used to meet your needs on the ground.

Use Cases

Use cases can include what sort of information agencies need from operators and for what purpose, what information operators share with agencies and its purpose, and the data fields within or outside of MDS that are needed for these purposes. You can look at the 'Passenger Services' mode comments here to see examples of what organizations have shared.

Kinds of data received now

Data possible in this MDS now

• Individual trip routes
• Start and end locations
• Fees paid for service
• Unique vehicle ID
• Speed policy requirements/geofencing
• Other info typical with scooters/bikeshare

Data explicitly not possible in MDS right now

• Time and distance traveled for a multiple trip journey or (not explicitly, but could be part of journey/trip structure)
• Types of states and events need to capture robot delivery
• Any sort of information about the remote operator, like ID, license (required by law in some locations)
• Vehicle characteristics required by law, like width/length/height/weight, lighting/lamp/LED/flag equipment, storage capacity, top speed, number of wheels, cameras or other equipped sensors.
• Advertising information displayed on device
• Package/cargo details

Member Network Roundtable

Based on an OMF Roundtable that occurred in September 2021 for the Delivery Robots Member Network, which included a review of San Jose’s program & policy approach and a review of technical approaches (Blue Systems, Populus), followed by discussion, we had about two dozen participants share what information is already being shared in the delivery robot space.

We also created some discussion starters, which you can use as prompts here:

• Vehicle Properties: Delivery Vehicle Properties #697
  • When thinking about delivery robots in MDS for city agencies to regulate, how important are vehicle properties and what level of detail do you need? What do you need to know about the vehicle that is making the delivery (fully autonomous, remotely driven, camera locations, wheels, size, weight, height, battery, etc)? What would you do with this information and what are your use cases?
• Trip Reasons: Delivery trip reason names #696
  • When thinking about delivery robots in MDS for city agencies to regulate, how important is it to label trip types in MDS? Is it useful to know the possible segments of a trip (warehouse to restaurant, leaving restaurant to customer, customer to next customer, returning to restaurant, returning to warehouse, etc)? Within the proposed technical structure of Modes in MDS, how should this be accomplished? With custom trip field names for each case? Or maybe a trip_reason field that can be enumerated or free from?
• Package/Cargo Details: Delivery package and cargo details and categories #694
  • When thinking about delivery robots in MDS for city agencies to regulate, how important is information about the package and cargo that is on each trip taken? Do you need to know the details of the items delivered (like a receipt) and if so what policy goals does this serve? Instead would you only need to know the category of items delivered (food, produce, medicine, entertainment) and to what granularity? Do you need to know what programs are associated with the delivery (CSA or farmer's market fresh food delivery program, low income assistance food or supply delivery, medical assistance delivery)? What are your use cases?

Some helpful notes from this roundtable include:

• Other challenge: trip segments/not all trips are equal - empty bots, delivery with 1 package, 2, etc. or return trip or roaming - this concept is not yet in MDS but will be with Modes
• Asked bot company to slice up segments of each journey into new trips with unique IDs and a trip purpose field and package ID that are new
• A separate endpoint package ID does not yet exist but likely will be needed in the future
• package types are of importance - is it food, grocery, goods, etc. - this is where the most work is needed to understand what cities need for use cases and how MDS should specifically be adapted
• Most pilots that have been deployed are similar and less need to understand vehicle types but eventually there will be lots of different vehicles and likely a need to understand this as well
• Example from cities around equity zones. This is another area of anticipated need to adapt MDS

[meg-bcdot]

We're still developing regulations for PDD in Baltimore City, but we have one operator who is on a campus and expanding to the PROW this fall. They are already linked to Populus and are submitting an MDS feed, but it's not functioning totally yet. Our policies are still under development, so our list is growing. Items we expect to enforce via MDS:

• geofencing routes - we will need to be able to export our policy API and track violations of the zones. this will need to be quite detailed and likely linear shapes to prohibit usage on sidewalks under 6ft wide, unlike e-scooter geofences where we have focused more on parcels.
• monitoring idle time/parking - this already exists in MDS and we use it for scooters, but there seems to be more concerns about these sitting idle when we do not know what may be inside of the device and when they are not public but using public space (nobody will walk up and just rent one like they do scooters)
• trip info - of course we want all that for analysis - O/D/Routes/duration etc. and I'm curious to see what level of aggregation will be deemed allowable for this mode, since there is no person traveling on the vehicle.

Regarding Vehicle properties: we will already know the vehicle type based on the PDD permits, this is not necessary under MDS except basic tags like we have for "scooter" or "bike" already.
Regarding Trip Reasons and cargo: I do not think this is necessary for us to know besides "loaded" and "unloaded" to represent when it's making a delivery or returning. Any restrictions on what can/should be carried will be dictated by the law and not pertinent to MDS IMO, I'm not trying to overstep our regulatory authority.
Regarding Equity Zones: I don't think we can define equity in this realm yet -- like how can we say if there are advantages of this delivery type that can help underserved communities? DC does have a requirement that to expand the fleet of PDD there must be delivery partners in other wards, just so the technology spreads.

[stevebrining]

Blue Systems started with a goal of utilizing MDS for robot delivery operators to share data with cities, starting with San José. With robot delivery vehicles sharing some similarities with scooters in that they’re both electric and operate in the public right of way, it seemed natural to make allowances for them to share data in MDS with cities that are considering starting robot delivery pilots or programs. We initially made a small adjustment to Provider to just bring on the delivery portion of trips, but realized this wasn’t covering the whole time vehicles were moving on sidewalks.

Agreeing on the best way to include delivery bots would allow for a faster onboarding process while also extending the usefulness of MDS (along with taxi-related updates too). At a minimum, a delivery-based trip definition that could be visualized by cities and easily developed by delivery operators may help with program compliance. Here are a few items we focused on when working on how to bring robot delivery operators like Kiwibot into the fold:

• Provide a method for robot delivery operators to quickly come online in cities that already utilize MDS for scooter/bicycle deployments.
• Provide a method that’s not too cumbersome for smaller/up-and-coming companies. There is likely some crossover with taxis companies in their bandwidth for working with MDS and a preference between Provider and Agency APIs.
• Make adjustments that allow for cities to understand PROW usage for all aspects of robot movements while in operation, including pickups, deliveries, roaming, etc., allowing the monitoring of any program progress in trip counts, while giving insights about high usage/impact areas.
• Ensure that there is consistency on how a trip may be displayed alongside scooters/bicycles on the same visualization for a city (just the delivery portion, the entire trip including pickup and return, what to do about multiple packages to separate addresses, etc.)

[schnuerle]

See recap (slides, recording, notes) from the second half of the August 18 WG meeting where we kicked off this delivery robot work.

This week's meeting we will do a deep dive on this, including PR #778, and look at how we can implement this in MDS 2.0. Please continue to leave your comments and use case here on this Issue.

There is also a Delivery Robots draft feature branch to review that is based on PR #787 but limited to vehicles without human drivers on board only.