EDGE-IO: Calibrated Learned Inertial Odometry Across Quadrotor Platforms

November 6, 2026

Status

Ongoing work. A paper is in preparation (target venue tentative); there is no preprint or public code yet. Authors: Sasanka Kuruppu Arachchige and Joni-Kristian Kämäräinen. This page summarises the method and the results so far, and will be updated as the cross-platform experiments finish.

Publication

Sasanka Kuruppu Arachchige and Joni-Kristian Kämäräinen, EDGE-IO: Calibrated Learned Inertial Odometry Across Quadrotor Platforms, in preparation (venue tentative).

@unpublished{KuruppuArachchige2026EDGEIO,
  author = {Kuruppu Arachchige, Sasanka and Kämäräinen, Joni-Kristian},
  title  = {{EDGE-IO}: Calibrated Learned Inertial Odometry Across Quadrotor Platforms},
  note   = {In preparation},
  year   = {2026}
}

Introduction

A drone's IMU works in the dark, in fog and through motion blur, but integrating it directly drifts within seconds. Learned inertial odometry fixes much of this: a network looks at a short window of IMU data, plus the rotor signals on a quadrotor, and predicts the vehicle's velocity, which an Extended Kalman Filter (EKF) then fuses with the IMU. For that fusion to work, the network also has to say how sure it is. An over-confident prediction pulls the filter off course; an under-confident one is wasted.

EDGE-IO is my framework for building, testing and eventually deploying such estimators on small flight computers. It has three goals:

• Calibrated velocity. Predict a velocity distribution, not just a value, and check that the filter stays statistically consistent.
• A benchmark that can tell real gains from noise. Four public quadrotor datasets, cleaned, with 8 training seeds per model and significance tests.
• One model for many drones. Every dataset logs rotor activity differently (rpm, rad/s, PWM, thrust command), so today each drone gets its own network. EDGE-IO is moving towards one shared encoder that adapts to a new drone from a few minutes of flight.

Built on AI-IO and VeloBins

EDGE-IO builds on two published methods by other groups:

• AI-IO (Cui et al., arXiv 2603.00597, code): a Transformer that regresses body velocity from IMU and rotor speeds, fused in an EKF. EDGE-IO starts from its open-source code and encoder.
• VeloBins (Azhari et al., arXiv 2608.29720): replaces the regression head with a decoder that predicts a probability over 512 velocity bins per axis, trained on error-conditioned Gaussian labels. The mean and variance of that distribution become the filter's measurement and its covariance.

I re-implemented VeloBins on top of the AI-IO encoder in one PyTorch package, matching the paper's parameter counts exactly (69.8k encoder + 6.8k decoder), and fixed several upstream issues on the way, for example an input normaliser that kept updating its statistics during testing and filtering.

Method

• Encoder (shared). A 1 s window at 100 Hz. Separate 1-D convolutions for the accelerometer, the gyroscope and the four rotor signals, followed by a 2-layer, 8-head Transformer.
• Decoder (per platform). The VeloBins bin decoder gives a full velocity distribution per axis. Its mean and variance go to the filter as they are, with no hand-set scaling.
• Filter. The EKF propagates with the raw IMU at 100 Hz and takes a velocity update at 10–20 Hz. Its noise settings are tuned per dataset on validation flights only, and its consistency is measured with the normalised estimation error squared (NEES).
• Thrust map (per platform, in progress). A fitted per-rotor model turns each drone's actuation signal into the same physical unit, mass-normalised thrust in m/s² per rotor, so a shared encoder sees inputs that mean the same thing on every drone.
• Small by design. The full network has 76.7k parameters. A JAX and ROS 2 port for on-board deployment is the next engineering step.

A benchmark that can tell the difference

• Four public datasets: AI-IO, NanoBench, TII-RATM and NeuroBEM, from four different quadrotors and four actuation signals.
• Cleaned data. The cleaning only removes data, and every decision is logged: 20 duplicate NanoBench flights, AI-IO files whose ground truth is 18–51% interpolated, extrapolated tails and ground-truth gaps.
• 8 seeds per model. On the AI-IO data, seed-to-seed spread alone was 6% in velocity error and 22% in trajectory error, the same size as the improvements reported for VeloBins on that dataset. Every comparison below is a mean over 8 seeds with a significance test.
• Fair filtering. The filter for each dataset is chosen on validation data, then frozen for the test flights.

Because the datasets are cleaned, the numbers on this page are not directly comparable with numbers published on the original files. As a check, AI-IO's released model on the cleaned AI-IO data matches the published EKF velocity error to within 0.01 m/s on average, on the test groups the cleaning left intact.

Results so far

The network: VeloBins is better calibrated everywhere

