06-litewing-ml-autonomy-plan

LiteWing ML autonomy — phased plan

Goal: turn the LiteWing + Positioning Module into a machine-learning robotics project, culminating in vision-based "hover around me" following.

Hardware on order: LiteWing drone (ASIN B0GNN1MGC7) · Positioning Module (ASIN B0GNN2L81Z: VL53L1X downward ToF + PMW3901 optical flow) · still needed: 1S 650mAh 30C LiPo + charger.

Architecture (locked): off-board brain. The drone cannot see and cannot run models; a PC on the drone's WiFi runs perception + planning in Python and streams setpoints via cflib (the firmware speaks Crazyflie CRTP over UDP). The drone's only jobs: hold attitude, hold height (ToF), hold position (flow), obey setpoints.

flowchart LR
    CAM[Webcam / phone cam] --> ML[PC: detection + pose\nYOLO / MediaPipe]
    ML --> PLAN[Relative-position planner]
    PLAN -->|cflib setpoints, WiFi UDP| DRONE[LiteWing\nflow + ToF hold]
    DRONE -->|telemetry: battery, height, flow| PLAN

Phase gates

Phase	Deliverable	Gate to pass before next
P0 Manual flight	stable hover + landing (see first-flight checklist)	3 clean sessions logged
P1 Module bring-up	positioning module installed; height-hold flight in app	30 s hands-off height hold
P2 Python link	cflib connects; telemetry read; scripted takeoff→hover→land	script runs 5/5 times
P3 A→B flights	scripted waypoint runs (relative moves) over textured floor	≤30 cm landing error over a 2 m leg, 3/5 runs
P4 Follow-me (the ML piece)	webcam + person detection → drone holds station ~1.5 m in front of user, tracks slow walking	60 s continuous track without manual takeover
P5 Stretch: floor mapping	grid flight logging flow XY + ToF height → 2D elevation/occupancy plot	one rendered map of a room

Phase notes (annotations)

P1 — Module bring-up

Module mounts to the bottom 2×12 header; battery relocates to the top of the board (wiki).
May require flashing the shield firmware: browser ESPtool.js over USB-C — bootloader.bin @0x0000, partition-table.bin @0x8000, LiteWing_Shield.bin @0x10000 (positioning-module docs).
Optical flow needs texture: patterned rug/mat = good; uniform glossy floor = drift. Buy/borrow a cheap patterned area mat for the test zone.
Added mass shifts the hover throttle point and eats flight time — re-run the hop test after install.

P2 — Python link

pip install cflib on the PC; join the drone's hotspot (PC loses internet while connected — pre-download everything).
Port the standard Crazyflie flow-deck examples (MotionCommander pattern); LiteWing wiki confirms cfclient/cflib compatibility.
Log battery voltage every flight — scripted flights must abort at the same threshold the app warns at.

P3 — A→B

Flow positioning is dead reckoning: define "points" as relative displacements from takeoff, not absolute coordinates. Expect drift growth per leg.
Keep legs ≤2–3 m, speed ≤0.5 m/s, height 0.5–1 m (flow sensors have a sweet-spot height band).
Metric per run: commanded vs measured (tape-measure) displacement — this becomes the baseline error dataset, and it's your first "data" artifact.

P4 — Follow-me (ML)

Perception: MediaPipe pose or YOLOv8-nano on the PC webcam, 15–30 fps is plenty. TypeScript option: run perception in a small web app and bridge to Python, but Python end-to-end is fewer moving parts — recommend Python here despite the TS preference; revisit at P5.
Control: map person's pixel position + estimated distance → target offset → velocity setpoints (not position jumps); clamp hard (e.g. ±0.3 m/s) and add a deadband so the drone doesn't twitch.
Safety: geofence in software (max radius from takeoff, max height 1.5 m), instant-land hotkey, fly with props away from face height, never over people. One person = pilot with a kill key while testing.
Latency budget: camera→model→setpoint under ~150 ms feels fine because the drone self-stabilizes between commands.
Failure default: lost detection for >1 s → hold position; >5 s → auto-land.

P5 — Floor mapping (stretch)

Boustrophedon (lawnmower) grid over the mat; log (flow-x, flow-y, ToF-z) at ~20 Hz; render with matplotlib as heightmap. Obstacles appear as ToF discontinuities under the flight path only — set expectations: this is a floor profile, not SLAM. Forward-obstacle mapping is out of scope for this airframe (no forward ranging, no on-board camera).

Routing note (poor-mans-ai)

Open/educational content throughout — no Fable-lock. Suggested delegation when executing: cflib example-porting → Codex; perception-script scaffolding → Sonnet/Codex; any live "current best tiny person-detection model" checks → Comet; phase reviews + safety-critical control code review → Fable/Opus inline.

Log

Date	Phase	Result	Notes
2026-07-12	plan	written	hardware in transit; battery still to buy