Capturing rebalancing devices (remote or self-driving) outside of trips

[jfh01]

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

There has been some interesting development in "self driving scooters" that can navigate themselves to the customer. For example: https://www.tortoise.dev/

I'm not sure our state machine can handle the concept of a riderless trip. How would we extend it?

Is this a breaking change

A breaking change would require consumers or implementors of the API to modify their code for it to continue to function (ex: renaming of a required field or the change in data type of an existing field). A non-breaking change would allow existing code to continue to function (ex: addition of an optional field or the creation of a new optional endpoint).

• I'm not sure

Impacted Spec

For which spec is this feature being requested?

All of them potentially.

[thekaveman]

This could be accomplished by defining new event types that transition into and out of the on_trip state, different from the trip_start/trip_end events which indicate real user trips. For example, rebalance_start and rebalance_end could be used to indicate an automated rebalancing trip.

Do we want to handle as part of #506, or in a follow-up PR targeting 1.0.0, or save for post-1.0.0?

[marie-x]

I would vote for 1.1 since there's so little time to have the community kick the tires. Also I don't think it's urgent, since AFAIK there are no self-driving scooters yet.

[avatarneil]

I think this relates pretty closely to a more broad question I've been thinking about (particularly for non-micromobility modes): How do we want to represent non-trip movement? This is critical for things like autonomous vehicles (non-trip, non-driver movement), buses (deadheading to the first pick-up point for a route), etc...

Just considering the state machine, I think that there are a few different ways we could go, but it really depends on the specific use-case. I'd argue that for the scenario: User reserves a scooter, and the scooter drives itself over to them we ought to capture that movement under the reserved state, this would translate to other modes very well, such as ride-share where a reserved vehicle is expected to be in motion to the customer. That being said, for micromobility reserved has typically been a 'static' state (no vehicle movement), so perhaps we need a new state to represent it, something like reserved_moving compared to reserved_static (poor naming, but you get the idea).

[marie-x]

Yep, we should definitely try to characterize non-trip movement in the 1.1 timeframe (IMHO). It would be great to start with the perspective of the operators and how they think about it. I believe that's largely how we arrived at the unknown state and transitions in and out of that state.

[schnuerle]

So far we've been discussing 1) modifying the state machine and 2) ensuring non-trip movement.

Should this proposal also include how to modify MDS to support this (not just state machine) and related devices like self-driving bots, sidewalk delivery, delivery bots, etc? Or is that scope too big and be in another issue?

[quicklywilliam]

I'd love to see something done here. Scooters that cannot move themselves often do, in fact, move when they are not on a trip. There are also cases such as getting a new GPS fix where a scooter's location will update. In practice what this means is that the scooter's latest/best known location will drift from what was communicated on the trip end event. We currently have to compare the GBFS feed to infer when this happens…

[mplsmitch]

@quicklywilliam for what it's worth I saw this a lot when I operated dockless bikes because of IOT connectivity problems. A device looses its connection so the field team moves it someplace with better cellular signal. Suddenly its position has changed. I don't know how you would account for this since without a connection the state would not change. And yes, GPS drift is significant, particularly in urban areas.

[quicklywilliam]

@mplsmitch have you seen #503? I mention it because it introduces an "internal state change" via a crossed_geography_boundary event. This event is used to share location updates while the vehicle is in a trip. Conceivably we could have a similar event for parked vehicles (whether or "traditional" GPS data is being shared or Geometry-Driven Events are being used instead).

Following the above line of thinking, it would be pretty straight forward to add an internal state change event that supported all the PROW states. See below where I've put hastily drawn red arrows labeled "location/geometry changed".

It gets a little insane though when you start to think about location updates that would place the scooter in a new jurisdiction (purple arrows and ???s below). Imagine a scooter parked near the boundary of two jurisdictions, with the GPS drift moving it between them. That's no longer an internal state change, but it's also not a transition we support today!

Would also be curious to get @karcass's and @billdirks's thoughts.

[schnuerle]

What do you all think are the specific recommendations and changes needed so this could get into a PR for the 1.1.0 release? Still seems like it could go a few ways and there isn't a specific solution ready yet.

[quicklywilliam]

@schnuerle I'm thinking this warrants more thought and discussion than we have time for in 1.1. I'd suggest making it a high priority for 1.2.

[schnuerle]

See notes from the WG call this week.

