After the Stop How to Authorize Safe AMR Recovery and Return to Automatic Operation

The Most Dangerous Moment May Come After a Successful Stop

An autonomous mobile robot loses localization beside a blind intersection, detects a safety-field intrusion, or receives an emergency-stop command during a load transfer. The drives stop. The status light changes. The fleet dashboard records a fault. Everyone can see that the machine is stationary.

That apparent calm is where a second risk begins. The person who removed the obstruction may still be inside the movement envelope. A pallet may have shifted. A lift axis may be suspended between states. The robot may have regained a numerical pose without regaining trustworthy spatial alignment. The fleet controller may still hold a valid-looking mission that was created for conditions that no longer exist. If clearing one fault bit also re-enables motion, the system can turn a correct stop into an unexpected restart.

A defensible AMR safe restart design therefore treats stopping and restarting as two separate safety decisions. The stop asks, “How will hazardous motion be removed or controlled?” Restart asks, “What new evidence justifies allowing motion again?” A documented AMR restart authorization connects that evidence to a named person or control function and a bounded first movement. Time alone, disappearance of an obstacle, release of an emergency-stop actuator, restoration of Wi-Fi, or recovery of a software health score is not a complete answer.

This guide addresses the safety authorization layer after a robot has entered a hold. It does not repeat the site’s broader guide to AMR fault recovery, which explains how to preserve mission and material state and restore production service. Here, the subject is narrower and more demanding: who may authorize recovery, what must be true before limited movement, how degraded operation is bounded, and what evidence is required before the robot returns to automatic execution.

Five Verbs That Must Never Collapse Into One Button

Many human-machine interfaces use “reset,” “resume,” “retry,” “recover,” and “start” as if they were synonyms. They are not. A safe design gives each verb one defined state transition and one defined authority. If the interface cannot explain which transition a button will request, the operator cannot predict the machine’s next behavior.

The search phrase AMR reset versus restart names a real engineering problem: a reset can make a start possible, but it should not be the start. An AMR emergency stop reset must likewise be separated from the command that initiates new travel or application motion. This distinction is consistent with general machinery-safety principles and with the European Machinery Directive’s requirement that restarting after a stoppage normally follow voluntary actuation of a control device provided for that purpose. Exact legal and standards obligations still depend on the machine, jurisdiction, installation, and applicable edition; the requirement belongs in the project risk assessment, not in a generic software convention.

Build a Recovery Authorization Case, Not a Troubleshooting Checklist

A troubleshooting checklist asks how to make the error disappear. A recovery authorization case asks whether the complete robot application is entitled to move. The difference matters because the original fault may be gone while a consequential hazard remains. A localization fault can be cleared after relocalization, yet the robot may now be physically displaced relative to its reserved traffic segment. A protective-field violation can clear when a person steps out of the scanner plane, yet the person may remain beside an overhanging load. A station timeout can clear after communication returns, while the conveyor and robot disagree about load ownership.

The case should contain four connected artifacts:

1. a state-transition contract defining every legal and prohibited transition;
2. a set of restart authorization gates that must close for the current event;
3. a recovery-motion envelope defining any movement permitted before full automatic release; and
4. an evidence ledger showing what the system and operator actually observed.

This structure is more useful than a universal “recoverable/not recoverable” flag. A single incident can be recoverable at the diagnostic layer, prohibited at the motion layer, and unresolved at the production-transaction layer. Those states need separate representation.

The State-Transition Contract

The contract below is an engineering model, not a claim that one named standard mandates these exact labels. Projects can rename the states, but they should preserve the separation of authority and evidence.

The most important prohibited edge is Safe hold → Automatic execution merely because the triggering input returns to normal. Other prohibited shortcuts include Service → Automatic without configuration checks, Manual → Automatic while the fleet still assumes the old position, and Limited recovery → unrestricted travel because the operator released a control.

The Eight Gates Between a Stationary Robot and New Motion

An effective AMR restart procedure evaluates the event, not just the robot. The following eight gates create a repeatable decision. Not every gate needs a human confirmation; many should be machine-enforced. However, every applicable gate needs a defined owner, input, acceptance rule, failure response, and logged result.

Gate 1: Identify Why the Robot Stopped

Classify the initiating event and the stop response. Was it an emergency stop, protective stop, controlled operational pause, localization loss, drive fault, station fault, fleet command, loss of communication, power interruption, or a combination? “Robot stopped” is not a diagnosis. The category determines what may be reset, whether a person must inspect the site, and whether motion can be recovered at all.

