RaaS (Robotics as a Service)

RaaS (Robotics as a Service) – definition

Robotics as a Service (RaaS) is an operating and commercial model in which a customer consumes robotic capability as an ongoing service rather than purchasing and independently maintaining a complete robotic system. In mobile robotics, the service can include a UGV platform, onboard compute, sensor payloads, ROS 2 software, remote monitoring, software updates, maintenance, and defined support levels.

RaaS is not a ROS or ROS 2 standard, message type, navigation algorithm, or hardware interface. It is a service-delivery model applied to a robotic system. A RaaS agreement should therefore define the technical boundary of the delivered system, the interfaces available to the customer, operating conditions, responsibility for safety, data ownership, maintenance procedures, and measurable service levels.

For a mobile UGV, the service scope may include the following components:

A mobile base with differential drive, motor controllers, battery management, and wheel odometry.
ROS 2 nodes for base control, sensor drivers, diagnostics, navigation, perception, and telemetry.
Integrated sensors such as 2D or 3D LiDAR, IMU, depth cameras, GNSS, or RTK GNSS receivers.
A cloud, VPN, or on-premise connection for fleet telemetry, log collection, software deployment, and remote support.
Operational documentation, acceptance tests, maintenance schedules, and incident-response procedures.

RaaS in the context of ROS 2 mobile robots

In a ROS 2-based RaaS deployment, the robot remains a distributed software system. The provider may operate some nodes on the vehicle and other services on customer infrastructure or a managed server. ROS 2 commonly uses DDS-based middleware implementations through its middleware interface, while communication behavior is configured through Quality of Service (QoS) policies.

A practical RaaS architecture usually separates the robot into the following layers:

Layer	Typical ROS 2 components	RaaS responsibility
Vehicle control	`ros2_control`, base driver, `geometry_msgs/Twist`	Motor interface validation, emergency-stop integration, firmware compatibility
State estimation	`sensor_msgs/Imu`, `nav_msgs/Odometry`, TF2	Sensor calibration, timestamp validation, frame convention documentation
Autonomy	Nav2, SLAM Toolbox, costmaps, planners, recovery behaviors	Map lifecycle, navigation configuration, test scenarios, update control
Observability	`diagnostic_msgs`, rosbag2, system logs	Monitoring, incident analysis, log retention, support access

ROS 2 QoS settings are relevant because service quality depends on whether critical data is delivered with suitable reliability and history policies. For example, a LiDAR topic used by a local costmap may need different QoS settings from a low-priority telemetry topic. ROS 2 documents reliability, durability, history, deadline, lifespan, and liveliness as configurable QoS policies.

Source: ROS 2 Humble documentation – Quality of Service settings.

Service boundaries and measurable technical parameters

A RaaS offer should not describe autonomy as a generic capability. It should specify measurable properties and the environmental assumptions under which they apply. The customer must be able to distinguish platform availability from navigation success, sensor availability, and network availability.

Common metrics for a UGV RaaS service include:

Platform availability: the percentage of scheduled operational time in which the robot is able to execute its defined mission.
Mean time to repair (MTTR): the average time required to restore the agreed service function after a confirmed fault.
Telemetry freshness: the time difference between a sensor or diagnostic timestamp and its receipt by the monitoring system.
Navigation success rate: completed navigation tasks divided by all valid navigation tasks within a defined test route and environment.
Localization quality: pose covariance, GNSS fix status, or deviation from ground-truth reference measurements.
Battery operating window: usable operation time under a documented payload, terrain, temperature, speed, and duty cycle.

Availability can be calculated over a defined reporting interval as:

Availability = operational time / scheduled service time × 100%

The formula is only meaningful when exclusions are defined. Planned maintenance, customer-caused network loss, operation outside specified terrain conditions, and safety shutdowns should be recorded separately rather than hidden in a single availability value.

RaaS deployment with Leo Rover and Raph Rover

Leo Rover can be used as the mobile base in a RaaS pilot, research service, or educational laboratory service. It is a four-wheel differential-drive UGV with onboard Raspberry Pi compute, ROS 2 software support, and an IP55-rated enclosure. It requires integration and validation of a navigation stack before it can perform autonomous missions.

For Leo Rover, a provider may deliver a bounded service such as indoor inspection data collection, repeatable mapping experiments, or ROS 2 navigation training. The service definition should state whether LiDAR, depth sensing, external compute, docking, remote teleoperation, or autonomous navigation are included.

Raph Rover is more suitable where the service requires a larger payload capacity, additional sensor hardware, or operation with heavier research equipment. It does not replace Leo Rover in laboratory and educational workflows where a smaller platform is sufficient. In both cases, the RaaS scope must identify payload mass, power budget, mounting interfaces, compute requirements, and environmental constraints.

Source: Leo Rover technical documentation.

Example ROS 2 service configuration

A managed deployment can store operational parameters in version-controlled YAML files. The values below are an example configuration, not a universal Leo Rover or Raph Rover specification.

raas_monitor:
  ros__parameters:
    robot_id: "ugv-01"
    diagnostics_topic: "/diagnostics"
    odometry_topic: "/odom"
    battery_topic: "/battery_state"
    telemetry_timeout_sec: 5.0
    record_rosbag_on_error: true
    required_frames:
      - map
      - odom
      - base_link

nav2:
  ros__parameters:
    use_sim_time: false
    autostart: true

The configuration should be deployed through a controlled release process. Containers can isolate dependencies, while CI/CD pipelines can run linting, unit tests, launch tests, simulation tests, and hardware-in-the-loop validation before deployment to a physical UGV.

Standards, safety, and limitations

RaaS does not remove the need for a system-level safety case. The provider and operator must define who is responsible for risk assessment, emergency-stop behavior, supervised teleoperation, remote access, geofencing, and operation near people or infrastructure.

ISO 8373 provides standardized vocabulary for robots and robotic devices, but it does not define RaaS as a commercial or operational model. ROS 2 also does not certify a robot as safe, autonomous, or service-ready. A ROS 2 deployment requires separate validation of hardware, software, sensor performance, communications, and operating procedures.

Relevant technical references include:

RaaS (Robotics as a Service)