ROS 2 in Gazebo is forgiving. Clocks are perfect, network latency is zero, USB hubs never corrupt camera streams, and the robot never needs a firmware update while someone is watching a demo. Field deployment is none of those things. This article covers the hardware and software stack we use for field robotics projects — the specific choices that have held across multiple deployments — and the failure patterns that we see teams discover by painful experience instead of by reading.
Choosing the compute platform for the field
The board selection for a field robotics system starts with the control loop latency budget, not the benchmark sheet. What is the maximum acceptable latency from sensor input to actuator command? That number, combined with the inference workload and the peripheral requirements, determines the hardware tier — not the other way around.
Raspberry Pi 5 is the default for CPU-bound perception tasks with GPIO-heavy peripheral requirements. The improvement over Pi 4 in single-threaded and multi-threaded performance is significant for real-time control tasks. For anything running ONNX Runtime inference at moderate throughput without GPU requirements, Pi 5 is the cost-effective and well-supported choice.
Jetson Nano is the default when CUDA is required for vision workloads. The TensorRT ecosystem on Nano gives access to well-optimised model runtimes, and the camera interface with CSI is straightforward to configure for standard sensors. The trade-off is higher unit cost and a more constrained peripheral ecosystem.
Banana Pi enters the selection when I/O layout or supplier diversity is a hard requirement. Double Ethernet, SATA storage, or specific PCIe configurations that are unavailable on Pi form factors justify the additional driver bring-up time. We use it in specific contexts, not as a general default.
The field-tested software stack
Embedded Linux base: a minimal, reproducible build — Yocto or a well-locked Debian derivative — with no unnecessary services running. A field robot does not need a desktop environment, a display server, or the standard Raspbian bloat. Every unnecessary process is CPU contention and a potential source of scheduling jitter in the control loop.
ROS 2 Humble on an LTS base. We do not follow the latest ROS 2 release in production field systems. Stability and a predictable support window matter more than access to the newest features. Breaking changes in ROS dependencies have derailed field projects before; pinning to an LTS release eliminates that class of problem.
Camera drivers validated on the exact sensor batch. Not just the sensor model — the specific firmware version on the physical units that will ship. Camera firmware updates between prototype and production have caused unexpected behaviour changes in multiple projects. We validate and lock the camera firmware version as part of the hardware bill-of-materials process.
Motor controllers and actuator interfaces communicate over busses that can be independently scope-tested: CAN, RS-485, or serial with defined framing. This isolation means motor control firmware can be updated and tested without requiring a full perception system rebuild — and vice versa. The decoupling is not elegant for its own sake; it prevents a camera driver issue from blocking a motor control fix.
Real-time configuration and scheduling
Real-time priority tuning is necessary for control-loop threads on Pi hardware. Without explicit priority assignment, the Linux scheduler can preempt the control loop for background I/O tasks and USB events — producing jitter that shows up as mechanical oscillation or missed actuator commands. We set SCHED_FIFO priorities on control-critical threads and validate with latency measurement under representative peripheral load.
DDS configuration for ROS 2 requires tuning in field environments. Default middleware settings work well in simulation and on a local network. In constrained network environments — isolated subnets, wireless with packet loss, multiple robots on the same segment — DDS discovery and QoS settings need explicit configuration. We test the DDS layer in isolation before bringing up the full ROS graph.
Clock synchronisation across distributed nodes is non-optional for multi-robot or sensor-fusion deployments. We use PTP where the hardware supports it and chrony on platforms where it does not. Timestamp errors that are invisible in a single-robot simulation become sensor fusion failures in field deployments with multiple nodes.
Failure patterns we see repeat across projects
Under-powered USB hubs corrupt camera streams in ways that look like model failure. The symptom is intermittent, low-confidence detections that improve when the camera is reconnected or when the robot is stationary. The root cause is bus contention causing partial frame transfers. Always measure bus utilisation under full peripheral load before attributing perception problems to the model.
Default logging fills the disk in a week. ROS 2 logging defaults are set for development, not field operation. A robot running 12 hours a day with default log levels will fill storage within days. Set aggressive log rotation from day one, route important logs to remote storage immediately, and review log volume as part of the integration test suite.
Simulation environment assumptions break on real hardware in predictable ways: perfect timing, zero-loss networking, and uniform lighting conditions. Build hardware-in-the-loop tests early that exercise the real sensor interfaces, real timing constraints, and real environmental variation. The earlier these tests run in the project, the cheaper the fixes they find.
Enclosure design that was not co-developed with the electronics produces thermal surprises in the field. A board that runs at 58C in open air may throttle at 74C in a sealed enclosure in a warm environment. We model and test thermal behaviour in a representative enclosure early — not as a step before shipping, but as a step before finalising the mechanical design.
Shipping, updating, and maintaining field robots
Documentation is a shipping deliverable, not a post-project task. Every field robot ships with: a bill of materials with exact part numbers and firmware versions, a calibration procedure with acceptance criteria, a recovery procedure for the most common failure modes, and a list of known limitations with their operational implications.
OTA update capability is designed in from the first device, not retrofitted when the fleet grows large enough to make manual updates painful. A/B partitions, signed image verification, and rollback on failed boot are the minimum viable OTA stack. Field devices that cannot be updated remotely accumulate security debt and require on-site visits for every firmware fix.
Remote log access and health monitoring replace the assumption that an engineer will be present when something goes wrong. The monitoring stack for field robots mirrors the server stack: heartbeat, resource utilisation, inference throughput, and a structured log stream. When a field device behaves unexpectedly, the first investigation step should be reading logs from the office, not driving to the site.
