Embodied AI

Embodied AI – definition

Embodied AI is an approach to artificial intelligence in which an agent perceives, decides and acts through a physical body operating in a real environment, or through a simulated embodiment in a virtual environment. In mobile robotics, the body is a mobile platform with sensors, actuators, compute hardware, power constraints and motion limits. The agent does not only process data. It must relate perception to the robot’s position, movement and possible actions.

For an unmanned ground vehicle (UGV), Embodied AI connects perception, state estimation, planning and control in a closed loop. A camera image, LiDAR scan, IMU measurement or GNSS/RTK position is useful only when it is associated with coordinate frames, timestamps and the current motion of the platform. The resulting system can estimate where the rover is, identify traversable space, select a path and send velocity commands to the drivetrain.

Embodied AI is not a separate ROS 2 package or an IEEE software standard. It is a system-level concept. In ROS 2, it is implemented through interoperable nodes, messages, transforms and control interfaces. On a Leo Rover or Raph Rover, the physical embodiment is especially relevant because wheel slip, uneven terrain, sensor placement, payload mass and compute latency directly affect the behaviour of the AI pipeline.

Embodied AI in a mobile UGV control loop

A practical Embodied AI system for a ground rover requires a continuous feedback loop. Perception provides observations of the environment. State estimation combines observations with odometry. A planner generates feasible motion commands. The rover executes those commands and produces new sensor data.

In ROS 2, this loop is commonly represented by the following functional layers:

Perception: LiDAR, depth camera, RGB camera, GNSS receiver and wheel encoders publish environment and motion observations.
State estimation: odometry, IMU and GNSS data are fused into a pose estimate, often using robot_localization.
Spatial representation: sensor data is transformed into local or global costmaps, point clouds, occupancy grids or semantic maps.
Planning: a navigation stack evaluates a global route and a local collision-free trajectory.
Control: the controller publishes velocity commands, usually as geometry_msgs/msg/Twist or geometry_msgs/msg/TwistStamped.
Safety and supervision: watchdogs, emergency stop logic, diagnostics and lifecycle state handling constrain autonomous operation.

The main ROS 2 coordinate-frame convention is defined by REP 103. Mobile robots commonly use map, odom and base_link frames. Their intended semantics for navigation are further described in REP 105. A navigation system becomes unreliable when sensor messages, transforms and odometry are not time-consistent.

ROS 2 interfaces used by Embodied AI systems

ROS 2 provides standard message definitions and middleware-based communication for distributed robotic systems. The interface design matters because an AI model must receive sensor data with known frame identifiers and timestamps, while control nodes must expose predictable command and status interfaces.

Function	Typical ROS 2 interface	Role in embodied operation
Laser ranging	`sensor_msgs/msg/LaserScan`	Obstacle detection, scan matching and local costmaps.
Depth perception	`sensor_msgs/msg/Image`, `sensor_msgs/msg/PointCloud2`	Terrain geometry, object detection and free-space estimation.
Inertial sensing	`sensor_msgs/msg/Imu`	Angular velocity, orientation and acceleration observations.
Satellite positioning	`sensor_msgs/msg/NavSatFix`	Global position input for outdoor localization.
Motion command	`geometry_msgs/msg/Twist`	Linear and angular velocity request for a differential-drive or skid-steer base.
Robot geometry	`tf2` transforms and URDF	Sensor extrinsics, kinematic relations and frame conversion.

Message definitions are maintained in the ROS 2 interface packages, including sensor_msgs and geometry_msgs. For UGV integration, each sensor driver should publish a valid header.stamp and header.frame_id. Missing or incorrect transform data can cause map distortion, unstable localization or false obstacle positions.

Embodied AI on Leo Rover and Raph Rover

Leo Rover is a four-wheel, skid-steer mobile platform with an IP55 enclosure and an integrated Raspberry Pi compute unit. It supports ROS 2, including the Humble distribution. It is suitable for laboratory experiments, education, indoor mapping and moderate outdoor research tasks where sensor payload and compute demand remain within the selected configuration.

On Leo Rover, an Embodied AI stack typically starts with base odometry, IMU data and a robot description. A LiDAR or depth camera can provide obstacle observations, while a camera-based model can add semantic information such as terrain class, markers or selected objects. The platform is not autonomous out of the box. Autonomous behaviour requires integration, calibration and validation of a navigation and safety stack.

Raph Rover is the larger platform for projects requiring greater payload capacity. It can carry more extensive sensor assemblies, protected compute hardware or research instrumentation. This makes it appropriate for field data collection, agricultural sensing, construction-site inspection and outdoor localization experiments. It does not replace Leo Rover in laboratory and educational use cases where a smaller platform is more appropriate.

# Inspect the core interfaces of an embodied UGV system
ros2 topic list
ros2 topic echo /imu/data
ros2 topic echo /scan
ros2 run tf2_ros tf2_echo odom base_link
ros2 lifecycle nodes

Key engineering constraints

Embodied AI performance is constrained by the physical system, not only by model accuracy. A perception model may classify terrain correctly but still produce unsafe behaviour if the rover pose is delayed, wheel odometry drifts or the controller receives stale commands.

Before deploying an autonomous function, an integrator should verify the following engineering conditions:

Sensor extrinsics are represented in URDF or published through tf2.
All sensor clocks and ROS 2 timestamps are consistent enough for fusion.
The robot footprint and collision geometry match the physical rover and mounted payload.
Wheel odometry is validated against real motion, especially on loose or uneven ground.
Compute load does not delay perception, localization or command delivery.
Navigation failure states produce a safe stop or supervised recovery action.

For ROS 2 navigation, the Nav2 documentation describes behavior-tree-based navigation, costmaps, planners, controllers and lifecycle-managed nodes. For sensor fusion, the robot_localization documentation specifies supported filter configurations and ROS message inputs. Leo Rover platform-specific interfaces and configuration details should be checked against the current Leo Rover documentation.