HexVIO: Towards All-Day Stereo-Inertial Tracking Through Commodity DSPs

Can a commodity Hexagon DSP accelerate a stereo-inertial visual-inertial odometry frontend enough to provide large power and throughput gains over CPU-only execution without sacrificing tracking accuracy on consumer hardware?

VIO is accurate and low-cost but CPU implementations consume too much power and generate heat, preventing all-day tracking on battery-powered phones, headsets, smartglasses, and robots. GPUs add power and thermal overhead; custom ASICs and FPGAs are efficient but not broadly deployed or reprogrammable; existing Hexagon DSP ports were closed, required rooted devices, or did not support stereo-inertial VIO.

The baseline is CPU-only Basalt with OpenCV/Eigen NEON paths. Prior acceleration includes GPU frontends (vilib, Jetson-SLAM, FastTrack, GLidE-SLAM), custom silicon (Navion ASIC, eSLAM/ac2SLAM FPGA, PX4Flow MCU), and earlier Hexagon efforts such as Muffang's OpenVINS port and an ORB-SLAM3 extractor/matcher for the Lynx R1. These are limited by higher power, non-commodity hardware, closed source, or lack of stereo-inertial support.

HexVIO runs pyramid construction, FAST-9 detection, and sparse inverse-compositional KLT tracking on the Hexagon V73 DSP of a stock Samsung Galaxy S23. All frontend stages are fused into one FastRPC call per stereo frame to amortize RPC overhead. The implementation is restructured for HVX wide SIMD, VTCM scratchpad, and gather limitations: pixel-parallel pyramid/detection and feature-parallel tracking with 32 features per vector batch. Full-resolution stereo images are DMA'd into VTCM; sparse feature data pass via shared memory; the backend optimizer remains on CPU.

Across eight sequences from EuRoC, Monado SLAM Dataset, TUM-VI, and a custom XREAL Air 2 Ultra dataset, maximum throughput improved 1.65–2.38×, and MOO05 frontend time fell about 70%. At the CPU baseline's 98 fps/4.8 W point, HexVIO needs 1.6 W (67% less power); at 4.5 W HexVIO reaches 180 fps vs 97 fps for CPU (+86%). In sensor-paced runs, DSP_B reduced whole-device power by 35% on average (range 28–43%) and DSP_L by 40% on average (up to 45%) at matched accuracy. ATE differed by at most 0.4% on four sequences; TR6 improved 2.9% (2.06 vs 2.00 cm) and EMH03 worsened 6% (6.05 vs 6.43 cm); RTE was identical on five of six sequences. Late frames summed across eight paced sequences: CPU 342, DSP_B 21, DSP_L 1. On a 40-minute, 72,810-frame run, DSP_L drew 0.83 W vs 1.46 W for CPU, with 0.05% late frames vs 0.25% and 34–35°C SoC die temperature vs 42°C; 0.83 W on a 15 Wh battery is about 18 hours of tracking.

Evaluation is on a single smartphone model with dataset replay rather than live camera streaming. Camera ISP direct-to-DSP access is restricted to signed vendor code, so live sensor integration needs OEM support. The backend remains on CPU and accounts for most remaining frame time. DSP_L intentionally loosens accuracy by raising the FAST threshold floor from 5 to 20 and using 6 keyframes instead of 7. Long XREAL sequences thermally throttle at maximum throughput. Power is measured from the internal fuel gauge with coarse resolution, so per-stage energy is not reported. Source code is stated as 'will be released,' not yet available.