New 3d printer updates

Time for some new updates on old progress on the 3d printer project I began anew last summer! This work is all from over a month ago, but got delayed (with most everything else) due to a mountain of work and tests recently. First up, some freshly waterjet cut parts:

Featuring extensive t-nutted and tab-and-slot connections, I quickly became thankful for ordering a small file set to get into the tight spots on the waterjetted assembly. Unsure of the offset or tolerance settings on the cutter, I just had to make a guess on my dimensions. Some turned out tight, others were spot on. With that, the pieces slowly started coming together:

With  the easy parts done, the laborious process of drilling out all the holes in the vertical angle aluminum began. It took several night sessions on the vertical mill to get all of them, but the results were worth it. I opted to not try and waterjet vertical members and t-nut along the edge, because of worries about accuracy. It was at this point that I also started adding the acrylic panels (laser cut near the end of summer). Everything is 1/4-20 tapped for maximum convenience:

Unfortunately I don't have any good pictures of more recent progress. All of the aluminum members are installed, and the last few acrylic pieces will be ready once I manually drill a couple more sections. The biggest question mark in this project has been the z-axis gantry. After press fitting the bronze bushings into their aluminum mounts, I temporarily installed the guide shafts and tested alignment. The flexure mounts on the carriage were certainly pulling their weight, but I still found a lot of resistance when I attempted to run it up and down. Reaming the insides of the bushings helped significantly, but I'm still not happy with the results yet. I have multiple theories as to the cause of this, but the number one is the accuracy of the t-nutted connections. I installed and tightened the pieces together before installation on the rails, and noticed some definite play in the position of the plates. I plan on loosening and and refiling the carriage pieces before re-tightening them on the rails to see if this solves the problem. The other potential issue I see could be bushing alignment. The press fits for the bushings was looser than I would have liked, and I suspect this allows them to twist out of colinear alignment.

While I could just switch to the linear bearings I use elsewhere on the machine, I feel that the bushings are a more robust choice when supporting such a large cantilevered load (and desiring to minimize vibrations and wobble). Next up on the printer project is more machining, 3d printing of the x/y gantry pieces, and wiring of the electronics!

MechEtroller-the barebones brushed motor controller

With Obligatory 3d printer awaiting yet more parts before commencing construction, I'd like to take a break to introduce a new project that has been in the works for a few weeks. Introducing MechEtroller: the alarming result of a mechanical engineering major attempting to build his first motor controller. Living true to its name, version 1 has successfully trolled a certain MechE from the get go.

Before diving in, I'll call attention to my last electronics endeavor, Mini ATmega328 board. Started way back in Freshman year, this board was my first PCB, first introduction to SMD soldering, and first real introduction to the world of embedded hardware. It failed due to a laughable mistake shorting logic power to ground when the reset pin was pulled down. Development did not continue on that board, but it inspired me to keep playing around with electronics for the last two years. While there are now enough inexpensive Arduino clones to render the economics argument behind making the board void, I don't think the same can be said for brushed motor controllers.

Most of the hobby motor controllers I've used in the past have been expensive and occasionally unreliable (case in point: Sabertooth 2x60). I won't pretend to think I can produce the same quality of motor controller for less, but it does make the idea of a custom motor controller that much more tempting. After a year of playing around with H-bridges and releasing smoke from MOSFETs, I decided to try and get serious with this.

MechEtroller is relatively simple as far a motor controllers go: an H-bridge based DC brushed motor controller in the 20 amp range. I don't do many projects above 36 volts outside of RPI Hybrid, so I set an input voltage range of 12-36 volts as my goal. This is low enough that I can find a pair of linear voltage regulators to bring it down to gate drive and logic levels without too much trouble. I'm also making life easy by choosing a relatively low gate drive voltage such that I don't have to boost the 12 volt lower limit. The microcontroller is a typical ATMega 328 smd chip, which will either run an Arduino bootloader or be programmed in Atmel C if I want to get lower level with some of the functionality. An FTDI header is on the board to allow programming, and ICSP flashing of the chip with happen with this sweet pogo pin programmer.

