PiGRRL Switch: Controller Test Firmware

May 7, 2017 kelliott121 Projects Arduino, Bluetooth, emulator, Nintendo, PiGRRL, Switch

As a follow-up to my last post, I wanted to go over the Arduino firmware I used for my primary controller test. Essentially what it does is read the states of multiple buttons and print a sequence of 1’s or 0’s (1 for unpressed and 0 for pressed) to the Bluetooth module.

	enum DPad {RIGHT = 2, UP = 3, LEFT = 4, DOWN = 5};
	enum Buttons {A = 6, B = 7, X = 8, Y = 9};

	void setup() {
	// Set the DPad buttons to pullup inputs
	pinMode(RIGHT, INPUT_PULLUP);
	pinMode(UP, INPUT_PULLUP);
	pinMode(LEFT, INPUT_PULLUP);
	pinMode(DOWN, INPUT_PULLUP);

	// Set the action buttons to pullup inputs
	pinMode(A, INPUT_PULLUP);
	pinMode(B, INPUT_PULLUP);
	pinMode(X, INPUT_PULLUP);
	pinMode(Y, INPUT_PULLUP);

	Serial.begin(9600);

	delay(5000);
	}

	void loop() {
	// Print the Key packet
	// DPad
	Serial.print("K:");
	Serial.print(digitalRead(RIGHT));
	Serial.print(digitalRead(UP));
	Serial.print(digitalRead(LEFT));
	Serial.print(digitalRead(DOWN));

	// Action buttons
	Serial.print(digitalRead(A));
	Serial.print(digitalRead(B));
	Serial.print(digitalRead(X));
	Serial.println(digitalRead(Y));

	delay(10);
	}

view raw

BluetoothTest.ino

hosted with ❤ by GitHub

The whole program is embedded above and I’ll go through each section individually and explain what it does below.

	enum DPad {RIGHT = 2, UP = 3, LEFT = 4, DOWN = 5};
	enum Buttons {A = 6, B = 7, X = 8, Y = 9};

view raw

ControllerTestFirmware0.ino

hosted with ❤ by GitHub

These enums serve the purpose of defining human-readable names for the pins that are hooked up to the buttons. That way their usage in the code is immediately obvious upon reading.

This isn’t strictly necessary due to the simplicity of this program, but the general best practice is to not use integer literals in code.

	// Set the DPad buttons to pullup inputs
	pinMode(RIGHT, INPUT_PULLUP);
	pinMode(UP, INPUT_PULLUP);
	pinMode(LEFT, INPUT_PULLUP);
	pinMode(DOWN, INPUT_PULLUP);

	// Set the action buttons to pullup inputs
	pinMode(A, INPUT_PULLUP);
	pinMode(B, INPUT_PULLUP);
	pinMode(X, INPUT_PULLUP);
	pinMode(Y, INPUT_PULLUP);

view raw

ControllerTestFirmware1.ino

hosted with ❤ by GitHub

This is the pin mode setup in the Arduino setup() function. The buttons are hooked up directly to ground so that when the button is pressed, the pin sees 0V. When not pressed the pin is floating so here I’m enabling the Arduino’s pullup resistors so that when the button isn’t pressed the pin sees 5V.

	// Print the Key packet
	// DPad
	Serial.print("K:");
	Serial.print(digitalRead(RIGHT));
	Serial.print(digitalRead(UP));
	Serial.print(digitalRead(LEFT));
	Serial.print(digitalRead(DOWN));

	// Action buttons
	Serial.print(digitalRead(A));
	Serial.print(digitalRead(B));
	Serial.print(digitalRead(X));
	Serial.println(digitalRead(Y));

view raw

ControllerTestFirmware2.ino

hosted with ❤ by GitHub

Here the state of the buttons is read and printed to the Bluetooth module over UART. Because of the way pullups are handled, ‘1’ corresponds to unpressed and ‘0’ corresponds to pressed. The printing of the button states is preceded by a “K:” to act as a key-value pair. This means that when the controller driver on the Raspberry Pi sees a “K” it knows it’s about to get a list of digital buttons. I’m planning on using this in the future to enable more complex data than just a few buttons. For example, I could use the keys “JX” and “JY” to denote the two axis values of an analog joystick. The last serial print is a Serial.println() function call to print a newline character. This is an easy way to segment the data so the controller driver can differentiate between multiple packets.

