Dart Counter, IMU-Based Hit Detection System

1. Context

This system was built to explore how tiny embedded devices can detect physical interactions, in this case a dart hitting a dartboard, and trigger further system actions.

The origin was simple: tracking dart scores during practice sessions meant manually typing numbers into a website. Not difficult, but ripe for automation. A microphone-based listening system seemed like the obvious solution, except for one real-world constraint: music playing in the background destroys audio model reliability.

So the challenge became: how do you build an automated dart scoring system that works in noisy environments?

The answer: treat the physical impact as a wake word. Detect the hit with an IMU, then trigger downstream systems (voice transcription, camera scoring) only when a dart actually strikes the board.

A small system, but a powerful concept:
physical events to embedded detection to workflow automation.

2. The Problem

Dartboard hits produce extremely short, variable signals:

• Very fast vibration burst (sub-second)
• Highly variable depending on region of board (bullseye vs edge)
• Noise from footsteps, wall vibrations, board movement
• Music and ambient sound make pure audio detection unreliable

Typical vision-based detectors are overkill or require expensive camera setups.
IMU detection is simple, but only if you build the right signal system around it.

Key problems:

• Distinguishing true hits from incidental noise
• Running inference on-device with minimal latency
• Handling physics variability (soft throws, different dart weights)
• Providing immediate UX feedback
• Creating a reliable “event bus” for downstream systems

3. Constraints

• Low compute on Arduino
• Need near-zero latency for real-time detection
• IMU noise + real-world vibration variability
• Must run offline and instantly
• Frontend should show hits in real-time
• Detection must be robust across throw force, dart type, and board position

4. The System I Designed

An IMU-powered event detector that turns physical impacts into system triggers.

Timeline
Built in early December 2025, immediately following the Edge Impulse Hackathon (October 30 to November 30, 2025). The hackathon provided fresh hands-on experience with Edge Impulse’s platform, which was then applied to this dart detection challenge.

Components

• Arduino Nano 33 BLE Sense (IMU sensor)
• Edge Impulse for model training and deployment
• Edge classifier (TFLite) for onboard inference
• Event smoothing logic to reduce false positives
• Serial/USB communication to send events to frontend
• Simple frontend UI (vanilla HTML/JS) to show counter + flash animation

How It Works

1. The IMU streams 3-axis accelerometer data continuously (gyroscope data excluded after testing showed accelerometer alone was sufficient)
2. Data is processed through Edge Impulse’s spectral analysis (FFT) block, reducing 90 raw features (30 samples × 3 axes over 300ms) down to 63 frequency-domain features
3. Features pass directly to a logistic regression output layer (no hidden MLP layers), making inference nearly instantaneous
4. Inference runs every 50ms (sliding window) to ensure detection during the impact event
5. Hits are classified with a threshold of ~0.25, providing excellent accuracy without false positives
6. Cooldown logic (1000ms) groups detection bursts into single events to prevent double-counting
7. Frontend timeout (tunable) handles missed detections: if a hit is detected but no subsequent hits arrive within the timeout period, the system assumes all darts have been thrown and proceeds to the next stage
8. Event is sent over Serial/USB to the frontend via Web Serial API
9. UI increments counter and flashes green on each detected hit

The IMU effectively becomes a physical wake word. By the time you walk to the board to retrieve your darts, the system is ready for score input.

Evolution of the System

The final architecture emerged through systematic iteration:

Initial approach:

• 1000ms inference window (Edge Impulse default)
• 6 raw sensor inputs (3× accelerometer + 3× gyroscope)
• Multi-layer perceptron (MLP) with hidden layers
• Result: worked but inference was too slow for 300ms windows

Insights from testing:

• Dart impacts complete in under 300ms
• Accelerometer data alone captures the impact signature
• Gyroscope data added no value and increased compute
• Sensor position variability made raw values problematic
• Wider windows require more training data for regularisation

Optimised design:

• 300ms inference window
• 3 accelerometer inputs only
• FFT preprocessing for dimensional reduction
• Direct output layer (logistic regression)
• 50ms sliding window for continuous detection
• Result: near-instantaneous inference, robust detection

What Would Change in v2

Instead of FFT preprocessing, simply calculating root mean squared (RMS) energy across the three accelerometer axes would likely achieve similar or better results with even less computational overhead.

5. Before vs After

Before	After
Manual score entry while training	Real-time automated hit detection
Audio detection unreliable with music	Works regardless of ambient sound
No way to trigger downstream systems	Each hit becomes a programmable event
Expensive vision systems required	Low-cost, edge-first solution

6. Stack & Architecture

• Arduino Nano 33 BLE Sense for sensors and inference
• Edge Impulse for spectral analysis, model training and deployment
• TensorFlow Lite for on-device classification
• Cooldown + timeout logic to handle detection reliability
• Serial/USB communication for device-to-frontend data transfer
• Vanilla HTML/JS frontend (Web Serial API) for visualisation

Architecture highlights:

• Fully offline detection
• Edge-first, ultra-low-latency (~50ms refresh rate)
• Modular: frontends and backends can evolve independently
• Handles physics variability (bullseye impacts vs edge impacts) through timeout fallback

7. Impact

• Reliable detection of dart hits with ~0.25 confidence threshold
• Real-time event streaming with no false positives in testing
• Graceful handling of missed detections (soft throws, bullseyes) via timeout logic
• Demonstrated viability of “wake word” pattern for physical events
• Foundation for full smart dartboard system:
  • Voice-to-score (“60”, “Triple 20”, etc)
  • Camera-based scoring
  • Stats/timing analysis
  • Player profiles and match history

8. What I’d Build Next (v2)

• Replace FFT with RMS energy calculation for even faster inference
• Add voice listener post-hit detection for score input (already implemented with Whisper Tiny)
• Integrate stereo camera for automated scoring verification
• Build complete scoring engine (501, cricket, around-the-world)
• Add player profiles and local match history
• Explore multi-class model for board region detection (ambitious but possible)