This Little Guy Needs a Brain
Lessons from two days designing how a telco could help a food delivery robot think, learn and recover in Los Angeles.
Last week I was in Los Angeles for one of the most interesting projects of my career, working with a tier-one operator and a robotics startup on a challenging problem. When a delivery robot cannot think its way out of a situation, where does it borrow a better brain from, and can a telco rent it out?
The project is confidential, so I will keep names and sensitive details out, but the areas we identified are worth sharing while they are still on the drawing board.
Some context on scale. Only Los Angeles already has more than 500 sidewalk delivery robots operating across some 40 neighborhoods, plus several hundred Waymos inside a US fleet above 3,800 vehicles, plus Nuro, Zoox and a growing number of drones. Thousands of autonomous machines in one metro area, and Goldman Sachs expects the global robotaxi fleet alone to grow from about 7,000 vehicles to roughly a million by 2030. Every one of them carries a SIM and a data plan worth a few dollars a month, and that is the entire commercial relationship telecom has with them today.
These little machines are capable despite their frail look. Sidewalk fleets report completion rates near 99.8%, and the onboard stack handles navigation, crossings, and the trip home.
But most of their problems live in the tail. For example, Sidewalks closed since the map was built, Addresses that resolve to a courtyard invisible from the street, A scooter across the only curb cut, or corners where the radio link drops at the wrong moment. In those cases, the robot stops and escalates to a human. A public example is Waymo, which told Congress it keeps about 70 remote assistance agents on duty for some 3,000 vehicles, giving advice while the vehicle remains the decision maker. So the demand already exists and is already paid for, currently in salaries.
In my initial discussions with the food delivery robot startup, a ground rule was set: motion control stays on the robot, running in tens of milliseconds, and no radio link goes inside that loop. Nobody proposed the network drive anything, so the ultra-low-latency story of a driverless vehicle was gone in a few minutes. Instead, the work was everything above the loop, and we mapped it into six concrete service areas, plus a short list of things we decided not to pursue.
Eight places where a telco brain can create value
The robotics startup team, the telco engineering team, and I spent two days with a whiteboard and the fleet’s incident data.
At first, we made little progress. The operator had a list of network capabilities. The startup had a list of operational problems, but the two lists did not connect. The discussion improved when we mapped the robot’s actual operating cycle.
The robot sees something. It cannot resolve it. And it asks for help. The request is sent to the most appropriate brain. The robot receives an answer, acts, and reports the outcome. That experience should then improve the next decision.
We identified eight places where a telco could add value to that cycle. To be honest, the operator has a credible position because it can combine four inputs: the machine’s identity, the current and predicted radio conditions, the available compute locations, and, with the right permissions, what other machines have recently learned about the same area.
1. Convert the physical world into tokens
The first problem is the amount of data produced by the machine. A robot may carry several cameras and other sensors, but continuously sending raw video to a cloud region is expensive. It consumes uplink capacity, backhaul, cloud ingest, storage, and inference resources.
A better architecture converts the relevant part of the scene into a compact machine representation. A lightweight encoder on the robot extracts the initial features. A tokenization function at the metro edge can then enrich, validate, and route those features without sending the full video deeper into the network.
Instead of forwarding every pixel, the system may send something closer to:
Blocked curb. Unknown temporary object. Pedestrian approaching from the left. Alternative route confidence 62 percent.
Raw images would still be required for some incidents, particularly when detail or auditability matters. But many requests can be handled using a much smaller scene representation.
Our working estimate is that suitable continuous streams could be reduced by close to two orders of magnitude. The exact result depends on the sensors, model architecture, and amount of visual detail required. The fleet saves on cloud transport, storage, and processing. The operator avoids carrying a large volume of low-value upstream traffic through its core network.