Investigational: timed gimbal waypoints for repeatable moves

[erik-sutton95]

Investigational: customizable, time-set gimbal waypoints so an operator can repeat the same move (A → B → C with holds). Mimo-style “repeatable shoots.”

This is research first. There is no waypoint / keyframe / timed-path opcode in the repo today.

Related: gimbal speed + modes thread · roadmap index

What already exists (not waypoints)

• Analog stick stream at 40 ms (0x04/0x01, center 1024 ±550)
• Recenter / flip
• Captured Follow / FPV / speed / tilt-lock builders (UI still missing — other thread)
• Heartbeat 0x04/0x05 is currently swallowed (“not a running-state signal”)

Zero hits for waypoint, keyframe, or timed gimbal paths.

Investigation plan

• Capture Mimo (or other) waypoint / pan-tilt-zoom path sessions on Pocket 4 Pro. Store under gitignored captures/. Do not commit pcaps.
• Document whether the camera has a path engine, or whether Mimo is just recording stick samples on the phone
• If camera-side: table opcodes, payload, ACK, replay
• If phone-side: decide whether OPC should sample stick + clock locally and play back 0x04/0x01 (timing jitter vs SoftAP congestion)
• Safety: cancel on rec stop, disconnect, or stick touch; never fight ActiveTrack
• Explicit non-goal until capture: shipping a UI

Likely outcomes

1. Camera path engine — implement against the table, like other captured SETs
2. Phone-side playback of stick samples — prototype with a 2-point A/B first, then time holds
3. Won't do — if the move is not repeatable enough on SoftAP UDP to be production-safe

Done when

We either have a labeled capture + a go/no-go note in docs/protocol-notes.md, or we close this as won't-do with the evidence.

Concrete threads: gimbal speed and modes

[erik-sutton95]

Tracked as maintainer spike #80.