The cause must be specific enough to test. “Sensor fault cleared” is weak. “Front safety scanner reported contamination; lens was cleaned; diagnostic channel returned healthy; protective-field switching was checked; no configuration changed” is reviewable. If the fault source is unknown or contradictory, the case remains in diagnostic hold.

Gate 2: Control the Physical Scene

Confirm where people, forklifts, loads, carts, racks, doors, conveyors, lifts, and adjacent robots are now—not where the map predicts they should be. The person who initiates recovery should have either direct view of the relevant hazard zone or a validated equivalent means of determining that it is clear. Camera visibility alone is not automatically sufficient; blind areas, latency, image freeze, field of view, and the distinction between monitoring and a safety-related protective function must be addressed.

For work that requires a person to enter a danger zone, unjam equipment, reach beneath a load, or bypass normal guarding, routine recovery may no longer be the right procedure. In the United States, OSHA 29 CFR 1910.147 applies to servicing and maintenance where unexpected energization, startup, or stored-energy release could injure a worker. A project-specific energy-control procedure should define when the event crosses that boundary.

Gate 3: Restore the Safety Chain Without Bypass

Verify the safety-related inputs, logic, outputs, brakes, drive inhibit, protective devices, emergency-stop circuit, field selection, load-holding functions, and external interlocks required for the next state. A healthy navigation computer does not prove a healthy safety controller. A clear scanner field does not prove that the correct field set is active. A released emergency-stop actuator does not prove the reset circuit, brakes, contactors, or external zone are ready.

This gate connects directly to the site’s distinction between safety-rated sensing and navigation perception and to its guide on protective-field engineering. Recovery must preserve that boundary: perception may advise, but only the credited safety path can satisfy the safety-function prerequisite assigned to it.

Gate 4: Re-establish Trustworthy Robot State

Check pose, map and zone identity, speed feedback, steering state, brake state, controller mode, time synchronization, sensor freshness, active software/configuration baseline, and any top-module position relevant to motion. When the trigger was localization loss, use the acceptance rules defined in the preceding guide to AMR localization confidence and safe response. A confidence score that rises above a threshold for one sample does not close this gate. The system needs stable, cross-checked evidence that the pose is usable for the intended transition.

VDA 5050 version 3.0 gives a useful interoperability example: when the reported localized field is false, the position cannot be trusted, a fatal localization error is reported, and the robot must not resume automatic driving or continue the order. The same specification says its numeric localization score and deviation range are for logging and visualization, not fleet-control logic. This illustrates why a dashboard’s green indicator should not silently become a restart authorization.

Gate 5: Verify Load, Tooling, and Stored Energy

Confirm load identity, presence, restraint, overhang, center-of-gravity-sensitive state, lift or conveyor position, clamp status, station ownership, and any energy that can produce motion independently of the travel drives. A mobile base at zero velocity can still present a hazard through gravity, a raised mechanism, compressed pneumatics, a powered roller, an unstable payload, or an adjacent station.

If the load was manually moved, removed, or re-seated during the stop, the old mission assumptions may be invalid. The system should not infer load truth solely from the business transaction. Physical detection, station handshake, and operator confirmation may need reconciliation before movement is allowed.

Gate 6: Reconcile Fleet, Mission, and Shared Resources

Determine whether the old order should continue, be canceled, be reconstructed, or be replaced. Reconcile the robot’s physical position with traffic reservations, one-way segments, exclusion zones, doors, elevators, stations, chargers, and other vehicles. A robot manually pushed two meters may now occupy a resource that the fleet considers free. Conversely, the fleet may still reserve a route behind the robot and create avoidable congestion.

VDA 5050’s operating-mode semantics show why this cannot be improvised. In INTERVENED mode, fleet control is not in control; zone requests are removed, and most instant actions are restricted. In MANUAL, SERVICE, and TEACH_IN modes, the current order is cleared and fleet orders are not allowed. A site need not use VDA 5050 to learn from the principle: intervention changes both motion authority and the validity of coordination state.

Gate 7: Authenticate the Person and the Command

Define who may request diagnostic reset, who may authorize limited recovery, who may operate a local enabling device, and who may return the system to automatic mode. Those privileges do not have to belong to the same role. A trained operator might clear a routine obstruction and request restart; only maintenance may release a drive fault; only a safety engineer may approve operation after a bypass or configuration discrepancy.

