fabi/Syplheed-Reborn
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

re(flight): roll DOES depend on speed -- the withdrawal is reversed

Browse Source 
Measured about the FORWARD axis (roll_axis.py), which is the fix the withdrawal
specified: express the new up-vector in the old (up, right) basis and take
atan2(u.w_old, u.u_old), so the component along forward -- what pitch produces --
is dropped by construction. The old probe watched a non-forward matrix row, which
sees any rotation that moves it, and that is why two different stick axes produced
the same numbers.

Stage 02, file pad, single-axis holds (lx=32767 with every other channel exactly
0, trigger held in the same write since the pad state is written whole), 5 s
settles, 8 s dwells, each phase bracketed by HUD-clock screenshots:

  min speed (LT)  1 856.9 deg / 8.01 s wall, clock x1.247 -> 185.9 deg/game-s
                  vs AV_Roll_Min 200
  max speed (RT)  1 181.2 deg / 8.02 s wall, clock x1.218 -> 120.9 deg/game-s
                  vs AV_Roll_Max 125

So roll behaves exactly like pitch: the rate cap falls as speed rises and
_Min/_Max mean "at minimum / at maximum speed". The withdrawn claim that roll
shows NO speed dependence is reversed, and the axis rule is now confirmed on a
second axis instead of contradicted by it.

Both land just under their caps (93% and 97%), the right side for a rate limit.
The shortfall is NOT explained and no claim is made about it: candidates are the
craft not being exactly at min/max speed after 5 s, and the 20 Hz swept-angle sum
undercounting.

The tell that the old result was broken was two conditions agreeing too well. The
tell that this one is sound is that they disagree in the direction the definitions
predict, on two independently bracketed phases.
This commit is contained in:
Claude (auto-RE)
2026-08-13 21:57:10 +00:00
parent 3d3d6726fa
commit 850b04c606
2 changed files with 351 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

38
docs/re/flight-speed-law.md
View File

@@ -420,3 +420,41 @@ measurement specified above.
**The clock ratio has now been measured three times in three flights: 1.260, 1.311,
1.383.** It is not a property of the machine but of the moment, so any rate probe
must bracket its own phases.
## Roll, re-measured about the forward axis — the withdrawal is reversed ✅
The earlier roll result was withdrawn because the *measurement* was wrong, not the
input: watching a non-forward row of the rotation matrix sees **any** rotation that
moves that row, and pitch moves it as much as roll, which is why two different stick
axes produced the same rates. `tools/re-capture/roll_axis.py` measures rotation
**about** the forward axis instead — express the new up-vector in the old
`(up, right)` basis and take `atan2(u_new·w_old, u_new·u_old)`, so any component
along forward (what pitch produces) is dropped by construction.
Run on stage 02 with the container-safe file pad, which matters here: the pad state
is written whole, so the stick is deflected on **exactly one axis** (`lx=32767`,
every other channel exactly 0) while the throttle trigger is held in the same write.
5-second settles, 8-second dwells, and each phase bracketed by HUD-clock screenshots
because the clock ratio is a property of the moment (1.260/1.311/1.383 previously).
| phase | swept | wall | HUD clock | per **game** second | definition |
|---|---|---|---|---|---|
| min speed (`LT`) | 1 856.9° | 8.01 s | 01:20.64 → 01:30.63 (×1.247) | **185.9 °/s** | `AV_Roll_Min` **200** |
| max speed (`RT`) | 1 181.2° | 8.02 s | 01:37.11 → 01:46.88 (×1.218) | **120.9 °/s** | `AV_Roll_Max` **125** |
**Roll DOES depend on speed**, and the withdrawn claim ("roll shows no speed
dependence, unlike pitch") is **reversed**. Roll behaves exactly like pitch: the rate
cap falls as speed rises, and `_Min`/`_Max` mean *at minimum / at maximum speed* —
the same rule the pitch work established, now confirmed on a second axis rather than
contradicted by it.
Both measurements land **just under** their caps (93 % and 97 %), which is the right
side for a rate limit. 🟡 The shortfall is not explained: candidates are the craft not
being exactly at min/max speed after 5 s, and the swept-angle sum slightly
undercounting at 20 Hz. Neither is worth a claim without measuring it.
Method note: the tell that the *old* result was broken was two conditions agreeing
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).