Test Flightops on your ROS 2 system

Use a laptop or desktop terminal at least 120 columns by 36 rows. Start with a non-actuating ROS 2 system or simulation you know how to stop. Record the distribution, Python version, domain, and command you used.

Starting with a clean machine? Use the fresh Ubuntu demo walkthrough for ROS 2 installation, a package you can build yourself, and a TurtleBot3 simulation before running this checklist.

1. Install, activate, and check the environment

Install the beta for your Ubuntu version with installation. Activate this device once; it needs the internet and the key from your beta email (details):

bash

flightops license activate

In a new terminal, source your ROS environment and run:

bash

flightops --version
flightops license status
flightops --help
flightops doctor
ros2 node list --no-daemon

Expected: license status reports a valid license, doctor finds the terminal, reports ROS ready, and shows the distribution and domain you intended. If ROS is unavailable, use flightops setup or troubleshooting.

2. Attach to running nodes

Start a harmless ROS system in another terminal. Then run:

bash

flightops

Use ? for keys, 1 for Health, 3 for Topics, 4 for Nodes, and 2 for Graph. Press r to refresh. Press q to leave. The ROS nodes you started separately should still be running. Note the time from starting Flightops to the first screen and to a populated graph.

3. Launch a known file

Choose a launch file for your test system. Substitute your package and file:

bash

flightops launch PACKAGE FILE.launch.py

Or use flightops ./path/to/file.launch.py. Press L to inspect its log, then Esc to close the log view. Press q to stop the launch. Check that the owned launch processes stop and any unrelated ROS processes remain running. Start the launch with --session-dir DIR before launch. Reopen with flightops --session-dir DIR attach from the same directory and ROS environment. Confirm it shows the retained launch record without starting another copy. If you use XML or YAML files, repeat with one known file of each format.

4. Inspect a saved result

Use an existing Flightops result JSON or run the recording quickstart. Then run:

bash

flightops results /path/to/result.json --open

Expected: Flightops prints an HTML path and the desktop report shows the saved result. Opening a saved result does not require ROS.

5. Open the Scene Workbench

From a terminal in your desktop session, open the two sample Nav2 runs:

bash

flightops workbench --sample

Expected: a desktop window opens in Compare with the runs nav_working and nav_lidar_topic_fault. Press 1 for Replay, Space to play, and 3 to return to Compare. Close the window; the command returns. If the window is black, repeat with --gl. Then open one of your own recordings with flightops workbench --run NAME=PATH. See the Scene Workbench guide and its troubleshooting.

6. Try the component commands

These commands are on your PATH after install. Each one prints its version:

bash

onscope --version
splashdown --version
lcc --version
highbay --version

With your ROS system running, run onscope sourcing and onscope doctor. Run splashdown stats on one of your MCAP files, or follow the recording quickstart. In a project you can change, run lcc init and lcc probe, and review the generated .launchcommit.yaml before any lcc run. The advanced guide covers each command.

7. Try the coding-agent tools

Install the ROS 2 skills into a scratch project and check them:

bash

mkdir -p ~/flightops-skills-test
cd ~/flightops-skills-test
flightschool install
flightschool validate .claude/skills

Expected: flightschool install prints one installed line per skill. Use flightschool install --agents for Codex and other agents that read .agents/skills. See flightschool (source repository).

flightlead is a preview. It needs tmux, git and Claude Code or Codex:

bash

flightlead init ~/flightlead-test

Expected: it prints Coordinator ready in .... Start your coding agent in that directory. See flightlead (source repository).

To give a coding agent the four Flightops MCP tools, register the installed flightops-mcp command as an MCP stdio server. See integrations (source repository) for the configuration.

8. Try optional features

Use declared launch conditions only if you have a suitable topic or lifecycle node. Press L for each result. passed records a single observation; overall readiness remains unknown.

For API-based AI, follow the AI tutorial. flightops ai status is local. flightops ai test sends a synthetic greeting to the selected provider and may incur usage. The OpenAI and Anthropic setup wizard lists candidate models after you enter a masked key; a model-list response does not prove the selected model can answer an assistant request.

For the ChatGPT account route (preview), install Linux bubblewrap if Flightops reports it missing, then use flightops ai setup to install the pinned Codex runtime and sign in through the browser. If sign-in was deferred, run flightops ai login. Run flightops ai test to check one bounded isolated text answer. Record whether account verification and the assistant answer both succeeded. Native Codex tools remain disabled.

The Gym smoke run is a research preview. It needs /dev/kvm, QEMU, a readable x86_64 kernel and static BusyBox; see Gym (source repository) before you run flightops-gym-smoke.

Optional Jev trial

Follow the Jev guide. Record flightops --version and the configured Jev model.

Run flightops ai jev status; it should report local configuration without a provider call.
Select two known evidence artifacts with flightops ai select-evidence. Deny the first review and confirm no request runs. Repeat and approve the exact packet.
Check that the selected receipt is relevant, or that insufficient evidence is reported where appropriate. Compare the choice with the original source.
Try flightops ai ask --jev with the same question and artifacts. Confirm the TypeSafe and conversational requests have separate reviews and all receipts appear in the second packet.
Change a source while approval is pending; the stale request must fail. Check that unknowns and failed measurements never become passing diagnostic results.
Save judgments for the offline comparison. Record actual usage and elapsed time; leave missing measurements unknown. Quality needs representative real incidents as well as synthetic checks.

Optional developer check for the Codex text boundary

This check needs a source checkout, because the script is not part of the install. With the pinned Codex CLI 0.156.1 and Linux bubblewrap, run from the checkout:

bash

.venv/bin/python scripts/verify_codex_assistant.py \
  --codex /path/to/codex \
  --output output/codex-native-check.json

Replace /path/to/codex with the installed pinned binary. The harness uses a local synthetic server on loopback and supplies no account credentials. It checks the native runtime boundary; it is separate from a real ChatGPT account and model trial. Review the generated JSON before reporting a result.

Record the outcome

For each step, note pass or fail, elapsed time where requested, the exact command, flightops --version, and a relevant log or screenshot. Automated checks and manual host trials are separate evidence. Do not count this checklist as a completed trial until you retain its results. The known limits list the checks that are still open for the beta. Send results and problems to beta@flightops.dev; see feedback and support.