[ptescher]

Step 0 of the plan to make the battlefield keep up with the camera (#95). It adds the plan, a way to measure the lag, and the first numbers. It changes no behaviour a commander sees.

What it adds

• plans/battlefield-latency.md: keep the GPUI app and the Bevy 3D view as two processes and fix the join between them, with a go/no-go to one process.
• A number on each request. The battlefield protocol numbers each request (seq), and each picture comes back with the number it was rendered for. The magic changes to BFL2/BFR2, so an old view and a new app refuse each other instead of misreading.
• teleoperation_battlefield::lag: for each motion of the camera, how long the picture on screen has been out of date, and how many new pictures came. The app logs each motion. The 3D view logs its frame rate every 5 s while an app is connected.
• The expectation «The picture keeps up with the camera»: at most 80 ms behind, and at least 45 new pictures a second, during a 3 s pan. It is Status: pending until step 1, because it fails today.
• Driver support. The commander's driver arranges a live picture and observes the two numbers. During the pan it draws the window 60 times a second, because in a test run the system does not draw the window, and the app asks for pictures only when it draws.

The numbers (plans/battlefield-latency-results.md)

During a 3.1 s pan, on an Apple M4, in a practice game with ten SITL drones:

	Measured	Go/no-go
New pictures	1 (0.3 a second)	45 a second
Picture out of date by	544 ms median, 1728 ms at the 90th percentile	80 ms
3D view frame rate	8 to 11 frames a second (15 to 19 while loading)
Valley load	127 to 136 s in a game, 35 s alone

• The stillness gate (steady_request) is the largest part. Step 1 removes it.
• The 3D view is slow on its own. At about 100 ms a frame, no later step can meet the targets without a lighter view. So the plan moves step 5 up, to just after step 1.

Tests

• Unit tests: teleoperation_shared 20 passed, teleoperation_battlefield 21 passed (6 new for lag), visualization_battlefield 1 passed.
• The new expectation, before it was marked pending: it failed with the numbers above. That is the red evidence for step 1.
• The app's existing camera and battlefield tests on this branch:
  • Passed: keys, mouse at the edge, wheel, PORTRAIT, a click on a camera, the minimap state, Space, and «Follow a drone to the west tower».
  • «The battlefield shows the valley in 3D» failed once, at its 180 s limit, then passed on a rerun (127 s), the same time as master's build (127 s). The valley takes about 130 s to load in a game, so this test is close to its limit and can flake.
• Tooling: expectation check: 0 errors. cargo clippy on the changed crates: clean. cargo fmt: done.
• Not run: the whole workspace test suite, and --selftest. Nothing here touches the flight model.

To run the measurement yourself (the valley takes over two minutes to load, so the default 120 s budget runs out):

cd domains/teleoperation/command && SIM001_SUITE_BUDGET=600 cargo run --release -- --expect --only "keeps up with the camera"

Remove Status: pending from the expectation first; a pending test is not run.

🤖 Generated with Claude Code