As much as we enjoy spinning up our own solutions, there are times when you’ve got to look at what’s on the market and realize you might be out of your league. For example, take Bluetooth game controllers. Sure, you could make your own with a microcontroller, some buttons, and a couple joysticks. But between the major players like Microsoft, Nintendo, and Sony, as well as independent peripheral companies like 8BitDo, there’s some seriously impressive hardware out there that can be easily repurposed.
How, you ask? Well, Bluepad32 by [Ricardo Quesada] would be a great place to start. This Apache v2.0 licensed project allows you to easily interface with a wide array of commercially available BT controllers, and supports an impressive number of software and hardware platforms. Using the Arduino IDE on the ESP32? No problem. CircuitPython on Adafruit’s PyPortal? Supported. There’s even example code provided for using it on Linux and Mac OS. Sorry Windows fans — perhaps there’s a sassy paperclip or sentient dog built into your OS that can instruct you further.
The nature of the Bluetooth Human Interface Device (HID) protocol means that, at least in theory, pretty much all modern devices should be supported by Bluepad32 automatically. But even still, it’s hard not to be impressed by the official controller compatibility list. There’s also separate lists for Bluetooth mice and keyboards that are known to work with the project.
While it’s somewhat unlikely to be a problem in this particular community, there is an unusual quirk to this project which we think should at least be mentioned. Although Bluepad32 itself is free and open source software (FOSS), it depends on the BTstack library, which in turn uses a more ambiguous licensing scheme. BTstack is “open” in the sense that you can see the source code and implement it in your own projects, but its custom license precludes commercial use. If you want to use BTstack (and by extension, Bluepad32) in a commercial product, you need to contact the developers and discuss terms.
License gotchas aside, Bluepad32 is definitely a project to keep in the back of your mind for the future. You can always build your own controller if you’re looking a challenge, but you’ll have a hell of a time beating the decades of testing and development Sony has put into theirs.
Nice was thinking about looking for something like this.
AFAIK: using the PicoW includes a commercial license:
https://www.raspberrypi.com/news/new-functionality-bluetooth-for-pico-w/
I worked with BTStack for a long time, liked it much more than Bluedroid, but the licencing model was also new to me.
I am 100% in favor of opensource stuff disallowing commercial usage. Imo it’s crappy when a company takes an opensource product, slaps it in hardware and sells it, then directs software questions/issues to the GitHub.
Well that’s nice, but both the FSF and OSI agree that a license clause which limits what a user can do with the code (like not use it in commercial product) violates the core principles of open source.
I don’t even think BTstack can call itself an open source project with this kind of limitation in their license. The more accurate term would be “source available”.
Speculation?
They don’t appear to do so in their GitHub readme.
Well it’s a good thing BTstack doesn’t call itself anything of the sort.
It’s explicitly proprietary with a clause allowing free use for non-commercial projects. The only people claiming differently are people here who haven’t bothered looking (and Tom, who seems to think it’s “ambiguous” when it clearly isn’t.)
All the FOSS projects it in turn uses are explicitly listed along with their licenses, all of which are directly compatible with that model (BSD/MIT/Apache).
It’s one thing if e.g. the main contributors of a project are selling assembled kits as a means of support while giving away the design, and a crappy clone undercuts their price without contributing to the project. But otherwise, I am happy to see open designs taken to production with the manufacturer actually providing proper attribution and access to the source for once instead of keeping a private copy with no updates and without contributing back to the original. Maybe most of the feedback will be a waste of time, but some will help find real points for improvement. Of course, I’d ultimately prefer them to actually contribute resources rather than just point people at the project.
Just don’t use this to control your submarine
tell that to the US submarine service: https://www.theverge.com/2017/9/19/16333376/us-navy-military-xbox-360-controller
I couldn’t find circut python library for pico w on git . Can someone paste the link in the reply if they have any idea. I could only find pico sdk version for pico w
Looks like an accidental conflation by the article author. Pi Pico W is supported by the C API, while the CircuitPython library requires ESP32 boards (as a co-processor).
The Bluepad32 docs say you can use a standalone ESP32 Airlift board with whatever CircuitPython device you want:
https://bluepad32.readthedocs.io/en/latest/plat_airlift/
But admittedly, that’s probably not what people are expecting in relation to the Pico W. I’ve changed it to be clearer that CircuitPython support is better left to devices that have Airlift integrated.
I bet you could dump BTstack for NimBLE. I had a helluva time trying to teach myself bluedroid due to the lack of good documentation, but NimBLE is well documented and there are lots of examples to look at. The best part is NimBLE takes around a quarter to half the flash and ram that bluedroid requires, at least on ESP32s.
(Bluepad32 author here).
NimBLE is BLE only. Which would be a problem for the majority of the controllers, that as of today, are based on BR/EDR (BT Classic). E.g: DualShock4, DualSense, Switch Controller, etc.
See: https://bluepad32.readthedocs.io/en/latest/supported_gamepads/#bluetooth-gamepads-and-their-protocol