DEV Community: Abhinav krishna N

Every alarm clock punishes laziness. My Arduino UNO Q rewards it: a radar watches me sleep and lets me stay in bed 🦥

Abhinav krishna N — Mon, 26 Oct 2026 06:38:29 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady

What I Built

Every alarm clock punishes laziness.

It rings at the same minute whether you slept like a log or stared at the ceiling until 3 a.m. Then it hands you a snooze button, so you can chop your last half hour into nine-minute pieces of broken sleep. Snooze, snooze, snooze.

Sloth Clock 🦥 rewards it.

It's a bedside sloth built on one Arduino UNO Q. A 60 GHz radar watches how you actually slept, through the blanket, with no camera and no wearable. If the night was rough, or it's raining outside (a microphone listens for rain, keeping only sound features, never audio), it lets you stay in bed longer: up to 30 minutes, decided early, and never past the time you must be up. No morning run in the rain anyway. Then it wakes you the way a sloth would want, slowly: a sunrise climbs the LED matrix, a soft chime follows, and Gemma 3 1B, running on the clock itself, tells you why you got the lie-in:

06:45. Good morning, dear. Your sleep was a bit restless, so I've given you a longer rest.

That's a real message, written by the model on the board, offline.

The cardboard sloth: the UNO Q's LED matrix shows through the front, the radar on top faces the bed, and the no-glow e-paper card shows the morning.

TL;DR

📡 Senses: a 60 GHz mmWave radar reads breathing, heart rate and restlessness, and a small microphone listens for rain. No camera, no wearable, nothing to charge.

🧮 Decides: plain code scores the night and picks the alarm, inside health limits it cannot break.

🌅 Acts: an LED-matrix sunrise, a chime, a Gemma-written note, and an e-paper card.

🔌 One Arduino UNO Q, fully offline. No phone, no cloud, no account, no API key.

Lazy, but only the safe kind

Sleeping in is the easiest feature in the world to get wrong. So the sloth has rules it cannot break:

Rule
💤 Restless night (score below 60)	+15 min
🌧️ Raining outside	+15 min
🧱 Never more than	+30 min in total
⏰ Never past	your "must be up by" time
🚫 Snooze	does not exist
📅 Two days in a row	no, unless last night was very poor (score below 40)
🤷 Not enough radar data	normal alarm, and an honest "not sure"

They're hard-coded in one small file, not settings. Future sleepy me does not get a vote.

Slow and steady, all the way down

The theme isn't just the name. Every part of the clock is slow on purpose, and that's exactly what makes it reliable:

Part	Slow	Why slow is fine
🌅 Wake-up	A sunrise that climbs the LED matrix, then a soft chime	Nobody wants to wake up to a fire alarm
🧠 Gemma 3 1B	~4.4 tokens/s on the board's Arm CPU, 20–38 s per note	The decision is made 45 minutes before the alarm, so the model has 70× the time it needs
🪜 Your to-do list	One tiny step a day (5, 15 or 30 min)	Slow and steady is how a sloth gets anywhere

Demo

The video shows a full run: a 6-minute demo nap (tossing and turning on purpose), the decision (+15 min, restless night, score 33), the sunrise, the chime, and Gemma's note. Demo mode exists because you shouldn't have to sleep eight hours to see an alarm clock work. That would be a little too on-theme.

It sees you breathe. Here's the live page while I lie still, then while I hold my breath for a few seconds:

Breathing 15/min, heart rate 63 bpm, movement near zero. Nothing touches me.

Holding my breath: the breathing rate drops from about 15 to 2.5 per minute, then recovers.

The whole page, on any phone or laptop on the same network:

Live readings, the night score with every term, the alarm decision and the wake note, all served by the UNO Q itself.

The decision, with every rule shown:

Alarm 06:45 (usual 06:30, must be up by 07:00): +15 min, because the night scored 33 out of 100.

Code

Abhinavkrishna3211 / Sloth-Clock

A bedside sloth on Arduino UNO Q: a 60 GHz radar watches your sleep, the alarm gives you extra minutes when it’s safe, and a no-glow e-paper card moves procrastinated jobs forward one tiny step a day. Fully offline.

Sloth Clock 🦥

Slow and steady wins the morning.

Most alarm clocks punish you for being tired. Sloth Clock does the opposite: it watches how you slept, and if the night was rough, it lets you sleep in, safely. Then it asks for the smallest possible step on the job you keep putting off. Not the whole job. One tiny step.

Laziness, done properly, is a strategy. Rest when you need it, move a little every day, never panic That is how a sloth gets where it is going.

Everything runs offline on one Arduino UNO Q. No cloud, no account, no camera, no wearable.

The three lazy things it does for you

1. It lets you sleep in, and it earns that right

A 60 GHz mmWave radar on the nightstand reads breathing, heart rate and restlessness through the blanket In the morning the board scores the night. A…

View on GitHub

Path	What lives there
`app/sketch/sketch.ino`	STM32: radar line parser, 10 s rows, LED-matrix face and sunrise, chime, button, backup alarm
`app/python/`	Linux: SQLite, night score, alarm decision, Gemma notes + validator, tiny-step engine, web page
`firmware/`	The radar kit's XIAO ESP32C6 and the e-paper card's XIAO ESP32-S3
`tests/`	Decision, validator, night score and on-board Gemma tests
`docs/measurements.md`	Every number in this post, with date, setup and trials

MIT licensed.

How I Built It

Hardware

Everything in the clock. Top left: the XIAO ePaper Display Board EE04 with the 7.5" e-paper panel. Left, top to bottom: the round INMP441 microphone, the green PAM8403 amplifier, and the small cavity speaker for the chime. Bottom: the 60 GHz radar in its case, and the Arduino UNO Q.

Part	Job
Arduino UNO Q (4 GB)	The whole brain: an STM32U585 microcontroller and a Qualcomm QRB2210 running Linux, on one board
Seeed MR60BHA2 60 GHz mmWave kit	Breathing, heart rate, presence and movement, without contact
Seeed XIAO ePaper Display Board EE04 + 7.5" 800×480 panel	The no-glow card
PAM8403 amplifier + small cavity speaker	The soft chime, driven by a tone from the STM32
INMP441 microphone	Listens for rain. The STM32 keeps only a few sound features, never audio

Everything runs from USB: low voltage, no mains, nothing that heats up or moves. And the enclosure? Cardboard. I don't have a 3D printer, so the sloth lives in a box I cut and taped in an evening. Lazy and free.

The Arduino UNO Q: Linux and an STM32 on one board, with the 8×13 LED matrix that draws the sunrise.

The 60 GHz radar on top of the sloth, tilted down toward the bed.

The 7.5" e-paper panel and the XIAO ePaper Display Board EE04 that drives it. Even on the desk it shows the morning: wake up 06:45, "+15 min of slow morning, never later than 07:00", the month, what's coming up, today's tiny step and the note. And a sloth hanging from a garland of lights.

One-sheet wiring: the chime on D3, the button on D2, and the radar and card talking to the board.

Why the UNO Q, specifically

An alarm clock is a strange mix of jobs. Part of it must be hard real time: the alarm must ring and the button must work. Part of it is heavy and slow: a language model. Most boards make you pick one.

The UNO Q is two computers on one board, and Sloth Clock gives each the job it's good at:

	⚡ STM32U585 (real time)	🐧 QRB2210 (Linux)
