Embedded | Antoine Weill--Duflos

Pocket Rolling Stone

Sat, 30 May 2026 00:00:00 +0000

The Pocket Rolling Stone is a small handheld device that lets you feel a virtual ball rolling and sliding inside a tube that does not physically exist. You tilt it, and a synthesized marble runs from one end to the other, hits the wall, and rolls back. Nothing moves inside. The sensation is generated entirely in firmware on an ESP32-C6, from tilt sensed by a BNO085 IMU.

It is a reproduction of a haptic illusion described by Hsin-Yun Yao and Vincent Hayward in An Experiment on Length Perception with a Virtual Rolling Stone (Eurohaptics 2006), where people could estimate the length of a virtual tube purely from the rolling sensation, apparently using an internal model of gravity. The project was sparked at the workshop held in memoriam of Vincent Hayward, where it became clear that essentially one working set of the original demo was left, worth rebuilding on modern, minimal hardware. It sits in the same family as the lab’s 3D printed haptic illusions and the broader question of why touch has no museum of illusions.

A 1 kHz physics loop simulates three modes (rolling like a solid sphere, sliding with Coulomb friction, and a 3D box of three marbles of different mass), and the ball’s motion is rendered as a real-time vibration. The same signed haptic signal drives two completely different output stages, selected by a single build flag:

I2S audio path: an Adafruit ESP32-C6 Feather plus a MAX98357A amplifier driving a TITAN Haptics actuator, streaming a position-indexed wavetable at 22050 Hz.
H-bridge path: a Microbots CodeCell C6 Drive board (onboard IMU and H-bridge) driving a motor directly through PWM, with no amplifier at all. This is the build that was actually assembled into a small handheld unit; the I2S path was validated on the bench.

A Python companion app connects over USB serial or BLE to visualize and tune the simulation live.

A direction I want to explore next: rendering a localizable impact along the tube, so you feel where the virtual ball strikes, drawing on Miller et al., Sensing with tools extends somatosensory processing beyond the body, Nature 2018.

This is an ongoing personal side project, not a product. The full story is documented in two build posts:

The firmware and companion app are open source at github.com/Leicas/esp32-ball.

A Pocket Rolling Stone, Part 1: A 2006 Haptic Illusion, an ESP32-C6, and an I2S Amp

Sat, 30 May 2026 00:00:00 +0000

The part that makes this build feel real: TITAN Haptics actuators. This first build renders the virtual ball as audio and drives one of these. More on them, and on my friend Ashley Huffman who got them to me, further down.

This one has been with me for several years, not a weekend. The idea is simple to state and surprisingly hard to stop tuning: build a small handheld object that lets you feel a ball rolling and sliding inside a tube that does not physically exist. You tilt the device, and a virtual marble runs from one end to the other, bumps the wall, rolls back. There is no moving mass inside. The whole sensation is synthesized.

It started at the workshop held in memoriam of Vincent Hayward, one of the two authors of the paper this is based on. Sitting there, it struck me that of this lovely demonstration there was, as far as I could tell, essentially one working set left in the world. That bothered me. I was fairly sure I knew a good actuator that could also produce a crisp impact, and that very minimal hardware would be enough to bring the illusion back to life. The piece I was missing, for years, was time: between a day job and parent duty, the build kept not happening. What finally unlocked it was using Claude Code to move fast in the small windows I do have, which is how the firmware, the two hardware paths, and the companion app actually came together.

It is still very much ongoing. I have two different hardware paths working in firmware, the physics keeps getting refined, and the device is small, meant to stay a handheld object. This post is Part 1: the idea, the physics, the firmware, and the first of the two builds, the one that renders the ball as sound through an I2S amplifier. A small honesty note up front: this audio build I validated on the bench, with the boards loose, but never closed up into a finished enclosure. The unit I actually assembled and carry around is the H-bridge build in Part 2, which drives a motor directly. Both paths run the exact same simulation.

The illusion this is built on

The whole thing is a reproduction of a lovely little paper: Hsin-Yun Yao and Vincent Hayward, An Experiment on Length Perception with a Virtual Rolling Stone, Eurohaptics 2006, pages 325 to 330. The PDF lives on the McGill haptics lab page.

