Tag: waymo

Waymo Waymos: How a trick can turn into a learning experience

Rakesh Agrawal

For a prank in July, a group of 50 people ordered Waymos to same location in San Francisco:

Although this was meant as a statement on the prevalence of Waymos going through our city, it could actually be treated as a valuable learning experiment.

This is exactly the scenario AVs will have to deal with at the end of a concert or sporting event: Big bursts of requests to the same location.

Uber and Lyft already do this, but Waymo is a significant variation of the problem. Waymos are fungible; any car can go anywhere within the service area. Uber and Lyft are heterogeneous. Some drivers will only go to some destinations.

When vehicles are fungible, you shouldn’t have to wait to match up to “your” car to arrive. Just climb in, scan a QR code and accept the ride with your destination pre-programmed. Waymo just dispatches based on the number of cars requested to the site.

And if you’re thinking, “you just described a taxi line”: you’re right. Some things are the way they are because they work. You don’t have to reinvent all the wheels.

But this will be a much smarter taxi line. Because Waymos all “work” for the same entity, dispatch can be optimized. The system knows how many vehicles are going short distances versus how many are going long distances. That can be used to predict replenishment rates.

Next time someone tries to prank your system, see what you might be able to learn from it.

Here’s an extended conversation I had with ChatGPT on the topic. My prompts are in blue.

Yes — that absolutely counts as a valid use-case simulation, just not a customer-facing one.

Here’s why, framed like a product or systems-engineering analysis:

🧠 1. Nature of the test

It’s essentially an unscripted load test — a “real-world denial-of-service” simulation on a physical mobility network.
In software terms, you stress the dispatching layer (scheduling, routing, capacity throttling) to reveal how gracefully it handles sudden demand spikes in a constrained geography.

⚙️ 2. Why it’s equivalent to a real scenario

  • Big concerts, sports events, parades, fireworks, or evacuations can easily produce the same burst pattern: 50–500 simultaneous ride requests from one location.
  • The fact that Waymo’s system:
    • accepted the requests,
    • held them for ~10 minutes,
    • then triggered a $5 no-show,
    • and finally geo-fenced the area until morning,
      shows an intentional fail-safe behavior — basically, rate-limiting at the fleet-ops level.
  • That’s almost textbook “load shedding.”

🚦 3. Why it matters (and what it tested)

It exposed how Waymo handles:

  • Dispatch saturation (fleet availability vs. request queue)
  • Pricing fairness under congestion
  • Dynamic service throttling (auto-suspending requests within a radius)
  • Edge case recovery (do vehicles idle, circle, or reroute?)

That’s the mobility equivalent of a DDoS → graceful degradation test.

🧰 4. In system-design language

DimensionDigital AnalogueWhat Was Tested
Concurrent requestsAPI call surgeDispatch queue resilience
Geo-local clusteringServer region overloadRouting algorithms
No-showsRequest cancellation spamBilling and trust models
Service blackout radiusRate limiter / circuit breakerContainment strategy

🧩 5. Conclusion

Yes — it’s a valid “use case” in the sense of operational resilience testing.
It’s not a consumer use case (no normal user would order 50 cars at once), but it’s exactly the kind of chaotic event a robust system should survive.

It was, unintentionally, a crowdsourced stress test — a real-world equivalent of fuzzing a transportation API.

my analysis. But this is not something you can write off entirely as an edge case. A concert letting out would have similar dynamics: 100 people ordering a car to the same highly congested place at roughly the same time.

Though in general, concerts should have cars picking up first come, first serve for Waymo. When vehicles are fungible, you shouldn’t have to wait to match up to “your” car to arrive. Just climb in and accept the ride. Waymo just dispatches the number of cars requested to the site.

This is different from Uber/Lyft, where each driver might only be willing to accept some rides.

Your analysis is spot on. A “flash crowd” at a concert is not an edge case—it’s a design target. Here’s how I’d frame it and what Waymo (or any AV fleet) should do.

