A HAL 9000 replica has been on my “to make” list since Adafruit started stocking their massive, red arcade button. They even created a tutorial for building a HAL replica! When the Alexa developers added support for a wake word last month, I knew I had to build it. Rather than simply playing sound effects with the Pi, I wanted to include Amazon’s new Alexa sample that allows to run the Amazon Echo software on the Raspberry Pi 3. Always a fan I tempting fate, I thought the HAL replica would be the perfect container for a voice assistant that has access to all of my smart home appliances. What could go wrong?
After OpenADR was not selected as a finalist in the Hackaday Prize Automation Challenge, I decided to take a brief break from working on the vacuum after working in full-fledged competition mode for the previous few months. I spent a few weeks trying to think up simple projects that would keep me occupied but wouldn’t take up too much of my time. I also wanted to use this time in between big projects to develop new skills and get outside of my comfort zone a little bit with a project that I wouldn’t normally pursue. At last, inspired by the wide array of medieval props I saw at the Pittsburgh Renaissance Festival, I decided to 3D print a medieval longsword and attempt to make it as realistic as possible.
While 3D printed parts certainly aren’t new territory for me, designing a realistic weapon really pushed me to think through challenges that I had not encountered before. Creating large and unwieldy objects using FDM introduces new constraints in terms of printability and strength. When creating my own parts from scratch, I have a lot of flexibility and can design pieces while keeping in mind the limitations of 3D printing . For this project though, I had to rethink the design process to make printing possible because I was trying to replicate something that (1) exists in the real world and thus should look a certain way and (2) wasn’t designed to be easily 3D printed. Strength is also a concern as 3D prints are notoriously weaker than regular, injection-molded plastic parts and can delaminate when too much stress is applied across the Z-axis. I wanted the sword to be as realistic as possible (i.e., long and pointy), so keeping the sword sturdy without too much bending was also a big priority.
In addition to the 3D printing structural challenges, appearance was also a big concern – this too is where I wanted to push myself. It isn’t easy to pass off a plastic part as metal given the differences in texture and shine. Furthermore, given the size of the sword, I had to print the blade in segments, and so finding a way to smooth out the joints was a significant problem in addition to the normal visibility of layer lines. Just designing, printing, and assembling the blade (a.k.a. all the things I already knew how to do!) was the easy part – the bulk of the work was in the finishing stages of making the sword look realistic.
I started this project by researching the general properties of longswords. I spent a lot of time looking at modern replica swords, movie swords, and historic swords from the middle ages so I could get a good idea of what I wanted my own sword to look like. Two great references that I found were the Wikipedia page for longsword and the website My Armoury, which has more history, mechanics, and specifications of medieval weaponry than you could ever possibly need.
From those resources, I determined that I wanted a sword, roughly 1.1-1.2m in length, with a blade about 90cm long, 5cm wide, and 5mm thick. In additional to the dimensions I also wanted accurate blade geometry. This required me to read up on blade cross sections, profile tapering, and distal tapering. I also decided to print out the sword in PLA due to its stiffness and ease of printing.
My primary concern, at first, was the thickness of the blade. While PLA is stiffer than ABS, it is still pretty bendy when it comes to a meter long part that’s only 5mm thick. PLA is also brittle so it wouldn’t take much bending to snap the blade. To alleviate these concerns, I decided that the blade should have steel rods at its core. I still had plenty of 2mm x 300mm steel rods that I used as axles for OpenADR, and decided to use these.
The next concern was print geometry. A meter-long blade obviously wasn’t going to fit on my Printrbot, so I needed to determine how to split it up into multiple pieces. The two obvious options were splitting it down the middle lengthwise and printing it in multiple left and right half chunks (left image). Extending this idea, I could have also had the left and right chunks mismatched (middle image) so that it’d be harder for the blade to break along the blue, horizontal lines. The last option would be printing out vertical chunks of blade (right image) without any bisecting along the long axis. For all of the options, I planned on using cut sections of 2mm steel rod to hold the parts together.
I ended up going with the last option for several reasons. My concern with the first two options was warping. A big benefit of bisecting along the long axis was that it would allow me to print out large chunks on the long, 225mm X axis of my Printrbot. However, 225mm is a big 3D print and tends to cause warping, even using PLA. Without the strength advantage of large, sturdy sections there wasn’t much point to the left/right bisection option. I was also concerned about space for the metal spine and connectors in the first two options. While a single 2mm rod fits fine in a 5mm blade, the blade thickness quickly decreases due to the distal taper. It quickly reaches a point where both vertical and horizontal steel rod connectors won’t fit in the blade cross section. With the last option, all I needed to add was a single vertical rod to hold the segments together.
With the mechanical design handled, the next step was the aesthetics. The first thing I tackled was the blade cross section. It seemed like historically, the most common types of blade cross section were lenticular and diamond, with the former being popular in the early middle ages and the latter becoming more popular in the late middle ages. Considering this, I opted for the diamond cross section, thinking that its flat features would be easier to sand later on.
Despite going with the diamond cross section, I still designed both main options. One of my secondary goals for this project was to make everything available in OpenSCAD so others could design and print their own swords, and so I wanted to design the different options as modules in case someone in the future has more patience for sanding than I do. I also included the option for fullers. While I ultimately didn’t include fullers in the blade I made, mainly due to concerns about thickness and strength, they certainly add aesthetic appeal when included.
The next step was designing the actual blade. To help simplify the implemention in code, I mostly based the profile taper of my blade designs on mathematical equations, with one custom option as well. From left to right, the blades shown above were designed as follows:
- A custom blade that has an array of widths passed in. To demonstrate this I went with a sawtooth-like design, but it’s currently extendable out to any design as long as it’s symmetrical across the z-axis. There was no historical precedent for this blade type, but it seemed like a cool option to have.
- An elongated elliptical blade with the ellipse length and width passed in. Historically, this kind of blade provided a good compromise between a cutting and thrusting, allowing a wide blade without sacrificing the sharp point.
- An exponential blade with the width of the blade decreasing exponentially. Again, this didn’t really have any historical precedent, but it was easy to add and has an interesting aesthetic. Without a point, this blade would be no good for thrusting but would provide a good cutting edge.
- A linear blade with the blade tapering to a fine point. Historically this type of blade was used predominantly for thrusting.
For the aesthetics I was looking for, I went with the elliptical blade because I thought it looked like a traditional middle ages longsword. With the width of the blade only tapering off at the very point, it also provided a good amount of structural integrity.
With the entirety of the blade designed, the next step was making it printable. I quickly refactored the design of the blade so that the 90cm blade is broken up into 18 50mm segments. The blade segments were then separated and spread out so as to be printable. I also added ~2mm holes in each segment to allow space for the metal spine. The width and thickness at the bottom of the blade had enough space for three metal spines, which allowed for an increase in stiffness and strength.
I discovered a problem when adding in the spine, however. Originally, I kept the distal taper of the blade the same as the profile taper, so the blade was the top half of an ellipse when viewed across both the X and Y axes. However, while the blade was thick enough to allow for a 2mm hole at the base, this quickly became impossible toward the top of the blade.
To alleviate this, I tripled the width of the ellipse (in terms of blade thickness), but capped the maximum value at 5mm. An exaggerated example of this is shown in the picture above. The blade is constant 5mm thick for the bottom half, but still tapers off at the top. Due to how thin the blade is, this modification is barely noticeable.
One thing to note when looking at my OpenSCAD code is that I only made this printability modification for the elliptical blade. It took some tweaking to get everything configured correctly, and I didn’t want to spend too much time tweaking for blades I had no intention of printing. I might go back in the future to fix this, but for now the printability and segmentation code will have to be ported to the other blade types to print one of the other blades.
With the blade complete, the next step was designing the hilt. The three parts on a traditional, medieval sword are the crossguard, grip, and pommel. I was going to design something elaborate and decorative, but decided I’m no artist, and OpenSCAD doesn’t lend itself well to organic and artistic designs. Instead I opted for more spartan, geometric designs.
The two options in the back were the customizeable options with an elliptical shape in the back and rectangular one in the front. Two arrays are passed into the modules that determine the width and height of the shape from left to right. I liked the custom rectangle shape so much that I went with that design for my final crossguard. The front two options are a flat hilt and curved hilt with pointed edges.
The grip is just a simple octagonal shape that I made by creating an OpenSCAD cylinder with eight sides. I designed it to be printed in two pieces because the entire 200mm piece wouldn’t fit on my printer. I also included a little octagonal segment in the middle, that’s printed separately, in case I wanted a visible separator for the two-handed grip.
The last piece is the pommel. On a normal sword this acts as both a counterweight for the blade and a means of preventing hands from slipping off the grip. Since everything is made out of plastic, and because I don’t intend on using this as an actual sword, this piece is purely decorative.
I was originally going to make this part a little extravagant with a gemstone and went as far as designing it, but decided to go with a simpler approach to keep with my minimalist design. The left design is the gemstone pommel. The four holes in the base cylinder are meant to have paperclips inserted that can then be bent to hold in the stone. For gemstones I was intending to use some fake pirate gems I found on Amazon, but a gemstone mock-up was provided in the OpenSCAD design as a visual reference.
The design I ended up using is on the right. It’s a simple low-poly shape and went well with the rest of the hilt. It’s an octagonal shape made in the same fashion as the custom blade and crossguards with a customizeable array that determines the radius of the octagon.
With the design work all finished, the next steps are printing, assembling, finishing, and then finally painting the whole thing! So next post – Keith gets crafty!
For the past year or so I’ve had a project on my project list called the PiPad+. The details on the project page are pretty generic, describing it as a DIY tablet. I’m hoping to remedy this by fleshing out the project details and motivating myself to finish it in the coming weeks.
Like most of the Maker community, I was amazed when the PiPad came out. When Chalk-Elec got their 10″ displays back in stock I quickly bought one so I could create my own version of the PiPad. Of course, being myself, I couldn’t just copy what had already been done. I had to do something new and exciting. Right off the bat I decided I would get rid of Raspbian’s default GUI and do something new that was optimized for touch controls and my personal tastes. I got as far as implementing a basic window manager and a grid-style homescreen before I “took a break” because GUI design is hard! For the past year the code lived in my GitHub, gathering digital dust, until very recently when I decided to delete it.
During the long “break”, the project was also subjected to a good deal of feature creep and component scouting. Many things have also changed in that time; I bought a 3D printer, the Raspberry Pi 2 was released, etc. Rather than continue to let this project stagnate in its project drawer I’ve decided to try to finish up the project in the near future so I’m no longer plagued by the inexorable desire to shove in as many features as possible. The semi-final state of the project will be as follows.
I chose to build my tablet around the Raspberry Pi due to the large amount of community support behind the SBC. The huge number of people tinkering with the Pi’s OS ensured that I’d be getting the maximum performance available for the hardware. I’m currently using a Raspberry Pi 2, though I will probably upgrade to the Raspberry Pi 3 once it becomes available. The built in WiFi and BLE will help save space inside of the tablet. The only downside with using the Pi is the size. Due to the dimensions of the USB port the thickness of the tablet will have to be around 2.5cm. Rather than attempting to slim down a Pi, I opted to utilize the thickness to cram the tablet full of features as detailed below.
Due to the amount of stuff I wanted to cram in this tablet I decided to get Chalk-Elec’s 10″ Touchscreen to use as the tablet display. If things get too cramped I might consider upgrading to one of their bigger displays.
For the battery I decided on an EasyAcc 10Ah Battery, commonly used as a portable phone charger. I chose this battery because it was the largest one I could find that would fit in the tablet chassis. It also has pass-through charging, a feature which allows the battery to power the tablet while it’s being charged. Surprisingly, this is a rather uncommon feature in portable battery packs.
Rather than building a basic tablet that won’t get much use, I decided to add extra features that would enable my version of the PiPad to be the ultimate Maker’s tablet. The extra added features are detailed below.
The most important tool in a Electrical Engineer’s toolbox is his multimeter, so this one was a must have. However, I had trouble finding a small and cheap USB multimeter, so instead I opted to make my own. I borrowed heavily from this Instructable when designing my custom board.
An important tool for working with analog circuits is an oscilloscope. A few months prior to starting this project I bought an Xprotolab Plain, which is a nifty little USB oscilloscope that’s surprisingly cheap. Due to its small size I decided to add this into the tablet. I also created an adapter to go from the Xprotolab’s header to a standard BNC connector.
The Xprotolab Plain also had a Logic Analyzer built in so this one was a freebie. The logic level is only 3.3V, however, so I’m toying with the idea of making an adapter to add 5V tolerance.
The Bus Pirate seems to be a commonly used tool by many makers and hackers. I don’t have any experience with it, but decided to include it in the tablet since it didn’t take up much space. I decided to go with version 3.6 of the hardware as that seems to be the most widely supported.
Lastly, because I wasn’t using them for anything I decided to add a breakout for the Raspberry Pi’s GPIO to the tablet. This would add some additional IO to fiddle with and was simple to add.
The components that will hopefully make the tablet are currently sitting on my workbench in a rough semblance of how they will be organized inside of the tablet. The steps that I still need to take in order to get everything working are listed below:
- Populate, solder, and test the multimeter
- Determine how to organize the power subsystem
- Decide on a semi-final organization of all the parts’ locations inside of the tablet
- Finalize the 3D printed bezel with connector cutouts
- Glue the mechanics together
- Secure the components inside of the tablet with double sided and Kapton tape
- Connect everything together
- Design and attach a removable back plate
- Decide on whether to use Raspbian’s default window manager or design my own
Over the next few weeks I’ll start going through each step, trying to finish up the tablet hardware so I can move on to other projects. For the components that I’ve custom built, I’ll post source files and separate blog posts to explain how I’ve designed these parts, and how they work.
After tons of design work and hours of printing, the prototype for the navigation chassis is done! This is by no means meant to be a final version, but rather will serve as a prototyping platform to start work on the electronics and software for the robot. Pictures and explanations are below!
Due to print bed limitations I divided the navigation unit of the robot into three main sections, two motor sections and a front section. Each of these sections was then split in half for printing. There are mounting holes on each part that allow everything to be assembled using M3 nuts and bolts.
In terms of sizing I’ve left a 150mm square at the center of the robot as well as the back quarter of the circle as free space. These should provide sufficient space for any extensions I design.
The motor assembly is the most complex part of the design, consisting of five separate parts. For the motors I decided to use the most common motor found on eBay, a generic yellow robot motor. They tend to be very cheap and easy to use. They’re attached to the motor mount using M3 nuts and bolts.
While these motors usually come with wheels, I found them to be too large and cumbersome. Smaller wheels were necessary to conserve space so I designed simple, 3D printed ones using a spoked hub and TPU filament for the tires to provide traction.
I couldn’t find any cheap encoders that I was happy with on eBay, so I decided to design my own using magnets and hall effect sensors. The magnets are generic 1/4 in. and should be easy to find. My reasoning behind using magnetic encoders instead of optical is because magnetic encoders tend to be more robust when it comes to dirty environments. I’ll go into detail about the hall effect sensor PCB I designed when I do a write-up for the electronics.
As seen in the top image, I have five ultrasonic rangefinders that will be used for localization and mapping. They’re mounted on either side, in the front, and 45 degrees to the left and right of the front. This will provide the robot with a full view of obstacles in front of the robot.
I’m still waiting for this part in the mail, but I’ve designed space for a TCS3200 color sensor module. This will be used for determining what type of floor the vacuum is on. This color sensor uses internal photodiodes to measure the amount of reflected red, green, blue, and white light. I’m hoping that I’ll be able to use the white light magnitudinal component as a primitive proximity sensor so the robot can detect stairs.
Rather than using metal ball casters like I was originally planning, I decided on designing 3D printed rollers instead. These are the same type of casters used on the Neato robots.
While I have yet to design in the bumpers for the robot, I plan on using microswitches attached to two 3D printed front bumpers to detect obstacles, on bumper on the front left and one on the front right.
There are a handful of things that I’d like to tweak to improve upon this design. The current version of the navigation unit only has 3.5mm of ground clearance. I’ll be playing with this a lot in order to strike a balance so that the cleaning module is low enough to optimally clean the floor, yet high enough so the chassis doesn’t sag and drag on the ground.
While I’m currently using five ultrasonic sensors, I’m unsure as to whether that many is needed, or if the mapping will be fine with only three. I’d like to remove any unnecessary components to cut costs.
There are a few other difficulties I noticed when assembling the navigation unit. Mounting the wheel on the motor proved a little difficult due to the size of the wheel well. Since I have some extra space I’ll probably increase the well size to make mounting the wheel easier. The same goes for the casters. Because the axle can’t be 3D printed with the chassis design, I have to find a way to mount it on the front that allows it to be put in easily but doesn’t allow it to be knocked out during use.
As always my design files are available on the Github repository. Thoughts, comments, and criticism are always welcome. I’ll be doing a lot of tweaks on the design and wiring up the electronics in the near future. I hope to do a full electronics write-up soon.
I realized that in my last blog post I stated how modularity was important to the design of OpenADR, but I never actually defined my vision for what modularity means and what it would entail. Thus far I’ve identified this project as a robot vacuum. My ultimate goal, however lofty it may be, is to design a system of robots and extensions rather than just an autonomous vacuum. There are home robots of all kinds on the market today such as vacuums, mops, and gutter-cleaners. They’re always complicated and always expensive. The thing is, I don’t think they need to be.
As an engineer I look at the design of these robots and see unnecessary complexity. As a programmer I see redundancy and chances to optimize. As a Maker I see an opportunity for the community to make something better. Those thoughts were my inspiration, and the reason I decided to create this Open Source project. I wanted to make something simple and elegant with a low barrier to entry so that anyone can contribute.
To aid in this endeavor I looked at the current domestic robot market and saw the redundancy in the designs. A robot vacuum, robot mop, as well as other types of robot can really be broken up into two different parts. There’s the navigation unit (e.g., the localization sensors, drive motors, encoders) and the cleaning system (e.g. vacuum, mop, waxer). Rather than buying a vacuum for each separate task and effectively paying twice for the navigation hardware I’ve decided to first design a navigation robot and leave a large slot in robot body to allow for various swappable extensions. The first, proof of concept extension will be the vacuum. Doing this will reduce the number of duplicated components and cut costs of the overall project. It will also save time on hardware and software design.
Another benefit of this modular system is additional ease of development. Large software projects like the Linux kernel having componentized designs, breaking the software into parts based on architecture, use case, abstraction level, etc. By having these functionally separate components, new contributors don’t need to understand the entire project just to add to a small part. The barrier of entry to the project is reduced and project members can focus only on the components they’re most comfortable with.
This is my ultimate goal with OpenADR. I’m most comfortable in the realms of embedded design and firmware development. I hope that by providing a strong base for the project, people who are much more proficient than I in other areas will join in to help OpenADR move forward.
I’ve had my 3D printer for almost a year and a half now and so I thought it was about time I write a post explaining why I think it’s the most useful tool in my office. The setup I’m using is as follows:
Before I start explaining why I think 3D printing is the bee’s knees I just want to state that this post isn’t intended to be a review of the Printrbot. This is the first 3D printer I’ve ever owned, so I don’t have any frame of reference to compare it to. Rather this is an explanation of the uses I’ve found for 3D printing. One of the biggest barriers I’ve seen to a 3D printer in every home is that most people can’t think of enough applications to justify the cost. While I can’t definitively state that the money I’ve saved from 3D printing things has balanced out with the cost of the printer, I can at least bring my use cases to the table.
When working on projects I find that the greatest disincentive often comes from the act of physically doing something, be it measuring, drilling, cutting, etc. While it wouldn’t necessarily be difficult to make custom parts out of wood and poster board, I find the time and effort it takes to plan and assemble the part deters me from even starting. It also doesn’t help that I have trouble planning ahead and so will often encounter unforeseen problems mid-construction. 3D printers help mitigate this problem for me.
With how ridiculously easy OpenSCAD makes 3D modeling, I can quickly design a project and print it out without ever lifting a drill. This makes 3D printing both easier and safer for the small things. 3D modeling has also reduced the number of unforeseen errors in my projects. With the the configurable design right on my screen I no longer have to open my graph paper notebook to get a accurate view of my project. I can move, change, and combine 3D parts with ease.
Granted, programmatic CAD does have drawbacks since it converts text to 3D images rather than directly manipulating the design. However I believe that the benefits when it comes to reuse, version control, and parameterization outweigh these downsides.
Another benefit of having objects as a shareable software construct is that it allows you to take from and tweak the designs of others. Thingiverse, one of the most popular sites for sharing 3D printed designs, even allows you to copy and “remix” other users’ objects for your own purposes. One useful example I can think of is the idea for an Iron Throne style phone charger that I’ve been mulling over. I don’t have the patience or CAD skill to design an Iron Throne 3D model from scratch, but there are other people who do. I can then take their 3D models, with appropriate attribution, and use them as a baseline to design my phone charger.
As 3D printing and scanning gains in popularity more large organizations will begin sharing important objects with the public. Both NASA and the Smithsonian are beginning to openly share object models of important artifacts like space probes and fossils. I truly hope there comes a day when I can have my own miniature 3D printed T-Rex skeleton to decorate my desk.
Another considerable use I’ve found for the printer is to aid in apartment living. Since I rent I’m limited in how many nails I can put in the wall before I lose my security deposit.
With a combination of Command Strips and custom printed adapters, I can create a way to hang heavy objects on the walls without doing any damage.
Lastly, and probably the most important use I’ve found for 3D printing in the home is for creating one-off objects that don’t have enough utility to be sold as a mass-produced product.
The cake topper for my wedding is one such example of this. Rather than settling for an expensive custom one on Etsy or a generic one from elsewhere, I designed and printed my own. With the wide variety of filament that’s now available, finding a food-safe, metallic gold PLA wasn’t difficult.
I’m sure as time goes on I’ll continue to find more uses for my 3D printer around the house, but I already believe it’s paid for itself in terms of the productivity it’s afforded me with my hobbies. There are things I can create now that I never would be able to without it and I feel that’s plenty of justification for my purchase.
Being a generally disorganized person who works as a professional engineer, I’ve noticed that the tools I use at work have really helped me stay organized and focused. After noticing this, I’ve decided to utilize some similar tools for my personal projects to keep me organized and motivated, and also to apply a professional touch to my hobbies. The most useful tools I’ve used at work are part databases, a version control system, and an issue tracker. Since the specific tools I use at work are targeted towards large companies and therefore have expensive licenses, I’ll be using open source or free alternatives. In addition to the tools I mentioned, I’m also going to install a 3D printing server so my Printrbot is no longer tethered to my main PC and prints can be uploaded and controlled from anywhere. I’ve bought a Raspberry Pi 2 Model B specifically to handle this software and become my official home maker server. The software that I’ll be installing as well as links to installation instructions are as follows:
PartKeepr – A part database. I’m constantly losing, buying multiples, and rediscovering parts so this will help give me a clear snapshot of all of my components, allowing me to better plan out projects and determine part requirements. I used this blog post for installation instructions, but here are a few quirks I noticed when installing:
- I had to copy the partkeepr folder to /var/www/html rather than /var/www since that was the default root directory for my apache server
- I had to be logged in as the super user (sudo su) for the pear part of the installation or it wouldn’t work
Github – I don’t anticipate developing closed source code in the foreseeable future so I’ll just be using Github for version control.
Trello – A simple issue tracker with a convenient web interface. There’s not a lot of advanced functionality but it should be sufficient for what I want to do. Originally I was going to use a more sophisticated issue tracker called Trac because it has integration with version control and a built-in wiki, but decided against it. It would be another service to install and host on my Raspberry Pi and the additional complexity might deter my productivity. In addition, not having a private wiki could serve as encouragement to keep my projects better documented on this blog.
In my ongoing, multi-year effort to clean my office and upgrade it to the ultimate make-station, I decided that I needed a fume extractor since inhaling solder fumes probably isn’t too good for my health. Of course, being me, I decided a basic fume extractor was too simple and set about building one into the cheap Ikea tables I use as desks.
Right off the bat I knew I needed at least four components: a fan to move the air, a filter to absorb smoke and particulates, a porous tabletop, and a power switch to turn the system on and off. For the fans I bought a few cheap pc fans. They’re about 5 inches in diameter, run off 12V, and move a decent amount of air quietly. The filters are just a few solder fume extractor filter replacements. The porous tabletop surface was a bit harder to find. I wanted something with large enough holes to let plenty of air through, but small enough that I wouldn’t constantly be losing pieces into them. I settled on a one foot by two foot piece of sheet metal with 3/16 inch holes. The on/off switch was just something I picked up from Radioshack.
For the placement of the fume extractor, the two desks, when placed next to each other on the long axis, take up almost the entire width of the office with nine inches to spare. I decided to place the fume extractor into that space to save myself the trouble of cutting into the desk.
The first step in the process of building the fume extractor was to create the structure to hold the fans and filters. Originally I was going to 3D print elaborate fan and filter holds but decided that cutting into some foam core board I had laying around would be much easier. Since I had no idea about what kind of airflow is necessary to draw in solder smoke I decided to try and fit as many fans as I could into the fume hood and cut out holes for four of the PC fans I bought.
Once that I was done, I designed and printed out some simple brackets to hold the carbon filters.
I hot glued them all together to make mounting easier.
And taped them onto the foam core board. (Huzzah for Duct Tape!)
The filters fit in snugly and are easy to pop out and replace.
The fans had holes in the corners so mounting them was a simply a matter of poking holes in the foam core board and mounting them with M3 screws and nuts.
I taped these brackets onto the desk as a proof of concept and because I like to avoid drilling/cutting/sawing if at all possible. If I’m feeling ambitious at some point in the future, I will probably screw these in to make the assembly more permanent.
After some fidgeting with the placement of the desks, the foam core assembly sits in the gap pretty nicely. My original intention was to attach the assembly directly onto both of the desks via the brackets, but decided against it for two reasons. First, with the board sitting gently on top of the brackets, it’s much easier to pull it out. This will make pulling the assembly out and replacing the filters much easier. Second, the 3D printer can produce a lot of vibration and usually shakes the entire table. If the foam core assembly was rigidly attached to both desks the vibrations would shake both tables and the computer monitors on the left desk would vibrate whenever the 3D printer was in use. With the foam core laying in the gap it will probably get a little more beat up being hit by right desk, but foam core is cheap and it would be easy to replace.
This is the basic wiring diagram for the electrical side of things
For the power I just wired up an old Power Wheels charger I had lying around. Originally I intended to add another switch and some 10W resistors to be able to select two speeds for the fume hood. I thought that the four fans would be excessively loud and I’d want to run the fume extractor at half speed most of the time. Fortunately, running the four fans together turned out to be surprisingly quiet, so I simplified and decided to only wire up an On/Off switch.
I mounted the button on the front of the foam core assembly in a 3D printed panel. Cutting precision circles in foam core board turned out to be pretty difficult, so using a 3D printed front was simpler.
I was a little unhappy with the metal surface I purchased. The surface was pretty scratched and stained. It also had a curvature to it from being rolled up, something which I didn’t anticipate. I laid it flat and put my two heaviest books on top to flatten it out.
However, after several days of flattening there was still a slight curvature to the metal so I had to screw it into the desk to keep it flat.
The edges of the metal surface were also pretty sharp so after fastening the metal into position I taped down the edges with the black Duct Tape i used earlier. This provided both a nice finish and a way to not cut myself.
Overall I’m happy with how this turned out. It looks pretty nice, and while it could do with some polish it’s simple and sturdy. And best of all it works!
As a software engineer I’ve long been unimpressed with the triviality associated with compiling code. Surely the building of a masterful creation involving hundreds of source files and complex algorithms deserves more than just a small keyboard shortcut. There should be drama, there should be flair, there should be maniacal laughter!
To fill these requirements I’ve created the Build Button! Using the wonderfully dramatic Adafruit Massive Arcade Button, a mini Arduino Kickstarter reward, and a 3D printed enclosure, I made a button that communicates serially to a computer through the USB port. A Python program on the computer monitors the currently active window and tells the button to light up when the active program matches a list of programs with build shortcuts. When the button tells the computer that it’s been pressed the computer executes the keyboard shortcut associated with the currently active window to compile the code.
The source for this project is on my GitHub.
Going into this project I knew I would have to do a lot of surface mount soldering to save space and money. I used the smallest SMD hand-solderable packages and still ran out of space! I’ve never been particularly good at soldering, but knew that I would have to become much better to tackle the types of projects I’m interested in. In anticipation of this, I splurged and bought a very nice soldering iron from Radioshack. I cannot express how great this iron is! I’m used to using cheap, $10 irons that just need to get the job done, but with the fine tip on my new one, SMD wasn’t difficult at all! Below is a picture of the board with most of the components soldered on.