Why AI service robots lose their route at a real site
AI service robots confidently complete a demonstration route and fall apart at the first real site. The reason is not the drives, but the localization loop: it relies on assumptions that cease to hold in a crowded hall.
Glass display cases and mirror panels return false reflections, the robot "sees" a passage that does not exist, and its position estimate diverges from reality. Loss of localization here is not an accident, but a normal consequence of the room's geometry.
The second most frequent cause of stops is false obstacles. People, carts, and abandoned pallets enter the field of view as static objects; the robot cannot distinguish a temporary occlusion from a real wall and either freezes or begins a detour into the oncoming lane.
At peak hours, this turns into a queue around a stationary machine and manual accompaniment by an operator.
The third failure is position drift in narrow passages and on ramps. Wheel odometry accumulates error: on a slope the wheel slips, on a turn in a tight passage the machine skids, and by the end of the shift the return point to the charging station shifts.
The robot formally "knows" the route, but arrives at the wrong place or stops in a doorway.
All three failures look like different breakdowns, but are treated by one thing — rebuilding navigation for the real geometry of the site: stable anchoring to the map, separation of dynamic and static objects, control of error accumulation, and explicit dead-end recovery scenarios. Below we analyze how this is addressed.
Effect of autonomous control: cycle, failures, downtime
Autonomous control changes not peak metrics, but variance. On a repeating route — bypassing racks, feeding a workpiece, delivery — cycle time stops "floating": instead of a 30-40% spread from the average, 8-12% remains.
The reason is that the speed profile and braking points are set by the planner, not by an operator with a joystick.
The second effect is operator interventions. We count them not "by eye", but by telemetry: how many times protection tripped, how many times the robot was pulled out of a dead end, how many tasks were closed manually.
On a stable section, the share of tasks without intervention grows from 70-80% to 96-98%, and an entire class of navigation failures disappears — loss of localization, entering a dead end, hitting an obstacle.
We separate failures by class, because their impact is different. Navigation ones are resolved on their own: re-localization by map, detour, repeated passage of a point — recovery time is measured in seconds.
Hardware and integration ones require an engineer visit, and their share is visible separately. It is by this breakdown that it is clear what the new loop gave and what remained stuck on hardware or an adjacent system.
We measure before and after on the same route: first the initial shift logs, then the same shift with the new control configuration.
The loop is built on ROS 2 — an open branch, so telemetry on cycle time, failures, and downtime is captured with standard tools, without manual timekeeping.
Navigation and control modes: comparison of options
The navigation mode is chosen not by sophistication, but by the environment: how much dynamics it has, how often equipment is rearranged, how stable lighting and floor covering are.
Below are four schemes that are actually chosen between at the design stage, and their mode limitations.
| Navigation mode | When suitable | Mode limitations |
|---|---|---|
| Route marking | Fixed passages, stable layout, flow of similar tasks | Rearrangement requires remarking; on carpets, tile joints, and wet floors it is read unstably |
| Room map | Free layout: offices, halls, exhibition spaces | Fails near glass partitions, mirrors, and in dense crowds; the map is rebuilt after rearrangements |
| Hybrid scheme | Mixed environment: long corridors plus open areas, seasonal rearrangements | More difficult to configure — two landmark loops need to be kept up to date |
| Manual accompaniment | Complex zones, non-standard cargo, debugging a new route | Depends on the operator, does not scale to flow, does not provide repeatability |
In practice, the hybrid scheme more often wins: the room map provides free movement, reference markers provide repeatability in critical sections.
If landmarks are lost, the robot does not "go blind", but enters a safe mode and stops — loss of navigation becomes a manageable event, not an accident.
Implementation stages: from environment audit to handover to operation
The order of stages is not rearranged: navigation and control rely on the actual geometry of the site, and an error made during measurements surfaces only during the pilot run — when the hardware is already installed and the scenarios are agreed. Therefore each step is closed with a measurable result that becomes the input for the next.
- Environment audit. We walk the site along actual routes: passage width and turning radii, slopes and floor joints, line-of-sight zones and blind areas, dynamic obstacles — carts, visitors, pallets. We record points where the robot will have to yield, wait, or change route.
- Route scheme. We build a map anchored to permanent landmarks, mark work points, waiting zones, and virtual boundaries where entry is prohibited. For each scenario, we define priorities and passing rules when flows cross.
- Motion setup. We select speed and acceleration profiles for the surface and cargo, behavior in narrow places, reaction to a person suddenly stepping out, and recovery logic after loss of localization — the robot must return to the route without calling an engineer.
- Integration with the customer's infrastructure. We connect what the scenario needs: elevator call, automatic doors, status transfer to the accounting system, task exchange with a dispatcher or warehouse loop.
- Pilot run on real scenarios. We run the full cycle during a working shift, not on an empty site. We look at the share of tasks completed without operator intervention, the number of manual takeovers, and the deviation of cycle time from the calculated one.
- Personnel training. We hand over regulations to operators: how to set a task, what to do when stopped, how to remove the robot from the route and return it to work, where to view the event log.
- Handover to operation. We provide the map, loop configurations, update rules, and the procedure for rolling back to the previous working version — so changes can be made without stopping the site.
Documentation package: environment maps, configurations, regulations
We hand over not just working equipment, but a system that the customer can operate and develop on their own. Documents are assembled during the project and at acceptance are checked against the actual state: a map outdated by one passage means the robot stops exactly there. The package is versioned, so during re-layout one section changes, not the entire documentation.
- Environment map — floor plan with passages, prohibited zones, charging points, and sections with changed flooring; routes are recalculated from it after any rearrangement.
- Route and stop point schemes — task anchoring to zones: where the robot waits, where it bypasses people, where it delivers cargo.
- Settings profiles — parameter sets for operating modes: day and night, peak hour, cleaning, delivery.
- Access policy — roles of operators and dispatchers, permission boundaries, procedure for issuing and revoking upon employee dismissal.
- Operator instructions — actions during a shift, reactions to typical situations, rules for manual intervention.
- Maintenance regulations — frequency of checks, sensor cleaning, calibration, replacement of consumables, and signs for removing the robot from the line.
- Escalation scheme and change log — who and within what time joins an emergency situation and why a particular decision was made.
The package is handed over in two forms: the operations service engineer edits the configuration, and the manager reads the regulations. Our engineers update the documents along with changes in the fleet — support does not end at acceptance.
Case study: robot fleet in a distribution center
What was before implementation
In the distribution center, the fleet of machines transported pallets along fixed routes, while operators brought carts with small orders.
Each flow crossing required manually launching a task: up to 30% of tasks went with human accompaniment, and a failure — loss of a marker or getting stuck at a floor joint — stopped the machine for an average of 40 minutes.
What was changed
We merged both flows into a single zone map and assigned priorities: pallets go along mainlines, carts along local loops, and the dispatcher Диспетчер потока rebuilds the route when they meet.
Engineers added cycle control: the machine itself detects displacement and goes to a backup point instead of stopping in the passage.
What became after
The share of tasks with manual accompaniment dropped to 4%, recovery time from a failure decreased from 40 minutes to 4.
On a mixed flow of pallets and carts, 97% of cycles fit within the calculated takt, and fleet downtime decreased threefold: one stop no longer blocks the area entirely.
The margin was checked separately: four machines and a new shipping zone were added without rebuilding the map — the rules were picked up automatically.
This is the main result of the implementation case: the fleet grows, and the share of manual operations and downtime do not return to previous values.
How does navigation by marking differ from navigation by map?
The difference is in the source of truth. The map gives the robot a metric model of the room: it matches rangefinder readings with the scheme, estimates position globally, and drives to any free point.
Marking works locally — lines, magnetic tape, or visual markers such as AprilTag define a corridor, and position is calculated from the nearest landmark.
Route stability depends on the type of changes. Rearranging a rack interrupts a marked passage: the landmark has disappeared, and installation of a new section is needed. The map survives such a rearrangement after re-walking the zone.
However, on a shiny floor and in a dense flow of people, global localization degrades — marking keeps the corridor predictably.
| Option | When suitable | Limitations |
|---|---|---|
| Room map | Frequent layout changes, wide passages, many free trajectories | Requires even flooring and an up-to-date map; localization drifts on glass and in crowds |
| Marking | Stable routes, high repeatability, simple corridors | Installation and maintenance of the floor covering, area downtime during layout changes |
| Hybrid | Mixed rooms: open hall plus narrow passages | More difficult setup, switching logic between modes is needed |
Changing the layout has different implications. Remarking means stopping the area, work on the floor covering, and re-validating the route; the map only needs to be re-walked and dangerous zones checked.
That is why in mixed rooms a hybrid is chosen: the map as a basis, markers as anchors in elevators, narrow passages, and at the charging station — if one modality is lost, the robot does not stop.
In practice, the choice is made by two metrics: the share of successful passages on the actual flooring and the time to restore the route after rearrangement. Marking wins where repeatability is needed, the map — where the layout lives its own life.
Failures, integration, and access: technical questions from customers
Doubts about the project almost never concern the robot itself — they concern how it will behave in an already operating service.
Below are four questions that most often come up before launch: equipment rearrangement, integration with the accounting system, operator rights, and recovery from failure.
What happens if the layout is changed or racks are rearranged?
The room map is not redrawn — it is updated based on new landmarks, and approach zones and waiting points are re-marked. If there is a discrepancy with the map, the robot does not continue moving from memory, but stops at a safe point and sends a signal to the operator. Updating takes one pass along the route, after which tasks return to normal mode.
How is the robot connected to the accounting system?
Exchange goes through the standard exchange interface: tasks come from the system, execution statuses go back. If the system is unavailable, requests are not lost — they accumulate in a local queue onboard and are processed after communication is restored. Manual transfer of tasks and double entry disappear completely.
How to differentiate employee access?
Roles are configured by shifts and zones: the dispatcher sees only their areas and sets tasks, the setup technician changes route parameters, the observer views statuses without the right to intervene.
Every action goes into the log with the author indicated — disputed situations of "who reconfigured the route" are closed by a record, not a conversation.
Can the robot be recovered from a failure without an engineer visit?
Most stops are resolved remotely: the log shows at which step the robot stopped, repeating the operation or resetting the task returns it to service.
In case of a hardware cause, the system itself puts the robot into safe mode and calls a specialist — but the share of such cases is an order of magnitude lower than it seems before launch.
Let's discuss the task: we'll select a mode and come back with a plan
Project evaluation begins not with choosing a robot model, but with the environment in which it will operate. Layout, usage scenarios, and room constraints determine both navigation and control logic, as well as the scope of integration.
Therefore, we conduct the first review from the task, not from the catalog — this way the implementation plan relies on real conditions.
To come back with an assessment and plan, it is enough to send:
- Layout or zone scheme: routes, narrow passages, parking places, charging points.
- Usage scenarios: what the robot does during a shift and how many operations occur at peak load.
- Environment constraints: flooring and height differences, thresholds, glass partitions, lighting, flow of people and carts.
- Integration requirements: which systems to connect with and what data must go both ways.
- Autonomy mode: shift duration, presence of an operator nearby, behavior when communication is lost.
- Navigation materials: an up-to-date room map or its absence — this is also an input.
- Regulations: access control, security service requirements, noise restrictions.
Next we break down scenarios into feasible and disputable: where the route does not match the layout, where integration runs into a closed system on the customer's side, where a person is needed nearby at the first stage.
Based on the results, we send an implementation plan by stages, with checkpoints and a list of risks. Describe the task — we will come back with an assessment and a plan.
