AGV / AMR warehouse robots

What the navigation service includes

We set up navigation for the fleet of AGV and AMR warehouse robots the client already owns, and we don't supply the carts themselves. As input we take the warehouse layout, the chassis model, the sensors (lidars, cameras, encoders) and write the software part: the room map, the routes, the avoidance rules and the fleet-dispatch logic. The hauling of loads across the warehouse is done by the client's equipment, while our area of responsibility is the software that turns a set of carts into a managed system. Separately we set up the integration with the WMS and the upper level, so that movement requests come from the accounting system rather than being entered by hand. The service's result is a working navigation configuration and parameters verified on the client's equipment before handover to operation.

How navigation really works

The robot continuously solves three tasks: where it is, what the surroundings look like and which way to drive to the goal. Localization compares lidar and odometry data with a pre-built warehouse map, so the cart understands its position without floor markings and ceiling wires. The planner builds a global route to the destination, while a local loop recomputes the trajectory in real time, avoiding people, pallets and other machinery. The fleet dispatcher distributes tasks among the machines, separates them at intersections and doesn't let two carts occupy the same aisle. All this logic is executed by the onboard computer of the client's equipment, and we set it with parameters and code rather than by interfering with the mechanics.

The history of AGVs

The first automatically guided transporter was built in 1953 by Arthur "Mac" Barrett Jr., owner of the company Barrett Electronics of Northbrook, Illinois. It was a converted tow tractor that drove around a grocery warehouse following the signal of a wire strung under the ceiling; it began to be sold commercially in 1954 under the name Guide-O-Matic. Later the wire was moved into the floor, and for decades AGV navigation was built precisely on physical guides — wires, magnetic tape, optical lines. This gave precision but rigidly tied the route to the infrastructure: any change to the warehouse layout required re-laying the markings. Modern warehouse robots have moved away from wires to map-based navigation and machine vision, which is exactly what makes up the main part of our work.

Why the software part is critical

In wireless navigation the machine's behavior is determined entirely by software, so the cost of a setup error is high. If the map is built imprecisely or the localization parameters are tuned roughly, the cart drifts, confuses aisles and stops where the path is clear. Positioning accuracy directly affects safety: the robot shares the warehouse with people and machinery, and a discrepancy of even ten centimeters in a narrow aisle turns into a collision or a blockage. Fleet dispatch likewise rests on software logic — without it several machines create jams and deadlocks at intersections instead of boosting productivity. That's why we invest the main time not in the hardware but in calibration, the map and the motion rules, and we bring them to predictable behavior on the client's equipment.

Stack: ROS2, Nav2, SLAM

The base framework is ROS2, an industrial message-exchange environment between the robot's nodes, on which the sensor drivers, drive control and data exchange with the upper level rest. We build the navigation layer on Nav2 — the standard routing stack for ROS2, which uses behavior trees and a managed node lifecycle, giving controlled launch, stop and recovery of the machine. We cover building the warehouse map and the subsequent localization with SLAM methods: the robot simultaneously builds the room map and determines its position in it from lidar and odometry data. This combination isn't tied to a single chassis vendor, so it suits a heterogeneous fleet where the warehouse robots are assembled on machinery from different manufacturers. The whole stack is open, which removes license dependence and leaves the configuration under the client's control.

When ROS2, Nav2 and SLAM appeared

The term SLAM was introduced in 1995 by Hugh Durrant-Whyte and John Leonard, while the mathematical basis of the approach was laid back in 1986 in the work of Smith, Self and Cheeseman on the probabilistic description of spatial uncertainty. ROS itself originated as a project at Willow Garage: the first public repository appeared in November 2007, and version ROS 1.0 came out in 2010. ROS2 was designed already for industrial and distributed tasks, and its first distribution, Ardent Apalone, was released in December 2017. The Nav2 navigation stack for ROS2 was presented in 2020 in the paper "The Marathon 2" by Steve Macenski and colleagues, in which a robot drove a distance greater than a marathon across a dynamic campus. We use mature versions of these tools rather than raw builds, so that the machines' behavior is reproducible.

Why you can trust this to us

The combined experience of our development team in IT exceeds 45 years, and we run navigation as an engineering task rather than a set of ready-made presets. We don't trade in carts and aren't tied to a specific manufacturer, so we set up the equipment the client already has and pick the parameters to fit their layout and load flow. We run every configuration first in simulation, then on the real machinery in a controlled mode, and only after verification do we hand it over for the production launch. This order removes the risk of warehouse robots entering the shop floor with unpredictable behavior and halting the logistics. The client's equipment does the hauling and maneuvering, and we're responsible for the program, the map and the dispatch — and for them working as stated.