TREX
Forests burn faster than we can measure them — manual wildfire fuel assessment takes hours per transect. Designed a $300 autonomous sensor robot that does it in 15 minutes, tested in real forests with actual technicians.
Overview
I led UX and hardware design for TREX — an autonomous sensor robot that replaces manual wildfire fuel measurement. Started as a UW MSTI class project (TECHIN 540), grew into a summer apprenticeship at AI2, then continued as my capstone. Post-capstone, the project was handed over to AI2 Wildlands, where it's now in active development. I designed the field technician interaction model, led hardware prototyping across multiple drivetrain iterations, and conducted user research with actual forest professionals.
The Problem
You can't predict wildfires without ground truth — and ground truth takes hours
Wildfire prediction models need detailed forest fuel data: how much downed wood, how decomposed it is, what slope it sits on. Today, this data is collected by technicians who walk into the forest, run a tape measure across a transect, count sticks by hand, and write tallies on paper. It takes hours per site. Two technicians measuring the same site can produce different numbers because decomposition classification is subjective.
The catch: AI-driven fire prediction models are only as good as the data they're trained on. Inconsistent ground truth produces unreliable models. Aerial LiDAR is expensive and inaccessible to most agencies. There's a gap between “walk in with a clipboard” and “hire a $50K aerial scan” — and that gap is where most forests sit.
Field Research
Talked to the people who actually do this work
Olympic Experimental State Forest
Teodora Minkova, Forest Researcher
Walked us through transect protocols and pain points. Confirmed that subjectivity in decomposition classification is a known training issue across teams — not a one-off complaint.
FLAME Lab
Brian T. Drye, Photogrammetry Expert
Explained why cost-effective photogrammetry hasn't solved this — point clouds from photos miss the dense undergrowth where fuel actually lives. We needed direct sensor measurement, not reconstruction.
Grand Teton Fire Effects
Paul & Olivia, Fire Ecologists
They've used the Brown transect method on 100+ projects. Their wishlist: standardized data collection that doesn't depend on which technician shows up. This shaped our success criteria — consistency was as important as speed.
AI2 Wildlands
Jenna James, UX Designer
Helped me think through the field technician interaction. Forests are loud, wet, and hostile to UI. The interface had to work with gloves on, in the rain, with one hand free.
The Solution
An autonomous sensor robot that runs the transect for you
TREX is a zipline-suspended autonomous sensor platform. The technician strings a line across a 30–40m transect, clips TREX to it, and presses a button. TREX traverses the line autonomously, capturing synchronized data from a camera, LiDAR, time-of-flight sensor, and IMU every 5 seconds. A local vision-language model running on the device classifies fuel types and decomposition levels in real time. The technician walks back to the laptop with a structured, AI-ready dataset.
Hardware
Iterated through 3 drivetrains, 4 motor types, and a $300 budget
I came in as a UX designer and left as a hardware engineer. The drivetrain alone went through three full iterations — 2-wheel, 3-wheel, and finally 7-wheel for stability. Motors evolved from cost-prohibitive NEMA 17 steppers to toy DC motors to brushless ESCs. Wheels were 3D-printed PLA — cheap, but slipping became a real problem. Every component decision was a trade-off between cost, durability, and the field reality of running this thing on a wet log in the Pacific Northwest.
Compute
Raspberry Pi 5 with UPS, AA battery backup, and active cooling. Chosen because it could run a quantized vision-language model on-device while still managing sensor I/O — and because it left budget for sensors.
Sensor Suite
Arducam IMX519 (16MP autofocus), Slamtec RPLiDAR A1M8, Adafruit VL53L4CX time-of-flight, Adafruit BNO055 9-DOF IMU. All wired to the Pi via USB and I2C. Synchronized capture every 5 seconds during transect traversal.
Drivetrain Iterations
2-wheel was unstable on uneven terrain. 3-wheel improved balance but couldn't handle the payload. 7-wheel finally distributed weight enough to traverse reliably under load. Each iteration was 3D-printed, tested, and rebuilt — usually within the same week.
Field-First Constraints
Had to support 1kg payload minimum. Had to run from a single battery pack. Had to be operable with one hand. Had to survive being dropped off a zipline. Every decision was made in service of the technician's actual workflow — not what looked clean on a CAD render.
UX Paradigm
Designing for cold hands, wet gloves, and dropped devices
Most hardware UX assumes a calm indoor environment. Forests don't cooperate. The UX paradigm I designed for TREX had to accept hostile conditions as the default, not the edge case.
Three buttons, no menus
GPIO buttons for start, stop, and reset. No touchscreen — gloves don't register. No nested menus — you don't have time to dig through a UI when daylight is fading and the next site is 2 miles away.
Visual feedback first, then audio
An LED ring shows status from across the transect. Audio confirmation plays through a speaker when the run completes. The technician doesn't have to be standing next to the device to know what's happening.
Recoverable from drops
Usability testing showed 86% of users had grip concerns and 57% worried about dropping it. I redesigned the form factor with a recessed handle and impact-absorbing wheel mounts. Drops happen — the design assumes that.
Web app as a control surface, not the interface
Initial usability tests revealed 50% of users were confused by the Streamlit web app. I simplified it to a single configuration screen plus a live status view — used at the start and end of a session, not during the run.
Validation
Tested in real forests with real technicians
Data Capture Efficacy
95%
Of transect runs produced complete, usable data across all four sensors. This is the metric that mattered most to AI2 — they needed reliable input, not perfect output.
On-Device VLM Accuracy
~80%
Local vision-language model classified fuel types from captured images at ~80% accuracy — running on Raspberry Pi, no cloud, no roundtrip. Enough to be useful, with clear paths to improvement.
We tested at the Olympic Experimental State Forest with actual forest technicians and people who do forest estimation professionally. Every finding above became a design change in the next iteration. The grip concerns drove a recessed handle redesign. The web app confusion led to a single-screen control surface. The physical demand score validated the zipline approach over a ground-traversing rover.
Outcome
Class project → summer apprenticeship → capstone → AI2
TREX started as a 10-week class project (TECHIN 540) at UW MSTI. It worked well enough that AI2 brought the team on for a summer apprenticeship to keep building. That extended into a capstone project the following quarter. By the end of capstone, we had a functional prototype, real field data from OESF, and validated UX patterns.
Post-capstone, the project was handed over to AI2 Wildlands. They're currently in active development — extending the sensor suite, improving the VLM, and working toward a production deployment with forestry partners. The hardware design, the field UX patterns, and the validated workflow I built carried forward as the foundation.
From a manual process that takes hours to a 15-minute automated transect run, with consistent data and 80% on-device classification — for $300 in parts.
Reflections
What I learned
Hardware UX is its own discipline
Designing for a Raspberry Pi in a wet forest is nothing like designing for a phone on a desk. Constraints are physical: glove thickness, button feedback through cold fingers, IP ratings, drop survival. I came in thinking like a screen designer and left thinking about ergonomics, feedback latency, and recovery from physical failure. Different vocabulary, same fundamentals.
$300 forced better design decisions than $30,000 would have
Every component had to earn its place. We couldn't throw money at problems — we had to think them through. The 7-wheel drivetrain wouldn't exist if we'd had budget for a high-torque industrial motor. The on-device VLM wouldn't exist if we'd had a cloud GPU budget. Constraints made the product more interesting, not less.
Validation isn't a phase, it's the work
We field-tested every iteration at OESF. Every drivetrain. Every motor. Every UX change. The 86% grip concern didn't come from a survey — it came from watching technicians actually pick the thing up. You can't design hardware for a hostile environment from your desk. You have to be in the environment, watching it fail.
Handing off is part of designing
When the project moved to AI2, the documentation, the rationale, and the iteration history mattered as much as the prototype. The fact that it's still being developed today is partly because we left a clear trail of decisions for the next team to follow. Good hardware design is also good knowledge transfer.