LAK

It s a drone autonomy research platform built around a simulated Skydio X2 quadrotor in MuJoCo. It implements a dual loop flight control architecture inspired by dual process cognition. System 1 is a 500 Hz reactive controller. It uses classical PID or L1 adaptive geometric control to stabilize the aircraft and reject disturbances in real time. System 2 is an LLM based meta controller that reasons asynchronously about physical faults detected by the fast loop. It deploys compensatory patches like feedforward force offsets, motor trim scales, and gain multipliers. All patches stay within a safety envelope and the reflex loop is never interrupted. A trigger layer watches position error, tilt, gyro rate, and force estimates, firing the LLM worker within 50 ms of sudden disturbances. A chaos engineering suite injects seeded faults to stress both controllers. These include motor cuts, tethered swinging payloads, gyro noise, and wind gusts. An evals harness runs headless benchmark suites over scenario presets. It computes a 14 metric registry plus pass fail verdicts with time to detect and time to patch metrics. Results are rendered as terminal tables and HTML dashboards. A FastAPI web dashboard provides live telemetry, one click chaos presets, an FPV camera feed from body fixed MuJoCo cameras, a mission setup page for payload wind and drone presets, and one click launch of a mirrored 3D viewer. The repo is a collaboration between Anurag and Feng-Yi. Anurag built the core runtime, evals suite, dashboard, and chaos framework. Feng-Yi contributed sim parameter and LLM timing findings, the verdict layer with timing metrics, the FPV camera system, and the mission setup page. How it solves the problem The pieces above add up to a robustness testing platform for drone controllers. A company brings its controller and plugs it in as System 1. The chaos suite then runs it through hundreds of seeded fault scenarios in headless simulation, which is fast and costs nothing to crash. The evals harness measures exactly how the controller behaves under each fault. How far it drifted. How fast it recovered. Whether it crashed. The verdict layer turns those numbers into a pass fail score with clear thresholds, plus time to detect and time to patch so engineers can see not just whether the controller survived but how quickly it responded. Because every run is seeded, the same fault can be replayed exactly, so a fix can be proven against the failure that motivated it. And because it runs headless in CI, every code change gets a robustness score before it ever touches real hardware. That is the gap in the market today. Nobody sells a lightweight fault injection harness with pass fail scoring for drone controllers in CI.