# Robot Safety Scanners: Monitoring Strategy, Alert Thresholds and Escalation - Canonical: https://pearlgateway.net/docs/robot-safety-scanners-monitoring-strategy-alert-thresholds-and-escalation/ - Updated: 2026-09-22T05:51:00+00:00 Robot safety scanners are non-contact protective devices that monitor a defined area around a moving machine. On autonomous mobile robots (AMRs), handling cells, and automated pallet movers, these scanners provide the main protective layer for people who share the facility. In daily operation, the scanner is also a source of information: it measures distances, detects objects, selects field sets, and supports navigation. This dual role often creates confusion. Operators may observe a slow-down, a warning message, or an unexpected stop and assume the scanner is at fault. In most cases, the scanner is reporting exactly what is in its monitored area. The problem lies in how the field thresholds are configured, how the monitoring strategy interprets the data, and how the team handles escalation. This field note explains those layers in plain language and gives a practical path for evidence-based troubleshooting. ## Operating Context: Where the Scanner Sits in the System On an AMR, the scanner is typically mounted low on the front or at the leading corner, at a height chosen to detect a person’s lower legs while ignoring overhanging loads. On a robotic cell, the scanner may be fixed at the entrance or along a guarded opening. In both cases, the scanner produces two kinds of output: a safety-related output that goes to the machine’s safety logic, and measurement data that goes to the navigation or cell controller. The safety output is tied to defined protective fields. The measurement data is used for mapping, localization, and obstacle avoidance. These two functions share the same optical assembly, but they are processed independently inside the device. This separation matters during diagnosis. A robot that slows down because a warning field is entered is doing what the configuration asks. A robot that stops because a safety field is entered is doing the same. The scanner is not “thinking” about whether the object is real. It compares each measured distance to a stored boundary and responds accordingly. When a person, pallet, or reflective floor marking enters the protected region, the scanner opens the safety output and the robot’s safety circuit disables motion. Understanding the components around the scanner, including the safety relay, contactors, brake controller, and restart interlock, helps the engineer trace the event from sensor to machine state. ## Field Sets and What Each Field Means Every safety scanner operates with one or more field sets. A field set normally contains two functional areas: a protective or safety field and a warning field. The safety field is the area where the scanner must stop the machine. The warning field is a larger area that triggers a slower speed, a change in travel path, or an audible signal before the object reaches the protective zone. The scanner selects a field set through its control inputs, usually on the basis of the robot’s speed, direction, or operating mode. For example, a fast-moving AMR in open aisle travel uses a longer, narrower safety field because its stopping distance is longer. In a narrow doorway or at a charging station, the same robot uses a shorter, wider field because high speed is not allowed in that area. Field sets are not adjustable through the HMI during an event. They are stored in the scanner’s configuration and selected by another controller. When reading an event log, the engineer must know which field set was active at the moment of the trip. A person standing at a fixed position may be inside the safety field in one field set and outside it in another. That is not a sensor failure; it is the intended behavior of the speed-related monitoring strategy. This is also why the robot may appear to “see” someone who is standing in a spot that was safe moments earlier while the robot was still moving at full speed. ## How the Monitoring Loop Really Works The scanner emits pulsed infrared light. The receiver measures the time of flight for each pulse and builds a distance profile of the surrounding area. The safety-related monitoring loop then takes this profile and compares each measured point against the active field boundary. If a measured point falls inside the safety field, the scanner opens its safety output. If the point falls inside the warning field only, the scanner sets a separate digital flag that the machine controller can read. That flag is what triggers a slow-down or an alert tone. The scan runs continuously, but the output response is not instant. The scanner uses a short internal confirmation time to prevent a single dust speck, a spurious reflection, or an electrical glitch from stopping the robot for one scan cycle. This confirmation time is a normal part of the safety design and is not a field-adjustable sensitivity. The scanner also monitors its own optical health. Contamination on the window, moisture, or a partially blocked mirror reduces received signal strength. If the scanner cannot guarantee that it can see a protective field at full performance, it enters a safe state. From the operator’s perspective, this appears as an unexplained stop in a perfectly clean aisle. The window may look clean to the eye, but a fine film of dust on the outer surface can scatter light and reduce the distance at which the scanner can reliably detect an object. The scanner reports this condition in its diagnostics, but most operators never open the diagnostics view. They simply reset the robot and continue. The next stop occurs at the same location, and the investigation starts over. ## Alert Thresholds, Trip Thresholds, and Fuzzy Lines The word “threshold” is used differently in daily conversation and in scanner configuration. In the operator’s mind, a threshold is a sensitivity level that can be raised or lowered. In the scanner, alert and trip thresholds are physical boundaries drawn in the floor plan. The warning threshold is the outer edge of the warning field. The safety threshold is the outer edge of the protective field. The scanner does not measure “how close” an object is in a continuous way before it acts. It checks whether the measured distance falls inside a geometric area. Once an object enters that area, the relevant output changes state. The threshold is therefore a line, not a gain. Many configuration tools allow the engineer to draw these lines and to adjust the distance between them. This is where interpretation errors occur. ### Common Threshold Misreadings - Raising the warning threshold to reduce nuisance slow-downs is not a harmless change. A narrow warning field gives the robot less time to reduce speed before the object enters the protective zone. - A scanner that reports “object present” with no visible object is often interpreted as a threshold problem. In reality, the likely cause is a reflective surface, a bright floor marking, or ## Practical Review Table Review area | Evidence | Interpretation caution Operating state | Mode, sequence step, mission and interlock status | Expected holds can resemble equipment faults. Physical condition | Alignment, wear, contamination, obstruction and load condition | One visible defect may be a consequence rather than the cause. Event history | Time-aligned alarms, input changes and recent interventions | Unaligned clocks can reverse the apparent event order. Validation | Controlled test result under representative conditions | A single successful cycle does not establish long-term reliability. Apply this table to robot safety scanners: monitoring strategy, alert thresholds and escalation using approved site procedures and documented evidence. ## Related Pearl Gateway Guides - [Piece-Picking Robots: Capacity Planning and Bottleneck Analysis](/docs/piece-picking-robots-capacity-planning-and-bottleneck-analysis/) - [Mobile Robot Charging Stations: Capacity Planning and Bottleneck Analysis](/docs/mobile-robot-charging-stations-capacity-planning-and-bottleneck-analysis/) - [Fleet Traffic Management: Capacity Planning and Bottleneck Analysis](/docs/fleet-traffic-management-capacity-planning-and-bottleneck-analysis/) ## Site-Specific Review Worksheet This educational worksheet supports a structured review of robot safety scanners: monitoring strategy, alert thresholds and escalation. 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. ## Evidence Matrix for Operational Review Evidence group | Questions to answer | Why it matters Sequence state | What mode, step, mission and interlock state were active? | Separates a physical problem from an expected control hold. Material condition | Were load dimensions, orientation, stability and spacing within the intended envelope? | Explains faults that appear random when only controller data is reviewed. Device evidence | Which inputs changed, in what order, and against which timestamp? | Supports repeatable diagnosis instead of component substitution by guesswork. Change history | What maintenance, configuration, software or process change preceded the symptom? | Helps define a useful comparison window and rollback boundary. For robot safety scanners: monitoring strategy, alert thresholds and escalation, the matrix should be completed with evidence from the same event window. Mixing observations from unrelated shifts can create a convincing but false causal story. If timestamps are inconsistent, establish which controller, server or operator record is authoritative before comparing event order. Trend evidence is more useful when the measurement definition remains stable. Record units, sampling interval, filtering, equipment mode and product family. A rising fault count may reflect increased throughput rather than deteriorating equipment, while a stable count can hide deterioration if production volume has fallen. ## Implementation and Governance Questions Before changing a maintenance task, control parameter or operating method related to robot safety scanners: monitoring strategy, alert thresholds and escalation, define ownership and approval boundaries. Identify who can authorize the change, who validates it, how the previous state will be restored and which operating conditions must be represented during the test. - Is the observed condition repeatable, and has the equipment boundary been stated clearly? - Are mechanical, electrical, controls, software and process explanations being considered independently? - Does the proposed action alter a safety function, protected access rule, alarm priority or recovery sequence? - Can the result be measured with an agreed baseline rather than operator impression alone? - Will the change remain valid across product sizes, routes, modes, shifts and degraded conditions? - Is there a documented rollback point and a named owner for follow-up observation? Temporary workarounds should be visible in shift handover and maintenance records. An undocumented workaround can become the new normal and obscure the original defect. Closeout should distinguish containment, corrective action and systemic prevention so later teams do not assume that a restarted system has been permanently repaired. This governance context is especially important in robotics, amrs & automated handling, where local changes can affect upstream release logic, downstream capacity, inventory state or recovery behavior outside the immediate machine boundary.