TrailBuddy

Active walk display mockup
Start walk display mockup (closed eyes)
Start walk display mockup (open eyes)
Start walk display mockup (tongue sticking out)
Web application mockup
Figma Mockup

🌲 Inspiration

TrailBuddy started with a simple question:

What if you always had a friend to walk with?

We wanted to combine the nostalgia of caring for a virtual pet with something that encourages people to explore outside. Instead of leaving your buddy at home, TrailBuddy joins your adventure, tracks your walk, and gives you another reason to keep moving. 🐾

TrailBuddy pet demonstration

🐱 What it does

TrailBuddy is a Raspberry Pi-powered virtual pet and GPS trail tracker.

Our working hardware prototype allows users to:

🥕 Feed their virtual pet
💚 Pet it and manage its happiness
🍽️ Monitor its hunger
🛰️ Record a real walk using GPS
📺 View the pet, distance, time, and GPS status on an OLED screen
💾 Save walks locally on the Raspberry Pi
📤 Upload a completed walk to the laptop after reconnecting

When the user selects Send, the Pi creates a walk through our API, uploads its recorded GPS points, and marks the walk as completed. The backend then stores the walk persistently in SQLite.

Our React frontend includes an interactive Leaflet and OpenStreetMap interface that demonstrates how users and their friends’ routes can be visualized.

TrailBuddy route demonstration

🛠️ How we built it

TrailBuddy combines physical hardware with a complete software stack:

Hardware: Raspberry Pi, GPS module, OLED screen, and physical button
Hardware software: Python, GPIO controls, GPS parsing, Pillow, and local SQLite storage
Backend: FastAPI and SQLite
Frontend: React and Vite
Maps: Leaflet and OpenStreetMap
Design: Figma

The Raspberry Pi stores GPS coordinates locally throughout a walk. Once the walk ends, it sends the route to a FastAPI server running on a laptop connected to the same hotspot.

The backend supports:

Persistent walks and GPS points
Retry-safe batches of GPS points
Walk distance, duration, pace, and point-count summaries
Four demo user profiles
Friend requests and friendships
Private, friends-only, and public walk visibility
Timed GPS data for future route replay
Safety-event storage
Location-sharing permissions and Last Ping information

We also wrote automated backend tests covering the walk lifecycle, persistence, friendships, visibility, GPS validation, walk summaries, safety events, location sharing, database migrations, and connection cleanup.

😅 Challenges we ran into

Our hardest challenge was connecting the Raspberry Pi to the FastAPI backend and ensuring it sent the correct information.

The Pi originally stored walks using local numeric IDs and Unix timestamps, while the backend expected UUIDs, ISO timestamps, and a different GPS point structure. We had to transform and validate the data before uploading it.

Networking added another challenge. The Pi and laptop needed to be connected to the same hotspot, FastAPI had to listen on 0.0.0.0, and Windows Firewall had to allow the connection.

We also encountered:

GPS fixes and inaccurate coordinates
OLED and physical-button reliability issues
SQLite connection handling
Frontend build and Node.js setup
Git branches, merge conflicts, and teammates updating main
Learning several unfamiliar frameworks during one hackathon

There were many moments when one part worked independently but did not yet communicate with the others. Seeing the Pi finally upload a complete GPS walk successfully was one of the most rewarding moments of the project. 🚀

🎉 Accomplishments that we’re proud of

We are especially proud that:

This was our first hardware project
Our physical pet has animations, hunger, and happiness
The Pi records real GPS coordinates
The Pi successfully uploads completed walks to our FastAPI backend
Walks and GPS points are stored persistently in SQLite
Walks remain available after restarting the server
The backend validates GPS coordinates and timestamps
GPS batches can avoid storing duplicate points
FastAPI serves both the API and the built React application
We created the foundation for social, racing, location-sharing, and safety features
Four team members combined hardware, backend, frontend, and design work into one project

⏳ What we couldn’t finish

