TARAF: Trail Recovery and Path Finding System

BNO055 IMU hardware for the foot unit. The point at this stage is reliable logging for estimator development.

Intro

TARAF began with a personal question: what would it mean to get lost safely? Modern hikers often rely on GPS, cell service, expensive handheld devices, or subscription-backed navigation tools. Those tools are useful, but they are not always available, affordable, or self-contained.

The project turned that desire to explore into a practical backup navigation system. TARAF records a walked path with a foot-mounted IMU and estimates how to return without relying on external infrastructure.

Purpose

The goal is not to replace GPS everywhere. The goal is to investigate a trusted, self-contained wearable system for moments when GPS-dependent tools become unreliable: dense tree cover, canyons, poor visibility, disconnected terrain, or a dead phone.

A hiker needs to trust the device. That means the project is as much about validation as it is about sensing. Raw IMU integration drifts quickly, so TARAF includes both the embedded sensing system and the tools needed to measure how wrong the estimate is.

System overview

The current system includes:

Foot-mounted IMU unit using ESP32-class hardware and a BNO055 IMU
Wrist-mounted display concept for return guidance
BLE communication between units
Path recording and return guidance logic
Side-profile computer-vision validation with ArUco markers
Offline analysis and optimizer tooling in Python

The estimator pipeline covers calibration, filtering, stride and stance detection, zero-velocity and zero-angular-rate updates, and an Error-State Kalman Filter (ESKF) with quaternion-based attitude representation.

Design decisions

The project was scoped like a product trade study, not just a controls exercise. The Pugh chart kept the early hardware choices tied to practical constraints: low cost, available parts, enough performance for a prototype, and a path toward better sensors later.

Decision	Selected direction	Why it fit the prototype	Tradeoff / next step
MCU family	ESP32-class boards	Cheap, available, BLE-capable, strong enough for logging and first firmware	Higher idle power than low-power MCU families
IMU	BNO055	Available 9-DoF module with simple integration for a capstone prototype	Not the ideal long-term navigation sensor
Validation	Side-profile ArUco tracking	Direct external reference for foot motion during repeatable indoor tests	Needs cleaner trials and more route types
Estimator	ESKF with ZUPT/ZARU	Matches the foot-mounted inertial navigation problem and gives explicit correction points	Needs movement-aware tuning for turns, stops, and curves
Optimization	Offline ML/config search	Lets collected trials shape estimator parameters instead of guessing	Generalization depends on better labeled data

Implementation

Embedded platform

The foot unit pairs an ESP32-class microcontroller with a BNO055 IMU. The BNO055 was chosen because it was cheap, available, and practical for a first prototype, not because it is the ideal long-term sensor. The system polls sensor output, timestamps samples, filters duplicate readings, and logs data for estimator development and validation.

I2C was a reasonable prototype bus because the BNO055 output rate was around 100 Hz and the firmware polling was around 175 Hz. The limiting problem was not raw bus speed; it was drift, stance detection, duplicate samples, timing, and whether the estimate matched an external reference. SPI would only become worth the wiring and integration cost if the project moved to a faster or more capable IMU.

Stride detection and ZUPT/ZARU

Zero Velocity Update (ZUPT) and Zero Angular Rate Update (ZARU) are the main drift-suppression mechanisms. During stance phases, the foot is assumed to be briefly stationary, so the estimator can inject a zero-velocity correction and limit accumulated drift.

State estimation

The core estimator is an Error-State Kalman Filter. The current completed work includes the ESKF, ZUPT/ZARU correction logic, and an offline optimizer that tests estimator configurations against collected walking data.

Ground truth

The validation setup uses side-profile computer vision. A large ArUco marker is placed on the right calf while the IMU is mounted on the foot. Camera tracking gives an external reference for the walked trajectory across repeatable tests. The longest indoor test distance so far is 17.27 m.

Movement-aware tuning

The next controls goal is to classify movement segments and select estimator behavior for each segment. A person may be stopped, walking straight, deviating from a straight path, or moving through an arc. TARAF should eventually detect those transitions, use hysteresis to avoid jitter, and build the path from movement-specific blocks.

Technical details

Parameter	Current notes
Microcontroller	ESP32-class hardware, including Waveshare ESP32-C6 / ESP32-S3 boards to verify
IMU	BNO055, used as an available low-cost prototype sensor
IMU output	About 100 Hz from the BNO055
Polling	Around 175 Hz, with duplicate readings filtered
Estimator	Error-State Kalman Filter
Drift correction	ZUPT + ZARU
Orientation	Quaternion representation
Ground truth	Side-profile ArUco + OpenCV validation
Offline ML	Random Forest and SVM experiments in Python
Languages	C / C++ firmware, Python analysis

The attached poster gives the one-page capstone view of the system for quick scanning. The Pugh chart is included for the design-selection trail behind the embedded and sensor decisions.

Validation

The system has reached an integrated proof-of-concept stage with working sensing, path recording, estimator logic, and validation tooling. The offline optimizer can tune configurations against collected data. Person-specific tests can perform much better than generalized tests, while generalized results are still affected by bad or inconsistent trials.