That's pretty much all there is to the logic side of things. A couple of resistors provide current limiting for LEDs and pull down for inputs. Most of the tiny caps on the board are for the voltage rregulators with the exception of the huge capacitor footprint at the top, which is for decoupling the battery power line. The board allows TTL serial, I2C, and analog voltages for inputs.

Moving onto the power electronics, I've selected the PSMN3R3-40YS MOSFET for the first revision of the board. While my research has indicated that the LFPAK enclosure is less than ideal for dissipating heat, I wanted to aim for the cheap end of the MOSFET spectrum. Given the brand new nature of the board, these FETs had a 100% likelihood of death, so there was no point in splurging for nicer ones. In figure 9 of the PSMN3R3-40YS datasheet you can see a very nice graph of Rds vs Vgs. This was the other motivation behind the PSMN3R3-40YS; it has (almost) minimized its on-state resistance with only 12 volts on the gate pin. 4 mOhms of resistance still leaves something to be desired, but it's acceptable for my needs!

To drive the FETs, I picked out the FAN 3111E gate driver. It meets all of the voltage and current requirements and comes in an easy to solder SOT-23 package.

 Board design proved to be the most challenging aspect of the project. A tight budget and dislike of unused board space lead me to use the smallest trace width allowed by OSH Park. This was also my first time routing a board from scratch. It took a while to get the hang of, but eventually I began to improve. Despite this, the final routing ended up very ugly and inefficient. Experienced PCB designers please avert your eyes:

This was also the first board I have ever done using copper pours. After quickly realizing that standard traces on 2-oz copper were not going to meet the current requirements of the MOSFETs, I eventually determined a configuration of the FETs that minimized the distance between component and plated hole. Connecting to the gate pins still proved tricky, but some tiny routing allowed them to sneak in. I attempted to generally confine logic and battery voltages to different sides of the board. While I wasn't completely successful, overall I was pleased with how the board layout came out. Certain component footprints were definitely pushing the limit for space (such as the reset button), but I found no issues with the placement or soldering process when the boards arrived.

The boards looked excellent on arrival from OSH Park (as usual). As I began soldering the board together, I made my first mistake. Instead of staring with the voltage regulators and logic circuit and then testing, I over eagerly soldered the entire board. While I intend to use solder paste for the FETs in the future, for the first test I just used lots of flux and heat and pre tinned the pads on the underside.

For the moment of truth, I started out on a lab power supply at 14 volts. The microcontroller was unprogrammed, so I was just looking to see the power LED turn on. Instead, I noticed that the MOSFETs immediately began heating and remelting their solder. Oops.

Thinking I had shorted two pins, I desoldered one side of the FETS so that no current could pass through the "high voltage" side. Now upon applying power, the board immediately smoked. Closer inspection revealed a voltage regulator had gone. I was suspicious of this, and mistakenly thinking I must have swapped the 12 and 5 volt regulators, resoldered two new versions in the opposite spots. No smoke this time, but an immediate and uncontrolled heating of the 328 microcontroller. Fairly confident the microcontroller was toast, I just focused on the voltage regulators. Measuring the output pin against ground revealed that the full 14 volts was flowing through the entire board. This was odd, because checking the schematic confirmed that they were in the correct orientation and properly grounded. Or were they?

After another round of regulator replacement and destruction, I tried measuring the resistance between the voltage regulator ground and power supply ground. This finally revealed the truth: my board ground appeared to not be connected to anything. In the absence of a reference ground, the poor regulators couldn't do anything to save the board. While this partially solved the puzzle, I was confused by the fact that my schematic showed all the grounds to be connected. It wasn't until closer inspection that I realized by mistake. In Eagle, you can either use a GND symbol from the component library, or simply label a line GND. In my ignorance, I attempted to use both, some on certain parts, and some on others, These two do not automatically connect, and thus there were no connections between one half of my board and the other. 

