Mobile Robot Chassis Buying Guide for OEMs and Integrators: Payload, APIs, Navigation, Power, and Expansion

A mobile robot chassis is not a finished AMR. It is a development platform — a mechanical base with drive, power, sensors, and varying levels of software access that lets you build your own robot. The problem is that “open SDK” and “supports ROS2” mean different things depending on the supplier. One vendor’s “open SDK” gives you full low-level motor control; another’s gives you read-only telemetry over a REST endpoint. This guide helps OEMs, integrators, and research teams evaluate a chassis by what actually matters: payload capacity with top-module geometry, navigation stack access level, safety I/O, power budget, expansion interfaces, and lifecycle support.

A Mobile Chassis Is a Platform, Not a Finished AMR

The market offers multiple OEM/ODM chassis platforms. Some provide open SDKs with SLAM navigation and modular mounting. Others sell what is essentially a closed AMR with a development interface bolted on.

The distinction matters because it determines what you can build. A true OEM chassis gives you:

• Mechanical mounting patterns for custom top modules
• Electrical connections (power rails, communication buses)
• Navigation stack access (at some level)
• Software development tools (SDK, API, or ROS2 drivers)
• Documentation sufficient to build on top of the platform

A closed AMR with a “developer mode” gives you:

• A finished product with limited customization
• An API for sending navigation commands
• No access to low-level control, motor drivers, or sensor data
• No ability to change the navigation stack

The first question to ask: Are you buying a platform to build on, or a product to integrate? Both are legitimate, but they are not the same thing, and they are not interchangeable.

Payload, Center of Gravity and Top-Module Geometry

Payload is the most frequently misunderstood specification on a mobile chassis. The rated payload is not the weight you can put on top — it is the weight you can put on top under specific conditions of center of gravity, inertia, speed, and surface.

What payload actually means:

• The rated payload assumes a specific center of gravity height and offset from the chassis center.
• If your top module shifts the CG higher or off-center, the effective payload drops.
• Dynamic loads (acceleration, deceleration, turning) create additional forces that the rated payload does not account for unless the manufacturer specifies dynamic load conditions.
• A 300 kg rated payload with a low, centered top module is not the same as 300 kg with a tall, offset manipulator arm on top.

What buyers must calculate:

If your top module is a manipulator arm that extends and retracts, the CG shifts dynamically during operation. The chassis must handle not just the static weight but the dynamic CG movement.

Drive Architecture and Maneuverability

The drive architecture determines what the chassis can do physically — where it can go, how it turns, and what floor conditions it can handle.

Differential drive is the most common architecture for indoor AMRs. It is simple, robust, and can achieve zero-turn radius by rotating wheels in opposite directions. The turning radius depends on the wheelbase. Limitations: cannot move laterally, and casters can cause issues on uneven floors or at low speeds (caster wobble).

Omnidirectional drive uses Mecanum or omni wheels to enable lateral movement and rotation in place. This is ideal for tight spaces and precision positioning. The trade-offs: wheels are mechanically complex, sensitive to floor conditions, and typically more expensive to maintain. Mecanum wheels wear faster than conventional wheels and can leave marks on some floor surfaces.

Ackermann drive uses car-like steering linkage. It is best for outdoor applications and heavier payloads. It cannot move laterally and has a non-zero turning radius, but it can achieve higher speeds and handles outdoor surfaces better than the other two architectures.

What drives this choice: Application environment (indoor vs. outdoor), space constraints, payload, speed requirements, and floor conditions.

Battery, Charging and Power Available to the Payload

Battery specifications tell you how long the chassis runs and how much power it can deliver to your top module. Both matter, but for different reasons.

Battery capacity is specified in Ah (amp-hours) or Wh (watt-hours). Wh is the more useful metric because it accounts for voltage. A 10,400 mAh battery at 37 V has 384.8 Wh. A 315 Ah battery at 48 V has 15,120 Wh. Comparing Ah without voltage leads to wrong conclusions.

Charging strategies:

