Project Logs

Collapse

• ATLAS v2 Prototype

  Apollo Timbers • 2 days ago • 0 comments

  The ATLAS tricorder in now deep into the second and more refined design/build version mark 2. 

  It's been a long time coming but Mark 1 is now a shelf queen. 

  It takes a lot of hard work to build these prototypes but each one helps further the design language and overall build quality. Below are some images of it in work. 

  New features include: (not limited too) 

  • A refined case design to allow for more internal volume
  • A dual super bright LED module in the back with protective rim, (glued in place with marine 2 part epoxy) 
  • A speaker/grill with built in amp with a adjustable knob (amp not shown)
  • No need to trim the button holes the keys do not get stuck anymore. 
  • Much nicer internal wiring and attention to detail such as gluing thins in with for mentioned marine epoxy. 
  • Double the resolution screen bumped up from 128x64 to 256x128 pixels monochrome OLED
  • Case is printed in white ASA for a more durable and heat resistant plastic (I.E you can leave it in a reasonably hot car)

  Enjoy the images! 

• ATLAS Vision: Training a 50-Class Species Classifier

  Apollo Timbers • 02/24/2026 at 14:46 • 0 comments

  The Goal

  A vision model that runs on a HUSKYLENS 2 (Kendryte K230, 6 TOPS AI accelerator) and classifies species into safety tiers:

  • DEADLY — do not touch, do not eat
  • TOXIC — causes serious harm
  • EDIBLE — safe to eat, confirm ID first
  • MEDICINAL — documented medicinal use
  • INFO — identification and environmental context

  The model has to be small enough for edge deployment, fast enough for real-time use, and — critically — it has to be right about the dangerous stuff.

  The Pipeline

  1. Data Collection

  I wrote a Python scraper that pulls research-grade, expert-verified observations from the iNaturalist API. Research-grade means community consensus on identification — these aren't random smartphone photos with guessed labels.

  50 classes across 5 categories:

  • Mushrooms (18): 4 deadly, 1 toxic, 7 edible, 6 medicinal
  • Plants (18): 2 deadly, 3 toxic, 4 edible, 1 edible cooked, 8 medicinal (added in v1 final — renamed from 13 to 18)
  • Leaves (5): oak, maple, birch, fern, pine
  • Rocks (6): granite, limestone, sandstone, obsidian, quartz, basalt

  Total: 17,700 images. Dangerous species are intentionally oversampled — death cap and destroying angel get 600 images each while safe species get 300. When someone's life is on the line, false negatives on deadly species are unacceptable.

  2. Dataset Preparation

  A preparation script validates every image (corrupt file detection, minimum size check), splits into train/val/test (roughly 84/16 split plus held-out test), and generates a safety-tagged class map. Every class gets a safety label baked into the metadata so the device firmware can display appropriate warnings.

  3. Training

  YOLOv8n-cls (nano classification) on an NVIDIA RTX 2070 SUPER. 1.5 million parameters, 3.4 GFLOPs.

  • 224×224 input
  • Batch size 32
  • 100 max epochs, patience 20
  • Mixed precision (AMP)
  • RandAugment, horizontal/vertical flips, HSV jitter, rotation

  Training stopped early at epoch 85 (best model at epoch 65). Total training time: 51 minutes.

  4. Results

  Score
  88.4>#/td###
  98.4>#/td###
  3.1 MB
  5.7 MB
  0.2ms per image

  88.4% top-1 means the model picks the correct species 88% of the time across all test images — including bad angles, poor lighting, and visually similar species. 98.4% top-5 means the correct answer is almost always in the model's top candidates.

  More importantly: on clean, well-lit images of distinctive species, confidence scores hit 95-99%. A photo of a destroying angel / death cap came back at 100% confidence. A baby bella mushroom (not in the training set) came back at 6% — the model knows when it doesn't know.

  Live Demo

  Exported to ONNX and ran live inference through a USB webcam using OpenCV. Point the camera at a photo on my phone, get real-time classification with confidence scores. Chanterelle: 99%. Death cap: 99%. Unknown grocery store mushroom: low confidence, no false ID. Exactly the behavior you want from a safety-critical system.

  Hardware Target

  The final model deploys to a HUSKYLENS 2 AI camera (Kendryte K230, 6 TOPS, 1GB RAM). A custom PCB designed by my collaborator Yasir Ahmad. The MCU board runs dual RP2350 processors handling sensor fusion, UI, and audio while the HUSKYLENS handles all vision processing. Communication over UART/I2C.

  The nano model at 3.1MB with 0.2ms inference is absurdly comfortable on this hardware. Which is good, because V2 is going to need the headroom.

  What's Next: V2

  V2 expands from 50 to ~200 classes:

  • Berries (22 classes — deadly and edible)
  • Insects & arachnids (37 classes — venomous spiders, stinging caterpillars, edible insects)
  • Snakes (10 classes — venomous + harmless lookalikes)
  • Animal tracks (17 classes — predator awareness, wildlife)
  • Trees by bark (12 classes — year-round ID)
  • Lichen (8 classes — survival food, air quality indicators)
  • Edible nuts (8 classes)
  • Marine life (20 classes — fish, crustaceans, shellfish)
  • Additional mushrooms (12 classes — more deadly lookalikes, regional edibles)

  The V2 dataset...

  Read more »

