Glossary

Fictionlab > Glossary > Proof of Concept (PoC)

Proof of Concept (PoC)

Proof of Concept (PoC) – definition

A Proof of Concept (PoC) is a bounded technical experiment that verifies whether a proposed robotic capability is feasible under defined conditions. In mobile robotics, a PoC does not prove that a UGV is production-ready. It produces evidence that selected hardware, software, interfaces, and algorithms can achieve a stated technical objective.

For a ROS 2-based UGV, a PoC may verify that a LiDAR can provide usable sensor_msgs/msg/LaserScan data, that wheel odometry and IMU measurements can be fused into a stable odom transform, or that Nav2 can send velocity commands to a differential-drive base. The output should be reproducible measurements, logs, configuration files, and clearly defined acceptance criteria.

PoC is not a normative ROS term. It is commonly used within systems engineering and research projects as an early feasibility activity. Requirements and verification should be traceable, consistent with the requirements-engineering principles described in ISO/IEC/IEEE 29148:2018 and the system life-cycle processes described in ISO/IEC/IEEE 15288:2023.

What a robotics PoC verifies

A useful PoC starts with one or more falsifiable hypotheses. The scope must be narrower than a complete autonomous-robot project. For example, “the rover can autonomously inspect an entire construction site” is a project goal. “The localization stack maintains a valid map → odom → base_link transform while the rover follows a mapped indoor route” is a testable PoC hypothesis.

For mobile UGV platforms, the scope often includes the following technical layers:

  • Hardware compatibility: electrical power, mechanical mounting, USB, Ethernet, CAN, serial interfaces, and compute capacity.
  • Driver operation: sensor data availability, timestamp quality, frame identifiers, diagnostics, and ROS 2 lifecycle behavior where applicable.
  • State estimation: wheel encoders, IMU, GNSS, RTK, visual odometry, or LiDAR odometry fused into a consistent robot pose estimate.
  • Perception: obstacle detection, point-cloud filtering, image processing, semantic detection, or terrain assessment.
  • Navigation: localization, costmaps, path planning, velocity control, recovery behavior, and safe stop conditions.
  • Operational repeatability: deployment from documented source code, containers, launch files, and parameter sets.

A PoC should distinguish feasibility from performance qualification. A system may demonstrate that a sensor driver works while still failing requirements for latency, localization drift, environmental robustness, or continuous operation.

PoC architecture in ROS 2

ROS 2 provides the middleware and message model for connecting a PoC stack. A minimal autonomous-navigation experiment normally separates sensor drivers, state estimation, transform publication, mapping or localization, navigation, and base control into independent nodes.

The coordinate-frame structure should follow REP 105. In a typical UGV configuration, base_link represents the robot body frame, odom provides locally continuous odometry, and map provides a globally consistent frame. Axis orientation and units should follow REP 103, including SI units and right-handed coordinate conventions.

PoC function Typical ROS 2 interface Evidence to record
2D LiDAR acquisition sensor_msgs/msg/LaserScan Bag file, frame ID, timestamps, scan continuity
Inertial measurement sensor_msgs/msg/Imu Orientation convention, covariance fields, bias behaviour
Wheel odometry nav_msgs/msg/Odometry Pose drift, twist consistency, encoder dropouts
Robot transforms tf2_msgs/msg/TFMessage Transform-tree validity and lookup failures
Base command geometry_msgs/msg/Twist Command-to-motion delay and stop response

Message definitions are maintained in the official ROS 2 interface packages, including sensor_msgs, nav_msgs, and geometry_msgs.

Acceptance criteria and measurable outputs

Acceptance criteria convert a PoC from a demonstration into an engineering test. Each criterion should specify a test environment, input conditions, an observed output, a threshold, and a method for collecting evidence. Thresholds are project-specific and should be derived from the intended field task rather than copied from another robot.

A mobile-robotics PoC can measure the following attributes:

  • Availability of required ROS 2 topics, services, actions, and transforms.
  • Message frequency, timestamp monotonicity, dropped-message rate, and end-to-end latency.
  • Localization error relative to surveyed markers, motion-capture data, or a manually measured reference path.
  • Map consistency, loop-closure behaviour, and recovery after temporary sensor occlusion.
  • Navigation completion rate, path deviation, obstacle response, and safe-stop behaviour.
  • CPU, memory, storage, network, and power consumption during a repeatable mission.

ROS 2 Quality of Service settings are part of the test configuration. Reliability, durability, history, and deadline policies can affect whether sensor and control nodes communicate as intended. The available QoS policies are defined in the ROS 2 QoS documentation. A PoC report should record the selected profile rather than assuming default settings are suitable for all sensor streams.

PoC example with Leo Rover and Raph Rover

Leo Rover is appropriate for a compact ROS 2 feasibility experiment involving differential-drive motion, indoor mapping, educational research, or sensor integration. It uses an onboard Raspberry Pi compute unit, has four-wheel differential drive, and is rated IP55. ROS 2 Humble is documented as a supported ROS 2 distribution. These platform characteristics are documented in the Leo Rover technical documentation.

A practical Leo Rover PoC can validate a 2D LiDAR and IMU integration before a larger autonomy project. The experiment may record LiDAR scans, wheel odometry, IMU data, and TF transforms while the rover drives a repeatable route. The result is sufficient to determine whether the selected sensor placement, calibration, ROS 2 driver, and localization method are viable. It does not establish that Leo Rover is autonomous out of the box. A navigation stack, sensor integration, maps, safety logic, and validation remain necessary.

Raph Rover is suited to PoCs that require a larger chassis or higher payload capacity, such as multi-sensor mapping payloads, outdoor GNSS/RTK integration, or rugged inspection instrumentation. It should not be treated as a replacement for Leo Rover in compact laboratory and educational experiments. The PoC should select the platform based on payload, environment, sensor geometry, compute requirements, and test objective.

# Record core evidence during a ROS 2 navigation PoC
ros2 bag record \
  /scan \
  /imu/data \
  /odom \
  /tf \
  /tf_static \
  /cmd_vel \
  /diagnostics

Reproducibility and PoC documentation

A PoC is reproducible when another engineer can rebuild the test environment and obtain comparable evidence. ROS 2 distribution, operating system version, package commits, sensor firmware, calibration files, URDF/Xacro description, QoS settings, and launch parameters should be version-controlled.

Docker can isolate build dependencies, while CI/CD can test package builds, linting, launch-file validity, and simulation scenarios. ROS distribution support status should be checked against REP 2000, which records target platforms and distribution support information.

poc_acceptance:
  test_case: lidar_imu_localization
  required_frames:
    - map
    - odom
    - base_link
    - laser
  recorded_topics:
    - /scan
    - /imu/data
    - /odom
    - /tf
  evidence:
    - rosbag2_recording
    - parameter_files
    - calibration_report
    - test_report

See also