delay(10);

view raw

ControllerTestFirmware3.ino

hosted with ❤ by GitHub

Lastly is the delay that sets the update rate of the program. With a delay of 10 milliseconds at the end of the loop, new button states will be sent to the driver at an update rate of roughly 100Hz. Right now this rate was arbitrarily decided, but in the future I’ll have to tweak it to balance several factors.

First off is the bandwidth of the Bluetooth connection. As far as I can tell, the HC-05 module uses Bluetooth 2.0 which has a data throughput of of 2.1 Mbit/s or 275251.2 bytes per second. Divide this by the update rate and you get the total amount of data that can be sent in one cycle of the program. This also assumes that the connection is perfect with no lost packets. Bluetooth’s serial port profile uses re-transmission to verify that packets sent are received. This means that wireless noise can cause the connection to slow down while the Bluetooth module is attempting to resend a bad packet. Additionally, if I go back to the BLE module and am able to get it working, BLE only has a throughput of 35389.44 bytes per second, or 13% of Bluetooth 2.0. So while I’d be saving power I’d be restricting the update rate and amount of data I can send from the controller.

Another thing to consider is the update rate of the controller driver running on the Raspberry Pi. Serial ports have buffers to store incoming data. This means that if the driver is updating slower than the controller, the driver won’t be able to process all of the data coming in and the buffer will overflow. This problem will exhibit itself as lag in the controls. The driver needs to be updating at the same rate, or faster, than the controller.

The last consideration is debouncing. This is a topic that has been extensively covered elsewhere, but suffice it to say that if the controller updates too fast it will accidentally send phantom bounces in the switch contacts to the driver and cause erroneous button presses.

Once everything has come together and is working to a degree I’m happy with, I’ll come back to these small issues and tweak everything until it works perfectly. Until then, my next step is writing the controller driver! As always, my code is available on my GitHub in the PiGRRL_Switch repository.

PiGRRL Switch: Creating the Controllers

April 27, 2017April 27, 2017 kelliott121 Projects Arduino, Bluetooth, Circuit Design, Gaming, Raspberry Pi

With the screen chosen and working, the next step for creating the PiGRRL Switch was prototyping the controllers. Initially, I wanted something cheap and easy like a breakout board that acted as a Bluetooth HID joystick. I was immediately drawn to Adafruit’s EZ-Key which acts as a Bluetooth keyboard. At the time I’m writing this, however, it’s out of stock and seems to have been for a while. Additionally, because it acts as a Bluetooth keyboard and not a joystick, it rules out any possibility of adding analog controls in the future.

Another alternative to a Bluetooth HID breakout would be taking apart a cheap Bluetooth joystick and putting it in a 3D printed casing. However, I decided this would greatly reduce the design flexibility of the controllers and might make it difficult to reconfigure the controllers on the fly (i.e. using two JoyCons as one controller vs. using them as two separate controllers).

So with those two options off the table I decided instead to use a Bluetooth serial bridge. The HM-10 BLE and HC-05 Bluetooth 2.0 modules are both cheap and plentiful and provide a good solution at the cost of some extra work. These modules can be hooked up to the UART of an Arduino and paired via Bluetooth. Once connected, it acts as a virtual serial port in Linux, allowing the serial data to be read just as if the Arduino was connected via USB or FTDI. The only exception to this is that it doesn’t support firmware loading wirelessly.

2017-03-13 22.18.32

The next step was setting up the initial design on a breadboard. Above is an Arduino Pro Mini, four pushbuttons wired to the digital pins, and the HM-10 BLE module. I decided to use the HM-10 because of the lower power requirements (BLE being an initialism for Bluetooth Low Energy). The code for the Arduino reads the values from the digital pins and prints out eight characters to signify which buttons are pressed (‘1’ for unpressed and ‘0’ for pressed). Right now I’m using a byte for each button which is wasteful, so I’ll go back at some point in the future and make the code more efficient so each button is represented by a bit.