We built more backend functionality than we had time to connect to the user interface. Some features remain prototypes or foundations for future work:

Real route integration: The React map currently displays sample routes instead of GPS points retrieved from the backend.
Real friend data: The friends sidebar currently uses mock profiles and locations.
Walk selection: Users cannot yet select between their uploaded walks from the interface.
Ghost racing: The backend stores timed GPS points and a follow/race permission, but the animated ghost and time comparison were not completed.
Public trail discovery: Visibility rules exist in the backend, but there is no public trail browser in the frontend.
Live location: The backend stores Last Ping information, but the Pi currently uploads its route only after a walk ends.
Safety check-ins: The backend can store check-in and SOS events, but the complete physical check-in and emergency-contact notification flow was not finished.
Authentication: The demo uses four seeded users and an X-Demo-User-Id header instead of real accounts.
Additional pets: Cat, capybara, dog, and bear profiles exist in the database, but only the cat has complete visual assets.
Automatic synchronization: Failed uploads can be retried manually, but a complete automatic background synchronization queue was not finished.

Even though we could not complete every feature, we designed the backend so these ideas can be added without rebuilding the entire project.

🧠 What we learned

We learned that hardware and software integration depends heavily on agreeing on data formats and responsibilities early.

We gained experience with:

Raspberry Pi hardware and GPIO
Reading and validating GPS information
Designing APIs for physical devices
FastAPI and SQLite
React, Vite, Leaflet, and OpenStreetMap
Offline-first data collection
Testing and debugging across multiple devices
Git collaboration and resolving merge conflicts
Dividing a large idea into smaller team responsibilities

Most importantly, we learned how to keep adapting when our original plan met real hardware limitations.

👋 About us

Team Hackattack was formed in July 2026 at BloomKnights, the first hackathon for all four of us.

Inspired by the projects and people we met there, we decided to reunite for KnightHacks and challenge ourselves to build our first hardware project: TrailBuddy.

Our team consists of Sam, Xavian, Pablo, and Laeh. Each person contributed their own ideas and skills across hardware, backend development, frontend development, and design.

Combining a Raspberry Pi, GPS hardware, an API, a database, and a React frontend pushed each of us outside our comfort zones. TrailBuddy was a major learning experience, and we hope to carry everything we learned about teamwork and hardware-software integration into future hackathons. 💚

🔮 What’s next for TrailBuddy

Our first priority is replacing the frontend’s sample routes with real uploaded GPS data.

After that, we would like to add:

🗺️ A completed-walk selector
👻 Ghost racing against a friend’s recorded trail
🌐 Public and friends-only trail discovery
📍 Optional live location and Last Ping display
✅ Physical safety check-ins
🆘 Emergency-contact notifications
🔐 Real accounts and authentication
🐻 Additional pets and customization
📶 Reliable automatic offline synchronization
🏆 Achievements, challenges, and walk statistics

Our long-term goal is to make exploring outside feel safer, more social, and more playful.

🎨 Figma Challenge

View our TrailBuddy designs in Figma

Built With

Submitted to

Knight Hacks IX

Created by

I built and tested much of TrailBuddy’s FastAPI and SQLite backend, including persistent walks, GPS uploads, summaries, sharing, and social features. I also helped in testing the connection between the Raspberry Pi to the API and debugged networking and data-format issues. This was my first hardware project, and I learned a lot about integrating physical devices with a web application.

samuel olarte
I worked on the physical hardware of the device. Connecting each module through a breadboard and then into the Raspberry Pi 5 GPIO pins. I was also responsible for making the Python code that runs the TrailBuddy itself. I learned a lot about hardware and embedded systems through this project. Also increased my confidence in working with linux-based systems.

Pablo Garcia
I worked on the frontend, specifically the on the map. This is my first time using the frameworks and tools needed for this, including including React, Leaflet.js, React Leaflet, Vite, and OpenStreetMap, which was challenging yet rewarding.

Laeh Pimentel
Xavian Martin