PiGRRL Switch: Test Controller in Action!

June 28, 2017June 28, 2017 kelliott121 Projects Arduino, DIY, Gaming, Nintendo, Python, Raspberry Pi, Switch

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

June 9, 2017June 9, 2017 kelliott121 Projects DIY, Gaming, HID, Python, RetroPie, Switch

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:

	import serial
	from uinput import *

	class Controller:
	"""docstring for Controller"""

	NumButtons = 8

	def __init__(self, devName, devKeys):
	self.devPath = "/dev/" + devName
	try:
	print "Connecting to " + self.devPath
	self.serial = serial.Serial(self.devPath, 9600, timeout=10)
	except Exception as inst:
	print type(inst) # the exception instance
	print inst.args # arguments stored in .args
	print inst
	print "Connection to " + self.devPath + " failed!"
	self.connected = False
	else:
	print "Connection to " + self.devPath + " successful!"
	self.connected = True

	self.devKeys = devKeys
	self.device = Device(devKeys)

	ValidKeys = [ KEY_A, KEY_B, KEY_C, KEY_D, KEY_E, KEY_F, KEY_G, KEY_H, KEY_I, KEY_J,
	KEY_K, KEY_L, KEY_M, KEY_N, KEY_O, KEY_P, KEY_Q, KEY_R, KEY_S, KEY_T,
	KEY_U, KEY_V, KEY_W, KEY_X, KEY_Y, KEY_Z,]
	ControllerNames = ["rfcomm0"]

	Controllers = []

	controllerNum = 0
	for controllerName in ControllerNames:
	Controllers.append(Controller(controllerName, ValidKeys[controllerNum:((controllerNum*Controller.NumButtons) – 1)]))
	Controllers[controllerNum].serial.reset_input_buffer()
	controllerNum = controllerNum + 1

	PrevPacket = {}
	PrevPacket['K'] = '1' * Controller.NumButtons

	while True:
	controllerNum = 0
	for controller in Controllers:
	line = controller.serial.readline()
	print line

	packet = line.split(':')
	if packet[0] == 'K':
	charNum = 0
	for char, prevChar in zip(packet[1], PrevPacket['K']):
	if (char == '0') and (prevChar == '1'):
	controller.device.emit(controller.devKeys[(controllerNum*Controller.NumButtons) + charNum], 1)
	elif (char == '1') and (prevChar == '0'):
	controller.device.emit(controller.devKeys[(controllerNum*Controller.NumButtons) + charNum], 0)
	charNum = charNum + 1
	PrevPacket['K'] = packet[1]
	elif packet[0] == 'A':
	pass
	elif packet[0] == 'B':
	pass

	controllerNum = controllerNum + 1

view raw

ControllerServer.py

hosted with ❤ by GitHub

	class Controller:
	"""docstring for Controller"""

	NumButtons = 8

	def __init__(self, devName, devKeys):
	self.devPath = "/dev/" + devName
	try:
	print "Connecting to " + self.devPath
	self.serial = serial.Serial(self.devPath, 9600, timeout=10)
	except Exception as inst:
	print type(inst) # the exception instance
	print inst.args # arguments stored in .args
	print inst
	print "Connection to " + self.devPath + " failed!"
	self.connected = False
	else:
	print "Connection to " + self.devPath + " successful!"
	self.connected = True

	self.devKeys = devKeys
	self.device = Device(devKeys)

view raw

ControllerServer0.py

hosted with ❤ by GitHub

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.

	ValidKeys = [ KEY_A, KEY_B, KEY_C, KEY_D, KEY_E, KEY_F, KEY_G, KEY_H, KEY_I, KEY_J,
	KEY_K, KEY_L, KEY_M, KEY_N, KEY_O, KEY_P, KEY_Q, KEY_R, KEY_S, KEY_T,
	KEY_U, KEY_V, KEY_W, KEY_X, KEY_Y, KEY_Z,]

view raw

ControllerServer1.py

hosted with ❤ by GitHub

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.