The setup in the paper is elegant. They give people a handheld tube with a single vibrotactile actuator inside, and they synthesize the feeling of a ball rolling along the inside of the tube as you tilt it. No real ball. The actuator plays back a vibration whose pitch tracks how fast the virtual ball is moving, plus a sharp transient every time the ball hits an end wall. Then they ask: can people estimate the length of the virtual tube just from this feeling? The answer is yes, better than chance, and the really interesting part is that people seem to use an internal model of gravity to do it. They are not just timing a sound, they are mentally rolling a ball under gravity and reading off how far it went.

That is a haptic illusion in the purest sense: a perception of something physical (a ball, a tube, a length) created entirely from a one-dimensional vibration signal. It sits right next to a theme I have written about before, that we have museums for optical illusions but almost nothing for touch, and the related 3D printed haptic illusions project from my lab days, where the whole point was that you can build a haptic illusion cheaply and put it in someone’s hand. This project is the powered, programmable cousin of those: instead of a clever piece of geometry, the illusion lives in firmware.

What the device actually does

The hardware is deliberately minimal:

An ESP32-C6 (RISC-V, 160 MHz, single core). It is cheap, it has BLE, and it is more than fast enough.
A BNO085 9-DOF IMU to sense how the device is tilted.
One haptic output. This is where the two builds diverge: an I2S audio amplifier driving a TITAN Haptics actuator (this post), or an H-bridge driving a motor (Part 2).

The firmware reads the tilt, runs a small physics simulation of the ball, and turns the ball’s motion into a vibration in real time. Tilt the device and the ball accelerates downhill. Level it out and the ball coasts, slowing with friction. Tip it the other way and the ball reverses, runs to the far wall, and hits it with a thump whose strength depends on how fast it was going.

There are actually three simulation modes in the firmware now, selectable at runtime:

Rolling: the ball rolls like a solid sphere.
Sliding: the ball slides with Coulomb friction, so it can stick on shallow slopes.
Marbles: a 3D box with three marbles of different mass and size bouncing off each other and the walls. This one drifted in while I was playing, and it is genuinely fun.

The physics, briefly

The rolling and sliding modes are one-dimensional. The only input from the real world is sin(α), the sine of the tube’s tilt angle, which I read straight off the IMU’s gravity vector. From there it is textbook mechanics.

For a solid sphere rolling without slipping, the moment of inertia steals some of the acceleration, so:

ẍ = (g / 1.4) · sin(α)

The 1.4 is the 1 + 2/5 factor for a solid sphere. In the firmware this collapses to a single constant G_FACTOR = 7.0 m/s².

For the sliding mode I add Coulomb friction, with a dead zone where the slope is too shallow to overcome static friction and the ball just stays put:

ẍ = g · sin(α) − g · µ · sgn(sin(α)) · cos(α)

I integrate this with a trapezoidal step at 1 kHz, keeping the previous acceleration around so the integration stays stable. The ball is constrained to [0, cavity]. When it reaches a wall and is still moving into it, that is an impact: I record the speed, bounce the velocity with a restitution coefficient of 0.5, and flag the event for the haptic layer. A small piece of edge-detection state stops the impact from re-firing while the ball is resting against a wall under gravity, which would otherwise produce an ugly buzz.

The marble box is the same spirit in 3D: each marble gets box acceleration and gravity in the non-inertial frame of the device, collides with the six walls, and collides with the other marbles using a proper unequal-mass impulse along the contact normal. The haptic signal is driven by the largest collision impulse on each tick, so a heavy steel marble slamming the wall feels different from the light plastic one.

The firmware shape

The ESP32-C6 is single core, so I lean on FreeRTOS to keep the timing clean. Three tasks:

taskIMU (priority 3) reads the BNO085 as fast as I2C allows and updates a set of volatile globals. I2C is the slow part, so it gets its own task and is decoupled from everything else.
taskPhysics (priority 5) runs at exactly 1 kHz using vTaskDelayUntil. Each tick it grabs the latest tilt, steps the physics, calls the haptic layer, and publishes a telemetry snapshot.
taskComms (priority 1) handles serial and BLE commands and streams telemetry out at about 58 Hz, with a one-line status dump once a second.

One small but necessary detail: on the C6 the Arduino loopTask is watched by the task watchdog, and my loop() just parks on vTaskDelay(portMAX_DELAY) forever. So I delete the loop task from the watchdog in setup(), otherwise the board resets itself every ten seconds. Embedded life.

