From dc46339b632018b0633be241df206ca1df1c29ec Mon Sep 17 00:00:00 2001 From: "Claude (auto-RE)" Date: Thu, 13 Aug 2026 22:35:36 +0000 Subject: [PATCH] re(flight): rows pinned by world-Y, and nothing yaws -- the yaw gap is answered The probe now pins which non-forward row is up and which is right, instead of taking the D3D convention on faith: row world-Y means: [0.469, 0.883, -0.000] forward = row 2 -> up = row 1, right = row 0 CONFIDENT That is the OPPOSITE of the assumption the previous run used, so that run's yaw and pitch columns were swapped -- under the correct labels its ly+ reading of 154.1 deg/wall-s is PITCH, which is what a left-stick Y should do. Measured with the unknown inputs FIRST, each passing a liveness check: rx 0.0 0.0 0.0 ry 0.0 0.0 0.0 LB 0.0 0.0 0.0 RB 0.0 0.0 0.0 lx roll 209.8 ly pitch 154.1 These zeros are trustworthy where the previous run's were not: the craft was verified alive between inputs, and the probe aborted the moment it stopped moving rather than reporting the clean zeros a destroyed craft produces (it did abort, after lx+, which is why lx/ly are carried from the earlier run rather than re-measured). So NO PAD INPUT YAWS THE CRAFT. AV_Yaw_* (45/25) exists in the definitions but nothing on the right stick or the shoulders drives it, which upgrades the old "yaw: no input found" from a failure to find one into a measurement that the remaining candidates do nothing. The natural reading is that yaw is a consequence of banking rather than a commanded axis. Not covered, and not claimed: the d-pad (tactical map) and the face buttons (fire/weapon select). Neither is a plausible flight axis; neither was measured. --- docs/re/captures/axis-probe-rows-pinned.csv | 5 +++ docs/re/flight-speed-law.md | 46 +++++++++++++++++++++ 2 files changed, 51 insertions(+) create mode 100644 docs/re/captures/axis-probe-rows-pinned.csv diff --git a/docs/re/captures/axis-probe-rows-pinned.csv b/docs/re/captures/axis-probe-rows-pinned.csv new file mode 100644 index 0000000..5ffd845 --- /dev/null +++ b/docs/re/captures/axis-probe-rows-pinned.csv @@ -0,0 +1,5 @@ +input,roll_deg_s,yaw_deg_s,pitch_deg_s +rx+,0.0,0.0,0.0 +ry+,0.0,0.0,0.0 +LB,0.0,0.0,0.0 +RB,0.0,0.0,0.0 diff --git a/docs/re/flight-speed-law.md b/docs/re/flight-speed-law.md index ee90d1d..4ed16a2 100644 --- a/docs/re/flight-speed-law.md +++ b/docs/re/flight-speed-law.md @@ -458,3 +458,49 @@ Method note: the tell that the *old* result was broken was two conditions agreei too well (pitch ≈ roll). The tell that this one is sound is that they now **disagree in the direction the definitions predict**, on two independently-bracketed phases. Data: [`captures/roll-about-forward-axis.csv`](captures/roll-about-forward-axis.csv). + + +## Which input drives which axis — and the yaw answer ✅ + +`tools/re-capture/axis_probe.py` holds one channel at a time (file pad, so every +other channel is exactly zero) and decomposes the result into **all three** rotation +components at once, rather than measuring one axis through a row that moves under any +rotation — the flaw that once made roll and pitch produce identical numbers. + +**The row labelling is measured, not assumed.** `entities2` pins row 2 = forward +against velocity; the probe pins the other two by comparing **world-Y** in flight: + +``` +row world-Y means: [0.469, 0.883, -0.000] forward = row 2 + -> up = row 1, right = row 0 CONFIDENT +``` + +That is the **opposite** of the D3D convention an earlier run assumed, which means +that run's *yaw* and *pitch* columns were swapped — under the correct labels its +`ly+` reading of 154.1 °/wall-s is **pitch**, which is what a left-stick Y axis +should do. + +| input | roll | yaw | pitch | | +|---|---|---|---|---| +| `rx` right-stick X | 0.0 | 0.0 | 0.0 | nothing | +| `ry` right-stick Y | 0.0 | 0.0 | 0.0 | nothing | +| `LB` | 0.0 | 0.0 | 0.0 | nothing | +| `RB` | 0.0 | 0.0 | 0.0 | nothing (it is the nose gun) | +| `lx` left-stick X | 209.8 | ~0 | ~10 | **roll** | +| `ly` left-stick Y | ~0 | ~0 | 154.1 | **pitch** | + +These zeros are **trustworthy**, unlike the previous attempt's: the four unknown +inputs were measured *first*, each passing a liveness check, and the run aborted the +moment the craft stopped moving instead of reporting the clean zeros a destroyed +craft produces. + +**So no pad input yaws the craft directly.** `AV_Yaw_*` (45/25) exists in the unit +definitions but nothing on the right stick or the shoulders drives it — the earlier +❔ *"no input found"* is upgraded from "we could not find one" to **"the remaining +candidates measurably do nothing"**. The natural reading is that yaw is a +*consequence* of banking rather than a commanded axis, which a reimplementation +should model as such. + +🟡 Not covered: the **d-pad** (the tactical map) and the **face buttons** (fire / +weapon select). Neither is a plausible flight axis, but neither was measured here. +Data: [`captures/axis-probe-rows-pinned.csv`](captures/axis-probe-rows-pinned.csv).