Glossary

Fictionlab > Glossary > Field testing

Field testing

Field testing – definition

Field testing is the controlled evaluation of a mobile robot in its intended or representative operating environment. For an unmanned ground vehicle (UGV), it verifies whether the complete system performs within defined requirements outside laboratory conditions. The tested system includes the vehicle base, compute unit, sensors, power system, ROS 2 nodes, network links, autonomy software, and safety procedures.

Field testing differs from simulation, bench testing, and indoor validation. Simulation evaluates models and algorithms under defined assumptions. Bench testing validates individual components or interfaces. Field testing exposes the integrated robot to environmental variables such as uneven terrain, wheel slip, changing illumination, dust, vibration, GNSS obstruction, and wireless interference.

For Leo Rover and Raph Rover, field testing is typically used to validate teleoperation, sensor integration, autonomous navigation, mapping, perception, payload operation, and operational limits. It is not evidence that a rover is autonomous by default. Leo Rover requires an integrated navigation and perception stack before autonomous operation can be evaluated.

Scope of a UGV field test

A field test should begin with measurable acceptance criteria. Requirements must be connected to a specific mission, terrain type, payload, software revision, and environmental condition. Results from one location cannot be assumed to apply to substantially different terrain, weather, or sensor configurations.

A practical field-test plan usually defines the following elements.

  • Test objective: for example, validate waypoint navigation on compact soil, inspect a construction area, or collect georeferenced camera data.
  • Test configuration: rover model, wheel configuration, payload mass, battery state, ROS 2 distribution, operating system, node versions, and parameter files.
  • Environmental conditions: terrain surface, slope, temperature, rain exposure, ambient light, vegetation density, dust, and GNSS visibility.
  • Test procedure: route, start and stop conditions, operator actions, emergency-stop procedure, number of repetitions, and pass/fail thresholds.
  • Recorded evidence: ROS 2 bag files, node logs, video, photographs, GNSS reference data, battery measurements, and incident reports.

Configuration control is important. A field result is only reproducible when the recorded data identifies the software commit, container image, ROS parameters, sensor firmware, calibration files, and physical payload arrangement.

Field testing in ROS 2

ROS 2 supports repeatable field-data collection through topic recording, parameter files, diagnostics, transforms, and launch descriptions. A common workflow records sensor data and robot state during the mission, then replays the dataset offline to investigate failures without repeating the entire test.

For a differential-drive UGV, the minimum recorded interfaces often include odometry, transforms, command velocity, IMU data, laser scans or point clouds, camera streams, navigation status, and diagnostics.

ros2 bag record \
  /tf /tf_static \
  /odom /cmd_vel \
  /imu/data \
  /scan \
  /camera/color/image_raw \
  /camera/depth/image_rect_raw \
  /diagnostics \
  /battery_state

The exact topic names and message types depend on the integration. Typical message types are nav_msgs/msg/Odometry, sensor_msgs/msg/Imu, sensor_msgs/msg/LaserScan, sensor_msgs/msg/Image, and sensor_msgs/msg/BatteryState. Message definitions are maintained in the ROS 2 interface packages.

Time synchronization is a field-test requirement, not only a logging detail. Sensor fusion becomes unreliable if LiDAR, camera, IMU, wheel odometry, and GNSS observations use inconsistent timestamps. Timestamps should be traceable to a common time base, and ROS 2 nodes should be configured consistently with the selected clock source. Recorded timestamps should be checked for gaps, delays, or clock resets.

Reference frames and coordinate conventions

Field data must use consistent coordinate frames. REP 103 defines standard units and coordinate conventions for ROS, including SI units, radians for angular quantities, and right-handed coordinate frames. REP 105 defines common mobile-platform frames such as map, odom, and base_link.

For a rover navigation test, the transform chain is commonly structured as follows.

map -> odom -> base_link -> sensor_frame

The odom frame provides locally continuous motion estimation but can drift. The map frame is a world-fixed reference that may be produced by SLAM or used by a localization system. A field test should verify that transforms are available throughout the mission and that sensor mounting is represented by fixed transforms in the TF tree, often generated from the URDF.

Key metrics for Leo Rover and Raph Rover

Metrics should be selected according to the mission. A mapping experiment needs different evidence than an inspection route or a teleoperated outdoor survey. The following metrics are commonly useful for mobile UGV validation.

Metric Example measurement Field-test relevance
Mission completion rate Completed runs / attempted runs Measures repeatability of a defined route or task.
Cross-track error Distance between planned path and measured trajectory Evaluates path-following accuracy.
Localization error Estimated pose compared with surveyed or RTK reference pose Validates SLAM, AMCL, or GNSS-based localization.
Obstacle detection latency Time from observation to planner or safety response Evaluates perception and navigation pipeline timing.
Power consumption Battery voltage, current, runtime, and payload state Identifies mission-duration limits under actual terrain load.
ROS 2 data integrity Dropped messages, bag gaps, diagnostic errors, CPU load Shows whether compute and communication capacity are sufficient.

For localization, position error can be expressed as Euclidean distance between an estimated position and a reference position:

e = sqrt((x_est - x_ref)^2 + (y_est - y_ref)^2)

Leo Rover uses a four-wheel differential-drive base and an onboard Raspberry Pi compute unit. Field tests should therefore account for available compute capacity when processing depth images, point clouds, visual odometry, or neural-network perception. Its IP55 rating is relevant to ingress protection, but it does not replace a test procedure for heavy rain, water immersion, or conditions outside the platform specification. Raph Rover can carry larger payloads, but added mass, sensor placement, and power demand must be documented for each test configuration.

Safety and operational controls

Field testing requires a defined safety boundary and a recovery procedure. Before autonomous motion, operators should verify stop behavior, communication-loss handling, maximum permitted speed, obstacle clearance, and manual takeover. The test area should exclude uninvolved persons and property that could be affected by rover motion.

ISO 12100:2010 provides a general framework for risk assessment and risk reduction for machinery. It does not define a complete UGV field-test procedure, but its hazard-identification approach is applicable when documenting motion, electrical, battery, terrain, and payload risks.

Normative references and technical sources

The following sources define the conventions and interfaces most often used when preparing ROS-based UGV field tests.

See also