VLOG SCRIPT - Muhammad | Team: The Debuggers
SECTION 1 - INTRODUCTION
~1.5 mins | [in person]
Hello. My name is Muhammad, and I’m one of five members of team The Debuggers. My role in the team was the backend; specifically, building the hardware controller and making sure it actually talked to the game our teammates were building.
So the project we built is a Guitar Hero clone. The frontend is a Pygame application, visually designed by my teammates and the hardware side is a Raspberry Pi Pico, wired up with six buttons, acting as the guitar controller.
My job was everything on that Pico. Getting it to read button presses, debounce them properly, encode them, and send that data to the game to work as a plug and play device.
That’s what this vlog is about.
________________________________________
SECTION 2 - RESEARCH + MY JOURNEY (with flowchart)
~2 mins | [in person]
So before I show you any code, let me walk you through how I actually got here, because I did not start with any prior knowing of any of this.
My initial assumption was… how hard can a controller be? You’ve got buttons. A button is either pressed or not pressed. High current or low. Done. Right?
But yeah… doesn’t work like that.
The moment I actually started looking into it, I realised that any kind of human input on a microcontroller is way more complex than what a light switch is. There’s electrical noise, there’s timing, there’s how the operating system even recognises the device in the first place.
So I went and consumed everything I could find on the subject.
Because that’s another thing I overlooked at first, that not every language works with every board. So I mapped out a path for myself. Three languages, all compatible with the Pico which we already had on hand, in order of difficulty: MicroPython, CircuitPython, and then C. The two Pythons would act as my stepping stones.
One quick thing I want to point out here is that the entire stack we used is all open source or freely available. That matters because it makes this kind of hardware project genuinely accessible. Anyone with a £1–4 Pico can build this.
Ethical overview:
On the flip side one of my MicroPython approaches involved using the sys.stdout debug channel to send data to the PC, which is technically using a channel that isn’t designed for that. In a real production context, that may raise questions about reliability and intended use. Something I’d address properly with more time… more on that later.
________________________________________
SECTION 3 - THE CODE: LANGUAGES
~3.5 mins
3.1 - MicroPython side projects
[in person]
So I didn’t go straight into the controller. I wanted to get comfortable with the board first so I did a few small side projects in MicroPython.
I played with the onboard temperature sensor.
I made a reaction-time terminal game — nothing fancy, just checking inputs and timing.
And I made an auto-clicker for my phone… I’ll be honest, I was farming an idle game, I’m not going to pretend otherwise.
But the point is by the end of those, I understood how pins work, how to read values, how timing works on the board and got pretty confident.
But as life is… not everything goes smoothly. MicroPython doesn’t have a HID library. Meaning I couldn’t just declare the Pico as a gamepad. The operating system wouldn’t see it as a controller at all.
________________________________________
3.2 - CircuitPython + HID
[in person]
So I moved to CircuitPython, which is Adafruit’s version of Python for microcontrollers. And this is where things actually started working.
CircuitPython has the HID library built in from version 10 onwards. Which means I could declare the Pico as a real USB HID gamepad. HID stands for Human Interface Device. It’s the USB standard that tells the OS “this thing is a controller, treat it like one.” No extra script needed.
The way it works is two files. boot.py runs once on power-up, before USB even initialises, and that’s where I register the HID descriptor. The descriptor is basically the Pico handing the PC a CV of itself on connection.
The descriptor has to follow the USB HID spec exactly, so I defined 8 buttons rather than 6, because HID reports must align to full bytes. So bits 6 and 7 are declared but always stay zero.
Then code.py is the main loop reading the buttons, building a bitmask, and sending it as a one-byte HID report.
That bitmask approach — each bit in the byte represents one button — is what lets you press multiple notes at once. One byte includes everything.
One thing I had to solve that I didn’t expect: debouncing.
Physical buttons don’t cleanly switch states. The metal contacts bounce for about 10 milliseconds, producing rapid false reads. Without debouncing, one press registers as multiple.
My solution uses three parallel lists per pin — a stable state, a candidate state, and a timestamp. A new state only gets accepted if it holds steady for 20 milliseconds. Bounce noise flickers too fast to survive that window. A real deliberate press passes it.
________________________________________
3.3 - Back to MicroPython (the sys.stdout workaround)
[in person]
So at this point I had a working CircuitPython prototype. But I kept going back to MicroPython — I refused to believe there was no workaround.
And then I found one. The sys module. Specifically sys.stdout.write().
Normally stdout is for debug output. But you can use it to write raw bytes over the serial connection. So instead of a proper HID report, the Pico sends a single byte over serial, and a reader script on the PC side picks it up and translates it into inputs for the game.
It was an ingenious workaround but also a double-edged sword. You’re essentially building your own gamepad system from scratch.
That meant the PC side needed threading, a lock to prevent data corruption between the reader thread and the game loop, and auto-detection of the Pico’s vendor ID.
More moving parts. More things to break. But it worked, and honestly it taught me more than the CircuitPython version did.
________________________________________
SECTION 4 - TESTING
~1.5 mins | [in person]
Testing the thing was its own challenge.
Before the game was far enough along to test against, I needed a way to verify the output was actually working.
So I used a built-in controller testing program that shows every button press in real time. If it works there, it works as a gamepad.
Once the game was ready, I moved to testing with the serial system properly integrated. The reader auto-detects the Pico by scanning connected ports for its vendor ID, so it finds the right connection regardless of what the system assigns.
________________________________________
SECTION 5 - EXAMPLE PROJECTS DEMO
~5 mins | [in person]
Right so here’s where I show everything. Starting with the side projects I built to learn the board, then the MicroPython controller, the CircuitPython version, and then the full game running.
________________________________________
SECTION 6 - PROJECT MANAGEMENT EVIDENCE
~45 seconds | [in person]
Quick look at the project management side.
We used in person meetings for task tracking as a team, and kept in contact through messaging. Being in a team where everyone had a clearly separated domain actually worked well.
But we still had to communicate for major decisions — whether that was visual design, hardware choices, or future additions.
________________________________________
SECTION 7 - CONCLUSION
~1 min | [in person]
So to wrap up.
The project worked. We shipped a playable Guitar Hero clone with a physical controller, built from scratch.
I went from genuinely not knowing what embedded programming involved to having a working HID gamepad on CircuitPython and a serial-based MicroPython version with proper debouncing, bitmask encoding, threading, and auto-detection.
What I’m most proud of is probably the HID implementation and the MicroPython workaround. Those were real problems I had to research, understand from first principles, and implement myself.
If I had more time, the main thing I’d push toward is C. That would give full low-level control over the descriptor. It’s more complex but it’s the proper way to do it.
But for the scope and timeline of this project, I’m happy with where it landed.
________________________________________
TIMING Goal
Sec 1 Introduction ………… ~1.5 min
Sec 2 Research ……………… ~2.0 min
Sec 3 Three languages ……… ~3.5 min
Sec 4 Testing ……………….. ~1.5 min
Sec 5 Demo ………………… ~5.0 min
Sec 6 Project management …… ~0.75 min
Sec 7 Conclusion ………….. ~1.0 min
TOTAL …………………….. ~15.25 min