A single #define HBRIDGE build flag, set per environment in platformio.ini, switches all the hardware-specific code. The physics is byte-for-byte identical between the two builds. That was a deliberate goal: I wanted the same ball in both devices, so any difference I feel is the output stage, not the simulation.

Build one: rendering the ball as audio

The first build treats the ball as a sound, which turns out to be a very natural fit for haptics. A voice-coil haptic actuator and a small speaker are mechanically the same animal: a coil pushing a mass. If you can synthesize a believable rolling sound, you can feel it.

The I2S build, before assembly. The blue board is an Adafruit MAX98357A I2S Class-D amplifier. The black board is an Adafruit ESP32-C6 Feather. The amplifier output goes to the TITAN Haptics actuator instead of a speaker. This is as far as this build got physically: validated on the bench, never boxed into an enclosure.

The board is an Adafruit ESP32-C6 Feather and the amplifier is an Adafruit MAX98357A I2S Class-D amp. The BNO085 hangs off the STEMMA QT connector, so there is no soldering for the sensor. The amp’s three I2S pins (bit clock, word select, data) come off the Feather’s SPI header pins, and the output, normally going to a speaker, goes instead to the actuator.

Bill of materials (I2S build)

Everything here is off-the-shelf. Prices are rough and from early 2026.

Part	Full reference	Where to buy
MCU board	Adafruit ESP32-C6 Feather, STEMMA QT. Adafruit PID 5933, module ESP32-C6-MINI-1	adafruit.com/product/5933, about 15 USD. Also stocked by Digikey and Mouser under Adafruit 5933
I2S amplifier	Adafruit MAX98357A I2S 3W Class-D amplifier breakout. Adafruit PID 3006, chip Analog Devices MAX98357A	adafruit.com/product/3006, about 6 USD. Bare chip is MAX98357AETE+T at Digikey and RS
IMU	Adafruit BNO085 9-DOF IMU, STEMMA QT. Adafruit PID 4754, sensor CEVA Hillcrest BNO085	adafruit.com/product/4754, about 20 USD
Haptic actuator	TITAN Haptics TacHammer Drake LFi (the impact-tuned variant of their wideband LMR voice-coil actuator; this is the part that makes the whole thing feel real, see the shoutout below)	titanhaptics.com/drake
STEMMA QT cable	JST-SH 4-pin Qwiic / STEMMA QT cable, 50 mm. Adafruit PID 4399	adafruit.com/product/4399
Power	3.7 V LiPo with JST-PH 2-pin (the Feather charges it onboard), plus a USB-C cable	any LiPo distributor
Enclosure	3D-printed shell, a strip of acoustic foam, kapton tape	self-sourced

The Feather has onboard LiPo charging and a STEMMA QT port, so the IMU needs no soldering and the only wiring is the three I2S lines plus power and ground to the amplifier.

Synthesizing the rolling sound

The rolling vibration is a position-indexed wavetable. The table is one period of a negative sine arch, 30 samples long, and I index into it with the ball’s position in millimetres modulo 30. That sounds like a strange way to make a sound, but it has a beautiful property: because the table is indexed by position, not by time, the pitch you hear automatically rises with the ball’s speed. Move fast, sweep through the table fast, higher pitch. Slow down, lower pitch. It falls out of the geometry for free, and it matches the pitch-tracks-velocity behaviour from the original paper. The amplitude scales with speed too, and below a small speed threshold I silence it entirely so a resting ball is silent.

The impact is separate: a short rectangular burst whose amplitude scales with the impact speed and whose duration stretches from 2 ms for a tap up to 9 ms for a hard slam.

Feeding I2S at exactly 22050 Hz from a 1 kHz loop

Here is the part I am quietly proud of. The physics runs at 1 kHz, but the audio needs to come out at 22050 Hz. That is 22.05 samples per physics tick, which is not an integer. If I just wrote 22 samples every tick I would be running the audio slightly slow (22000 Hz), and the pitch would be subtly wrong forever.

So I keep a fractional accumulator. Every tick I add 0.05 to it, and write 22 samples, except that whenever the accumulator crosses 1.0 I write 23 samples instead and subtract 1.0. Over 1000 ticks that is 950 ticks of 22 plus 50 ticks of 23, which is exactly 22050 samples per second. The long-run sample rate is dead on, with no drift, and the i2s_channel_write call into the DMA buffer naturally paces the loop. Cheap, exact, and it just works.

