Automated guided vehicles are no longer isolated machines that follow a buried wire and stop when a photocell is broken. In a modern warehouse, an AGV is a mobile measurement system that carries payloads and people cannot hear internally. The same motors, encoders, scanners, batteries, and radios that move the machine also generate a continuous stream of data. That data is not just a record of what happened; it is the earliest available evidence of what is about to happen. Condition monitoring, therefore, is the discipline of converting raw signals into maintenance decisions. It requires some technical literacy, a disciplined approach to evidence, and a clear understanding of what an AGV’s control system can and cannot tell you. This article explains the signals that matter, how they interact, what common symptoms mean, and how to avoid the interpretation mistakes that cost warehouses hours of unnecessary downtime.
The Data Landscape: Onboard Signals and Infrastructure Telemetry #
An AGV produces two broad classes of data. The first is onboard data, generated by the vehicle’s own controller, safety systems, and peripheral devices. The second is infrastructure data, generated by the fleet controller, charging stations, network access points, and any manual control panels or gateways the vehicle communicates with.
Onboard data is typically available in several forms. Cyclic telemetry may include motor speed, motor current, battery voltage, laser scanner measurement quality, steering angle, and position coordinates at set intervals so you can replay the vehicle’s route second by second. Event data appears when a threshold is crossed, such as a low battery warning, a deviation in speed, or an emergency stop activation. Fault logs store the most severe occurrences and usually include a code, a timestamp, and some amount of context captured at the moment of failure.
Infrastructure data adds another layer. The fleet controller records which vehicle was sent where, how long it waited, and whether messages were acknowledged. A charging station records the start time, charge duration, current profile, and maybe the temperature of the charger’s own components. Network infrastructure records signal strength, latency, and reassociation events for vehicles using industrial Wi-Fi or 5G. These different sources are not independent. A motor fault that you see in the vehicle log may only make sense when you also know that the vehicle was climbing a ramp, operating at low battery state of charge, and struggling to maintain its slot in a busy traffic corridor.
Understanding the data landscape is less about having a single dashboard and more about appreciating that no measurement should be read in isolation. An AGV condition monitoring routine is a correlation exercise, not a meter reading exercise.
Core Signal Groups and Their Interaction #
AGV data signals can be organized into five groups: navigation and localization, drive and steering, safety sensing, battery and charging, and fleet communication. Each group has its own normal range, but the groups interact with one another heavily. A navigation problem can look like a drive problem, and a battery problem can look like a communication problem. Building a mental model of these interactions is the first step toward accurate diagnosis.
Navigation and Localization Signals #
For a laser-guided AGV, navigation relies on a rotating or scanning laser range finder, reflectors or natural features, and a position-matching algorithm. The key signals are scan quality, reflector identification, match quality, and position uncertainty. Match quality indicates how closely the observed environment matches the map or the expected reflector arrangement. Position uncertainty tells you how spread out the possible vehicle positions are after each correction. A healthy vehicle normally maintains a low, stable uncertainty value.
When dust accumulates on the scanner window, the signal-to-noise ratio drops. The vehicle may still find enough reflectors to navigate, but the match quality will decrease, and the vehicle may move with a slight zig-zag pattern that appears to be steering instability. Ignoring match quality data in favor of watching only the floor marker or the motor current is a common mistake.
Drive and Steering Signals #
Each drive motor and steering unit generates setpoints and actual values. The setpoint is the speed or angle the controller requests; the actual value is what the sensor reports. When the difference between setpoint and actual is larger than allowed, the controller typically raises a deviation fault. That is the most visible signal. But before the fault threshold is reached, the motor current often tells the real story.
You will see current spikes when a vehicle starts from standstill, when it climbs an incline, or when it decelerates in a curve. Those are normal. The problem arises when the average current creeps up over weeks without a corresponding change in payload. This is a classic sign of rolling resistance, mechanical binding, or brake drag. Similarly, a steady increase in steering current on one side of the vehicle can indicate worn kingpins or a bent steering linkage that will soon produce a wheel-off-sync fault.
Safety Sensor Signals #
Modern AGVs rely on safety laser scanners for people detection and obstacle detection. These scanners continuously perform internal self-tests and also report diagnostic data such as contamination on the field window, number of invalid measurements, and the quality of individual measurement points. A scanner that is gradually obscured by grease will often warn about contamination while still appearing to operate normally. The vehicle will not necessarily stop; it will simply have a reduced sensing field or a shortened maximum detection range.
Signal values from safety systems deserve special treatment. Unlike navigation data, safety data is tied to a compliance lifecycle. If the scanner is reporting borderline readings, do not attempt any kind of temporary masking or software workaround. Stop the vehicle, follow site lockout procedures, and consult the OEM documentation. Condition monitoring is intended to identify the need for service, not to justify extending the service interval past a safety boundary.
Battery and Charging Signals #
The battery management system provides voltage, current, state of charge, cell temperature, cycle count, and charge throughput. On a lead-acid or lithium-ion AGV battery, the most telling signal is not the state of charge at rest; it is the voltage behavior under load and the current behavior during charging. A battery that sags too low during a normal acceleration event is not just weak; it is drawing high current from the motors and forcing the vehicle’s auxiliary systems to operate in a degraded mode. This can trigger phantom motion errors because the motor controller loses its low-voltage margin.
Charging data reveals trends as well. Lithium-ion batteries normally charge at a high current, then taper as they approach full charge. If the taper happens too early, the vehicle may report 100% capacity but deliver fewer usable cycles. If charging current is unstable or the charger alternates between connection and disconnection, the charging contacts may be dirty or the vehicle may be sitting slightly out of alignment at the charging station. These are condition signals that can be collected without opening any enclosure.
Fleet Communication Signals #
AGVs do not think alone. They receive commands, share position, and request route clearances from a fleet manager. Communication quality data is sometimes overlooked because it does not appear in the motor or battery logs. Vehicles can record received signal strength, packet retry counts, and heartbeat acknowledgements. A high retry count preceded by a period of lost heartbeat is a strong indicator that the vehicle is entering a radio dead zone, not that the vehicle’s controller is faulty.
Communication issues are often intermittent and notoriously hard to reproduce. The best evidence is a time-synchronized sequence that includes a vehicle position, a network data point for the access point at that location, and a timestamped interruption in the vehicle’s command stream. Without all three signals, you might misdiagnose a network problem as a vehicle controller failure.
Observable Symptoms: From Raw Data to Condition Indicators #
Symptoms are the visible manifestation of a condition. The table below shows common symptoms, the signal group most likely to be involved, the likely condition, and the evidence that should be collected before acting. This table is a diagnostic starting point, not a step-by-step repair procedure.
| Signal Group | Observable Symptom | Likely Condition Indicator | Suggested Evidence to Collect |
|---|---|---|---|
| Navigation | Vehicle drifts sideways in a straight corridor; frequent re-localization stops | Degraded match quality, dirty scanner window, or shifted reflector positions | Match quality over time, vehicle x-y variance, environmental changes in the corridor |
| Drive | Intermittent “motor speed deviation” alarms with no audible difference | Brake drag, encoder contamination, or motor supply sag under load | Actual vs. setpoint speed traces, motor current peaks, battery voltage dip at alarm time |
| Steering | Vehicle weaves during horizontal travel; steering motor runs hot | Mounting compliance, worn bearing, or incorrect steering calibration | Steering angle tracking error, steering motor temperature, measurement of physical backlash during lockout |
| Safety scanner | False stops near a specific fixed structure but nowhere else | Reflective surface, scanner contamination on one field, or changed floor condition | Scanner diagnostic log, capture of the field image, physical inspection of the area with site lockout in place |
| Battery | Reduced runtime but no battery alarm | Capacity fade, early charge taper, or increasing internal resistance | Charge/discharge curves, cell temperature spread, vehicle-specific cycle count |
| Communication | AGV stops mid-transit with “controller handshake lost” error | Wi-Fi 5G signal loss, access point handover issues, or fleet manager overload | Radio retry counts, access point association history, fleet controller CPU or queue depth at the same timestamp |
The table is intentionally not a replacement for manufacturer diagnosis. It is a guide to help you collect the right data before you contact the OEM or perform any corrective maintenance.
Collecting Evidence Without Jumping to Conclusions #
The most common failure in AGV condition monitoring is not a lack of data; it is a lack of discipline in collecting data over a meaningful time window. A single fault timestamp might point to a motor controller, but the evidence only becomes useful when you compare it to the vehicle’s full context over the preceding ten minutes, across the full fleet activity, and against previous faults of the same kind.
Begin by synchronizing all clocks. AGV controllers, fleet servers, and network infrastructure all produce timestamps. If the clocks are not aligned to a common time source, you will not be able to correlate events. A five-second discrepancy between the vehicle log and the access point log can obscure the actual cause of a handover failure.
Next, capture the cyclic trend, not just the alarm. Most AGV control systems can store a buffered history of signals such as motor current, speed, and battery voltage. When a fault occurs, the buffer contains the conditions just before the fault. The conditions after the fault are also relevant, because they reveal whether the system was already unstable or whether a single external event pushed the vehicle past its threshold.
Do not limit evidence to digital signals. A vehicle technician who notes a whining sound from a drive motor or the smell of hot rubber from a steering unit is providing evidence that no sensor on most AGVs records automatically. Human observations should be logged with the same level of respect as a measured current spike, but they must be time-stamped and tied to the same location.
Finally, collect evidence from all the vehicles running the same route. If vehicle A has repeated deceleration faults at one lane but vehicle B never has them, the issue is probably not vehicle A’s individual drive unit. It may be a floor condition, a misconfigured speed zone, or a radiator fan blowing hot air at the vehicle’s scanner at that specific point in the route.
Common Interpretation Errors #
Even with good evidence, interpretation is where most maintenance teams lose time. The following errors are common across warehouses that use AGVs.
The first error is confusing normal ripple with a fault. AGV motor currents are naturally noisy. A change of 10 to 15% under normal acceleration is normal. Acting on a single elevated current sample can lead you to replace a motor controller or gearbox that was always healthy. The fix is to look at the moving average and the trend over multiple trips, not at one spike.
The second error is placing the fault inside the vehicle when the trigger is outside it. A laser-scanner fault on a vehicle that repeatedly stops near a newly installed rack row may simply mean the rack row is reflecting too much light, or the vehicle’s field has been configured too tightly for the new environment. Before requesting a scanner replacement, examine what changed in the environment.
The third error is treating correlation as causation. If you see a battery voltage dip at the exact moment of a motor deviation, you might assume that the battery caused the deviation. But the sequence might actually be a blocked wheel, which causes the motor to draw a high current, which causes the voltage dip. The voltage dip is a symptom, not a cause. Look at what happened first in the event buffer.
The fourth error is ignoring the time of day and the charging schedule. Many AGV faults are temperature-related. A vehicle that has been idle for a long charge cycle may have a warm battery, warm motors, and a warm charging connector. Faults that appear within the first minutes after a charge cycle may be caused by thermal expansion of electrical contacts rather than by vehicle electronics. Compare faults across the same time of day and similar thermal states.
The fifth error is trusting a single diagnostic code without reviewing the message’s context. AGV log codes are often ambiguous. A “position tracking” code can be generated by a navigation error, an external safety stop, or a flicker in power supply to the scanner. The code is only the beginning of the investigation, not the conclusion.
Maintenance Implications #
Condition monitoring changes maintenance from a scheduled-interval activity to an evidence-based activity. The benefit is that you stop replacing healthy parts and start acting on early indicators. The risk is that you begin acting on noise. The practical middle ground is to establish site-specific thresholds based on observation, not on a general recommendation from an unverified source.
For example, if scanner match quality typically sits between 90 and 95% on a clean route, you might set an investigation threshold at 85%, a planning threshold at 80%, and a service action threshold at 75%. The thresholds are based on your site’s own baseline. They should be reviewed whenever the environment changes, such as after rack installation or when plastic wrapping is left near a reflector.
Maintenance intervals for mechanical components such as drive wheels, steering bearings, and brakes are influenced by accumulated torque and travel distance. If your condition data shows a steady upward trend in motor current, you can schedule a bearing inspection before the bearing reaches a failure state, rather than waiting for a vibration alarm.
Thermal imaging of AGVs is useful but only when combined with electrical load data. A motor that is warm after a heavy trip is normal; the same motor that is warm after an empty, slow trip is telling you something. Always compare thermal measurements against actual power output for the same trip profile.
One maintenance implication is often overlooked: condition monitoring data itself needs maintenance. If the data files are not archived, if the software used to view trend data is outdated, or if no one is assigned to review the data periodically, the entire monitoring program becomes a dead file repository. Reserve at least a weekly review of fleet-level exceptions, and a monthly review of trends for vehicles that are known to operate at high utilization.
Decision Boundaries: When to Act, Escalate, or Stop #
Not every anomaly requires immediate action, and not every action is appropriate for a site maintenance crew. Your decision should depend on the safety classification of the component, the certainty of your diagnosis, and the acceptable risk of continued operation.
If any safety-related signal, such as a scanner warning, an emergency stop circuit anomaly, or a brake fault, is present or imminent, the decision is simple. Stop the vehicle. Do not attempt to override or mask the signal. Follow the site’s lockout/tagout procedures. Bring in an authorized engineer where local regulations require it, and rely on OEM documentation before returning the vehicle to operation.
If the anomaly is in a non-safety system, such as a minor steering calibration drift or a battery voltage dip that has not yet caused a fault, you may be able to continue operation while you collect more data. But you must define an end condition. For instance, you may allow a vehicle with a slightly low battery voltage to continue until the next planned charge cycle, but you must commit to a capacity check at the next maintenance window.
Escalation is appropriate when the data is contradictory or when the cost of a wrong diagnosis is high. If the vehicle shows a drive fault, the battery voltage is low, and the network logs show a communication interruption, you may need to escalate to a controls engineer who can look at the system with a cross-disciplinary view. Do not disassemble a drive unit because you have a vague suspicion when a network data review might reveal everything.
Some decisions require OEM support. If your trend data indicates a component is consistently failing across multiple vehicles, or if the fault behavior is new and not described in the manual, contact the original equipment manufacturer. They may have better visibility into design changes, software revisions, and known failure modes, and they are the appropriate source for any firmware-level changes.
Finally, document each decision. A maintenance log that records what data was reviewed, what threshold was crossed, what action was taken, and whether the action resolved the symptom creates a feedback loop. Over time, you will build a site-specific profile of normal AGV behavior that is more accurate than any generic default table.
Key Takeaways #
- AGV condition monitoring depends on correlating multiple signal groups, not on interpreting any single log code or alarm message in isolation.
- Navigation match quality, motor current trends, scanner contamination warnings, battery voltage under load, and radio retry counts are early indicators that should be reviewed before components begin to fail.
- Always time-synchronize vehicle logs, fleet controller records, and network logs before attempting to reconstruct the cause of an intermittent fault.
