Last-mile sidewalk delivery robots

Short grocery, food and parcel trips of one to a few kilometres are expensive per drop and are usually done by petrol or electric vans and couriers. Small six-wheeled or four-wheeled robots drive on pavements at walking speed, cross streets using perception models and are watched by remote operators who step in for rare edge cases. Typical value: low-emission, on-demand delivery at lower marginal cost per order once fleet density is reached.

Problem & value

• Today: last-mile delivery is the most expensive leg of the chain. Short, small-basket orders (a few groceries, a meal) are barely profitable with a human courier or van.
• AI value: autonomous navigation among pedestrians, cyclists and kerbs lets one remote operator supervise many robots, and routing/dispatch optimises robot utilisation. Operators such as Starship Technologies (Estonia-founded, fleets in Estonia, Finland, the UK and US campuses) work with platforms such as Bolt, Wolt-type food delivery services and grocers; vendors publish cumulative delivery and kilometre counts on their sites [1].
• Limits on value: robots only serve dense, compact catchments; weather, kerbs, snow and vandalism cap availability. Benefit claims (cost per drop, CO2) are vendor-reported and need independent validation per site.

Variants

• Urban/suburban residential delivery: grocery and takeaway from a hub or store within about 2-3 km.
• Campus delivery: universities and corporate campuses with private paths, simpler legal setting (Starship, Kiwibot).
• Parcel and returns robots: carrier-operated, often with lockers or parcel hubs; also pilots with postal operators.
• Large-payload "road-edge" vehicles: larger robots driving on bicycle lanes (see ROBO-005 for road vehicles).
• Indoor / hotel / hospital delivery: see ROBO-008. Air delivery: see ROBO-006.

How it works

1. order (retailer/platform app)
2. dispatch & routing (robot choice, ETA, charging)
3. robot loads at hub/store (locked lid, customer app unlock)
4. on-board perception: cameras + ultrasonics (+ radar/lidar)
5. detection/segmentation of pedestrians, cyclists, kerbs, vehicles; localisation (GNSS + visual map + IMU)
6. local planner: sidewalk following, obstacle avoidance, crossing decision
7. remote-assist trigger on low confidence (blocked path, construction, unclear crossing)
8. remote operator gives waypoint/approval or takes over at low speed
9. delivery handover (customer unlocks lid via app)
10. proof of delivery
11. return/charge

• Perception is mostly convolutional/transformer detectors and segmentation networks running on an embedded GPU/SoC (NVIDIA Jetson-class); neural nets classify traversable surface, detect people and read traffic-light state.
• Crossing logic is the safety-critical piece: conservative rules plus learned detection of approaching vehicles; many operators let a remote human confirm difficult crossings.
• Human-in-the-loop: remote teleoperation or "remote assistance" for edge cases; operations staff for recovery of stuck or tipped robots; fleet safety review of incidents.
• Fleet layer: dispatch, ETA prediction (PRED-018), charging and demand forecasting, often VRP-style optimisation.

Data preparation

A delivery service needs operational data more than training data: order and address data from the shop system, ERP or WMS; pick-up and delivery time windows; map and route data (OpenStreetMap, municipal GIS) including curbs, crossings, construction sites and no-go zones; and customer contact data for notifications. Typical gaps: addresses that are incomplete or do not match the map, unmaintained construction information, no list of permitted zones, scattered consent and contact data, and no baseline of cost per delivery by other means.

Preparation steps: clean and geocode addresses and test them against the covered area; maintain a zone and route catalogue with the municipality; export orders cleanly from ERP or WMS via API (PREP-005); check the legal basis for using customer contact and location data (PREP-025); and define what camera footage is kept or deleted (PREP-022). Developers additionally need labeled sidewalk scenes and a test set (PREP-018). Tools: Excel or a database for address cleanup, QGIS, OpenStreetMap, the operator's portal. Effort is moderate, roughly 20 to 30 percent of a pilot (GUIDE-003).

Implementation paths

Which path for whom