A mobile robot restart interlock should evaluate role, robot identity, current mode, site zone, unresolved faults, command source, command age, and the required sequence. Shared passwords or a generic fleet “resume all” button weaken both safety and accountability. The site’s guide to AMR cybersecurity and access control provides the related identity and remote-access architecture.

Gate 8: Bound and Observe the First Motion

Restart authorization should define the first motion, not merely release an indefinite permission. Specify route segment, direction, speed, acceleration, steering range, top-module behavior, protective-field set, maximum distance, warning time, timeout, and abort triggers. If the robot is resuming an old order, verify that the first executable step is still appropriate. If a fresh order is issued, verify that it begins from the robot’s actual current node or validated pose.

The first movement after recovery deserves higher observability than an ordinary mission. Log the command source, authorization gates, initial state, warning output, motion onset, safety inputs, position progression, and completion. A system that records only “fault cleared” loses the evidence needed to distinguish a correct restart from a lucky one.

Degraded Operation Is a New Operating Envelope

An AMR degraded mode is not normal automatic operation with an amber icon. It is a separately assessed envelope in which named capabilities are unavailable or intentionally restricted while a defined subset of functions remains permitted. The mode is defensible only when the remaining controls are sufficient for the remaining hazards.

“Move slowly” is not a complete degraded-mode specification. Reduced speed can reduce stopping demand and kinetic energy, but it does not fix incorrect localization, an unprotected load edge, an invalid safety-field contour, loss of steering feedback, an occupied blind area, or a brake that cannot hold on a slope. For each fault family, the risk assessment must determine whether reduced motion provides benefit, creates new exposure, or is prohibited.

Four Practical Recovery Classes

The phrase AMR manual recovery mode should therefore describe a controlled operating state, not a maintenance back door. Its specification should state which device has control, whether fleet commands are rejected, whether steering and handling devices are enabled, what safety functions remain active, the maximum speed and distance, how the operator maintains control, and what happens when the control is released or communication is lost.

Degraded Does Not Mean Safety-Downgraded

Some functions may degrade without changing credited risk reduction. A failed barcode reader may prevent load identification but leave travel safety intact; the robot might be allowed to move empty to an inspection point. A non-safety 3D camera may fail while safety scanners remain valid, allowing a restricted route that avoids the performance feature. By contrast, loss of a safety-channel input, uncertain braking behavior, invalid field selection, or untrusted pose near a boundary can remove the evidence needed for motion.

The specification should list capability dependencies explicitly. Do not make “degraded mode available” a generic procurement checkbox. Ask which fault combinations were assessed, which motions remain possible, which safety functions remain credited, and which evidence demonstrates the boundary.

A Fault-Family Matrix Prevents One-Button Recovery

The matrix below illustrates how the same reset button cannot safely govern every stop. Acceptance criteria must be tailored to the actual robot, top module, site, load, and risk assessment.

Authority Must Follow the Hazard, Not the Software Hierarchy

A fleet manager may coordinate hundreds of missions, but broad operational scope does not make it the owner of every safety decision. The local safety controller has immediate knowledge of credited safety inputs and outputs. Navigation has richer environmental and pose data. The fleet manager owns traffic and order context. The station PLC owns transfer state. The operator sees the scene. Maintenance understands the intervention. Safe recovery depends on a controlled intersection of those views.

The safest architecture does not force one actor to guess the others’ state. It exposes the prerequisite explicitly and refuses the transition when required evidence is unavailable, stale, contradictory, or outside limits.

Remote Recovery Needs a Cyber-Physical Permission Model

Remote diagnostics can reduce downtime, but distance removes direct knowledge of the scene. A technician may know that a software service restarted successfully while having no reliable view of the person behind the robot, the shifted load, the forklift entering the aisle, or the local maintenance lock. For that reason, remote access and remote motion authority should be different permissions.

A defensible remote design can require all of the following:

• a named user or authenticated service with role-specific permission;
• selection of one uniquely identified robot and one recovery request;
• a local area-clear or enabling confirmation when the remote party cannot establish the scene;
• fresh status from the local safety system, navigation, fleet, and affected station;
• rejection of commands created before the current fault, mode transition, reboot, or authorization window;
• protection against duplicate, delayed, or replayed commands;
• a short validity period that expires to no-motion;
• an audible or visible pre-motion warning appropriate to the risk assessment;
• immediate cancellation on any new safety event, mode change, communication loss, or local override; and
• a complete record connecting digital identity to physical consequence.