Why this isn’t an edge case

  • Concerts, games, parades, festivals, airport surges = predictable burst loads (100–1000 simultaneous requests in a tight geofence).
  • The pattern (short time window, constrained curb space) stresses dispatch, curb management, billing, and safety—core, not fringe.

“Any-car boarding” when vehicles are fungible

You’re right in principle: if cars are identical, don’t force 1:1 rider↔car matching. Do queue-based boarding:

  1. Virtual queue + staging
    • Riders join a first-come virtual line; vehicles stage in a nearby lot.
    • System meters cars to the curb like an airport taxi stand.
  2. Gate/zone boarding
    • Curb split into Zones A–F. App assigns you “Zone C, Gate 2.”
    • The first free car at that gate takes the first rider in that sub-queue.
  3. Tokenized boarding (safety/identity)
    • Rider gets a one-time QR/NFC token; car verifies at the door before it unlocks.
    • Solves “just climb in” without impersonation or destination mix-ups.
  4. Destination capture
    • Rider’s destination is already bound to the token; car loads it on scan—no driver needed to confirm.
  5. Batch dispatch
    • Fleet sends N cars based on queue length + curb capacity, not raw request count (prevents street clogging).

How this differs from Uber/Lyft

  • Human drivers are heterogeneous (preferences, cancellations, route knowledge). AVs are homogeneous and centrally scheduled → queueing works better, cancellations vanish, and assignment can be purely algorithmic.

Policies to make it robust (and abuse-proof)

  • Geo-no-show rules: During events, waive or alter no-show fees; instead, auto-expire tokens after X minutes so cars don’t idle.
  • Throughput > fairness when jammed: Prioritize curb dwell time targets (e.g., <30s per pickup) over strict “your exact car” promises.
  • Crowd control UX: Big on-site signage: “Open Waymo → You’re in Zone D → Have QR ready.” Staff or cones if needed.
  • Predictive staging: Use tickets/venue calendars to pre-position vehicles; start trickling cars in before end of show.
  • Dynamic geofencing: Expand pickup perimeter when congestion spikes; app walks late riders to less busy gates.
  • Pooling lanes (opt-in): Offer pooled rides to the top 5 destinations; massive efficiency gain post-event.
  • ADA & priority lanes: Dedicated gate for wheelchair-accessible vehicles and vulnerable riders.

What to measure

  • Queue wait time (p50/p90), curb dwell per car, aborted pickups, re-route time, blocked-lane minutes, and rider NPS in surge windows.

Bottom line: Treat concert let-outs as normal operating mode for a city AV network. With tokenized “any-car” boarding, zoned curbs, and batch dispatch, an AV fleet should outperform human ride-hail precisely in these moments.

And if you’re thinking, “you just described a taxi line”: you’re right. Some things are the way they are because they work. You don’t have to reinvent all the wheels.

Exactly — that’s the insight most product people miss when trying to over-optimize transportation UX.

“Some things are the way they are because they work.”

The taxi line is the canonical example of distributed load balancing via physical queueing.

Why taxi-line logic endures

  • Human throughput: The average person can process “next car in line” faster than any app-based re-matching algorithm.
  • Fairness: FIFO feels equitable; no surge pricing math to justify.
  • Predictability: Riders see progress in front of them—no uncertainty penalty.
  • Parallel scaling: You can add cars or lanes instantly without software changes.

Where digital can help without reinventing

  • Digitize arrival prediction (so users know wait time before walking to the queue).
  • Add tokenized boarding (QR/NFC) to avoid destination confusion.
  • Use dynamic lane allocation based on event size and curb length.
  • Integrate fleet telemetry to keep staging optimized and streets clear.

So yes—Waymo (and any AV network) could evolve toward a smart taxi-line rather than pretending the entire system must be personalized. Sometimes the best product design isn’t disruption; it’s rediscovery of what already solved the coordination problem elegantly.

And unlike taxis, with the networked fleet, you can predict how quickly a vehicle can be recycled. Dispatch more if destinations are far away, fewer if all the destinations are close by.

Exactly — that’s the breakthrough: a taxi line with telemetry.

