// the find
elodin-sys/elodin
Elodin simulation and flight software monorepo.
Elodin is a full-stack aerospace simulation and flight software platform targeting drones and small spacecraft. It ships a custom time-series database, a Multiplicative Extended Kalman Filter, NixOS-based flight computer config for NVIDIA Orin, and a Python/JAX simulation SDK with a 3D editor — all in one monorepo. The audience is small teams building autonomous vehicles who want to close the loop between simulation and hardware without stitching five unrelated tools together.
- The MEKF in fsw/mekf is real aerospace math, not a toy physics integrator — quaternion-based attitude estimation that can actually run on hardware is genuinely useful and rare in open source.
- elodin-db as a shared telemetry bus that works identically in simulation replay and live flight is clever architecture; it means your analysis code doesn't branch on 'am I in sim or on hardware'.
- nox-py's JAX integration lets you JIT-compile physics and run vectorized Monte Carlo sweeps with essentially no extra code — that's a meaningful speedup over Python-loop-based parameter sweeps.
- The Nix + NixOS stack for the Orin flight computer is reproducible in a domain where 'it worked on my drone' is the norm; the flake.nix approach means firmware deploys are deterministic across the team.
- The setup story is brutal: mandatory Nix, git-lfs, Just, an Arm Mac 'strongly preferred', and a first-time nix develop that warns it 'can take awhile' — this will kill adoption for anyone who just wants to try the simulator.
- The scope is enormous for a 535-star project with 39 forks: custom DB, MEKF, sensor firmware, NixOS modules, Python bindings, Monte Carlo, 3D editor. If the team shrinks, several of these layers will rot; there's no obvious seam where you could fork just the simulator without pulling in the rest.
- The Python SDK (nox-py) is a maturin-built Rust extension and the documentation is thin — the API reference is a single markdown file and the examples are the real docs, which means any non-obvious behavior requires reading Rust source.
- The Aleph hardware board is load-bearing for the flight software half of the repo — the NixOS modules, sensor firmware, and serial bridge all assume you have their specific hardware, so a significant portion of the codebase is unusable without the physical board.