[mncharity]

There are a lot of possible paths between those two points.[1] And the Google directions for car/transit/walk/bike all differ. So why shouldn't Google directions for a bot also be different? All you need is one viable path, and the knowledge of city conditions to find it.

That, or a lawn gnome shell with a display saying "I'll give you a cookie to walk me down this street"...

[1] https://www.google.com/maps/dir/Sutter-Stockton+Garage,+444+...

[lowglow]

possible != viable

But you are folding in a lot of problems with the hand waving of "All you need is one viable path, and the knowledge of city conditions to find it."

Re: HITL/Helper has been considered, but it's not viable to assume there will be someone there in a reasonable amount of time, causing scheduling problems. Predictive models/scheduling theory is important when considering autonomous logistics and resource allocation.

There are a few cases where HITL might be needed, for instance to take over in the case of an obstacle/condition that hasn't been accounted for.

[mncharity]

The idea is, as path constraints are relaxed, city delivery looks more like a graph-connectivity problem than a obstacle-course skills test.

"Apt 3C, ring the bell and come up" vs "1670 Market" vs "Gough and Market" vs "Gough and (two blocks away but more easily navigated) Page". Those range from ARPA-challenge hard, to perhaps plausible. "At 7:35 pm, as my bus arives" vs "7ish" vs "this evening" vs "sometime in the next few days". "During rush hour" vs "during the day" vs "whenever - text me" vs "drop it off overnight". "While I'm jogging" vs "at home/work/food" vs "here's my schedule and cell - intersect me" vs "drop it off anytime". "Regardless of weather" vs "when there's no snow" vs "on a nice day".

Delivery is always a coverage function, even for humans. "We don't deliver there, after 11, in a blizzard." "No, our delivery person won't wait on that corner for you to bike by."

Once a robot is street/sidewalk legal, perhaps it's more interesting to know where it can get to then where it can't? And to try to craft a business model around that.

Few street corners are difficult to reach at 4 am on a weekday. But is there a market for that?

And focusing on connectivity rather than robot tech, emphasizes the potential of hybrids. Maybe Ubers get extra money, and perhaps their passengers a discount, for carrying robots or their payload pods across town. Perhaps it's much technically easier, and permissible, to tailgate a city bus, than to navigate a messy street scene. Perhaps customers get pod points for commuting with other customer's pods. If some robots are simple and cheap, then utilization matters less, and perhaps it becomes plausible sit on a corner for a few hours, waiting for the customer, or for traffic to become saner before crossing. The robot that can handle hairy traffic need not be the dinky little robot that can barely do sidewalks, but is cheap enough to putter down some smooth and empty sidewalk, and sit waiting for the customer to get home.

And tactical intelligence matters. Google maps has like 10 cm resolution in SF. Enough to tell sidewalks with trees and tables, from big empty concrete "highway" sidewalks. City streets are very heterogeneous. The easiest way to navigate a difficult street, is to avoid it. Estimating what that costs in space/time/market coverage, and balancing out a business model, seems the interesting challenge.

Knowing the trash pickup schedule, and routing around those streets, may be easier than driving around trash. Knowing this block is fine for 4 inch wheels, but that block has a tree root uplifting the pavement. This block is concrete, that is poorly maintained brick. Busy vs deserted in the evening. Dog walkers and kids vs commercial and industrial. Basically just Google directions service, for variously capable bots.

> it's not viable to assume there will be someone there in a reasonable amount of time

In a city with Uber, it may well be that humans are too expensive and needed too often, but it seems less likely that they are unavailable. Modulo the previously discussed temporal constraints.

This is all just quick brainstorming, but I just was struck by the "At Asteria..." comment framing the challenge as one of robot capability in the face of intractable street problems, when it seemed the opportunity is a much richer system and market design space.

Is an IoT chinese food delivery bag, that keeps an eye on the food, so the driver can just drop it at the curb and move on, rather than waiting to interact with the customer, is that bag a delivery robot? How much of its challenge is technical vs market? What if it unclips and can creep down a sidewalk, to be more easily gathered afterwards? What if it's a box, and can creep down a good sidewalk, from main street dropoff to nearby customer? Is that cross-town robot delivery? Can robots be one-way, to be recovered manually in the wee hours, moving labor from crunch time with traffic, to night shift with clear streets? Can grocery delivery get permission to drop off IoT boxes instead of dropping into combo lock bins? Can those boxes then get permission to roll empty down night sidewalks, and cross streets, to gather for pickup? Permission to roll loaded during non-rushhour daytime? And so on.