Skip to content

GEWIS/gelift-tracker

GELIFT tracker

GELIFT weekend is a hitchhiking competition where teams compete against each other to be the fastest at the location. Challenges can be completed to receive a time deduction. GELIFT tracker is the piece of software that is used to publish the current location of the teams in the GELIFT weekend in real time to both the participants and the rest of the world to see who is closest to the finish.

System design

System requirements

The app is built on three main goals in order of importance:

  1. Availability, accuracy, and precision of the locations. The location is used for safety as well, so this needs to be available, accurate, and precise at all times.
  2. Ease of use for the participants. The set-up should be as minimal as possible to make sure they use this app instead of the other common solutions, such as Life360 or WhatsApp.
  3. Mobile first frontend. The frontend of the application should be easily accessible on mobile and poor WiFi, as it should be possible to reach while on the road (for the participants), and the link is generally shared on messaging apps on mobile.

System architecture

The app works on three main components, as visualized below. System architecutre

  • Location publisher: For the location publisher, the OwnTracks app is used; This app can function in two modes, namely MQTT and HTTP mode. For the first requirement, MQTT has been chosen, as it off-loads some of this availability to existing applications. What is known for OwnTracks as "user" has been defined as the teams, and what OwnTracks calls "devices" have been called "participants". So, for each participant "Pluk" from the team "Petteflet", they publish to /owntracks/petteflet/pluk with the messages described in the OwnTracks documentation.
  • MQTT Broker: As suggested by OwnTracks, the Mosquitto broker is used. Its responsibility is making sure that the location from the publisher arrives at the server, and is published to the Go backend. MQTT has some techniques for this as described in the protocol specification.
  • Location API: The Location API is a piece of custom code that makes sure that the locations as received from the MQTT Broker are stored in an format that can be used by the frontend. This includes things like the team, the participant, the battery percentage, the time, but most importantly, the location. The location API does not calculate any extra properties, but does make sure that every entry is unique in terms of the MQTT message. Finally, it also exposes a single HTTP endpoint for serving the tracks that are stored in the database. The endpoint is public, and it is possible to create multiple frontends for displaying the tracks. GORM, Echo and Paho are used as libraries for the ORM, webserver, and MQTT client, respectively.
  • Backoffice: The backoffice uses a very simple single password authentication, and allows very straightforward editing of settings. Or for easy importing of OTRC (owntrack configuration) files for participants.
  • Location visualizer: The location visualizer is the React app that displays the tracks. It takes the tracks from the location API, groups this data by the user/team, sorts the data on timestamp, and calculates properties like distance to the destination. It also contains some settings for customizing visualization. For the maps Leaflet + OpenStreetMaps is used, primereact + tailwindcss for components and styling.

Changelogs

Future ideas

  • Split the app into microservices, with a separate service for the MQTT server/client, the API, backoffice, and the frontend. This allows for more stability, the frontend can then be redeployed during the weekend without downtime for the Location API.
  • Timeline to scroll back in time
  • Add photos at locations for challenges and other things
  • Backoffice for managing teams/participants
  • Generation of OTRC files, and MQTT credentials for teams/participants

v2026

  • Dockerization of the components
  • Kubernetes deployment
  • Restructuring of the backend codebase
  • Admin backoffice for basic settings (start/end time, destination)
  • Participant backoffice for easy OTRC loading
  • Tried switching to maptiler, but ran into quota limits

v2025

  • Initial release
  • Visualize current location and history
  • Switch between individual view and team view
  • Switch permanent tooltips
  • Switch on/off specific teams
  • Info on who published and when
  • Distance to destination and arrival time

About

Application used in the hitchiking competitions of GEWIS

Resources

License

Contributing

Security policy

Stars

Watchers

Forks

Packages

 
 
 

Contributors