• ATLAS Power Management — A Week in the Field on a Single Charge

  Apollo Timbers • 02/22/2026 at 16:02 • 0 comments

  Note: Everything in this post is initial research and estimated projections for ATLAS v2, which is the first version to include dedicated power monitoring hardware (INA226 voltage and current monitor, BQ25892 charge management IC). None of these power figures have been validated against real hardware yet — that testing will happen once the v2 MCU board comes back from the builder. Consider this the design intent and the math behind it. Real-world numbers will follow in a future post once I have actual bench data.

  One of the things I'm most proud of in the ATLAS tricorder firmware is the power management system. When you're building a handheld field instrument meant for serious wilderness deployment, battery life isn't a feature — it's a safety requirement. A device that dies on day two is worse than no device at all because you trusted it.

  So I designed ATLAS around three distinct power modes, each tuned for a specific use case, with some logic baked in that I think is genuinely clever.

  The Three Modes:
  

  Full Active — The Lab Bench and Active Survey Mode

  This is ATLAS with the hammer down. GPS running at 1Hz continuous, the BNO085 IMU screaming at 10Hz, all environmental sensors polling fast, display always on, both RP2350 cores active. This is what you run when you're actively scanning a site, doing a structured survey, or demoing the hardware.

  The cost is power — roughly 120mA continuous. On the student 5Ah pack that's about 42 hours. On the full 10Ah pack you get ~83 hours. Not a field deployment mode, but you're not meant to live here. It's full capability on demand.

  Hiker Mode — On the Move

  Hiker is the balanced field mode. GPS drops to a fix every 5 seconds, the IMU stays alive but throttles back to 1Hz, environmental sensors poll at reduced intervals, and the display auto-shuts after 30 seconds of inactivity with a button wake. The speech processor core sleeps between alerts.

  That IMU staying alive at 1Hz is intentional — ATLAS uses it for dead reckoning when GPS signal degrades under heavy canopy or in terrain. If the GPS drops out, the BNO085 keeps navigation alive using accelerometer and heading data. You don't lose your breadcrumb trail just because you walked into a ravine.

  Estimated draw is ~65mA. Runtime: ~77 hours (~3.2 days) on 5Ah, ~154 hours (~6.4 days) on 10Ah.

  Basecamp Mode — The Long Watch

  This is where ATLAS earns its keep. Display off. Speech core off. IMU off. GPS wakes every two hours, grabs a fix, and goes back to sleep. Environmental sensors poll at drastically reduced intervals. Deep processor sleep between cycles.

  Estimated draw is ~42mA. Runtime: ~119 hours (~5 days) on 5Ah, ~238 hours (~nearly 10 days) on the full 10Ah pack.

  But here's the thing — radiation and CO polling never slow down. In every mode, including deep Basecamp sleep, the ATtiny85 sub-processor is continuously counting radiation pulses and sampling the CO sensor at 500ms intervals. ATLAS is always watching for the two threats you can't see or smell. That was a non-negotiable design decision.

  The Cool Part — GPS Waking the IMU

  The piece of logic I'm most pleased with is the Basecamp displacement detection system.

  The problem it solves: someone sets Basecamp mode at their tent, then wanders off without switching to Hiker. Maybe they're groggy in the morning, maybe they forgot. In Basecamp mode the IMU is completely off to save power, so ATLAS can't detect walking directly.

  Here's how it handles it. Every two hours, the GPS wakes up and grabs a fix. That fix runs through a Haversine calculation against the stored anchor position. If you're within 200 meters of where you set camp — go back to sleep, everything is fine. But if you've drifted more than 200 meters from the anchor, ATLAS doesn't immediately assume you're hiking. It wakes the IMU and opens a 2-minute confirmation window.

  During that window, feedImuSteps() watches the BNO085 step counter. If it sees sustained walking confirmed over 60...

  Read more »

