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.

CodeCell | Antoine Weill--Duflos