ControllerNames = ["rfcomm0"]

view raw

ControllerServer2.py

hosted with ❤ by GitHub

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.

	Controllers = []

	controllerNum = 0
	for controllerName in ControllerNames:
	Controllers.append(Controller(controllerName, ValidKeys[controllerNum:((controllerNum*Controller.NumButtons) – 1)]))
	Controllers[controllerNum].serial.reset_input_buffer()
	controllerNum = controllerNum + 1

view raw

ControllerServer3.py

hosted with ❤ by GitHub

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.

	PrevPacket = {}
	PrevPacket['K'] = '1' * Controller.NumButtons

view raw

ControllerServer4.py

hosted with ❤ by GitHub

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.

	while True:
	controllerNum = 0
	for controller in Controllers:

	#…
	controllerNum = controllerNum + 1

view raw

ControllerServer5.py

hosted with ❤ by GitHub

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

	line = controller.serial.readline()
	print line

	packet = line.split(':')

view raw

ControllerServer6.py

hosted with ❤ by GitHub

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.

	if packet[0] == 'K':
	#…
	elif packet[0] == 'A':
	#…
	elif packet[0] == 'B':
	#…

view raw

ControllerServer7.py

hosted with ❤ by GitHub

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

	charNum = 0
	for char, prevChar in zip(packet[1], PrevPacket['K']):
	if (char == '0') and (prevChar == '1'):
	controller.device.emit(controller.devKeys[(controllerNum*Controller.NumButtons) + charNum], 1)
	elif (char == '1') and (prevChar == '0'):
	controller.device.emit(controller.devKeys[(controllerNum*Controller.NumButtons) + charNum], 0)
	charNum = charNum + 1
	PrevPacket['K'] = packet[1]

view raw

ControllerServer8.py

hosted with ❤ by GitHub

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!

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.

Alien Clock: 3D printed parts are done!

March 18, 2017March 17, 2017 kelliott121 Contests, Props 3D Printing, DIY, Props

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

March 17, 2017March 17, 2017 kelliott121 Contests, Props 3D Printing, Arduino, DIY, Props

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.

3D Printed Sword: Build

March 11, 2017 kelliott121 Projects, Techniques 3D Printing, DIY

Printing

Material

The filament I decided to use was silver Hatchbox PLA. After printing the coloring of the plastic turned out more of a shiny gray than a silver. While I knew I was going to paint the sword anyway, I wanted a grayish base color so that the color of the filament wouldn’t show through. Plus, if the sword ever gets scratched, the dull gray scratch color will look more realistic.

Settings

My biggest concern for the printed parts used for the sword was the strength, specifically the strength between print layers. This was most critical on the blade of the sword, due to its length and weight providing a lever arm that could cause the prints to snap. Additionally, due to the way I decided to print out the blade, speed became an issue. I oriented the sword segments so that the blade was divided along the X-Y plane. This meant that the longest axis was in the Z direction. The Z-axis is also commonly the slowest on a 3D printer, mainly because a leadscrew is usually used. To compensate for all of these design concerns, I tried to find an optimal balance between weight, strength (particularly layer adhesion), and print time.

After reading numerous studies and suggestions, I decided on a layer height of 0.3mm and width of 0.4mm. I also ran the hotend a little on the hotter side at 210C. Because I planned on sanding and finishing, allowing for a little stringing (a common result of too-high hotend temperature) was well worth the added strength and layer adhesion it provided. I also kept the infill a little low at 10% so the blade wouldn’t be too heavy.

The 18 50mm segments of the blade are shown above. They turned out pretty good with minimal stringing. One noticeable feature on the outside of the blade segments are the vertical lines. These are caused by interaction between the internal hole perimeters and outside perimeters. There’s isn’t enough space for both sets of perimeters and so some external artifacts are present on the outside. Luckily these can be easily hidden by the finishing process.

The two halves of the pommel didn’t turn out as well as I’d hoped. Because I printed with the center of the pommel on the bed, there wasn’t enough support for the circular arch that would hold the grip. This can hopefully be fixed with some sanding and finishing. Also shown above is the hole that the blade will be glued into.