AMR automatic restart prevention must cover more than restoration of electrical power. It should also address Wi-Fi reconnection, fleet-server failover, broker reconnection, navigation-process restart, map reload, recovery of an external PLC, clearing of a field violation, charging completion, and expiration of a traffic pause. Each event can recreate a previously pending command unless the architecture deliberately invalidates or reauthorizes it.

Three Clocks Decide Whether Authorization Is Still Valid

Recovery logic often checks values without checking their age. A status may be correct for the instant when it was generated and dangerous when acted upon later. The authorization case should therefore control three clocks.

The State-Freshness Clock

Every critical observation needs a timestamp and an allowable age: safety state, pose, velocity, brake state, load state, station state, traffic permission, operator area-clear confirmation, and configuration identity. If clocks are not synchronized well enough to establish ordering, the system cannot reliably prove which observation preceded the restart request.

The Authorization-Window Clock

A permission should expire if motion does not begin within a defined interval. Otherwise, a scene-clear confirmation can remain armed while people and equipment re-enter the area. Expiry should require a new deliberate authorization, not silently refresh itself.

The Recovery-Envelope Clock

Limited recovery should terminate after a maximum duration, distance, number of attempts, or state transition. Repeated retries can gradually move a robot beyond the assumptions of the original risk assessment. A robot that fails the same bounded maneuver should return to hold and escalate, not keep improvising.

Write the Evidence Ledger Before Writing the HMI

A good recovery procedure is generated from evidence requirements, not from the buttons a vendor interface happens to offer. Define the record needed to reconstruct the event, then design controls that can produce it.

At minimum, the ledger should be able to connect:

• robot, fleet, site zone, map, configuration, software, and safety-parameter identities;
• initial fault, stop type, time sequence, speed, load, operating mode, and active order;
• all safety inputs and outputs relevant to the stop and restart;
• localization status, pose plausibility, field set, traffic reservations, and station state;
• diagnosis, work performed, components changed, bypasses applied and removed, and inspections completed;
• operator, maintainer, remote user, approving role, command source, and authentication result;
• selected recovery class and its speed, direction, distance, zone, timeout, and abort limits;
• reset request and result, separate start request and result, warning output, and motion onset; and
• first-motion trace, final state, mission reconciliation, deviations, and follow-up action.

The ledger does not have to live in one database. Safety logs, robot diagnostics, fleet events, station PLC records, identity logs, and maintenance records may be distributed. The requirement is a shared time basis and identifiers that allow investigators to join them without guessing.

This evidence should trace back to the AMR safety requirements specification. A requirement such as “the robot shall restart safely” is not testable. A stronger requirement names the triggering state, prerequisites, command source, prohibited automatic transitions, warning behavior, motion envelope, timeout, safe response to a failed prerequisite, and recorded evidence.

Twelve Challenge Tests That Expose Unsafe Shortcuts

AMR recovery validation should try to break the authorization logic, not merely demonstrate a successful operator workflow. The following cases are targeted recovery tests; the next article in this series will organize them inside a complete site-acceptance matrix.

1. Power returns with a previous run request present. Remove and restore power during an active mission. Verify that startup completion does not cause motion and that stale outputs, orders, and permissions are handled as specified.
2. Communication returns after a network interruption. Queue, delay, duplicate, and reorder messages. Verify that the robot does not execute a command whose context predates the reconnection or state reconciliation.
3. An emergency-stop actuator is released. Verify that release does not reset the safety function and reset does not command movement. Confirm the separate deliberate restart step.
4. A protective field clears while a person remains nearby. Place the person outside the active scanner plane but inside another part of the load or turning envelope. Verify that area-clear logic and operator rules prevent a blind restart where required.
5. Localization recovers transiently. Cause confidence or position validity to alternate around the threshold. Verify persistence, plausibility, hysteresis, timeout, and safe response rather than single-sample restart.
6. The robot is pushed or towed during the stop. Verify that old node, order, route, and traffic assumptions cannot authorize automatic motion until position and shared-resource state are rebuilt.
7. Local and remote users issue conflicting commands. Verify precedence, rejection, indication, and logging. A remote command must not override an active local intervention or energy-control state.
8. The wrong robot is selected. Present similar names or adjacent units in the HMI. Verify positive robot identification, local indication, and command scoping.
9. The enabling control is released during recovery. Verify immediate transition to the specified stop and that reapplying the control requires the intended sequence.
10. The recovery window expires. Delay motion until after authorization expiry and verify that the request is rejected rather than refreshed or executed late.
11. A second fault appears during the first recovery motion. Introduce a field violation, mode change, station disagreement, or communication loss. Verify immediate termination to the defined safe state.
12. The mechanism state disagrees with the mission state. Simulate a pallet present when the WMS says empty, a raised lift when the controller says travel-ready, or a conveyor transaction completed only on one side. Verify that the inconsistency blocks return to automatic operation.