In a last ditch effort, I attempted to solder a wire from one ground to the other, and replace any components I had left:

Unfortunately, I believe that too many components were still damaged. I got one more pop noise upon applying voltage, and then unregulated voltage upon measuring the Vreg output. The fate of the first board was disappointing, but at least the error originated from labeling in Eagle, rather than a fundamental issue with the circuit design, MechEtroller will return with a new fixed board and probably some better routing. The new DigiKey parts have arrived, it's just a matter of finding the time to revise the Eagle design and send out a new OSH Park order. For future versions, I'd also like to investigate adding some cool features, like encoder input and current limiting functions.

That's all for now, check back soon for a new build update on the 3d printer. 

The second flight of the quad

Now there is some slightly better footage of the quad in action. One of the Hobbyking motors needed replacing after it began internally shorting last time. With the new motor installed, CarbonCopter is back in action!

Obligatory 3d Printer design updates

Work is proceeding slowly but surely on Obligatory 3d Printer. While I'd like to proceed faster, general busyness and the knowledge that I won't have waterjet access until 3 weeks from now are setting the build schedule. First, updates on the mechanical design:

This strange looking part is the assembly for my sliding extruder mechanism. As I have already purchased a MakerBot Mk. 7 knockoff extruder, I based this design around it (the CAD of the extruder itself is available online, not something I modeled). My goals with this piece were to keep it light and simple. I've swapped out the "universal mount plate" that came with the extruder (which was apparently not universal enough for my needs) with some soon-to-be waterjet cut 1/16th aluminum plate. This plate forms a rigid mount point for the extruder and linear bearing holders. The 4 LM8UU linear bearings, popularized by almost every hobby 3d printer on earth, are snap fit into 2 ABS 3d printed holders. Yes, I am 3d printing parts for my 3d printer. Fortunately, this is inexpensive and relatively painless by utilizing the high quality 3d print services at RPI. These two "wings" on either side tap into the plate and suspend the nozzle. I've decided not to design some intentional flex points into the bearing mounts here, mostly because of the inherent flexibility in the ABS mount and my faith in the accuracy of the 3d printer making the part. Looking closely at the lower image, it is possible to see a little clip that will clamp onto the timing belt which moves the assembly. Progressing to the next logical parts, below are the y axis sliding mounts:

The same general design procedure applied here, 3d printed ABS and snap in bearings. The two parallel holes support the x axis rods. The other protrusions consist of a mount for the stepper motor and timing pulley, respectively. These parts are not finalized yet, and still lack timing belt clips to allow them to move along the y axis. I feel very spoiled being able to print parts with ridiculously complicated geometry like these to fit my exact needs. Hopefully this will be a taste of future printing endeavors. I'll leave the y axis stepper motor coupling for next post when it is more complete.

I think that now would be a good time to cover the electronics that will be used in this project. As stated earlier, the extruder comes courtesy of the MakerBot Mk. 7 design. All of the other stepper motors are standard NEMA 17 types, sourced from Sparkfun. Moving on to the control side, I will be using a AzteegX3 board for all my motor driving, heating, and processing needs. I haven't had the opportunity to try out the board yet, but my initial impressions lead me to be very impressed with it. Complementing the Azteeg, I also have a ViKiLCD unit which will mount into the front, providing a simple user interface and SD card support. Rounding out the trio of products from Panucatt devices is the Helios heated build plate, which provides 62 square inches of build space (and looks really cool with its black and yellow color scheme). Powering it all is a currently unspecified 500ish watt computer power supply, because my last one abruptly exploded a few weeks ago for an unknown reason. The interior sides of the printer are also lined with blue led modules from Sparkfun, to go with the translucent blue acrylic side windows. I have yet to find a good source for stepper motor cable specifically, so I plan on using some generic "automation rated" 4 conductor wire from McMaster. That's all for now, more updates will follow shortly.

CarbonCopter

