How to Share a Live ROS 2 View With a Link (No X11, No VPN)

To share a live ROS 2 visualization with a link, you point a browser at your robot's WebSocket bridge and send the URL. No X11 forwarding, no VNC session, no VPN, no screen-share. A teammate opens it on a laptop or a phone and sees the same live URDF, point cloud, and TF stream you do. This is the remote-RViz workflow that RViz itself cannot give you, and this guide shows the whole path — including the network parts people skip.

# Why sharing an RViz view is painful

RViz is a desktop Qt application that runs on Linux. That design has a cost the moment you want anyone else to see what it shows:

• It is display-bound. To view RViz on another machine you forward X11, run a VNC or NoMachine session, or wire up a PiKVM. Every one of those is a workaround, and each is fragile over a real network.
• It needs the network opened up. Remote access usually means a VPN into the robot's network first, then one of the display hacks on top.
• You cannot paste it. There is no URL. You cannot drop an RViz view into Slack or attach it to a Jira ticket so a colleague sees the exact frame you are looking at.

That gap — the inability to simply link someone to a robot's-eye view — is a big part of why browser-based robotics visualization exists at all; it is close to the reason Foxglove was founded. The good news: you can get the same shareable result against your existing ROS 2 stack.

# What sharing a live ROS 2 view actually needs

Two pieces. A WebSocket bridge on the robot side that exposes ROS topics to browsers, and a browser client that subscribes and renders. Yugma speaks both common bridges — classic rosbridge and the Foxglove WebSocket — so you use whichever is already running. For how these approaches compare head to head, see RViz vs Foxglove vs browser.

Once connected, the browser renders the messages robotics teams stare at most, live off the wire:

• URDF / robot model — the robot posed in real time from its TF frames.
• PointCloud2 — depth-camera or LiDAR point clouds, streamed and decoded in a worker.
• OccupancyGrid — 2D maps from SLAM or the navigation stack.
• TF tree — the full transform hierarchy, with Z-up to Y-up handled for you.

# Run a bridge on the robot

Start a WebSocket bridge on the machine running your ROS 2 graph — classic rosbridge (default port 9090) or foxglove_bridge (default port 8765). A ROS 2 Humble plus rosbridge setup on a dev box or WSL works fine.

# rosbridge — WebSocket on :9090
ros2 launch rosbridge_server rosbridge_websocket_launch.xml

# or the Foxglove bridge — WebSocket on :8765
ros2 launch foxglove_bridge foxglove_bridge_launch.xml

# Share a live ROS 2 view with a link: step-by-step

1. Open Yugma and find the ROS panel. Yugma Studio runs in any browser — nothing to install on your side or your teammate's.
2. Point it at your bridge. Enter the WebSocket URL of the endpoint from above — ws://your-robot-host:9090 for rosbridge, or ws://your-robot-host:8765 for the Foxglove WebSocket — and connect.
3. Watch the stream render. Yugma subscribes and draws the live scene: the robot's URDF, PointCloud2 from a depth camera or LiDAR, an OccupancyGrid map, and the full TF tree. REP-103 Z-up data is converted to the browser's Y-up automatically, so nothing renders on its side.
4. Share the URL, or embed it. Send the view link in Slack, Jira, or email, or drop the embeddable viewer into a dashboard or wiki page.
5. Your teammate opens it anywhere. They click the link on any laptop or phone — zero install, no ROS, no VPN client — and see the same live view you do.

Beyond viewing, the same channel carries teleop (cmd_vel and Nav2 goals) and MCAP record and replay, so a shared session can be interactive, not just a window to watch.

# Network reachability, honestly

The one thing a link cannot do is punch through a network for you. The browser must be able to reach the WebSocket endpoint, so plan for it:

• The bridge host must be reachable. If the robot sits behind NAT or on a private LAN, a random laptop on the internet cannot hit ws://robot:9090 directly. You expose or tunnel the WebSocket endpoint first.
• Mixed content blocks plain ws://. Yugma is served over HTTPS, and browsers refuse an insecure ws:// connection from a secure page — with a localhost exception. For any remote host you need wss://, a TLS-terminated WebSocket.
• The clean fix is a tunnel or reverse proxy. Put the bridge behind a reverse proxy that terminates TLS (nginx, Caddy, or Traefik), or run a tunnel such as cloudflared, ngrok, or Tailscale to get a wss:// URL that resolves from anywhere. Then share that URL.

None of this needs a VPN for the viewer. You secure the one WebSocket endpoint once, and everyone else just opens a link.

# FAQ

Does my teammate need ROS or RViz installed?

No. They open a URL in a browser. The rendering happens client-side from the streamed topics, so any laptop or phone works — no ROS, no Linux, no display server.

Can I share a robot that is behind NAT or a firewall?

Yes, but you expose or tunnel the WebSocket endpoint first. Because the viewer runs over HTTPS, terminate TLS and share a wss:// URL — via a reverse proxy or a tunnel like cloudflared, ngrok, or Tailscale.

Which bridge should I use, rosbridge or Foxglove?

Either. Yugma connects to both rosbridge (port 9090) and the Foxglove WebSocket (port 8765). Use whichever already runs in your stack; if neither does, rosbridge is the most common starting point. The Foxglove bridge tends to be lighter on high-rate topics, so reach for it if you are streaming dense point clouds.

View and pose a URDF robot in the browser →