Project ASTERIA is the current bi-liquid rocketry project at ARIS, running from October 2025 with the goal of flying at EuRoC 2026 in the 9 km liquid category. It is the direct successor to HERMES and NICOLLIER, inheriting HERMES’s vehicle architecture, propulsion system, and ground support infrastructure, and the guided recovery work that NICOLLIER proved in flight. The challenge for the year is to take those first-generation systems and turn them into something mature and reliable enough for a real 9 km campaign.
After two years of hands-on systems engineering on NICOLLIER and HERMES, I have stepped back from day-to-day ownership and into a coaching role, focused on helping the new team succeed rather than running subsystems myself.
I support the team mainly in systems engineering, avionics, recovery, and the new state-estimation team that ASTERIA spun up this year. In practice, that means helping wherever experience is most useful: reviewing designs and PRs, giving feedback, challenging assumptions, and pointing out problems that are easy to miss when you are deep inside a single subsystem, but much more obvious with experience.
Beyond coaching, I am still actively contributing to ASTERIA on the firmware, sensor carrier, and GNC sides.
I did the initial port of the HERMES firmware codebase into asteria-firmware and set it up for the avionics team: the just-based build and flash system (newly introduced in ASTERIA to make working across multiple workspaces less painful), CI setup, and the asteria-tool CLI for talking to the boards from a host machine. To get the team productive on it, I also prepared and ran an embedded Rust workshop (an ASTERIA-flavoured successor to the one I originally built for HERMES).
I have since spent significant time designing a new repository layout that makes it easier to share code across crates and escapes the limits of running everything in a single Cargo workspace (a real pain on HERMES, since Embassy’s mutually-exclusive chip features cannot coexist in one workspace). On the boards themselves I have also been experimenting with proper flash-chip integration, and am working on a shared parameter read/write layer on top of the flash chip that gives the CLI one uniform way to talk to a board and drive its functions.
The sensor carrier lineage I started on HERMES continues on ASTERIA as the V3 board, and I am still maintaining and iterating on it: there were several architectural details I was not satisfied with on HERMES V2 that I now have the time to iron out. A large part of my current work on the board is integrating the state-estimation team’s stack into the firmware and the CAN message layer.
The sensor-carrier work is also what eventually pushed me to write ekf2-rs, a Rust API around PX4’s EKF2 state estimator core that I have since published as its own crate.
Post-HERMES, I spent significant time on asteria-gnc bringing the codebase onto a properly maintainable footing: end-to-end mdbook documentation, CI gates for build, format, and clippy, and an architectural cleanup pass that split the crates more cleanly and reworked the simulation configuration to be more general and easier to extend. On top of that I wrote a simulation plugin system that lets simulations be composed from self-contained plugins, plus the initial set of those plugins (KML and CSV trajectory export, and a GeoTIFF-backed EnvironmentDEM for terrain-aware sims). To get the team going on it, I ran a dedicated GNC workshop on the codebase.
Some of the work has also pushed back out into the open-source ecosystem:
RpcService primitive for embassy-sync for dispatching work from an async context to a dedicated runner (some of the most difficult code I’ve ever written).const support for nav-types.