Each test needs preconditions, instrumentation, expected transition, maximum response time where relevant, pass/fail criteria, required logs, deviation handling, and an owner. “Robot did not move” is not enough if the test cannot prove which interlock prevented it.

Procurement Requirements That Reveal Real Recovery Capability

Suppliers often demonstrate recovery under friendly conditions: an obstacle is removed, an operator taps resume, and the robot continues. Buyers should request boundary evidence before accepting the feature.

• Provide the complete operating-mode model and every permitted and prohibited transition.
• Identify which reset actions are safety-related, which are standard control functions, and which can be initiated remotely.
• Demonstrate that reset, emergency-stop release, communication restoration, power restoration, and fault disappearance do not inadvertently command motion.
• List every degraded or recovery mode with its enabled functions, safety functions, speed, direction, distance, zone, time, operator interface, and abort behavior.
• Show how manual repositioning changes pose, node, order, map, traffic reservation, and mission validity.
• Define behavior for duplicate, delayed, stale, unauthorized, and conflicting commands.
• Explain how local intervention overrides or blocks fleet commands.
• Provide the recovery evidence schema and export method, including synchronized timestamps and user identity.
• Identify faults for which recovery movement is prohibited and the required towing, support, or energy-control method.
• Provide test evidence for the final robot, load, top module, interfaces, software, safety configuration, and site conditions—not only a base-platform certificate.

The existing AMR acceptance testing guide can be used to place these questions in FAT, SAT, and handover. The purpose of this article is to define what the recovery claim must contain before the broader test program is built.

How the Standards Fit Without Becoming a Shortcut

As of August 2026, ISO 3691-4:2023 is the published international standard covering safety requirements and verification for driverless industrial trucks and their systems; its scope explicitly includes AMRs and vehicles with automatic, additional manual, and maintenance modes. ISO also reports a replacement draft under development. Projects should freeze the edition and regional requirements used for their assessment and monitor whether a later edition affects systems delivered over the 2026–2027 transition.

ISO 12100 provides the machinery risk-assessment and risk-reduction methodology. ISO 13849-1:2023 provides a methodology for designing and integrating safety-related parts of control systems, while noting that it does not select the safety function or required performance level for a particular application. ISO 13850 addresses emergency-stop design principles, and IEC 60204-1 covers electrical equipment of machines, including control-circuit, safe-torque-off, and emergency-stop topics. These references support the engineering process; none turns a general “recovery” feature into a credited safety function without an application-specific claim and validation.

VDA 5050 version 3.0 is an interface specification for communication between mobile robots and fleet control, not a functional-safety certificate. It is still valuable because it makes operating authority and state semantics visible. It distinguishes automatic, semiautomatic, intervened, manual, startup, service, and teach-in modes; represents emergency-stop and protective-field state; and defines what happens to orders and zone requests when control changes. The site’s AMR fleet interoperability guide explains the broader integration context.

Open navigation frameworks also use lifecycle states and “recovery behaviors.” Those mechanisms can help structure software bring-up, shutdown, planning retries, clearing costmaps, waiting, backing up, or other navigation actions. They are not automatically safety-rated restart controls. A Nav2 lifecycle transition can show that managed software nodes are active; it cannot by itself prove that the person is clear, the correct safety field is selected, the load is stable, or the robot is authorized to move. Safe recovery of autonomous mobile robots requires the complete application evidence chain.

Engineering note: this article is an educational framework, not a conformity assessment, legal opinion, or substitute for the applicable standard text, supplier instructions, site risk assessment, and validation by competent personnel.

Focused FAQ

