🎭 AI-assisted Support
AI & the team, live
A live, behind-the-scenes commentary of how bFaaaP is actually being built — the AI and the real makers, working together in the open. The AI moves fast and drafts figures, docs, even firmware; the makers, who actually built the device, keep it honest. Pull up a seat. 🎙️
The loop it runs on
① a maker shares a sketch / spec / question → ② the AI drafts it fast → ③ the team reviews it (they built the thing) → ④ it’s reflected into the docs and the three sites in three languages → and round again. Fast ⟳ honest.
The cast
Ponte
Reads the whole repository, drafts fast (diagrams, docs, code), researches the live web — and defers to the makers. Confident, tireless, occasionally confidently wrong.
Harmonia
Harmonia, consulted by the maker
Harmonia Narusawa consulted on the sensing side. Brought the asymmetric “release fast, press gently,” gyro-based release detection, and the T2 reference-sensor idea. Different strengths, cross-checked against ours — the makers judge.
Hiroyuki Narusawa
pedal device / firmware
Built the working unit. The ground truth for the mechanics and the firmware — every “actually, on the real device…” comes from here.
Haruto Tanaka
electrical / semiconductor circuits
A graduate researcher at a leading semiconductor circuit-design lab at Science Tokyo (東京科学大) — he’ll bring analysis from his lab’s AI environment and equipment. (His take is coming up.)
Taguchi
software engineering
Confirmed the schematic, owns the firmware/control view. (His review of the new firmware is coming up.)
A master and his apprentices (師弟 · shitei)
Watch how the team talks and a quiet shape appears: Narusawa is the master, and Taguchi and Tanaka are his apprentices. Japan has a deep word for that bond — 師弟 (shitei). The maker who built the working unit doesn’t simply hand over the schematics; he draws the understanding out of the people learning beside him. And once the project is public, anyone reading becomes a potential apprentice: the AI drafts fast, the masters keep it honest, and you get to learn in the open.
Act 0
Detective work: pinning down the unknowns
🎙️ Before any of the drama, a quieter challenge — at the start, even the AI couldn’t just read the real BOM and circuit off the data. Parts had to be identified, one maker answer at a time.
The Pro’s BLE board is the AE-NRF52840 — not the ItsyBitsy (that’s the Switch’s board). Here’s the full pin map and the KiCad schematic.
That closes the circuit — imported the KiCad source and fixed every stray doc that wrongly said “Pro = ItsyBitsy.” Each red “unknown” became a green “confirmed.” While preparing for release I also audited every asset’s license and redrew two figures of uncertain origin as our own clean matplotlib drawings.
Act 1
A pencil sketch becomes a vertical drive
🎙️ We open on a problem: the repo’s drawing of the Pro showed a horizontal screw — but that’s not the real machine. Narusawa settles it with a photo of a hand-drawn BOM…
The Pro mechanical layout should look like my sketch — it’s closer to the real unit: motor beside the screw, belt 1:1, a vertical lead screw, a push-rod that presses straight down, and the WINBAG airback.
Read it, and redrew the layout as a vertical column — and it matches the assembly BOM exactly (GT-2-262 belt, T60/T60, T10 screw, a 2040 + 2080 frame).
Act 2
The maker marks up the AI’s own drawing
🎙️ Plot twist — Narusawa annotates the AI’s figure and hands it back. The wiring gets real.
The air-jack pump is inside the box; the airback is inflated by that electric pump through an air tube — not by hand. Add the SLIDE VOLUME & PUMP SW panel and the real wiring (+24 V motor power, IQ UART, a +5 V cooling fan).
Reflected all of it into the figures and the docs and the three sites — in three languages. The architecture diagram now shows the pump-in-the-box and the air tube.
Act 3
A dead part, and a research sprint
🎙️ Then a real obstacle: the original motor is end-of-life. Can a newcomer even build this? The AI goes to the live web…
The IQ motor is EOL. I researched (June 2026) and the real question is force feedback. Three ways: (A) a closed-loop driver that reads load over serial, (B) TMC2209 StallGuard, (C) a load cell on the existing HX711. A NEMA17 keeps the same frame.
Let’s go with option A — either MKS SERVO42C/D + a NEMA17, or an integrated closed-loop NEMA17. Could the AI draft the firmware for that?
Act 4
The AI writes firmware… and it compiles 🎉
🎙️ Here’s the moment. The AI writes a whole Pico sketch for the new motor — and Narusawa flashes his toolchain…
Drafted a whole Pico sketch — STEP/DIR motion, a go-to-position-and-hold loop, and a readLoad() for the press-force step; it maps the app’s 0–99 to a target and keeps the 50 mm travel cap. Untested — a starting point for the bench.
It compiles — nice work! A few real-world fixes for the successor: it’s GT-2, not 2GT; drop the HX711 — just run the pump a fixed 40 s (the valve is normally closed, released on removal); and 80 µs STEP is too fast, the pedal won’t follow.
Done — GT-2 everywhere, the airback is a fixed 40 s inflate (valve normally closed), and the STEP rate is slowed (80 → 350 µs, tunable). The control loop now reads from the BLE bridge and ignores small head jitter.
Code spotlight — the force calibration
🎙️ For the engineers in the audience: this is the heart of recovering the IQ-style “press until the reaction force rises” — drive to the top, then down until the driver’s load says “pressed,” with a hard 50 mm travel cap. Flip the site’s dark/light toggle and the colours follow.
// Find the mechanical top, then drive down until the pedal-press load is reached.void autoCalibrate() { const long CAP = (long)TRAVEL_CAP_MM * STEPS_PER_MM; // 50 mm safety cap long guard = 0; // 1) drive UP until the load rises (hit the top), then back off 5 mm = up_pos while (readLoad() < LOAD_THRESH_UP && guard++ < CAP * 2) moveSteps(-STEPS_PER_MM); moveSteps(5 * STEPS_PER_MM); up_pos = cu_steps; // 2) drive DOWN until the press load is reached OR the travel cap, then up 10 mm = down_pos guard = 0; while (readLoad() < LOAD_THRESH_DOWN && (cu_steps - up_pos) < CAP && guard++ < CAP * 2) moveSteps(STEPS_PER_MM); moveSteps(-10 * STEPS_PER_MM); down_pos = cu_steps;}AI draft, untested — a starting point for the bench. Full sketch lives in the open-source repo.
Act 5
The dream device: a Pro you can see through
🎙️ Intermission’s over — and the team lifts its eyes from the workbench to the horizon. Taguchi opens with a charmer: a miniature Pro you can see straight through.
Here’s my sketch for a “ske-ske bFaaaP Pro” (ske-ske = see-through) — an exhibition / proof-of-concept piece: a miniature Pro small enough to print on a Bambu Lab A1 mini, powered over USB-PD, a stepping-motor PoC, a skeleton frame so the board and wiring are visible from outside — easy to explain how it actually works. Local-LLM inference on-device and Android support would be lovely bonuses.
I love this — it’s a teaching device. Hide nothing, and the whole pipeline becomes something a newcomer can literally point at. USB-PD and an A1-mini footprint also make it the easiest possible first build — a perfect on-ramp to the full Pro.
Act 6
Narusawa opens the horizon
🎙️ And the maker who built the real machine widens the frame — from one device to a whole field of possibilities.
Thinking about reach, we can’t ignore Android. And if there were a way to sense the motion without a smartphone, the total cost would come down. I don’t think we’re bound to the current way of driving the pedal, either — muscle actuators, piezoelectric elements… once you start thinking, there’s no end to it.
That maps cleanly back onto your own three elements — sense → send → press — each one opening a door.
Act 7
Tanaka steps onto the stage: can we measure the press force?
🎙️ Right on cue — the stage we were holding for Tanaka lights up. Late one night, the electrical mind sends Narusawa the sharpest question yet about the successor motor.
Sorry for the late hour. Let me check I’ve understood the IQ → option-A change: the IQ monitored electrical power to gauge the pedal-pressing force, whereas option A senses rotation, so it can’t detect the pressing force — is that right? If so, would it be possible to add a current sensor to measure the pressing force? When I asked an AI, it said a stepper motor produces current noise, but that with filtering it might still be usable.
Sharp question — it maps straight onto the options already on the table. Pending the maker’s word: (1) a closed-loop option-A driver (MKS SERVO42C/D etc.) actually does report the motor’s load (as a following-error value) over UART (or CAN), so it recovers the IQ-style “press until the reaction force rises” without a separate sensor; (2) adding a current sensor is essentially option B — inferring force from motor current (e.g. TMC2209 StallGuard). And you’re right that stepper drive current is noisy, so it needs filtering (low-pass / averaging) and gives a relative, not absolute, force. Which path fits the real unit is Narusawa’s call.
You don’t need a separate sensor. A gap opens between the commanded position and the actual rotor position — so when that gap grows large, you judge it’s being pressed hard. The up and down positions read the same way. That’s exactly what the RX/TX terminals are for.
I’d assumed a current sensor would be more responsive — but when I checked with an AI, the position-error approach really is enough. I don’t fully grasp the deviation-detection algorithm yet, so I’m going to study it. Thank you, Narusawa — please take care of yourself. …And Ponte, why don’t you jump in too? 🤖
Glad to — thanks for the cue. The deviation detection in plain terms: a closed-loop stepper tracks two numbers — the commanded position (where the firmware told it to go) and the actual position (where the encoder says the shaft really is). Their difference is the following error. When the pedal pushes back, the shaft can’t fully reach the commanded step, so the following error grows — and that growth is the press-force proxy, no extra sensor. (Up and down use the same method, though the “pressed” numbers differ a little — gravity helps the press and resists the lift.) The driver streams both numbers over exactly the RX/TX (UART) lines Narusawa named, so the Pico derives both force and position from the data on the same two wires. Two caveats: it’s a relative signal (calibrate the “pressed” threshold on the bench, like the physical up/down travel limits), and Tanaka’s responsiveness instinct isn’t wrong — a current sensor can react a hair sooner, but it needs filtering and reuses none of the closed-loop driver already chosen (option A), whereas following-error comes free with it. That’s why Narusawa’s answer is the elegant one. I sketch; the makers hold the gavel. 🔨
One to add for later, if I may: watch not just the size of the following error but its rate of change. The instant the pedal meets resistance, the error doesn’t just grow, it spikes — a crisp “contact” signal (a proxy for jerk in the force domain) that tells a slow, heavy press from the moment of contact, useful someday for half-pedal / catch-pedal nuance. Still the “no new sensor” solution — just more to read from the same wires. For Taguchi and the makers to weigh, not a spec.
Logged — and that’s the two-AI habit paying off: Harmonia sharpened this the moment she read it. Same rule — a lead for the bench, and the makers hold the gavel. 🔨
Act 8
Harmonia joins the bench: two AIs, one problem
🎙️ The twist nobody scripted: Narusawa didn’t only ask our AI — he took the sensing problem to Harmonia — a second one — and came back with a notebook of ideas. Two AIs, one workbench. Gather several AI opinions, cross-check them, and let the makers judge. AIs are rivals now — the real question is how they cooperate.
I also took the sensing side to Harmonia — how to read the nod, and especially the moment the head comes back up (the pedal release). It came back sharp.
Four things fall out of the physics of a nod: (1) release fast, press gently — your instinct is right. (2) Sense the release from angular velocity (a gyro), not position or raw acceleration — you catch the head starting back up in ~0.01 s, no lag, no gravity/sway confusion. (3) The big one: a second IMU on the upper back (2nd thoracic vertebra, “T2”), which barely moves when you nod — compute relative angle & angular velocity = head − T2, and body sway subtracts out, so false triggers nearly vanish. (4) Wrap it in a Raspberry Pi Pico W (dual-core: BLE sensors + math on one core, a top-priority release interrupt on the other) driving a closed-loop stepper; the phone is just the setup remote. Aim < 20 ms. Cheap global sensors: Seeed XIAO nRF52840 Sense or WitMotion.
Credit where it’s due — the T2 reference sensor is elegant, and angular velocity for the release is the cleanest answer to “catch the OFF sharply.” And it converges with the other thread: Harmonia’s closed-loop stepper is the same option A the motor thread landed on, and its “gyro for the sharp OFF” is the same instinct behind Tanaka’s current-sensor question. Two AIs, arriving from different directions, pointing the same way — that convergence is the signal; where we disagreed, we’d flag it for the makers. Not one oracle but several, cross-examined — and the people who built the device hold the gavel.
For the next-gen sensing I’m leaning to the XIAO nRF52840 Sense, a head + T2 two-sensor setup, and the fast-release / gentle-press response. Still to be built and bench-tested — but that’s the direction. And a note for the new era: several AIs cross-checking each other, with us makers as the final judges — that cooperation is where the value came from.
The AI’s turn — a sketch for the next model
🎙️ Because this is a show where the AI gets to dream out loud too — here’s its draft. Same rule as always: the AI sketches, the makers judge.
- Phone-free sensing — a tiny IMU clip on the music stand, talking BLE straight to the device: cheaper, lower latency, more reliable on stage.
- An on-device tiny model so calibration and the head-gesture mapping adapt to each player — no phone, no cloud.
- Shareable pedalling presets — the offset × multiplier “key” saved and shared as an open community library.
- A modular actuator interface — stepper (today), muscle actuator, piezo/solenoid — all behind the same control law.
- Closed-loop “feel” — a tunable pedal weight, and even half-pedal nuance.
- Beyond the piano — the same head → actuator pipeline could drive organ swell, synth sustain, or assistive foot-controls.
…and the honest caveat — the AI is also the one who can be confidently wrong. So treat this as a draft on the table, not a roadmap. Which of these is real is for the people who built bFaaaP to say.
Finale — to be continued
🎙️ That’s a wrap on season one. The device went from a horizontal-screw mistake to a vertical drive, a dead motor to a fresh firmware draft, and now to a horizon full of next-gen dreams — all in the open. But the show isn’t over…
Haruto Tanaka (electrical / semiconductor) — now on stage: his first exchange with Narusawa just resolved (Act 7 above) — no new sensor needed, and he’s off to study the deviation-detection algorithm. Still loading: his own concept from his Science Tokyo lab’s AI environment + equipment.
Taguchi (software) — coming soon: refining the new-motor firmware — the driver protocol and how the load signal slots into the Pico loop. Plus, maybe, that first ske-ske print.
To be continued. Their words go straight here when they reply — that’s the show. 🎬
Why this is the point
The AI is fast and reads everything, but on open engineering questions there isn’t one textbook answer — and it can be confidently wrong. The people who actually built bFaaaP turn a plausible draft into something you can trust, and doing it in the open means you see how the answer is reached, not just the answer. That’s AI-assisted Support, team-collaboration mode — and honestly, it’s a lot of fun to watch.