Robotics & ROS 2
Admiral runs the full software stack of Autonomous Mobile Robots (AMRs), Automated Guided Vehicles (AGVs), unmanned submersibles (AUVs/ROVs), robotic manipulators, and physical AI perception nodes. A ROS 2 stack usually moves over unchanged: package it as one OCI image, start it with your normal launch file, and set the options below.
This page is the ROS 2 checklist. The details of each option live on the pages it links to.
Recommended Configuration
| Setting | Value | Why |
|---|---|---|
Host Network (hostNetwork: true) | On | DDS multicast discovery, SocketCAN, and off-board tools such as RViz2 and Foxglove. See ROS 2 DDS Discovery. |
Device Isolation (isolateDevices) | Off (the default) | The full /dev tree with hotplug: serial, CAN, cameras, LiDAR, GPU. See Hardware Access. |
/dev/shm | Default, or a tmpfs System Mount with an explicit size= | Zero-copy loaned messages (FastDDS SHM, Iceoryx). See Shared Memory. |
| Custom Volumes | For maps, calibration, and ros2 bag recordings | The workload's root filesystem is recreated on every image update. See Custom Volumes. |
Real-time priorities (SCHED_FIFO / SCHED_RR) and memory locking work without extra settings; see Real-Time Scheduling.
One Workload per Robot
Admiral runs one primary workload per machine, which matches how robot software is usually started: a master launch file (ros2 launch robot_bringup bringup.launch.py) or composable node containers (rclcpp_components). The image is a full userspace, so supporting daemons can run beside your nodes under the same entrypoint (see the multi-service pattern).
Robot Peripherals
With device isolation off, each subsystem is available at its usual Linux node:
| Subsystem | Linux Node | Consumption in ROS / ROS 2 |
|---|---|---|
| Motor Controllers / IMUs | /dev/ttyUSB*, /dev/ttyACM* | Serial drivers, micro-ros-agent, or Roboteq/Odrive motor controller nodes. |
| CAN Bus Actuators | can0, can1 (SocketCAN) | Industrial servos, steer-by-wire steering columns, and smart BMS batteries via standard Linux SocketCAN. |
| RGB-D Cameras & LiDAR | /dev/video*, /dev/bus/usb | Intel RealSense, Luxonis OAK-D, and USB LiDARs upload firmware and stream point clouds directly. |
| Physical E-Stop & Bumpers | /dev/input/event* | Hardware emergency stop buttons and bumper microswitches feed into safety supervisor nodes. |
| AI Perception Accelerators | /dev/nvidia* (x86), NVGPU nodes (Jetson Orin), /dev/rknpu | Host driver mapping for NVIDIA CUDA/TensorRT and Rockchip NPU. Jetson Orin CUDA is a developer preview; see the Orin CUDA guide. |
Updating Robots Safely
- Schedule rollouts for when robots are docked or charging with Maintenance Windows.
- Send a new navigation or perception build to one canary robot first; the rest of the fleet waits, and the rollout pauses itself if failures exceed its budget. See Rollout Strategy.
- A new configuration runs on probation, and the robot returns to the previous one on its own if it keeps failing, with no cloud connection needed. See Automatic Workload Rollback.
Related
- Platform Boundary & Customisation: what stays in your image and what the platform owns (Wi-Fi, reboots, kernel patches, real-time kernels).
- GPU & NPU Acceleration and Jetson Orin CUDA for perception workloads.
- Admiral on Unitree Robots for the Unitree G1.