Glossary

Fictionlab > Glossary > Security robot

Security robot

Security robot – definition

A security robot is a mobile robotic system used to support physical-security operations in defined indoor or outdoor areas. In the context of unarmed unmanned ground vehicles (UGVs), it performs tasks such as scheduled patrols, remote visual inspection, event recording, environmental monitoring, and teleoperation-assisted response. It should not be confused with a road autonomous vehicle or a stationary surveillance camera.

A security UGV combines a mobile base, perception sensors, compute hardware, communication interfaces, and supervisory software. It may navigate between patrol points autonomously, stop at inspection locations, stream sensor data to an operator, and generate alerts when configured conditions are met. Human operators remain responsible for escalation decisions, access control, and any action affecting people or property.

On ROS 2-based platforms, a security robot is usually implemented as an integration of navigation, sensor drivers, recording nodes, remote-operation tools, and a monitoring backend. Leo Rover and Raph Rover can serve as mobile UGV bases for this type of research or system integration. Neither platform becomes an autonomous security system without an added sensor suite, navigation stack, safety assessment, and operational procedures.

Core functions of a security UGV

A security robot normally operates within a mapped and bounded site. The site can include corridors, laboratories, warehouses, construction areas, utility rooms, agricultural facilities, or fenced outdoor infrastructure. The robot’s mission logic should define where it may travel, where it must stop, and when it must request human intervention.

  • Patrolling: following predefined waypoints or navigation goals at scheduled intervals.
  • Remote inspection: providing live RGB, thermal, depth, LiDAR, or audio data to an operator.
  • Event documentation: storing timestamped images, video segments, map positions, and diagnostic logs.
  • Condition monitoring: detecting configured conditions such as a door left open, an obstruction in a corridor, water leakage, smoke-alarm activation, or equipment-state changes.
  • Teleoperation: allowing an authorised operator to drive the UGV when autonomous navigation is unsuitable.

The term does not imply that the robot can reliably identify criminal intent, determine whether a person is authorised, or make legal or safety-critical decisions. Person detection, object detection, and anomaly detection are probabilistic perception tasks. Their output requires validation against the target environment and a defined human review process.

ROS 2 architecture for security robotics

ROS 2 provides middleware, message definitions, lifecycle management, launch tools, and integration patterns that are suitable for a modular UGV system. ROS 2 uses DDS-based communication by default, while its security model can use DDS-Security features such as authentication, access control, and encrypted communication. The ROS 2 security tooling is commonly referred to as SROS2.

A typical graph separates hardware drivers, state estimation, navigation, perception, recording, and operator interfaces. The robot should publish its coordinate transforms according to REP 105, which defines the conventional map, odom, and base_link frame roles for mobile robots.

Function Typical ROS 2 interface Purpose Reference
Velocity command geometry_msgs/msg/Twist on /cmd_vel Commands linear and angular base velocity. ROS 2 geometry_msgs documentation
Laser scan sensor_msgs/msg/LaserScan Represents planar range data for obstacle detection and localisation. ROS 2 sensor_msgs documentation
Camera image sensor_msgs/msg/Image Transfers image frames with timestamp, encoding, dimensions, and pixel data. ROS 2 sensor_msgs documentation
Robot pose geometry_msgs/msg/PoseWithCovarianceStamped Represents an estimated pose with uncertainty information. ROS 2 geometry_msgs documentation

Navigation, perception, and evidence collection

Autonomous patrol requires localisation and obstacle-aware navigation. A common ROS 2 implementation uses Nav2 with a 2D occupancy grid, a costmap, a planner, a controller, and recovery behaviours. Nav2 does not create a complete security application by itself. It provides navigation components that must be configured for the UGV footprint, sensor placement, velocity limits, and operating area.

For indoor operation, 2D LiDAR-based SLAM or localisation is often used because it provides geometry that is less dependent on illumination than RGB cameras. Cameras add contextual evidence, while depth cameras can improve near-field obstacle perception. IMU data can support state estimation, particularly on uneven ground. GNSS or RTK positioning is relevant primarily for outdoor sites with sufficient satellite visibility and a suitable correction source.

Evidence records should preserve sensor timestamps, frame identifiers, robot pose estimates, and relevant diagnostics. ROS 2 bag recording can capture selected topics for later analysis. Storage policies must define retention time, access permissions, encryption requirements, and deletion procedures before deployment in areas where people may be recorded.

# Record patrol telemetry and selected perception data
ros2 bag record \
  /tf /tf_static \
  /odom \
  /scan \
  /camera/image_raw \
  /camera/camera_info \
  /diagnostics \
  /security/events

Use with Leo Rover and Raph Rover

Leo Rover is a four-wheel UGV with an IP55 rating and a built-in Raspberry Pi compute unit. It can be used with ROS 2. For a security-robot prototype, Leo Rover can carry a 2D LiDAR, an RGB or depth camera, and an optional external compute unit when perception workloads exceed the capacity of the onboard Raspberry Pi. Its skid-steer drive configuration must be reflected in the Nav2 controller and the robot’s URDF configuration.

Raph Rover is a larger UGV platform intended for applications requiring higher payload capacity. It can be more appropriate where the sensor package includes multiple cameras, a larger LiDAR, a protected compute enclosure, additional batteries, or communications equipment. It is not a replacement for Leo Rover in laboratory teaching or compact indoor experiments. Platform selection should be based on payload, terrain, operating duration, turning space, and required sensor mounting geometry.

Safety and cybersecurity requirements

A security UGV needs both operational safety controls and communication security. Physical-security use does not remove the need for risk assessment, emergency stopping procedures, speed limits, geofencing, and operator supervision. The system’s safety design should define a predictable safe state when localisation is lost, communications fail, battery level becomes critical, or obstacle sensing is unavailable.

For networked ROS 2 deployments, the following controls should be considered during system design. These controls address unauthorised access to the robot and its telemetry rather than physical intrusion detection alone.

  • Use ROS 2 enclaves and SROS2 keystores to apply DDS-Security identities and permissions.
  • Restrict access to teleoperation, recording, configuration, and software-update interfaces.
  • Segment robot traffic from general office or guest networks.
  • Log authentication failures, remote commands, lifecycle transitions, and software versions.
  • Apply security updates to the operating system, ROS 2 packages, container images, and sensor firmware.

Relevant references and standards

There is no single IEEE or ROS standard that fully defines a security robot as a product category. A deployable system is instead built from applicable robotics, cybersecurity, safety, and data-governance requirements. The following references are relevant to ROS 2 UGV integration.

See also