Physical-robot observation

Confirm that MIRA exposes live PX4 status—without commanding it.

When a physical MIRA is already powered for normal maintenance, this source command subscribes to one PX4 status topic and writes a small observation. It does not arm, enter Offboard, call a service, publish velocity or establish that the vehicle is safe to fly.

Updated 2026-09-23 · RLSOK

Download the MIRA observer

Use it only in an already running maintenance session

Keep the vehicle disarmed and propellers removed or otherwise disabled under your existing lab procedure. Do not power or launch the system solely for this observation. The collector is useful only when the normal ROS 2 and PX4 bridge are already available to the owner.

The MIRA status observer has been included since Local Check 1.5.6 and records the actual MIRA checkout commit, dirty state and origin. Running that observer still needs the robot's ROS 2 environment and px4_msgs/msg/VehicleStatus; the desktop package alone does not create a live robot connection.

Download the pinned observer and capture once

Download the 24,612-byte v4 ZIP and checksum from the immutable GitHub release. Its SHA-256 is 0f21780c75a09b88a4567210226b9ac5ad386020ee5d46435c412c1e1567c033. This version waits for transient unknown ROS publisher identity and rejects it if still unresolved at the deadline; the broader v3 bundle's MIRA script did not reject that timeout case. Source the same ROS 2 environment that already sees the MIRA status topic, then run the read-only capture.

curl -fLO https://github.com/realitywarden/rlsok/releases/download/mira-status-observer-v4/rlsok-mira-status-observer-v4.zip
curl -fLO https://github.com/realitywarden/rlsok/releases/download/mira-status-observer-v4/rlsok-mira-status-observer-v4.zip.sha256
sha256sum -c rlsok-mira-status-observer-v4.zip.sha256
unzip rlsok-mira-status-observer-v4.zip
cd rlsok-mira-status-observer-v4/experimental/composable-shadow
python3 mira_status.py \
  --source-root /path/to/mira \
  --output mira-status.json

What the observation records

The ROS distribution, RMW implementation and domain ID visible to the collector.
One unambiguous publisher endpoint for /fmu/out/vehicle_status with the expected px4_msgs/msg/VehicleStatus type.
The observed arming state, navigation state, failsafe flag and preflight-check flag.
The selected checkout's full commit, dirty state, checkout name and origin URL without persisting the local absolute path.
A SHA-256 digest over the complete observation so a later copy can be checked for accidental changes.

What it deliberately cannot prove

A visible ROS publisher is not authenticated Pixhawk, airframe or vehicle identity. The file does not prove firmware provenance, estimator correctness, battery condition, failsafe configuration, sensor calibration, command-path safety or flight readiness. Even a preflight-check flag is an observed PX4 field, not an RLSOK safety decision.

The collector creates one subscription. Focused tests reject ambiguous publishers and incomplete status messages, and reject publisher or service-client APIs in this reader. Those tests establish the implemented zero-command boundary; they are not a physical MIRA run.

How this advances a real integration

Return the observation together with the exact MIRA checkout commit and the read-only offboard_velocity_control bench_mode value. RLSOK can then keep the live ROS observation separate from source mapping and from any later isolated Shadow comparison.

Do not treat the returned JSON as permission to arm or move. A physical result exists only after the system owner runs the command in their actual environment and confirms the setup context; publishing this collector does not establish that result.

Sources and verification scope

Source code and guides describe implementation and setup. Release notes identify reported checks and their limits. Publication alone does not establish customer use or physical-robot validation.

Frequently asked questions

Does this connect RLSOK to a physical MIRA?

The code can read the live status topic when the owner runs it in that ROS 2 environment. Publication alone is not a connection or physical result; an owner-run observation is still required.

Can the command arm, switch to Offboard or publish cmd_vel?

No. This collector creates a subscription only. It has no publisher or service-client surface and does not invoke the MIRA command path.

Is this included in the Windows and Mac Local Check downloads?

The observer and its source-bound checks have been included since 1.5.6. A live run still requires a real ROS 2 environment with px4_msgs; installing the desktop package does not by itself prove a connected robot or active controller state.

Continue with the relevant guide

Try the local example without an application. For setup or integration help, you can also contact us.