Author: kelliott121

Alien Clock: Extending the Clock Hands

kelliott121 Contests, Props ,

Despite the modifications I made to the Facehugger (adding a cutout for embedding the clock mechanism), the shaft of the mechanism doesn’t quite reach all of the way through.

IMG_0844.JPG

 

To remedy this, I attempted to design two nested tubes to extend the minute and hour shafts, which were 3.5mm and 5mm respectively, through the 8mm hole in the Facehugger. On top of these tubes I added keys so that the hands that came with the clock could still be used. Unfortunately, printing nested tubes accurate to 0.05mm while only 3mm thick, all with a 0.4mm nozzle is almost impossible.

IMG_0845.JPG

 

Above is a picture of the outer tube that extended the hour shaft. It doesn’t look too awful, but some intense boogering is visible on the right side. This part is the key that would go in the original hour hand. The minute hand didn’t turn out so well and was essentially one long 3D print blob. I briefly looked into buying a precision 0.2mm nozzle for my Printrbot, but with the ceramic tips currently out of stock I had to think up another way.

IMG_0848.JPG

 

So keeping the trouble I had in mind, I reprinted the Facehugger with a 20mm diameter hole for the clock shaft instead of the original 8mm.

Then, taking advantage of the larger diameter, I designed wider extender shafts (19mm for the hour hand and 14mm for the minute hand). I was also able to make the walls of the shaft thicker, giving the printer more space to accurately print the piece. I also decided that, rather than reusing the hands provided with the clock mechanism and having to design an adapter from the extender shaft to the keyed holes in the hands, I’d design my own that were more in line with the aesthetic of the clock.

alien-xenomorph-movie-a

 

Using the grown Xenomorph tail as inspiration, I designed both clock hands.

img_0836.jpg

IMG_0837.JPG

 

 

As visible above, the Xenomorph tails look fairly accurate and fit perfectly! Because the 3D printed clock hands were roughly twice as heavy as the thin metal ones that came with the clock, I was a little worried that the clock wouldn’t have enough torque to lift the hands. However, after some brief testing, the clock doesn’t seem to have any trouble with the heavier hands.

Alien Clock: Working Cuckoo Mechanism

kelliott121 Contests, Props , ,

The cuckoo mechanism is done, and it works! Below is a description of each of the printed pieces and a video of the mechanism in action.

 

IMG_0804.JPG

The main pieces are the four racks and the motor carriage. The racks provide a linear channel for the pinions to crawl along. The motors are mounted into the carriage with the four pinions on the two motor shafts.

IMG_0822.JPG

The four racks are mounted together with the backstops facing outwards. This serves to contain the pinions so they’re incapable of derailing.

IMG_0821.JPG

 

The carriage with the two motors mounted.

IMG_0823

 

The 3D printed parts and motors assembled.

IMG_0824.JPG

 

The entire assembly. I used a wooden dowel that I had on hand to hold the Chestburster and fit into the carriage.

Above is a demo video of the Chestburster actuating. I’m controlling it with an L9110s motor controller to get the required bidirectional motion. Mounted limit switches are visible on top of the assembly glued on the top racks. These currently aren’t wired to anything but would serve as a way for the Arduino to detect that the end of travel has been reached so it knows to stop sending current to the motors. Right now, however, I’m just using delays to run the motor approximately long enough to hit the end stops.

I’m considering keeping the setup like this and not using the limit switches at all. The travel distance is so short, and the time it will be running is so infrequent, that I think the simplicity of not having to use the limit switches would be worth the slight increase in the wear-and-tear on the motors due to stalling out. Another reason I’m considering this is because the limit switches may not match up perfectly with end of travel. Something I didn’t address in my mechanism was the mechanical linkage of the two motors. Because they’re not directly coupled, it’s possible for one motor to operate slower than the other, thereby causing the carriage to misalign and one motor be closer than the limit to the other. Applying current when one motor is at the end of travel limit would cause the faster motor to stall, but would give the slower motor a chance to catch up and resynchronize.

Alien Clock: Cuckoo Mechanisms

kelliott121 Contests, Props , ,

A cuckoo clock wouldn’t be very interesting if something didn’t pop out at the top of the hour. The obvious choice here is for the Chestburster to act as the cuckoo. This requires some form of linear motion to attain. I briefly entertained the idea of buying a linear actuator but couldn’t find anything that was the right speed and price.

So the alternative was using regular rotary motors and designing a rotary-to-linear motion converter. Luckily I have a whole drawer full of cheap DC motors from my work on OpenADR. Next, linear motion is a well-documented subject so designing a converter couldn’t be that hard, right?

As it turns out, it can. I am by no means a mechanical engineer. My degree and job are in computer/software engineering, so I had a great deal of trouble designing a linear mechanism I was satisfied with. I also wanted to avoid complex control electronics, so I wanted a design that produced reciprocating motion. This would let me to use a basic MOSFET to control the motor in a single direction along with a limit switch to detect a full stroke from the cuckoo.

Naturally, I chose to use a piston mechanism, most commonly used in cars to convert linear motion to rotary motion. The motor turns a linkage arm which then forces the piston (in my case the Chestburster) up and down a guide channel. The direction the motor is spinning doesn’t matter and a limit switch at the bottom of the guide would detect when the piston is fully retracted.

output_3OVD0f

