Glossary

Fictionlab > Glossary > WebRTC

WebRTC

WebRTC – definition

WebRTC, or Web Real-Time Communication, is a set of W3C APIs and IETF protocols for real-time transmission of audio, video, and arbitrary data between networked applications, directly where possible and through relays where necessary. In mobile robotics, WebRTC is primarily used to deliver low-latency camera streams, telemetry, map visualisations, and operator-control data from an unmanned ground vehicle (UGV) to a browser-based interface or a remote engineering workstation.

WebRTC is not a ROS or ROS 2 transport. ROS 2 nodes typically communicate through DDS-based middleware implementations and ROS middleware interfaces. A WebRTC integration therefore requires a bridge or application node that subscribes to ROS 2 topics, converts selected data into media or data-channel payloads, and establishes a WebRTC session with a remote client. This separation is important for Leo Rover and Raph Rover deployments: WebRTC can provide an operator-facing communication layer, while ROS 2 remains the internal robotic software architecture.

WebRTC sessions commonly use the following protocol components:

  • ICE – Interactive Connectivity Establishment, defined by IETF RFC 8445, selects a usable network path between peers.
  • STUN – Session Traversal Utilities for NAT, defined by RFC 8489, helps a peer discover its public-facing address and port.
  • TURN – Traversal Using Relays around NAT, defined by RFC 8656, relays traffic when direct peer-to-peer connectivity is unavailable.
  • DTLS – Datagram Transport Layer Security protects WebRTC data-channel traffic and is used to establish keys for SRTP media protection.
  • SRTP – Secure Real-time Transport Protocol protects audio and video transported over RTP.
  • SCTP – Stream Control Transmission Protocol carries WebRTC DataChannel messages.

WebRTC transport model for UGV systems

A WebRTC connection has two separate planes. The signalling plane exchanges session descriptions and ICE candidates before media transfer begins. WebRTC does not standardise this signalling transport. A robotics system may use HTTPS, WebSocket, MQTT, or another authenticated application protocol for signalling.

The media plane carries the actual video, audio, or data after negotiation. Video from a camera connected to a Leo Rover or Raph Rover can be encoded by a local process and published as a WebRTC video track. Commands, compact telemetry, and application events can use a WebRTC DataChannel.

Channel Typical UGV payload Transport characteristics
MediaStreamTrack RGB camera video, thermal video, operator audio RTP media protected with SRTP; designed for time-sensitive delivery
RTCDataChannel Battery status, mission events, joystick commands, compressed map updates SCTP over DTLS; can be configured as ordered or unordered, reliable or partially reliable
Signalling channel SDP offers, answers, ICE candidates, authentication data Application-defined; not specified by the WebRTC standard

For robot control, a DataChannel should not be treated as the sole safety mechanism. Command expiry, heartbeat supervision, velocity limits, an emergency-stop path, and watchdog logic should remain local to the robot control system. A lost WebRTC session must result in a defined safe state rather than continued motion.

WebRTC and ROS 2 integration

ROS 2 does not provide WebRTC as its default topic transport. DDS-based middleware is typically used for communication between ROS 2 nodes, while WebRTC is usually introduced at the user-interface boundary. A bridge node can subscribe to image, pose, diagnostics, and navigation topics, then forward only data needed by the remote client.

A practical integration should avoid forwarding arbitrary ROS 2 messages directly to an internet-connected browser. Instead, define a stable application schema for each DataChannel message and validate every received command before it is published to ROS 2.

# Example ROS 2 topics exposed by a WebRTC bridge
ros2 topic list

/camera/color/image_raw
/camera/color/camera_info
/odom
/tf
/diagnostics
/cmd_vel
/battery_state

A bridge may encode sensor_msgs/msg/Image into H.264, VP8, VP9, or AV1 depending on the available encoder and browser support. The associated sensor_msgs/msg/CameraInfo message is not normally sent as a video track. Camera intrinsics, frame identifiers, and calibration metadata should be transferred separately when the browser application needs projection, measurement, or augmented-reality functions.

webrtc_bridge:
  ros__parameters:
    image_topic: /camera/color/image_raw
    cmd_vel_topic: /cmd_vel
    odom_topic: /odom
    video_codec: h264
    data_channel_label: rover_telemetry
    command_timeout_ms: 250

The command_timeout_ms value above is an application example, not a WebRTC requirement. Its correct value depends on the rover controller, network conditions, and local safety design.

Key parameters and engineering trade-offs

WebRTC is designed to adapt to varying network conditions, but adaptive behaviour does not eliminate radio-network constraints. Wi-Fi coverage, LTE or 5G uplink capacity, NAT policy, relay availability, encoder load, and CPU resources affect the resulting stream quality and latency.

  • Codec support: codec availability must be verified in both the robot-side implementation and target browser. Hardware encoding can reduce CPU load on the rover compute unit.
  • Bitrate: a higher target bitrate can improve image detail but increases wireless bandwidth demand and packet-loss sensitivity.
  • Resolution and frame rate: these should be selected according to the inspection task, available encoder throughput, and radio link budget.
  • ICE policy: direct connectivity candidates may minimise path length, while TURN relay candidates improve connectivity through restrictive NATs at the cost of relay infrastructure and an additional network hop.
  • DataChannel reliability: ordered and reliable delivery suits configuration messages. Unordered or partially reliable delivery is more suitable for rapidly superseded telemetry or joystick updates.

Use with Leo Rover and Raph Rover

On Leo Rover, WebRTC is useful for browser-based teleoperation, laboratory demonstrations, remote camera observation, and visual monitoring during ROS 2 navigation experiments. Leo Rover can be used with ROS 2 on supported software configurations, but autonomous navigation is not provided by WebRTC itself. A navigation stack, localisation method, sensor integration, and safety logic must be configured independently.

Leo Rover configurations commonly use Raspberry Pi-based compute hardware. Video encoding, ROS 2 processing, LiDAR drivers, visual perception, and WebRTC packetisation can therefore compete for compute resources. Engineering tests should measure CPU utilisation, memory use, encoder behaviour, packet loss, and end-to-end control responsiveness under the intended workload.

Raph Rover can use the same architecture when a larger payload or additional sensing equipment is required. Typical examples include an inspection camera mast, a depth camera, a LiDAR payload, or an onboard computer dedicated to perception and streaming. WebRTC remains the remote transport layer and does not replace ROS 2 navigation, localisation, or low-level motor control.

Normative references and standards

The following documents define the core protocol architecture. ROS 2 documentation should be consulted separately for node interfaces, QoS policies, message definitions, and deployment practices.

See also