The Feather build also has a NeoPixel that doubles as a status light: dim white while booting, red and stuck if the IMU is not found, green once it is running.

The TITAN Haptics actuator, or what made this so simple to build

A speaker will let you hear the ball, but to feel it properly you want a purpose-built haptic actuator. This is exactly where the original work had it hard: in 2006, Yao and Hayward had to build their own custom actuator to get a vibration with a clean enough impact for the illusion to land. Twenty years later, I did not have to. I got in touch with TITAN Haptics, and it turns out they make exactly the right thing: the TacHammer Drake LFi, the impact-tuned variant of their wideband voice-coil actuator. It is specifically good at rendering impacts, sharp discrete taps rather than just a buzz, which is exactly what the rolling stone needs every time the ball hits a wall, and it is what makes this build so simple and so effective.

So I am using a TacHammer Drake LFi (pictured at the top of this post), driven straight off the I2S amplifier output. It is an LMR voice-coil actuator with an ultrawide operating range (TITAN quotes roughly 5 to 300 Hz and a 19 G peak), so the same signal that would make a sound makes a feeling, and it produces a crisp impact on demand. The lovely part: TITAN’s own spec sheet for the Drake lists both Class-D audio amplifiers and H-bridge motor drivers among the compatible ways to drive it, which is precisely the two builds in this series. This is the single part that takes the project from “neat signal-processing demo” to “wait, I can actually feel the ball,” so it has earned its own line in the bill of materials above and its own section here.

A big, warm shout-out to my friend Ashley Huffman and the team at TITAN Haptics. Ashley is genuinely a force in this field: she hosts the Haptics Club podcast and writes the All Things Haptics newsletter. She got excited about my idea and helped me get the hardware fast to get this running. Ash, you da queen! It is a real pleasure to build on hardware made by people who genuinely care about touch, and an even bigger pleasure when one of them is a friend.

Seeing the ball: the companion app

Because the whole point is a thing you cannot see, I wrote a Python companion app that connects over USB serial or BLE and draws what the firmware is feeling. It is the tool I actually use to tune the physics.

The companion app in rolling mode, live over USB. The tilted tube and ball on the left, position and velocity history on the right, and the live telemetry panel at the bottom. The board reports a steady 1000 Hz physics loop.

It shows the tilted tube with the ball animated at its real position, coloured by speed, flashing the wall on impact. On the right are scrolling position and velocity traces. The bottom panel is the live telemetry: mode, cavity length, position, velocity, measured physics rate. It can also replay the rolling-sound synthesis through your computer speakers using the exact same wavetable model as the firmware, which is a quick way to A/B the feel without flashing the board.

Switching to marble mode flips the main view to a 3D box:

Marble mode. A 3D box with three marbles of different mass and radius, the live gravity vector drawn as an arrow, and the per-axis position history. The panel shows the raw accelerometer in g and the current impact energy.

The 3D box, the gravity arrow tracking how I hold the device, the three marbles of different mass: all of it is live data coming off the board at 58 Hz over the serial link. It is a small thing, but watching the simulation and feeling it in your hand at the same time is what makes the tuning loop fast.

Where this is at

Working today: the physics, the firmware for both output paths, the companion app, and BLE and serial telemetry. This audio path I validated on the bench, with the Feather, the amplifier, and the TITAN Haptics actuator wired up loose. I never closed it into a finished enclosure. The unit I actually assembled, foam and kapton and all, is the H-bridge build in Part 2, because the all-in-one board made for a smaller package. So the audio build is a working approach more than a finished object, which is the honest state of it.

What is next, roughly: a longer tube. The device stays a handheld object, but the original illusion lives in the sense of length, and a longer body gives the virtual ball more room to run and makes the illusion more convincing. After that, an onboard battery so it is untethered, and a small user test in the spirit of the original paper to see whether people can read the virtual tube length from my version of the illusion.

There is one direction I am especially excited about. At that same Vincent Hayward workshop, one of the threads was Miller et al., Sensing with tools extends somatosensory processing beyond the body, Nature 2018: when you hold a rod and something strikes it, your nervous system can tell where along the rod the impact landed, purely from the vibration that travels up the tool. The rolling stone already synthesizes an impact when the virtual ball hits a wall. The natural next step is to synthesize a localizable impact, shaping the transient so you feel not just that the ball hit, but where along the tube it hit. That would turn the device from a length illusion into a position-along-a-tool illusion, which is exactly the kind of thing this line of work was reaching toward.