2017-03-14 22.50.16

Once everything was wired up and running I had a lot of trouble finding an app that could connect to the HM-10 as a serial terminal. Apparently the BLE standard has a lot of bells and whistles that make configuration a bit more difficult. After trying several different apps I eventually found Serial Bluetooth Terminal which can connect to both BLE and regular Bluetooth devices via a serial terminal. Above is screenshot of my phone connected to the controller with the button status being transmitted.

2017-03-14 20.31.24

2017-03-14 20.31.37

With my proof of concept working, I soldered everything onto a proto-board, this time with eight buttons to serve as a D-pad and four action buttons.

With that complete the next step was connecting to the Raspberry Pi over a serial terminal. Unfortunately, this was much more difficult than I expected. I could pair and connect to the HM-10, but couldn’t find a way to mount it as a serial terminal.

2017-03-15 21.01.17

Rather than continue further down the rabbit hole, I decided to drop the BLE module for now and switch to the HC-05 modules I bought as a backup. Those have been around for years and have been used extensively with Arduino and Raspberry Pi. Once that module was paired and connected, mounting it as a serial terminal was as simple as using the following commands to connect and then print out the values read from the module:

sudo rfcomm bind /dev/rfcomm0 <MAC Address>
sudo cat /dev/rfcomm0

2017-03-17 19.20.25

2017-03-17 22.01.22

Lastly I connected the controller, screen, and Raspberry Pi to battery packs and verified everything still worked as suspected. Success! The next step is writing a program for Linux that reads the button data coming off the serial port and uses it to emulate a controller for the console.

PiGRRL Switch: Choosing the Screen

April 12, 2017April 12, 2017 kelliott121 Projects

The centerpiece of any tablet or in the Switch’s case tablet-thingie, is the screen. Therefore, that seems like the best place to start my PiGRRL Switch design. But first, a brief list of the Switch’s display specs:

Size: 6.2 inches
Resolution: 1280×720
Type: LCD

Now the Raspberry Pi has a wide array of compatible screens, but unfortunately I’ve been unable to find a 6 inch one to match the size of the Switch. However, there are an abundance of 5 inch and 7 inch screens. This effectively means that my console display will have to be either larger or smaller than the Switch.

The 5 inch display I was looking at was from Elecrow with a resolution of 800×480. However, after looking at the dimensions of the display, it looks like it’s only slightly larger than the Raspberry Pi. This would require me fitting the supporting electronics (e.g. HDMI splitter, battery, etc.) into a small space. After the space concerns I ran into on my Raspberry Pi Tablet, I have no doubt I won’t be able to do this. So with that it mind, I decided to go with the larger, 7 inch display.

The two 7 inch displays I considered were Elecrow’s 7 inch display with a resolution of 1024×600 and Chalk-Elec’s 7 inch HD display with a resolution of 1280×800. I’ve used Chalk-Elec’s 10 inch display before for my tablet/oscilloscope project and was completely satisfied with it, but at two times the cost of Elecrow’s display I decided to go with the lower resolution. The highest resolution console of the first five console generations was the N64 with a output capability of 480i (or 576i for PAL regions). This means the 1024×600 resolution is more than capability of properly displaying any games I might want to play.

Because the screen input requires a specific resolution, the Raspberry Pi’s configuration file needed to be modified. I used this site as a guide. I added the following lines to /boot/config.txt

max_usb_current=1
hdmi_group=2
hdmi_mode=87
hdmi_cvt 1024 600 60 6 0 0 0

These lines increase the current to the USB peripherals and configure the HDMI to output the exact resolution required by the display.

PiGRRL Switch

April 5, 2017April 5, 2017 kelliott121 Projects

So keeping in line with my general theme of “anything big companies do, I can do worse” I’m going to attempt to make a retro game console stylized after the Nintendo Switch. Building a retro console is something I’ve wanted to do for a while now, but I’ve never gotten farther than a bare Raspberry Pi running RetroPie. Making this project would give me a retro console like I’ve wanted with some of the features provided by the Nintendo Switch. Another reason I wanted to do this project is because it’s been so long since I’ve done any high level programming or Linux development. With OpenADR moving away from Linux, this project will be a refreshing change of pace, a chance to brush up on old skills, and an opportunity to learn more.

