Autonomous mobile robot (AMR) fleets have become common in warehouse operations that require flexible, scalable material handling. Each robot generates a continuous stream of data from its drive system, safety sensors, battery management hardware, and the fleet management software that coordinates traffic and task allocation. This data is not merely a by-product of operation; it is a condition-monitoring signal that can reveal early wear, degraded component performance, misconfigured software, and developing safety hazards. When interpreted correctly, these signals allow maintenance teams to shift from reactive repairs to planned interventions. When misinterpreted, they lead to unnecessary downtime, overlooked degradation, and costly component replacements. This article explains the operating context of an AMR fleet, the meaning of common data signals, the interactions between subsystems, and the practical evidence needed to make defensible maintenance decisions. It is written as an independent industrial-education reference, not as an OEM service manual. Site procedures, lockout requirements, OEM documentation, and competent engineering judgment always take priority over general guidance.
The Operational Context of an AMR Fleet #
An AMR fleet does not operate as a collection of isolated vehicles. It operates as a shared resource pool within a dynamic environment. Robot availability is affected by shift patterns, order waves, battery charging schedules, warehouse layout changes, and the presence of manual operators, pallet jacks, or forklifts. A signal that appears abnormal in one context may be perfectly normal in another. For example, higher drive-motor current during a peak picking wave is expected, but the same current reading during a low-activity period may indicate a mechanical drag condition or a path obstruction.
Condition monitoring therefore begins with understanding the duty cycle of each robot. Robots assigned to long-distance transport between dock doors and storage zones experience more travel time and fewer charging cycles. Robots assigned to dense picking zones experience more stops, starts, and safety-related pauses. These duty-cycle differences produce distinct data patterns. Comparing one robot against a fleet-wide average is useful only if the comparison accounts for task profiles, assigned zones, and shift timing.
Another important contextual factor is the charging infrastructure. AMR fleets typically return to automatic charging stations during short gaps between tasks. Charging behavior is governed by the battery management system, the fleet scheduler, and the station hardware. Repeatedly shallow charges, long charge times, and frequent charge queuing are all observable signals that reflect not only battery health but also the efficiency of the scheduling algorithm and the condition of the charging contacts.
Data Signals That Describe Robot Health #
An AMR produces data at several levels. The low-level motor controllers report current, voltage, speed, and fault states. The navigation system reports pose estimates, localisation confidence, and path recovery events. The safety system reports scanner status, protective field violations, and emergency-stop states. The fleet manager records task completion times, waiting times, and resource conflicts. No single signal tells the whole story, but together they form a coherent picture of the robot’s condition and its interaction with the environment.
Traction and Drive Signals #
The traction drive is the most mechanically stressed subsystem in a typical AMR. Motor current and encoder readings are the primary indicators of drive health. A gradual rise in average motor current for the same travel path can indicate wheel wear, bearing deterioration, floor surface changes, or increased loading from misaligned racks. Encoder data also reveals anomalies such as wheel slip, which manifests as a mismatch between commanded velocity and measured velocity, or as lateral deviation from a planned path.
Some AMRs use a differential drive, some use steering hubs, and others use mecanum wheels or omni-wheels. Each geometry produces different data features. For a mecanum wheel, roller wear changes the effective wheel diameter and creates subtle tracking errors that are visible in localisation confidence scores. For a differential drive, a degraded motor brake may cause the robot to drift when stopped, which is visible in pose drift data while the robot is stationary and holding position.
Battery and Charging Signals #
Battery data is often the most abundant source of condition information. Voltage, current, temperature, cell balance, state of charge, and charge throughput are commonly logged. The battery management system typically protects the pack by derating discharge current or by preventing further operation at low voltage. These protective events are valuable signals. They indicate not only that the battery is ageing but also that the robot is being asked to perform tasks that exceed available energy capacity.
Charging signals matter equally. Charge duration, end-of-charge current, contact voltage drop, and charge-station retry attempts all provide insights. An increase in charge duration for the same delivered energy points to a degraded charger, worn contact surfaces, or a battery pack with rising internal resistance. Intermittent charging failures, where the robot reports “station found but charge not established,” often relate to the alignment of the charging contacts or the cleanliness of the pads.
Safety and Perception Signals #
Modern AMRs are equipped with safety laser scanners, optional bumpers, and sometimes additional cameras or time-of-flight sensors. The safety scanner outputs an occupancy status that is used to slow or stop the robot. Repeated safety stops in a specific location are a strong environmental signal, indicating a blocked aisle, a protruding pallet, or a sensor that is being triggered by reflective or dirty surfaces. Scanner health messages, such as reduced warning zone distances or contamination warnings, are also condition signals; a dirty scanner window degrades detection range and increases spurious protective stops.
Perception data from navigation sensors, whether laser-based or vision-based, is recorded as localisation confidence and map-matching quality. A robot that frequently re-localises after passing through a particular doorway is demonstrating a real environmental issue, such as a changed feature, a mirror-like surface, or a dynamic obstruction. These events should not automatically be attributed to navigation software failure.
Component Interactions and Failure Propagation #
AMR subsystems interact strongly. A condition that originates in one component often produces symptoms elsewhere. Understanding these interactions is necessary to avoid misdirected repairs.
Consider a set of worn drive-wheel tires. The reduced traction increases slip, particularly during acceleration and deceleration. The motor controller responds by drawing higher current to maintain speed. Higher current increases battery discharge rate and heat dissipation. The battery management system may detect elevated temperature and derate maximum current. The robot then appears slower and less efficient. If maintenance staff interpret the data solely at the battery level, they might replace the battery when the real cause is wheel wear on the drive unit.
A second example is localisation instability in a specific aisle. The navigation system responds by slowing the robot or making path-adjustment maneuvers. The robot spends more time in the aisle, causing traffic conflicts. The fleet manager sees increased congestion, operators see delayed deliveries, and the on-board data shows a high number of recovery events. The root cause may be a dirty scanner window, a displaced shelf that blocks a reflective target, or even a strip of over-polished floor that changes the laser return. Replacing the navigation computer would not resolve any of these.
Charging behaviour is similarly connected. A robot that generates more safety stops than its peers spends more time in the operating zone and less time charging. Its state of charge may drift lower over the shift. If the fleet scheduler decides that the robot has insufficient charge to complete the next task, it will send the robot to a charging station early, reducing its productive time. The symptom is “the robot charges too often,” but the cause is excessive energy consumption caused by stop-and-go driving, not necessarily battery degradation.
Observable Symptoms and a Structured Diagnostic View #
The table below summarises common observable symptoms, the data signatures that accompany them, likely contributing factors, and the evidence that should be collected during a structured assessment. The purpose of this table is to support dialogue between operators, maintenance engineers, and controls teams, not to make a diagnosis without site-specific verification.
| Observed Symptom | Data Signature | Likely Contributing Factors | Evidence to Collect |
|---|---|---|---|
| Robot travels noticeably slower on a specific loop | Increased motor current, lower average speed, repeated localisation recovery events | Wheel wear, floor surface issue, scanner contamination, suboptimal path assignment | Signed and time-stamped data logs from the loop, camera footage of the robot path, floor inspection report |
| Battery drains faster than usual on standard shifts | Higher average discharge current, voltage sag under load, shorter time between charge events | Battery ageing, increased drive friction, more safety stops, scheduling changes | Shift-level battery curves, task list with total distances, charge event timestamps, ambient temperature log |
| Charging takes longer or fails intermittently | Long charge duration, repeated connection attempts, high contact resistance, slow end-of-charge taper | Worn charge contacts, debris or oxidation on pads, misaligned dock position, degraded battery pack | Charge start/stop logs, robot pose at charge station, contact surface inspection photos, temperature of contacts |
| Spurious safety stops in the same zone | Safety scanner occupancy flags, protective stop events, recovery after human intervention | Environmental obstruction, reflective surfaces, scanner window dirt, misconfigured warning zones | Safety event log with zone coordinates, site condition photos, scanner contamination status, recent zone configuration changes |
| Fleet congestion at a transfer point | Increased waiting times, blocked resources, resend of tasks, lower utilisation of downstream areas | Suboptimal traffic rules, one robot with degraded accuracy, overhead obstacle, layout changes | Fleet manager traffic report, individual robot cycle times, map history, zone occupancy data |
The table illustrates that no column can be interpreted in isolation. The same data signature can have multiple possible causes. The evidence collection step is therefore essential, not optional.
Evidence Collection: Logging, Correlating, and Storing Data #
Condition monitoring relies on consistent evidence. The first principle is that data must be time-synchronised across all sources. The robot clock, the fleet manager clock, and the site monitoring systems should use a common time reference. If clocks drift, correlating a safety-stop event with a drive-current spike becomes guesswork.
The second principle is to collect evidence at the right granularity. High-frequency drive data, sampled at tens or hundreds of hertz, is valuable for diagnosing mechanical issues such as wheel imbalance or bearing noise. For long-term trend analysis, hourly aggregates of average motor current, average speed, and charge throughput are usually sufficient. Event-based logging should be configured for specific triggers: task start, task completion, safety stop, charge start, charge end, fault code, and re-localisation. These event logs provide the context that raw trend data lacks.
Operators and maintenance staff should be encouraged to add free-text notes to robot events. A note such as “robot paused near rack row C, possible pallet protrusion” is enormously valuable when correlated with a later peak in safety stops in the same zone. Without human context, a pattern of 15 safety stops may appear to be a robot sensor problem when it is actually a recurring environmental obstruction.
Data storage is a practical consideration. Logs should be retained for at least several weeks to support trend comparison and return-of-investment analysis. Raw high-frequency data can be compressed into daily summary files, but event logs and fault code listings should be kept in a searchable form. Many fleet management platforms already provide some of this logging; the gap is often in adding the cross-system correlation that turns raw logs into diagnosis.
Common Interpretation Errors #
Even with good evidence, interpretation errors are common. Recognising these errors improves diagnostic discipline.
Treating correlation as causation. If a battery alarm occurs after a drive motor fault, it is easy to assume that the motor fault caused the battery alarm. In reality, both may have been caused by a third factor, such as a heavy load on an incline, or by two independent and unrelated issues occurring in the same shift. Establish the causal chain using time-synchronised data and physical reasoning.
Using fleet averages without duty-cycle stratification. If Robot A has 15 percent higher motor current than the fleet average, but Robot A is assigned almost exclusively to ramp ramps and dock approaches, the reading may be normal. Compare robots only within similar task groups, or normalise by distance, load weight, and incline.
Ignoring environmental change. A change in data patterns may reflect a change in the warehouse, not in the robot. A new row of metal racking, a different floor coating, or a window that allows morning sunlight into a scanner field can all produce meaningful data changes. Always ask what has physically changed before replacing a component.
Assuming a fault code equals a failure. Fault codes are designed for fast communication between subsystems. A steep motor temperature fault may be a response to a hot aisle or an overloaded task, not a motor failure. Read the fault code together with the context values that preceded it—temperature, current, speed, and time in operation.
Over-reacting to noise. Drive current and localisation confidence are naturally variable signals. A short-lived spike that resolves itself may be an ordinary response to a floor seam or a brief traffic event. The consistent trend, not the occasional spike, is the more reliable indicator of degradation.
Maintenance Implications and Decision Boundaries #
Condition monitoring does not eliminate maintenance decisions; it makes them more informed and more timely. Maintenance teams should define clear decision boundaries based on trend data. For example, if average drive motor current increases by 10 percent above its baseline for the same duty cycle over a period of four weeks, the robot should be scheduled for inspection during the next available maintenance window. If the same parameter increases by 25 percent, the robot should be quarantined from mission-critical tasks until the cause is understood.
Similarly, battery capacity fade is expected over time. The decision boundary is not “does the battery still operate?” but “does the battery support the required duty cycle with sufficient reserve margin?” A battery that can complete a normal shift with 15 percent reserve may be acceptable. One that completes a normal shift with 2 percent reserve is near its operational boundary, even if no fault code is present. Replacing it at the boundary is a planned cost, not a breakdown response.
Wear-related thresholds also deserve attention. Charging contact resistance should be trended. If it is rising, a simple cleaning or resurfacing can restore performance. If it rises to a value that triggers intermittent charging failures, the robot will produce a cascade of scheduling delays and operator frustration. Cleaning and contact inspection are low-cost interventions that can be planned during shift changes without causing downtime.
Decision boundaries must also respect the limits of in-house capability. If the evidence suggests a sensor misalignment or a map calibration problem, site engineers may be fully capable of remediation. If the evidence suggests internal component wear inside the drive gearbox or a battery cell imbalance, the appropriate decision is to contact the OEM or a qualified specialist. Attempting to repair components outside the site’s training and tooling capability can create safety risk and invalidate warranty protection. The decision boundary is therefore not only a technical threshold but also a competence threshold.
Safety Interfaces, Recovery Data, and Non-Negotiable Boundaries #
Safety scanner, emergency-stop, and protective-stop data are condition-monitoring inputs, but they are also part of the machine’s safety system. Their primary purpose is to protect people and equipment, not to generate maintenance data. The integrity of these interfaces must never be compromised by software overrides, threshold relaxation, or physical disconnection.
Occasional safety stops are a normal and intended function of an AMR when a person or an obstacle enters its protective field. However, a high frequency of safety stops at a specific location is a signal that the operational environment is not suitable for the robot’s task. The correct response is to investigate the location, adjust the physical layout, improve operator awareness, or alter the robot’s traffic flow. The incorrect response is to reduce the sensitivity of the scanner or to define a narrower protective field so that the robot can continue moving.
Recovery events after safety stops also generate data. A robot that requires operator acknowledgment to resume travel should be logged with the reason for the stop, the time lost, and the action taken. Repeated recoveries may point to a robot that cannot reliably navigate a particular zone, or to operators who frequently walk through the area. Both are addressable through legitimate measures such as marked walkways, barrier placement, or changed task routing.
Strictly, this article does not provide instructions for bypassing, disabling, or adjusting safety devices. Site procedures
