# Choosing Foxglove or Lichtblick

Both clients support the common local workflow: connect to a Foxglove
WebSocket, inspect live ROS 2 data, open recordings, arrange panels, and use
extensions. Choose from the ownership model and services you need.

- **Choose Lichtblick** when the viewer must be inspectable, run locally or
  offline, be hosted as part of the application, or ship a custom panel without
  depending on a managed vendor service. It publishes desktop and browser
  clients and packages TypeScript extensions as `.foxe` files.
- **Choose Foxglove** when managed recordings, search, fleet access,
  organization layouts, or vendor support are material requirements.
- **Check the current contract** before promising a self-hosted Foxglove viewer.
  On 2026-08-27 the current embedded/self-hosted path required a custom
  Enterprise agreement; this is volatile commercial information, not a
  permanent product property.
- A launcher deep link can preselect a data source, but an organization layout
  identifier must already exist in that organization. It is not a way to embed
  arbitrary layout JSON in a URL.

Robium's Robot Navigation application validated a pinned Lichtblick web build,
a bundled `.foxe` dashboard extension, committed mapping/navigation layouts,
and a bridge at `ws://localhost:8765`. That is evidence for the tested app, not
a requirement to use the same port, build, or layout elsewhere.

Start from the current upstream sources:

- [Lichtblick repository](https://github.com/Lichtblick-Suite/lichtblick)
- [Lichtblick live-data documentation](https://lichtblick-suite.github.io/docs/docs/connecting-to-data/live-data/)
- [Lichtblick extensions](https://lichtblick-suite.github.io/docs/docs/extensions/introduction/)
- [Foxglove documentation](https://docs.foxglove.dev/docs)
- [Foxglove self-hosted viewer documentation](https://docs.foxglove.dev/docs/embed/self-hosted)
- [Robot Navigation](https://github.com/robium-ai/robium-apps/tree/main/robot-navigation)

triggers:
  positive:
    - phrase: should I use Lichtblick or Foxglove for this ROS 2 dashboard
    - phrase: connect Lichtblick to foxglove_bridge on my remote robot
    - phrase: record this ROS 2 session as MCAP and inspect it with Foxglove
  negative:
    - phrase: debug this TF tree locally in RViz2
      expect: rviz2
    - phrase: visualize policy tensors and embeddings from a non-ROS ML rollout
      expect: rerun
tasks: []

# Foxglove and Lichtblick failures

- **The client says the bridge is unreachable**
  - Confirm the robot, container runtime, and bridge process are actually up.
  - Prove the configured port is listening and reachable from the client host.
  - Check VPN, tunnel, firewall, and address binding before changing ROS code.

- **The web client cannot open a local `ws://` connection**
  - An HTTPS page may block insecure WebSockets as mixed content. In Robium's
    2026-07-11 test Safari blocked `ws://localhost` while the bridge was healthy.
    A desktop client, compatible browser, secure proxy, or Lichtblick may avoid
    that browser-origin policy.

- **A custom client receives HTTP 400 about a missing subprotocol**
  - Bridge 3.x builds may expect `foxglove.sdk.v1` rather than the older
    `foxglove.websocket.v1`. Inspect the installed build and current protocol
    documentation; the viewer applications negotiate this automatically.

- **The connection works but panels stay blank**
  - Prove the topic locally, then compare namespace, message schema, QoS, frame,
    and time.
  - Some topics stream only while a panel subscribes. A topic absent from a 3D
    view may simply be disabled in that panel.

- **Remote viewing is laggy**
  - Measure topic and message rates. Limit high-bandwidth streams at the bridge
    or recording source; panel filtering changes display, not network traffic.

- **Restarting the bridge over SSH kills the session**
  - In the 2026-07-24 TurtleBot 4 trial, `pkill -f foxglove_bridge` also matched
    the launch command being started and terminated the SSH shell. Freeing the
    configured listening port targeted the old process more safely. Resolve the
    exact process or port before killing anything.

- **Teleop moves nothing or a button cannot call an action**
  - Confirm the panel's topic, message type, scale, and the robot-side
    subscription.
  - If the client cannot invoke the required ROS action, use a narrowly scoped
    robot-side adapter and prove the trigger-to-action path; see
    [ROS 2 workflows](ROS2-WORKFLOWS.md).

The bridge normally has no application-level authentication. Do not expose it
directly to the public internet as a workaround for reachability.

# Foxglove WebSocket and ROS 2 workflows

Verify commands and launch arguments against the installed bridge. The package
and SDK surfaces have changed across releases.

## Live bridge

- Run `foxglove_bridge` on the robot or ROS host so it discovers the local
  graph. The normal case does not require one bridge declaration per topic.
- Connect the client to that WebSocket over a private network, VPN, or tunnel.
  A typical local bridge has used port `8765`, but treat the live configuration
  as authoritative.
- Use the bridge's allow/deny or topic-selection controls when a remote link
  cannot carry the whole graph.

## Record and replay

ROS 2 can record MCAP through `ros2 bag`; confirm the storage plugin and current
CLI flags for the selected distro. Record only the needed topics for a large
graph, while retaining `/tf`, `/tf_static`, and `/clock` when they explain the
data. The resulting MCAP can be opened without a live bridge.

## Navigation goals and layouts

- In Robium's 2026-07-11 Jazzy Nav2 trial, the 3D Publish tool's ROS 1-era
  pose-topic default sent goals to `/move_base_simple/goal`, while Nav2 consumed
  `/goal_pose`. Setting the Pose topic to `/goal_pose` made click-to-navigate
  work; `/initialpose` was correct for AMCL in that setup.
- Topic and action names remain application contracts. Inspect the live graph
  instead of copying those names universally.
- Export and commit one focused layout per task. Robium's navigation layout
  preserved the pose topic and useful displays so a new session did not depend
  on manual configuration.

## Teleoperation and actions

- The Teleop panel publishes `geometry_msgs/Twist`; set conservative linear and
  angular values and verify the actual command topic and message type before
  moving physical hardware.
- In the 2026-07-24 TurtleBot 4 trial, topic publishing and service calls were
  available but ROS 2 action calls were not. A small robot-side node translated
  trigger topics into dock/undock action goals. Re-check current client
  capability before preserving that adapter in a new app.
- Persist both the bridge and any control adapter as supervised services. In
  the 2026-07-26 trial, both disappeared after a Pi reboot until separate
  `systemd` units with restart policies were installed.

## Custom WebSocket clients

In Robium's 2026-07-25 live-hardware test, bridge 3.4.2 accepted the
`foxglove.sdk.v1` subprotocol. A publisher advertised a channel in JSON and
sent binary client-message frames containing the channel ID and CDR payload.
Older `foxglove.websocket.v1` examples were rejected. This is exact evidence
for that bridge build; use the current
[Foxglove SDK](https://github.com/foxglove/foxglove-sdk) protocol documentation
before implementing or testing a hand-rolled client.

---
name: foxglove
description: Visualize live or recorded ROS robot data remotely with Foxglove or Lichtblick.
---

# Foxglove and Lichtblick

Treat remote visualization as a chain: ROS graph, bridge, network, client, and
layout. Find the first link without evidence.

## Choose the client deliberately

- **Lichtblick:** prefer an inspectable open-core viewer, local/offline use, or
  a browser client you can host and extend yourself.
- **Foxglove:** prefer its managed data, fleet, organization, and support
  services, or when the team already uses its layouts and platform.
- Both clients can consume a Foxglove WebSocket and recordings for the common
  ROS workflow. Re-check current licensing and self-hosting terms before making
  them an architecture dependency.

Read [client choices](CLIENTS.md) when licensing, hosting, extensions, or
managed services affect the decision. If the visualization tool itself has not
been chosen, use `visualization` first.

## Trace the live-data chain

- Prove the ROS topics and QoS locally before blaming the bridge.
- Run the bridge near the ROS graph; DDS discovery should not need to cross a
  browser, NAT boundary, or public internet.
- Keep its unauthenticated WebSocket on a private network, VPN, or SSH tunnel.
- Confirm the listening port and WebSocket reachability before debugging a
  client layout.
- Limit high-rate topics at the bridge when bandwidth is constrained. Hiding a
  panel does not reduce transport load.
- Save a focused layout per task and record before any run that must be shared,
  replayed, or compared.

For bridge, MCAP, navigation goals, teleop, actions, layouts, and custom clients,
read [ROS 2 workflows](ROS2-WORKFLOWS.md). For a connection that is blank,
unreachable, mixed-content blocked, or missing controls, read
[failures](FAILURES.md).

Cross into `ros2` when the local graph or QoS is wrong. Cross into
`environments` when the bridge host, VPN, or container cannot provide the
network contract. Cross into `navigation` only after pose, map, sensors, and
goal messages are proven across the viewer boundary.

## Done

- The intended client reaches the bridge without exposing it publicly.
- The necessary topics render at useful rates and with correct frames.
- Controls publish to the interfaces the robot actually consumes.
- The layout and recording path can be reused by another person.
- Current behavior and hosting terms were checked against official
  [Foxglove](https://docs.foxglove.dev/docs) and
  [Lichtblick](https://lichtblick-suite.github.io/docs/) documentation.