The most important active work is improving generalization: collecting cleaner movement classes, detecting transitions between movement types, and applying estimator settings that match the kind of motion being measured.

Future work

Improve step and stance detection over varied paces
Expand tests across straight lines, heading changes, arcs, stops, users, and routes
Build movement-specific estimator configurations
Explore complementary and particle-filter approaches
Replace the BNO055 with a more capable sensor if the project continues

What TARAF is actually testing

TARAF started from a blunt outdoor question: how do you get lost safely? Phones, GPS watches, satellite messengers, and trail apps are useful, but they all depend on some combination of battery, sky visibility, maps, subscriptions, or external infrastructure. The project is not trying to beat every GPS device. That would be the wrong target.

The interesting question is narrower: can a self-contained wearable record enough of a walked path to become a believable backup when the normal tools are weak? That means the prototype has to be judged less like an app and more like a navigation instrument. It has to sense motion, estimate position, store a path, and prove how wrong it is.

The foot-mounted IMU choice comes from that framing. The foot gives the estimator something the torso or wrist does not: repeated stance phases where the system can say, for a moment, the foot should not be translating. Those moments are the project.

TARAF system block diagram — Early system map tying the foot unit, path storage, return guidance, validation, and tuning workflow together.

Drift is not a bug at the end

Raw IMU integration drifts because acceleration errors are not polite. A tiny bias does not stay tiny once it is integrated into velocity and then position. If the project waits until the end to "fix drift," it has already lost.

ZUPT and ZARU are the practical way back into the problem. During stance, the foot is briefly close to stationary. That gives the estimator a physical correction: velocity should be near zero, and angular rate should be near zero. The correction is not magic; it depends on detecting stance well enough that the filter is not lied to during swing, turns, or sloppy foot placement.

That is why the ESKF matters. It lets the system carry a nominal state while correcting the error state around it, which is a better fit for attitude, bias, and quaternion handling than pretending the motion is linear. The real work is deciding when the correction is trustworthy.

TARAF sensor board and foot-unit prototype — BNO055 IMU hardware used for logging and estimator development.

The floor markers came before ArUco

The tape markers were not ArUco validation. They were the predecessor: a way to make early Kalman/filter trials repeatable enough to mean anything. They controlled where the foot landed and how far the person traveled, because otherwise every test becomes a new route with a new set of excuses.

That mattered before the camera system was clean. If the same person walks roughly the same distance with roughly the same foot placement, then changes in the estimate are more likely to come from the estimator and less likely to come from an uncontrolled trial. It is not perfect ground truth, but it is a sane first constraint.

ArUco came in as the external validation path. The side-profile setup tracked markers, including a marker on the right calf while the IMU sat on the foot, so the estimated motion could be compared against a camera reference. That is the difference: tape controlled the trial; ArUco measured the trial.

TARAF floor markings for repeatable tests — Original repeatable path markings for Kalman/filter testing. They controlled foot placement and distance before the ArUco validation setup.

Why I2C was enough for this prototype

The bus question only matters after you ask what the sensor is producing. The BNO055 output was around 100 Hz, and the firmware polling was around 175 Hz with duplicate samples filtered out. For that prototype, I2C was not the thing holding the system back.

SPI would give more bandwidth and cleaner timing margins with a faster IMU, but that was not the active bottleneck. The estimator was fighting bias, stance detection, duplicate handling, calibration, and validation quality. A faster bus does not make a bad stance detector truthful.

UART belongs in a different category here. It is useful for logging, validation, or debug paths, but it is not the natural shared sensor bus for this foot-unit setup. I2C was the boring choice, and boring was acceptable because the experiment needed better data discipline before it needed a more aggressive interface.

TARAF ESP32 and IMU hardware — Prototype sensor hardware. Bus choice mattered less than calibration, timing, duplicate handling, and estimator tuning.

The estimator has to know how a person is moving

A single tuning mode asks too much from the filter. A person can be stopped, walking straight, beginning a turn, correcting their heading, dragging a step, or moving through an arc. Those are not the same motion class, and treating them the same is one reason generalized trials become weak.

The next useful version needs movement-aware estimation. The plan is to classify motion segments, use hysteresis so the mode does not flicker, and apply estimator settings that match the kind of motion actually happening. That is also where ML can help without pretending to replace the physics: it can label or select regimes, while the estimator still has to obey the motion model.

The project is at the uncomfortable but good stage where the prototype works enough to reveal the next problem. Person-specific tests can look much better than generalized tests. That means the system is learning something real, but not yet in a way that survives enough users and routes.

Whiteboard notes for TARAF estimator discussion — Whiteboard discussion around estimator behavior and motion classes.

Where it goes next

TARAF does not need a prettier demo as much as it needs better trials. Straight lines, stops, turns, arcs, different paces, different users, and longer routes all have to be separated enough that the estimator failure modes can be named.

After that, the hardware question becomes worth revisiting. A better IMU, a lower-power MCU, or a different bus may make sense once the validation path is stronger. Right now the most honest next step is to collect cleaner motion classes and stop letting trial quality hide inside the estimator.