Taking a detour from the ongoing 3d printer build report, I'd like to introduce: CarbonCopter (or at least the crude, motor-less CAD model seen above). CarbonCopter is a simple, no frills, semi-custom quadricopter I put together in the first few weeks after spring term ended this summer.  Intended to be a platform for future motor controller/positioning system/balance algorithm projects, it was also just a fun and easy craft that allowed me to enter the world of DIY flying things.

After checking out all the applicable RC supplies available in the US HobbyKing warehouse, I ordered the motors, props, carbon fiber boom arms, battery, and MultiWii controller board. I wanted this copter to be cheap and easy to build. Higher performance parts and optimized component pairing can happen later if I decide to invest a lot more money in an expensive RC hobby! While it would be cooler to try to make a controller board from scratch, I doubt I could top the user interface and hardware you get with the MultiWii for only $27.15. I choose the Aerodrive SK3 2822-1275 outrunners with generic 10x4.5 props because they were in stock and in the right size range. Some 15 amp "Multistar" escs and two 3s Lipos rounded off the order. The two Lipos were actually an accident; I had only intended to order one 3s 4000mAh pack, but now I guess I've also got a 3s 5000mAh pack to play with too. 

That covered most of the moving parts and electronics. When it came to designing the chassis (if one can even call it that), I stuck to parts I could reasonably mill on the ShapeOko CNC mill. I went with the "sandwich" design school of  thought, squishing the boom mounts between two stiff plates. I like this because it does a decent job of minimizing bending torque on the plates, and instead converts a lot of the force into tension and compression. With relatively long 320mm booms, I wanted to keep things as rigid as possible, to minimize oscillation effects on the gyro and accelerometer. I can personally attest to how frustrating it can be when vibrations screw with your control system. The spacers between the carbon fiber plates are two piece HDPE shaft collars, with the material sourced from my favorite cutting board supplier. Seriously, if you have a CNC router and haven't tried HDPE as a milling material, you are missing out. 

Sourcing the carbon fiber plates was surprisingly harder than I expected. There were no good US warehouse HobbyKing offerings at the time, and most of the other online sources I found that could ship quickly seemed overly expensive. So I finally decided that the benefits of purchasing some epoxy and cloth from my local Tap Plastics (which could allow me to make more interesting things in the future) outweighed the hassle. I layed up the carbon fiber plates five layers thick, using standard twill weave cloth. I used wax paper and a petroleum jelly and acetone mix to help keep the epoxy from sticking to my work station. This worked actually worked decently, and gave me satisfactory (if not perfectly smooth and glossy) results. 

Next up, I exported the Solidworks drawings to g-code, and began milling.

I was happy with how well the parts came out, and especially with how little fraying I saw. The cutting process was very quick, but I unfortunately neglected to document it. After the plates were done, I also got to work milling a foam mold for a carbon fiber electronics cover. This is visible in the first image on this post, but it was really more of an neat thing than actually useful.

In the milling process

Done and sanded!

The idea was to take this positive, make a fiberglass negative, then make a carbon fiber positive from that. The process worked up to the point when I tried to make the carbon fiber positive. The cloth couldn't bend sufficiently to reach the inside spaces of the mold, producing an ugly result:

Oh well, at least now I know how not to do it. This didn't end up being used. While this was happening, the ShapeOko was milling out even more pieces. Specifically, 16 chassis spacers and 4 motor mount clamps were produced from the HDPE. The motor mount clamps are what connect the 4 outrunners to their respective booms. They were my first attempt at doing real 3d profiling work (2.5d milling), and they worked great. Here is a closeup of their design:

They are not particularly elegant or weight conscious, but they were easy to mass produce on the mill. Not knowing the exact bolt pattern of the outrunners (as they had not arrived yet), I just made a large hexagon of space that could be drilled through later.

When it came to fastening the pieces together, I think my time spent designing a Formula Hybrid racecar is beginning to show, because it's a little over the top for the application. 4-40 hardware everywhere, with abundant nylock fasteners.