Lastly are the grip and pommel. The grip was printed in two halves and held together by a metal spine. Three 2mm holes were extended through the length of the grip so the pommel and blade could both be securely attached.

Assembly

The majority of the build time was spent assembling the blade, because it’s the most complex part. I used cyanoacrylate glue (super glue) due to it’s good adhesion to PLA. The brand I used was also labeled as “gap filling.” I figured this would be useful if the tops and bottoms of the blade segments were slightly warped or didn’t match up properly.

I also used a metal spine to prevent stress on the glue joints and provide additional strength to the blade. Due to the metal pieces only being 300mm long, I trimmed the rods so that, when transitioning from one rod to another, the joint is in the center of a blade segment.

I was able to fit three metal spines at the wider base of the blade.

I cut the metal rods so that a decent portion would protrude from the bottom. These extra length could then be used to mount the blade to the grip.

With the pieces all glued together, the next step was coating it!

Finishing

The process of finishing the blade was divided into three main parts, coating, sanding, and painting, with an additional step of leather wrapping the grip. These steps weren’t terribly difficult, but nevertheless the finishing took a long time, with each step requiring patience.

Epoxy Coating

This slideshow requires JavaScript.

The first step in finishing the sword involved coating the plastic in epoxy. The brand I used was XTC-3D. It works like most epoxy, involving mixing the two parts together to get a rapidly curing mixture. I then had about five minutes before the epoxy hardened to brush it on to the plastic. After this was a four hour wait for the epoxy to finish curing. Once completely hardened, the epoxy left a hard, clear coat over the plastic. This had the added benefit of adding more strength to the plastic by holding together the print layers and separate parts. Because I planned on sanding the pieces anyway, I used an excessive amount of epoxy when coating, as is evident by the visible epoxy drips.

Because I had to apply the coating two each side of the blade separately, I had to wait four hours between each half. I also wanted to apply three coats to the blade. What resulted from this was the week long process of coating the blade because I only effectively had time for one half of a coat once I had gotten home from work.

Sanding

This slideshow requires JavaScript.

The next step was sanding down the epoxy coating to a smooth, metal-like surface. This was by far the most tedious process. I initially bought plain sandpaper and started the process of sanding everything down by hand. As I soon realized, this was a profoundly terrible idea and would have taken forever. I shortly gave up and bought a random orbit sander. The benefit of the “random orbit” was that no directional sanding lines would show up on the finished piece, and so the sword would look uniformly smooth, just like actual steel.

New toy in tow, I forged (pun intended) on with the process of smoothing out the pieces of the sword. I started out by using 80 grit sandpaper to sand the flat surfaces of the blade entirely flat, and then slowly worked my way through 150, 220, 320, 400, and 600 grit sandpapers. These left me with an incredibly smooth surface that was ready for painting.

One downside of the sanding that I noticed was that the vibrations caused some of the superglued joints to come undone. Both the pommel and a piece of the blade had to be reglued. The blade one actually happened after painting and was difficult to repair.

Painting

This slideshow requires JavaScript.

The last step was painting everything. This was the simplest step, but was still time consuming due to having to wait for each coat to dry before flipping over the sword to paint the other side. I spray painted each of the pieces separately with silver spray paint, with several coats for each piece.

Leather Wrapping

This slideshow requires JavaScript.

As a bonus step, I decided to wrap the hilt in leather to add a nice touch to the finished product. I cut the leather roughly to size stretched it out a bit, then superglued one edge to the grip. I specifically left the grip unpainted so that the glue would have a stronger hold on the plastic part. I then tightly wrapped the leather around the octagonal grip, applying glue on each face.

Failings

While I’m fairly happy with how the finished product turned out, there are two things that didn’t turn out as I’d hoped. Mainly the stiffness of the blade was lacking and joints between blade segments couldn’t handle the stress of the finishing process.

Stiffness