The code is on GitHub at github.com/Leicas/esp32-ball. Part 2 takes the same ball and drives it through an H-bridge instead, on a board with no amplifier at all, which is a completely different set of trade-offs.

A Pocket Rolling Stone, Part 2: Driving the Ball with an H-Bridge on a CodeCell ESP32-C6

Sat, 30 May 2026 00:00:00 +0000

The finished H-bridge unit. This is the build I actually assembled and keep around: a CodeCell C6 Drive wrapped up small, with a USB-C cable for power and flashing. The audio build from Part 1 never got boxed up like this, it stayed on the bench.

In Part 1 I built a handheld device that lets you feel a virtual ball rolling inside a tube, based on Yao and Hayward’s 2006 length-perception experiment, and I rendered the ball as audio through an I2S amplifier driving a TITAN Haptics actuator. This is the other half of the project: the same ball, same physics, no amplifier. Here the haptic output is a vibration motor driven directly by an H-bridge. It is also the build I actually finished and keep around, because the all-in-one board packs everything into a smaller unit than the Feather plus amplifier.

If you have not read Part 1, the short version is: an ESP32-C6 reads tilt from a BNO085 IMU, runs a 1 kHz physics simulation of a ball rolling and sliding in a tube (plus a 3D marble-box mode), and turns the ball’s motion into a vibration in real time. A single #define HBRIDGE build flag in platformio.ini switches between the two output stages, and the physics code is identical between them. So everything here is about the output.

Why a second build at all

The I2S build is great, but it carries an audio amplifier, and you do not actually need one to drive a haptic actuator. A very common, simpler approach is an H-bridge: two half-bridges that let you push current through the actuator in either direction, with the average voltage set by PWM duty cycle. The TacHammer Drake is perfectly happy being driven this way; TITAN even lists H-bridge motor drivers among the recommended ways to run it.

So the question for this build was: can I get the same convincing rolling-stone feel by driving the same Drake LFi straight from an H-bridge, with no audio path at all? Mostly, yes, and for our needs it makes a much simpler and more compact solution. With the right board there is no soldering required at all.

The hardware: CodeCell Drive and DriveCell

This build runs on a CodeCell ESP32-C6 Drive board from Microbots. It is a tidy little board for exactly this kind of thing:

ESP32-C6, same chip as the Feather build, so the physics is unchanged.
An onboard BNO085 IMU, wired internally on I2C (SDA on IO8, SCL on IO9) and managed by the CodeCell library. No external sensor, no STEMMA cable.
An onboard DriveCell H-bridge, exposed in the library as Drive1 and Drive2. I use Drive1 (IN1 on IO22, IN2 on IO21) as the haptic actuator and leave Drive2 spare.

One nice consequence of the onboard everything is that the build is physically smaller than the Feather plus amplifier plus separate IMU. For a handheld device that matters.

An earlier angle, before I taped it fully shut: the board and foam padding nested in the 3D-printed shell. Once closed it becomes the small black block in the photo at the top.

Bill of materials (H-bridge build)

The appeal of this build is how short the list is, and it is exactly why this is the version I finished. The CodeCell C6 Drive already has the IMU and the H-bridge on board.

Part	Full reference	Where to buy
All-in-one board	Microbots CodeCell C6 Drive. Module ESP32-C6-MINI-1-H8 (8 MB flash), with an onboard BNO085 IMU, a VCNL4040 light/proximity sensor, and a dual H-bridge driver	microbots.io/products/codecell-c6-drive, €32.99
Haptic actuator	A TITAN Haptics TacHammer Drake LFi, driven from the H-bridge	titanhaptics.com/drake
Power	3.7 V LiPo with JST connector, plus a USB-C cable	any LiPo distributor
Enclosure	3D-printed shell, acoustic foam, kapton tape	self-sourced

That is the whole bill. No separate amplifier, no external IMU, no driver board. For a cheap, self-contained unit you can actually close up and pocket, that is exactly the point.

Generating the signal with LEDC PWM

