How Delivery Robots Navigate: Sensors, Maps, Remote Help and AGV vs AMR

The short answer

A delivery robot works out where it is from its sensors and a map, plans a route to the destination, and follows that route while watching for people, vehicles and obstacles and slowing or stopping when needed. When it reaches the customer, it checks that it is in the right place and unlocks its compartment for the right person. [1] [2]

The two companies whose documents are used here do not leave their robots entirely alone. Starship states that every robot has human back-up, and Serve Robotics describes remote supervisors who monitor its fleet over video and help at places such as intersection crossings. Autonomy and remote help work together, and a fair description says which one handled each part of the trip. [3] [2]

A simple picture: a careful walker with a map and a phone

Imagine walking to a friend’s house in a town you have visited before. You remember the streets, glance at landmarks to check where you are, walk around people on the pavement, wait at crossings and, if you get stuck, phone someone for advice.

A delivery robot does the same jobs with sensors and software. Its map is a stored model of the area. Its landmarks are features its cameras and range sensors recognize. Its phone call is a request to a remote assistant.

The comparison has limits. A person understands why a crowd is gathering or what a police officer’s hand signal means. A robot only has the categories and rules its software was given, and it can misread unusual situations that a person would understand at a glance.

What a delivery robot senses

Starship’s plan for a university deployment lists 12 cameras, 4 radars, 8 ultrasonic obstacle detectors, 2 inertial measurement units and 1 GPS receiver, giving 360-degree coverage. Serve’s annual report describes active sensors such as LiDAR and ultrasonics, and passive sensors such as cameras. Different companies make different choices, and these lists describe those two companies’ robots. [3] [2]

[3] [2] [1] [4]

How cameras and LiDAR turn measurements into positions is explained in how robots see the world.

Knowing where it is

Localization means estimating the robot’s position and heading on its map. Navigation software commonly keeps three coordinate frames: map, a fixed frame for the whole area; odom, a smooth frame built from wheel and motion sensors that drifts slowly; and base_link, attached to the robot. A localization method corrects the map-to-odom relationship, while odometry provides odom-to-base_link. [1]

Odometry usually fuses wheel encoders with an IMU using a Kalman filter, a method that combines several noisy measurements according to how much each one can be trusted. The Nav2 guide describes a typical robot with at least wheel encoders and an IMU as odometry sources, fused by the robot_localization package. [5]

Odometry alone drifts, so the robot also matches what it sees against its map. AMCL, a method used in Nav2, keeps many guesses of the robot’s pose, called particles, and keeps the ones that best explain its sensor readings. Outdoors, GPS can help but is not precise enough on its own to keep a robot on a pavement next to a road. [1]

What happens when the world no longer matches the map is examined in where lidar SLAM loses a changing warehouse aisle.

Planning the route and avoiding obstacles

Navigation is split into two problems. A global planner finds a route from the current position to the goal on the map. A local controller follows that route while reacting to what the sensors see right now, producing speed and steering commands. Nav2 calls these the planner server and the controller server. [1]

Both use a costmap, a grid in which each cell is marked free, occupied, inflated or unknown. Inflation adds a safety margin around obstacles so the robot does not plan to brush past them. When the robot gets stuck, recovery behaviours such as clearing stale obstacles or backing up take over, and in Nav2 a behaviour tree decides which step runs next. [1]

Pedestrians, stopping and crossings

Avoiding a person has two parts: noticing them early enough, and being able to stop or steer in time. The distance a robot needs to stop is roughly the distance it travels while it reacts, plus its braking distance: d ≈ v × t + v² ÷ (2a), where v is speed, t the time to detect and react, and a the deceleration.

Speed matters twice: it lengthens both terms, and the braking term grows with its square. This is why mobile robots slow down in crowds, near doors and at blind corners, where a person can appear with little warning. [6]

Crossings are treated as special cases. Starship’s plan says its robots operate in pedestrian areas, use roads and cycle lanes only to cross, use only streets and crossings the company has chosen, and wait for the pedestrian signal. Serve says its supervisors assist at intersection crossings. [3] [2]

Why predicting a person’s path is harder than it looks is explained in what a biped still cannot promise when a person changes direction.

Autonomy and remote help

Serve describes Level 4 robots that “can operate without humans in the loop for periods of time”, and says the design lets a single remote supervisor oversee several deliveries at once. Starship says a robot that meets a problem it cannot handle alerts a remote assistant, a local assistant attends serious situations, and both can disable the robot. [2] [3]

[2] [3]

Neither document, in the parts read for this article, gives an intervention rate. When reading claims about an autonomous delivery fleet, the useful number is how often a person had to help per kilometre or per delivery, and in which situations. [2] [3]

The same distinctions for humanoid robots are set out in are humanoid robots autonomous?.

Compartments, handover and batteries

The order rides in a locked compartment. Serve says its compartment can be unlocked only through the delivery app or with a code entered on the robot’s screen. Starship lists a 400 × 340 × 305 mm cargo space and a 10 kg maximum load for the robot described in its plan. [2] [3]

Batteries set the working day. Serve states a range of up to 48 miles, about 77 km, on one charge, with robots returning to a depot to recharge at night. Range figures like this depend on speed, temperature, slopes and load, and the filing does not give the test conditions. [2]

Worked example: from a restaurant to a customer

[1] [2] [3]

Indoors, outdoors and operating limits

Indoor and outdoor delivery are different problems. Indoors there is no GPS, but floors are flat, lighting is controlled and the map changes slowly, apart from people, doors and lifts. Outdoors, robots face weather, curbs, slopes, uneven paving, crowded walkways and traffic. Serve says improved water resistance has widened the weather conditions its robots can handle, which also tells you that weather is a real limit. [2]

Rules differ by place. Serve reports that over 25 US states and a number of cities have legal frameworks for sidewalk delivery robots. A robot that operates in one city is not automatically allowed, or able, to operate in another. Claims that a robot can travel any public sidewalk or road should be checked against where it has actually been demonstrated and permitted. [2]

AGV versus AMR

In factories and warehouses, two terms are common. An automated guided vehicle, or AGV, follows a defined guide path, physical or virtual, such as a wire, magnetic tape or a programmed route, and stops until an obstacle in its path is removed. An autonomous mobile robot, or AMR, uses its own sensing and planning to choose and adjust its route within its operating area and can drive around obstacles. [7]

[7]

The line between them is not always sharp. Some vehicles follow virtual paths but can shift sideways around a small obstacle, and manufacturers use the terms differently. According to The Robot Report’s account, R15.08 classifies vehicles by how they plan their path, not by size, payload or localization method. Ask how a specific vehicle chooses its route and what it does when the route is blocked. [7]

Safety risks and how they are tested

[3] [2] [6]

Serve’s risk summary names safety incidents arising from human supervision, connectivity issues, third-party software or automation. That list is a useful reminder that a delivery robot is a system of robot, network, software and people, and any one of them can fail. [2]