Industrial Inspection

Industrial Inspection – definition

Industrial inspection in mobile robotics is the systematic acquisition, localization, and analysis of data from industrial assets by a mobile robot operating in a structured or semi-structured environment. In the UGV context, the goal is not generic surveillance. The goal is repeatable measurement and documentation of asset condition, geometry, anomalies, and process state. Typical targets include pipes, tanks, valves, cable trays, facades, conveyors, utility corridors, solar farms, and construction zones.

For a ground robot, industrial inspection combines three layers. The first layer is mobility and positioning. The robot must move safely near equipment and maintain a known pose in a local or global frame. The second layer is sensing. This usually includes RGB cameras, depth cameras, LiDAR, thermal cameras, gas sensors, microphones, or non-contact vibration sensors. The third layer is interpretation. Data is time-synchronized, georeferenced, and processed to detect defects, generate reports, or trigger operator review.

In ROS 2, industrial inspection is typically implemented as a pipeline of sensor drivers, timestamped topics, transforms managed by tf2, recorded datasets in rosbag2, and perception or navigation nodes. The result can be a map, an asset model, an anomaly list, or a mission log linked to precise robot poses. On Fictionlab platforms, this means that Leo Rover or Raph Rover acts as a mobile sensing base. They carry the payload, publish standard ROS 2 messages, and execute inspection routes, but autonomous inspection requires a configured navigation and perception stack.

How industrial inspection works on UGV platforms

A mobile inspection workflow starts with route definition and frame setup. The robot operates in a coordinate system that follows ROS conventions, usually with base_link, odometry, and map frames. Frame semantics are standardized in REP 103 for units and conventions and REP 105 for mobile platform coordinate frames. Inspection data only becomes useful when every measurement can be traced to a pose estimate with known uncertainty.

A typical UGV inspection mission includes the following stages.

Localization – wheel odometry, IMU, LiDAR SLAM, visual odometry, or GNSS/RTK provide pose estimates.
Coverage – the robot follows waypoints or a manually teleoperated path around the asset.
Data capture – cameras, LiDAR, and other sensors stream synchronized data with timestamps.
Asset association – measurements are linked to map coordinates, inspection points, or object IDs.
Post-processing – datasets are reviewed offline for measurements, change detection, or defect classification.

Inspection differs from ordinary teleoperation because it must preserve measurement quality. Motion blur, unstable exposure, poor calibration, and inaccurate transforms can invalidate a dataset. For this reason, sensor calibration, stable mounting, and deterministic time handling matter as much as the locomotion system.

ROS 2 interfaces used in inspection systems

ROS 2 provides standard interfaces for the data types used in inspection. This improves interoperability between sensors, navigation, and analysis tools. The exact topic names depend on the integration, but the message types are usually consistent.

Function	Typical ROS 2 message / interface	Typical rate	Notes
RGB image	`sensor_msgs/msg/Image`	15 – 60 Hz	Resolution depends on camera and compute budget
Camera calibration	`sensor_msgs/msg/CameraInfo`	same as image	Required for metric reconstruction
LiDAR scan	`sensor_msgs/msg/LaserScan` or `sensor_msgs/msg/PointCloud2`	5 – 20 Hz	Depends on LiDAR model
IMU	`sensor_msgs/msg/Imu`	50 – 400 Hz	Used for filtering and motion estimation
Pose estimate	`nav_msgs/msg/Odometry`	10 – 100 Hz	Source can be wheel odometry or fused estimation
Transforms	`/tf` and `/tf_static`	dynamic and static	Frame consistency is critical
Map	`nav_msgs/msg/OccupancyGrid` or point cloud map	0.5 – 10 Hz	Used for navigation and reporting

For image and point cloud synchronization, integrators often use approximate time policies from message_filters. This is practical when camera, IMU, and LiDAR drivers do not expose hardware-level trigger synchronization. However, if precise dimensional inspection is required, hardware timestamping and fixed-latency transport are preferred.

Key parameters and metrics

Inspection quality can be evaluated with measurable parameters. These metrics depend on the asset, sensor payload, and navigation method. A UGV intended for corridor inspection has different requirements than one documenting concrete cracks or thermal leakage.

Localization error – often expressed as RMS position error or drift per distance traveled.
Image ground sampling distance – mm/pixel at a defined stand-off distance.
Point cloud density – points per square meter on the inspected surface.
Update rate – sensor and estimation frequency, for example 10 Hz LiDAR or 200 Hz IMU.
Coverage ratio – fraction of the target asset observed from valid viewpoints.
Repeatability – ability to revisit the same inspection pose across missions.
Mission duration – constrained by battery, compute load, and payload power budget.