• Enterprise: A, because retailers and logistics firms can contract an established delivery-robot service and avoid running a fleet and permits themselves.
• Public: B, because municipalities and public bodies that run pilots should keep data and route rules under their control and combine a service with EU-hosted tooling, within procurement rules.
• Developer: C, because building or adapting robots needs open navigation and perception stacks (ROS 2, open detectors) and simulation.

Path A — Buy / contract a delivery-robot service (recommended)

• Operators offering robots-as-a-service or delivery partnerships: Starship Technologies (EU-rooted: founded by Skype co-founders, ops in Tallinn; fleets in Estonia, Finland, UK, plus US campuses), Cartken (US/Europe pilots, incl. Japan and Germany pilots), Serve Robotics and Coco (US-focused, expanding), Kiwibot (campus), Avride (Yandex spin-out, US/Korea/Japan focus). Sidewalk-robot activity in the EU also appears via local pilots with postal operators and retailers.
• Choose A when: you are a retailer, platform, campus or municipality and want delivery as a service. Hardware, autonomy stack, teleoperation, maintenance and permits are bundled.

Path B — Build on cloud APIs

• Not the core: vehicle control must run on-board. Cloud is used for dispatch, routing, customer app, ETA and fleet telemetry: map/routing APIs (HERE - EU; Google Maps; OpenStreetMap-based services such as GraphHopper, Valhalla), telemetry in EU-region cloud, VLMs for offline labelling and incident triage.
• Choose B when: you integrate third-party robots with your own shop/order stack.

Path C — Self-host (open source)

• Stack: ROS 2 with Nav2 for navigation, Autoware-style perception modules for reference, OpenCV, Ultralytics YOLO-class detectors (check licence), Open3D/PCL for point clouds, NVIDIA Isaac ROS on Jetson Orin, and Gazebo/Isaac Sim for simulation. Teleoperation via WebRTC (e.g. LiveKit, Janus).
• Hardware: on-board Jetson Orin NX/AGX-class (HW1); simulation/training on HW2-HW3 GPUs.
• Effort: a robot platform plus safety case is a multi-year engineering programme; realistic mainly for research groups, universities and robotics startups.

Path D — Custom training

• Operators train their own perception on millions of sidewalk frames plus synthetic data (see ROBO-010). Needs fleet-collected, labelled data across seasons, lighting and cities; edge-case mining from teleoperation events is the main data engine. Not sensible for a customer, only for platform builders.

State of the art (2026)

• Learned perception plus rule-based safety layers is standard; end-to-end driving policies from road autonomy (ROBO-005) are starting to influence sidewalk stacks, but certifiable safety still relies on conservative planners.
• Remote assistance ratios (robots per operator) are the key economic lever; vendors keep humans for hard crossings.
• Sim-to-real pipelines (Isaac Sim, Gazebo) and synthetic data reduce data collection cost for new cities.
• Failure modes: snow/leaves hiding kerbs, glare, crowds, narrow pavements, unusual obstacles (scooters, e-bikes parked on pavements), GNSS multipath in street canyons, vandalism, connectivity loss for teleoperation, and occasional blocking of wheelchair users or pedestrians. Behaviour in these cases decides public acceptance.

Shared resources & combinations

• Same capabilities (robotics-control, object-detection, simulation): ROBO-002 (AMRs), ROBO-005 (road autonomy), ROBO-008 (service robots), ROBO-010 (sim-to-real), ROBO-016 (AI safety functions, person detection).
• Edge hardware: Jetson-class modules are shared with ROBO-011/ROBO-015-type deployments.
• Fleet/ops: PRED-018 (ETA prediction), ROBO-006 (drones as alternative mode for rural drops).

Effort, cost & KPIs

• Path A: weeks to a few months for a pilot (permit, hub setup, app integration); pricing per delivery or per robot per month, typically negotiated.
• Path B: months for dispatch/app integration with a robot vendor API.
• Path C/D: years; multi-million investment in engineering, safety case, fleet operations.
• KPIs: completed deliveries per robot-day, on-time rate, remote interventions per 100 km, robots per operator, incident rate per km, customer rating, cost per delivery, share of orders accepted by robots, uptime in bad weather.

