---
license: mit
tags:
- inertial-odometry
- imu
- tartanimu
- iros2026
- state-estimation
- sensor-fusion
---
# TartanIMU Challenge (IROS 2026) — team Lexxxxx — model `a3v21_s42` (second leaderboard entry)

Second of the two final entries of a team that finished **20th of 131** in the IROS 2026 TartanIMU Challenge. Official scoring service over all 89 test sequences: **TartanIMU Score 0.26306** (macro ATE₂₀ 0.637 m, macro AVE 0.222 m/s). The delivered entry is `a3v20_s42` (0.25878).

| | |
|---|---|
| **Code, evaluation rulers, technical report, full development record** | https://github.com/Jadiouo/tartanimu-unified-io |
| Results and how to verify the standing | https://github.com/Jadiouo/tartanimu-unified-io/blob/main/docs/results.md |
| Technical report (PDF, submitted to the organisers) | https://github.com/Jadiouo/tartanimu-unified-io/blob/main/report/technical_report.pdf |
| Competition | https://www.kaggle.com/competitions/tartan-imu-challenge-iros2026 · [final standing](https://www.kaggle.com/competitions/tartan-imu-challenge-iros2026/leaderboard?search=Lexxxxx) · [challenge page](https://superodometry.com/imuchallenge/) |
| Delivered entry (official 0.25878) | https://huggingface.co/LexHo/tartanimu-a3v20 |

Single unified model, one shared set of weights, for all four platforms (car, dog, drone, human).
This repository is our **second** considered submission; the primary one (`a3v20_s42`, official 0.25878) is at
https://huggingface.co/LexHo/tartanimu-a3v20. Each repository holds exactly one model and the exact prediction file it produced.
Frozen weights: `weights/tartanimu_a3v21_s42.pt` (sha256 `7d90badeb2873b1d8f3e13ffca21a624cf2b2ae8a5f838473a7ac44964f9c07b`).
`submission.csv` is the exact prediction file behind the claimed Kaggle score (md5 `a53e196f6b67e8ea52733f4386b5c403`;
official scoring service: TartanIMU Score 0.26306, macro AVE 0.22232, macro ATE20 0.63665).

## Run

    pip install -r requirements.txt
    python predict.py --data /path/to/tartan-imu-challenge-iros2026 --out submission.csv

Input: `index/test_windows.csv` + `test/*.npz` (raw 6-axis IMU only). No internet, no ground truth, no platform label.
Measured re-execution of this repository as downloaded (CPU only, isolated environment, process-level socket block,
empty cache): 1 min 10 s wall, 1.4 GB RSS; on one GPU < 1 min, < 1 GB VRAM.
Cross-machine numerical tolerance vs `submission.csv` (produced on an RTX 5090): componentwise mean 1.8e-5, p99 1.6e-4, max 1.6e-3 m/s.
`SHA256SUMS` covers every file (`sha256sum -c SHA256SUMS`).

## Method (short)

Same main network as the primary entry, **without** the learned-INS sub-modules and recursion head, **with** a
recording-level FiLM conditioning: dense random-offset 1 s windows → 14 input channels (raw IMU + an 8-channel
decomposition about a slow complementary-filter "up" direction computed from the same IMU) → dilated 1-D ResNet trunk
(5 tokens per window) whose blocks are modulated (FiLM: per-channel scale and shift) by a 35-dimensional descriptor of
the whole recording (per-axis mean / spread / step roughness of the raw IMU, rest-window statistics, a 10-bin
|acc| spectrum, gyro-rate percentiles, log duration — IMU only, no labels) → bidirectional GRU over 40-window chunks →
linear head → body-frame velocity per window. Huber loss (β 0.05). Trunk initialised from a masked-IMU self-supervised
pre-training on the released train+val IMU (no labels). Training augmentations: time dilation k ∈ [0.7, 1.5] (drone;
identity-source racing family capped at 1.2) and, for the racing family only, translation scaling s ∈ [1.0, 1.8]
applied to velocity labels and the gravity-removed specific force ("S-fast"); yaw augmentation about the estimated up
(direction-only) for the identity source. Final weights = last epoch of a 120-epoch train+val run, seed 42
(pre-designated; seed range reported in the technical report).

## Compliance declaration

1. **Single model, one shared set of weights?** Yes. One checkpoint, one forward pass per chunk; no per-platform experts.
   The FiLM descriptor is a function of the recording's own IMU computed inside the same forward pass; it is not a
   platform label and nothing is routed.
2. **Platform classification, routing or specialization at inference?** No. An auxiliary platform head exists only as a
   training loss; it is not used at inference.
3. **Ensembling, checkpoint averaging or test-time augmentation?** No. Single checkpoint, deterministic inference,
   overlapping-chunk averaging of one model's own predictions only (stride K/2 within a trajectory).
4. **Test-set leakage avoidance, incl. model / checkpoint selection?** Test ground truth never used. The final checkpoint
   is the fixed last epoch (no selection on any test signal). The self-supervised trunk pre-training used only the released
   train+val IMU. No external data or external pretrained weights are used in the submitted system. Development-time
   experiments with an external dataset (NeuroBEM) were run and are disclosed in the report; none of their weights or data
   enter this model. A public-leaderboard probe with a physics post-processing rule was made during development and is
   NOT part of this submission.
5. **Development-time vs submitted system?** Identical inference code; the submitted checkpoint differs from earlier
   leaderboard entries by the training augmentation (S-fast) and the recording-level FiLM. Model/checkpoint selection used
   the released validation split and two stress folds of the training split.