For visual inspection, stand-off distance matters directly. A simple approximation for observed width is:

scene_width = 2 * distance * tan(horizontal_FOV / 2)

If a camera produces N horizontal pixels, then the approximate spatial sampling is:

mm_per_pixel = 1000 * scene_width / N

This estimate is useful when selecting lens and mounting position for crack detection or label reading. It does not replace full camera calibration.

Supported sensors and payload integration

Industrial inspection on Leo Rover and Raph Rover is payload-driven. The rover provides mobility, power distribution, compute hosting, and ROS 2 integration. The payload determines what can actually be measured. In practice, three sensor groups are common.

Geometry sensors – 2D LiDAR, 3D LiDAR, depth cameras. Used for obstacle detection, mapping, and dimensional reconstruction.
Visual sensors – RGB cameras, often with a global shutter for motion-sensitive inspection. Used for corrosion, crack, label, and connector inspection.
Condition sensors – thermal cameras, gas sensors, microphones, or environmental probes. Used for leak detection, overheating, or acoustic anomaly screening.

Leo Rover is a compact four-wheel rover platform with ROS 2 support and a Raspberry Pi based compute unit in standard configurations. It is suitable for education, lab validation, indoor inspection prototypes, and light outdoor inspection where payload and runtime remain moderate. It is IP54, which helps in dusty or splash-prone conditions, but it is not a sealed hazardous-environment robot. Raph Rover is better suited when the inspection payload is heavier, when a larger battery is needed, or when terrain and mounting constraints are stricter.

Use cases with Leo Rover and Raph Rover

On Fictionlab platforms, inspection usually means a custom integration rather than a fixed turnkey configuration. The mobile base must be matched to the sensor suite and the mission profile.

Leo Rover – indoor utility corridor inspection with 2D LiDAR, RGB camera, and Nav2 waypoint following.
Leo Rover – educational or research testbed for visual anomaly detection, rosbag2 data collection, and SLAM benchmarking.
Raph Rover – outdoor construction or energy-site inspection with higher payload, larger sensor mast, and longer mission time.
Raph Rover – field deployment with GNSS/RTK, multi-sensor logging, and denser onboard compute such as NVIDIA Jetson class hardware.

Leo Rover is not an autonomous inspection robot out of the box. It requires integration of navigation, perception, and safety logic. Raph Rover does not replace Leo Rover for lab or classroom workflows. It addresses a different operating envelope, mainly payload capacity and field robustness.

Example ROS 2 inspection stack

A minimal inspection configuration combines localization, mapping, sensor drivers, and recording. The exact packages depend on the chosen payload.

inspection_stack:
  ros__parameters:
    use_sim_time: false
    record_topics:
      - /camera/color/image_raw
      - /camera/color/camera_info
      - /scan
      - /imu/data
      - /odom
      - /tf
      - /tf_static
    waypoint_tolerance_m: 0.20
    image_rate_hz: 15
    lidar_rate_hz: 10

ros2 bag record \
  /camera/color/image_raw \
  /camera/color/camera_info \
  /scan /imu/data /odom /tf /tf_static

ros2 topic hz /scan
ros2 topic echo /odom --once
ros2 run tf2_tools view_frames

Limitations and trade-offs

Inspection robots operate under practical constraints. High-resolution sensing increases bandwidth, storage use, and compute load. Dense point clouds improve reconstruction, but they can reduce runtime on embedded computers. Ground UGVs are also limited by viewpoint geometry. They cannot inspect elevated surfaces without a mast, tilt mechanism, manipulator, or external fixture.

Another trade-off is between fully autonomous and operator-supervised missions. In cluttered industrial areas, autonomy may be feasible for corridor traversal but not for close-up sensing near reflective, narrow, or dynamic obstacles. In such cases, supervised teleoperation with precise logging is often the safer and more auditable approach.

Normative references and standards

The technical interpretation of industrial inspection in ROS-based UGV systems depends on established conventions and vendor documentation. The most relevant references are:

ROS REP 103 – standard units of measure and coordinate conventions.
ROS REP 105 – coordinate frames for mobile platforms.
ROS 2 documentation for tf2, sensor_msgs, nav_msgs, and rosbag2.
Vendor specifications for LiDAR, RGB-D cameras, IMUs, and GNSS/RTK receivers, including range, update rate, field of view, and timestamp behavior.
IEEE literature on mobile robot inspection, visual inspection repeatability, and SLAM accuracy metrics.

Industrial Inspection