• Opportunity charging: The robot docks at a charging station between tasks. Requires docking stations at strategic locations. Works if duty cycle allows enough charging time.
• Battery swap: The battery is physically replaced in minutes. Requires spare batteries and a swap mechanism. Enables near-continuous operation but adds battery inventory cost.

Power budget for top module: This is critical and often overlooked. Your top module — sensors, arms, conveyors, computing — needs electrical power. The chassis battery must supply this power in addition to propelling the chassis itself.

What buyers must specify:

LFP (lithium iron phosphate) batteries are increasingly common in mobile robots due to better thermal stability and longer cycle life compared to other lithium chemistries. If your application runs multiple shifts, battery chemistry and cycle life directly affect total cost of ownership.

Navigation Stack: Included, Optional or Buyer-Developed

The navigation stack is the software that makes the chassis move autonomously — mapping, localization, path planning, and obstacle avoidance. How much of this comes with the chassis, and how much you need to build, varies widely.

If navigation is included: You get a working AMR. You can send it goals and it will navigate. But you may not be able to modify the navigation algorithms, add custom behaviors, or integrate non-standard sensors.

If navigation is optional: You buy the navigation module separately and configure it. This gives more flexibility but requires in-house expertise to tune parameters, define routes, and handle edge cases.

If you build your own: You get base APIs (motor commands, sensor data) and build the entire navigation stack. This is the highest effort but gives maximum control. Suitable for OEMs building a branded product or research teams developing novel navigation approaches.

What buyers must verify:

• Which tier are you buying?
• If “included,” can you modify navigation parameters, or is it fixed?
• If “optional,” what is the cost of the navigation module?
• If “buyer-developed,” what APIs and documentation are provided?

APIs, SDKs, ROS2 and Low-Level Control Access

“Supports ROS2” is one of the most frequently misleading claims in mobile robot chassis marketing. ROS2 support exists on a spectrum, and knowing where a chassis falls on that spectrum is essential.

API and Access-Level Table

What “supports ROS2” must specify:

1. Which ROS2 distribution? ROS2 has multiple distributions (Foxy, Humble, Iron, Jazzy). They are not all compatible. A chassis that supports Humble may not work with Jazzy. Verify which distribution the chassis supports and whether it matches your development environment.
2. Which drivers are included? “ROS2 drivers” can mean a basic node that publishes odometry, or a complete driver suite for all sensors and motors. Ask for a list of provided drivers and their maturity level.
3. What API access level? Can you publish velocity commands directly to the base controller? Can you access raw sensor data? Can you override the navigation stack’s path planning? Or can you only send high-level goals?
4. Is the navigation stack source available? If you need to modify navigation behavior, you need source access. A binary-only navigation stack cannot be customized beyond its configuration parameters.
5. Security features? SROS2 (Secure ROS2) enhances security via DDS Security. An academic paper (Park et al., IEEE Access 2025) proposes a ROS2Sec module with centralized authentication and group-based access control — this is an academic proposal, not a production standard. SROS2 itself provides DDS Security tooling; centralized authentication is a specific architectural choice that some implementations may offer. If your deployment involves multiple robots, shared networks, or enterprise IT requirements, verify what security features are actually implemented, not just claimed.

Safety I/O and Emergency-Stop Integration

Safety I/O is not the same as standard digital I/O. This distinction is critical for OEM applications where the chassis will be integrated into a larger system with its own safety requirements.

ISO 3691-4:2023 covers safety requirements for driverless industrial trucks, including emergency stop, protective devices, and safety zones. Depending on the final integrated product and intended use, ISO 3691-4 may apply to the completed driverless industrial truck or mobile robot system. A development chassis by itself is not a finished product — its regulatory status depends on what you build with it.

Safety I/O types:

• Emergency stop (E-stop)
• Safety door interlock
• Safety scanner input
• Safety-rated speed monitoring

What makes safety I/O different from standard I/O:

• Safety-rated components must meet specific reliability standards (performance level, safety integrity level).
• E-stop circuits must be safety-rated — a standard digital input is not an acceptable E-stop interface.
• Safety controllers or safety relays are typically required to process safety I/O.
• Safety-rated speed monitoring allows the chassis to reduce speed in defined zones.

