My Melody MotionBox

the problem

Kids zone out the moment STEM stops being physical. We needed an instrument that taught sound and motion through play, not slides.

Who it's for

Kids aged 6–10 learning STEM concepts at home or in a classroom. The blocker we kept hearing from parents and teachers wasn't curiosity — kids have plenty of that — it was the gap between abstract physics (sound waves, frequency, motion) and anything they could touch. So we built an instrument: pick it up, tilt it, hear what changes. The lesson is inside the toy.

Product bets

Three calls shaped the build: 1. Sound first, screens never. A screen would have pulled attention away from the body. UART output goes to a debug console for parents/teachers, not the kid. 2. Two channels, not one. A single speaker collapses X and Y motion into a muddy tone. Routing X and Y to separate channels (stereo) gives each axis its own voice, so kids physically hear that motion has dimensions. 3. Continuous mapping, not buttons. Frequency scales with angular velocity instead of triggering preset notes. Slow tilt = low hum, fast shake = high pitch. The cause-and-effect is unmistakable in the first 5 seconds.

How it works

An LSM6DSL 6-axis IMU (over I2C) samples gyroscope data at ~1 kHz. A ReadSensorTask thread updates a shared state struct with the latest X/Y angular velocity. Two generator threads — one per axis — gate on motion magnitude (|ω| > 10000 dps raw), then synthesize a sine wave whose period is modulated by the angular speed: samples_per_cycle = base / (1 + (|ω| − 10000) / 15000) The sine table is built with CMSIS-DSP's `arm_sin_f32` (single-cycle fixed-point on Cortex-M4), scaled to the 12-bit DAC range, and streamed out via DMA so the CPU stays free to read the next sample. X and Y are routed to DAC_CHANNEL_1 and DAC_CHANNEL_2 — different speakers, different ears. A fourth PrintTask thread emits UART debug messages so adults can verify the device is working.

Engineering decisions worth calling out

• Threading model: 4 cooperative RTOS threads sharing state through a single sensor struct. Cheaper than a message queue at this scale, and the read-mostly access pattern means we don't need locks if the producer is single-writer. • DMA-driven audio: Blocking the CPU on each sample would have starved the gyro read loop. DMA frees the M4 to keep sampling motion while audio plays out. • Dynamic sample buffers: Sample count varies with frequency, so we malloc/free per cycle. Not ideal for production (fragmentation risk on long sessions) — a fixed-size ring buffer is item #1 on the rewrite list. • Threshold gating: The ±10000 dps deadband stops the toy from droning when it sits on a table. Tuned empirically with a 7-year-old test subject.

What I'd ship next

If this became a real product, the v2 backlog I'd push for: 1. Velocity-to-timbre, not just pitch. Add harmonics so fast shakes sound 'brighter,' not just higher. 2. Onboard LED ring. The visual feedback currently lives in a UART console no kid will ever see — move it onto the device with an addressable LED strip. 3. Accelerometer fusion. Gyroscope alone misses translation (kid swinging it through the air). Fusing accel + gyro unlocks gesture vocabularies like 'cast' and 'swipe.' 4. Curriculum sleeve. The instrument is the hook; the real product is the 4-page activity guide that turns it into a 30-minute lesson on waves.

key decisions

outcomes

• Working prototype demoed end-of-semester to faculty and TAs
• Two-axis stereo audio with sub-perceptual (<20 ms) gesture-to-sound latency
• 4 RTOS threads coordinating sensor read, X/Y synthesis, and debug output without lock contention
• Top-grade group project (ECSE 444, McGill)