I got as far as designing the whole mechanism for 3D printing before deciding to scrap the it. The large number of linkages added unnecessary complexity and I was worried about the arms bending or snapping. Additionally, with the length of the guide added to the lengths of the arms, the whole mechanism was too long to fit in the depth of a human sternum and therefore the mannequin.

output_dDBKaj.gif

My next thought was to use a Scotch yoke mechanism. It’s much simpler, shorter, and wouldn’t require multiple axles to be added for assembly. The red part at the bottom of the design is a telescoping tube assembly to help reduce the depth of the design. I got as far as printing and assembling the mechanism (minus the telescoping tubes). Unfortunately, the design broke pretty much right out of the gate. The slot in the yoke requires low friction to work properly and the friction of the PLA on PLA proved too much. The axle going in the slot snapped off far too easily.

output_Ndksjq.gif

So with my previous two attempts failing, I decided to eschew reciprocating motion for something simpler. I have a few spare L9110s motor controllers and can afford to use one if it makes the mechanical design easier. So I opted for a rack and pinion system. This is essentially just a linear gear being driven by a rotary gear. By mounting the motors on the carriage within four racks, simple and constrained linear motion is achieved. This also allows for the depth of the mechanism to be equal to the height of the Chestburster. There are also plenty of rack and pinions available on Thingiverse and so I found one to use for my system.

Alien Clock: 3D printed parts are done!

kelliott121 Contests, Props , ,

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

IMG_0806_small.JPG

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.

IMG_0820.JPG

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

kelliott121 Contests, 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

kelliott121 Projects, Techniques ,

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

kelliott121 Contests, Projects , , ,

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.

 

OpenADR: Esp32 Initial Test

kelliott121 Projects , ,

As I mentioned in a previous post, I’m attempting to test the ESP32 as a cheap replacement for my current Raspberry Pi and Arduino Mega setup.  I’m hoping that doing this will save me some complexity and money in the long run.

Unfortunately, with the ESP32 being a new processor, there’s not a lot of Arduino support implemented yet.  Neither the ultrasonic sensor or the motor driver libraries compile yet due to unimplemented core functions in the chip library.

Luckily a new version of the ESP-IDF (IoT Development Framework) is set to be released November 30,with the Arduino core most likely being updated a few days later.  This release will implement a lot of the features I need and so I’ll be able to continue testing out the board.  In the mean time I plan on adding more sensors to the Navigation Chassis v0.3 in preparation, as well as working on some other projects.

OpenADR: New Controller Options

kelliott121 Projects , , ,

One of the reasons for my hiatus from OpenADR is due to some uncertainty when it comes to the main processor for the robot.  My current implementation uses a Raspberry Pi for general control and data logging with an Arduino Mega handling the real-time code.  However, these two boards result in a combined price of $80 ($35 for the Raspberry Pi and $45 for the Arduino).  Requiring these parts would make the total cost of the navigation chassis much higher than I’d like.  These parts might also make it more difficult to manufacture OpenADR if I ever decide to turn it into a product.  While I could always create a custom board based on the Arduino Mega, the Raspberry Pi isn’t exactly manufacturing-friendly.

These reasons are why I’m exploring alternative options for the main controller for OpenADR and through my research I’ve discovered two options that I’m pretty excited about.  Both the C.H.I.P. Pro and ESP32 are powerful processors that could potentially be used for OpenADR, with the former being similar to the Raspberry Pi and the latter being closer to an Arduino.  Below is a comparison of specs and a description of how they could be used.

C.H.I.P. Pro

The C.H.I.P. Pro is an embedded Linux module produced by Next Thing Co. and is advertised as a solution for products requiring embedded Linux.  It has onboard WiFi and Bluetooth, and has an ARM Cortex-A8 processor with 256MB or 512MB of RAM running at 1GHz.  An added benefit is the Gadget ecosystem that Next Thing Co. announced.  They haven’t released too many details, but the impression I got is that it’s a Linux package that allows for easy and secure updating of products running on the C.H.I.P. Pro system.  My expertise starts to fuzz when it comes to product software management, and I know very little about security, so having an ecosystem that would make this easier would help me a lot.

One possible downside is that embedded Linux isn’t always good enough for real time applications.  While the board might have enough GPIO to connect to the robot’s peripherals, they might not be able to update outputs and read data fast enough for what I need the robot to do.  For example, any timing delays in the reading of the ultrasonic sensors could lead to incorrect distance data that would inhibit the robot’s ability to understand and map its environment.  This is something I can experiment with when I receive my development kit.

ESP32

The ESP32 is the other side of the embedded systems coin.  It doesn’t run Linux, but instead uses a Tensilica LX9 microprocessor with 520KB of RAM running at 240MHz.  It also has WiFi and Bluetooth built-in.  The plus side of a bare metal system is that there’s less concern about delays and real time control with the robot’s peripherals.  The downside is that this makes it much harder to write software for the robot.  A lower level language would need to be used and without Linux or the features of a more powerful processor, certain features, such as real time data logging, may be harder to manage and implement.

While different processor architectures aren’t always directly comparable, the ESP32 does run a 15x the speed of the Arduino Mega I’ve been using so far.  So while it might not be able to compete with a Raspberry Pi or C.H.I.P. Pro in terms of data processing, it’s way more powerful the Arduino and it will probably still be possible to implement the more complex features.  I currently have SparkFun’s ESP32 Thing development board on my desk and look forward to testing it out with OpenADR!

 

HAL 9000: Wiring

kelliott121 Projects , , , ,

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.