Where Lidar SLAM Loses a Changing Warehouse Aisle, and Why a VLA Policy Does Not Replace It

The aisle is not the map that was built last shift

A warehouse aisle is a poor match for the static-world assumption inside geometric SLAM. Pallets are staged and removed. People and forklifts cross the scan. Racks that were empty in the morning are full after lunch. A map that was correct at the start of the shift is then a picture of a scene that is gone. The robot can still be localized against leftover structure, or it can be localized against objects that have moved, which is worse. [1]

Cadena and colleagues, writing in 2016, put the failure in plain terms. Current SLAM methods are easy to break when the robot moves too fast or when the environment is strongly dynamic. In a dynamic scene the system has to detect changes, discard them, or track them. Mainstream systems try to throw the moving part away. Some research keeps dynamic objects inside the model. Neither choice is free. Discarding motion treats a forklift as an outlier and can also discard a pallet that is now a real obstacle. Tracking every change requires a map that is allowed to vary with time. [1]

Over longer periods the same paper says change is inevitable. Systems either keep several time-dependent maps of one place or keep one representation with a time parameter. Mainstream SLAM was built for a rigid, static world. Warehouses are non-rigid in practice because the goods move, even when each pallet is itself a rigid body. The survey also says that fusing semantic labels with metric measurements taken at different times is still an open problem. A label such as “aisle” or “pallet” does not, by itself, repair a metric map. [1]

Lidar measures ranges, not the meaning of a range

A spinning or solid-state lidar returns ranges. SLAM then estimates the sensor pose and a map together. If the only large surfaces are fixed racks, repeated scans overlap and the pose estimate can stay consistent. If a large fraction of the returns come from objects that will not be there on the next pass, the overlap is partly accidental. Loop closure can then lock the robot to the wrong place because two aisles of similar racks look alike. Cadena treats repeated structure and long-term change as robustness problems, not as details to be patched with a slogan. [1]

The same survey says SLAM often cannot meet a strict rate requirement, for example high-rate estimation for fast closed-loop control. That sentence matters in an aisle. A local planner that swerves around a person needs a fresh free-space estimate at the rate of the control loop that will act on it. A map update that arrives after the robot has already committed to a trajectory does not prevent the commitment. Semantic perception does not remove that timing requirement. It adds another stream that also has to be time-aligned with the metric one. [1]

This is not a claim that lidar SLAM never works in logistics. Fixed infrastructure, a slowly changing racking layout, and a policy that refuses to trust returns from known dynamic classes can be a sound design. The failure mode to design against is specific: the map is asked to stay true while the scene is being rearranged, and the only recovery is to keep driving on the old geometry. [1]

A VLA model outputs an action, and the published ones are slow

OpenVLA is a useful counterexample because the paper states what the model actually emits. Given an image and a language instruction, it predicts a 7-dimensional robot action. The reported embodiments are manipulation setups: a WidowX arm, a Franka arm on a table or on a movable desk, and the mobile manipulator used in the RT-1 and RT-2 evaluations. The paper does not report a warehouse-aisle trial in which this model replaces lidar localization. [2]

The rate is part of the result, not a footnote. Loaded in bfloat16, OpenVLA uses about 15 GB of GPU memory and runs at about 6 Hz on one NVIDIA RTX 4090, without compilation or speculative decoding. On an A5000, a 4-bit quantized copy ran at 3 Hz and an 8-bit copy at 1.2 Hz. Six hertz is one action about every 170 ms. A person walking across an aisle, or a pallet jack starting from rest, covers a meaningful distance in that interval. The model also does not publish a free-space polygon, a pose covariance, or a statement that the previous map is now invalid. [2]

A 7-dimensional manipulation action is the wrong object for the SLAM failure above. The failure is a bad estimate of where the robot is and of which surfaces still exist. An action token can steer a base only if some other module has already turned the camera image into a locally consistent motion command. OpenVLA does not document that module for a changing warehouse. Treating “vision-language-action” as a substitute for SLAM confuses a policy head with a state estimator. [2] [1]

The mechanism of a vision-language-action model is already covered. Read the existing VLA guideThis page does not repeat that mechanism. It asks whether the published rates and action vectors solve aisle mapping.

Onboard compute does not cancel the missing state

The trade that is real is between model size and the interval between actions. The OpenVLA measurements show that moving from a 4090 at about 6 Hz to a smaller GPU with quantization drops the rate to 3 Hz or 1.2 Hz. A warehouse vehicle that cannot carry a 4090 does not get the 6 Hz figure. Even the 6 Hz figure is an inference rate on a desktop-class GPU, not a closed-loop localization rate on a vehicle computer next to a safety PLC. [2]

Semantic navigation still needs a geometric channel when the cost of being wrong is a collision. Cadena’s open problem on semantic-metric fusion is exactly this seam. A language model can propose “go to the packing station.” The proposal is not a certificate that the path is free of a pallet that was not in the training set. If the geometric layer is removed in order to save a lidar, the system has thrown away the sensor that at least measures range, and it has not gained a published uncertainty on the remaining camera policy. [1] [2]

[1] [2]

Put the 6 Hz interval into meters before calling it navigation

Six hertz, the OpenVLA figure on one RTX 4090, is an action about every 170 ms. That interval is not yet a stopping distance. It becomes a distance only after you multiply by a speed you are willing to state. At 1 m/s, 170 ms is 0.17 m. At 2 m/s it is 0.34 m. Those products are arithmetic on the published rate. They are not a measured braking test, and they are not a claim that a warehouse vehicle runs OpenVLA. They show why a policy rate and a map rate cannot be compared as slogans. One is a time. The other has to survive contact with a moving object. [2]

Cadena’s remark about high-rate estimation sits on the other side of the same product. A geometric estimator that cannot keep up with fast closed-loop control fails even when the map is static, because the pose used by the controller is late. A semantic policy that runs at a few hertz fails the same timing test for a different reason: the output is an action, not a pose, and the action is stale by a large fraction of a second. Stacking a slow policy on a slow map does not average the delays. The controller sees whichever packet arrives last. [1] [2]

A fleet log that can actually decide the architecture records four clocks. Time since the last accepted lidar sweep. Time since the last accepted policy action, on the vehicle computer. Time since the aisle was last known to match the map, from a human restage or from a measured change detector. Time since the protective device last reported clear. If any of those clocks is missing, a dashboard that shows “autonomy on” is not evidence that the aisle and the map are the same object. [1] [2]

Glass, wet floors and mirror-like wrap are often blamed in product talks. This page does not assign them a failure percentage, because the Cadena survey does not measure those surfaces in a warehouse. What the survey does support is broader and enough to design against: a method built for a rigid static world will be asked to run in a place where the world is rearranged. The remedy is a map policy for change, a rate that matches the controller, and a safety sensor that is not the policy. It is not a newer name for the same stack. [1]

What to keep, and what evidence would change the split

Keep a geometric estimator where the racks are stable and the dynamic objects can be rejected without deleting true obstacles. Do not ask that estimator to remember a pallet location across a restaging. Keep a language-conditioned policy, if you use one, at the layer that chooses a goal or a manipulation action. Do not cite its manipulation success as evidence that the vehicle knows where it is. [1] [2]

• A trial in which the aisle is physically rearranged between mapping and the run, with the failure count stated separately from the static-aisle count.
• The computer that actually runs the policy on the vehicle, and the measured interval between actions on that computer, not only on a 4090.
• A free-space output with a stated uncertainty, time-aligned with the range sensor, rather than an action token alone.
• A protective detection function whose response time is in the stop calculation, independent of the policy.

[1] [2]