• ATLAS Breadcrumb Navigation

  Apollo Timbers • 02/07/2026 at 16:48 • 0 comments

  You're a hundred yards into a cave and you lost GPS signal a while back. Now what?

  That's the problem I'm solving with ATLAS, a handheld environmental tricorder I've been developing that packs nine sensors, dual RP2350 processors, and now a breadcrumb navigation system that can guide you home even when satellites can't see you.

  The Compass Was Just the Start

  ATLAS already had a working compass thanks to a BNO085 IMU. I actually tried rolling my own sensor fusion first with a raw gyro and accelerometer. It worked, but not well enough to trust in the field. The BNO085 runs Hillcrest's sensor fusion on-chip with gyro bias correction and magnetic calibration. It basically doesn't care about orientation. Tilt it, flip it, shove it in your pocket. The heading stays solid. That gave me a reliable compass, but a compass alone doesn't get you un-lost.

  Breadcrumb Navigation

  The concept is simple. When you activate trail recording, ATLAS starts dropping GPS waypoints at adaptive intervals, faster when you're driving, slower when you're standing still. The trail lives on the SD card so it survives a power cycle. When you want to get back, you have two options:

  Backtrack. Follow your breadcrumbs in reverse, waypoint by waypoint. The nav screen shows a compass ring with a direction arrow pointing to the next crumb. Walk that direction, arrive within 5 meters, and it advances to the next one. You retrace your exact path.

  Direct. Ignore the trail entirely. The arrow points straight back to where you started. As the crow flies. Useful when you know the terrain between you and your starting point is passable and you just need a heading.

  Dead Reckoning When GPS Drops

  Here's where it gets interesting. GPS is great until it isn't. Dense tree canopy, canyon walls, caves, urban canyons. When ATLAS loses GPS fix for more than 8 seconds, the system engages dead reckoning using the BNO085 heading and last known speed to project your position forward.

  But I didn't want some arbitrary confidence timer that just counts down and hopes for the best. I built an error-budget model based on the actual sensor characteristics:

  • BNO085 heading uncertainty: ~5° typical
  • Speed estimation error: ~±25% (using last GPS speed, no wheel encoders here)
  • Lateral drift rate: speed × sin(5°) per second
  • Along-track drift rate: speed × 0.25 per second

  At walking speed (5 km/h), that works out to about 0.37 meters of position error per second. So after 5 minutes of dead reckoning you've accumulated roughly 110 meters of uncertainty and the system reports CONF:93>. After 15 minutes, you're at about 65%. After 30 minutes, around 30%.

  At that point, yeah, you're a bit lost until GPS comes back online. But the arrow is still pointing in broadly the right direction, which is a lot better than nothing when you're trying to find the mouth of a cave.

  The moment a GPS fix returns, error resets to zero and confidence snaps back to 100%. No accumulated drift baggage.

  What's On Screen

  The nav display shows a compass ring with N/E/S/W cardinal markers rotated by your actual magnetic heading, so north always points north regardless of which way you're facing. Inside the ring, a direction arrow points toward your target. Below that: distance to target, bearing, waypoint progress (for backtrack mode), and the confidence readout.

  CONF:GPS 8s means you have a real fix with 8 satellites. CONF:87% E:35m means you're on dead reckoning with an estimated 35 meters of position error. You always know exactly how much to trust the arrow.

  Why Not Just Use Your Phone?

  Fair question. Your phone has better GPS, more processing power, and Google Maps. But your phone also has a glass screen, a battery that dies in the cold, needs cell service for most of its tricks, and isn't something you want to pull out in a downpour or drop on a rock face. ATLAS is a ruggedized tool that boots in seconds, runs all week on a single charge, and gives you environmental...

  Read more »

