This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass
Most hiking trouble isn't dramatic. Nobody falls off a cliff. Someone simply keeps going a little too long because the summit is "just around the corner", the sun sets earlier than they thought, and the only person who knows where they went is themselves.
Two things would fix most of that:
- Knowing, before you leave, the time you should turn around, based on how fast you actually walk rather than a sign at the trailhead.
- Someone you trust finding out automatically if you don't come back, without you having to remember to tell them.
So I built Turnaround. You spend about two minutes with it before a hike, then put your phone in your pocket.
What I Built
Turnaround is a hiking companion that runs entirely on your own laptop. Before a hike it gives you three times:
- Turn around by: not at the top or the far end by this time? Head back.
- Back by: 9 in 10 hikes like yours finish before this.
- Sunset margin: how much daylight you have to spare.
Then it does four things:
- Predicts how long you will take, as a range rather than a single guess. An open tabular foundation model (TabPFN) learns from 7,186 real recorded hikes and adjusts to your pace after every hike you finish.
- Briefs you out loud. Gemma 4, running locally, turns the numbers into a short spoken briefing that sounds like a friend who hikes. It's saved to your phone before you leave, so it plays with no signal.
- Watches. When you tap Start, a durable safety timer begins waiting for your check-in.
- Tells someone. If you're well past your back-by time and still haven't checked in, your emergency contact gets an email with your plan, your route and a map link to where you set off. If you then check in late, they get a second email saying you're safe.
No GPX file? You just enter the three numbers every trail page lists (distance, elevation gain and trailhead), and Turnaround plans from those.
Who it's for: anyone who hikes alone or is new to it, and anyone with a parent, partner or friend who worries when they head out.
How it gets you off the screen: the screen part is the beginning and the end of the trip. Plan, listen, pocket the phone, walk. The next time you look at it is to tap Hike complete.
How it works
Demo
The video walks through the whole flow: planning a hike, the spoken briefing, starting the trip and the safety timer, and checking in.
Turnaround runs on my laptop, by design (more on that below), so there's no public link. The repo has one-command-per-terminal setup if you want to run it yourself.
Code
CodeNeuron58
/
Turnaround
An open-source hiking companion
MIT-licensed. CI runs typechecks, the app build and two unit-test suites on every push. Everything I claim below has a file in the repo backing it.
How I Built It
Everything runs on one laptop:
- Phone or browser → the app (React + Vite), reached over Wi-Fi or Tailscale
- App → the prediction service (FastAPI + TabPFN + SQLite)
- Prediction service → Gemma 4 (via Ollama) for the briefing, Kokoro for the voice, and the Temporal server to arm the timer and send check-ins
- Temporal worker → the alert and all-clear emails to your contact
The only things that leave it are an anonymous weather lookup (coordinates only) and, if you're overdue, the alert email.
1. Predicting your hike time: TabPFN
The classic hiking-time rule is Naismith's rule: roughly 12 minutes per kilometre plus 1 minute per 10 m of climbing. It's on half the trail signs in the world, and it gives the same answer for everyone.
I wanted a range, and I wanted it to fit the person. TabPFN is an open tabular foundation model: you give it a table of examples and it predicts new rows in context, with no training loop. Crucially for a safety tool, it returns a full predictive distribution rather than one number.
The data is 7,186 GPS-recorded hikes from hikr.org (a public Kaggle dataset, CC0). The features are distance, climb, descent, highest point and the SAC difficulty grade (T1–T6). I held out 1,438 hikes the model never saw and compared it with Naismith:
| On 1,438 unseen hikes | Naismith's rule | TabPFN v3.5 |
|---|---|---|
| Average error | 44.1 min | 34.8 min |
| RMSE | 69.1 min | 54.5 min |
| Real times inside the predicted 90% band | — | 89.5% |
| Hikers back before the "back by" time (P90) | — | 90.4% |
The last row is the one I care about most. A safety tool has to be honest about its uncertainty, not just accurate on average. When Turnaround says "9 in 10 hikes like this are done by 4:40", that turns out to be true for 90.4% of hikes. Average error being 21% lower is a nice bonus.
On a laptop CPU I serve TabPFN v2 by default. It's about 3x faster with nearly identical calibration (89.7%). The v3.5 checkpoint is one environment variable away.
How the prediction becomes decisions:
- Back by = the 90th percentile + your planned breaks.
- Turn around by = the share of that time you should spend heading out, assuming you retrace your steps. Climbing happens on the way out, so steep routes front-load it (Naismith's split, clamped between 50% and 70%).
- Alert = the 95th percentile + breaks + 30 minutes of grace. I deliberately didn't make it the back-by time: your contact should only be emailed when you're genuinely late, not five minutes slow.
Learning your pace. The crowd isn't you. Every hike you finish compares your actual moving time with the model's median for the same route, and the ratios combine into a personal pace factor. It's shrunk toward 1.0 on purpose, so one bad day can't swing the safety timer. A hike that was 40% slower than predicted moves your next estimate up about 12%, not 40%. Hikes where you tapped I turned back early don't count, because a turned-back time says nothing fair about the whole route. All of these rules are in a small, unit-tested module.
2. A promise that survives a crash: Temporal
The scariest bug a safety app can have is a timer that silently dies. If the alert depends on a Node process staying alive for six hours on a laptop, it's not a safety feature, it's a hope.
So the safety timer is a Temporal workflow. One tripWorkflow per hike races a check-in signal against a durable timer set to the alert moment. Sending the email is an activity with retries. A late check-in after the alert triggers the all-clear. I run Temporal's free local dev server with an on-disk database, so timers survive a restart of the server itself, not just the worker.
Then I tried to break it. Each scenario has its workflow history or logs committed in docs/evidence/:
| # | What I did | What happened |
|---|---|---|
| 1 | Checked in on time | Timer closed, nobody emailed |
| 2 | Missed the check-in while the mail server failed | Activity retried; alert went out on attempt 2 |
| 3 | Killed the worker mid-trip, restarted it 25 s later | Alert still fired exactly on the deadline: 90.5 s after start, despite the worker being dead from second 20 to 45 |
| 4 | Drill: missed check-in, then a late check-in | Alert on the deadline, then an all-clear |
| 5 | Killed the Temporal server mid-trip | Timer survived on disk; a check-in sent during the outage reported the failure honestly and landed when re-sent |
Scenario 3 is the whole reason Temporal is here. The promise didn't notice the outage.
This is what your contact actually receives. Both emails below were delivered to my own phone through Brevo, using the same templates and code path the worker uses (sent with the preview command, which is why they're marked [PREVIEW]):
The alert says who, which route, when they set off and when they should have been back, with a one-tap map link to the starting point. The all-clear tells your contact they can stand down. Nobody has to decode a log file at 4 a.m.
The app is equally honest when something is wrong. If the timer fails to arm, the trail screen shows a red "safety timer NOT armed" banner with a retry button rather than pretending you're covered. If you check in with no signal, the check-in is saved on the phone and sent the moment it can reach the laptop, and re-sending is idempotent, so a flaky connection can't double anything.
3. A briefing that sounds like a friend: Gemma 4 + Kokoro
Numbers on a screen are easy to ignore. A voice in your ear saying "If you're not at the top by 1:40, turn around. The view will still be there next weekend" is not.
Gemma 4 (E4B) runs locally through Ollama's OpenAI-compatible endpoint. The service hands it the trip's facts (distance, climb, turn-around and back-by times, sunset, rain chance, trailhead) and asks for 4 to 6 short sentences "like a friend who hikes, not a robot", always including the turn-around rule. Kokoro, an open 82M-parameter text-to-speech model, reads it aloud on the same machine. The text and audio are generated once, stored, and saved to your phone while you still have signal.
Gemma is the voice, never the source of truth: every number it speaks comes from the prediction service, and if the sunset time is unknown, the prompt tells it to say so rather than invent one.
The app
React + Vite, three screens: Plan, On trail and Summary. Your phone reaches the laptop over the same Wi-Fi, or over Tailscale on mobile data, so nothing is exposed to the public internet. Weather and sunset come from Open-Meteo, with no API key and coordinates only. Alert emails go through a free Brevo account, and every email is also written to a local outbox as a record.
Why Does Open Innovation Matter?
Think about what a hiking plan reveals: where you'll be, that you'll be alone, and until when. I don't think that belongs on someone else's server, and with open models it doesn't have to.
- Your location stays on your machine. Gemma 4, TabPFN and Kokoro all run on my laptop. A closed AI API would see every trailhead I start from and every hour I'm out alone.
- It costs nothing to run. No subscription, no per-request bill, no key that expires mid-hike. A hiking club could host it for its members on one old laptop or a Raspberry Pi-class box.
- The uncertainty is mine to inspect. With TabPFN's weights and a public dataset, I could measure calibration on 1,438 unseen hikes myself. A closed "estimated time" API gives you a number and asks for trust. For a feature that decides when your family gets an alarming email, I wanted the evidence.
- Everything is swappable. The checkpoint is one environment variable (v2 for speed, v3.5 for accuracy), Gemma could be any model behind an OpenAI-compatible endpoint, and Piper is a drop-in fallback for Kokoro. Nothing in the stack can be deprecated out from under it.
- The data is a commons. The model learns from thousands of hikers who shared their tracks publicly, and gives each new hiker something back.
Where open was genuinely better for me, not just cheaper: calibration. I needed to know that "back by" means 90%, and I could only know that because I could run the model myself on data I could see.
Honest limits. So far I've tested Turnaround at home, with sample routes and missed-check-in drills; taking it on a real trail is next. It's a prototype, not a replacement for telling someone your plan or carrying a satellite messenger in real backcountry. The laptop has to stay awake and online for the alert to send. The model knows hikr.org's mostly Alpine hikers best, and the pace factor exists precisely because you are not them.
Prize Categories
- Best Use of TabPFN: TabPFN predicts each hike's moving time as a calibrated distribution. Its P90 becomes the back-by time, its P95 sets when your contact is alerted, and its median feeds your personal pace factor. On 1,438 unseen hikes it beat Naismith's rule (34.8 vs 44.1 min average error) with 90.4% of hikers back before P90.
- Best Use of Temporal: the safety timer is a durable Temporal workflow that races a check-in signal against the alert deadline, retries the alert email, and sends an all-clear on a late check-in. Tested by killing the worker and the Temporal server mid-trip, with evidence in the repo.
- Best Use of Gemma: Gemma 4 runs locally via Ollama and turns each trip's numbers into a short spoken briefing (voiced by Kokoro) that's saved to your phone before you lose signal.
Thanks for reading. If you hike alone, I'd love to hear what would make you actually use something like this, and what time you'd want to be told to turn around. 🥾
Top comments (1)
tr.ee/dev-to
Some comments have been hidden by the post's author - find out more