Glossary

Fictionlab > Glossary > rosbridge

rosbridge

rosbridge – definition

rosbridge is a protocol and software suite that exposes a ROS graph through network-friendly interfaces, most commonly WebSocket connections carrying JSON messages. It allows software that does not run as a native ROS node to publish and subscribe to ROS topics, call services, provide services, and interact with actions.

In mobile robotics, rosbridge is commonly used to connect browser-based operator panels, remote monitoring applications, simulation front ends, and custom fleet tools to a UGV. A client can receive odometry, battery state, camera metadata, diagnostics, and map updates without linking against ROS client libraries such as rclcpp or rclpy.

The reference implementation is rosbridge_suite. Its central component, rosbridge_server, acts as a gateway between ROS interfaces and remote clients. The protocol is defined by the rosbridge Protocol Specification, currently identified as protocol version 2.0.

How rosbridge works in ROS 2

In ROS 2, rosbridge runs as a ROS node and communicates with the local ROS graph through ROS 2 client libraries and middleware. A remote application connects to the server, usually through a WebSocket endpoint. The server converts rosbridge protocol operations into ROS 2 publishers, subscriptions, service calls, and action interactions.

ROS 2 uses DDS as its default middleware layer. rosbridge does not expose DDS entities directly to a browser. Instead, it provides an application-layer gateway. This distinction matters when designing a network architecture for Leo Rover or Raph Rover: DDS discovery may remain inside the robot network, while selected interfaces are made available through a controlled WebSocket endpoint.

The default WebSocket port used by rosbridge_websocket is 9090, as documented in the rosbridge_server package documentation. The port should be treated as a configurable deployment parameter rather than a fixed system requirement.

# ROS 2: start a WebSocket rosbridge server
ros2 launch rosbridge_server rosbridge_websocket_launch.xml

# Example: use a non-default listening port
ros2 launch rosbridge_server rosbridge_websocket_launch.xml port:=9091

A client sends a JSON object containing an op field and operation-specific parameters. For a topic subscription, the client specifies the ROS topic name and may request throttling or queue limits. Message payloads are represented as JSON-compatible structures.

const ros = new ROSLIB.Ros({
  url: 'ws://192.168.1.50:9090'
});

const odom = new ROSLIB.Topic({
  ros: ros,
  name: '/odom',
  messageType: 'nav_msgs/msg/Odometry'
});

odom.subscribe((message) => {
  console.log(message.pose.pose.position);
});

ROS interfaces commonly exposed on UGV platforms

rosbridge is most useful when the remote client needs a limited, clearly defined subset of the robot interface. On a differential-drive UGV, these interfaces usually cover state observation, teleoperation commands, mission control, and diagnostic data.

ROS 2 interface Typical message or service type UGV use
/odom nav_msgs/msg/Odometry Robot pose and velocity estimated from wheel odometry or sensor fusion.
/cmd_vel geometry_msgs/msg/Twist Velocity command input for a differential-drive base.
/scan sensor_msgs/msg/LaserScan 2D LiDAR data for visualisation, obstacle monitoring, or SLAM debugging.
/tf and /tf_static tf2_msgs/msg/TFMessage Coordinate transforms between frames such as map, odom, base_link, and sensor frames.
Navigation actions nav2_msgs/action/NavigateToPose Sending a goal to a ROS 2 Navigation stack deployment.

Topic names and message types must match the running ROS 2 system. rosbridge does not translate between incompatible message definitions. For example, a client publishing to /cmd_vel must provide fields consistent with geometry_msgs/msg/Twist, including linear and angular vectors.

Use with Leo Rover and Raph Rover

Leo Rover has an integrated Raspberry Pi-based compute unit on which ROS 2 applications, including rosbridge, can run. Compatibility with a particular ROS 2 distribution depends on the installed Leo Rover software image and packages. Leo Rover has a four-wheel differential drive, so remote velocity control normally uses geometry_msgs/msg/Twist on a configured command topic.

For Leo Rover, a practical rosbridge deployment may provide a browser dashboard with the following functions:

  • displaying /odom, battery data, diagnostics, and Wi-Fi signal state;
  • showing a compressed camera stream through a dedicated web-video component rather than raw image JSON;
  • sending bounded teleoperation commands to a supervised /cmd_vel interface;
  • requesting a navigation goal only when a Nav2 stack, localization source, map, and obstacle sensors have been integrated.

Raph Rover can use the same pattern when its larger payload capacity is used for additional sensors or an external compute unit. A higher-bandwidth sensor set, such as multiple cameras or a 3D LiDAR, should not automatically be mirrored through rosbridge. Raw point clouds and uncompressed images create large JSON payloads and can increase latency. It is usually preferable to send derived data, compressed media, or selected status topics.

Performance and security limitations

rosbridge is an integration layer, not a real-time transport. JSON serialization, WebSocket framing, wireless links, browser execution, and client-side rendering all add latency. It is suitable for supervision, visualization, configuration, and non-safety-critical command paths. It should not be the only control channel for emergency stop, motor protection, or low-level drive control.

Before exposing rosbridge beyond a trusted robot network, restrict which clients can connect and which ROS interfaces they can access. Publishing to a velocity topic or calling an actuator-related service can change robot behaviour. Use network segmentation, firewall rules, authenticated reverse proxies, TLS termination where required, and explicit command validation in the ROS 2 control layer.

Standards and references

rosbridge is not a ROS Enhancement Proposal standard. Its normative protocol reference is the rosbridge Protocol Specification maintained by RobotWebTools. ROS 2 distribution support is governed by the ROS 2 release process described in REP 2000. ROS interface definitions should be verified against the installed distribution documentation and the message packages deployed on the robot.

See also