• It's the little things

  Apollo Timbers • 02/05/2026 at 16:35 • 0 comments

  he front panel got a proper speaker grill. The 40mm driver press-fits into the back of the faceplate and the grill pattern keeps things looking clean. Small detail but it makes the whole unit feel less like a science fair project and more like something that was meant to exist.

  Picked up a Pelican case for transport and storage. ATLAS fits snug in the foam with room for cables and accessories underneath. Since I'll eventually be traveling with this thing, I put together a two-page TSA security information card to keep in the case. It breaks down every component, battery specs, what it looks like on X-ray, and lists comparable commercial devices like Kestrel meters and Garmin handhelds. Did everything short of writing "PLEASE DON'T ARREST ME" on the cover. Still fully expecting a 45-minute conversation in a small room somewhere.

  Also have a new OLED display on the way - upgrading from the current 128x64 to a 256x128. Same SPI interface, double the resolution. Should make the sensor readouts and menus a lot easier on the eyes and give more room to work with in the UI.

  On the electronics side, the custom PCB schematic is underway with a board designer and progress is looking great. Moving to a dual RP2350 architecture - the B variant for the main controller since it needs all the GPIO it can get, and the A variant dedicated to speech so the main processor isn't blocked during conversation. Power management includes a proper charge controller, boost and buck-boost converters, and an INA226 power monitor. That last one matters - the goal is real battery estimation based on actual current draw, not just reading voltage and pretending. If it says two hours, I want it to mean two hours. None of that "15% for an hour then dead in 30 seconds" experience we've all come to accept from every device we own.

  More updates as the schematic comes together and we move toward layout.

• I2C Topology Solved

  Apollo Timbers • 01/31/2026 at 20:05 • 0 comments

  ATLAS Update: I2C Topology Solved, PCBs in Design

  Quick update on ATLAS progress.

  The I2C Clock Stretching Fix

  Finally solved the bus contention issue. The SCD41 stretches the clock for up to 5 seconds during CO2 measurement, which was freezing everything else.

  The solution is two separate I2C buses:

  Bus 1 (Environmental): TCA9548A 8-channel mux

  • Ch0: SCD41 (CO2, temp, humidity)
  • Ch1: SGP41 (VOC, NOx)
  • Ch2: BMP581 (pressure)
  • Ch3: TSL2591 (light, UV/IR)
  • Ch4: ATtiny85 + Pocket Geiger Type 5 (radiation)
  • Ch5: JST expansion

  The mux isolates each sensor. SCD41 can hold its channel hostage while I poll the others freely.

  Bus 2 (Navigation): TCA4307 hot-swap buffer

  • BNO085 (9-DOF IMU)
  • NEO-M9N (GPS)
  • Hot-swap port for Water Module

  The buffer protects the external port so the water probe can connect/disconnect in the field without crashing the bus.

  I2S (Audio): SPH0645LM4H MEMS mic on its own bus.

  Three Custom PCBs

  This has grown beyond breadboard territory. Three boards in design:

  1. MCU Board: Dual Pico 2, power management, RTC with supercap, SD card, audio amp
  2. Sensor Board: Both I2C buses, mux, buffer, all sensors, expansion ports
  3. Keypad Board: Six NKK tactile switches

  Dual Pico 2 Architecture

  Two RP2350 processors, each with a dedicated job:

  Main Pico: Sensor polling, display, SD logging, keypad input, alert logic, UART TX to speech processor.

  Speech Pico: Talkie synthesis, audio amp control, UART RX. Runs the voice alert queue.

  Why two? Speech synthesis is blocking. While Talkie is generating audio, nothing else runs. Splitting it means the main system never stops monitoring while ATLAS is announcing "STORM APPROACHING" in that robotic voice.

  RTC Addition

  Added a DS3231 real-time clock with supercap backup. Timestamps need to survive power cycles for logging to make sense. The supercap charges when the device is on and keeps the clock running for weeks when it's off. No coin cell to leak or replace.

  Water Probe

  Designing an external water quality probe that connects via the hot-swap I2C port. Three sensors in a single stainless steel tube:

  • TDS: Total dissolved solids, catches minerals and contamination your filter can't remove
  • ORP: Oxidation-reduction potential, detects biological activity and decay
  • Temperature: For compensation and general data

  All three feed into an ADS1115 16-bit ADC inside the probe handle. One I2C address, one cable, clips to the case when not in use.

  The goal isn't lab-grade water analysis. It answers one question: is this water source worth filtering, or should I find another? Dip, wait 3 seconds, ATLAS tells you.

  Building a Team

  I brought on Yasir Ahmad as a contract PCB designer to handle layout. I'm providing flowcharts, BOMs, and overview docs. He's delivering KiCad source, Gerbers, BOM, and pick-and-place files for all three boards.

  PCBWay looks to be sponsoring the initial v1 board fabrication.

  Timeline is about 6-8 weeks for design, then off to fab. Should have assembled boards in hand within four months.

  More updates when schematics are ready for review.