Does releasing an emergency-stop button allow an AMR to move?

No. Releasing an emergency-stop actuator should remove the mechanical latch condition only within the designed sequence. The emergency-stop function may still require reset, and reset should only permit a separate restart action. The complete application must also confirm the scene, safety chain, robot state, load, interfaces, and authorization conditions relevant to the event.

Can an AMR resume automatically when a person leaves its protective field?

Only if that restart behavior is explicitly justified by the applicable standards, risk assessment, protective-device design, full hazard envelope, and validation for the exact application. A field becoming clear does not always mean the person has left every hazardous area. Load overhang, turning sweep, blind areas, adjacent equipment, and task context can require a deliberate restart.

Is reduced speed enough to make recovery safe?

No. Reduced speed changes some consequences and stopping requirements, but it does not correct untrusted position, wrong mode, failed brakes, missing protection, unstable loads, incorrect field selection, or an occupied blind area. Recovery speed is one parameter inside a separately assessed envelope.

Who should be allowed to restart a mobile robot?

The answer should come from the risk assessment and role model. Routine operational restart, local recovery motion, maintenance reset, post-repair release, and return to automatic service may require different competencies and permissions. The system should authenticate the role, record the person or service, and enforce the boundaries technically where practical.

Can the fleet manager authorize restart by itself?

Not when required prerequisites depend on local safety state, physical scene, load, intervention, or station conditions that the fleet cannot establish. Fleet control can participate by reconciling missions, positions, and shared resources, but it should not override the local safety chain or an active manual/service condition.

What is the difference between recovery motion and resumed production?

Recovery motion is a bounded action used to reach a known condition under a limited envelope. Resumed production returns authority to automatic mission execution and restores the approved operating envelope. Completing a recovery maneuver should lead to another verification point, not silently expand the robot’s permission.

When does routine recovery become maintenance requiring energy control?

That boundary is determined by applicable law and the site procedure. As a practical trigger, reassess the task whenever a person must enter a danger zone, remove or bypass guarding, unjam equipment, work beneath a raised load, release stored energy, or rely on control functions that may not prevent unexpected energization. In U.S. general industry, OSHA 29 CFR 1910.147 specifically addresses servicing and maintenance exposure to unexpected startup or hazardous-energy release.

What records should be kept after a recovery event?

Keep enough synchronized evidence to reconstruct cause, stop, intervention, authorization, reset, restart, and first motion. That normally includes configuration and map identity, robot and load state, safety and navigation status, operating mode, mission and traffic context, user identity, commands, gate results, warnings, timeouts, deviations, and final disposition.

Conclusion: Restart Permission Must Be Earned Again

A stopped AMR has not yet proved that it is ready to move. It has only completed one part of the risk-control sequence. Safe recovery begins by preserving the stop, understanding the event, controlling the scene, and separating acknowledgement, reset, reinitialization, recovery, and restart into explicit transitions.

The strongest designs create a recovery authorization case: a state contract that forbids shortcuts, eight gates that reconnect machine and site evidence, a bounded recovery envelope, and a ledger that makes every decision auditable. They also recognize that navigation recovery, production recovery, and safety release are related but different claims.

This approach prevents a familiar failure pattern: a robot resumes because the last red indicator turned green. Instead, motion begins only when the current physical condition, safety chain, robot state, load, fleet context, and authorized command support the same conclusion.

The next module will convert these event-level tests into a complete site acceptance test matrix, linking each scenario to configuration, instrumentation, expected response, pass/fail criteria, evidence ownership, and release decision.

Primary Technical References

• ISO 3691-4:2023 — Driverless industrial trucks and their systems
• ISO 12100:2010 — Machinery risk assessment and risk reduction
• ISO 13849-1:2023 — Safety-related parts of control systems
• ISO 13850:2015 — Emergency-stop function principles
• IEC 60204-1:2016+A1:2021 — Electrical equipment of machines
• VDA 5050 Version 3.0.0 — Mobile robot and fleet-control interface
• Directive 2006/42/EC on machinery
• OSHA 29 CFR 1910.147 — Control of hazardous energy
• Nav2 Lifecycle Manager documentation

#AMRSafeRestart #AMRRestartAuthorization #AMRRecovery #DegradedMode #RestartInterlock #EmergencyStopReset #AutomaticRestartPrevention #MobileRobotSafety #RecoveryValidation #NavigationSafety