Check declared launch conditions

Flightops can watch for named topic messages and lifecycle states after it starts a ROS 2 launch file. These checks are optional. They observe the ROS graph; they do not activate nodes or run project scripts.

Add a readiness file

Create .flightops/readiness.json in your project, or save the following JSON at another path:

{
  "schema": "flightops.runtime-readiness/0",
  "phase": "after-entrypoint",
  "timeout_s": 20,
  "messages": [
    {
      "topic": "/robot/status",
      "reliability": "best_effort",
      "durability": "volatile"
    }
  ],
  "lifecycle": [
    {"node": "/robot/controller", "state": "active"}
  ]
}

Replace the example names with names from your system. A file needs at least one message or lifecycle condition. Set the message QoS to match the publisher. The timeout is shared by all conditions and can be at most 120 seconds.

Declare an expected rate (schema /1)

Use "schema": "flightops.runtime-readiness/1" to add min_hz and/or max_hz (numbers above 0, at most 10000, min_hz not above max_hz) to a message:

{"schema": "flightops.runtime-readiness/1",
 "messages": [{"topic": "/scan", "min_hz": 8, "max_hz": 12}]}

The readiness verdict does not change: a message condition still passes when one message arrives. The terminal samples the topic's received rate for one second on each refresh and shows it beside the declared range. Health warns only when two of the last three full samples fall below 0.8 × min_hz (and min_hz × 1 s is at least 2) or above 1.2 × max_hz. Samples are taken at the Flightops observer, so a busy observer or a lossy link can lower them. /0 files keep working.

Run a launch with an explicit file:

flightops --readiness ./readiness.json launch my_robot bringup.launch.py

If Flightops recognizes your project, you can omit --readiness and it will read PROJECT/.flightops/readiness.json. Use --project /path/to/project to select a project explicitly. --readiness works only with launch, not attach. Flightops checks the JSON before it starts the launch process.

Read the result

Press L in the terminal to see each check beside the launch log. A check can report passed, timed_out, failed, cancelled, or not_checked. Flightops checks messages first, then lifecycle states. If the deadline expires, the terminal stays open so you can inspect the failure. The command exits with status 1 when you leave it. Reopening the launch's session with flightops --session-dir DIR attach shows the old result as history; it does not rerun the check. See reopen a launch session.

passed means Flightops received one message under the chosen QoS, or the named lifecycle node reported the chosen state once. Another process with the same ROS name may have satisfied the check. A retained transient message may also predate this launch. For that reason, Flightops still reports overall robot readiness as unknown. Do not use this result as a hardware safety decision.

Schema limits

• phase must be after-entrypoint for public launch.
• JSON is limited to 64 KiB. Each of messages and lifecycle accepts at most 16 unique absolute ROS names.
• Message reliability is reliable or best_effort; durability is volatile or transient_local.
• Lifecycle state is unconfigured, inactive, active, or finalized.

For limits that apply to the beta, see known limits. The test checklist has the manual path.