The frame is very rigid, even when flexed from the far ends of the booms. Once this and the motor mount clamps were in place, electronics install went very quickly. The MultiWii was simple to wire to the escs and my cheap HobbyKing receiver. As for the battery, it is just slung beneath the quad with velcro. I thought about adding legs for graceful, less jarring landings. Who was I kidding though; legs only work if you plan on not crash landing occasionally, and I expect to crash a lot. Besides, the entire quad is very flat and wide, so the risk of a propeller contacting the ground if I were to make a proper landing seems fairly low. I booted up the MultiWii software and confirmed that I was getting good sensor readings from the quad. Initially I had trouble triggering the motors to arm and start up, but some tweaking on the transmitter adjustment slides fixed that.

I managed to get a video of the first test flight. It isn't pretty, and I didn't do justice to how well it can actually fly due to my inexperienced piloting. I've since taken it for some really fun runs and put it to more of a test. Below are my introductory "touch and go" landings.

I don't plan on continuing to develop CarbonCopter at the present due to the many other projects I'm currently working on. I do have some really interesting ideas that use this as platform however, so it may return in the not so distant future. I'll try to post any other good flight videos too as they happen. Stay tuned for more 3d printer design soon!

Obligatory 3D printer

Sometime, about half a year ago, I decided that it was finally time to make a 3d printer. Not because I had a real need for one, nor because it would be revolutionary in any way, and not because I found them particularly interesting. To be honest, the internet had just shamed me into making one because apparently everyone else already has already done so.

My other problem with many of the 3d printers on the internet was how fragile and finicky they were. Everyone was trying to outdo each other building progressively cheaper and more flimsy machines. I don't have a problem with innovation, but after seeing 10 "new" dream schemes on Kickstarter each claiming to be the next cheaper printer that would finally bring mainstream 3d printing into our homes, I started to get sick of the obsession.

Thus began the design of my Obligatory 3d printer. It would not be designed from trash I found in a dumpster and some duct tape to keep it under a hundred dollars. It won't require me to buy sketchy 3d printed fittings from some guy on eBay. Most importantly, I won't (hopefully) need to spends months going crazy trying to figure out all the quirks and tweaks needed to make it work well. I'd rather pay for something reliable, robust, and simple to use. I also wanted the learning experience associated with designing a machine like this.

Having decided this at the start of winter break, I then realized I'd have about 2-3 weeks to design, order parts, and built it before classes started again. I would also lack the many nice automated and manual machine tools at my disposal at college. In retrospect, it wasn't the greatest idea to try and pull off a reliable and robust machine with those constraints. I tried it anyway however:

Obligatory printer Mk. 1

This was the first (incomplete attempt). Everything could be put together and manufactured with hand tools and the Shapeoko. Many parts were also very much homemade. Custom coupling from the z-axis stepper, custom brackets holding the frame together, complicated custom 3d profiled bearing holders made on the Shapeoko all existed in this version. I ordered all the parts, and started building.

An early picture of the build process

2 weeks later, I was out of time and about halfway along. I was also very unhappy with it. Tolerances on sliding parts were off, the frame held together with those unfortunate custom brackets was slightly out of alignment, and sloppy design choices were causing numerous problems. I am fairly confident that it could have been made to work with the investment of  more time, but I never would have been satisfied with its operation. So the project sat in storage for a few months while I dealt with other priorities.

Now I'm back for round 2. This time featuring a thought-out design process, automated machinery, fewer time constraints, and the knowledge of all the things I disliked about the last one. I will be salvaging almost all of the parts from the previous attempt, because they were not inexpensive. 

Obligtory printer Mk. 2

