PiGRRL Switch: Test Controller in Action!

2017-03-18 12.55.34

So I didn’t get a chance to take a video of the controller in action, but I do have a picture of me playing the original Zelda using my soldered up controller prototype. The Raspberry Pi and LCD is hooked up to one battery bank and the controller is hooked up to a separate one. Going through this test I noticed a few things that can be improved.

For starters, I had a hellish time getting enough power to both the Raspberry Pi and LCD. For whatever reason the power supply didn’t seem to be able to give enough juice to keep the Raspberry Pi from rebooting. The display has two micro USB ports on it that are used to power the screen and provide touchscreen feedback to the Pi. However since I currently don’t need to use the touchscreen I just powered the screen directly from the battery bank. To circumvent these power issues in the future I’ll need to see if I can get the Pi to provide more current from the USB ports. If that doesn’t work I can use one of the micro USB ports for touchscreen feedback and cut the red power wire to prevent the screen from drawing power from that port and use the second USB port to power the screen directly from the battery bank.

Another issue I noticed with my controller is the lack of menu buttons. The RetroPie interface requires using Start and Select buttons for navigation, so I had to map those to an attached keyboard since I only have four action buttons and four directional buttons on my prototype. Additionally I’ll also want shoulder buttons since the later consoles all have at least two and the PS1 has four.

The next step for the controller interface is designing the PCB!


PiGRRL Switch: Controller Driver

The next step in getting the controller to work as a RetroPie controller is writing a driver so the console interprets the serial data coming in from the Bluetooth module the same way it would interpret a USB controller.

I got this idea from petRockBlog who mapped their custom, two-player joystick to two separate virtual controllers in RetroPie.  Their code is available on GitHub.  After a quick review, I saw that their code is using a C user input emulation library called uinput.  In the interest of simplicity I found a Python uinput library and decided to use that to emulate my controller driver.

Below is a full snippet of the code from the GitHub repository followed by an explanation of how it works:

This is the definition of the Controller class.  A static variable called NumButtons is used to show the maximum number of buttons a Controller has.  A Controller instance is initialized with a path to the Bluetooth serial device which it then connects to.  The initialization also creates a uinput Device that it will use to simulate a virtual controller for providing input to the console.

An array of keys is created to represent the possible input keys that will be passed into the system.  Right now I’m just using the letters of the alphabet.  RetroPie offers full controller customization so the actual keys used don’t really matter.  I still plan on changing the controller driver to emulate a joystick with analog controls, however, so this method will need to be updated in the future.

This array will store the device names for all of the Bluetooth serial consoles.  At some point I’d like to autodetect all of the serial consoles from the controllers but for now a hardcoded array will work.

The program creates a controller for each serial console in the ControllerNames array and stores them in the Controllers array.  It also resets the serial input buffer so old input data doesn’t bog down the driver and it can start processing the most current data.

My driver operates on button transitions (unpressed->pressed and pressed->unpressed) rather than operating on the button state.  This is to be consistent with keyboards which work in the same way.  Because of this transition-based processing, the previous input packet needs to be stored so the previous packet can be compared to the current packet and differences between the two can be detected.  Here the previous packet is instantiated as a dictionary and is initialized to a known, totally unpressed state.

This is just an infinite loop which iterates over the list of controllers and processes each of them.

A line is read from the serial port and split at the colon.  The left side will be the key character which reflects the type of data and the right side will be the data itself.

This if statement detects which key is seen and executes the appropriate code.

This is the code for the key ‘K’ which is the only type of data I currently have.  It iterates over each character in the eight bytes of data and compares it against the data from the previous packet.  If the value went to ‘1’ from ‘0’ it emits an event to signal that the key was pressed and if the value went to ‘0’ from ‘1’ it emits an event to signal the opposite.

Alien Clock: Painting All the Things!