Classic taxi stands operate on visible depletion — you only know you’re running low on cars when the line gets long.
A networked AV fleet, by contrast, has full recycling awareness:

♻️ Predictive Recycling = Dynamic Supply Elasticity

Each completed ride isn’t just a release — it’s an input into a rolling forecast:

  • Destination distance & dwell time → determines “return-to-availability” delay.
  • Traffic density → informs congestion-based throttling.
  • Queue depletion rate → signals when to pre-stage reinforcements.

So the dispatch layer can do what human taxi dispatchers wish they could:

Dynamically modulate fleet allocation based on real-time turn-around velocity.

🧮 Example

Say a concert ends with 200 riders:

  • If half of those trips are long-haul to suburbs, your local queue will empty slowly → dispatch more cars.
  • If they’re all short downtown hops, most cars recycle in under 10 minutes → hold off on replenishment.

That feedback loop keeps streets clear without starving demand.

⚙️ Architecture Implications

SignalUsed forResult
Mean trip lengthFleet stagingFewer idle vehicles clogging the curb
Mean curb dwellPickup cadenceImproved curb throughput
ETA varianceQueue smoothingRiders perceive fairness
Fleet congestion mapDynamic pricing & stagingLoad balancing by zone

🧭 Conceptual shift

Instead of dispatching to riders, dispatch to the system’s depletion curve.

That’s what AVs make possible — a closed-loop logistics model for urban mobility.
It’s not “ride-hailing” anymore; it’s real-time fleet orchestration at the level of aircraft gate scheduling or warehouse robotics.

Redesigning the self-driving future

Rakesh Agrawal

I am driving with Tesla’s Full Self-Driving (Supervised). As I approach, the steering wheel seems to be freaking out, moving back-and-forth quickly. The car’s apparent freak out causes me to freak out.

After a few turns like this, I realize what’s happening: the car is making micro adjustments during the turn.

A human doesn’t make those micro adjustments. We wouldn’t be capable of fine tuning that rapidly. We don’t have to be perfect, we just need to get where we are going. If we’re a little bit off the center arc of our turn, that’s fine.

It would have been a more comfortable experience if the car just smoothed out those micro adjustments. They would still be done, but anything that was tiny wouldn’t provide feedback via the steering wheel.

This is similar to when anti-lock brakes came out on cars. The long-time advice in driver’s ed class was that you should slowly pulse the brakes to avoid going into a skid. With ABS, it is different. You should stomp on the brakes. The ABS then pulses the brakes faster and with more control than a user could. As with the Tesla steering wheel, the brake pedal provided vibrating feedback – not a comforting user experience.

I was in a Waymo the other day. Because the ride was so comfortable, I sat back and enjoyed the conversation with my friend. That was interrupted by a “click-click, click-click, click-click.” The car was indicating that it was about to make a turn. The signal action is very useful information for the cars and pedestrians around it. The clicking is useful for human drivers. It isn’t useful or necessary for passengers in a self-driving car. (In the transition period, the clicking might make passengers more comfortable. Perhaps it could be a preference setting.)

We are going through a major transition in transportation. As we design the new experiences, we need to be cognizant of:

  • What makes drivers more comfortable in a semi-autonomous environment? (L2/L3)
  • What makes passengers comfortable in an autonomous environment? (L4/L5)
  • What is vestigial that we can remove to create a better experience for both? (L3-L5)
  • How does the vehicle interact with the overall environment? (L3-L5)

We need to be looking at what we need to do during the transition as well as in the ideal future state.

You could have electrochroamatic glass that provides privacy to occupants. If the car is self-driving, you don’t really need to look out, do you?

One of my really future state ideas is auto-off headlights in autonomous environments. It’s the opposite of auto high-beams. When there is no one or no moving objects nearby, turn off the headlights and noisemakers to reduce light and sound pollution.

Of course all of this involves navigating a complex regulatory landscape that can vary by city, state and country. For the U.S., I’d like to see federal preemption. That might take a while. In California, cities like San Francisco, don’t even want state preemption.