• All the Buttons

  Apollo Timbers • 01/27/2026 at 19:52 • 0 comments

  Finally got all the buttons wired in and working with the built in menu system, actually I did it last year. Been working a bit on a Bluetooth smart lab air filter too. Though I'm very happy with it so far. It was may intention to try to make it as rugged and useful as possible without over loading the user. I have seen a few Tricorders in the past, but they are a rare breed. I like how this came out and hope to keep on developing it. 

  Some current modifications for the newest revision is:

  • A much nicer industrial style power LED
  • Lots of Internal code revisions
  • A newer power switch that is low profile, so you can't bump it on/off as easy
  • All switches wired and working
  • Cutouts on the back for better grip of the device
  • Lots of field testing on the auto environment detection feature (indoor, outdoor, and vehicle) 

  When I have some additional funds I plan on at least getting a nicer professional 3D printed case for it so the symbols and names show up and no layer lines. The program is up to about 6k lines of C++ at this point.

  I'm finding out however I'm pushing the 12C bus a bit hare with traffic, so I'm looking into solutions. One is some type of I2C MUX chip or possibly moving to dual processors. A MUX chip may be the easiest as I can put some of the lower traffic sensors like light, temp and humidity on it. With GPS and the IMU on its own bus. Some PCB's for the main controller and sensor board will need to wait till I have some time to design them but they are high on the list so I can both reduce the thickness and overall size a bit. 

• Menu System

  Apollo Timbers • 08/02/2025 at 19:07 • 0 comments

  Still don't have all the buttons installed, but I wasn't going to let that stop me from building out the menu systems.

  Currently I'm controlling everything from the serial interface using WASD and E and M for Up, Down, Left, Right, Menu and Enter. The menu system is quite functional - first, the menu button stays on screen at all times, then you can press E or M to enter the menu system. From there you can access:

  1. Screens: Load individual static screens to lock them in place. The system continues monitoring all sensors but only displays what you're asking for - Thermal, System, Compass, Weather, and so forth.

  2. Settings: Two options here - Brightness (which does nothing yet) and Units, which switches all sensor data from Metric to Freedom units.

  3. Imager: Just a placeholder for when I reintegrate the thermal imaging camera.

  4. Mode: Normal mode cycles through all screens, while Low Power mode actually does something useful - it refreshes the screen less frequently and polls sensors less often too. I was thinking about adding a deep sleep mode, but then I thought... just turn it off?

  5. Mark: Records your current location via GPS along with all sensor data to the SD card.

  6. About: An auto-scrolling section with info about me, current firmware level, and a brief description.

  7. Reboot: Asks for confirmation (yes/no) then reboots the MCU. Sure, you could turn it off and on again, but why not have this feature? It's cool and it just works.

  Below is a video of it in action.

