AMR Autonomous Mobile Robot Design Standards: How Safety Standards Shape AMR Design

When designing an Autonomous Mobile Robot, navigation accuracy, payload capacity, and travel speed are only the basic parameters. Once the AMR enters an industrial environment, it must also operate safely around people, forklifts, equipment, and other robots.

This means AMR Autonomous Mobile Robot Design Standards influence the controller, safety LiDAR, emergency-stop circuit, drive system, stopping distance, load detection, and navigation software from the earliest stages of product development.

ISO 3691-4:2023 is currently one of the key international safety standards for AMRs and other driverless industrial trucks. It explicitly includes Autonomous Mobile Robots and Automated Guided Vehicles within its scope. ANSI/A3 R15.08 addresses the design, system integration, and use of Industrial Mobile Robots.

For AMR engineers, the important point is not simply knowing the standard numbers. The real task is translating those requirements into the mechanical, electrical, and software design of the robot.

AMR Design Standards First Define the Safety Control Architecture

AMR navigation control and safety control perform different jobs.

The Navigation Controller handles localization, path planning, and normal motion. The Safety Controller handles emergency stop, safety scanner inputs, speed monitoring, and other safety-related signals.

These functions should not simply depend on the same ordinary software logic.

For example, the navigation system may still consider the route ahead passable even after a person enters the protective area. The safety system must be able to trigger deceleration or a stop independently, without waiting for the higher-level navigation program to make that decision.

The same principle applies to the emergency-stop circuit.

Pressing an emergency-stop button should move the AMR into the required safe state. It should not be treated as nothing more than a normal software command to stop a task.

For that reason, the safety architecture needs to be defined while selecting the AMR controller, drive, encoder, and safety I/O. ANSI/A3 R15.08 Part 1 is primarily aimed at IMR manufacturers and addresses technical requirements for the design and integration of Industrial Mobile Robots.

Safety LiDAR and Protective Fields Cannot Use Fixed Parameters

An AMR protective field is directly related to vehicle speed.

When the robot approaches a workstation at low speed, it needs a shorter stopping distance. When it travels at higher speed along a main aisle, more distance is required between obstacle detection and a complete stop.

Safety LiDAR therefore commonly switches between different protective fields according to the vehicle state.

As speed increases, the protective field extends farther forward. In low-speed areas, a smaller field can support docking, load transfer, or movement in confined spaces.

What really matters is the complete stopping process:

Detection -> Controller Response -> Drive Deceleration -> Mechanical Stop

The scanner range is only one part of this process. Controller response time, vehicle speed, braking performance, and floor conditions all affect the final stopping distance.

If the maximum AMR speed is increased later, the existing safety fields need to be checked again. Changing only the Speed Limit in the navigation software is not enough.

Load Conditions Directly Affect AMR Safety Design

An AMR is not dynamically identical when empty and fully loaded.

As payload increases, vehicle mass, inertia, and stopping distance change. For Lifting AMRs, Autonomous Forklifts, and other mobile robots with top modules, the center of gravity and external dimensions may also change during operation.

Consider a lifting AMR with a vehicle width of 700 mm carrying a rack that is 1,000 mm wide.

The rack now determines the actual space occupied by the moving system.

Path planning, turning clearance, and obstacle detection must account for the 1,000 mm loaded profile rather than continuing to use the dimensions of the bare vehicle.

The situation is even more complex for an Autonomous Forklift.

Fork height, payload weight, load center, and steering condition all affect stability. A fully loaded high-speed turn should not use exactly the same motion parameters as unloaded straight-line travel.

AMR safety parameters therefore need to consider several factors together:

Speed + Load + Vehicle Geometry + Direction + Braking Performance

The payload is therefore not an isolated product specification. It directly affects protective-field settings, speed limits, and motion-control design.

AMR Navigation Software Is Also Constrained by Design Standards

An AMR can change its route autonomously, which is one of the clearest differences between an AMR and a fixed-route AGV.

Autonomous navigation, however, does not mean the robot can detour through any part of the map.

If a pallet blocks the original route, the AMR may replan around it, but the new path still has to remain within the safety boundaries defined for the facility.

A practical AMR map therefore often contains operational rules such as:

No-Go Area | Speed-Limit Zone | One-Way Area | Restricted Area | Traffic Zone

The robot can reduce speed automatically in areas with frequent pedestrian traffic, restrict passing in narrow aisles, and switch to the appropriate docking parameters and protective field as it approaches a workstation.

