Field robotics

Field robotics – definition

Field robotics is a branch of robotics focused on robots that operate outside tightly controlled indoor environments. In practice, this means autonomous or teleoperated systems working in terrain, agriculture, construction sites, inspection zones, mines, forests, or planetary analog environments. The term is used in research and engineering literature for robots that must perceive, localize, plan motion, and execute tasks under changing conditions, partial observability, and limited infrastructure.

In the context of UGV platforms, field robotics usually refers to ground robots that move on soil, gravel, grass, mud, uneven concrete, or mixed terrain. Unlike indoor service robots, field robots cannot assume stable lighting, flat floors, reliable GNSS reception, or obstacle-free operation. They depend on robust sensor fusion, terrain-aware locomotion, fault-tolerant software, and mechanical protection against dust and water. For ROS 2-based systems, field robotics is therefore not one algorithm or one package. It is a system-level discipline that combines perception, state estimation, navigation, communications, power management, and mission execution.

For Fictionlab platforms, field robotics is best understood as the practical use of mobile UGVs such as Leo Rover and Raph Rover in outdoor or semi-outdoor research scenarios. Leo Rover is a compact differential-drive, four-wheel platform with native ROS support on Raspberry Pi-based compute. It is suitable for prototyping perception, teleoperation, and autonomous navigation stacks, but it is not an out-of-the-box autonomous vehicle and requires integration of a localization and navigation pipeline. Raph Rover addresses similar software concepts on a larger platform class, with more payload margin for heavier sensors and compute modules.

Core characteristics of field robotic systems

A field robot is defined less by its shape and more by its operating constraints. In mobile robotics, these constraints directly affect the architecture of the ROS 2 graph, the sensor suite, and the planning stack.

The following properties are typical for field robotics on UGV platforms:

Operation in unstructured or semi-structured environments.
Exposure to weather, dust, vibration, and variable illumination.
Need for multi-sensor localization, often combining wheel odometry, IMU, LiDAR, cameras, and GNSS or RTK GNSS.
Incomplete maps or no prior map at all.
Communication constraints, including low-bandwidth links or intermittent connectivity.
Mission-specific payloads such as multispectral cameras, gas sensors, or inspection sensors.

These factors distinguish field robotics from lab-only autonomy. A robot may run the same ROS 2 middleware and use the same message definitions, but its tuning, reliability strategy, and hardware assumptions are different.

How field robotics is implemented in ROS 2

ROS 2 is commonly used as the integration layer for field robotic UGVs because it supports distributed computation, standard message interfaces, lifecycle-managed nodes, and DDS-based communication. For outdoor robots, the software stack typically combines sensing, state estimation, control, and mission logic.

A minimal field robotics stack on ROS 2 often includes:

sensor_msgs/msg/LaserScan or sensor_msgs/msg/PointCloud2 from LiDAR.
sensor_msgs/msg/Imu from the inertial unit.
nav_msgs/msg/Odometry for wheel odometry and fused state.
geometry_msgs/msg/Twist for velocity control.
tf2 transforms, typically map, odom, base_link, and sensor frames, following REP 105 conventions.
URDF-based robot description according to REP 103 units and coordinate conventions.

Outdoor autonomy on ROS 2 commonly uses Nav2 for navigation, robot_localization for state estimation, and SLAM or localization packages depending on whether a prior map exists. When GNSS is available, the system may fuse absolute position with IMU and wheel odometry. When GNSS is unavailable or unreliable, LiDAR SLAM or visual-inertial odometry becomes more important.

ros2 topic list
ros2 topic hz /scan
ros2 topic echo /odom
ros2 run tf2_ros tf2_echo odom base_link
ros2 lifecycle set /controller_server activate

Sensors and integration patterns

Sensor selection in field robotics is driven by environmental uncertainty. No single sensor is sufficient across all outdoor conditions. Engineers usually design for redundancy and complementary failure modes.

Typical sensor combinations for UGV field deployments include:

Sensor	ROS message type	Role in field robotics	Typical limitation
2D or 3D LiDAR	`sensor_msgs/msg/LaserScan`, `sensor_msgs/msg/PointCloud2`	Obstacle detection, SLAM, local costmaps	Rain, dust, sparse vegetation, reflective surfaces
IMU	`sensor_msgs/msg/Imu`	Attitude, dead reckoning, filter stabilization	Bias drift and vibration sensitivity
RGB-D or stereo camera	`sensor_msgs/msg/Image`, `sensor_msgs/msg/CameraInfo`	Visual odometry, semantic perception	Lighting dependence and motion blur
GNSS / RTK GNSS	often via `sensor_msgs/msg/NavSatFix`	Global positioning in open sky	Multipath, canopy, urban obstruction
Wheel encoders	typically published through `sensor_msgs/msg/JointState` and/or `nav_msgs/msg/Odometry`	Short-term motion estimate	Slip on loose terrain

On Leo Rover, a practical field setup often starts with wheel odometry, IMU, and a compact LiDAR, then adds a depth camera or RTK module depending on the experiment. On Raph Rover, the larger payload budget makes integration of 3D LiDAR, industrial GNSS, or GPU-based perception more realistic.

Key parameters and metrics

Field robotics is evaluated through operational metrics, not only algorithm accuracy. Metrics should be tied to terrain, weather, and mission profile.

Common engineering parameters include:

Localization drift – for example meters per 100 m traveled without absolute correction.
Pose update rate – often 10-100 Hz for odometry and IMU fusion.
Obstacle perception range – dependent on LiDAR or camera specifications.
Control latency – from sensor acquisition to actuator command.
Mission endurance – runtime under payload and terrain load.
Ingress protection and environmental operating limits.

For differential-drive UGVs, odometric motion can be approximated from left and right wheel displacements:

delta_s = (delta_right + delta_left) / 2
delta_theta = (delta_right - delta_left) / wheel_base

In field conditions, these equations remain valid kinematically, but real error grows due to slip, sinkage, wheel deformation, and uneven contact. This is why wheel odometry alone is rarely enough outdoors.

Use cases with Leo Rover and Raph Rover

Leo Rover and Raph Rover fit different scales of field robotics work, but both are relevant in research and applied prototyping. The main distinction is not software compatibility. It is payload, endurance, and terrain margin.

Leo Rover is useful for:

ROS 2 navigation experiments in campus, test track, and light off-road environments.
Education and research on SLAM, waypoint following, and teleoperation.
Sensor fusion pipelines using compact LiDAR, IMU, and camera payloads.
Remote inspection prototypes where size and portability matter.

Raph Rover is better suited to:

Heavier perception stacks with larger batteries and compute modules.
Field inspection missions that require larger payloads or longer runtime.
Agricultural or construction-adjacent R&D where sensor mast stability and ruggedization matter more.

In both cases, autonomous operation requires integration work. A typical deployment includes URDF modeling, calibrated sensor extrinsics, robot_localization configuration, and Nav2 tuning for terrain and braking behavior.

Limitations and trade-offs

Field robotics has no universal stack that works across all environments. Trade-offs are unavoidable. A LiDAR-centric stack can be robust in low light but may degrade in vegetation or dust. Vision stacks provide richer semantics but require more compute and are sensitive to lighting. GNSS improves global consistency but is not reliable under cover or near structures.

For Leo Rover, compute and power budgets are more constrained because the default onboard computer class is Raspberry Pi-based. This makes efficient ROS 2 node design, image compression, and selective offloading important. Raph Rover reduces some payload and compute constraints, but larger systems introduce transport, power, and safety complexity.

Normative references and standards

In ROS-based field robotics, several references are especially relevant. REP 103 defines standard units and coordinate conventions. REP 105 defines coordinate frames for mobile platforms, including base_link, odom, and map. URDF is the standard robot description format used to represent links, joints, and sensor placement in the ROS ecosystem. For navigation, ROS 2 Nav2 documentation defines the expected interfaces for maps, costmaps, planners, controllers, and behavior trees. IEEE literature uses the term field robotics to denote robots deployed in natural or outdoor environments with limited environmental control.

When building a field robotic UGV, these standards matter because interoperability depends on them. Incorrect frame semantics, inconsistent units, or poor timestamp synchronization can make otherwise valid algorithms fail in deployment.