PERF-P01 second half: benchmark PX4's control loop head-to-head on the same hardware

[avrabe]

relay#361 landed the falcon cascade baseline. This is criterion (d) of SWREQ-FALCON-PERF-P01, which is deliberately not discharged by it.

What we can now say, and what we still cannot

full_cascade_tick   1.2413 us   <- all five stages, one tick, dev host
  iekf_propagate    1.1256 us      91 % of it
  position/attitude/rate/mixer  ~108 ns combined

We can say what our cascade costs. We cannot say it costs less than the alternative. The second is the claim worth having — and it is the one claim no open-source, verified-systems or commercial competitor can answer, because none of them carry machine-checked control-law proofs.

What this needs

1. PX4 control-loop instrumentation — per-cycle timing for the equivalent path (EKF2 + position + attitude + rate + mixer), not a SITL round-trip.
2. Same hardware, both sides. A host-side comparison is worth something but is not the claim; the architecture argument is about no RTOS on the control path, no dynamic allocation, fused single address space, and those only pay off on the MCU.
3. Therefore this is gated on the hardware round (Hardware bring-up round (v1.57+): the 7-item flight-readiness register #157) for the version that matters.

Suggested sequencing

A host-side PX4-vs-falcon number is cheap and worth having as a directional check — it would catch the embarrassing case where we are slower despite the structural argument. But it should be labelled as directional, not published as the comparison.

The on-silicon head-to-head is the artifact. It should be scoped with the hardware bring-up, not before it.

Why this is filed rather than left in the requirement

PERF-P01 stays implemented until this runs. Filing it means the gap has an owner and a place, instead of living only as an unmet criterion inside an artifact nobody re-reads.

Blocked by #157. Refs #8.

🤖 Generated with Claude Code