Sense	Parse every radar line, count bad ones, build a 10 s summary row	Store rows in SQLite
Think		Night score, alarm decision with hard limits, Gemma 3 1B
Act	LED-matrix sunrise, chime, button, backup alarm	Validate every note, serve the web page, update the card

They talk over the Arduino Bridge. Each summary row is a handful of integers, and its largest possible message is 33 bytes, well under the Bridge's 256-byte limit.

That split is what makes it a trustworthy alarm clock:

🔘 The button lives on the microcontroller, so it works even while Linux is busy running a model.
⏰ The microcontroller has a backup alarm. If Linux ever misses the alarm, the STM32 rings on its own.
🕰️ No model is on the critical path. If Gemma is slow, down or wrong, a plain template is used and the alarm still rings on time.

The night score is explainable, not magic

score = 100 − (restless % + 0.5 × irregular-breathing % + 10 × long awakenings)

Each term is a share of the minutes observed, so a 6-minute demo nap and a full night use the same scale. The page shows every term, so you can see exactly why you did or didn't get your lie-in.

Gemma only words things. Code decides everything.

This was the most interesting part. A 1B model is lovely at sounding warm and bad at facts, and an alarm clock that lies about what time it is is worse than no alarm clock. So:

Code makes the decision and writes the reason in plain words.
Gemma only rephrases it in a sleepy, kind sloth's voice.
A validator checks every note before you see it:
- every number and time must appear in the decision record (6:45 is one time, not 6 and 45, and 2:10–3:30 is a range, not a minus sign)
- number words count too ("twenty" is a number)
- no "snooze", and no "extra time" if the alarm didn't move
Code writes the wake time at the front. The model never copies it.
One retry with a stricter prompt, then a template. Something honest always comes out.

Every rule exists because the model broke it. In one early test, on two nights where the alarm had not moved at all, Gemma cheerfully said "I've given you a little extra time" 😅. Each failure became a validator rule and a test.

On the board, across 10 different decision records:

Prompt version	✅ Valid first try	🔁 Valid after retry	📄 Template
Model writes the time itself	4 / 10	1 / 10	5 / 10
Code writes the time, model writes the reason	8 / 10	2 / 10	0 / 10

No wrong number got through. What the validator can't catch: in one retry, the model turned "you slept badly, but you already slept in yesterday" into "you've already had a restful sleep". Every number was right, but the meaning wasn't. Rules can check facts. They can't fully check feelings.

One tiny step a day

You type the job you keep avoiding. Gemma splits its first step into three sizes (5, 15 and 30 minutes), a checker rejects anything with invented numbers, and each morning the card shows one step. After a bad night, it shows the tiniest one. Rest counts too.

The open-source AI at the core

🧠 Gemma 3 1B (open weights, QAT Q4_0 GGUF): wake notes and step splitting.
⚙️ llama.cpp llama-server on the UNO Q's Arm CPU: 3 threads, no GPU, no internet, started at boot.
🧩 Arduino App Lab: one app made of a Python container, the MCU sketch and the web UI.
🧮 TabPFN v2 (open tabular foundation model): guesses which step size you'll actually finish, with a small numpy fallback built in. Tested on synthetic data so far, since real mornings take time to collect.
📡 Seeed's open mmWave library and Seeed_GFX on the two XIAOs.

Measured on the UNO Q	Result
Gemma generation	4.42–4.45 tok/s
First token, cold prompt	2.4 s
Wake note, including retries	20–38 s
Alarm decision + health limits	12 / 12 test cases
Note validator	20 / 20 test cases
Sketch size	97 KB flash (12%), 44 KB RAM (16%)
Radar vs manual breath count + reference heart rate	~80–90%

Every number here is logged in docs/measurements.md with date, setup and trials.

What it can't do (yet)

I'd rather say this than have you find it:

Radar accuracy: about 80–90% against a manual breath count and a reference heart rate in my tests. That's enough to tell a restless night from a calm one, but not enough for medicine. The movement number still jumps too easily, so calibration is next.
Rain bonus: it passes my tests at home, but it hasn't lived through a full monsoon of real mornings yet. A loud fan or a shower could still fool it.
It's a comfort device, not a medical one.

My Agent Session

I built Sloth Clock with Claude Code as my coding agent. Here's how we split the work:

🧑 Me	🤖 Claude Code
The idea, and the safe-laziness rules	Wrote most of the Python app, the STM32 sketch and the two XIAO firmwares
Picking, wiring and placing the hardware	Wrote the tests and the note validator, one rule per failure I found
Flashing, testing and every measurement on the board	Debugged from the logs and readings I sent back
Deciding what ships, and what the post claims	Kept `docs/measurements.md` and the progress notes up to date

The best part: every time Gemma broke a rule on the board, I pasted the bad note back, and the agent turned it into a validator rule and a test. That loop is why no wrong number got through.

Why Does Open Innovation Matter?

Because this device lives in your bedroom, watching you breathe. 🛏️

🔒 Your data never leaves the nightstand. No audio, no camera, and no raw radar waveform is stored anywhere. Only small rows go into a file on the board: a breathing rate, a heart rate and a movement number every 10 seconds. That's health data. With a closed API, every wake note would be a little report about your night sent to someone else's server.
🔌 It works offline. An alarm can't depend on the internet, a server, or an API key that expires. The radar is wired straight to the clock, and nothing leaves the room. If the Wi-Fi dies at 3 a.m., the sloth doesn't notice.
💸 It costs nothing to run. No tokens, no subscription. A year of wake notes costs $0.
🔁 I can swap the model. It's one GGUF file and one command line. When a better small open model comes out, the clock gets better without asking anyone's permission.
🔍 I can read every layer: the radar library, the inference server, the model. When something broke, I could find out why.

A closed model could write a slightly nicer sentence. It couldn't do it on a nightstand, offline, for free, without learning when you sleep.

The Lazy Payoff

😴 Up to 30 more minutes of sleep on exactly the mornings you need it, with zero risk of being late.
🧠 Zero decisions before coffee. No more bargaining with a snooze button, half asleep. The sloth already did the maths.
⌚ Zero effort to track sleep. No wearable to charge, no app to open, no button at bedtime. The laziest sleep tracker is the one you never touch.
🪜 Progress without willpower. One tiny step a day, and a smaller one after a bad night.

Prize Categories

Best Use of Arduino: the whole agent lives on one Arduino UNO Q, and each half does the job it's built for. It senses with a 60 GHz radar: the STM32 parses every line and builds 33-byte summary rows. It decides on Linux: night score, alarm logic with hard health limits, and Gemma 3 1B running on the board, offline. It acts on the STM32: the LED-matrix sunrise, the chime through a PAM8403 and a small speaker, the button, and a backup alarm that rings even if Linux doesn't. The two halves talk over the Arduino Bridge, packaged as one App Lab app. The STM32 also carries a register-level I2S driver and a hand-written FFT for the INMP441 microphone (the core has no I2S library or CMSIS-DSP), so the microcontroller itself listens for rain and passes on only a few numbers, never audio.
Best Use of Gemma: Gemma 3 1B runs on the board through llama.cpp, offline. It writes every wake note and splits avoided jobs into tiny steps. Code writes the facts, and a validator checks every number Gemma writes: 10 / 10 notes valid on the board (8 on the first try, 2 after one retry), 0 wrong numbers through.

Project Pulse: an offline vibration stethoscope that diagnoses and stops a failing machine

