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.

TITAN Haptics | Antoine Weill--Duflos