Short definitions for words used in the user guide. See build features to check what the beta includes.
Session
A saved Flightops workspace for one project and ROS environment. It holds observations and results so you can return to the same investigation later.
ROS underlay
The ROS 2 installation that provides commands and libraries, such as Humble under /opt/ros/humble.
ROS overlay
A workspace you built on top of the ROS installation. Source its install/local_setup.bash after the underlay to make its packages available.
ROS domain
A number that separates ROS 2 discovery groups. Nodes in different domains usually do not see each other. Flightops and the nodes must use the same domain.
RMW
The ROS middleware implementation that carries discovery and messages between nodes. The selected RMW must be compatible across the nodes you want to see.
Node
A named component in a ROS 2 system. A node can publish or receive data on topics. One running program can contain several nodes.
Topic
A named path over which ROS 2 nodes publish and receive messages, such as /chatter.
TF
ROS 2's transform system. It describes how coordinate frames relate, for example where a camera is relative to a robot base.
MCAP
A file format for recorded messages and their timestamps. Live capture needs the ROS recording packages. Analysis of a saved MCAP with splashdown needs no ROS environment; splashdown replay needs a sourced ROS 2 installation.
Readiness
Checks that say whether a launched system met conditions declared for startup. Readiness reports only those checks; it does not prove that a robot is safe.
Capture
Saving selected live ROS messages to a recording. A capture can have gaps or limits, so check its status and recorded evidence before relying on it.
Playback
Reading messages from a recording again. Playback is separate from a live ROS system and does not restart the original nodes.
Result
A saved report from a check or analysis. A result describes the inputs and outcome recorded for that run; it does not prove the system's current state.
Evidence
The files and recorded facts used to explain or review a result, such as a recording, log, configuration, or observation. Evidence can be incomplete or out of date.
Fixture
A prepared test input or simulated system used to check behavior. A fixture helps reproduce a case, but it is not evidence from a user's live robot.
In splashdown, a replay fixture is a versioned directory made by splashdown fixture from a window of a recording: fixture.yaml, the recorded stimulus (recording.mcap) and triage.md. splashdown replay publishes the recorded inputs into the nodes under test and checks the fixture's criteria on what they publish back. The gate runs fixtures as one of its stages. See the splashdown guide (source repository).
Command
An instruction typed into a terminal, such as flightops doctor or ros2 node list. flightops is the Flightops program; ros2 is a command provided by the ROS installation.
QoS
Quality of Service: settings for message delivery, including reliability, history, and durability. Publisher and subscriber settings must be compatible for messages to reach the subscriber.
Owned launch
A ROS launch started by Flightops. Flightops tracks and stops the processes it started when you quit. Attaching to a system does not give Flightops ownership of its existing processes.
Scene Workbench
The Flightops desktop app, opened with flightops workbench. It opens one or two saved recordings read-only and does not connect to ROS or a robot. It has three views: Replay (key 1) plays one run in a 2D scene; Live (key 2) shows jobs that the Flightops service runs, not imported recordings; Compare (key 3) shows two runs on one time cursor. See the Scene Workbench guide.
Gate
The check that lcc (also called launchcommit) runs on a change. lcc run checks out a commit into a disposable workspace, then runs the dependency audit, build, lint, tests, replay fixtures and scenarios as numbered stages. It writes a verdict. A stage that did not run reports SKIP, never PASS. See the launchcommit guide (source repository).
Proof
The record of one gate run: the verdict.json file (schema flightops.proof-record/0) and its evidence bundle. It records what ran, on which commit and environment, and the result of each stage. A proof describes that run only; it is not a hardware approval.
Highbay pool and slot
highbay keeps a pool of reusable colcon workspaces for one repository, ROS distribution and CPU architecture. Each workspace in a pool is a slot. highbay acquire leases a slot, and highbay release returns it. A slot that still holds uncommitted or unpushed work is quarantined instead of reused. See the highbay guide (source repository).
Flightlead coordinator and crewmate
flightlead (preview) sets up a coordinator agent: a coding agent, such as Claude Code or Codex, started in a flightlead directory. The coordinator reads projects but does not edit them. It gives each task to a crewmate, a short-lived worker agent that works on one task in its own highbay workspace, in a terminal pane you can watch. See the flightlead guide (source repository).
Skill
A Markdown guide that teaches a coding agent one ROS 2 topic, such as QoS or launch files. flightschool install copies the 14 Flightops skills into a project (.claude/skills, or .agents/skills with --agents). See the flightschool guide (source repository).