Inspiration
I built this because I kept losing small chunks of time to my phone and wanted a simple, physical way to make starting focused work effortless. The system is a tiny Flask server and web UI plus two devices: an RPI5 that detects phones with a local CV pipeline, and a Pico W that sits on the desk as the display and controller. It is as simple as adding tasks in the browser and starting a session; the Pico shows the task and timer, accepts button inputs, and optionally notifies you when the RPI flags a phone – all running locally and physically so you don’t have to keep touching other devices.
What it does
Pi-crastinator exposes a small REST surface for session and task state. The server implements the authoritative Pomodoro timer and session transitions; clients poll or post actions against endpoints such as /api/pico. The Pico W polls the server; updates an I2C LCD (1602 style) that displays the task, time remaining, and whether a break is currently active; drives a 10‑segment LED progress bar so that users can quickly estimate how much time is left before the next session; a buzzer to indicate when a button is pressed, a transition between work and a break occurs, or to encourage the user to put their phone down; controls four buttons that can delete a task, stop a task, skip to the next work or break session, and skips to the next task; and includes a slide switch to turn phone monitoring on or off. The RPI5 runs a local phone detection pipeline (YOLO + fallbacks and Roboflow) and reports a phone detection flag to the server, where the Pico W can then notify the user of their treason via the alarm.
How we built it
I implemented the system as three cooperating pieces: a small Flask server (server/app.py) that holds the Pomodoro state and exposes endpoints like /api/pico, /api/timer-status, and /api/phone-status; a Pico W client (picow.py) running MicroPython that polls /api/pico, updates an I2C 16×2 LCD, drives a 10‑segment LED bar and a buzzer, and reads four buttons plus a slide switch with software debouncing and reconnect/retry logic; and an RPI5 phone detector (rpi5code.py) that captures frames with Picamera2, attempts YOLOv8 and falls back to a YOLOv4‑tiny OpenCV DNN, then applies short temporal smoothing and simple heuristics (area/aspect/confidence filters) before POSTing an update to the server; frames are processed in memory and not persisted.
Challenges we ran into
Debugging the I2C 1602 LCD cost more time than I expected: it had an adjustable contrast that was initially too high for text to be visible, and with me being unfamiliar with the hardware, I spent roughly fifty minutes troubleshooting why text wouldn’t appear.
Running and testing the phone‑detection pipeline on the RPI5 introduced another class of problems. Installing and configuring the various toolchains on a Linux Pi exposed dependency and runtime conflicts that required scripted installs and fallbacks, and the detection task itself proved hardest: phones are frequently occluded, rotated, or seen in poor lighting, so making the detector usable in just some scenarios was quite difficult.
Accomplishments that we're proud of
We implemented a compact, maintainable stack that ties real hardware to a real server with pragmatic choices at each layer. On the Pico side, the I2C 1602 LCD integration, the 10‑segment LED bar, the slide switch for phone‑monitoring, and robust button handling (debounce and per‑button timestamping) are all implemented and tested in the field. The buzzer supports short, configurable patterns and a background blare thread for sustained alerts when needed.
On the server side, the timer is authoritative and supports session counting and automatic long‑break logic. The /api/pico endpoint returns a full snapshot of task, timer, and phone state so the Pico can reconcile locally without complex protocols. The RPI detection module runs inference locally and gracefully falls back to simpler detectors or heuristics when the primary model is unavailable. Overall, the system is resilient to typical edge cases: intermittent Wi‑Fi, brief detection noise, and user actions from multiple clients.
What we learned
Working with the hardware taught me how to read hardware documentation more effectively and I became more familiar with moderately-popular hardware like the I2C LCD and the slide switch wiring. Managing the RPI5 detection stack gave me a lot of experience with working with Linux (as it was running a Debian-based OS), especially since I accessed it through the CLI and XQuartz. Finally, I also recapped working with APIs (this being my second project where I implemented them) as I had to develop my own as well as use the one provided by Roboflow when building the phone detection model.
What's next for Pi‑crastinator
Next, I want to add inetgration with iCloud reminders, Microsoft ToDo, and Google Tasks, and then add a short calibration flow for the RPi camera so detection adapts to different rooms and lighting. I want to add an analytics view so people can see when they are the most focused and most distracted. Beyond that, I want to add a settings menu for users to configure their own UI and tune buzzer volume, LED intensity, and session lengths. None of these are revolutionary, but together, they make the tool more respectful, more useful, and more likely to become a habit.
Log in or sign up for Devpost to join the conversation.