Cubli (Armonia) — Space Challenges Program 2026

A 156 mm reaction-wheel cube that balances on an edge and on a corner, taken from Lagrangian derivation through Simscape multibody simulation to working hardware — and validated against its own flight telemetry.

Standing on a single corner, unsupported. Three reaction wheels, a Teensy 4.1 running a 2 ms control loop, and a gain set designed for this specific corner.

And the telemetry underneath it — six minutes of exactly that, without falling:

373 s continuous. Tilt RMS 0.40°, peak 1.25°, wheels never reaching the 40 rad/s policy cap. Raw log: data/corner/corner-balance-373s-2026-08-20.log.

Official documentation: the full Technical Design Document submitted by Team Armonia to the Space Challenges Program 2026 — requirements, sizing, CAD, electronics, control and results in one 127-page document.

---

What it achieves

	Result	Source
Corner balance, longest run	373.5 s continuous, tilt RMS 0.40°, max 1.25°	log
Corner balance, quietest run	278 s, tilt RMS 0.25°, max 0.92°	log
Edge balance	197 s continuous, tilt RMS 0.58°	log · report
Disturbance rejection	recovers ~3° pushes in 0.08–0.20 s; trips at the 25° policy limit	report §3
Edge release	recovers from 6.18°, settles under 0.5° by 9.6 s	report §5
Predicted envelope	2.76°–3.14° worst-case recovery, all 8 corners	envelope study

The hardware sits inside the envelope the simulation predicted, and the run above is momentum-bound rather than torque-bound — exactly the binding constraint the model identified before the cube was ever switched on.

The system

Structure	156 mm printed PETG-CF frame (150 mm in the frozen CAD), 1.615 kg assembled (1.633 kg with the strut added during bring-up), 3 ballasted reaction wheels
Actuation	3 × T-Motor Antigravity 4006 (Kt 0.02513 N·m/A) on 3 × mjbots moteus-n1 FOC drivers on a CAN-FD bus (5 Mbps-capable, run at 1 Mbps)
Sensing	Bosch BMI270 IMU at the cube's geometric centre — 130 mm from every corner
Compute	Teensy 4.1 running the control loop at a 2 ms period (500 Hz; the TDD design analysis assumes 400 Hz); XIAO ESP32-C6 as a Wi-Fi telemetry bridge
Estimator	reduced-attitude complementary filter with gyro-bias states (kP = 4, kI = 0.5)
Control	per-corner and per-edge reduced-order LQR, yaw-projected — 8 corner gain sets, 12 edge gain sets
Operating point	τ_max 0.12 N·m, wheel-speed cap 40 rad/s (firmware policy, not a hardware limit)

The engineering story

1 — Derive the plant. The 3D Lagrangian derivation is worked from scratch and specialised to the 1D/2D edge case, with CAD → model parameters and an attitude-representation study that ends up rejecting quaternions for corner balance and choosing a reduced attitude instead — argued, not assumed.

2 — Prove it on a 2D panel first. A Simscape panel model with four dedicated nonlinearity studies — saturation envelope, discrete-loop delay, IMU lever arm, friction sensitivity. The 1D-jig-to-3D-cube strategy states exactly what transfers and what does not.

3 — Build the cube model three ways. A 9-state linear design plant, a Simscape multibody model built from imported STEP geometry, and a fast nonlinear plant with sensors and actuator limits. They agree to A err 1.7e-07 and within 1 % through the transient — which is what makes the thousands of bisection runs behind the recovery envelope trustworthy.

The accelerometer lever arm is the dominant sensing effect. Fed raw, the cube falls every time, at any IMU position. The complementary filter rejects it almost entirely — but there is a cliff past ~150 mm, which is why the IMU sits at the geometric centre.	All eight corners balance, but each needs its own gains. Apply the primary corner's gains elsewhere and six corners diverge at the open-loop rate. The antipodal corner almost works — a 13 s fall that short tests score as a pass.

4 — Find the real limits, then design to them. A 48-point Bryson grid moves the envelope by 2 %; the actuator chart moves it by 4×. The conclusion — the envelope is set by hardware, not by the controller — is what keeps the rest of the project realistic about what tuning can and cannot buy. The shipped weights are chosen on robustness to inertia error, not on peak performance: qw = 10 costs 4 % against the grid optimum and is the only set that survives ±20 % on Θ.

5 — Climb a staged bring-up ladder on hardware. Every control mode is reached through the same five stages, each of which must pass before the next is flashed: open-loop torque → damping only → position + damping → full law → release. The ladders live in firmware/ — panel, cube, edge, corner, and a separate Wi-Fi link ladder.

6 — Measure, and correct the record when it disagrees. The hardware test reports are written to be falsifiable: the rate-filter A/B is reported as not a clean comparison and the reasons are given; a firmware comment claiming "20–30 dB of attenuation" is shown to be ~6 dB with the filter theory to prove a first-order filter cannot do better. Simulation values that later proved wrong are struck through and corrected in place rather than quietly edited.

Repository map

