Search and rescue robot (SAR)

Search and rescue robot – definition

A search and rescue robot, or SAR robot, is a mobile robotic system used to collect situational data, inspect hazardous or inaccessible areas, locate potential victims, and support incident-response teams. In mobile robotics, a SAR robot is typically an unmanned ground vehicle (UGV) equipped with mobility hardware, perception sensors, communications equipment, and a teleoperation or autonomous navigation stack.

A SAR robot does not replace a human responder. Its technical role is to extend sensing and mobility into environments that may be unsafe, confined, unstable, contaminated, dark, or difficult to access. Typical civil applications include post-collapse inspection, fire-scene reconnaissance, tunnel inspection, and industrial incident assessment.

For ROS-based UGVs, the SAR function is implemented as a system architecture rather than a single algorithm. It combines robot localisation, mapping, obstacle detection, video streaming, sensor fusion, route planning, diagnostics, and operator control. ROS coordinate-frame conventions are defined by REP 103, while the standard mobile-robot frame hierarchy is described in REP 105.

Core functions of a SAR UGV

A field robot intended for search and rescue requires more than basic remote driving. The platform must provide traceable spatial information and expose its operational state to the operator or a supervisory system.

Remote inspection – live RGB, thermal, depth, or LiDAR data from areas that should not be entered without assessment.
Mapping and localisation – estimation of the robot pose in an existing map or construction of a new map with SLAM.
Obstacle awareness – detection of walls, debris, narrow passages, people, and other hazards within the limits of the installed sensors and perception system.
Operator control – teleoperation with a defined emergency-stop strategy and feedback on motion, battery status, and communication health.
Data recording – logging of sensor streams, transforms, diagnostics, and operator-relevant events for later review.

In ROS 2, these functions are usually separated into nodes that exchange typed messages. A camera may publish sensor_msgs/msg/Image, a 2D laser scanner may publish sensor_msgs/msg/LaserScan, and a 3D LiDAR may publish sensor_msgs/msg/PointCloud2. Message definitions are maintained in the official sensor_msgs documentation.

ROS 2 architecture for search and rescue robotics

ROS 2 is suitable for SAR prototypes and research platforms because it provides distributed communication, lifecycle nodes, parameterisation, rosbag recording, and quality-of-service policies. ROS 1 normally used ROS-specific transport mechanisms such as TCPROS. ROS 2 commonly uses DDS-based middleware and exposes QoS settings at publisher and subscriber level. The ROS 2 QoS model is documented by docs.ros.org.

A minimal SAR UGV graph often contains the following interfaces:

ROS 2 interface	Typical message type	Purpose in SAR operation
`/cmd_vel`	`geometry_msgs/msg/Twist`	Velocity command for teleoperation or autonomous navigation.
`/odom`	`nav_msgs/msg/Odometry`	Wheel-odometry estimate used by localisation and state estimation.
`/scan`	`sensor_msgs/msg/LaserScan`	Planar range data for mapping and obstacle layers.
`/tf` and `/tf_static`	`tf2_msgs/msg/TFMessage`	Transforms between `map`, `odom`, `base_link`, and sensor frames.
`/diagnostics`	`diagnostic_msgs/msg/DiagnosticArray`	Health reporting for sensors, compute hardware, batteries, and drivers.

The following command illustrates a common ROS 2 workflow for recording evidence and debugging data during an inspection run:

ros2 bag record \
  /tf /tf_static /odom /scan /camera/image_raw \
  /imu/data /diagnostics /cmd_vel

Navigation, mapping, and perception

SAR navigation must account for incomplete maps, changing obstacles, wheel slip, poor lighting, and communication interruptions. A practical architecture may combine wheel odometry, IMU data, LiDAR scan matching, visual odometry, and GNSS or RTK-GNSS where satellite visibility is available.

For indoor or GNSS-denied environments, 2D LiDAR SLAM is commonly used to create an occupancy grid. The resulting map is normally published as nav_msgs/msg/OccupancyGrid. For outdoor terrain, 3D LiDAR or depth cameras can provide point clouds for traversability analysis, obstacle segmentation, and elevation mapping.

The ROS 2 Navigation Stack, commonly called Nav2, provides modular planners, controllers, costmaps, recovery behaviours, and behaviour-tree orchestration. Its interfaces and configuration model are documented in the official Nav2 documentation. Autonomous navigation should be treated as supervised functionality in SAR work. A robot must retain a safe teleoperation path when localisation quality, perception coverage, or network connectivity degrades.

local_costmap:
  local_costmap:
    ros__parameters:
      global_frame: odom
      robot_base_frame: base_link
      rolling_window: true
      plugins:
        - obstacle_layer
        - inflation_layer
      obstacle_layer:
        plugin: "nav2_costmap_2d::ObstacleLayer"
      inflation_layer:
        plugin: "nav2_costmap_2d::InflationLayer"

Use with Leo Rover and Raph Rover

Leo Rover is a four-wheel differential-drive UGV with an IP55 enclosure and ROS 2 support. It can serve as a compact research platform for indoor reconnaissance, camera-based inspection, LiDAR mapping, and supervised navigation experiments. It is not an autonomous SAR vehicle out of the box. A navigation stack, sensor drivers, transforms, safety logic, and validation procedure must be integrated by the project team.

For a Leo Rover SAR prototype, a typical payload includes a 2D LiDAR, IMU, RGB or depth camera, and optional thermal camera. The required static transforms should describe each sensor position relative to base_link. Platform-specific ROS interfaces and hardware documentation should be checked in docs.fictionlab.pl.

Raph Rover is more appropriate when the mission requires a larger sensor payload, additional onboard compute hardware, or equipment such as a mast-mounted LiDAR, protected communications hardware, or a higher-capacity power system. It should be selected for payload and terrain requirements, not as a replacement for Leo Rover in laboratory or educational work.

Operational limitations and validation

SAR robot performance must be evaluated at system level. Map quality alone does not prove that the robot can operate safely in a damaged or unstructured environment. Tests should cover mobility, localisation drift, sensor occlusion, wireless range, emergency stop behaviour, compute load, battery runtime, and recovery after node failure.

Relevant engineering references include ISO 22320:2018, Security and resilience – Emergency management – Guidelines for incident management, and the NIST response-robot testing programme maintained by the National Institute of Standards and Technology. These references support repeatable evaluation of robot mobility, sensing, communications, and operator effectiveness in emergency-response contexts.