AMR Drive Wheel Units: Integrated Architecture and Safety-Function Specification

1. Define the AMR Drive-Wheel Unit Boundary

The term drive wheel can describe either a mechanical wheel used in a drive position or a coordinated wheel-drive subsystem. Those two procurement objects have different interfaces, integration responsibilities, and documentation needs.

Published supplier architectures show that AMR wheel-drive subsystems can combine mechanical drive elements and control-related functions within one assembly. maxon describes a modular AMR wheel-drive subsystem combining a wheel, motor, gearhead, and brake. ^[1] IDEC describes a Safety Wheel Drive architecture combining a wheel, gearbox, motor, safety encoder, and safe motion control. ^[2]

These descriptions establish useful architecture patterns; they do not make the two products performance-equivalent or demonstrate that every integrated unit contains the same functions. An OEM should therefore convert the intended subsystem boundary into explicit RFQ fields rather than relying on a product-family name.

2. Integrated Architectures Found in AMR Wheel Drives

Two documented architecture patterns illustrate why an AMR OEM should not use a generic drive-wheel description as the complete technical requirement.

The distinction is material. The first pattern makes clear that a drive unit may consolidate wheel-drive and braking elements. The second adds safety-related sensing and motion-control functions. Neither pattern establishes a universal bill of materials for AMR drive wheel units, and neither should be used to infer load, torque, speed, power, duty cycle, environmental suitability, reliability, or certification status.

3. Specify Mechanical and Control Ownership Before RFQ Release

The RFQ should separate inclusion from responsibility. A component may be physically integrated into a supplier unit while its application-level behavior remains dependent on OEM control-system design, final machine integration, and validation.

A practical ownership model

1. Define the purchase boundary. Mark each of the wheel, motor, gearbox or gearhead, brake, encoder, and safe motion-control functions as required, optional, externally supplied, or not applicable.
2. Define the integration boundary. For every included function, request the electrical, mechanical, and control interfaces necessary for the OEM to integrate the unit into the AMR.
3. Define the safety boundary. Identify which safety-related functions are declared by the supplier and which remain part of the OEM’s complete AMR safety design.
4. Define the document boundary. State the documents needed for design review and clarify whether each document covers the unit itself, an interface, or the complete AMR application.
5. Hold selection pending application review. Review application-specific performance, interfaces, environmental conditions, validation needs, and service considerations before final selection.

4. Safety Functions in the AMR Drive-Wheel Specification

Safety-related content should be treated as a defined specification and documentation subject, not as a marketing attribute. A published AMR design-standards discussion identifies functional safety integration as typically involving Performance Level d (PLd), Category 3, or SIL2, and references ANSI/RIA R15.08 and ISO 3691-4. ^[3]

For this guide, that reference is useful for screening the supplier conversation: it indicates that safety-function integration may affect the drive-wheel subsystem and its controls. It does not establish the exact requirement for every AMR configuration, demonstrate conformity of a particular wheel-drive unit, or substitute for complete-robot validation.

5. Supplier Documentation Request Checklist

Use the following checklist as a pre-RFQ gate. It is deliberately architecture-focused because comparable quantitative ratings, test reports, lifecycle results, and common performance benchmarks are outside the available scope of this guide.

• Declared AMR drive-wheel unit boundary.
• Wheel inclusion: required, optional, externally supplied, or not applicable.
• Motor inclusion: required, optional, externally supplied, or not applicable.
• Gearbox or gearhead inclusion and stated architecture.
• Brake inclusion and stated subsystem boundary.
• Encoder inclusion, including whether it is declared as a safety encoder.
• Safe motion-control inclusion and the declared boundary of that function.
• Supplier statement of the safety-function architecture.
• Applicable standard or requirement reference used in the supplier documentation.
• Supplier/OEM responsibility allocation for subsystem integration and complete-AMR validation.
• List of documents supplied with the quotation or design-review package, including the scope each document covers.

Buyers can use these fields to normalize supplier responses. A quotation that omits the safety-function and responsibility boundaries should be treated as incomplete for an architecture-level comparison, even when the mechanical component list appears similar.

6. What This Guide Does Not Determine

This guide does not calculate wheel load, torque, speed, power, traction, braking distance, or duty cycle. It does not compare tread materials, thermal behavior, efficiency, price, supplier capacity, delivery performance, reliability, certification status, or lifecycle performance.

Those matters require application-specific data and review. Before releasing a final purchase order, the OEM should evaluate the intended AMR interfaces, operating environment, validation plan, service needs, and the current requirements applicable to the complete robot and target market.

Bottom line: specify the AMR drive wheel unit as a bounded subsystem. Make the requested mechanical, sensing, braking, and motion-control functions explicit; require a declared safety-function boundary; and compare suppliers only after their documentation describes the same technical object.