What buyers must verify:

A chassis with standard I/O labeled as “E-stop input” is not the same as a chassis with properly rated safety I/O. If your application requires compliance with safety standards, verify the safety architecture, not just the presence of an E-stop connector.

Consider an OEM building a delivery robot for hospital corridors. The chassis spec sheet lists an “E-stop input” on a standard GPIO pin. During safety review, the hospital’s risk assessor asks whether the E-stop circuit is safety-rated (PL d or higher). It is not — it is a standard digital input with no redundancy, no diagnostic coverage, and no safety certification. The OEM now faces a redesign of the safety architecture, a delay of weeks, and the cost of adding a safety relay and dual-channel E-stop circuit.

Expansion for Arms, Cabinets, Conveyors and Sensors

The expansion interface determines what you can mount on the chassis and how it communicates. This is where OEM requirements diverge most from standard AMR deployment.

Mechanical/Electrical/Software Requirements Matrix

ISO 9409-1 standardizes certain mechanical interface dimensions for industrial robot end-effectors. It should not be treated as proof that a robot arm, top module, or tool is mechanically or dynamically compatible with a mobile chassis. If your chassis uses an ISO 9409-1 pattern, it may simplify adapter plate design for off-the-shelf arms and tooling, but you still need to verify payload, stiffness, and dynamic compatibility for your specific configuration.

Top-module integration must consider weight, center of gravity, inertia, power draw, and communication requirements jointly. A top module that is within weight limits but draws more power than the chassis can supply is not a viable configuration.

Lifecycle: Updates, Documentation and Spare Parts

For OEM applications, lifecycle support is as important as the initial specification. A chassis you cannot maintain, update, or get parts for after two years is not a viable platform for a product you intend to sell or deploy long-term.

What to specify in the RFQ:

Documentation requirements for OEM buyers:

• URDF (Unified Robot Description Format) files — needed for simulation
• CAD models — needed for mechanical integration design
• API documentation — needed for software development
• Driver source code — needed if you need to modify or port drivers
• Maintenance manuals — needed for long-term operation

A vendor that provides a PDF spec sheet and a basic API reference is not an OEM platform partner. A vendor that provides URDF, CAD, source code, maintenance manuals, and a documented update roadmap is.

OEM Chassis Evaluation Matrix

Use this matrix to compare chassis platforms side by side.

OEM RFQ Checklist

Before sending an RFQ, prepare these answers:

• Define your top module: weight, CG height, CG offset, power draw, communication requirements
• Define your operating environment: indoor/outdoor, floor conditions, temperature range, humidity
• Define your speed and maneuverability requirements: maximum speed, minimum aisle width, turning requirements
• Define your navigation requirements: which tier, what modification level, what sensors you need to integrate
• Define your ROS2 requirements: which distribution, what access level, what drivers you need
• Define your safety requirements: applicable standards, safety I/O needs, safety controller compatibility
• Define your expansion needs: mechanical pattern, power rails, communication protocols, industrial networks
• Define your lifecycle requirements: documentation needs, spare parts timeline, firmware update expectations
• Request URDF, CAD, API documentation, and driver source code availability
• Request spare parts availability commitment in writing
• Request firmware update policy and backward compatibility statement

Key Takeaways

1. “Open SDK” and “supports ROS2” have widely varying meanings. Verify the ROS2 distribution, driver set, API access level, and navigation stack source availability. Read-only telemetry is not the same as full low-level control.
2. Payload must be evaluated with top-module geometry. Rated payload assumes specific CG conditions. Your actual top module weight, CG height, and CG offset determine the real payload capacity.
3. Navigation stack tier determines development effort. Know whether you are getting a working AMR, a configurable platform, or a base to build on. The effort difference is enormous.
4. Safety I/O is not standard I/O. Safety-rated components, safety controllers, and compliance with ISO 3691-4 are required for industrial deployments. A standard E-stop input is not sufficient.
5. Lifecycle support is critical for OEM products. Documentation, firmware updates, and spare parts availability determine whether you can build and maintain a product on this platform long-term.