• Uncertainty: VeloBins' predicted distributions fit the true velocity better on all three datasets (NLL lower by 0.40, 1.22 and 0.10; p < 0.001).
• Accuracy depends on the dataset: VeloBins is 8% better in RMSE on TII-RATM, 4% worse on NanoBench, and 15% worse on NeuroBEM at its best-validation checkpoint (2% at its final one).
• On the AI-IO dataset, the same picture holds at 8 seeds: the calibration gain is clear (p < 0.001), while the accuracy difference is within seed-to-seed noise on our cleaned copy.

The filter: tuning matters more than the network

• The default filter fails on all three datasets. It is strongly over-confident (median NEES 53–150, against 2.37 for a consistent filter) and doubles or triples the network's error.
• Tuning on validation cuts the filter's error by 34–71%. With it, VeloBins + EKF is as good as AI-IO + EKF or better everywhere: 0.517 vs 0.589 m/s on TII-RATM, 0.175 vs 0.176 on NanoBench, 0.632 vs 0.700 on NeuroBEM.
• Check the grid edges. On NeuroBEM the first tuning grid picked its smallest measurement-noise scale. Widening the grid found a better setting between two old grid points, which cut VeloBins' fused error by a further 8% (0.685 → 0.632 m/s) and brought its NEES median from 4.7 to 2.9.
• The filter does not yet beat the network on TII-RATM and NanoBench (5–10% worse). On TII-RATM the accelerometer itself is the limit: integrated with the true attitude, it drifts 0.7 m/s within one second.

Finding: NeuroBEM's gyroscope reads 2.5% high

Even with a tuned filter, three NeuroBEM test segments diverged. The cause was not the network: on those segments the heading drifted by 20–59° during highly tilted manoeuvres with 6–9 full turns. Regressing the ground-truth heading change on each gyro axis over the training flights shows the x-axis gyro reading 2.5% high (scale 1.0249, 95% CI 1.0238–1.0265). Correcting only the filter's gyro input, with the network unchanged, lowers the filter's test error by 41%, from 1.165 to 0.685 m/s (at the first tuned filter setting), and the three diverging segments drop from 1.5–5.1 to 0.4–2.0 m/s.

A spectral-norm bound fixes late over-confidence on NanoBench

Without regularisation, VeloBins becomes over-confident on NanoBench by the end of training (NLL rises from −1.34 to −0.63). Keeping every encoder weight matrix at spectral norm ≤ 2, as Neural-Fly does, prevents this and makes the model more accurate:

• Network: 10.5% lower RMSE than VeloBins at the final checkpoint (0.150 vs 0.167 m/s, p < 10⁻⁴) and 7.5% lower than AI-IO.
• Filter: 9–11% lower fused velocity error than either baseline, and a NEES median of 2.45, close to the 2.37 of a consistent filter.
• But it is dataset-dependent: in a 3-seed screen the same bound made TII-RATM and NeuroBEM up to about 10% worse. A looser bound of 3 is roughly neutral there and is the candidate setting for the cross-platform work.

What did not work

• Battery voltage as an input. Motivated by command-based platforms, where the same command gives less thrust as the battery drains. All effects stayed within ±4% with no consistent direction; the accelerometer likely already tells the network how much thrust a command produces.
• A rotor-drag physics loss. At low weight it changed nothing; at higher weight it pulled predictions towards the drag model, whose velocity is 1.3–1.9 m/s off, and the error doubled or worse.
• Physics as a second velocity sensor. Inverting a hybrid aerodynamic model gives velocity 2.5–5× less accurate than the networks, and fusing the two gained nothing measurable.

Ongoing: one encoder for every drone

The four datasets come from four different drones, each trained separately so far. The current experiments train one shared encoder on all of them, with a separate actuation normaliser and bin decoder per drone, and then test transfer to a drone left out of training using only 0.5, 2 or 8 minutes of its flight data. The aim is a pretrained encoder that a new platform can adopt with minutes of flight logs instead of hours.

To make the rotor input mean the same thing on every drone, I fit a per-rotor thrust map, f = a·u² + b·u, from each drone's actuation signal to mass-normalised thrust. It is fitted on the training flights against the thrust implied by the ground-truth motion, and checked on validation flights:

• R² of 0.84 (AI-IO, rpm), 0.90 (TII-RATM, thrust command) and 0.95 (NeuroBEM, rad/s).
• An independent check against the accelerometer, which the fit never sees, agrees in scale to within 2%.
• NanoBench is the exception (R² 0.15): its flights hold nearly constant thrust, so there is little variation to explain.

There are no cross-platform results yet; they will be added here. After that comes the JAX and ROS 2 port, to run EDGE-IO on board.