So rather than make individual posts for painting each of the pieces, I decided to lump everything together. The Xenomorph design has varied a lot between depictions, so really there were no specific requirements for coloring and design. I wanted something similar enough to the original designs to be recognizable, but I wasn’t that concerned about fine details.

Disclaimer: Since I don’t have an artistic bone in my body, my wife was kind enough to do most of the painting for me. She did a far better job than I ever could have and everything turned out wonderfully!

Prior to painting, I coated all the prints and the styrofoam head in liquid latex, which was an interesting experience. The bottle I purchased advertised that it was good for monster make up or making scars on faces, but it was difficult to work with to make a smooth surface. Luckily, the dried latex peeled off really easily, which was convenient in the case of mistakes but also sometimes peeled off too easily. After several tries, however, all the pieces had a nice matte finish and fleshy look to them.


Since Freddie the Facehugger is so large, we were a little concerned about keeping the color scheme constant if we went with the same messy approach used for Charlie. Instead, she mixed a ton of light yellowy greenish gray (again, technical terms!) as well as a darker, browner version and a deeper dark gray/brown for shadows. She coated the whole thing with the lightest shade and then contoured the edges and details with the darker colors. This approach was less detailed than mixing small amounts of each creepy bloody shade for Charlie, but it was the easiest way to keep this consistent from the tail all the way out to the arms. One extra challenge with Freddie was all the joints. We wanted to cover as much of the white PLA as possible while still allowing some flexibility. To solve this problem, we used a very watered down paint that was more translucent but soaked into the joints better and did a good job of covering all the visible white sections.












For Charlie the Chestburster, she painted a base coat of yellowish peachish brown (that is the technical term for it, I believe) with some gray mixed in for texture and then added darker gray to the shadows and details to help define them. For the blood, she mixed a bright red paint with black, brown, and green to get a deeper color and painted this on thick in splotches and also watered it down to stain other areas. This was a lot of just splashing paint around and hoping for the best, but the messy look really turned out well!







For the face itself, I just spray painted the styrofoam head model with two coats of “Skin colored” paint. The model had some stains and marks on it when I got it, but this really covered them up well. Plus, his face will be pretty much hidden anyway (poor guy).







Clock Hands

The clock hands were just black and gray paint mixed together. We had to do two coats to get in all of the grooves of the uncoated PLA. The benefit of this is that it lets some of the white plastic show through and gives the “tails” a more textured look.







Alien Clock: Making Kane’s Uniform

I decided to model the mannequin after Gilbert Kane, the first victim from the original Alien movie. In order to add some realism to the model, I decided to make his uniform from the infamous last supper scene.

He has two patches on what looks like a white shirt. The shoulder patch is the Nostromo Crew patch and the breast patch is the Weyland-Yutani logo There appears to be a pocket and some other details on the shirt, but for my purposes I’ll just use another one of my undershirts.

And luckily for me, the patches are readily available on Amazon, with the Nostromo one here and the Weyland-Yutani one here.



Both patches were iron-on so then went on easily.



And with that, Gilbert is ready for his last meal!

Alien Clock: Making the Mannequin

Originally I was hoping to find a full mannequin body locally to use as the “host.” Unfortunately I was unable the find anything and all of the online options seemed expensive with shipping.



Luckily, HackPGH had some spare, foam mannequin heads lying around that they let me use for my project. Still in need of a mannequin torso, I found this Instructable which provides instructions on how to make a mannequin of your own body using duct tape casting.



I used an undershirt as my scrap shirt and, because this project doesn’t really need an entire mannequin upper body, I stopped duct taping at my navel. I only ended up using a single roll of duct tape, but would recommend more as more layers result in the final product being stiffer.

This is already the creepiest thing I’ve ever made, by far.

The last step for the mannequin was attaching the head to the torso. The fit was already snug so a few strips of duct tape were all that was needed to attach the head.

The wig is something I picked up from Amazon. I’m hoping to style it after Kane’s hair from the original movie.

