Nico Peng
← Back to the Physical AI index

Physical AI · Family 2 · Public-facing route

Public-facing service & delivery robots

How a mobile robot and its operating service work around pedestrians, customers and visitors.

AS OF 2026-09-02DATED · NON-EXHAUSTIVE

Supply badges: “not assessed” means this report has not established a node-wide supply rating. It does not mean supply is plentiful; product maturity and local constraints are discussed separately.

Family 2 · Public-facing route

Public-facing service & delivery robots

Robots move goods or perform services around pedestrians, customers and visitors. Street delivery adds route operations and remote assistance; indoor services can add doors, lifts and building-system integration. The machine and its operating service both matter.

A robot joins a place that was not designed around it

A small delivery robot can carry an order across a campus or neighbourhood. A service robot may move supplies through a hotel or hospital. Both must complete a physical journey among people who have not been trained to work with that machine. Unlike a fenced production cell, the surroundings cannot simply be specified once and kept unchanged.

This is a route within the broader mobile-robot family, not a separate theory of intelligence. It shares navigation, power and drive technology with managed-site robots. The differences are the body and payload, public interaction, building or street interfaces, and the continuing work needed to keep a service running. Indoor versus outdoor is an imperfect dividing line: a hospital is indoors but includes visitors, while an industrial yard can be outdoors and tightly managed.

The map uses delivery as its concrete example. It does not claim that a delivery compartment, a cleaning head and a hospital-handling mechanism are interchangeable. A materially different service payload can justify its own downstream branch when the evidence warrants it.

From a moving prototype to a repeatable delivery service

AI perception and navigation help the robot interpret changing scenes. But the commercial advance is demonstrated when it repeatedly completes useful jobs. Starship reported ten million cumulative deliveries in April 2026, across roughly 300 locations in eight countries. That is evidence of operating adoption; it is not independent verification of the company’s claims about universal cost advantage. Starship’s operating disclosure →

Production can also become a separately supplied activity. Serve’s April 2024 agreement named Magna as its exclusive contract manufacturer, while Serve retained its robotic technology and operating business. This is a concrete reason to distinguish robot design, manufacture and service operation in the chain. The agreement’s fleet target was a plan, not a completed-delivery count. Manufacturing agreement →

Autonomy does not make the support organization disappear. Serve’s 2025 annual report describes remote assistance and physical recovery from a local depot. Those are different activities: a person providing guidance through a connection cannot repair a wheel or retrieve a stranded robot. The relevant economic test is how often each is required, not whether a promotional demonstration contains a visible driver. Operating model and risks →

The enabling supply chain

The robot is one input to the service

Read toward the right, following the physical robot into a working delivery operation. Software development feeds the robot; dispatch, site integration and operating support meet it downstream. Amber links show application-dependent building interfaces.

Product or componentEngineering or productionSupplied outputSupply / processAlternative routeApplication-dependentDevelopment supportMaintenance / support
Each bubble opens its explanation below
The robot is one input to the serviceRead toward the right, following the physical robot into a working delivery operation. Software development feeds the robot; dispatch, site integration and operating support meet it downstream. Amber links show application-dependent building interfaces.

Delivery is the representative route. Public authorization and accessibility obligations shape deployment, but they are not products drawn as bubbles. Remote assistance remains separate from physical field operations. The robot can be supplied as equipment or retained inside an operated service.

Key players are selected examples, linked to their relevant products or work—not a market-share ranking. Some activities are performed inside a manufacturer or operator rather than sold separately. “(private)” marks unlisted businesses; listed parent groups are identified separately.

Building a task-specific robot

The body and payload are designed around a service. The same navigation concept can lead to very different equipment.

Economic nodes

Mobile base & drives

Supply not assessed

The chassis, wheels, suspension and drive system carry the payload through the intended environment. Pavement gaps, slopes, door thresholds and stopping behaviour affect the design. A low-speed sidewalk carrier should not be treated as a road vehicle with a smaller shell.

Key players

Worth understanding

Starship’s delivery robot is one supplied design point; its task-specific body is part of the solution, not an incidental container around software. Delivery-robot design →

↑ Back to the map

Power & charging

Supply not assessed

Cells, pack electronics and charging equipment determine how much work a robot can perform between charging events. The operating plan must also account for returning to a charger, spare units and battery ageing. Battery capacity is therefore not the same as useful service availability.

Key players

  • Pudu Robotics (private) — robot-specific battery and charging system.
  • Wiferion (private) — wireless-charging systems for compatible robot designs.
↑ Back to the map

Service payload

Supply not assessed

The compartment, lock and user interface protect and release a delivery. A different job could require a cleaning tool, inspection sensor or handling mechanism. This node identifies the task hardware that makes travel useful; navigation alone does not complete the service.

Key players

Worth understanding

Payload changes can alter cleaning, maintenance, customer interaction and product assurance even when the underlying mobile platform is similar.

↑ Back to the map

Sensing

Supply not assessed

Cameras and other environment sensors supply observations for detecting people, obstacles, traversable surfaces and the delivery interface. Sensor cleaning, placement and calibration affect what the software can infer. The exact mix varies by robot and environment; the map does not prescribe lidar or a particular vision architecture.

Key players

  • Ouster — lidar supplier identified by Serve Robotics.
  • Pudu Robotics (private) — integration of visual and lidar sensing in BellaBot.
↑ Back to the map

Compute & control

Supply not assessed

Onboard computing runs the robot’s navigation and task logic; control electronics command motion and protective stops. Communications connect the robot to dispatch and assistance. A connection to an operator is not a substitute for onboard fault handling.

