HARDWARE!

Inspiration

Everyone at a hackathon knows the food queue. You walk over, it is twenty people long, and you walk back hungry. Apps tell you how long a queue is right now. What you actually want to know is when to go.

Queues are predictable: a food drop, a rush, then a lull. So we built QueueTime, a £10 sensor box that watches the OxHack food point and tells you "go now" or "wait, it will be shorter at 19:10".

What it does

Measures the queue with a cheap Arduino box: an ultrasonic sensor, two IR beams that count people in and out, a hand-count button, and a webcam head-count as a cross-check.
Forecasts the wait 15, 30 and 60 minutes ahead, as a range (P10 / P50 / P90) rather than a single number, so you can see the uncertainty.
Recommends an action ("go now" or "wait, come back at 19:10 to save about 6 minutes") through a Gemini agent. Every number comes from Python tools. Gemini only chooses and explains, and a rule-based fallback takes over if it fails.
Tells you in four ways: a web dashboard, an installable phone app, green/amber LEDs on the box, and a spoken alert through ElevenLabs.

How we built it

Hardware: Arduino with an HC-SR04 ultrasonic sensor, two IR break-beams (entry and exit), a button for hand counts, two LEDs, and a Logitech camera. The box prints one JSON line per second over USB serial, and a logger turns it into CSV files.

Prediction model: We could not collect enough data in 24 hours, so we trained a LightGBM quantile model on the public TouringPlans Disney World wait-time dataset. The features are unit-free (the wait relative to 15, 30 and 60 minutes ago, relative to today's and this week's level, time of day, minutes since the queue last changed), so the model carries over from theme-park rides to a food queue. A cold-start variant hides the weekly baseline so it works on a brand-new queue.

Honest validation: We trained on 2015-17, tuned on 2018, tested on 2019 and kept 2021 untouched. We also left whole rides out. On unseen rides the model beat a "nothing changes" baseline on 13 of 14 zero-shot, and its 80% band covered roughly 80% of outcomes.

Software: a live queue-state estimator (with handling for beam drift and counter resets), the Gemini agent with function calling, a Streamlit app, and a standard-library web server for the dashboard and phone app.

Challenges we ran into

Sensors lie. A beam can count one person several times, the board can reset its counters, and the ultrasonic reading drifts. We added de-bouncing, reset stitching and drift handling.
The camera over-counts. In a staged test (3 people looping through the queue, 30 served by hand count), the camera counted 35, about 17% too many, because people hidden behind others came back with new IDs. That is why the camera is only a cross-check and the beams and hand counts anchor the numbers.
No real rush data yet. Our checks of the camera are from two staged tests, not a real dinner rush. We say so rather than pretend otherwise.
A flat forecast. The Disney-trained model is cautious about short, sharp food rushes, so on simulated data it often says "go now". We know this is the weak spot.

Accomplishments that we're proud of

A full loop from a £10 box to a spoken "go now" in 24 hours.
A model that works on queues it has never seen, validated on untouched data with its uncertainty shown honestly.
Candid numbers: where we are right (the 80% band, beating the baseline on unseen rides) and where we are not (the camera over-count, waits above two hours, a flat forecast on rushes).

What we learned

Always show uncertainty. A forecast with a range is more useful than a confident single number.
Unit-free features let a model move between very different queues.
Cheap sensors need honest checks. The +17% camera error only showed up because we counted people by hand.
Test on data the model has never seen, and report the awkward results too.

What's next for QueueTime

Record real rushes and compare the forecast with what actually happened.
Add a queueing-theory step (wait = queue length ÷ service rate) and a "minutes since the food arrived" feature so the model can say "wait" during a rush.
Tune the camera tracker on a second real rush to cut the double counting.
Deploy it as a hosted service so anyone can check a queue from their phone.