TRL (Technology Readiness Level)

TRL (Technology Readiness Level) – definition

Technology Readiness Level (TRL) is a structured scale used to assess the maturity of a specific technology before it is deployed in an operational system. The most widely used model contains nine levels, from TRL 1, where basic principles are observed, to TRL 9, where the technology has been proven in operational use.

TRL is not a measure of commercial readiness, software quality, manufacturing capacity, or project completion. It assesses whether a defined technology element has been demonstrated with sufficient evidence in a relevant or operational environment. NASA defines the nine-level framework in its Systems Engineering Handbook, while ISO 16290:2013 specifies TRL definitions for space systems. The European Commission also uses TRLs in research and innovation programmes.

For mobile robotics and UGV development, a TRL assessment should apply to a clearly bounded capability. Examples include a ROS 2 navigation stack, a LiDAR-based localization subsystem, an RTK GNSS integration, a perception model, or an autonomous inspection workflow. A complete Leo Rover or Raph Rover deployment may contain components at different readiness levels.

The nine TRL levels

The table below summarizes the common NASA-style TRL model. The descriptions are paraphrased from NASA guidance and should be interpreted together with the operational context of the assessed system.

TRL	Technology maturity	UGV robotics example
1	Basic principles observed and reported.	A research team identifies that wheel odometry drift can be reduced using IMU fusion.
2	Technology concept and application formulated.	A proposed ROS 2 architecture combines encoder, IMU, and GNSS data for outdoor localization.
3	Analytical and experimental proof of concept.	A localization algorithm is validated with recorded sensor data or simulation logs.
4	Component or breadboard validated in a laboratory environment.	A LiDAR driver, robot_localization configuration, and Nav2 components run on a bench setup.
5	Component or breadboard validated in a relevant environment.	The stack is tested on a Leo Rover in indoor corridors or controlled outdoor terrain.
6	System or subsystem model or prototype demonstrated in a relevant environment.	A Raph Rover performs repeated autonomous waypoint missions with its intended sensor payload.
7	System prototype demonstrated in an operational environment.	A UGV completes supervised field inspections under real lighting, terrain, and communication conditions.
8	Actual system completed and qualified through test and demonstration.	The robot configuration, software release, documentation, and verification records meet defined acceptance criteria.
9	Actual system proven through successful operational use.	The same controlled configuration is used repeatedly in its intended field workflow.

Source: NASA Technology Readiness Levels; ISO 16290:2013, Space systems – Definition of the Technology Readiness Levels (TRLs) and their criteria of assessment.

TRL assessment for ROS 2 mobile robots

In ROS 2 projects, TRL should be assigned to the complete technical capability rather than to the existence of a package in a repository. A ROS 2 package can be publicly available and still be at a low readiness level for a specific UGV because hardware interfaces, timing behaviour, recovery logic, documentation, and field validation may be incomplete.

A navigation capability for Leo Rover, for example, includes more than Nav2. It includes the robot base interface, transform tree, sensor drivers, state estimation, map or localization method, velocity constraints, safety behaviour, deployment process, and repeatable test evidence. Leo Rover supports ROS 2 natively on its integrated Raspberry Pi compute unit, but autonomous navigation requires integration and validation of the relevant navigation stack.

For ROS 2 distributions, the target environment must be recorded in the assessment. ROS 2 Humble Hawksbill was released in May 2022, while ROS 2 Jazzy Jalisco was released in May 2024. A result demonstrated on one distribution should not automatically be treated as evidence for another because package versions, operating system support, middleware implementations, and dependencies can differ.

Sources: REP 2000 – ROS 2 Releases and Target Platforms; Leo Rover technical documentation.

Evidence required for a UGV TRL assessment

A credible assessment requires traceable evidence. The evidence must show what was tested, on which hardware and software versions, under which environmental conditions, and against which pass or fail criteria. A demonstration video alone is usually insufficient for TRL 6 or higher.

For a ROS 2 autonomy subsystem, an evidence package can include the following records:

Hardware bill of materials, sensor mounting geometry, firmware versions, and power configuration.
ROS 2 distribution, operating system image, package commit hashes, container image digest, and parameter files.
Recorded rosbag2 datasets containing relevant topics, timestamps, transforms, and diagnostic data.
Test protocols covering terrain, illumination, precipitation exposure where applicable, GNSS availability, and communication loss.
Measured metrics such as localization error, mission completion rate, obstacle detection recall, CPU utilization, memory consumption, and recovery time.
Failure reports showing known limitations, fallback modes, operator intervention requirements, and unresolved risks.

TRL is ordinal. It should not be averaged mathematically across subsystems. For example, combining a TRL 7 chassis with a TRL 4 perception pipeline does not create a TRL 5.5 robot. The field capability remains constrained by the least mature subsystem that is necessary for the intended mission.

Example TRL criteria for Leo Rover and Raph Rover

Leo Rover is suitable for laboratory, educational, and controlled field validation of mobile robotics components. Its four-wheel skid-steer drive architecture makes it appropriate for evaluating odometry, local planning, ROS 2 control interfaces, sensor placement, and autonomous navigation workflows. Its IP55 rating should be considered when defining the environmental conditions for a relevant-environment test.

Raph Rover is intended for larger payloads and applications that require a larger mobile base. A TRL assessment for Raph Rover should separately document payload mass, centre of gravity, sensor vibration, compute hardware, electrical integration, terrain conditions, and mission duration. A configuration validated on Leo Rover is not automatically validated on Raph Rover because the kinematics, dynamics, payload integration, and operating environment may differ.

technology: ROS_2_LiDAR_navigation
target_platform: Leo Rover
target_ros_distribution: Humble
claimed_trl: 5
relevant_environment:
  location: indoor_corridor_and_controlled_outdoor_area
  surface: concrete_and_compacted_gravel
evidence:
  - rosbag2_recordings
  - nav2_parameter_files
  - localization_error_measurements
  - mission_test_reports
acceptance_criteria:
  - autonomous_goal_execution
  - documented_recovery_behavior
  - repeatable_sensor_calibration
known_limitations:
  - no_validation_in_heavy_rain
  - degraded_performance_in_low_feature_areas

Standards and reference frameworks

Different organizations use similar TRL scales but may apply different assessment criteria. The assessment framework must therefore be named in technical documentation, grant proposals, procurement specifications, and verification plans. ISO 16290:2013 is focused on space systems, whereas NASA guidance is broadly referenced across engineering research programmes.

For ROS 2 software, TRL should be used alongside software engineering controls rather than instead of them. Useful controls include version pinning, automated tests, CI/CD pipelines, reproducible Docker builds, hardware-in-the-loop testing, and documented ROS interface definitions. These practices improve the evidence available for a readiness decision but do not independently determine a TRL.

TRL (Technology Readiness Level)