First use on
your machine.

1. Check prerequisites and record the host

This beta build requires Ubuntu 22.04, x86_64, Python 3.10, and ROS 2 Humble. Ubuntu 24.04 is unsupported by this archive. Install ROS using the official Humble instructions first. The demo needs demo_nodes_cpp; managed recording additionally needs rosbag2 and rosbag2_storage_mcap.

Use a user account without an existing Flightops installation. A local VM or container is useful for debugging but does not count as a second physical machine.

evidence="$HOME/flightops-engineer-check-$(date +%Y%m%d-%H%M%S)"
mkdir -p "$evidence"
cat /etc/os-release > "$evidence/os-release.txt"
uname -a > "$evidence/uname.txt"
python3 --version > "$evidence/python-version.txt" 2>&1
systemd-detect-virt > "$evidence/virtualization.txt" || true
command -v flightops || true
source /opt/ros/humble/setup.bash

2. Install and retain the transcript

Download flightops-install.sh using the command on the landing page. Inspect it, then run the following in Bash. pipefail preserves an installation failure when output is saved with tee.

set -o pipefail
bash flightops-install.sh 2>&1 | tee "$evidence/install.txt"
export PATH="$HOME/.local/bin:$PATH"
flightops --list | tee "$evidence/installed-versions.txt"
flightops --verify | tee "$evidence/installed-verify.txt"
flightops license activate
flightops license status | tee "$evidence/license-status.txt"

Activation shows the beta terms, asks you to type yes, and reads the license key from your beta email at a hidden prompt. It needs the internet once. Every other Flightops command needs an activated device.

Stop at any failure and keep its output. The installer prints the platform and exact archive digest, downloads into a temporary directory, verifies it, and installs in your home directory. No GitHub account or sudo is needed. For custom paths use --prefix "$HOME/flightops-test" --bin-dir "$HOME/flightops-test-bin" and follow the printed PATH correction.

Release flightops-20261022-0.2.0b1-humble-public3 · expected archive SHA-256:

301b9f977b147b1cc670afcf353b57ca7c46ec58c212b32f26e63d6a142c387f

This build derives from source commit 9ec4bac7264b939be1439cbec8c52a82019b558c. Redistribution notices and packaging changes are documented inside the archive.

3. Attach to a harmless running system

Use a terminal at least 120 columns × 36 rows and a desktop browser around 1440 × 900. Source ROS in every terminal. Choose a domain from 1–232 unused by other ROS systems; the example uses 181.

source /opt/ros/humble/setup.bash
export ROS_DOMAIN_ID=181 ROS_LOCALHOST_ONLY=1
ros2 pkg prefix demo_nodes_cpp
flightops doctor | tee "$evidence/doctor.txt"

In a second terminal with the same ROS setup and domain:

ros2 run demo_nodes_cpp talker

In the first terminal, run flightops. Confirm Topics, Nodes, and Graph show the talker. Press ? for controls, then q to quit. The separately started talker must keep publishing. Run flightops attach to reopen without starting another talker. Stop the external talker with Ctrl+C when finished.

4. Manage a launch and reopen its session

Stay in the first terminal, in the same working directory and with the same ROS setup and domain as step 3. Choose the launch's session directory when you start it:

cat > "$evidence/engineer-talker.launch.py" <<'PY'
from launch import LaunchDescription
from launch_ros.actions import Node

def generate_launch_description():
    return LaunchDescription([
        Node(package="demo_nodes_cpp", executable="talker",
             name="engineer_talker", output="screen")
    ])
PY
flightops --session-dir "$evidence/launch-session" launch "$evidence/engineer-talker.launch.py"

Check the node and its log (L). Press q; the launch owned by this invocation must stop. Flightops first sends SIGINT, as Ctrl+C does in ros2 launch, and waits up to 6 seconds for a clean shutdown before it sends SIGTERM, then SIGKILL if needed. Nodes started elsewhere keep running.

Reopen the launch's session from the same working directory, with the same ROS environment (setup file, ROS_DOMAIN_ID and ROS_LOCALHOST_ONLY):

flightops --session-dir "$evidence/launch-session" attach

The retained launch should show as exited with its log, and nothing should be relaunched. A plain flightops opens a separate attach session instead. If the directory or ROS environment differs, Flightops leaves the launch record intact and opens a sibling session named launch-session-<key>; note it if that happens. Save the session location and screenshots. Use flightops results --help for the installed results commands.

Closing the terminal window, or losing an SSH connection, while a launch runs also stops the launch and any recording owned by that invocation. If you try this, confirm from another terminal with ros2 node list that engineer_talker is gone. These behaviours passed automated checks in local containers for this build; your result on a separate physical machine is the independent check.

5. Return later and report

At least six hours later or the next day, reopen the same installation and saved result: from the same working directory and ROS environment, run flightops --session-dir "$evidence/launch-session" attach again. Record elapsed time, whether the machine rebooted, whether you could find the result, and any confusing steps. Retain the result files and their SHA-256 values, install/verify transcripts, host details, screenshots, and notes.

Report time to first useful screen; attach/quit/reopen and managed-launch outcomes; any recorder checks performed; and anything not tested. Configuration-change and hardware checks require a safe bench and independent before/after observations. Say “not run” if no bench is available.

Send evidence through your agreed project channel after reviewing it for private data. A successful download or local container check does not establish independent human acceptance. The Gym bundle is separate and is not available through this site.