• There are two cores, funny enough...

  Apollo Timbers • 07/28/2025 at 22:29 • 0 comments

  So here’s the thing. I went through the painstaking process of converting the entire codebase to C++. All of it. Beautifully brutal. (10,000 lines yep...) Then I noticed it was running slower than CircuitPython. Which, for the record, is like being outpaced by a kid on a tricycle while you're driving a sports car with the parking brake on.

  Turns out Python, bless its interpreted little heart, automatically spreads the workload across both cores. Meanwhile, my glorious C++ code was partying hard on just one core like it was 2002.

  And yes, in case you're wondering, the RP2350 in the Pico 2 has two cores. Two whole floating point capable cores just sitting there, sipping coffee, waiting to be asked to do literally anything. Moral of the story: delegate. Core 1 now handles sensor polling and weather logic, which includes some wonderfully blocking sensor reads. Core 0 sticks to the main loop and display manager like it’s got a purpose again.

  Bonus update. I added my favorite feature yet: a working compass using the BNO085 IMU. It’s ridiculously accurate. I compared it to a real compass and was honestly insulted by how well it performed. So yeah, navigation just got a serious upgrade.

  Next on the roadmap is breadcrumb mode. Mark your path using sensor fusion, then retrace your steps like a tiny digital Hansel, minus the birds.

  Anyway, if you want to see the thing, here’s the teaser site:

  https://realatlas.carrd.co

  Go ahead. Click it. Your browser probably won’t catch fire.

• ATLAS Update: From CircuitPython to C++, and into the fire

  Apollo Timbers • 07/27/2025 at 01:23 • 0 comments

  Big update: I’ve officially ported all core code for ATLAS from CircuitPython to C++. \o/

  That’s a huge milestone, though not without pain. Here are a few fun (read: painful) lessons from the process.

  Lesson 1: Just because it worked in Python doesn’t mean it’ll work in C++

  Yeah, I know. Obvious, right? But getting text to scroll correctly in C++ took way more time than I care to admit. Python lets you get away with things. C++ reminds you that memory is real, types matter, and no, that thing you tried isn't going to compile.

  Lesson 2: GPS Library Swap = CPU Spike

  Originally I had a custom GPS parser, but when moving to C++ I switched to the SparkFun's u-blox GNSS library. That came with its own set of problems. CPU usage jumped from 10% to 57–78%. The main issue? GPS was updating way too fast.

  Let’s be honest... this isn’t a Tomahawk missile skimming treetops. There's no reason to poll GPS faster than every 3 seconds or so. Once I throttled that, the CPU calmed down.

  Lesson 3: SSD1325_TrueGrey.h survived the war

  My custom grayscale OLED display driver worked perfectly after the transition. No edits, no weird quirks. Still rendering clean text and thermal visuals. I’m calling that a win.

  Lesson 4: Thermal Mode Now Has Its Own Lane

  The thermal imager is I²C-heavy and CPU-greedy. So now, a long press on button 1 puts ATLAS into thermal mode, shutting down all other sensors and screens. (and back again) A press on button 2 swaps into Medical Mode. It’s not elegant, but it works — and it gives the system enough breathing room to handle the imager properly without data lag or weird interference.

  Lesson 5: I thought I was building a guidance system… 

  I thought I was building Apollo’s space guidance computer — a clean, practical interface for Earth-bound explorers. What I’ve actually built is starting to resemble HAL 9000.

  Somehow, I’m stuffing all of this onto a Raspberry Pi Pico 2: GPS parsing, sensor fusion, thermal imaging, grayscale display rendering, environmental classification logic, and now — soon — speech. I’m in the process of merging in the Talkie speech synthesis library to add voice output: basic warnings, system alerts, and maybe the occasional deadpan comment about an incoming storm or bad air.

  It’s not conversational (yet), but it’s veering toward full sci-fi. Let’s just hope it doesn’t start asking who’s in charge of the mission.

  Hardware Status

  I'm wiring up the two working buttons — the others have been out of stock forever — and I'm finalizing the design for both the main MCU board and a modular sensor board. There's also a teaser website live now. It's nothing fancy, but it helps keep momentum up.

  Ten hours of software dev later, ATLAS is operational, switching modes, logging smart GPS reads, and still running under ~30% CPU. Progress. Painful, but real.

  – Apollo out.

View all 35 project logs