Abhinav krishna N — Sun, 18 Oct 2026 21:54:34 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle

A low-cost, offline machine-monitoring probe built around an Arduino, designed to bring predictive maintenance within reach of small businesses.

What I Built

Where I live in Kerala, many small businesses depend on machines to keep running. Think of the grinder in a batter-making business, the machinery in a flour mill, a water pump on a farm, or the machines in a small workshop.

When a machine starts to fail, the warning signs can go unnoticed until it breaks down. A repair technician might listen to the machine, feel its vibration and rely on experience to diagnose the problem. That experience matters, but what if they also had measurements to back it up?

Project Pulse is designed for both technicians who want to check machines periodically, like using a stethoscope during a routine inspection, and business owners who want to monitor multiple machines across their setup. Deploy multiple probes across a workshop, factory or farm, and each can learn the normal behaviour of its assigned motor and flag unusual changes. Instead of waiting for a breakdown, the goal is to spot warning signs earlier and make maintenance decisions with better information.

That's why I built Project Pulse: a stethoscope for small motors.

It's a handheld probe with a magnet at its tip. Attach it to a running machine, and it measures vibration while capturing sound. It estimates vibration severity, identifies possible fault patterns and explains what to investigate in language a shop owner can understand.

Everything runs on an Arduino UNO Q. No cloud, no account, no internet connection required.

It has two modes:

Check mode, for repair technicians. Take a reading, see the severity zone, review possible faults such as imbalance or looseness, and generate a report. The report can be downloaded as a PDF and shared with the customer.
Guard mode, for machine owners. Leave the probe on a motor. It first measures the motor while switched off, then learns that specific motor's normal running pattern in about three minutes. It watches for sustained changes and tracks an estimated heat/overload budget. An LED shows the state: blue for learning, green for healthy, amber for watch, red for stop, and off when the motor isn't running. A red stop state stays latched until a person clears it. At the end of the day, the device generates a short note.

Who would pay for it?

Independent repair technicians could carry one probe between customer sites, check motors during routine maintenance, identify unusual vibration patterns and provide customers with a report backed by actual measurements.
Small business owners could use Project Pulse to monitor the motors their operations depend on, helping them spot unusual behaviour before it leads to unexpected downtime.
Factories and workshops could deploy multiple probes across their equipment, monitoring individual motors as a fleet rather than relying entirely on manual inspections. Each probe learns the normal behaviour of its assigned motor and flags sustained abnormalities.
Agricultural and industrial operators could use the portable probe to inspect pumps, motors and other rotating machinery at regular intervals, even where internet connectivity is unreliable.

Industrial vibration-monitoring systems already exist, but many come with high hardware costs, cloud connectivity requirements and recurring subscription fees. These can make continuous monitoring difficult to justify for small businesses that only need to monitor a handful of machines. Project Pulse explores a more accessible alternative: an affordable, fully offline tool with no recurring AI or cloud costs. It can work as a handheld diagnostic stethoscope for periodic inspections or be deployed across multiple machines for continuous, individual monitoring. The goal is to make predictive maintenance accessible without the infrastructure and ongoing costs traditionally associated with industrial monitoring systems.

Demo

I didn't have access to an industrial machine for the demonstration, so I started with what I had at home: a fan. To test whether Project Pulse could detect unusual vibration, I taped a coin to one of the fan blades to introduce an imbalance and observed how the system responded.

It was a simple, controlled experiment using an everyday appliance, but it gave me a way to test the complete sensing and alerting loop with a real motor. The prototype detected the sustained induced imbalance during my test. It's an initial proof of concept, and testing across different motors and real-world fault conditions is the next step.

Here's the hardware before it went into the enclosure:

UNO Q, KX134, INMP441, RGB LED, three resistors, and the magnet that lets the probe snap onto a motor casing.

I don't own a 3D printer, so I made the enclosure from cardboard, cutting, folding and gluing it by hand. The magnet sits at the bottom, letting the probe attach to a motor casing. It's not a production-ready enclosure, but it contains the working electronics used for the prototype.

Red means stop. The heartbeat line was the only part of this build that didn't need debugging.

The probe's wiring, start to finish: KX134 over SPI, INMP441 over I2S, everything else just GPIO.

Check mode, live: severity zone, the raw numbers underneath it, and the button that turns them into a report.

The PDF a technician hands the customer. Every number in the paragraph above the table is checked against the table itself before it ships.

Code

Abhinavkrishna3211 / ProjectPulse

A magnetic stethoscope for small motors: snap it on, get a fault diagnosis in 30 seconds, or pair it with a plug that stops the motor. Offline on Arduino UNO Q with an open-weight model.

Project Pulse

A magnetic stethoscope for small motors, with an optional plug that can stop them.

Snap the probe onto a running machine and in about 30 seconds it tells you how hard the motor is shaking what the likely fault is (imbalance, looseness, overload, bearing wear) and what to check, in plain words Leave it mounted and pair it with the stop plug, and it guards that motor: it learns what normal looks like, warns when something drifts, and cuts power when it has to. Everything runs on an Arduino UNO Q; nothing goes to the cloud.

Two units

Probe: Arduino UNO Q, KX134 accelerometer, INMP441 microphone, RGB LED, magnet base.
Stop plug: XIAO ESP32-S3 and a relay. An ordinary socket until paired; once paired, it keeps power on only while the probe keeps saying so.

Two modes

Check: for repair technicians. Severity zone, likely fault and a short…

View on GitHub

How I Built It

Hardware

Arduino UNO Q (4 GB): combines an STM32U585 microcontroller with a Qualcomm QRB2210 Linux processor.
KX134 accelerometer: measures vibration over SPI.
INMP441 microphone: captures sound over I2S.
RGB status LED and button: provide a simple physical interface.
Magnet: attaches the probe to a motor casing.
XIAO ESP32-S3 + relay: planned as an optional stop plug; see the limitations below.

Sense: the microcontroller side

The STM32 samples the KX134 at about 1,600 Hz (measured: 1,623–1,627 Hz). Every second it runs a hand-written FFT and turns the raw samples into one small feature row:

vibration velocity (mm/s)
the motor's rotation frequency
the strength of the first three harmonics (1×, 2×, 3×)
band energies, kurtosis and crest factor

That row goes to the Linux side over the UNO Q's Bridge. It's about 60–70 characters, well under the Bridge's 256-byte message limit.

The INMP441 runs at the same time at 16 kHz (measured: 16,004–16,031 Hz). The UNO Q's Arduino core has no I2S library, so I drove the chip's SAI audio peripheral directly through its registers. That taught me two lessons:

My first build read every sample as 0 or 32767, because the clock-edge bit (CKSTR) was left at its reset value.
The KX134 delivered no samples at all until I set its data-ready enable bit (DRDYE). Its WHO_AM_I check passed perfectly the whole time, so the real bug was hiding one register away from where I was looking.

Decide: the Linux side, all open source