Here is the design so far. A tribute to abrasive waterjet cutting, laser cutting, and a little bit of 3d printing, I aim to eliminate as much manual manufacturing as possible. Design started with the frame. I generally like the idea of building a machine in its natural free form shape, then giving it an enclosure if necessary. However, a feature I was dead set on having was a somewhat evenly heated atmosphere around the printed part. Using a heated cabinet reduces stress in the part from areas cooling at uneven rates. This enclosure is not explicitly heated by anything other than its heated bed, but at least it should prevent drafts and breeze from people walking by from affecting the part. Many of the panels as well as a top are obviously still missing. The other big choice was to use both waterjet cut aluminum plate and aluminum angle for the structure. Waterjet cutting gives me good tolerances without any extra effort, and allows me to create any custom shape, hole, or slot I need. I can also abuse tab and slot t-nut joining methods, and easily tap or make any modifications with easy machining. Aluminum angle in the corners gives me an easy way to join the perpendicular plates. I'd also like to point out the awesome friction hinges on the front door, which allow it to remain in whatever position it is opened to. Thanks, Mcmaster, for supplying things I should have known existed for a long time.

Before going into the z-axis design, I should probably go through my thought process on the fundamental mechanics of the printer. Many inexpensive printers use a printing bed that moves laterally rather than print head. I dislike this for a number of reasons. First, it dramatically expands the footprint of the machine, making it harder to contain in a enclosure. Secondly, it involves shaking your precision printed part around at the same time as it is trying to cool and stay bonded to the surface below it. While it can simplify design in a couple ways, I don't think that outweighs the disadvantages for my situation. 

A design that takes the static bed and moving machine idea to the extreme is the x,y, and z moving nozzle. This makes sense from a part quality point of view, but it does sacrifice some elements of machine simplicity. Namely, machines of this style often feature an additional stepper motor to lift the entire nozzle assembly in the z-axis from 2 sides. I'd prefer not to deal with the additional motor, but there are ways around that. The cantilever solution is to just lift the nozzle assembly from one side, but this seems like a recipe for vibration. I suppose that you could mechanically link 2 lead screws to one motor with additional timing belt and pulleys, but then we return to the increase in complexity.

A design that is perhaps as simple as possible uses 1 or 2 motors to lift the z-axis, moves the part on the x or y axis, and then moves the nozzle on the remaining horizontal axis. I admire the elegance of this design, but now we've compounded the downsides of both of the previous designs.

Finally, we have the fourth and very common solution: to only move the part in the z-axis. Given the slowness with which the bed descends and its lightness, we can assume that vibration effects will be trivial. We now only have to deal with two linked axes, and the entire assembly is well suited to fit into an enclosure. I feel like a little bit of a sell out going with the boring solution featured in so many existing machines...but being a sell out with a reliable machine beats the alternative.

So, having spent far too much time comparing these possibilities, here is the new z-axis design:

Both the support structure and the carriage are made of waterjet cut 1/4" aluminum plate held together with tab and slot t-nutting. The 2 outside rods going down the center of the assembly are 3/8" precision ground shafting. Oil infused bronze bushings interference fit into the top and bottom of the carriage. A precision 3/8"-16 lead screw runs directly between them. Misalignment is the biggest worry with a system like this. Ideally, one shaft would constrain the carriage in x and y axes while still allowing movement along and around the z-axis. The other would only constrain the carriage in the y-axis (to prevent the carriage from rotating about the other shaft) and do nothing else. If this second shaft constrained it in both x and y axes, we would have an over-constrained, statically indeterminant solution. This would be bad, because any minute tolerance difference in the two shafts would cause the carriage to seize. In some cases this may not be a problem, because the surrounding support material can naturally yield enough to make up the difference, or the bearings are designed to be a little loose. This is unlikely to happen with 1/4" aluminum plate and bronze bushings. For this reason, some flexibility must be intentionally built into the carriage.

An excellent solution to this problem was featured on this build thread (one of the coolest engineering project websites I know of). At the risk of blatantly copying the great information on that page, I'll just try to briefly describe the idea. Flexure mounts make any misalignment in the two guide shafts introduce a bending moment across a small cross section of material. This cross section is designed to flex to an appropriate degree such that the bushings are relieved of excessive lateral pressure and do not bind. They look something like this:

I'm still investigating how to calculate the exact dimensions of these, so this image is  subject to change. Detail oriented readers may notice that there is no mechanism for mechanically linking the lead screw to this carriage. This is the result of another unhappy discovery I made on the first version. It turns out that the Mcmaster lead screw nut mount appeared to be off dimension, causing terrible wobble when the screw attempted to turn. This could probably have been solved by some better thinking on my part, for example not milling the holes for the adapter mount until the lead screw was centered to negate any eccentricity issues. For this version, however, I am doing away with the adapter mount all together and just tapping carriage to match the outer thread of the lead screw nut. Once I can verify proper operation, I'll Locktite and tighten it in for good.

The last line of defense in my paranoia of binding parts will be a flexible coupling between the end of the z-axis stepper shaft and lead screw. This is pretty much standard operating procedure on most machines like this, so I don't have anything to add. 

This post has gotten long enough, so next time I'll go over the other axes and electronics selection.

RadBot, the radiation detection and mapping robot

What is a RadBot? It was the name of my team's awesome final project in RPI's Introduction to Engineering Design class! I want to make it clear up front that this project was a collaboration between myself and a number of other students in my class group, not a personal project. While I would not usually document other people's work, I think that it would be a shame not to share some of the interesting parts of this project.

Specs:

Purpose: A robotic radiation detection and mapping platform

Chassis: Abrasive waterjet cut and TIG welded 6061 and 5052 aluminum alloys. Tab and slot fastening with a space frame design.

Drivetrain: 4WD Pololu 30:1 metal gearmotors

Suspension: 4 corner trailing arm system

Electronics: SaberTooth 2x12 RC motor controller, Arduino Nano with custom breakout board, Xbee transmitter and receiver, photoresistors, EM-406a GPS module, and HobbyKing radio control

Top speed: ~9 mph

Software: Processing program for wireless reception, Arduino language for on board sensing and transmission, Java parsing program, and Matlab for data analysis

For those who are unfamiliar with RPI's intro to engineering course (known as IED, but hopefully not in the explosive way), it is a semester long class tailored to teaching the engineering research, design, and manufacturing processes found in industry. For many students, it is the first "real world" engineering design work they participate in. It is commonly dreaded for its tendency to consume time, force students into dysfunctional groups, and inexplicably break working projects before final presentations. Fortunately, I would say that I went into the class better prepared than most due to the experience gained from personal projects and RPI Formula Hybrid.

I also had the advantage of getting a great group to work with. Together we decided upon an ambitious final project. This was partly to stubbornly ignore the common knowledge rule of IED (keep everything simple, and never rely on complicated electronics) and prove that it is possible to do a more technically challenging project. Additionally, we just found the concept very cool.

The concept behind our project was to create an inexpensive, yet rugged remotely operated vehicle that could enter environments with dangerous levels of ionizing radiation and map out the intensity of those localized readings. By using a GPS and wireless transmitters, the intensity across an entire landscape could be plotted. While the idea was conceived to assist in the rescue efforts surrounding reactor meltdowns or natural disasters, the concept could easily be applied to any contaminant or toxin. A lengthy paper was produced going into much more of the business justification and details behind this, but I won't elaborate on it more here. What this meant was that we needed a robust prototype RC vehicle that could operate in adverse environments and produce reliable data.

I contributed to multiple areas of the project, but my first task was chassis design. As seen above, the chassis made use of the abrasive waterjet cutting process to "jigsaw puzzle" the vehicle frame together. In the spirit of racecar design, I loosely emulated a space frame design when considering the load paths moving through the structure. Essentially, the goal was to ensure that every structural member was loaded in pure tension or compression, creating a network of 2 force members intersecting in nodes. This ensured that no material was loaded in bending, which would have created a potential failure point.