People & change

Involve management and the head of logistics or delivery, then legal/compliance for road and sidewalk permits and the municipality as a key partner. The DPO checks cameras and location data; end users are drivers, warehouse staff and customer service who handle exceptions and failed deliveries; customers and neighbours must be informed.

Works council: depends. The robots themselves do not monitor staff, but fleet software, dispatcher dashboards and remote-operator logs can be suited to monitor behaviour or performance, then §87(1) no. 6 BetrVG applies; if work processes of drivers or dispatchers change, §90(1) no. 3 requires early information (GUIDE-004). Public bodies involve the Personalrat. Robot cameras record passers-by: run a DPIA, sign an AVV with the operator, and define signage, blurring and short retention (GUIDE-005).

Support AI literacy (Art. 4 AI Act) for staff handling exceptions and for customer service (GUIDE-006). Typical concerns: job loss among couriers, blocked sidewalks, privacy of passers-by and vandalism. Address them with a small pilot area and time-limited trial, a public contact point, clear no-go zones, honest KPI reporting and a human who can intervene remotely or on site (GUIDE-008, GUIDE-009). Humans stay in control through remote operators and emergency stop.

Risks, regulation & compliance

• Road traffic law (national): no EU-wide regime. Operation relies on national or municipal permits, exemptions or pilot rules; status and speed limits differ by country (e.g. Estonia and the UK allow regulated operation; check each Member State and city before pilots). Liability allocation follows national traffic and product liability law.
• EU AI Act: classification depends. A standalone sidewalk robot is generally not a listed Annex III case; AI used as a safety component of machinery falls under Annex I via the Machinery Regulation (EU) 2023/1230 and may be high-risk once the applicable dates are reached (Machinery Regulation from 20 Jan 2027; AI Act high-risk dates subject to the digital-omnibus delay, check current status); vendors should check conformity assessment with a notified body [2][3]. Art. 5 prohibitions (e.g. emotion recognition in workplaces, untargeted facial-image scraping, real-time remote biometric identification for law enforcement) are not inherent to normal robots, but must not be added: face recognition of passers-by from robot cameras is prohibited or heavily restricted under Art. 5 and GDPR Art. 9. AI literacy (Art. 4) applies to operators and remote staff.
• GDPR: continuous camera capture in public space records passers-by, number plates and homes. Required: DPIA, legal basis (legitimate interest with balancing test), data minimisation (on-device blurring of faces and plates, short retention, no audio), clear signage and information notices, processor agreements, and access controls on teleoperation video. Delivery customers' addresses and order data are personal data [4].
• Other: Machinery Regulation, Radio Equipment Directive, battery regulation; cybersecurity (NIS2/CRA for connected products); insurance; accessibility (robots must not block wheelchair or blind users); noise and municipal acceptance.
• Mitigations: conservative speed limits, geofenced operation, remote kill-switch, incident reporting to authorities, public engagement, independent safety assessment.

Getting started

1. Define the catchment: orders under about 3 km, dense housing, a hub or store, and compact pavements.
2. Check the national and municipal permit regime and speak with the municipality early.
3. Run a 3-6 month pilot with a robot operator (Path A) on one hub; measure KPIs against courier delivery.
4. Carry out the DPIA, set retention for video, and publish a public notice for residents.
5. Decide go/no-go with intervention rate, incident rate and cost per delivery data.

Sources

1. Starship Technologies — company and delivery statistics — https://www.starship.xyz
2. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
3. Regulation (EU) 2023/1230 (Machinery Regulation) — https://eur-lex.europa.eu/eli/reg/2023/1230/oj
4. Regulation (EU) 2016/679 (GDPR) — https://eur-lex.europa.eu/eli/reg/2016/679/oj
5. ROS 2 Navigation (Nav2) documentation — https://docs.nav2.org
6. NVIDIA Isaac ROS — https://nvidia-isaac-ros.github.io
7. EDPB Guidelines 3/2019 on processing of personal data through video devices — https://www.edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-32019-processing-personal-data-through-video_en