Product
HIL testing on your laptop and in CI.
Rigless emulates the flight controller and simulates the vehicle it flies, both on one clock, on a laptop or a CI runner. The runtime that boots your firmware is free software, and the engine that couples it to a plant and breaks things on purpose is what we license, per seat or per site.
YOUR BUILD
firmware.elf
unmodified
compiled by you, never patched
EMULATED BOARD
Cortex-M4 core
SPI1 · TIM3 · USART2 · DMA
BMI088 · BMP388 · ESCs · GPS
actuator writes down, sensor words back, the injector on the wire
PLANT
a rigid body, or your model
sensors with noise and lag
stepped at 400 Hz
one clock
instruction-counted virtual time
every access and every event lands in a trace that replays bit for bit
The runtime · free
Boot the firmware and see each register access.
Install it from crates.io, point it at an ELF and the firmware runs. Each register access goes to a peripheral model written in Rust and gets printed with the instruction count that produced it. GDB connects the way it would through a debug probe, and when it stops the core, the plant, the DMA engines, the chips on the bus and the timers stop too. You can set as many watchpoints as you like, where silicon gives you four. GDB sees ChibiOS and FreeRTOS threads, semihosting works, and you can halt at a given instruction count, all without reads from GDB changing the run. It runs in a container in CI at or above real time, and running an image twice gives the same accesses in the same order.
That's as far as the runtime goes. With nothing on the other end of the sensors, the gyro reads zero and the motor commands go nowhere until the engine adds a plant.
Start here
All of that is free. If you want to build against the engine, its interfaces are public in rigless-labs/hil, including the plant trait, the board declarations a plant steps against and the snapshot types. The engine itself is a signed binary.
The engine · rigless-hil
The engine adds the plant and the faults.
It runs your firmware against a plant, injects failures you wouldn't try on a real airframe, and records enough that you can hand a failing run to a colleague and watch it fail the same way on their machine.
Lockstep
The controller and the plant share one instruction-counted clock. If one pass of your control loop runs forty microseconds long, the plant sees that forty-microsecond delay on that step.
Plants
You write a plant in Rust against the published trait, and the engine steps it in lockstep with the firmware. We're planning Python plants, FMU import from Simulink or Modelica, and a way to run your plant in a separate process so we never need to see your model.
Faults
Take a chip off its bus, stick or bias one sensor while its twin keeps reading true, add noise from the run's seed, flip or drop a word on a bus, or take a rotor away. A test case triggers each one at a set time or when the firmware reaches a given instruction, and the run keeps going without a restart.
Tests
Assertions run against virtual time, so you can check that a value stays in bounds between two instants, settles before a deadline, or that a handler finishes within an instruction budget. A failure names the instruction it failed at. Results come out as JUnit XML, and you can call the tests from the harness you already use.
Replay
Runs are recorded and replay bit for bit. Diff two of them to find the first instruction where they differ.
Console
A timeline over the trace that you can scrub back and forth.
Server
Hosts the runners, licensing, SSO and an audit log. You can run it yourself if your data can't leave the building.
Built
The runtime
boards, peripherals, GDB, traces
Built
The closed loop
lockstep, plants, failures
Built
The engine
rigless-hil, any board or bench
Built
Verification
tests, requirements, reports, replay
January 1, 2027
Open launch
community license live
Late 2027
Boards and plants
more parts, FMI import, console
2028
Teams and programs
server, campaigns, SSO, audit log
2029
Qualification
DO-330 kit, aerospace parts
Plans
Four plans under one license.
Community
Free
Team
US$8,000 per seat per year
Enterprise
By order, per site
The fourth is Evaluation, which everyone starts on. It gives you ninety days of use inside your company.
Services
We can build it around your board.
Getting a virtual HIL running for your own hardware takes real work. Your MCU has to be modeled, the chips on its buses have to answer, and your plant has to be coupled in. We do it in four stages, in order, since you can't test a stage until the one before it works.
01
The board boots
We generate the register tables from the vendor's SVD, fix them wherever the SVD disagrees with the reference manual, and model the peripherals your firmware uses. The stage is done when your unmodified build gets to main and stays there, with each access it made along the way in the trace.
02
The chips answer
Next come the IMU on SPI, the baro on I2C, the receiver and telemetry radio on UART, the ESCs on their timer and any CAN nodes. We model each one from its datasheet, down to the init handshake your driver expects. It's done when your power-on self-test passes and the sensors read values a controller would accept.
03
The loop closes
We write your plant against the plant trait, from your equations or your existing model. Most of the work after that is getting the units, frames, sample rates and sensor lag right, along with the noise you measured on the bench. It's done when the controller holds what it's meant to hold.
04
It runs unattended
We write tests against the published API or drive them from your existing harness, turn the failures in your hazard analysis into test cases, and run campaigns across them. Golden traces fail the build when a number moves. It all runs on your own runners for each merge request, and it's done when the pipeline catches a regression nobody wrote a test for.
After stage four, a night of testing on your own hardware is a thousand runs over a thousand fault schedules, with the handful that broke the controller picked out. Any of those replays to the instruction where it went wrong.
What we need from you
- The firmware image, or the source and how it's built
- The part number and its reference manual
- The schematic, or what's wired to what
- The plant model, or the equations behind it
- An engineer who can answer a question within a day
What you keep
Your plant model, firmware and traces stay yours, and the license says so. Common parts we model during an engagement go into the open runtime, so they keep working after the engagement ends.
Parts and kits
Which parts are open.
Open, in the runtime
- STM32 parts
- nRF parts
- RISC-V parts
Lots of people use these parts, and lots of people reporting bugs is how a model gets good.
Closed, and priced
- Rad-hard parts, LEON, and FPGA SoCs
- Validated plant libraries
- The DO-330 data a DO-178C program needs to qualify a tool
The people who need these have budgets, and there's no community around them to share the work.
Tell us which board you're on.
Send the part number, the RTOS if you use one, and the failure you want to catch before it flies. We'll tell you what works today and what doesn't yet.