• Rebalance, charging, navigate to customer, empty back to new delivery, improve cellular reception
• Sidewalk delivery robots, last mile delivery
• Productive trip movement, or other type of travel
• SPIN: Tele operated using cameras to reposition for obstruction removal. Short distance. Maybe not entire fleet, but a portion of fleet.
• Are trips included in all cases, eg obstructions
• maybe just state machine options are added for now with no trip/location data added
• This needs a provider to deploy at scale, or city needing this to be known. Start with sidewalk delivery which is happening now, and update MDS to support this. Ensure to align that to rebalancing and tele operation. Not currently part of OMF scope but when it is ensure this is brought up

Should this Issue be clarified to be about delivery robots like Tortoise, or about just tele operated/obstruction/charging use? Then a new issue can be make for the other.

[schnuerle]

We will be discussing this topic at tomorrow's Working Group meeting.

[schnuerle]

Notes from the public working group meeting:

• After drop off bot may not be available and might need to move to waiting zone, new state or new transition to unavailable
• Need to put in provider, possible in agency
• Drop off, end of trip, and/or linking points along the way
• Track period between trips - like lifecycle of ride hail trips
• See https://ww2.arb.ca.gov/sites/default/files/2020-04/April_1_CMS_workshop_slides.pdf Slide 8
• Develop something for other vehicles, map state machine to that in use in LA
• LA has remote operated robots
• Map to existing State Machine first instead of making changes now in MDS - prove it out
• Scenario where you may want to know the number of packages on board change as deliveries happen - but cities might not care about this
• Dwell time on sidewalk. Why it’s pausing, where it’s going.
• PDD - personal delivery device
• We could add extra states to Policy for testing by city in a fork, then add useful ones back into MDS
• Fork MDS and then bring back changes later
• OMF can offer a forum for discussing all the current work happening from all parties
  • Drop in discussion, affinity group, gathering docs in one place, get contact info, temporary working group could be made
  • La, San Jose, blue systems, e&A, tortoise - get people together in public area, gather docs and choices
• Taxis? GDEs? May be possible now, but keep robots separate from TNCs/taxis as the latter is a much more mature space

[schnuerle]

The City and Provider Working Group Steering Committees met last week for the Midway Checkpoint for the 1.2.0 proposed release. The Checkpoint let them review feature proposals, align current work to goals, and ensure the release features and work is on track. 

For this work, we have created a new rubric to help guide the evaluation, looking at feature utility, stakeholder adoption, implementation simplicity, direction consensus, and work completed as part of the evaluation criteria. The outcomes and actions from these discussions are summarized here:

Very good utility and adoption potential for this, as well as potential consensus on urgency and direction. Not sure of how much work is needed, how to implement, or how complex changes would be.

Actions: Create a “Community Group” (in the creation process by the OMF) to have the discussions needed, decide on a solution, and find stakeholders to commit.

[schnuerle]

Per the Consensus Checkpoint for this release, the WGSC decided that this should be moved as a breaking change for the next major release and part of a larger discussion on modes.

[schnuerle]

Comment from @tristan-charreton on issue #652 about making this mode apply to 'Delivery' in general and not as narrow as 'Delivery Robots':

Hey OMF Team ! Hey @alexdemisch and @schnuerle . I see that this discussion has been quiet for a while but I think it might be the best place to ask those questions :

• Regarding the new modes, why have a mode specific to 'Delivery Robots' and not a mode 'Delivery' in which we precise if it is a robot in the vehicle type. The workflow, the states and the events should be the same (or almost the same) ? And we might want to include all types of deliveries in this MDS 2.

• It seems like you had a different definition of a trip (see Elizabeth's screenshot above from 14th Aug 2021) for a delivery robot (where a trip is a segment) and a rideshare (where a trip is an order from a customer). Although most delivery bots' operators only handle one order at a time :

  • it might still be interesting to have the same definition for every mode so that it helps the standardization (some operators do both deliveries and passenger services)
  • some operators might or will handle many deliveries at once (same idea as a pooled ridehail trip) so it's important to anticipate on that.

I came up with these questions as I am working with Kiwibot on the Delivery mode PR and I think these need to be addressed before we move on.

[schnuerle]

I created a new issue #782 which will focus on new mode of Delivery Robots. The issue here was being used for that purpose a bit, but it was really created for something different around device rebalancing and out of trip movement. It's been renamed to reflect that.

[schnuerle]

These concepts and support for delivery robots and related states has been incorporated with our MDS 2.0 Modes work.