Fault rules (rules.py): the vibration velocity maps to the ISO 10816 severity zones that technicians use for small machines. Textbook signatures then name the likely fault:
- a dominant 1× peak means imbalance
- strong 2×/3× harmonics mean looseness or misalignment
- rotation slower than the rated speed means overload
- high-band energy plus high kurtosis means bearing wear
Learned normal (model.py, scikit-learn IsolationForest): in Guard mode it trains on the board from the motor's own healthy running rows. Both the anomaly flag and the rule faults are debounced: a condition has to hold for 5 consecutive rows before the light turns amber. The motor-off state reads from the same per-motor calibrated floor, not a fixed number. I tried a fixed "off" threshold first, and it broke the moment I tested it on a second, quieter fan. Every motor needs its own baseline; there's no shortcut around that.
Heat budget (heat.py): there's no temperature sensor yet. Instead, a slow budget fills with run time and overload and drains at rest. When it's full, the stop latches.
Gemma 3 1B via llama.cpp, running on the board, writes the Check report and the Guard daily note.

The rule I built Gemma around: the model never makes a decision. Pass/fail and stop/no-stop stay with the rules, the anomaly model and the heat budget. Gemma's only job is to turn a decision that's already been made into sentences a shop owner can read. A validator then checks every number in Gemma's text against the real measurements. If one doesn't match, it retries once, then falls back to a fixed template built from the real numbers. The report can be wrong in tone, never in its numbers.

Act

The RGB LED and the web page (live readings, Guard state, report and note, PDF download) show the result.
A red stop latches until a human clears it.

What I measured

Every number here is from a test I actually ran. The full details (date, setup and number of trials) are in docs/measurements.md in the repo.

Test	Result
KX134 sample rate (target 1,600 Hz)	1,623–1,627 Hz, no clipping, mic running concurrently
INMP441 sample rate (target 16 kHz)	16,004–16,031 Hz, proportional response 150 Hz–1 kHz, no clipping
Feature row over the Bridge	~60–70 bytes per second, no Bridge errors
Gemma 3 1B on the board	6.5 tok/s prompt, 4.5 tok/s generation (llama.cpp, 3 threads)
Gemma reports passing the number validator	8 / 8 once two bugs were fixed
Guard mode on a real motor (an old, slightly wobbly desk fan)	full calibrate, learn, guard cycle. A genuine 8-row imbalance run turned the light amber and held it steady; shorter blips didn't
Guard mode false-alarm soak (same fan, healthy)	zero false amber/red over a ~10 minute guarding window

Bugs that mattered:

My number validator read the dash in "10–800 Hz" as a minus sign and rejected every correct Gemma answer. There's a regression test for it now.
The llama-server was only listening on localhost, so the app's container couldn't reach it.
With a 3-row debounce, the fan's normal variation made the light flicker amber. Five rows fixed it without hiding the real fault.

Why Does Open Innovation Matter?

It has to work where there's no internet. A flour mill or a roadside repair stall isn't a data centre. An open-weight model on the board keeps working with the router unplugged.
It has to cost nothing to run. A technician isn't going to pay a monthly AI bill to check a machine. Open weights on a one-time board are what make a ₹-priced tool possible at all.
It has to learn one motor, not every motor. The anomaly model trains on the owner's own machine, on the device, in minutes. A general cloud API knows nothing about a 20-year-old grinder, and never will.
I needed to control the model, not just call it. With an open model I can pick the size that fits the board, keep it out of the decision path, and check its output before anyone sees it. A closed API hands me a black box behind a network call I can't guarantee.

My Agent Session

I used Claude Code as a coding agent for the App Lab side: the web page and the Python app logic. Everything it wrote was reviewed and tested by me on real hardware before it stayed.

Who This Is For

Who	Why it fits them
Independent repair technicians	Visit several small shops a day, currently diagnose by ear and experience alone
Small business owners (flour mills, juice carts, tea stalls, small workshops)	Own one or two motors their daily income depends on, can't afford unplanned downtime
Rental and tool-library operators	More on this below; one of the more interesting angles once the probe is cheap and small enough
Appliance and small-machine repair shops	Front-counter diagnostic to show a customer the actual reading instead of just a verbal opinion

Market and Business Potential

Small motors are everywhere in the informal and small-business economy: home appliances, small workshops, agricultural pumps, kitchen equipment, retail fans and mixers. This segment is usually the last to get any kind of predictive maintenance, because every existing vibration-monitoring product is priced, sized and documented for a factory floor, not a single shop owner with one machine.

Tier	Sold as	Why it works
Check mode	One-time tool purchase, technician	Pays for itself the first time it turns a guess into a confident, documented diagnosis
Guard mode	Bundle: probe + stop plug	The "insurance" tier for an owner protecting one critical motor
Rental	Day or week rate, tool library	No setup beyond a magnet, no network; fits alongside multimeters and clamp meters technicians already rent

Rental potential, in more detail: a technician who doesn't do enough vibration diagnosis to justify owning one can rent it for a day's rounds. A shop owner deciding whether a motor is worth repairing can rent it for a single Check-mode reading instead of buying outright. That's the group least able to justify buying specialist equipment, and renting gets it into their hands anyway.

Scalability:

Factor	Why it scales
Software cost	Fault rules, anomaly model and report generation run the same for one probe or a thousand; nothing leaves the device, so there's no cloud bill that grows with usage
Hardware cost	Commodity MCU/MPU board plus two off-the-shelf sensors, prices that drop with order volume, unlike a purpose-built industrial sensor
Per-unit setup	Guard mode's "normal" is learned on-device from the specific motor it's attached to, so the same firmware works on a desk fan, a flour mill or a water pump with no per-machine tuning from me
Upsell path	Check mode is the low-friction, one-time entry point; Guard mode plus the stop plug is the recurring-value tier once someone trusts the diagnosis

SWOT Analysis

Strengths	Weaknesses
Fully offline AI-assisted monitoring with no recurring cloud or AI inference fees	Field validation is at an early stage, with initial testing on two household fans; broader testing across different motor types and fault conditions is the next milestone
Learns each motor's individual baseline, making the approach adaptable to different machines instead of relying entirely on fixed thresholds	The optional relay-based stop plug is designed but still needs hardware validation; the current prototype demonstrates a latched warning state rather than a verified automatic power cut-off
Combines vibration analysis, anomaly detection and Gemma 3 1B on a single Arduino UNO Q platform	Direct temperature and current sensing are planned extensions; the current heat budget is an estimate based on runtime and overload conditions
Keeps critical decisions in transparent rules and anomaly detection, while validating every number generated by the language model	The current enclosure is a functional, low-cost prototype; a durable enclosure is needed before deployment in demanding industrial environments
Supports both handheld inspections and a scalable architecture with multiple independent monitoring probes	Long-term reliability and diagnostic performance under real industrial operating conditions remain to be established

Opportunities	Threats
A potential underserved market among small businesses, workshops, farms and factories that need monitoring without expensive industrial infrastructure	Established industrial monitoring companies could introduce lower-cost alternatives
Deploy multiple probes across a facility to monitor individual motors, enabling a gradual move from manual inspections to continuous condition monitoring	Incorrect fault indications could affect user trust, making transparent measurements, validation and field testing essential
A rental or tool-library model could make vibration diagnostics accessible to technicians who cannot justify buying specialist equipment	Dust, vibration, accidental drops and other harsh operating conditions could challenge hardware durability
Expand fault detection with additional sensors, more fault signatures and improved datasets without replacing the core architecture	Different motor types and operating conditions may require further calibration and validation
Generate understandable, potentially multilingual maintenance reports locally using the existing Gemma pipeline	Adoption will depend on demonstrating practical accuracy, reliability and value compared with existing alternatives
Build a cost-effective alternative for organisations that want to monitor multiple machines without paying recurring cloud inference fees	Safety-critical automatic shutdown requires rigorous hardware testing and safeguards before real-world deployment