Once the chassis was in place, the suspension could be installed. This consisted of relatively simple trailing arms with motor mounts direct driving the wheels. Lever arms projected outward from the suspension axles, to which compression springs were mounted. Despite its lack of damping, the suspension worked surprisingly well for such a rudimentary and low cost setup.

Electronics were installed in the fore and aft compartments, with the NiMH battery pack in the center. If you are wondering what the "tower" at the front is, it is intended to be a remote camera mount. It also gives more room to mount a Geiger counter.

Once the electronics were installed and tested, RadBot got taken outside to prove its capabilities.

But roaming around the RPI '86 field was only half of RadBot's job. The other half was Science! As described above, RadBot was initially designed to collect ionizing radiation readings. While the Geiger counter model we had found would have been easy to integrate into the robot, we made a last minute switch to reduce the cost of the project. So RadBot ended up using a slightly less exciting photo-resistor as its "radiation" sensor. Still sensing radiation, only now the  less deadly kind (if you remember to wear sunscreen). In order to test the system, we stayed up until 3am testing in the dead of night to get readings from streetlights so the sun wasn't a variable we had to worry about. After a few days of tweaking, the system worked great:

Note the red areas on the map above. Those were all light poles on the field. The squiggling path visible in this image was actually intentional, so as to cover as much area near the lights as we could. GPS accuracy was actually surprisingly good, typically coming within 5 feet of the robot's true position.

RadBot did struggle with a few problems. First and foremost, we made the rookie mistake of having nearly equal track and wheelbase lengths between the wheels. This meant that the skid steering system we intended to use was initially highly ineffective, as all the motor torque went into scrubbing the wheels. Shortening the rear suspension trailing arm allowed us to reduce the wheelbase, effectively solving the issue. The Pololu motors were also troublesome. They typically worked great for the first day or two of driving, then developed difficulties starting. Once spun, they could get up to speed, but never had the same torque that they started out with. My theory is that because we had the two motors wired per channel of the motor controller, the stalling of one could have damaged the other. I may test this in the future to get to the bottom of the problem. In all likelihood, we were just using these motors in a much harsher application than they were ever intended for. While the gearboxes held up excellently, opening the failed motors revealed a coating of carbon dust on the inside of the casing.

Overall, RadBot was a great example of an ambitious project that succeeded in the face of limited time and resources. In addition, my team kindly allowed me to keep the robot at the end of the semester. Maybe RadBot will get a revisit sometime in the future....

Racecars and Robots

Rensselaer Formula Hybrid's DCMS

RadBot!

Obligatory 3d Printer

CarbonCopter

It has been a long time since I've given an update on my projects. I think I owe a little background information to help explain what has been happening in the last 12 months.

I've been involved with the Rensselaer Formula Hybrid team since my first day at RPI. Rensselaer Formula Hybrid is a student run engineering team that builds hybrid electric/internal combustion open wheel racecars to compete at the annual Formula Hybrid collegiate competition. At the start of my Sophomore year, I became co-president of the team, responsible for management of all mechanical design on the vehicle. Unlike most projects I have undertaken, Formula Hybrid is a massive commitment that requires a huge dedication of time and energy. Starting from basics with an inexperienced team, we succeeded in designing and building an amazing vehicle, the DCMS, from an almost entirely Freshmen and Sophomore group. What does DCMS stand for? Unfortunately that's a secret that you'll have to use your own imagination to fill.

 My personal responsibilities (in addition to the leadership of the mechanical team) included the chassis, suspension system, and cockpit design. It isn't possible to describe the enormous effort and reward involved with being part of this great team.  I will not cover any details of the car design here, because it is not my project to write about, but instead encourage anyone reading this to check out the team blog here. To put it mildly, this has been the number one reason that updates have become so infrequent recently. I will be reprising my role as leader of the mechanical team this year, so keep posted on RPI Hybrid's blog to find out what we are up to!

With that out of the way, I can get to some of the new and old personal project updates that have been creeping along in the background. I'll give each of these their own post in the next day or so, so check back soon to demystify the last 3 pictures above.