touch grass by command: building walkie, an offline AI that decides when you walk
This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass
What I Built
walkie — a walk planner that decides for you, so you spend less time on a screen and more time outside.
Most of us don't skip the walk because we're lazy. We skip it because "when should I go? how long? where to?" turns into ten minutes of checking the weather app, then it's dark. walkie removes the decision. You configure your walk preferences once — time, length, pace — and after that a small AI model running on your laptop plans each day's walk:
1. It picks a time from today's forecast and daylight. Rain at 18:00? It moves you to 17:00.
2. It reminds you at T-30, T-15 and T-5, each with a quote. Do nothing and the plan auto-approves — the default is that you go.
3. It builds a route: a loop that starts and ends at your door, sized to today's duration, from an offline OpenStreetMap extract of your region.
4. It speaks the turns — "turn right", paced to your walking pace, as one local text-to-speech file.
5. Your phone downloads everything over home WiFi, you open the GPX in OsmAnd, start the audio, and put the phone in your pocket.
The screen is the shortest part of the experience: setup once, then it's a QR scan, a tap on OsmAnd, and walking.
I took it outside on October 10. A 1.8 km loop built from the local map, auto-approved for 17:30, notifications fired with quotes, the phone pulled walk.gpx over WiFi (serve log: GET /routes/walk.gpx 200), and OsmAnd's offline navigation ran the whole walk with no signal. Two honest findings from that walk went straight back into the code: I had recorded the screen for evidence, so screen time was n/a that walk, and a fresh user could finish the wizard with no route existing yet — that gap is exactly why the whole thing now runs behind a single command, make, that fills every setup gap in order and builds today's walk.
Demo
make
That's the whole interface. First time: it installs dependencies, pulls the AI model, downloads your region's map, opens a short wizard for your preferences, builds today's walk and opens a serve window with a QR code. Every later day the same command rebuilds only what changed.
On your phone (same WiFi): scan the QR, download walk.gpx + walk_audio.mp3, import into OsmAnd, walk.
!walkie serve window showing today's route on a map, a QR code with the phone URL, the downloadable file list, and reminder notifications including the 17:30 auto-approval
The demo video: the serve window with today's route, the reminder notifications (including the auto-approval), and the phone pulling walk.gpx over WiFi — watch for the GET /routes/walk.gpx 200 in the terminal at the end.
{% youtube YgV4LM7ZEuQ %}
Code
{% github kenedilichi1/walkie %}
How I Built It
The open pieces are the core, not a wrapper:
- Llama 3.2 3B through Ollama — one local call decides today's plan from today's inputs (proposal, weather, daylight)
- Piper — local text-to-speech for the spoken cues
- OSMnx + OpenStreetMap extracts — the offline route builder (one scan of a Geofabrik .pbf, street graph cached)
- Open-Meteo for the forecast — no account, cached, with offline fallback
flowchart LR
subgraph laptop["Your laptop"]
walkie["walkie<br/>(CLI + windows)"]
llm["Ollama<br/>local LLM"]
tts["Piper TTS"]
osm["OSM extract<br/>(offline map)"]
out[("output/<br/>today's walk")]
walkie --> llm
walkie --> tts
walkie --> osm
walkie --> out
end
subgraph net["Internet (best-effort)"]
meteo["Open-Meteo"]
geo["Geofabrik + Hugging Face"]
tiles["OSM map tiles"]
end
subgraph pocket["Your phone"]
page["Browser page +<br/>OsmAnd (offline)"]
end
meteo -.->|cached forecast| walkie
geo -.->|one-time download| walkie
tiles -.->|serve window| walkie
out -->|HTTP on home WiFi| page
Setting expectations for what a laptop-sized model can do was the useful starting point for me — posts like What Can You Do With Local AI on a 16 GB Laptop in 2026? by Ali Chherawalla and Run AI Locally on Your Mac with Ollama by rainytechlab.
The most interesting engineering wasn't the LLM call — it was not trusting it. One test run showed a requested 21:30/30-minute walk "planned" into 18:00–19:30/90 minutes: the model had drifted from its inputs. So every reply is validated against the input constraints before it's stored; drifted answers are rejected and the deterministic inputs win. The replay of that exact failure now sits in the repo's evidence folder as a regression test. The pipeline is otherwise staleness-driven — each stage rebuilds only when its inputs are newer — so a cron entry runs every minute for free. The gate is ruff + mypy --strict + 340 tests with a coverage floor.
Why Does Open Innovation Matter?
For this project, open isn't a preference — it's the product requirements list:
- It runs where closed APIs can't. The trailhead test (airplane mode on) still plans, builds the route, and speaks the cues: the weather fetch and Ollama both fail, and the full chain completes on cached inputs. A closed API is a network call; a closed TTS is a network call. Both would have died at "no signal" — the exact moment the app exists for.
- Your location and walk plans never leave your laptop. No account, no telemetry, no "send your day to a server you don't control."
- It costs nothing to run. No API fees, no subscription — the model is a one-time 2 GB download.
- It's yours to change. The model, the prompts, and your preferences are local files. ollama pull gemma3, edit one line of YAML, and the planner is a different brain. Try that with a hosted model's system prompt.
Where open beat closed most concretely: every component between "it's raining" and "turn right" is swappable local software, so the same offline guarantees hold at setup, at home, and on the trail.
Mentions
touch grass by command: building walkie, an offline AI that decides when you walk This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass What I Built walkie — a walk planner that decides for you, so you spend less time on a screen and more time outside. Most of us don't skip the walk because we're lazy. We skip it because "when should I go? how long? where to?" turns into ten minutes of checking the weather app, then it's dark. walkie removes the decision. You configure your walk preferences once — time, length, pace — and after that a small AI model running on your laptop plans each day's walk: 1. It picks a time from today's forecast and daylight. Rain at 18:00? It moves you to 17:00. 2. It reminds you at T-30, T-15 and T-5, each with a quote. Do nothing and the plan auto-approves — the default is that you go. 3. It builds a route: a loop that starts and ends at your door, sized to today's duration, from an offline OpenStreetMap extract of your region. 4. It speaks the turns — "turn right", paced to your walking pace, as one local text-to-speech file. 5. Your phone downloads everything over home WiFi, you open the GPX in OsmAnd, start the audio, and put the phone in your pocket. The screen is the shortest part of the experience: setup once, then it's a QR scan, a tap on OsmAnd, and walking. I took it outside on October 10. A 1.8 km loop built from the local map, auto-approved for 17:30, notifications fired with quotes, the phone pulled walk.gpx over WiFi (serve log: GET /routes/walk.gpx 200), and OsmAnd's offline navigation ran the whole walk with no signal. Two honest findings from that walk went straight back into the code: I had recorded the screen for evidence, so screen time was n/a that walk, and a fresh user could finish the wizard with no route existing yet — that gap is exactly why the whole thing now runs behind a single command, make, that fills every setup gap in order and builds today's walk. Demo make That's the whole interface. First time: it installs dependencies, pulls the AI model, downloads your region's map, opens a short wizard for your preferences, builds today's walk and opens a serve window with a QR code. Every later day the same command rebuilds only what changed. On your phone (same WiFi): scan the QR, download walk.gpx + walk_audio.mp3, import into OsmAnd, walk. !walkie serve window showing today's route on a map, a QR code with the phone URL, the downloadable file list, and reminder notifications including the 17:30 auto-approval The demo video: the serve window with today's route, the reminder notifications (including the auto-approval), and the phone pulling walk.gpx over WiFi — watch for the GET /routes/walk.gpx 200 in the terminal at the end. {% youtube YgV4LM7ZEuQ %} Code {% github kenedilichi1/walkie %} How I Built It The open pieces are the core, not a wrapper: - Llama 3.2 3B through Ollama — one local call decides today's plan from today's inputs (proposal, weather, daylight) - Piper — local text-to-speech for the spoken cues - OSMnx + OpenStreetMap extracts — the offline route builder (one scan of a Geofabrik .pbf, street graph cached) - Open-Meteo for the forecast — no account, cached, with offline fallback flowchart LR subgraph laptop["Your laptop"] walkie["walkie<br/>(CLI + windows)"] llm["Ollama<br/>local LLM"] tts["Piper TTS"] osm["OSM extract<br/>(offline map)"] out[("output/<br/>today's walk")] walkie --> llm walkie --> tts walkie --> osm walkie --> out end subgraph net["Internet (best-effort)"] meteo["Open-Meteo"] geo["Geofabrik + Hugging Face"] tiles["OSM map tiles"] end subgraph pocket["Your phone"] page["Browser page +<br/>OsmAnd (offline)"] end meteo -.->|cached forecast| walkie geo -.->|one-time download| walkie tiles -.->|serve window| walkie out -->|HTTP on home WiFi| page Setting expectations for what a laptop-sized model can do was the useful starting point for me — posts like What Can You Do With Local AI on a 16 GB Laptop in 2026? by Ali Chherawalla and Run AI Locally on Your Mac with Ollama by rainytechlab. The most interesting engineering wasn't the LLM call — it was not trusting it. One test run showed a requested 21:30/30-minute walk "planned" into 18:00–19:30/90 minutes: the model had drifted from its inputs. So every reply is validated against the input constraints before it's stored; drifted answers are rejected and the deterministic inputs win. The replay of that exact failure now sits in the repo's evidence folder as a regression test. The pipeline is otherwise staleness-driven — each stage rebuilds only when its inputs are newer — so a cron entry runs every minute for free. The gate is ruff + mypy --strict + 340 tests with a coverage floor. Why Does Open Innovation Matter? For this project, open isn't a preference — it's the product requirements list: - It runs where closed APIs can't. The trailhead test (airplane mode on) still plans, builds the route, and speaks the cues: the weather fetch and Ollama both fail, and the full chain completes on cached inputs. A closed API is a network call; a closed TTS is a network call. Both would have died at "no signal" — the exact moment the app exists for. - Your location and walk plans never leave your laptop. No account, no telemetry, no "send your day to a server you don't control." - It costs nothing to run. No API fees, no subscription — the model is a one-time 2 GB download. - It's yours to change. The model, the prompts, and your preferences are local files. ollama pull gemma3, edit one line of YAML, and the planner is a different brain. Try that with a hosted model's system prompt. Where open beat closed most concretely: every component between "it's raining" and "turn right" is swappable local software, so the same offline guarantees hold at setup, at home, and on the trail.