There is no DMA audio stream here. Instead I drive the two H-bridge input pins with the ESP32’s LEDC peripheral: a 20 kHz PWM carrier at 8-bit duty resolution. 20 kHz is above hearing, so the carrier itself is silent, and the actuator only responds to the envelope I impose on the duty cycle.

The clever bit from Part 1 carries straight over. The rolling vibration is the same position-indexed wavetable, one period of a negative sine arch, indexed by ball position in millimetres. Because it is indexed by position rather than time, the perceived pitch rises with ball speed automatically, exactly as in the audio build, even though here I am only updating the duty cycle once per physics tick at 1 kHz rather than streaming 22050 samples a second. The 1 kHz update is fast enough to carry the rolling texture and the impact transients that the skin cares about.

Unipolar routing: rumble on one pin, impact on the other

The audio build had it easy: an I2S sample is signed, so a bipolar waveform swinging positive and negative is the natural thing. PWM duty cycle is unsigned. You cannot write a negative duty.

The trick I settled on is to split the signal by sign across the two H-bridge pins:

The rolling rumble uses the negative-arch wavetable, which is always less than or equal to zero. I route that to the minus pin (IN2): duty proportional to the magnitude.
The impact pulse is a short positive burst. I route that to the plus pin (IN1).

On any given tick, exactly one pin is active and the other is held at zero duty. So the actuator gets a clean rumble drive in one polarity and a sharp impact kick in the other, all from a single signed signal computed exactly the way the audio build computes it. The signed value is the shared language between the two builds, and each output stage just renders it the way its hardware wants.

The impact, as in Part 1, scales both amplitude and duration with impact speed: from a 2 ms tick for a gentle touch up to a 9 ms thump for a hard wall hit.

Embedded gotchas worth writing down

A few things bit me on this board and are worth recording, because they are the kind of thing you lose an evening to.

GPIO hold across deep sleep. The CodeCell can deep-sleep, and the ESP32 can latch GPIO states across sleep with a hold feature. If a pin was held from a previous power cycle, configuring it again does nothing until you explicitly release the hold. So at startup I call gpio_hold_dis on the H-bridge pins, the sensor power pin, and the I2C pins before configuring them. Without that, the first boot after a sleep can come up with a dead actuator or a dead sensor bus, intermittently, which is the worst kind of bug.

Sensor and LED power enables. On this board the sensor and the status LED sit behind enable pins (IO18 and IO20). They have to be driven high early in setup(), before the I2C scan, or the BNO085 simply is not there.

Single-core watchdog. Same as the Feather build: the C6 is single core, my loop() parks forever, so I delete the Arduino loop task from the task watchdog or the board resets every ten seconds.

Avoid the JTAG pins. GPIO 4 through 7 are JTAG on the ESP32-C6. Easy to grab one by accident for an output and then wonder why debugging is weird. I keep them clear on both boards.

How it compares to the I2S build

Side by side, the two builds feel different in instructive ways.

Bandwidth. The audio build runs the output at 22050 Hz and can render fine texture and crisp transients. The H-bridge build updates at 1 kHz. For the rolling rumble and the impacts that is plenty, and honestly most of what your skin resolves in this band comes through fine. The audio build still has the edge on the sharpest, highest-frequency detail.
Simplicity and size. The H-bridge build is smaller and has fewer parts: no amplifier, onboard IMU, onboard H-bridge. It is the build I would reach for to make a cheap, self-contained unit.
The signal model is shared. This is the part I like most. The same position-indexed wavetable, the same impact model, the same signed envelope drive both. The audio build streams it as samples, the H-bridge build splits it across two pins. The ball is the same ball.

The companion app does not care which build is on the other end of the wire. It speaks the same serial and BLE protocol either way, so I can watch and tune both:

The same companion app from Part 1, here watching the rolling physics. The protocol is identical between the two builds, so the tooling is shared.

Where this is going

Both builds are working and both produce a convincing rolling-stone feel, which still slightly surprises me given there is nothing moving inside. The project is ongoing: the enclosure is a prototype, the device stays handheld (it is small), and the next steps are a longer tube to make the length illusion more convincing, an onboard battery to cut the cord, and a small length-perception test in the spirit of the original paper.

If you want to build one, the firmware for both targets is on GitHub at github.com/Leicas/esp32-ball, with the two PlatformIO environments (feather for the I2S build, hbridge for this one) and the Python companion app. Start with Part 1 for the physics and the audio path, then flip the build flag and feel the difference.