# Automated Guided Vehicles: Degraded-Mode Operations and Recovery Boundaries - Canonical: https://pearlgateway.net/docs/automated-guided-vehicles-degraded-mode-operations-and-recovery-boundaries/ - Updated: 2026-09-17T08:21:00+00:00 Automated guided vehicles (AGVs) do not fail the way most mechanical equipment fails. A conveyor stops hard and announces its fault with certainty. An AGV more often slides into a degraded state: it still moves, still accepts missions, still executes its program, but with a measurable loss of accuracy, speed, or confidence. This in-between condition is what makes recovery difficult. Unless the warehouse defines clear degraded-mode thresholds and recovery boundaries, a vehicle that should be pulled from service can keep running into the problem, wearing its own components and contaminating the evidence that would have explained the fault. This article explains how degraded-mode operations arise, how they interact across AGV subsystems, how to collect and interpret evidence, and where the boundary between continued operation and mandatory recovery should sit. ## Defining Degraded-Mode States and Recovery Boundaries Degraded mode is not a fault code. It is a state of reduced functional integrity. A fully functional AGV can maintain its programmed speed, its localization accuracy, its safety-rated protective fields, and its communication with the fleet manager. A degraded AGV may still complete missions but with a lower speed cap, wider positioning tolerance, higher battery draw, or recurring replanning events. A recovery boundary is the documented point at which the vehicle must transition out of autonomous operation and into a controlled intervention. That boundary is normally defined by a threshold value: a localization residual, a safety scanner flash count, a battery health parameter, or a mechanical observation. Three states matter in practice. Nominal operation means the vehicle is within all thresholds. Degraded operation means the vehicle is functional but outside some performance envelope. Recovery means the vehicle is removed from traffic, isolated, and processed according to site procedures. The common error is to treat a degraded vehicle as a working vehicle until a hard fault appears. That error converts a recoverable condition into a compound failure involving worn drivetrains, misaligned optics, and depleted batteries. ## The Operating Context: Interfaces That Matter An AGV is a mobile assembly of interacting subsystems, and degraded modes usually originate in one subsystem while announcing themselves through another. The most relevant interfaces are the localization chain, the safety perception system, the drive and steering units, the power system, and the fleet traffic manager. None of these operate independently. Consider a common scenario. Localization relies on a laser scanner reading reflections from reflectors or natural features. A thin film of dust on the scanner window attenuates the returning signal. The vehicle does not report a scanner fault; instead, it reports slower response times, occasional positioning jumps, and a reduced speed cap in certain aisles. An operator looking only at the drive system sees a slow vehicle. An operator looking at the localization confidence values sees a sensor confidence problem. The truck itself is still safe, but its recovery boundary has shifted because the environment around the sensor has changed. This interaction pattern recurs across the vehicle. Deviations in wheel speed create odometry drift. Odometry drift increases dependence on absolute positioning references. If the environment near those references changes, the vehicle replans its path repeatedly during a single mission. The traffic manager then logs more motion-blocking events, and the system appears to have a congestion problem when it actually has a wheel-slip problem. Effective degraded-mode diagnosis always looks across interfaces rather than at a single component. ## Symptom Patterns: How Degraded Running Announces Itself Recognizing degraded mode requires a list of early indicators. Operators and maintenance technicians should watch for the following - Repeated slow-down events at the same map location rather than at random points. - Path replanning that occurs more than twice during an otherwise simple mission. - Position drift visible in the fleet management display between the vehicle icon and the known aisle geometry. - Speed setpoints that are consistently below the programmed maximum, without an explicit traffic block. - Charging cycles starting earlier in the shift than historical averages. - Safety scanner warning events that increase in frequency but never escalate to a protective stop. - Audible drive hesitation, such as repeated micro-corrections of steering angle during straight travel. Symptom patterns matter more than individual events. A single replan can be caused by a pallet overhang. Ten replans in the same aisle, on the same shift, suggest a change in the environment or in localizer quality. The symptom pattern should be written into the daily shift handover in plain language, alongside the relevant vehicle number and the timestamp of the first observation. This gives the controls team a starting point rather than a vague report that a truck is “acting up.” ## Diagnostic and Decision Table The table below links a typical symptom pattern to a likely degraded mode, the evidence that should be collected before any intervention, and the recovery boundary decision that applies. It is a decision-support framework, not a substitute for OEM documentation or site-specific procedures. Observed symptom pattern | Likely degraded mode | Evidence to collect before intervention | Recovery boundary decision Position drift during straight travel; vehicle slowly veers toward one racking face. | Wheel encoder degradation or odometry calibration drift on the drive side. | Localization residuals during the drift window; tire and drive unit inspection notes; odometry vs absolute-fix comparison. | If localization residual exceeds the documented limit or the vehicle cannot hold its lane, stop autonomous travel and move to maintenance. Repeated path replans in a feature-poor zone; vehicle appears to “hunt” for its position. | Degraded localization quality caused by changed reflector positions, a modified racking layout, or a damaged map reference. | Localization confidence scores, map-change history, physical inspection of reflector mounts and sightlines. | If replan events exceed the site-defined threshold for three consecutive missions, remove the vehicle from service until the environment is corrected or the map is updated. Intermittent speed reductions near racking ends without any traffic block. | Safety scanner field intrusion from loose film, shrink wrap, or a displaced pallet edge in the protective field. | Scanner diagnostic counters, a camera image of the zone, and a physical check for dangling material. | If a contaminant is found, remove it, confirm the scanner reports a clear field, and return the vehicle to service. If no contaminant is found, escalate to OEM support. Battery capacity drops noticeably across a two-week period and charging cycles become shorter. | Charge contact contamination or battery cell imbalance. | Per-vehicle energy consumption trend, charge/discharge voltage curves, contact resistance checks. | If the battery management system reports an imbalance outside its operating envelope, take the vehicle out of service and follow the battery maintenance procedure. This table is intentionally generic. The thresholds and decisions in your facility should come from the vehicle manufacturer, your risk assessment, and your own operational data. The table exists to structure thinking, not to dictate the outcome. ## Evidence Collection: What to Capture Before Acting The single most common recovery failure is the replacement of a part before evidence is gathered. A maintenance team that swaps a steering motor because the vehicle drifts will lose the week of data that would have shown a failing encoder on the opposite wheel. Evidence collection must happen before intervention, and it must be organized around a common timeline. The following items should be captured for every degraded-mode event - Fleet-level event logs covering the vehicle, the traffic manager, and the charging system, with timestamps from the same clock source. - Localization quality values or fix residuals sampled at the same rate the vehicle uses for control, not only the averaged values displayed on a dashboard. - Screenshots or exports from the fleet management screen showing the speed setpoint versus the achieved speed over the relevant time window. - Physical inspection records for the scanner windows, reflector surfaces, floor condition, and racking alignment at the symptom location. - The battery charge and discharge curve for the affected vehicle over at least the previous five shifts. - A narrative of what changed immediately before the first symptom, including racking moves, floor repairs, part changes, or software updates. Log time synchronization is a recurring source of confusion. The vehicle controller, the traffic manager, and the charging station may each use different time bases. If the controls team is analyzing an event across those logs, a few seconds of offset can make a scanner event appear unrelated to a drive event when they are actually the same incident. The evidence packet should note the clock offsets, or the logs should be corrected to a single time base before analysis begins. ## Interpretation Errors That Delay Recovery Interpretation errors are more costly than component failures because they consume repair cycles without moving the vehicle toward a clean state. The most frequent errors in degraded-mode analysis are described below. The first error is assigning the fault to the most visible subsystem. A vehicle that drives hesitantly is treated as a drive problem, while the underlying cause is a marginal localization fix that forces the controller to make constant corrections. The same applies to a vehicle that stops in an intersection and is immediately blamed on the traffic manager; the actual cause may be a degraded safety scanner that reports a dirty field. The second error is relying on the restart-and-observe cycle. Restarting the vehicle clears the immediate replan buffer and often resets the speed cap, but it does not correct the environmental or component condition that caused the degraded state. A vehicle that is restarted will re-enter the degraded mode on the next mission, and the pattern of restarting becomes part of the routine, hiding the trend. The third error is confusing a safety-rated stop with a degraded-mode event. When a person or object enters a protective field, the vehicle stops legitimately and the recovery procedure is different from a degraded-mode intervention. Treating a safety stop as a component failure leads to unnecessary maintenance. Treating a degraded sensor as a safety stop leads to bypassing important diagnostic steps. The two must be separated by examining the event source, not by the physical result of the vehicle being at rest. The fourth error is reading dashboard displays as diagnostic truth. A fleet management dashboard usually shows a simplified status icon and an alert message. The raw diagnostic variable, such as the actual localization residual at the moment of the event, is stored in the vehicle controller and is ## Related Pearl Gateway Guides - [End-of-Arm Tooling: Commissioning and Acceptance Checklist](/docs/end-of-arm-tooling-commissioning-and-acceptance-checklist/) - [Mixed-Fleet Orchestration: Commissioning and Acceptance Checklist](/docs/mixed-fleet-orchestration-commissioning-and-acceptance-checklist/) - [Mobile Robot Mission Recovery: Commissioning and Acceptance Checklist](/docs/mobile-robot-mission-recovery-commissioning-and-acceptance-checklist/) ## Site-Specific Review Worksheet This educational worksheet supports a structured review of automated guided vehicles: degraded-mode operations and recovery boundaries. Begin by identifying the equipment boundary, control ownership, operating modes, material characteristics, upstream dependencies and downstream consequences. Record what the system is expected to do, what was actually observed and which evidence is time-aligned. Avoid changing several variables at once, because simultaneous changes make cause and effect difficult to establish. ### Evidence to collect - Operating mode, active mission or route, and the exact sequence state. - Alarm history, device state changes and controller timestamps. - Physical observations such as alignment, contamination, wear, obstruction and load condition. - Recent maintenance, software changes, parameter changes and recurring work orders. - Upstream and downstream readiness, including blocked, starved and unavailable conditions. ### Decision boundaries Use approved site procedures and competent engineering judgment before intervention. General information in the Robotics, AMRs & Automated Handling library cannot determine whether a specific machine is safe to enter, restart or modify. Preserve original settings, document authorized adjustments and establish a rollback point before controlled testing. When evidence conflicts, stop and resolve the timestamp, naming or measurement discrepancy before drawing a conclusion. ### Closeout record A useful closeout record states the symptom, confirmed cause, evidence, corrective action, validation method, residual risk and follow-up owner. It should also identify whether the event exposed a design weakness, maintenance gap, training issue, spare-parts issue or monitoring blind spot. This turns a single recovery into reusable reliability knowledge without treating one observation as universal.