Simplify AMR and AGV Integration with ROS 2 Components

Autonomous mobile robots (AMRs) and automated guided vehicles (AGVs) require tight coordination across multiple subsystems, including sensors, motors, navigation, and artificial intelligence (AI)-based decision-making. Integrating all of these subsystems is challenging for developers.

The Robot Operating System (ROS) offers a path through this complexity. ROS is open-source robotics middleware that provides standardized communication frameworks and a large ecosystem of reusable packages. By selecting components with native ROS support, designers can use pre-built hardware modules with software-addressable functionality, reducing bring-up time and improving interoperability.

This article briefly reviews the challenges designers of AMRs and AGVs face and how ROS can help. It then introduces ROS-compatible hardware from Analog Devices (ADI), including motor controllers, inertial measurement units (IMUs), and time-of-flight (ToF) sensors, and explains how these components integrate with the ROS software stack to accelerate product development.

The integration challenge for AMRs and AGVs

Integration work can dominate the early schedule in an AMR or AGV design. At the hardware layer, teams must select components, design interfaces, and validate signal integrity and timing. At the software layer, they must load drivers, define data flows, and ensure the system behaves predictably in real-world conditions.

Talented teams can meet these goals with in-house designs, but doing so often means recreating off-the-shelf capabilities. This effort can be difficult to justify, particularly when traditional approaches can lock teams into proprietary interfaces. When requirements evolve, replacing a component may necessitate reworking substantial portions of the software stack.

How ROS addresses integration challenges

ROS was created to address these issues. Despite its name, ROS is not an operating system in the classical sense. Instead, it is an open-source framework that offers a broad set of tools, libraries, and conventions.

The key concept of ROS is structuring complex robotics applications into modular nodes (Figure 1). These bite-sized processes perform specific tasks, such as reading sensor data or controlling motor speed.

Figure 1: The basic building blocks of ROS include packages, nodes, messages, and services. (Image source: Analog Devices, modified by Kenton Williston)

Nodes communicate through two main mechanisms:

• Topics: A publisher-subscriber model suitable for continuous data streaming, such as sensor feeds
• Services: A request-response model, best for infrequent actions, such as device configuration and initialization

Multiple nodes and their dependencies (including associated topics and services) can be combined into a package to provide more comprehensive functionality. For example, Analog Devices has created ROS driver packages for its sensor and actuator modules designed for AGVs and AMRs. These packages encapsulate the nodes, message definitions, and configuration files needed to integrate the hardware into a ROS-based system.

How ROS streamlines AMR and AGV design

This modular architecture enables interoperability and accelerates development. At the hardware layer, ROS provides standardized interfaces for components such as cameras and motor controllers. This speeds up integration while freeing designers from vendor lock-in and licensing fees.

At the software layer, ROS offers tools and middleware that help designers develop, test, deploy, and maintain complex robots. The current version of the framework, ROS 2, provides features particularly useful for AMRs and AGVs. These include:

• The Nav2 navigation stack, which supports behavior trees, keep-out zones, speed limits, and more
• Sophisticated positioning algorithms, including mapping and localization tools that enable AMRs and AGVs to understand their environment
• Integration with simulation, visualization, and logging tools that aid both development and diagnostics

ROS 2 typically runs on a Linux-based computer, although other OSs are supported. ROS 2 also supports micro-ROS, a variant that runs natively on microcontroller units (MCUs) with real-time operating systems (RTOSs), such as Zephyr and FreeRTOS.

Motor control with ROS 2 integration

To illustrate the potential of ROS 2, consider the complexities of drive control. Most AMRs and AGVs use a differential drive configuration, where two independently controlled sets of wheels enable both forward motion and turning. This architecture requires a motor controller capable of driving both wheels simultaneously while accepting coordinated commands from the navigation system.

The TMCM-2611-AGV from ADI (Figure 2) directly addresses this need. Part of the Trinamic Motor Controller Module (TMCM) family, this board is a dual-axis servo-drive platform for three-phase brushless DC (BLDC) motors, designed for AGV and AMR traction applications. Each axis can drive motors up to 14 amperes (A) RMS at 48 volts, with position feedback via incremental quadrature encoders or digital Hall-effect sensors.

Figure 2: The TMCM-2611-AGV is a dual-axis controller/driver for three-phase BLDC motors. (Image source: Analog Devices)

The adi_tmcl ROS 2 driver connects this hardware to the ROS 2 ecosystem primarily through topics (Figure 3). For example, a navigation stack can publish velocity commands to each set of wheels through the /cmd_vel_X topics. The adi_tmcl driver subscribes to these topics, translates commands into Trinamic Motion Control Language (TMCL) frames, and sends them over CAN bus via the Linux-native SocketCAN interface.