├── docs/           official Technical Design Document, theory, design studies and test reports
│   ├── dynamics/       Lagrangian derivation, attitude, CAD→parameters, cube envelope
│   ├── simulation/     panel model build guide, controller workflow, 4 nonlinearity studies
│   ├── testing/        hardware test campaigns, fine-tuning plan
│   ├── electronics/    electrical design guide + schematic PDFs
│   ├── bom/            component reference, motor notes, CAD↔BOM handoff
│   ├── references/     literature, with DOIs
│   └── archive/        pre-build planning notes and superseded write-ups
├── simulation/     MATLAB + Simulink/Simscape
│   ├── panel-2d/       the 1D/2D panel model and its LQR design
│   ├── cube-3d/        the 3D cube: params, plant, nonlinear sim, Simscape, studies, CAD
│   └── validation/     tools that plot hardware telemetry against the model
├── firmware/       Teensy + XIAO, organised as bring-up ladders
│   ├── panel-bringup/  cube-bringup/  edge-bringup/  corner-bringup/  link-bringup/
│   ├── cubli-ui/       the consolidated final system: firmware, dashboard, tools
│   ├── imu-calibration/  xiao/
│   └── archive/        superseded builds, kept for provenance
├── data/           curated flight telemetry (see data/README.md for formats)
├── figures/        every plot, render and demo video
└── hardware/       KiCad schematic, PCB and project libraries

Reproducing the results

Simulation needs MATLAB with Simulink, Simscape and Simscape Multibody, plus the Control System Toolbox. See simulation/README.md for the exact run order — several scripts depend on workspace state left by earlier ones and will tell you so if you skip ahead.

addpath(genpath('simulation'))
cubli_demo          % self-contained 3D recovery demo — no Simulink needed

Firmware is Arduino-IDE / arduino-cli sketches for Teensy 4.1 and XIAO ESP32-C6. Start at firmware/README.md; to actually run the cube, firmware/cubli-ui/README.md is self-contained.

Team and credits

The cube was built in one month for the Space Challenges Program 2026 (Sofia, Bulgaria) by a six-person team: Athanasia Nikolova, Andrea Liang, Deyan Nikolaev Vlaev, Niccolò Tonetto, Suvanna Viriyanti Wu and Pablo Urioste. Their roles are listed in Table 5 of the Technical Design Document.

This repository, and the software in it, is the work of two of them:

Pablo Urioste (@pablourioste)

• Systems integration — the systems engineering that joined every subblock (control, IMU, moteus, dynamics, Wi-Fi and GUI) into one working system, and the integration of all of it into the code that runs the controller: the consolidated cubli-ui firmware and the final corner bring-up sketches.
• moteus — calibration and operation of the three motor drivers.
• Remote communication — the telemetry and Wi-Fi stack and its tooling: the XIAO bridge, the cubli-ui dashboard and analysis tools, and the Wi-Fi variants of the bring-up stages.
• IMU calibration.
• Testing — hardware testing of the cube, together with Niccolò.
• Documentation — lead of the final documentation of the whole process (the Technical Design Document), except the control part.

Niccolò Tonetto (@NiccoloTonetto)

• Control — sole owner of the control and estimation design, and sole author of the control analysis in the Technical Design Document: Section 8 (Control Algorithms & Approach) and the control validation results of Section 9.
• Plots — every control, simulation and results plot, both in the Technical Design Document and in this repository (figures/simulation, figures/hardware).
• Test analysis — the analysis of the hardware tests and the test reports in docs/testing.
• Dynamics and written analysis in docs/: the Lagrangian derivation, the attitude-representation study, the CAD-to-parameters method, and the 2D panel Simscape model with its four nonlinearity studies.
• The 3D cube simulation chain — per-corner plant, reduced-order LQR, nonlinear sim, recovery-envelope sweeps and figure generation.
• Electronics — schematic, PCB and BOM.
• The five-stage bring-up ladder used for every control mode.

Both — the hardware testing of the cube, carried out together.

A note on the history: the portfolio restructure (511f285) moved every file. Because of that, git log on a current path shows only that commit. The history before it is at 4cb3738, and git log --follow <file> traces a file through the move.

Status and known limits

This is a working balance controller, not a finished vehicle. Known gaps, all documented rather than hidden:

• Only corner [-1,-1,-1] has been flown. All eight corners are geometry-complete and have verified gain designs, but the Kp matrices for corners 2–8 have not been transcribed into firmware — and running a corner on the wrong corner's gains is worse than not identifying it at all.
• Multi-corner locomotion is currently off the table on six of eight corners. A structural strut added during bring-up shifted the COM enough that their equilibrium tilt now exceeds their own recovery envelope. The analysis is in the repo; the fix is a counterweight, not a gain change.
• No jump-up. Balance only — the braking jump-up of the ETH papers was not attempted.
• Edge balance has no simulation study. It went straight from estimator design to staged hardware bring-up, so its numbers are measured, not predicted, and the reports say so.
• Several plant parameters are still estimates — wheel Coulomb friction, viscous damping and the real continuous-torque limit are flagged PLACEHOLDER in cubli_gains.h pending spin-down and thermal tests.
• The wheel-speed cap costs about 20 % of available capability. Raising it requires balanced wheels and a re-run of the gain grid, in that order — it is not a constant you can edit.

References

Full citations with DOIs in docs/references/. The core prior art is the ETH Zurich Cubli — Gajamohan et al. (IROS 2012, ECC 2013) and Muehlebach & D'Andrea (IEEE TCST 2017).

License

Original work in this repository is MIT licensed — see LICENSE. Third-party vendor libraries, JavaScript and fonts keep their own licenses — see NOTICE.