Prize Categories

Best Use of Arduino

Runs models on the board: the fault rules, an IsolationForest trained on the device, and Gemma 3 1B through llama.cpp, all offline on the UNO Q.
A physical agent that senses and acts: it senses vibration (KX134) and sound (INMP441), and acts through a status LED and a latched stop a human has to clear.
Uses what makes the UNO Q different: the STM32 handles the real-time sampling, the FFT and the button/LED; Linux handles the learning, the language and the web page; the two talk over the Bridge.

Best Use of Gemma

Gemma 3 1B writes every report and daily note on the board.
It's kept out of the decision path on purpose, and every number it writes gets checked against the measurements before anyone sees it (8/8 passed).

Limits and what's next

The stop plug (XIAO ESP32-S3 + relay, paired over Wi-Fi with signed "OK to run" permits, fail-safe on any lost signal) is coded but not yet tested on real hardware. That's the next step, so right now the "stop" is the latched red state, not a verified mains cut-off.
Validated so far on two real motor (two desk fans(one new and one a old fan)). Induced-fault trials on more machines, bearing faults especially, are next.
No winding temperature or current sensing yet. The heat budget is an estimate from run time and load.
No 3D printer on hand, so the enclosure is a hand-built cardboard prototype. A printed or molded shell comes once i get access to a 3D printer.
Power: the prototype runs off USB for convenience while building it. A real deployment doesn't need to stay tied to a cable. A handheld Check-mode probe makes more sense on a rechargeable battery, while a Guard-mode unit left mounted on one motor could just as well stay on mains/USB power full-time. The electronics don't force this choice either way; the power source is picked per use case.
It's a diagnostic aid, not a certified instrument. The ISO zones are field indications.

Daybreak: a phone box that only opens after you've touched grass, offline on an Arduino UNO Q

Abhinav krishna N — Mon, 12 Oct 2026 06:45:06 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass

What I Built

I snooze, then I scroll. The phone is the last thing I see at night and the first thing I grab in the morning, and my alarm can't fix that, because the alarm lives on the device I'm trying to get away from.

Daybreak is a bedside box that keeps my phone overnight and only gives it back after I've carried the box outside, walked, and stood in daylight. "Touch grass" is literally the unlock condition. While I'm out there, the phone is still in the box, so those minutes are screen-free too.

The box has a voice: Jarvis, a dry-witted butler that runs fully offline on an Arduino UNO Q. Jarvis wakes me up, takes tomorrow's plan by voice the night before, reads me today's plan while I'm standing outside in the sunlight waiting for the box to unlock, and talks me through a short rest session when I can't sleep.

A day with Daybreak:

Evening: an hour before bedtime, Jarvis nudges me: "An hour to bedtime, sir. Shall we plan tomorrow?" I say "Hey Jarvis, tomorrow I have a lab at 9:30 and lunch with Amal at noon." Jarvis repeats back the checked plan and writes tomorrow's briefing overnight.
To-do list: "Hey Jarvis, add buy filament to my list." · "What's on my to-do list?" · "Mark buy filament done."
Bedtime: phone into its little bed, blanket shut. "Hey Jarvis, sleep time." → "Locked. Alarm at 6:30, sir. Sleep well."
Can't sleep: "Hey Jarvis, I can't sleep." → Jarvis offers a guided rest session (10 or 20 minutes, NSDR-style), a 5-minute wind-down or a 2-minute breathing reset, all in his calm voice and ending in silence. After bedtime he speaks quieter and slower, and skips the chime.
Morning: Jarvis wakes me. The blanket stays locked.
The gate: I carry the box outside. It checks that the steps are real walking (steady cadence, carried upright, so shaking it in bed doesn't count), then that I'm actually outside in real daylight.
While I wait in the sun: Jarvis reads me today's plan (the briefing, written the night before), and I can keep talking: "How long left?", "What's next?", "Add buy filament to my list."
Unlock: "Daylight confirmed. Releasing your phone, sir."

It's for anyone whose phone wins the first ten minutes of the day. That's me.

Everything inside: Arduino UNO Q, light and UV sensors, motion sensor, RTC, two N20 gear motors, mic, speaker.

The 3D-printed parts: a little bed for the phone, with a blanket that locks over it.(Edited from an Open source design of HTX Studios)

Demo

"Hey Jarvis" → chime → I speak → Whisper transcribes → Jarvis answers in his own voice, all on the board with Wi-Fi off.

Code

Abhinavkrishna3211 / Daybreak

A box that keeps your phone until you've been outside in real daylight, then tells you your day, and talks you down at night, all offline.

Daybreak

A bedside box that keeps your phone until you've stood in real daylight, then tells you your day. Fully offline on an Arduino UNO Q.

Night: put the phone in and say "Hey Jarvis, sleep time". The box locks and stays locked until morning (override button always works).
Morning: one alarm, snooze off by default. The lid stays shut until you carry the box outside, walk, and stand in daylight for long enough. A UV-to-visible ratio (plus optional mains-flicker detection) separates sunlight from lamps and phone torches.
Unlock: the lid releases and an offline voice reads your plan: what, when and where.
Evening: press talk and say tomorrow's plan. Speech to text → rules extract the times and places → a validator rejects anything that wasn't actually said. The plan is built by rules alone, never by the language model: on this board the model got the structure wrong…

View on GitHub

The repo is a proper App Lab app (importable as a zip) with a full build guide (TUTORIAL.md), every benchmark in docs/measurements.md, and the raw CSVs in data/bench/.

What I Used

Hardware

Part	What it does
Arduino UNO Q (4 GB)	Linux side (Qualcomm QRB2210): speech, Gemma, voice, dashboard. STM32U585 side: sensors, lock, alarm, safety
BH1750 ambient light sensor	Measures lux for the daylight check
GUVA-S12SD UV sensor	UV level, to tell real sunlight from lamps and phone torches
MPU6050 (GY-521)	Counts steps, checks walking cadence and that the box is carried upright
DS3231 RTC + coin cell	Keeps the alarm on time through power cuts, with no internet
2× N20 gear motors	Roll the 3D-printed blanket shutter over the phone
DRV8833 dual motor driver	Drives the two lock motors
Microswitch + reed switch	Phone in the bed / blanket shut
Active 5 V buzzer	Alarm, run by the MCU alone
2 push buttons	Override (always opens) and talk
USB microphone + USB speaker	Jarvis's ears and voice
Powered USB-C hub + 30 W+ USB-C charger	Power and audio through the UNO Q's single port
10,000 mAh power bank	Runs the box on the walk outside
3D-printed enclosure (PLA)	The phone's bed, blanket shutter and sensor window

Software and models (all open, all offline)

Tool	Role
Arduino App Lab + bricks (`keyword_spotting`, `web_ui`)	App structure, wake word, dashboard
Edge Impulse	Trained my own "Hey Jarvis" wake-word model
Whisper (whisper.cpp / pywhispercpp)	Speech to text
Gemma 3 1B QAT Q4_0 via llama.cpp `llama-server`	Morning briefing and open questions
Piper TTS	Jarvis's voice
Python + pytest	Planner, gate, assistant logic and 200+ tests
Arduino (STM32 sketch)	Sensors, motors, alarm, watchdog
KiCad	Schematic

Schematic

KiCad schematic: UNO Q with the I²C sensors (BH1750, DS3231, MPU6050), GUVA-S12SD UV, DRV8833 driving the two N20 motors, buzzer, buttons, and the phone and lid switches.

How I Built It

The UNO Q fits this project because it's two computers in one. The STM32 handles everything that must never fail (sensors, the blanket lock, alarm, safety timers). Linux on the Qualcomm QRB2210 handles everything smart.

Layer	Open tech	Runs on
Wake word	My own Edge Impulse "Hey Jarvis" model, App Lab `keyword_spotting` brick	Linux
Speech to text	Whisper (whisper.cpp via pywhispercpp), `base.en`, `audio_ctx=512`	Linux
Language	Gemma 3 1B QAT Q4_0 via a supervised `llama-server`	Linux
Voice	Piper, British male voice	Linux
Dashboard	App Lab `web_ui` brick, port 7000	Linux
Sensing and safety	BH1750 light, GUVA-S12SD UV, MPU6050 motion, DS3231 clock, phone/lid switches, buzzer	STM32
The lock	2× N20 gear motors on a DRV8833 driver, rolling the 3D-printed blanket shutter over the phone	STM32

The most useful thing I measured: where Gemma does not belong

My first design had Gemma turn "tomorrow I have a lab at 9:30 and lunch with Amal at noon" into a structured plan. Before trusting it, I benchmarked every Gemma variant that fits the 4 GB board on 20 hand-labelled transcripts.

Best Gemma score: 5/20. The fastest model that could hold a JSON schema missed my latency limit by 5× (p90 108 s against a 20 s limit).
Plain Python rules: 20/20, in under a millisecond.

So the measurement changed the architecture. Python owns the facts (times, places, your alarm). Gemma owns the words: it writes the morning briefing and answers open questions, and every draft goes through a deterministic check (every plan time present, no invented times or places, ≤ 45 words) before Jarvis says it.

Briefing setup (full load: wake word + Whisper + Piper + LLM all running)	Score
Stock Gemma 3 1B Q4_0	8/10
+ QAT weights	9/10
+ check and retry (≤ 3 drafts)	10/10, 1.2 attempts on average

A full-load briefing takes about 39 s (median), which is far too slow for the morning. So it's written at night, when the plan is saved, and the morning only waits on Piper. Open questions (ask) score 10/10 at a p90 of 11.3 s.

Other numbers from the board:

Gemma 270m vs 1B: 270m is 3× faster (60 prompt / 18 generation tok/s) but scores 1–4/10 on the briefing. It can't hold the voice and the constraint at once.
Threads: prompt speed scales linearly up to 4 cores (15.8 → 61.2 tok/s), but 4 threads under full load reset the board twice, so it ships with 3.
Wake word: threshold 0.75 gives 0.90–1.00 recall at 1–3 m (even with a fan running) and one false wake in ten minutes of continuous speech.
Whisper: tiny.en is 1.6 s per command; base.en costs +1.9 s and is noticeably more accurate on times, so it won.

Bugs I only found by running it on the real board

Every spoken reply was silently failing: the Piper voice path pointed at a host folder that App Lab doesn't mount into the app container.
The night lock reused the morning's flat 90-minute limit, so it would have released my phone at 11:30 pm. No test caught it, so I wrote dispatcher tests for main.py.
A missing light sensor reads as 0xFFFFFFFF = 4.29 billion lux, brighter than the sun, which would have opened the gate indoors. The gate now rejects anything above 200,000 lux.

Safety (it holds your phone all night)

The blanket opens if the power goes. The N20 gearing is backdrivable and the motors are only driven for a moment to move the shutter, so an unpowered box never traps the phone.
Override button on the MCU opens it instantly, any time. Emergency calls are one press away.
Hard-release timer (alarm + 90 min) and a watchdog (Linux silent for 30 s → open).
The alarm runs on the STM32 off a DS3231 RTC, so it still rings if the AI side crashes.

The science behind it (and where Andrew Huberman comes in)

The idea for Daybreak came from Andrew Huberman's Toolkit for Sleep. He pulls a set of findings into one practical routine: get outside into daylight soon after waking, keep a fixed wake time, and keep bright light (screens) away at night. I kept failing at the first step, because my phone always won. So I built a box that makes the routine the default.

Why morning sunlight, and why the cortisol timing matters. Your body clock is set mainly by light hitting your eyes. Cortisol is meant to be high in the morning, when it peaks shortly after waking to get you alert and moving, and low at night, so melatonin can rise and you can fall asleep. Bright morning light lines that rhythm up with the actual day. Bright light late at night pushes it the wrong way. Daybreak attacks both ends: daylight in the morning, the phone in bed at night.

The studies behind each feature:

Feature	What the research says	Source
Daylight gate	Bright light in the morning produces an acute rise in cortisol, part of how light signals "daytime" to the body	Jung CM et al., J Biol Rhythms 2010
Daylight gate	A week of camping with only natural light shifted people's internal clocks about 2 hours earlier, lining sleep up with sunrise	Wright KP Jr et al., Curr Biol 2013 (n=8); Stothard ER et al., Curr Biol 2017
Daylight gate	People with brighter days and darker nights had lower mortality risk and fewer psychiatric disorders (wrist light sensors, ~86–88k people)	Windred DP et al., PNAS Nexus 2024; Burns AC et al., Nature Mental Health 2023
Phone in bed at night	Reading on a light-emitting screen before bed suppressed melatonin, delayed its onset and pushed the body clock later, compared with a printed book, in the same people	Chang AM et al., PNAS 2015
One fixed wake time	Sleep regularity predicted mortality risk better than sleep duration (~61,000 people)	Windred DP et al., Sleep 2024
Planning tomorrow before bed	Writing tomorrow's to-do list helped people fall asleep faster (n=57)	Scullin MK et al., J Exp Psychol Gen 2018
Plan says when and where	"When-then" plans make people far more likely to follow through (meta-analysis of 94 studies, d = 0.65)	Gollwitzer & Sheeran, 2006
2-minute breathing reset	5 minutes a day of cyclic sighing gave the biggest mood gain of the breathing patterns tested (RCT, 111 adults)	Balban MY et al., Cell Reports Medicine 2023
Rest sessions (NSDR-style)	Yoga nidra lowered salivary cortisol and improved sleep in chronic insomnia (RCT); an 11-minute session lowered stress and improved sleep quality in 341 people	Datta K et al., Natl Med J India 2021; Moszeik EN et al., Psychol Res 2022
No snooze (configurable)	The evidence on snoozing is mixed, so no-snooze is my choice, not a rule	Sundelin T et al., J Sleep Res 2023

How Huberman's numbers map to the gate. His toolkit suggests going outside within 30–60 minutes of waking for about 10 minutes on a clear day, 20 when cloudy, and 30–60 when very overcast. Daybreak uses these as adjustable defaults: the brighter the light it measures, the shorter you need to stay out. "NSDR" (non-sleep deep rest) is also his term. Jarvis's sessions are my own original scripts in that style, not his recordings or words.

I treat this research as the reason for the design, not proof that the box works. Several of these studies are observational or small. Daybreak is not affiliated with or endorsed by Andrew Huberman or Huberman Lab, isn't a medical device, and the rest sessions are relaxation audio, not treatment.

Why Does Open Innovation Matter?

This device sits in my bedroom, listens for its name, and knows when I sleep and wake. A cloud version would mean always-on bedroom audio leaving the house. Open models make the private version possible:

Nothing leaves the box. No cloud, no camera, no accounts. Audio is transcribed, then deleted.
It works at 6 AM with the router off. An alarm that needs the internet isn't an alarm.
It costs nothing to run. No API keys, no subscription.
I could measure it and change it. Because the weights run locally, I could benchmark every Gemma variant, quantisation and thread count on my own board, find out it shouldn't extract plans, and redesign around that. With a closed API I'd just have shipped the 5/20 version.
Anyone can rebuild it from the repo, retrain the wake word, or swap the voice.

Prize Categories

Best Use of Arduino: a physical agent on the UNO Q that senses and acts, with open models running on the board.

Senses (STM32): visible light + UV ratio, walking steps and rhythm (IMU), phone in the bay, lid closed, real-time clock
Acts (STM32): lid shutter motors, blanket, alarm buzzer, plus override, 30 s watchdog and hard-release timer that work without Linux
Thinks (Linux on the QRB2210): Edge Impulse "Hey Jarvis" wake word, Whisper, Gemma 3 1B QAT and Piper, all on the board, all offline

Best Use of Gemma: Gemma 3 1B QAT doing checked, real work on a 4 GB board, with every variant benchmarked and the results (including where it failed) published.

The daylight durations are adjustable defaults inspired by Andrew Huberman's published guideline; not affiliated with or endorsed by him. Daybreak isn't a medical device and makes no health claims.

Project JARVIS: The Offline AI Lab Assistant

Abhinav krishna N — Mon, 05 Oct 2026 06:56:17 +0000

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend

What I Built

Ask a new student in a college lab where the vernier is, and most will say nothing. They'll wander, give up, and not come back.

The IoT club lab at my college is an open space where anyone can walk in and learn about hardware. Nobody is taught from a podium. Students learn from each other, share what they know, and get their hands on real components, and there are a lot of them. The club also hosts workshops. When I was there I hosted workshops too, and I mentored students and taught them.

Now my junior, John, coordinates the lab. With so many tools and components, and so many people passing through, finding the right one and keeping track of what has been borrowed is a job in itself. John loves automation and cool tech, and he is a big Iron Man fan, so I thought: why not give him his own JARVIS for his lab? That's what I built: an offline AI assistant you talk to, which points a laser at the tool you need, lights up component boxes, and keeps the lending log.

It runs entirely on an Arduino UNO Q with 2 GB of RAM: no internet, no cloud account, no API key.

Ask out loud, and the dot lands on the hook.

New students are often too shy to ask where things are. With JARVIS they just ask the wall. It takes the friction out of a first visit, and it makes the lab a bit more fun, so people get curious and start poking around.

How you use it. You say the wake command, "Hey Jarvis", and the assistant comes alive. It answers "Yes, sir?" and waits for you to say what you need. Then you just ask in plain words, and it replies out loud, points, or lights up whatever you asked for. Say "No, thank you" and it goes quiet again until the next "Hey Jarvis".

Here is what it does today. These are examples of what it can do:

"Where's the vernier?" It answers "The vernier caliper is on hook 2, sir. I've highlighted it for you." A servo tilts a small laser pointer onto that hook. The laser lights with the first word of the reply and switches off when the reply ends. Code on both processors also cuts it after 10 seconds regardless.
"I want to measure the size of this groove." It works out the tool for the job (the vernier) and points at it. If you just say "I have a job, which tool should I use?", it asks "What's the job?" first.
"Lend two ESP32s to Arjun till Friday." It reads the loan back and saves it only after a spoken "yes" or a tap on the dashboard.
"What's overdue?" / "Who has the soldering iron?" It answers from the loan log.
After each answer it asks "Anything else?", and "No, thank you" ends the conversation.

It talks just like JARVIS in the Iron Man movies, with lines inspired by the films themselves, made for my Iron Man fan John.

Demo

JARVIS running on the UNO Q in the lab: wake word, a spoken request, and the reply, all offline.

Code

Abhinavkrishna3211 / jarvis-lab-assistant

Offline voice assistant on an Arduino UNO Q that finds tools, lights component boxes and keeps the lending log for a lab. Gemma 3 1B, whisper.cpp and Piper, all on-device

JARVIS: an offline lab assistant on the Arduino UNO Q

A voice assistant for an open IoT-club lab. Ask it where a tool is and a laser marks the hook; ask for a component and the LED under its box lights; lend and return hardware by voice and it keeps the log Everything runs on the board: no internet, no cloud account.

How it works

mic -> "Hey Jarvis" (App Lab keyword spotting, always listening) -> "Good evening, sir."
    -> record until you pause (6 s max) -> whisper.cpp tiny.en -> fuzzy candidate match (about 10 items)
    -> keyword rules; if they give up on a known item, Gemma 3 1B (App Lab llama.cpp runner,
       JSON-schema constrained) -> validator -> SQLite
    -> Piper reply and Bridge calls to the STM32: point / laser / box_led / ring_state

The model never touches facts it could invent. It returns one short JSON…

View on GitHub

What I Used

Hardware

Arduino UNO Q, 2 GB version
Servo, 180 degrees (an SG90), to tilt the laser
Laser module salvaged from an old keychain pointer, switched through a logic-level MOSFET (IRLZ44N) with a series resistor
Arducam B0490 camera (2 MP, IMX462 sensor, day and IR night vision, USB), watching the tool wall. Its built-in microphone is the microphone JARVIS listens through
Bluetooth speaker, for JARVIS's voice
USB-C hub, to connect the camera and other USB devices to the board
A separate 5 V supply for the servo, sharing ground with the board
Status ring and LEDs for the component boxes

Software and models

Arduino App Lab (Bridge between the Linux side and the STM32)
Gemma 3 1B through llama.cpp
whisper.cpp tiny.en
Piper
A "Hey Jarvis" wake-word model trained in Edge Impulse
A FOMO object-detection model trained in Edge Impulse (public project), which finds the tools on the wall
SQLite

How I Built It

mic -> "Hey Jarvis" (my Edge Impulse keyword model) -> cached greeting
    -> record until you pause -> whisper.cpp tiny.en
    -> keyword rules; only if they give up on a known item: Gemma 3 1B -> one JSON action
    -> validate() -> SQLite / servo + laser / box LED -> Piper voice, sentence by sentence

Open models, all running locally on the board:

Gemma 3 1B (open weights), served by App Lab's llama.cpp runner.
whisper.cpp tiny.en for speech to text.
Piper for the voice.
A "Hey Jarvis" wake-word model I trained in Edge Impulse (MFE plus a small classifier, classes JARVIS and NOISE, about 10 ms per window). It runs inside App Lab's keyword-spotting brick, swapped in with one variable in app.yaml. The wake word alone never goes to a model: "Hey Jarvis" by itself gets "Yes, sir?" straight from code.

On its validation set the wake-word model reaches 100% accuracy with a loss of 0.08. That set is small and has only the JARVIS and NOISE classes, so I don't read it as proof the model never wakes by mistake. Testing it with more voices is the first item under Still To Do

A FOMO object-detection model, also trained in Edge Impulse, which finds each tool on the wall in the camera image so the laser can follow it (see The camera below).

On the validation set the model scores an F1 of 96.6%. The multimeter and the wire stripper were found every time, and the vernier 80% of the time; the misses were counted as background. Inference takes 22 ms, with 305.5K of peak RAM and 81.3K of flash. The validation set is small, so a single missed vernier moves that score a lot. I treat these numbers as a first check, not as an accuracy claim.

JARVIS is a physical agent. It hears a request, decides what to do, and acts in the room: a servo swings the laser onto the right hook.

The UNO Q's two processors split the work:

Linux side (Qualcomm MPU): the wake word, whisper.cpp, the keyword rules and Gemma, the validator, SQLite and Piper.
STM32 side (microcontroller): the servo, the laser, the status ring and the box LEDs, called from Python over App Lab's Bridge in about 7 ms per call.

Wiring

The main wiring schematic, drawn in KiCad.

The pointer

It's built from scrap. The laser module and the servo came from old electronic parts I had at home, not bought.

What I planned, and what I built. I designed a pan-tilt head: two servos, one to swing the laser sideways and one to tilt it, inside a 3D-printed enclosure. I wrote the wiring and the code for both axes. But I had only one servo and no 3D printer. So the prototype in the demo is a simpler version: one SG90 servo on a cardboard mount, glued together, that moves the laser up and down. The hooks hang in a single column, so one axis is enough to point at the tool, and the camera tells JARVIS where along that column the tool is.

The old keychain pointer, from a drawer at home.

Opened up: the board and contacts I reused. The cells and case stayed behind.

The laser is the module from a keychain pointer with its cells removed. I never measured its output power, so I treat it as an unrated pointer and keep it away from people. It's switched from pin D3 through a logic-level MOSFET (IRLZ44N) and fed from 5 V through a series resistor that limits the current. The servo runs from a separate 5 V supply that shares ground with the board, and the sketch detaches it after each move so it doesn't jitter.

I started with fixed hook angles (50°, 65° and 79° for the three tools on the wall), found by jogging the servo until the dot sat on the hook. I used them for the first validation, to check that the laser pointed at the right place. Later I trained a FOMO object-detection model in Edge Impulse, and now the laser follows the tool wherever it is placed.

The camera

A camera watches the tool wall. I trained a FOMO object-detection model of the wall in Edge Impulse (public project). It finds each tool in the camera image, JARVIS turns that position into a servo angle, and the laser points at the tool wherever it hangs. If someone puts the vernier on the wrong hook, the laser follows the tool and JARVIS says "Someone has moved the vernier caliper, sir."

Safety

The laser's limits live on the microcontroller as well as in Python. The sketch caps every laser-on at 10 seconds and switches it off by itself, even if Linux crashes mid-reply. The module is current-limited, and I keep it aimed at the wall, never at people.

The model never gets the last word

It returns one small JSON action. Code checks that the item exists, the quantity is in stock, the borrower is a name and the date is real, and code does all the date and stock arithmetic. Nothing the model says reaches the database or the laser without that check.

What I Measured

All numbers come from the board; full tables are in docs/measurements.md. The 60-command evaluation uses typed commands. The speed numbers come from spoken requests through the mic.

A 1B model lost to keyword rules. On 60 typed test commands, Gemma 3 1B got 22 right and simple keyword rules got 40. Gemma handled loose wording better, but it labelled almost every loan and return as a search. It also invented answers to small talk: "what's the weather" came back as "the multimeter". On top of that, it takes 28-56 s per request on this board.

So JARVIS uses both. The rules answer first, in under a second. Gemma is asked only when the rules give up and the request mentions a known item, and JARVIS says "One moment, sir" before it starts. In a second run on the board, that hybrid scored 45/60, against 41/60 for the rules alone in the same run (the rules scored 40 in the first run; the one-command difference is run-to-run variation). Gemma was called on 18 of the 60 commands, and the net gain was 4 commands the rules missed. When it was wrong, it almost always answered with a search, never a loan or a return, so a mistake costs a wrong pointer, not a wrong record.

Since then I've added rules for asking about a tool by its job, and the rules alone now score 51/60. One caveat: I wrote the rules while looking at the same 60 commands, so these numbers are optimistic.

Speed. In the first version the reply took a while to start. Three changes cut that down:

Change	Before	After
Greetings cached at start-up	2.2-3.6 s from wake to first word	about 0 s of synthesis
Replies spoken sentence by sentence (next one synthesised while this one plays)	2.4-5.5 s before the first word	1.2-2.3 s
A short filler ("Right, sir.") once whisper has heard words	silence	something to hear while it thinks

whisper.cpp takes about 1.7 s for a short request. The Bridge call is about 7 ms.

What Went Wrong (and Stays In)

Whisper heard "wire stripper" as "wise triple". The rules gave up, and Gemma recovered the right tool. That one example is the reason for the hybrid design.
Whisper also transcribed the wake word: "Hey Aradino" matched the Arduino Uno and lit its box. The wake word is now stripped before parsing.
A desk fan pushed the mic to full scale for whole recordings. Whisper heard nothing, and JARVIS kept saying "Could you repeat that?" until I found the fan.
The laser pointed at the floor for a tool whose hook only existed in placeholder data. Now a tool without a measured hook angle gets a spoken answer and no laser.
I tried to calibrate the laser by having the camera find the red dot. It never saw the dot on the white foam board. In the end I jogged the servo a few degrees at a time while watching the dot, and wrote the three hook angles down by hand.
At full volume the Bluetooth speaker distorted. 85% volume and a slower, calmer voice fixed that.
The Bluetooth speaker paired without bonding and forgot the board on every reboot. It needed pairable on before pairing.
JARVIS could wake itself: its own voice came back through the mic. Wake words are now ignored while it speaks and for 1.5 s after (Bluetooth audio lags about a second).

Still To Do

Retrain "Hey Jarvis" with more voices and an "other speech" class. It only knows JARVIS and NOISE today, so other words can wake it.
Wire the LED strip under the component boxes and test it on the board.
Measure the laser's pointing error.
Load the lab's full inventory: three tools hang on the wall today.
Record spoken commands from other club members and report accuracy on those. -Build the two-servo pan-tilt head. It needs a second servo and a 3D-printed enclosure.

Why Does Open Innovation Matter?

A college open lab can't run on an API key. Someone has to pay for it, it needs Wi-Fi that works, and it stops the day the free tier ends. Open-weight models and open runtimes let the whole assistant live on a board we own, work with the router unplugged, and cost nothing per question.

Because everything is open, I could also measure each piece honestly. When the 1B model lost to plain keyword rules, I could see it, and change the design to use it only where it actually helps.

My Agent Session

I built JARVIS with Claude as my coding agent. It wrote most of the Python and the sketch. I did the hardware, the wiring, the Edge Impulse wake-word training, the Edge Impulse Vision model, the testing in the lab and the design decisions. The rules it worked under are in AGENTS.md in the repo: the model only returns one JSON action, loans need a spoken "yes", the laser always times out, and nothing goes to the cloud. Every number in this post was measured on the board, not estimated.

Prize Categories

Best Use of Arduino: JARVIS runs entirely on the Arduino UNO Q: wake word, FOMO model, speech to text, Gemma and the voice on the Linux side, and the servo, laser and LEDs on the STM32 over the Bridge. It senses (it listens), decides, and acts physically (the laser marks the hook), with the laser's safety limits enforced on the microcontroller.
Best Use of Gemma: Gemma 3 1B runs locally on the board through App Lab's llama.cpp runner. It's constrained to emit one JSON action, and code does the stock, dates and validation. I measured it honestly against keyword rules on the same 60 commands and used it where it actually helps.