While the PLA is stiff enough to prevent significant bending, the metal rods have a certain flexibility that allow some give at the inter-blade joints. As a result, the blade is more flexible than I’d like. I had to handle the sword very carefully for fear of the joint bending causing the blade to crack or break. If I attempt a repeat of this project, or something like it, I’ll have to consider a fix for this.

One option would be to use a different type of joint. The current, flat joint that I’m using allows for some space between the segments where the metal rods can bend. If I had used some type of overlapping joint it’s possible that the flexibility would have been reduced.

Another alternative would be to use a stiffer material for the blade spine. Something like carbon fiber rods would be much hopefully be much stiffer. The only concern with this would be the lack of flexibility putting more strain on the glue joints between segments.

Cracking

The biggest issue I had was with the blade segment joints not being strong enough to withstand the finishing process. Specifically the vibrations from the sander caused the joint adhesion to fail in one particular spot.

Near the top of the blade, where the cross section of the blade was small and only one spine held the segments together, the glue joint repeatedly failed.

At first I reapplied both the glue and the epoxy coating and sanded it down again. However this caused a second failure, at which point I gave up and just used a lot of super glue and some light sanding. Fortunately the poor finish isn’t too noticeable at a distance.

Another part of the blade partially cracked towards the bottom. Some of the epoxy came out between the blade segments leaving a slight crack. Because spray paint is so thin, it was unable to hide this defect.

I think the only solution to the strength problem would be to change the way I’m joining the segments since the superglue doesn’t seem to be strong enough. Two different methods I could use would be heat or friction welding when using PLA, or solvent welding when using ABS. These methods would hopefully make the whole blade into one cohesive unit.

Another possible option would be to use a different kind of paint. I used spray paint which is thin by necessity and has trouble hiding defects. Using a thicker, brush-on paint would have done a better job hiding the cracks that popped up.

Finished Product

Despite the issues I had I’m mostly happy with the finished product. Unfortunately not all projects can be resounding successes, but I learned some new techniques and have a nice decoration for my office now!

HAL 9000: Wiring

November 10, 2016 kelliott121 Projects alexa, amazon echo, DIY, home automation, Raspberry Pi

BOM

Wiring

This slideshow requires JavaScript.

With the Raspberry Pi as the centerpiece, I went about connecting everything together. The first step was wiring up the sound. I took a stereo audio cable plugged into the Raspberry Pi’s audio port and wired each of the left and right channels into its own amplifier. The power and ground of both amplifiers was sourced from the Raspberry Pi’s 5V and GND pins on the GPIO header. I then wired the outputs of one of the amplifiers to the speaker. The outputs of the other amplifier were wired to the LED in the button. By doing this, the light inside of HAL’s eye would flash in sync with the audio being played. Aside from that, all that was left to do was plug in the USB microphone and I was done. One optional addition I might make in the future is wiring up the inputs of the button. This would provide the possibility to activate Alexa via means other than the wake word.

HAL 9000: Alexa Install

November 10, 2016 kelliott121 Projects alexa, amazon echo, DIY, home automation, Raspberry Pi

I originally thought this blog post was going to be a lengthy explanation of how to install the Alexa software (found here) on the Raspberry Pi 3 with all of the caveats, tweaking, and reconfiguration necessary to get the software to install. Any Linux user who frequently installs software from source knows that the time it takes to get some software to compile and install is exponentially proportional to the complexity of the code and the compile time. This is not the case here.

It did take roughly an hour to run the automated install script provided in the Alexa repository, but once that had completed everything ran almost perfectly right out of the box. I’m utterly floored by this, and am incredibly impressed with the Alexa development team on the quality of their software project. So really, if this is something you’re interested in doing, use their guide to set up everything. All you really need is a Raspberry Pi 3, a microphone (I used this one), and a speaker (I used one from Adafruit which I’ll discuss in detail in my post on wiring). The only thing I had to tweak was forcing the audio to be output on the 3.5mm jack using raspi-config and selecting the jack in Advanced Options->Audio.

And without further ado, my working example.