Near the end of 2019, I realized that this website had become a bit of a mess. Posts were scattered all over the place, categories were poorly labeled and poorly organized, and the permalinks had a mind of their own. The website was not set up well for either hosting or sharing my content, and it was making me reluctant to post new things. So I decided to fix it.
FrameVis is a Python script for creating visualizations from video frames, also known as “movie barcodes” due to their vertical striping. The script uses the OpenCV library to read from a video file, load frames into memory, and then stack them together to make a new image visualizing the entire film. The resulting visualizations are as fascinating as they are beautiful… you can see the flow of the color grading, the pacing of the editing, and if you know the film well enough you can even pick out certain scenes or even shots.
This script works on Windows, Mac, and Linux and is compatible with all OpenCV file types and codecs. You can download it on GitHub.
I have an old Logitech C270 webcam that I use in combination with OctoPrint to monitor my 3D printer. Since my printer doesn’t have its own enclosure, I made a simple camera “pole” out of some spare 2020 aluminum extrusion I had lying around and stuck the webcam on top. There’s just one problem – the webcam’s bracket wasn’t designed for the shape of the extrusion, and sometimes the vibrations from the printer occasionally knock the webcam off! So I decided to put my skills to work and design a 3D printed mount to bolt the webcam directly to the aluminum extrusion.
A few months ago I was attempting to reformat my laptop as a dual-boot machine with both Ubuntu and Windows 10 and I was having issues getting the boot manager to properly detect both operating systems. Shortly after changing a setting in the BIOS related to SATA operation, the laptop suddenly stopped working after rebooting. Powering it on resulted only in a pure black screen where after approximately fifteen seconds it flashed “Lenovo Misto Ontario”, and then nothing. It was true and thoroughly “bricked”.
I tried everything I knew to fix it, including pulling the CMOS battery, reformatting the hard drive, and trying to ‘auto-flash’ the BIOS from a USB drive – nothing worked. I’ve had this little Lenovo S205 netbook for a few years and although it’s gotten slower it’s always served me well. And since it was working perfectly fine up until it er, wasn’t… it seemed like a waste to just throw it out without trying my best to fix it.
I’m happy to say that I succeeded. The solution was to reflash the BIOS chip with a replacement BIOS I found online, using an open source program called ‘flashrom’ and an Arduino acting as an SPI flash programmer. Here’s how I fixed it.
Aperture Science (a.k.a Aperture Laboratories) is a fictional scientific research corporation, whose facility is the setting for the 2007 puzzle-platform video game Portal, as well as its 2011 sequel Portal 2. Aperture’s approach to scientific research is a little… strange, to put it mildly. They have a penchant for testing exotic materials, building maniacal robots, and creating wholesome musical interludes. And, apparently, coming up with long-winded names for storage containers.
The Aperture Science Handheld Dihydrogen Monoxide Containment Unit was a stainless steel water bottle created and sold by Valve Corporation and ThinkGeek for the release of Portal 2, circa 2011. The bottle came in both 40 oz black and 22 oz white variations, with decals for Aperture Laboratories and a disclaimer about the deadly nature of H₂O. Unfortunately it looks like they stopped selling these several years ago – the product page from the Valve store has vanished entirely, while the ThinkGeek product page has both bottles listed as “no longer available”.
I’m not so easily deterred, so I spent this past weekend building my own “Aperture Science Dihydrogen Monoxide Containment Unit” using a stainless steel water bottle and some custom made vinyl decals.
In my opinion, one of the more novel things you can do with an Arduino is put it to use as a custom game controller for your favorite games. Whether you’re retrofitting a Nerf gun, converting a rhythm controller to play an FPS game, or playing PUBG with a frying pan – using an Arduino makes it quick and easy to build your own custom controller.
In this tutorial, I’m going to show you how to program your own Arduino to emulate an Xbox controller using the ArduinoXInput library.
Recently I’ve been playing around with building various alternative controller projects for games, typically using an Arduino-compatible microcontroller acting as an HID input device of some sort. The Arduino ecosystem makes it easy to set up these projects to act as either a Keyboard, a Mouse, a DirectInput Joystick, or a composite device that’s a combination of the above. Unfortunately back in 2005 DirectInput was supplanted by XInput with the release of the Xbox 360 controllers, and modern games have been weaning off of it ever since.
These days, many mainstream games barely support DirectInput at all. Games like Rocket League and Overwatch won’t even recognize a DirectInput joystick – you have to use XInput controller emulation software that can be tricky to set up and doesn’t work with every game.
Wouldn’t it be great if there was a simple, turnkey way to make your Arduino emulate an Xbox controller and work out of the box with these newer games?
One of my recent projects has been trying to modify some microcontrollers to function as XInput devices, emulating an Xbox controller. The first step in this process is to fetch and then break down the device’s “USB descriptors”. These descriptors are a hierarchy of standardized reports that describe features of the device including who makes it, what version of USB it supports, how it’s powered, and more. By copying the Xbox controller’s descriptors onto my own device, I can convince the computer that my device is also an Xbox controller and will behave like one, and therefore use the Xbox controller’s driver to easily interface with games.
But rather than just copying and pasting the descriptor from one place to another, I want to try and understand exactly what’s going on behind the scenes. I want to understand how the information in these descriptors translates into features of the device’s behavior.