Figure 3: The TMCL ROS2 driver package incorporates a robust set of interfaces. (Image source: Analog Devices)

In the other direction, the adi_tmcl driver publishes motor feedback to /tmc_info_X topics, providing velocity, position, torque, and status information. Other nodes can subscribe to this data for odometry calculation, diagnostics, or closed-loop control at the application level.

This bidirectional flow illustrates how ROS 2 enables modular system design. The navigation algorithm does not need to know anything about TMCL or CAN bus; it simply publishes standard velocity messages and receives feedback.

The adi_tmcl driver also uses services for tasks such as initialization and parameter access. For example, /tmcl_gap_all retrieves all axis parameter values, and /tmcl_ggp_all retrieves all global parameter values for the controller board.

Inertial measurement for position tracking

Although wheel encoders enable a system to estimate position based on wheel travel, wheel odometry alone is often insufficient for accurate position tracking. Wheel slip and uneven surfaces can introduce significant errors over time. This is a particular concern in the many indoor environments where GPS signals are unreliable and cannot provide ongoing corrections.

IMUs provide an independent motion reference that AMRs and AGVs can use to improve dead-reckoning accuracy. A prime example is the ADIS16500/05/07 family, which offers six-degrees-of-freedom precision inertial sensing via triaxial gyroscopes and triaxial accelerometers, all in a 15 × 15 × 5 millimeter (mm) BGA package. Factory calibration characterizes each sensor for sensitivity, bias, alignment, and temperature compensation, reducing the integration burden on system designers.

A representative example is the ADIS16500AMLZ (Figure 4). This part has a ±2000° per second (˚/s) gyroscope range, a gyroscope in-run bias stability of 8.1° per hour (˚/hr), and an angular random walk of 0.29° per root-hour (°/√hr). These specifications help reduce drift over time, improving dead-reckoning performance between external corrections.

Figure 4: The ADIS16500AMLZ is a precision MEMS IMU in a compact BGA package. (Image source: Analog Devices)

For ROS 2 integration, the ADIS16500/05/07 family is supported by the imu_ros2 driver. The driver leverages the Linux Industrial I/O subsystem via LibIIO. Its output is compatible with common ROS 2 sensor fusion packages such as robot_localization, which implement Extended Kalman Filters to combine IMU and odometry data.

Designers interested in experimenting with the IMU can start with the ADIS16500/PCBZ evaluation board (Figure 5). This board exposes the IMU’s SPI interface via a 16-pin header that is compatible with standard 2 mm-pitch ribbon cables.

Figure 5: The ADIS16500/PCBZ eval board exposes the SPI interface via a 16-pin header. (Image source: Analog Devices)

Depth sensing for obstacle detection

Obstacle detection is another standard AMR/AGV feature. While LiDAR excels at detecting obstacles at longer ranges, many applications also require near-field sensing to detect low-lying obstacles, floor discontinuities, or objects that fall outside the LiDAR’s scan plane. ToF depth cameras address this gap by providing dense depth images across a wide field of view.

The ADTF3175BMLZ ToF module (Figure 6) is an excellent fit for these requirements. Combining a CMOS depth sensor with illumination optics, the module captures depth and active brightness (AB) frames up to 1024 × 1024 resolution with a 75˚ × 75° field of view. This combination of resolution and coverage makes it well-suited for safety zone monitoring and floor detection in warehouse and manufacturing environments where obstacles may appear at varying heights.

Figure 6: The ADTF3175BMLZ ToF module integrates a CMOS depth sensor with illumination optics. (Image source: Analog Devices)

The adi_3dtof_adtf31xx driver makes it easy to access the camera data by publishing depth and AB frames using standard ROS 2 message formats. These outputs integrate directly with common perception packages for tasks such as point cloud generation, floor detection, and safety bubble monitoring. The driver also supports a file playback mode, allowing algorithm development and testing without a physical hardware connection.

For development and prototyping, the EVAL-ADTF3175D-NXZ kit (Figure 7) provides a complete sensor platform. The most notable feature of the kit is an Arm®-based board running Linux, which can directly host the ROS 2 node. Alternatively, the sensor can stream depth data over Ethernet to a separate ROS 2 host, providing flexibility across different system architectures.

Figure 7: The EVAL-ADTF3175D-NXZ eval kit includes an Arm-based Linux host. (Image source: Analog Devices)

The Analog Devices Autonomous Mobot (ADAM) reference platform demonstrates how these ROS-compatible components integrate with additional solutions for battery management, power conversion, and communications to form a complete AMR system.

Conclusion

The complexity of AMR and AGV design and development can be greatly reduced by selecting ROS-compatible components. Using a proven component source such as ADI, which provides ROS 2 drivers for a wide range of sensors and actuators and can be a valuable partner.