AMR (Autonomous Mobile Robot)

AMR – definition

An Autonomous Mobile Robot (AMR) is a mobile robot that estimates its own position, perceives relevant features or obstacles in its environment, plans motion, and executes movement without following a fixed physical guide path. In mobile robotics, an AMR is commonly implemented as a wheeled unmanned ground vehicle (UGV) with onboard computing, drive control, sensors, and autonomy software.

An AMR differs from a conventional automated guided vehicle (AGV). An AGV typically depends on predefined infrastructure such as magnetic tape, wires, reflectors, or fixed markers. An AMR can use sensor-based localization and navigation methods, including LiDAR SLAM, visual odometry, wheel odometry, IMU fusion, GNSS, or RTK GNSS. The level of autonomy depends on the installed sensors, software stack, operational environment, and safety design.

For Leo Rover and Raph Rover, AMR describes a complete integrated system rather than the base platform alone. Both platforms can serve as UGV bases for AMR research and engineering. They become autonomous only after integration of perception sensors, localization, mapping, path planning, motion control, and operational safety functions.

AMR architecture on a mobile UGV

A practical AMR stack separates hardware control from navigation and perception. ROS 2 provides a middleware-based architecture for exchanging sensor data, robot state, transforms, and navigation commands between these layers.

On a differential-drive UGV such as Leo Rover, the typical data flow includes the following components:

Base driver: publishes wheel odometry and accepts velocity commands.
State estimation: fuses wheel odometry, IMU data, and optionally GNSS data.
Perception: processes LiDAR scans, depth images, point clouds, or camera images.
Localization: estimates the robot pose in a map or global coordinate frame.
Navigation: plans a route and generates collision-aware velocity commands.
Safety layer: limits movement when obstacle, communication, battery, or sensor conditions exceed configured limits.

In ROS 2, the navigation stack commonly uses the transform tree defined by REP 105. For a ground robot, the relevant coordinate frames are usually map, odom, base_link, and sensor frames such as laser or camera_link. Coordinate-axis conventions should follow REP 103.

Function	Typical ROS 2 interface	Purpose in an AMR
Velocity control	`geometry_msgs/msg/Twist` on `/cmd_vel`	Commands linear and angular velocity to the base controller.
Wheel odometry	`nav_msgs/msg/Odometry` on `/odom`	Provides local motion estimation from wheel encoders.
2D LiDAR	`sensor_msgs/msg/LaserScan` on `/scan`	Supports mapping, localization, and obstacle detection.
IMU	`sensor_msgs/msg/Imu` on `/imu/data`	Measures angular velocity and acceleration, and may provide an orientation estimate.
Navigation goal	`nav2_msgs/action/NavigateToPose`	Requests autonomous travel to a target pose.

How an AMR works in ROS 2

ROS 2 Humble or later can run an AMR stack on Leo Rover when the compute unit has sufficient resources for the selected sensors and algorithms. Leo Rover includes a Raspberry Pi-based compute unit by default and supports ROS 2 natively. More computationally demanding perception pipelines, such as dense depth processing or neural-network inference, may require an external computer or an embedded GPU platform.

The ROS 2 Navigation2 project, usually called Nav2, is the standard navigation framework used in many ROS 2 AMR implementations. Nav2 combines planners, controllers, costmaps, behavior trees, recovery behaviors, and lifecycle-managed nodes. Its architecture is documented in the official Nav2 documentation.

ros2 launch nav2_bringup bringup_launch.py \
  use_sim_time:=false \
  map:=/home/robot/maps/lab_map.yaml

For autonomous navigation, Nav2 requires a valid transform chain, a robot footprint, an obstacle source, and a localization source. A static map is commonly used with Adaptive Monte Carlo Localization (AMCL). A robot operating in an unmapped environment can first create a map with a ROS 2 SLAM package, then use that map for later localization.

Key AMR parameters and metrics

AMR performance should be evaluated using measurable properties rather than a general claim of autonomy. The relevant values depend on terrain, wheel slip, payload, sensor placement, lighting, map quality, and compute latency.

Localization error: difference between estimated and reference pose, expressed in metres and degrees.
Obstacle detection range: usable distance at which a sensor detects an object with sufficient reliability for the configured stopping strategy.
Control latency: time between sensor observation, planning, command publication, and vehicle response.
Path-tracking error: lateral and heading deviation between commanded and actual trajectory.
Map resolution: grid-cell size used by a 2D occupancy map, expressed in metres per cell.
Traversability: ability to maintain localization and controlled motion on surfaces with slope, slip, loose material, or uneven geometry.

For a differential-drive robot, the commanded planar velocity is normally represented as:

v = linear velocity [m/s]
ω = angular velocity [rad/s]

The base controller converts v and ω into left and right wheel velocities according to wheel radius and wheel separation. Incorrect kinematic parameters create odometry drift and degrade AMR localization.

AMR use with Leo Rover and Raph Rover

Leo Rover is suitable for laboratory, education, and research implementations of an AMR. Its four-wheel differential-drive configuration can be integrated with a 2D LiDAR, IMU, depth camera, GNSS receiver, or additional onboard computer. Its IP55 enclosure rating may be relevant for controlled outdoor experiments, but it does not replace environmental validation of installed payloads, connectors, and sensor windows.

Raph Rover is a larger UGV platform intended for applications that require higher payload capacity. It can be used where the AMR sensor suite includes heavier computers, multiple LiDAR units, GNSS/RTK equipment, inspection payloads, or specialized field instrumentation. Raph Rover is not a replacement for Leo Rover in compact laboratory or education scenarios.

Neither platform is an autonomous vehicle out of the box. A complete AMR implementation requires configuration and validation of the navigation stack, drivetrain limits, emergency-stop strategy, obstacle detection coverage, localization accuracy, and mission-specific operating constraints.

Standards and technical references

AMR terminology and safety requirements vary by industry and jurisdiction. The following documents are useful references, but compliance must be assessed against the intended application and deployment environment.

ISO 3691-4:2020 – industrial trucks and driverless industrial trucks, including automated functions and safety requirements.
ANSI/RIA R15.08-1-2020 – industrial mobile robot safety requirements in the United States.
ROS REP 103 – standard units and coordinate conventions.
ROS REP 105 – coordinate frames for mobile platforms.
ROS 2 Humble documentation – official ROS 2 APIs, middleware concepts, and package documentation.