Project HERMES was a liquid rocket project at the Akademische Raumfahrtinitiative Schweiz (ARIS) from September 2024 to November 2025. HERMES was ARIS’s very first bi-liquid rocket and our entry in the 9 km liquid category at EuRoC 2025. With over 60 members, it was ARIS’s largest rocketry project to date.
HERMES was powered by a regeneratively cooled EthaLOx engine developed in the parallel HEPHAESTUS engine program, while recovery was handled by a guided recovery system that heavily iterated on the previous project, NICOLLIER.
We attended EuRoC in October 2025 and placed 11th overall. Unfortunately, a catastrophic pad abort meant that HERMES never lifted off. Even so, considering the project’s ambition and maturity, the attempt was a strong one, and we left the competition in good spirits.
I joined the project during its inception phase in June 2024 as one of four systems engineers. Although HERMES officially started in September, we had already started planning months earlier. Several of us were still active in management roles on the previous project, NICOLLIER, so HERMES had to be set up simultaneously.
A large part of our early efforts focused on establishing feasibility, recruiting members, defining the initial system architecture, obtaining the necessary approvals, and making the case to the board and other critics that such a program could be executed responsibly and successfully.
HERMES had originally been conceived as a two-year program. In the wake of NICOLLIER’s successful launch, however, we decided to compress it into a single year, preferring to fail fast rather than leave ARIS without an attempt at EuRoC.
With that, the goal became to:
Develop and fly a bi-liquid rocket to a target apogee of 9 km at EuRoC 2025, and successfully recover it with guided recovery.
…all within one year.
ARIS had no experience with fully bi-liquid propulsion in a rocket, and neither the previous nor the current team had hands-on experience with liquid or hybrid rocket engines. The last ARIS project to work in that area had been BERNOULLI, and by then that expertise was no longer part of the active organization. ARIS had also not targeted a 9 km launch in several years, guided recovery (one of NICOLLIER’s central goals) was still unproven at the time HERMES began, and ARIS did not yet have an engine powerful enough to get us off the pad.
We expected to fail in some form along the way. The potential upside was enormous, though: either we would make it work, or we would gather an extraordinary amount of knowledge and data in the attempt. In the end, we managed to push the project much further than many had initially expected.
If you haven’t yet, the HERMES intro video at the top of the page is our project introduction and worth a watch. For more depth there is also our reduced technical report (linked from our project website) — see Section 4: Launch Vehicle Overview for the system overview, which I authored.
HERMES is a ~5.5 m long, 179 mm diameter bi-liquid sounding rocket, split into eight modular sections from nosecone to engine bay. That modularity was essential because with over 60 people working on the system, subteams needed to be able to work independently.
The heart of it is the propulsion system: pressure-fed ethanol and LOx, with a high-pressure nitrogen COPV for pressurization. The engine, HEPHAESTUS Mk. IV, is a regeneratively cooled, throttleable EthaLOx engine developed in the parallel HEPHAESTUS program, with a nominal thrust of 3.5 kN, throttleable between 1.5 and 5.0 kN. The propellant tanks are custom-welded aluminum and double as structural elements of the airframe.
The Structures are built around minimal CFRP fairings, aluminum couplers, and bulkheads. Both the oxidiser and propellant tanks are the airframe in their respective sections.
The Avionics subsystem runs on a custom electronics stack with a flight computer, custom PCBs for sensors, comms, and power, all on a CAN bus. A CATS Vega provides independent backup for recovery.
The Recovery subsystem uses a parafoil-based, guided recovery system. The nosecone is separated at apogee, a drogue is deployed for stabilization, and a steerable ram-air chute is deployed at the desired altitude. The GNC algorithm then takes over control, and autonomously guides the system toward the target landing point.
The Remote Filling Station handles the remote loading of LOx and nitrogen, supplies the igniter, and powers the rocket on the pad, all connected through custom decouplers that retract pneumatically before launch.
Software runs across all systems: the flight computer on the rocket, the RFS computer at the pad, and mission control, deployed on consumer-grade hardware across two independent laptops in the mission control tent. Everything communicates via a custom MAVLink dialect. The flight and RFS computers run Rust applications built around configurable state machines, while mission control uses a combination of Grafana dashboards, data logging to InfluxDB, and custom controller apps.
For more pictures of the rocket, the team, and the test campaigns, see the HERMES photo gallery.
I was a systems engineer on HERMES. Together with the other systems engineers (Matteo Vass, Jakob Schreiber, and Thomas Abegglen) and our project manager, Pablo Scherpereel, I formed a core part of the project’s technical management.
What a systems engineer at ARIS actually does is a bit vague from the outside, and the role resists a clean description: you can list surface activities (owning the system architecture, managing interfaces between subsystems, driving technical decisions across teams), but the list never quite captures what the role really is. It boils down to ownership: if you own a system, your sense of responsibility drives you to slip into whatever roles turn out to be necessary, planned or not. In practice, my mandate was to help HERMES come together technically and organizationally, and to do whatever was necessary to maximize the chances of that happening. I’ve listed some of the more concrete things I did further down.
While systems engineers operate at the overall system level, at ARIS they are also deeply involved in subsystem-level work and decision-making. So to manage the large system, we divided subsystem responsibilities among ourselves. My primary responsibility was for the Recovery and Software subsystems, and I was also heavily involved in Avionics.
Systems engineering matters a lot on a project like this. Bi-liquid propulsion means much, much more complexity than a solid-motor rocket like the one we had in NICOLLIER: more custom components, more interfaces, and more people to manage.
As a systems engineer, you are the always-on-call engineer for the project: expected to resolve situations, answer questions from any subteam, catch mistakes early, and at all times hold the master plan, its backup, and the escape hatches in mind. For every decision, all the time. Dynamically planning around obstacles, adjusting to unfortunate circumstances along the way, and never, ever giving up. Because if your management no longer believes in the goal, then the cause is already lost.
Systems engineering is as much about managing the system as it is about managing the people working on that system.
My concrete contributions fall into two buckets: the day-to-day of the systems engineering role, and the specific things I built on HERMES: the sensor carrier board, the broader firmware footprint, and project-wide engineering process and tooling.
To make the SE role concrete: in practice that meant sitting in the weekly meeting of every subsystem I was responsible for, running and attending the management and SE syncs, maintaining a weekly view of the overall project timeline, and chasing whatever problems turned up along the way. I owned parts of the system architecture, evaluated architectural tradeoffs, planned, tracked, and verified requirements, pushed for a unified project-wide way of doing things rather than each subteam rolling its own, and held the bar on standards of work across the system.
A lot of the SE work is pushing structural decisions that change how the project runs. As one example among many: adding mandatory team-internal SDR/PDR/CDR reviews on top of the ARIS-wide ones, so each subteam got dedicated in-depth reviews of its own work instead of cramming everything into a single project-wide milestone.
Another big piece of the role is the integrated tests. SEs organise them and take leading positions in them. Having been flight director on NICOLLIER the year before, I wanted something a bit less stressful this year, and took on assembly lead for the upper section, which I practiced and then carried out during the dry runs and cold launches we ran as integrated tests of the full system. Things also go sideways: after a June 2025 helicopter drop test wrote off the rocket, I took care of the salvage operation, was on-site for the crash analysis, and sourced the replacement parachute afterwards.
EuRoC organisation and logistics also lived with the SE team. Mostly that is coordination on the ground once everyone is there, since the SEs are the people responsible for keeping the campaign running, plus the paperwork, the transport for the rocket and ground support, and the team travel around it.
Alongside all of this, I also put time into things that sat outside the SE role proper: most of the rocket renderings, and the HERMES intro video at the top of this page.
A bit of context on the embedded work: on NICOLLIER we had moved the whole system architecture to Rust, and I had been talked into bringing Rust to embedded too. It worked, but the embedded side was often rough around the edges. For HERMES I wanted a cleaner version of that stack, so I took it upon myself to push the embedded firmware and the quality of it forward.
I set up the hermes-firmware repository: the per-board workspace template, CI, and the hermes-can submodule integration every subsequent board built on. Getting the multi-board workspace to actually work required a cargo workaround that disables feature unification, so that otherwise-mutually-exclusive embassy-stm32 chip features could coexist in a single workspace. Aside from the sensor carrier, which gets its own section below, the firmware work I owned included:
ModbusFrame::parse that I pushed upstream to rmodbus along the way.I brought up and primarily maintained the HERMES CAN stack. hermes-can v2 is a full rewrite of the project’s CAN protocol library that I wrote, and I drove the subsequent semver discipline and message-definition cleanups as the design stabilised.
MAVLink was also my call. NICOLLIER had used a bespoke Rust serialisation crate (skynet) with hand-rolled packets, and for HERMES I wanted a more off-the-shelf solution that would scale better across teams and projects. I evaluated protobuf and a few other candidates before settling on MAVLink: XML-defined dialects, code generation into Rust and Python, and the mavlink-router / mavp2p multiplexer that handles multiple simultaneous endpoints (antenna and wifi) out of the box. I prototyped it end-to-end before committing, then set up hermes-mavlink with the initial hermes.xml dialect and introduced MAVLink at ARIS as the project’s telemetry protocol. It runs between the flight computer, the remote filling station, and mission control. Once the foundation was in place, I handed maintenance of the MAVLink messages off to our software team lead.
Back in NICOLLIER I had already taken care of the simpler sensor carrier there, so picking up the HERMES version was a natural fit. Embedded Rust was not widely familiar among our new members, so realistically the board would not have shipped without someone taking ownership of it, especially now that the sensor fusion had moved onto it rather than staying on the flight computer. I took it on.
The sensor carrier is the rocket’s primary state-estimation node: a custom STM32-based board on the HERMES CAN bus. It carries a fully redundant sensor set (two GNSS receivers, two IMUs, two magnetometers, two barometers, two humidity and temperature sensors) split across two independent sensor buses, with the IMU and GNSS paths kept on separate buses so that a failure on one side does not take the other down. The GNSS receivers are u-blox ZED-F9P modules, RTK-capable with two correction-stream inputs designed in, though we never ended up using them on HERMES. They were by far the trickiest and most finicky components I had to work with on the board. An on-board NOR flash provides storage for data logging; using it for board calibration was planned but only actually landed on ASTERIA. The board runs an attitude and heading reference filter on-board and publishes a processed state estimate out over CAN. I was the sole author of its firmware, its device drivers, its sensor-fusion integration, and the CAN message layer that exposes it.
I got involved in sensor selection and board architecture from early on, partly because I was not happy with what we had inherited from NICOLLIER. The biggest hardware-architectural change I pushed for was moving the GPS from the flight computer onto the sensor carrier itself, so that all sensor fusion could happen on one MCU instead of being awkwardly split between firmware and the FC. Doing it that way means more timely data, more control over it, and the ability to fuse before publishing onto the CAN bus, which lets you tolerate higher measurement rates and keep accuracy rather than bleeding it away in transport. Other improvements were splitting sensors across multiple buses rather than stacking them all on one, cutting back on unnecessary commonality between otherwise-independent sensors, and picking the right peripheral for the job (IMUs on SPI rather than I2C, f.ex.). I also pushed hard for including magnetometers in the sensor set, a call I have come to semi-regret in practice (more on that below).
The first sensor carrier (V1) still had several hardware flaws that became apparent as we started to use it: an STM32G473 with no double-precision FPU, so some of the GPS frame conversions ran too slow (V2 went to an STM32H723, also more pins and headroom for future expansion), a NAND flash chip instead of NOR (NAND support in embedded Rust is still thin and not something I wanted to build a logging path on in the time available), and the buses were not laid out as cleanly as they should have been. Some of that was on me; I had not been involved closely enough during the V1 design to catch it in time. For V2 I stayed much closer to the design. The V2 rework, which landed just a few weeks before EuRoC, cleaned up the architecture properly, and looked beautiful. That is the board we took to the competition.
To be clear on hardware credit: while I assisted in sensor selection, had very clear ideas on which peripherals should be mapped where and how, and took part in design reviews, the V2 schematic and layout themselves were entirely Carl’s work, which as you can see turned out beautifully:
I shipped both generations of the firmware: the first iteration in April 2025 in time for the drop tests, and Sensor Carrier V2 in October, just in time for EuRoC. The underlying drivers are also mine: the MS5607 barometric-pressure driver and the LSM6DSO32 IMU driver. The MS5607 driver later became the standalone ms56xx crate I published on crates.io, generalised across the family. A standalone LSM6DSO32 crate is yet to be released, but is in the works.
The hardest single piece of the integration was the magnetometers. The regret has less to do with the magnetometers themselves than with how much pain they were to make work. For a large part of HERMES we were still flying the steel AV frame inherited from NICOLLIER (the frame is the internal structure of the avionics bay that the boards bolt into; there had been no weight constraints back then, only cost ones), which is a hostile environment for a magnetometer: the steel frame disturbed the local field enough to saturate our LSM303AGR e-compasses (they have a range of ±50 Gauss), and Earth’s field is weak as fuck, as I rediscovered during tuning (f.ex. turning on the heating coils we used to warm up the hangar in winter had a measurable effect on the data). Magnetic declination and a handful of similar subtleties piled on from there. I got it working eventually though.
The magnetometers of course needed calibration, and this was quite an involved process. It had to be done with much of the rocket assembled, which meant five people coordinating the handling of a 4 m, 30 kg stack to run through the required orientations, and it had to be repeated for every instance of the sensor carrier. For each magnetometer on the board we estimated hard-iron and soft-iron biases.
Eventually our aluminium frames arrived during HERMES, which resolved the steel problem (the boards still needed good calibration, of course). We managed one more drop test with calibrated sensor carriers afterwards, which finally gave us usable yaw data normalised to north. Making this possible was something I had been personally pushing for, because ARIS has struggled with it for a long time: under the right conditions, combined with the GNSS-derived heading (from the 3D velocity vector), it lets us estimate wind magnitude and direction, which is very helpful for grounding some of the sysid data our GNC relies on. The magnetometer integration carries forward to ASTERIA (with adaptations); thankfully the steel frame does not.
Earlier in the project we also tested the Bosch BNO055, a 9-DoF sensor with on-chip orientation fusion. It was attractive on paper, since it did the whole orientation fusion internally and exposed a single fused output. In practice that output was not trustworthy enough to build on: it has documented orientation issues, its self-calibration was suspect, and the fused output showed behaviour we could not fully explain. I preferred to gather the raw sensor data ourselves and keep full control over the fusion, especially since the end goal was an EKF that would estimate orientation as one of its own states anyway, which makes externally-fused orientation more problematic than helpful. We did add pads for the newer BNO086 on V2 as a hedge, but never populated one because they are expensive, so the board supports it in theory but we never tested that path.
The production sensor fusion on the board was an AHRS-plus-GPS stack (an open-source attitude-and-heading library running against the IMU, magnetometer, and GPS data), paired with per-sensor filtering: a short moving average over the MS5607 barometer for the altitude-critical channel, a much slower exponential average on the ambient environmental pressure and temperature/humidity streams, and the magnetometer’s built-in low-pass. The whole pipeline was designed so that any individual sensor can drop out (bad bus, dead chip, missing GPS lock) and the rest of the fusion keeps producing usable output. Alongside that I also spent time experimenting with a full extended Kalman filter as a potential replacement. I wrote one from scratch as a spike (a 10-state filter tracking position, velocity, accelerometer bias, and barometer bias, with IMU control inputs and GPS plus barometer observations) and iterated on it against recorded sensor data, though most of it was simulated (with artificially added noise) so that I had ground truth to compare against.
We ended up not taking the EKF to production on HERMES. It still needed proper tuning and verification against the V2 hardware before we could trust it in flight, and with V2 arriving so late there was not enough time for either. I was also more focused on being the SE for our EuRoC preparation at the time, and there were more critical issues to deal with. Instead, we went with the proven and already set-up AHRS-plus-GPS stack from the drop tests, built on an open-source AHRS library I contributed a quaternion multiplication fix to upstream.
The tradeoff was acceptable because in our configuration, position estimation during ascent did not really matter in-flight. The only thing the rocket needs live during ascent is altitude, for apogee detection (we tried both prediction and direct detection) to trigger nosecone separation and subsequent chute deployment. Engine shutoff coordination would be the other typical reason to care about ascent state, but EuRoC’s impulse limits were tight enough that we were planning to burn all the way through without any early cutoff anyway. Everything else can be post-processed from logs after the flight. The EKF would mainly have benefited the ascent phase, since by the time we were in descent our GNSS was already extremely good thanks to proper placement of the Taoglas patch antennas feeding the ZED-F9Ps (we measured 1σ location accuracy at roughly 0.35 m horizontal and 0.5 m vertical across the whole drop test).
As part of the embedded work on the sensor carrier, I also defined its CAN message set with per-field accuracy and reliability documentation, and the body-fixed reference frame (X+ forward, Y+ right, Z+ down) that every HERMES sensor and GNC message is written against.
I wrote the project-wide requirements writing guide and the ICD strategy the subteams used for interfaces. The philosophy I kept coming back to: operate under the assumption that you have nothing available to you unless it is explicitly listed in your requirements; nothing exists unless you will it into being. I ran the verification campaign against the EuRoC Verification Control Document through to submission.
In March 2025 I shipped hermes-procedures: a versioned, automated system for writing and reviewing ARIS’s operational procedures. It replaced the scattered Excel tables we had used on NICOLLIER, which collaborated well enough but required 2–3 hours of manual prep the night before every integrated test to get procedures into a printable shape; nothing was standardised, the formatting drifted, and there was no export pipeline. hermes-procedures made procedures git-versioned, LaTeX-rendered, CI-checked, and required an SE review before merging to catch mistakes. I designed and built essentially all of the tooling: a custom LaTeX class for the procedure format, Python scripts for metadata validation and batch compilation, revision-history entries generated automatically from the git log, a devcontainer so contributors did not need a local LaTeX install, and later a self-hosted runner to keep CI fast. Every HERMES procedure was written on it from then on.
Looking back, the LaTeX stack was the wrong choice. Automation itself was actually fine, and because everything was embedded in git, some of it was genuinely nice (f.ex. CI rendered the git file history into each procedure document). But LaTeX syntax is annoying, outdated, and slow to compile, and git itself was a significant onboarding cost: most of our contributors were engineers, but not of the software kind, and getting them fluent with branches and PRs took time. For ASTERIA I pushed for a Typst-based successor, which is much easier for everyone to work with.
The core idea is what stuck, and the real lesson I took from it is this: if you cannot enforce a standard, nobody follows it. hermes-procedures looks as clean as it does (consistent naming, metadata filled in, no stray files) only because the CI rejected anything that did not conform. That is the real win: procedures as versioned, reviewed, standardised artefacts rather than ad-hoc documents.
Another real win from the same period was a common, standardised database of flight and drop-test data. I had gotten tired of how annoying it was to find old flight data when I wanted it (f.ex. for tuning the Kalman filter I was spiking on the sensor carrier), so I pushed for a unified schema and we put the relevant data in one place under it. Not every piece of data, but the rocket flights and the main drop-test campaigns, which were what any future GNC, analysis, or recovery work would actually want to go back to. The work involved back-converting the old NICOLLIER data into the new format, standardising on a logging setup, and a handful of shared primitives. Some of the early choices aged badly (a few of the datatypes were wider than they needed to be), but those are the kind of forgivable, instructive mistakes you learn a lot from. The core value is in having the data at all: in one place, in one shape, usable.
I also pushed for a proper repository architecture for the project as a whole: what lives in which repo, what depends on what, and who has write access where. NICOLLIER had been a single monorepo plus a handful of separate submodules whose boundaries never really made sense, and it struggled once the team grew. For HERMES the multi-repo structure is explicit: the interface crates (hermes-can, hermes-mavlink, hermes-gnc-interface) live in their own repos and are pulled into the board and service repos as git submodules, with clear ownership boundaries per repo and deliberate dependency directions so that subteams could work in parallel without stepping on each other.
After NICOLLIER I also realised that keeping software work organisationally bundled inside avionics was not going to scale. The work had been logically separate on NICOLLIER, but the team structure kept it permanently coupled to avionics timelines, with no room for quality-of-life improvements, tooling, or anything not on the critical path of a rocket integration. On HERMES I pushed for a properly dedicated software team, with its own PR-based review flow and its own repositories. By the end of the project it was about six people: two on ascent and ballistic simulations, the rest split across the groundstation, the RFS, the flight computer, and the interfaces between them. A small structural change, but one that gave the team room to work on things that made the rest of ARIS software better too.
On the repository side I applied branch protection and review requirements across HERMES repositories, and standardised the shared boilerplate.
Beyond HERMES specifically, I also pushed for technical reviews (system reviews, design reviews, that kind of thing, not code PRs) to run in a shared ARIS-wide review channel rather than each project keeping its own reviews siloed. Cross-team review is undervalued at ARIS: external eyes from other projects bring fresh perspectives and genuinely catch things, and the more we can get teams reviewing each other’s systems the better.
To get HERMES members fluent in embedded Rust before they had to write firmware, I prepared and ran an embedded Rust workshop for onboarding the team.
EuRoC (the European Rocketry Challenge) is an annual rocketry competition held in Portugal. Around 25 to 30 teams from across Europe are selected each year to launch rockets to target altitudes of 3 km and 9 km, making it a fairly unique opportunity on the continent.
To even be allowed to bring HERMES, we first had to clear a vertical integrated static fire of the engine on the full vehicle. We managed to pull that off about a week before the competition, days before everything had to be packed for logistics. From there the team travelled out to Portugal.
On launch day, the attempt ended on the pad. Shortly after ignition, a flight-critical pressure sensor returned a non-nominal value (most likely from an ice bubble), leaving the engine control unit (ECU) unable to confirm that combustion had actually started. The ECU did what it was designed to do in that case: it aborted, closing all valves and opening all vents to bring the rocket back into a safe state. Many teams in our category do not fly with any automated abort at all, and we remain convinced that having one is the safer design.
What turned the abort into a loss of the rocket was a leak. The ethanol valve did not seal cleanly, and residual heat in the chamber re-ignited the ethanol as it kept dripping through. The burning fuel set fire to the dry shrub under the pad, the flames climbed back up the airframe, and the engine bay burned out once the fins caught. The bush fire was eventually extinguished by the on-site firefighters. The fairing was a total loss, but the propellant tanks were later requalified and will fly on ASTERIA, and most of the piping and a fair amount of the electronics came through intact.
Even so, getting ARIS’s first bi-liquid attempt this far, and ready for EuRoC just one year after the project started, exceeded most expectations going in. A few things in particular went well:
Had we not aborted, our pre-flight simulations placed the likely apogee around 8.7 km, though ASTERIA’s newer simulations, with a more accurate model of the ramp-up phase and its losses, now place it closer to 7 km. ASTERIA now has a full year to fix the known issues in the system, iterate on it, and fly it at EuRoC 2026.
For the authoritative post-flight report, please see the HERMES Post Flight Analysis Report.
HERMES was harder than it was supposed to be in almost every way. We compressed a two-year program into one. We had no prior team experience with bi-liquid propulsion. We built a new engine, a new airframe, a new recovery system, and a new ground station in parallel, with a team of sixty people, most of whom had joined for this project specifically. And we made it to the pad.
What HERMES did not do in flight, ASTERIA now inherits and gets to finish. The propulsion architecture, the avionics stack, the software, the recovery system — all of it carries forward. That is also why I am still involved with ASTERIA, now as a coach rather than in the middle of it.
The best account of what HERMES actually was still sits in the photo gallery, with annotated images that tell the story better than I can here.