Key players

  • NVIDIA — onboard compute supplier identified by Serve Robotics.
  • Serve Robotics — internal motion, braking and communications integration.

Worth understanding

Serve describes protective braking that can override remote commands, illustrating the distinction between assistance and the robot’s own safety functions. Control and operating description →

↑ Back to the map

Data & simulation

Supply not assessed

Route observations, difficult encounters and simulation scenarios help developers train and test behaviour. Data must represent the task and operating conditions rather than merely accumulate kilometres. An unusual encounter can matter more for development than another uncomplicated trip.

Key players

Worth understanding

This work can remain captive to the robot provider. Its inclusion does not imply an established merchant market for every dataset.

↑ Back to the map

Autonomy engineering

Supply not assessed

Engineering combines perception, route selection, motion control and exception handling into behaviour suited to the robot. Developers also decide which situations require a stop or human assistance. The output is an integrated capability with limits, not a claim that every street or building is supported.

Key players

↑ Back to the map

Robot manufacture

Supply not assessed

Manufacturing assembles the body, payload, power, sensing and electronics, then installs and calibrates the software. The commercial manufacturer can differ from the autonomy developer. Serve’s Magna agreement is an example of that division, not evidence that all providers outsource production. Contract-manufacturing example →

Key players

  • Magna — contract manufacture under Serve’s production agreement.
  • Starship Technologies (private) — design and manufacture of its delivery robots.
↑ Back to the map

Product validation

Supply not assessed

Testing examines the produced machine, including faults, mechanical hazards, batteries and protective behaviour. Public operation does not mean that robot safety is ungoverned. UL offers consumer and commercial robot evaluation, including functional-safety services; the applicable requirements depend on product and use. Robot testing and assurance →

Key players

  • UL Solutions — commercial-robot safety and component evaluation.
↑ Back to the map

Service-robot equipment

Supply not assessed

The finished robot is a distinct output: it may be sold, leased or retained by a provider operating the fleet. It supplies the ability to perform a specified task in an intended environment. It does not by itself supply orders, a permitted route, depot support or a reliable customer handover.

Key players

↑ Back to the map

Making the service work

A manufactured robot becomes commercially useful through integration, a flow of jobs and an operating organization. These inputs should not be mistaken for properties of the robot alone.

Economic nodes

Building interfaces

Supply not assessed

A robot working across floors or controlled doors may need an interface to building systems. Otis Integrated Dispatch allows robots to request elevator journeys through an API. This is a real enabling product, but it is not required for a sidewalk delivery that never enters a lift. Elevator integration →

Key players

  • Otis — Integrated Dispatch API for robot elevator journeys.
↑ Back to the map

Route & site integration

Supply not assessed

Deployment work tests the chosen routes, loading and handover locations, communications and exception procedures. In buildings it can include doors and lifts; outdoors it includes the operating area and pedestrian interactions. Authorization is a condition of deployment, not the product of a universal “permission supplier.”

Key players

↑ Back to the map

Order & fleet software

Supply not assessed

Order interfaces and dispatch connect a request to a robot, a pickup, a destination and a completion record. Fleet software also manages availability, charging and service interruptions. Integration with a delivery platform does not guarantee enough eligible orders to keep every robot busy.

Key players

↑ Back to the map

Remote assistance

Supply not assessed

Remote staff help resolve situations the robot cannot finish on its own. Guidance, route clarification and direct remote control are not identical functions; providers allocate them differently. Serve discloses outside remote-piloting providers, so this can be a distinct purchased service. Remote-operation arrangements →

Key players

↑ Back to the map

Local field operations

Supply not assessed

People load or stage robots, manage depots, clean sensors and retrieve machines that cannot continue. Much of this work is local and physical. It cannot be eliminated by moving remote assistance to a lower-cost location; reducing its frequency requires a more reliable machine and operating process.

Key players

↑ Back to the map

Service operation

Supply not assessed

The operator brings together working robots, orders, route configuration and support. It takes responsibility for completing jobs and handling exceptions. These activities may be bundled inside one company, but their separate resource demands remain relevant to the cost of a delivery.

Key players

↑ Back to the map

Completed delivery / service

Supply not assessed

The customer receives a completed delivery or another specified service, not merely time on a robot. Repeated paid work is the useful adoption signal. Delivery counts establish usage; they do not disclose the complete cost of remote help, local support, depreciation and unsuccessful attempts.

Key players

↑ Back to the map

Maintenance & spares

Supply not assessed

Maintenance restores the robot’s mechanical, electrical and sensing systems and keeps software configurations supported. Scheduled service and component replacement differ from retrieving a robot during a live job, although one team may perform both. A service provider that owns its fleet also carries the resulting downtime and asset costs.

Key players

↑ Back to the map

Count completed jobs and the work around them

The opportunity is to perform more short-distance service work with less labour per completed job. The relevant comparison includes robot ownership or lease cost, charging, repairs, remote intervention, local support and unsuccessful attempts. A robot that is available all day can still be underused if the order pattern is sparse or concentrated in a short window.

This makes route density, integration and reliability important alongside better AI. Fewer interventions can improve staffing economics; more eligible orders in a compact area can spread the same fleet and depot costs across more completed work. These are mechanisms to test, not an assurance that every deployment is profitable.

The public-facing and managed-site maps deliberately repeat some inputs. A hospital robot can borrow from both routes. The test for a separate map is a materially different supply and operating chain—not whether a machine happens to cross a doorway. Disclosed operating costs and dependencies →