Scene Workbench

The Scene Workbench is the Flightops desktop app for recordings. It draws a 2D top-down scene from a run's recording: the latest laser scan on /scan at the cursor, placed where it was taken, and the robot pose from TF. Use it to replay one run or to compare a working run with a failing one on one timeline. It suits a mobile robot with a 2D lidar, such as a Nav2 setup.

It opens recordings read-only. It does not connect to ROS or to a robot.

Before you start

• An installed and activated Flightops beta (installation).
• A desktop session (X11 or Wayland). The app does not run over plain SSH.
• A Vulkan or OpenGL driver. Ubuntu desktop installs have the libraries the app needs; on a minimal system install them:

sudo apt install libxkbcommon-x11-0 libxkbcommon0 libxcb1 libfontconfig1 libfreetype6

Try the samples

flightops workbench --sample

This opens two short Nav2 recordings that ship with Flightops: nav_working, and nav_lidar_topic_fault, where the map-to-odom transform never appears. Close the window to finish.

Open a recording

flightops workbench --run mine=~/bags/run_2026_10_20

NAME=PATH names a run and points at an .mcap file or a rosbag2 folder that holds one .mcap file. The name appears in the app; use unique lowercase letters, digits and _.

flightops workbench copies each recording into a private folder under $XDG_RUNTIME_DIR, starts the local flightops-service, opens the app, and removes the folder when you close the app. Add --keep to keep the folder for a bug report. $XDG_RUNTIME_DIR is usually held in memory, so very large recordings need as much free memory; slice them first with splashdown slice.

Compare two runs

flightops workbench --run good=~/bags/run_ok --run bad=~/bags/run_fail

With two or more runs (at most 8), the app opens Compare: two runs on one cursor, aligned at the start of each recording. [ and ] change run B. The difference list compares the same signals for both runs, differing ones first: message counts on /scan, /workbench/scan and /clock, whether and when map → odom was published, and the frame of the robot pose.

Read the scene

• Replay (key 1): one run. The scene shows the scan and robot pose at the cursor. Timeline lanes show when /scan and /workbench/scan have messages and when map → odom starts; a signal with no messages is a dashed amber lane. The At-cursor panel lists observations only.
• Compare (key 3): two runs, as above. The difference list only says which run has which signal; it does not judge a cause.
• Live (key 2) appears only while the local service runs a job, and shows its states and events, not live samples. flightops workbench opens recordings read-only and starts no job, so Live stays unavailable there; it is for source checkouts with the developer image.

Imported recordings are labelled not_judged: Flightops did not run, isolate or judge them. The Task, Checks, Diagnostics, Logs and Evidence tabs show what the import holds.

Keys

Keys do nothing while a text field has focus.

--theme dark or --theme light sets the theme at start. Otherwise the app follows the system colour scheme.

Limits

• The scene is 2D. It draws laser scans from /scan only; other topics are counted, not drawn. No map layer is drawn, even when the recording has /map.
• The scene reads at most 64 MiB of each recording. Slice a larger one first with splashdown slice.
• Live is not available for opened recordings, and imported recordings are not judged.
• Simulation actions and the reviewed change flow need a source checkout and the developer image. Installed builds refuse them with a reason.
• Tested on an X11 desktop with an NVIDIA RTX 3080 and under Xvfb with Mesa. Wayland, integrated graphics and screen readers are untested.

See the known limits of the whole beta.

Troubleshooting