PiGRRL Switch: Creating the Controllers

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.

Advertisements

PiGRRL Switch: Choosing the Screen

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

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!

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: 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.

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.

IMG_0857.JPG

IMG_0858

IMG_0859.JPG

IMG_0871.JPG

IMG_0873.JPG

 

 

 

 

 

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!

IMG_0855

IMG_0856

IMG_0869.JPG

 

 

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).

IMG_0841.JPG

IMG_0842.JPG

IMG_0853.JPG

 

 

 

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.

IMG_0836

IMG_0843.JPG

IMG_0846.JPG

 

 

 

3D Printed Sword: Build

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.

img_0723

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.

img_0724

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.

img_0730

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.

img_0727

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.

img_0728

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

img_0733

img_0729

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.

img_0734

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.

img_0792

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.

IMG_0903

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.

IMG_0902

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

IMG_0914

IMG_0916

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!

OpenADR: Mop Module v0.1

For the sake of design simplicity and ease of assembly, the mop module is broken up in to two main parts based on the module base design.  The front of the module (the 150mm^2 square) is devoted almost entirely to the water storage tank and the rear is where all of the electronics and mechanics are.

IMG_0636

The picture above is a failed print of the front part of the mop module.  Rather than just tossing this piece, I ended up using it to test out the waterproofing capability of the XTC-3D print sealant.  It ended up working perfectly.

Despite the failed nature of the above print, it still demonstrates the main sections of the front of the mop module.  The main water tank is bounded by two walls, the left in the picture being the back wall of the water tank and the right wall being the front.  The small gap between two walls on the right side of the picture is the location of some holes in the base of the module that will allow for the water to be evenly dripped onto the floor.

IMG_0638

This bottom view of the part gives  a better view of the holes

IMG_0639

Two holes in the back of the water tank provide an input to the pumps.  Because combining electronics and water is a big no no, I added some holes in the bottom of the module so that any leaks around these holes would drip onto the floor rather than flooding the electronics section.

IMG_0640

This is the back of the mop module where all of the magic happens.  The holes in the bottom provide mounting points for the two motors that will drive the pumps.

IMG_0641

The two pillars in the very back provide a point to mount the base of the pump.

IMG_0644

The two, dual-shaft motors have one output shaft extending out of bottom that will be connected to the scrubber and one extending upwards that will be driving the pump.

IMG_0645

A picture of the downwards facing shafts.

IMG_0646

The above picture shows the back of the module with all of the hardware mounted.  Unfortunately, I didn’t give enough space for bolt heads that hold the motor in place.  The pumps can’t pushed down as far as I intended and so they don’t line up with the holes I left in the mounting pillars.  Luckily the mounts are sturdy enough to mostly hold the pumps in place and so I don’t need to mount them for testing purposes.

IMG_0648

These are the two halves the the scrubber that will hold the microfiber cloth that will be used to scrub the floor and soak up excess water.  The two halves are made to be pressed together with the cloth sandwiched in between them.

IMG_0649

This picture shows the cloth and scrubber assembled.  I underestimated the thickness of the cloth, so two won’t currently fit side by side.  I’ll need to either make the cloth smaller or move the scrubbers farther apart.

IMG_0650

Above is an overall picture with all of the pieces put together.