And luckily for me, there are a ton of great resources that I can utilize for my build. RetroPie already has a great emulation console and interface with tons of users. Additionally, what I’m doing will be heavily based on Adafruit‘s PiGRRL. A lot of the design, programming, and resources are already there, I just need to remix them for what I’m trying to do.

Primary Goals

The main goals of the project are as follows:

For the Console:

Portable
Docking station for playing on the TV
Compatibility with a wide array of games (1st gen through 5th gen)
Enough resolution to do compatible games justice
Speaker(s) for sound in portable mode
WiFi and Bluetooth connectivity
USB charging
>= 2 hours of battery
Up to four players
Touchscreen

For the Two Controllers:

Easy to connect and disconnect from console
Wireless
1x D-pad
4x action buttons
Usable as a single controller or two separate controllers
>= 2 hours of battery
USB charging

Secondary Goals

The less important goals of the project are as follows:

For the Console:

High quality stereo audio
>= 4 hours of battery

For the Two Controllers:

Analog sticks instead of a D-Pad
Chargeable via console
Controller mount with external battery
Controller mount with wireless audio
>= 4 hours of battery
Bluetooth Low Energy
Easy way to dynamically switch controller configurations

Tertiary Goals

Some “nice to haves”:

For the Console:

>= 6 hours of battery

For the Two Controllers:

Accelerometer support
>= 6 hours of battery

Alien Clock: Finally Finished!

March 27, 2017March 23, 2017 kelliott121 Contests, Projects 3D Printing, Props, robotics

And with everything assembled the project is finished! There was a small amount of coding involved, but it was pretty simply and mostly self explanatory. The Arduino sketch can be found here on my GitHub. It’s really just a combination of the Arduino ToneMelody example, Adafruit DS1307 example, and my custom L9110S llibrary that I wrote for OpenADR. And without further ado, the final video!

Alien Clock: Putting it All Together

March 26, 2017March 23, 2017 kelliott121 Contests, Props Props, robotics

Facehugger

I hot glued the clock mechanism into its place on the back of the Facehugger. The Facehugger won’t be too tight against the face so the dial will still be reachable.

With the mechanism in place, I just had to slight the hands onto the shafts protruding from the center hole.

Unfortunately the addition of the mechanism didn’t leave space for Kane’s nose, so it had to go.

And lastly the Facehugger was attached! The legs provide a pretty good grip when bent around the head but for additional security I drove a metal rod partway through the mannequin’s head and hung Facehugger on the protruding bit.

Chestburster

I cut a hole in the duct tape roughly where the Alien juvenile burst from Kane’s chest in the movie.

I used a combination of foam-core board and cardboard to give the bottom of the mannequin shape. I also 3D printed holders for PVC piping to make a structure to hold the Chestburster mechanism.

The final Chestburster mechanism mounted to the base.

The mounted electronics consist of a Sparkfun Redboard, L9110S motor controller, and DS1307 RTC.

Lastly was to cut a hole in the shirt so that the Chestburster was mostly concealed but not restricted in movement.

Alien Clock: Updated Chestburster Mechanism

March 25, 2017March 22, 2017 kelliott121 Contests, Props 3D Printing, Props, robotics

As mentioned in my post on the Chestburster mechanism, the two motors aren’t mechanically linked, causing a problem where one motor would crawl ahead of the other. To play it safe, I devised a method of avoiding this problem. I reprinted a few of the parts and added 2mm steel rods to act as guides for the motor carriage.

The metal rods are attached to the ends of the whole mechanism.

The rods are threaded through wings on the carriage to keep it straight.

And here’s a pic of the new assembly.

Alien Clock: Painting All the Things!

March 24, 2017March 22, 2017 kelliott121 Contests, Projects 3D Printing, DIY, Props

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.

Facehugger

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.

Chestburster

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!

Mannequin

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

March 23, 2017March 22, 2017 kelliott121 Contests, Props DIY, Props

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

March 22, 2017March 22, 2017 kelliott121 Contests, Props DIY, Props

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.