Normal navigation logic and safety functions still need clearly defined responsibilities.

Path planning can decide where the robot should travel, while functions involving personnel protection and safe stopping still need to be implemented through the appropriate safety-control architecture.

ISO 3691-4 also recognizes that conditions in the operating zone have a significant influence on the safe operation of driverless industrial trucks.

Top Modules Turn the AMR into a Different Safety System

Adding a Lift, Roller, Conveyor, or other attachment to a standard mobile base changes the risk assessment for the complete machine.

Take a Roller AMR as an example.

After the robot reaches a conveyor station, the mobile base may already be stopped while the roller continues running to transfer the load from the AMR to the conveyor.

At that point, the safety question is no longer limited to whether the robot could collide with a person.

The system also needs to confirm correct docking, conveyor readiness, load position, and whether the transfer creates a falling-load or pinch-point risk.

A Lifting AMR creates a similar situation.

Once the load is raised, load height and center of gravity change, so permitted speed and turning parameters may need to change as well.

ANSI/A3 R15.08 Part 1 distinguishes between mobile platforms, IMRs with active or passive attachments, and mobile manipulators because these attachments directly change the overall risk characteristics of the robot.

A mobile base that satisfies its design requirements does not automatically remain unchanged from a safety perspective after any top module is installed.

Multiple AMRs Extend Vehicle Safety into System Safety

A single AMR may be able to stop safely, yet that does not guarantee that an entire fleet will operate smoothly.

If two AMRs enter the same narrow aisle from opposite directions, both safety scanners may work correctly and both vehicles may stop safely.

There is no collision, but the system can still end up in a deadlock.

At that point, the problem has moved beyond single-vehicle obstacle avoidance. An RCS or Fleet Management System needs to manage right-of-way, intersections, one-way areas, and traffic priorities.

Peripheral equipment is also part of the system design.

When an AMR approaches an automatic door, the system needs confirmation that the door has opened to an allowed position before the vehicle proceeds. Elevator use requires coordination of floor and door status. Transfers with conveyors, AS/RS, or production equipment require handshakes between the AMR, PLCs, and higher-level systems.

The ANSI/A3 R15.08 series therefore extends beyond the individual IMR. Part 2 and Part 3 address IMR systems, applications, and the safety requirements that apply during use.

At this stage, the design object is no longer just a robot. It is the robot, fleet control, and operating environment working together.

Battery and Electrical Design Are Also Part of AMR Compliance

Long-running AMRs depend on the battery pack, BMS, charging system, and the vehicle's electrical distribution architecture.

Failures in these areas can create risks related to overcurrent, insulation, electrical faults, or the battery itself.

UL 3100 is one North American standard for Automated Mobile Platforms. It applies to battery-powered mobile platforms used for industrial tasks such as carrying, lifting, picking, and towing. The standard also makes an important distinction: equipment fitted with forks and used as a forklift is treated as an industrial truck and is evaluated under the applicable industrial-truck requirements.

Lifting AMRs, mobile platforms, and Autonomous Forklifts therefore should not automatically be treated as the same equipment category for standards purposes.

The target market, load-handling mechanism, and charging method can all affect which standards need to be considered during product evaluation.

Design Standards Should Enter the AMR Development Process Early

One of the most expensive situations in AMR development is waiting until the vehicle is complete before preparing for third-party testing.

If the safety scanner position is found to be obstructed at that stage, the enclosure or even the chassis may need to be modified.

If the original controller, drive, or emergency-stop architecture cannot support the required safety functions, the redesign can be much larger.

Software has the same problem.

A vehicle that can complete navigation and task execution normally has not finished validation. Sensor failure, communication loss, full-load braking, emergency stop, and peripheral-equipment faults also need to be tested.

A more effective development sequence is to define the target market and applicable standards first, then break the requirements down into:

Mechanical Design -> Electrical Architecture -> Functional Safety -> Navigation Software -> Load Handling -> System Integration -> Verification

With this approach, the design team already knows which parameters will need to be verified later when choosing the controller, LiDAR, drive, encoder, battery, and top module.

ISO 3691-4:2023 remains the current published edition, while ISO is already progressing work on a future revision. AMR development teams therefore also need to monitor changes in the standards that apply to future products and projects.

If you are developing or deploying an AMR, Lifting AGV, Autonomous Forklift, or other mobile robot system, you can contact Coolyne to discuss vehicle architecture, operating conditions, and automation-system integration requirements.