Alien Clock: 3D printed parts are done!

I’ve finally finished the 3D printed Facehugger and Chestburster!


The Chestburster was a simple print that used a file sourced from Thingiverse. I’m pretty happy with the way it turned out. I printed it with PLA at a 0.2mm layer height to get a good balance between speed and resolution. One issue I did notice was a striping along the Z axis. After some investigation, I attributed this to a slight bend in the Z-axis screw on my Printrbot. The striping is pretty faint, however, so I’m hoping that a layer of paint will cover it up. Additionally, there’s already a hole in the base of the Chestburster design which will make mounting it to the cuckoo mechanism trivial.


The Facehugger was a little more difficult. I also sourced this from Thingiverse. This is an amazing piece of work by user Agisis that’s perfectly split up for 3D printing. It’s also divided into opposable pieces which will make attaching it to the victim’s face much easier.

However, because the Facehugger will be making up the clock face, I wanted to modify the body so the clock mechanism can be easily inserted. I also wanted to provide a hole in the front for the main shaft to protrude through. Unfortunately, after importing the STLs into OpenSCAD to modify, I found out the file had a bunch of errors and OpenSCAD couldn’t render it properly. After running the complex body through several STL-cleanup programs (e.g. MeshLab, Netfabb, etc.) I still couldn’t get OpenSCAD to render. About to give up and resort to drilling a hole through the completed body, I decided to read through the 150+ comments to see if someone else had encountered the same problem (Side Note: If you read through the comments, you’ll see that Agisis is one of the most helpful authors on Thingiverse. He provides a bunch of assistance to people having issues with printing, and provides a lot of advice for painting the finished product.). Lo and behold, user rodrifra had already fixed the STL files. With the repaired STL files, modifying the body was simple and all that was left was printing!

I printed one leg at a time in PLA at a 0.1mm layer height, for maximum resolution. At an hour and a half a leg, it took a while! Next was the tail, which I printed in three parts with the same settings for a total time of five hours. Last were the body files. I printed both pieces at a 0.2mm layer height to speed things along, and am happy with the results! The bottom took a total of an hour and a half to print and the top took two and a half.

Next up for these parts is gluing everything together and then painting!

Alien Clock: Description

Note: This is a mirror of my "Alien Cuckoo Clock project" submitted to the 2017 Hackaday SciFi contest. For more information, visit the project link.

The Alien Cuckoo Clock consists of several discrete pieces that will be combined to form the clock. The different pieces are:

  • Facehugger
  • Chestburster
  • Clock mechanism
  • Cuckoo mechanism
  • Mannequin
  • Electronics

Thingiverse is a great repository for premade 3D printed files and many of the designers there are far more skilled in 3D modelling than I will ever be, so I’ll be reusing open source designs from there for the Facehugger and Chestburster. I will, however, be painting them myself.

Rather than reinventing the wheel (errr… clock) I decided to buy a clock mechanism to use as the clock internals and hands. The upside of this is not having to handle clock controls or complicated gearing, but the downside is that the cuckoo mechanism will have to be synced with the clock somehow so it can be properly triggered at the top of the hour.

I’ll be designing the cuckoo mechanism myself, probably using gears or other basic components from Thingiverse. I have quite a few spare, generic, yellow motors from OpenADR, so I anticipate designing a mechanism to convert that rotary motion into the linear motion required by the Chestburster cuckoo.

The mannequin will serve as the body of the Facehugger/Chestburster victim (chestburstee?). I anticipate finding a spare full-body mannequin, if possible, and cutting off the lower portion and arms. However, if I can’t find one I can create the torso using duct tape casting and find a lifelike mannequin head on Amazon.

I’m hoping to keep the electronics for this project as simple as possible. I have plenty of Arduino’s laying around so I’ll be using one for the controller in addition to a few end-stop switches for the cuckoo mechanism and maybe a hall effect sensor to detect the top of the hour.