Puma 260A robot arm (Restoration)

Thanks to the generosity of a friend and the magic of freight shipping, I've recently come into possession of a Puma 260A robot! This particular model, while small compared to most robots in industry, is exactly what I wanted as an industrial robotics novice. The 260 is small enough to not require an entire safety cage and light curtains, yet powerful enough to to do some fun experiments. Here is how it arrived right off the pallet:

Included with the arm was the Unimation controller/computer as well as some peripherals, including a double sided double density floppy drive and teach pendant. There was also an RS-232 line for serial commands, an original instruction manual, as well as a couple floppy disks containing various revisions of VAL-II (the robot's native operating system). Here's the entire setup post-unwrapping:

From the outside, the only visible flaws were some highly frayed wires and a little dust. I began by wiping off all the leaking grease and cleaning everything with a damp rag. The peripheral cords were untangled and checked to ensure none of the wire had been severed. As many of the labels state, this robot was refurbished back in '03 by RP Automation. They kindly included a report of all the maintenance they performed with dates!

Following the cleaning, a friend and I did a first power check with the controller in restart mode. The controller/computer fans started up right away, as well as the floppy drive and teach pendant. After briefly flashing the Unimation splash screen, the pendant immediately jumped to "ERROR - NO VAL", as expected.

The next step was getting a serial connection to the robot. After connecting through an RS-232 to USB converter, the robot controller finally spoke. We could successfully ask to initalize VAL about 50% of the time, but couldn't accept a response and frequently devolved into gibberish. Unable to get stable communication, I popped of the lid to the controller and started checking boards. After a careful read through the manual, all of the cards were removed and laid out for inspection:

While most of the cards appeared to be in decent condition, the processor and RAM cards were in extremely poor condition. The NiCad batteries last installed in 2003 had burst long ago, and were slowly dissolving half of the board. This corrosion had spread to nearby cards, ruining card slot edges and components. 

First, we clipped off all four of the batteries on the processor and RAM cards, noting their polarities. Using a sharp tool, I scraped off as much of the dried electrolyte crystals as I could. Those areas still coated in crystals were doused in electronic contact cleaner and let to sit for an hour. Using acetone and a hobby knife, I cleaned the card edge connector as well as I could. Some of the plating had clearly been flaking off of the conductors, but fortunately the actual copper was mostly still intact. This cleaning won't do anything to prevent the bare oxidizer from corroding more in the future, but hopefully slows the corrosion from the acid. Using replacement off-board 1.2 V NiMH cells, power was temporarily restored at the battery terminal inputs.

With all the cards removed, the slots (which undoubtedly had battery acid corrosion as well) were left to marinate in plastic safe contact cleaner as well. As the cards dried, we pulled out the servo amplifiers from the front half of the case. The cards were in excellent condition, and even had minimal dust thanks to the powerful cooling fans in the case. I took some pictures of these as well for interest. There appears to be nothing on these cards besides the power electronics for 3 H-bridges and two integrated temperature sensors. Even the gate driving circuits appear to be isolated on a separate board. That's all very well, because there wasn't much space with the huge heatsink and transistors!

The last step was re-assembling the controller using the huge quantity of pictures taken earlier and the instruction manual. I really loved how the manual actually took the time to describe the functionality and interconnection between each card in details. It was invaluable to be able to see the theory behind the inner-workings of the controller, and will make future modifications much easier.

The power-on was tense, but resulted in trouble free serial communication between the controller and PC! Every few power-ons still resulted in failed communication, but once it started successfully it usually continued to function. Now that we could talk, the next step was to load VALII into the controller from the floppy drive. After entering the robot serial number and giving it a few minutes to load, VAL was loaded and the arm could be powered up. After joyriding for a few minutes with the teach pendant, the controller crashed and auto-enabled the joint brakes. Reloading VAL fixed the problem temporarily. 

 With the mechanical functionality established, we worked through the calibration and nesting procedure outlined in the manual. Essentially this worked out to making the arm go limp, placing it in it's special nest holder, and resetting this as the calibration point. While the arm would calibrate and leave the nest successfully, moving from ready-position back to nest usually failed. The last two joints would just barely collide with the nest and then deflect out of position. Repeated calibration attempts didn't result in any improvement. The manual describes further procedure recommendations for this situation, so we may have to try those next time. 

What we did notice were repeated software crashes. It appears that the controller memory forgets its OS at some non-determinant time after loading, resulting in a full robot lock up that requires a power cycle and VALII reload. Reading the documentation indicates that this may be the CMOS memory, which has a recommended replacement date of three years after installation...which was probably last done 12+ years ago. I'll be investigating to see how realistic a memory replacement is.

My ultimate goal with the robot, however, is to move away from the VALII operating system. As amazing as this legacy system is, it is highly unstable and severely limited in capability and memory.  A new processor and controller board (possibly a 32 bit Atmel chip) could give me the freedom to stream live commands with a buffer, allowing rapid feedback between the arm and a PC. This would open up a world of possibilities, including integration with off-the-shelf camera systems like the Kinect. Replacements to the servo amplifier system could also be made, but would be considerably more costly. 

Ideally, I'll be able to find a way to integrate a custom controller board with the existing power electronics. This is the least expensive path, and also makes the most use of the original system which I want to preserve as much as possible. My preliminary observations indicate that interface card B might be the best place to make the transition, but I'll learn more about how "hack-able" the system is after doing some probing.

Restoring the control electronics will be a slow and expensive process, so it may be a while before the next update on the PUMA 260.

MechEtroller 1.3: Still Trolling

Far from stalling at version 1.2, MechEtroller 1.3 boards arrived in early January 2015, While still full of problems, I'm happy to report that this version has been the most successful yet!

1.3 uses a similar D2PAK FET package to 1.2, but with a revised layout. I'm finally convinced I've got a pretty efficient FET configuration which maximizes power track cross-sectional area, minimizes trace length, and provides very convenient diode locations. Disadvantages include having no great location to put the hefty power rail capacitor, slightly more complicated heatsinking geometry, non-unified power input and output thru-holes, and a loss of  symmetry.

There are also a number of other improvement over 1.3 besides fixing schematic mistakes.The series linear power regulators are much larger, not because the current draw has increased, but because I had serious reliability problems during debugging with the less robust smaller LDOs. Encoder input is now supported, and is now routed to the 328 interrupt pins, The logic side layout is also more clean in my opinion.

Soldering was uneventful and decently easy given the wide spacing of components. Power inputs worked right off the bat, as well as microcontroller bootloading and programming. Even gate driver triggering worked smoothly with no load. As soon as the drivers began triggering the FETs while they were under load, however, the board began experiencing an uncontrolled resetting symptom. For a week I probed, soldered, and desoldered, convinced that poor capacitive decoupling somewhere  in the voltage regulation,  logic circuitry, or gate drivers was causing a low voltage dropout (triggering a reset until voltage levels rose again). After going through a number of capacitors and inductors of various sizes, I eventually discovered a crucial schematic mistake.

The capacitors on the gate drivers were accidentally placed across the Vrail and output of the driver, instead of ground. I don't know exactly what kind of nonsense effects this had inside the driver, but it wasn't very productive. 4 point to point soldered caps later, and the board could actually drive a motor! 

After powering a couple small test motors, I ramped up the testing to a more challenging 24 volt electric scooter motor, powered by a Lithium Iron Phosphate battery pack rated at up to 800 A output! Quickly, it became apparent that further FET heatsinking was required. At first, in keeping with the low production cost goal of the project, I designed a simple flat aluminum plate that mounted to the top of the controller.

After some testing with a handy plate of copper, however, it became apparent that this was no where near sufficient for the heat output! So in order to continue testing, I grabbed some relatively cheap heatsinks and thermal epoxy off of Amazon and mounted it on.

I'm pretty sure this represents the biggest heatsink that can reasonably be fit on a controller of this size. An absence of time and proper equipment limited the extent of testing that could be performed with this setup, but the results were pretty impressive. At least one chair in the lab now has a small hole where a vise-grip clamped motor used to be. Despite the much improved heat sinking, temperatures were still quite high everywhere on the FET side of the board (even when driving smaller loads). For an unknown reason not too after this, at least one FET shorted out and ruined the prototype. It could have been a random metal chip or maybe something about the heatsink itself, but the epoxy didn't allow much of an opportunity to take it apart.

It wasn't until much later that I learned why the bridge operated so inefficiently. For a long time I've read of N-channel MOSFETs described as being "low side" transistors. Blissfully unaware of the ramifications of this, I've been using the same transistors (and more importantly, the same gate drivers) for FETs used on both high and low sides of the h-bridge. The problem (if not obvious already) is that the Vgs or gate-source voltage of my IRFS7537PbF FETs needs to be approximately 12 volts to operate with the lowest possible on-state resistance. However, in an H-bridge, nearly all of the voltage drop occurs across the motor, meaning that the voltage at the source pin of the high side FETS is dictated by the raw battery voltage feeding into the controller. If I was feeding the controller with a 24 volt battery, I would need a 36 volt (relative to ground) gate voltage to produce the required 12 volt potential between gate and source. Talk about a big mistake.

But hey, it's all a learning experience. As a bonus, now I won't be forgetting anytime soon. Solutions to this problem include: using a p-channel MOSFET or finding a gate driver that can dynamically boost its voltage to activate a high-side n-channel FET. It turns out that finding p-channel FETs with the same power rating as my existing n-channels is difficult and expensive, So that leaves the more complicated gate driving circuitry as the winner. Fortunately, Digikey (and Allegro Microsystems) are happy to help with the A4940 full bridge driver. This awesome chip packs all four gate drivers needed for high and low side n-channel FETs into one package with a bunch of bonus features. This will be my platform for version 1.4.

The list of changes I'd like to make in the next iteration includes:

• Swapping out the four individual gate drivers for the A4940 chip

• Overall cleaner component layout, particularly with the capacitors for logic components

• Simplifying voltage regulation down to just one regulator (thanks to the A4940)

• Switching to a surface mount crystal (just to standardize)

• ICSP header (it's not worth the hassle of using a pogo ICSP programmer when I have the extra board real estate)

• Possibly using FETs with a lower Rds (at least on the high side)

• Larger reverse polarity protection diode on the voltage regulator

• More capacitance across the power input (to provide buffering for larger motors)

Version 1,4 will get it's own update when the boards arrive,

3d printer updates 3: Almost there (for real)!

When I last left off, the mechanics of the 3d printer were near enough complete, with the wiring closely following suit. This progress and the progress that will follow all occurred in only a few days between the RPI Formula Hybrid season and final exams (hence the abrupt halt in work and weak photo documentation).

Now that the (substantial amount) of wiring was in a test-ready state, I began the process of tweaking Marlin (my open source controller firmware of choice) and debugging stepper motor connections. For a long time, I kept getting very strange "stuttering" effects from the steppers. I found the culprit to be a combination of swapped wires, poor limit settings in Marlin, and uncalibrated current control potentiometers on the stepper drivers . Once the x and y axes were moving smoothly (and scaled to correctly replicate mm inputs), I switched attention to the z.

The new NEMA 23 stepper motor was working great on the z, right up until the moment when it wasn't. Every time that the motor passed a certain point during upward travel, the speed would bog down, an unpleasant noise would be emitted, and usually the leadscrew clamp would slip. Initially, I though this was another case of misaligned guide rails or screw marring, but it never occurred on the downstroke, and worked fine at every other place on the rail. Many tests later, I finally noticed an edge of the aluminum rear panel that had warped in far enough to catch the gantry when it slid up from below. The motor had literally been trying (and failing) to tear the machine apart! With no immediate fix available, I simply shimmed the z-axis rails a fraction of an inch inwards by adding a washer to all connection points. This solved the problem, and shouldn't have any effect on accuracy due to the 3-point leveling build plate.

After fixing another relatively minor mechanical problem (incorrect build plate spacing), I was finally ready to tackle the extruder: one of the few parts on the entire machine I just purchased instead of designed. The extruder was a MB8 knockoff with no frills, bought more than a year ago for the initial 3d printer project. Initial wiring went well, with the thermistor responding properly and the hotend heating relatively quickly. A small amount of smoke was produced at full temperature, but I attribute this mostly to months worth contaminants and grease that had been collecting on the surface. It gradually stopped smoking after being on for a while.

Unfortunately, after loading it up with filament, things started going wrong. The first few inches of filament would readily squeeze out the end of the nozzle, and then slow to a crawl. Meanwhile, the internal driving gear would grind away at the seized filament, jamming the extruder and necessitating a tedious teardown of the assembly. About 10 time-consuming disassemblies and reassemblies later, I determined the cause of the problem to be unacceptable heating of the brass feeder tube leading up to the hot end. Before the filament had even reached the nozzle of the hot end, it would have already become sufficiently soft and malleable (technical term: gooey) to buckle over itself and stick to the walls of the tube.

I quickly came to understand that I needed a dramatic temperature transition between the feeding tube and hot end to allow the process to run as intended. There was nothing I could do about the conduction up through the brass tube, but I had hope that I could at least introduce some forced convection on the midsection of the tube. The ideal design would have circular concentric fins running up the tube with a fan blowing over them. With the night getting late on my last day to work on the project, I went for a hail mary option.While I ran over to the machine shop to turn a crude aluminum heatsink, my friend biked to the local (not yet shut down!) Radioshack to grab some Arctic Sliver heat paste. The result was a marginally better hot end:

With only a single (wide) parting tool left unbroken in the shop, and no time to grind a new one, I was only able to get two fins out of my stock. Despite the improvements, it still was not enough to get the extruder functional before the deadline. With no time to order a new one before flying across the country to California, the printer has sat at RPI all summer. While I'm sad to have to wait so long to finally see it run, I'm at least glad that many of my design elements that I was most concerned about worked. 

With the printer on my mind's backburner all summer (as I've been busy having too much fun interning at Tesla Motors), my eventual plan was to do a full extruder swap with whatever the internet claims is the best design. The downside, of course, is that this also requires re-waterjetting a new mount plate and possibly more parts to ensure functionality. So imagine my surprise when browsing Amazon revealed this. I love it when pictures in my head turn out to be real things! While it is not compatible with my extruder design, I'm excited enough about the design that I intend to buy one and modify it to accept the new hotend. If that too fails, I may have to plan on the original full replacement.

In the near future I'll try to write an update about the continuing progress of MechEtroller, a build log of an exciting year-long Formula Hybrid project, and possibly something relating to this:

More 3d printer updates: close to the finish!

It has been a long time since I've had the opportunity to post updates on some of my current projects. I'll be posting a number of more detailed updates on my motor controller, 3d printer, and Formula Hybrid related work in the near future. For the moment though, it's time to continue the printer build log. This will probably be more of a picture dump than I normally like to do, but there is a lot to catch up on!

In the last update, the last of the vertical milling operations were completed, and the frame was coming together for the first time. The frame was completed with no major problems, and the laser cut side windows installed perfectly. Installation of the z-axis, as predicted, was problematic at first. A number of tests with the Nema 17 motor revealed that the oil infused bronze bushings were creating more friction than I had anticipated, even with the flexure mounts doing their job. I deconstructed the z-axis and extensively reamed the bushings to loosen the tolerances slightly. as well and went through a much more careful alignment process as I re-tightened the t-nuts. Finally, I manually re-milled the motor mount bracket to accept a Nema 23 type stepper with almost double the torque. The z-axis movements are now extremely smooth and precise.

The x/y gantry mounts arrived from Shapeway looking great. Amazingly, the snap fit mounts I designed into the holders worked perfectly with the linear bearing, requiring no sanding or modification. I really have to compliment the SLS Nylon 3d printing process, the detail is fantastic, and there appears to be far less internal stress between the layers than with FDM prints. It took three design iterations before I got the components to a point where I was happy with them, but I think they turned out well:

The x/y gantry installation was a breeze. As a design note I may have forgotten to mention last time, the machine is composed of two pair of parallel shafts representing the x and y axes. An additional two shafts going across the machine transmit mechanical power to the timing belt pulleys running the belt behind the plastic bearing holders. This is visible in the image below. The coupling for those transmission shafts to the motor is seen at the lower right hand side.

This motor coupling turned out very nicely, and seems like it will be fairly robust:

 While a certain amount of dremeling was required to widen the tension adjustment slots for the transmission rods, once complete and lubricated the system worked well. The last major installation was the heated bed. After drilling and tapping the mounts for the standoffs, it appears that the spring leveled bed is going to work well. One last mechanical touch was the base plate. Initially the entire machine was going to sit on rubber feet to minimize vibrations, and keep a number of machine screws sticking out the bottom of the z-axis from colliding with the table top. However, though an incorrect product description or shipping mishap, I ended up with the wrong type of feet. Instead of returning the product. I just worked around it, milling a plate of HDPE for the feet to screw into and the printer to sit upon. A CNC router error means I may remake this part in the future.

This bring things back to the present. With the mechanics looking good, the process of wiring all the components together has begun. I've decided to route everything to a box at the back for simplicity, and keep the power supply separate. I'm also taking my time to ensure that all routes are as clean as possible and the connections are solid. Initially, I purchased 4 conductor automation wire from McMaster, concerned about the frequency of flexing that the cable would need to endure. It turns out the gauge was too low to fit in the terminal blocks of the Azteeg X3 controller, so I went back and just purchased some cheap 22 gauge alarm system cable instead. Remarkably, it appears to be just as good as the more expensive stuff so far, and even comes with shielding and a strain relief cable. Blue mesh wrap and zip tie strain relief keeps the cables safe and looking good.

I decided to pass on using connectors for this project due to the price. Instead, all wire just goes through grommets into the electrical box. Hopefully I will have the change to finish the wiring and begin working with the firmware over the next few days. Last but not least, I finally got the led lighting installed:

That's all for now, check back soon for a lot more updates.

Miniature Balancing Robot: first test

My miniature balancing robot is up and balancing! The new IMU sensor board implementation was easy and painless, and now I'm in the long (and probably never ending) of playing around with P, I, and D coefficients for the control loop. I've achieved balancing on carpets and temporary balance on hard surfaces so far. The small wheels, short distance between axis of rotation and center of mass, and poor vibration isolation of the IMU is making more optimized balance very difficult. Any proportional gain high enough to keep the bot upright on a hard surface is enough to generate high frequency oscillations that I can't easily address. Thus far, I've experimented with low-pass filtering the derivative output and filtering of the total output with little benefit. I've also attempted mapping the proportional gain exponentially to allow for higher gains at the extremes without jittering at low angles, but without much success. Next up, I may try optimizing the program to eliminate trig through a lookup table and certain floating point operations to speed it up. Problems aside, I am very pleased with how well the first iteration has worked!:

New Project: Miniature Self-Stabilizing Robot

With RPI's machining facilities inaccessible to me over winter break, I decided to pursue a new project to keep boredom at bay. My custom 3d printer project is still back at school awaiting parts that I will install when I return, and the third revision of the mechEtroller motor controller is awaiting new PCBs. So what to make that's cheap, interesting, requires no machining, and can be done in a few weeks?

It turns out that my answer was a tiny robot. Similar to the full sized Segway-like electric scooter I build in high school, I wanted to make a inverted pendulum bot. This time, however, with some differences:

• Small enough to fit in a (largish) pocket
• Properly coded and tuned PD control loop (the big scooter required some balancing skill on the part of the driver)
• Polished and professional looking electrical design (No vecro'ed Arduino Uno and rat's nest of jumper wires)
• Robust chassis that can take the inevitable repeated falls
• 30 minutes of run time, and integrated lipo battery charging
• Wireless control and telemetry

I thought long and hard about encoding the drive motors, but ultimately decided against it, as it would raise the cost and size of the build. I'm also looking into doing some extensive work with encoded motors in a much more ambitious future project. I began with the motors, as they would be the biggest determiners of the chassis footprint. I could have certainly gone smaller with my selection, but I wanted a gearmotor for the speed reduction and torque. A non-geared option struck me as being much harder to control and more prone to stalling when traversing obstacles (not that it's much of a concern either way). I ended up choosing the 50:1 micro geared motor from The Robot Marketplace, and picked up a set of matching 32 mm Pololu wheels to go with them. Now I had some dimensions to work with, so I CADed the motors and wheels and began sketching a chassis outline. With a good handle on the scale I was dealing with, I settled on 3d printed Nylon as my chassis material of choice. With the 3d print services from Shapeways,com, the Nylon (their "flexible and strong" material) was inexpensive and elastic enough to resist shattering. 3d printing also allowed me to design pretty much any shape and contour I liked (barring any thin geometry), which was a nice change from designing for manual mill or lathe work.

The upper half of the chassis was going to be designed around the PCB, so I switched gears and begin researching components. Optimization was of less priority than ease of integration and support documentation, so I focused on parts that were more well known. The venerable ATmega 328 processor was an easy choice (although I want to branch out more in the future). Wireless communication was also kept simple with an Xbee module header. The gyroscope and accelerometer were a little bit trickier. While I tried to find some hand-solderable surface mount components on DigiKey, it appears that the smartphone industry has hyper miniaturized the modern versions of these parts. Options which did not require reflow were generally highly specialized or highly expensive (or more likely both). So I retreated back to Sparkfun and settled on their 6 dof IMU, which kept everything  a lot simpler. This will be attached with a soldered header on the PCB, which actually helps save a little space. I also included an 5v to 3,3v I2C converter chip in the design (because the IMU ran on 3.3v), which I later determined was unnecessary. While I was ordering from Sparkfun, I selected two of their 1000mAh single cell batteries (3.7 volts per cell). In my testing of the motors, they appear to draw around .25 amps at 7.4 volts when changing direction after freewheeling, and can apparently reach around 1.6 at full stall. Given that the robot should only utilize a small fraction of the total torque, and that amperage is proportional to torque, I expect that it will easily exceed 30 minutes of run time. For driving the motors, I selected an integrated dual H-bridge chip with lots of support documentation from around the internet, the TB6612FNG, from Toshiba. While the control scheme seems a little input heavy, the operation of the chip is relatively simple and robust. It can handle 1.2 amps continuous and 3.2 peak, which is perfect. Last but not least was the charging support for the batteries. I found the MCP7384 line of dual cell charge controllers, which promises to do everything I need and much more. I've never spent much time looking at charge profiles for lithium polymer batteries before, but the datasheet for this was eye opening. I have never attempted to use a chip like this before, so there is a good chance my implementation may not work. Once all of the components were put into the schematic, I began the process of laying out the board:

The silkscreen rectangle at the bottom of the board illustrates the outline of there the IMU will sit. This board was also my first time integrating JST connectors, which I like a lot, The trick is to cut off the connector retaining nubs on the male plug if you ever plan on removing it. Finally, there was a lot of empty space going to waste underneath the Xbee, so I put some slightly over the top diodes for the motor controllers beneath there. Now that the board was done and sent to fabrication at OSHPark, I could finalize the mechanical side. I directly exported the Eagle board outline to a .dxf, which was opened in Solidworks and converted to a 2d sketch.This gave me the final dimensions needed to complete the chassis. 

I had a couple schools of thought on how to tackle the chassis design. In a strange departure from the Formula Hybrid car chassis and virtually every other electric vehicle I've built, weight really wasn't much of a concern here. I didn't need to design a nodal space frame or trussed structure for something this small. I played around with the idea of making a completely enclosed shell for a while, with a design similar to that used in plastic injection. While it would keep dirt and water out, it would make debugging more miserable and be more expensive to print. Given that the operating environment would primarily be on a desktop, an open design would work just fine. So I ultimately focused on making a structure that was easy to mount to, rigid, and capable of protecting components in case of a fall. An extruded I-beam shape was the natural result, with the batteries on one side of the web, and the PCB on the other. The extrusion was terminated with wheel hubs which continued down to support the motors at the bottom.

Mounting standoffs were printed in to the PCB's exact dimensions, and a slot was cut out of one of the chassis sizes to access the charging port. The motor compartment at the bottom was slotted for dubious cooling purposes, but otherwise dimensioned exactly to the gearmotor size for a tight fit. While keeping the center of mass farther from the axis of rotation makes balancing easier, this also impacted the overall size of the chassis. While it isn't visible in this picture, there are slight slots cut into the other size to help hold the batteries.

Here is the full assembly, complete with guesstimated wheels because Pololu didn't feel like giving more than 3 dimensions. I sent all the orders out, and waited 2-3 weeks for all the parts to arrive. The chassis came before the PCB, and the quality was fantastic. I would definitely use Shapeways again for prototypes. While RPI has commercial grade 3d printers and there are a smattering of hobby grade printers among the student body (soon to be joined by mine), it's hard to get parts printed in anything but ABS or PLA, and the quality is highly variable (in the case of the hobby printers). I got the blue polished option, which erases most of the interface lines between the plastic layers and leaves the part with a nice, almost sand blasted matte finish.

Nailed the fit

The PCB arrived shortly after, and was immediately soldered:

Shown here without the Xbee or IMU

The Arduino bootloader burned correctly the first time, and well as the power regulation and the battery inputs. When I went to solder the I2C voltage converter, though, I found the first problem. Apparently the chip footprint I used on the PCB was vastly larger than the actual chip size. After more research, the internet consensus seemed to be that a voltage converter wasn't necessary with this sensor, so I bridged the correct pins with fine strands of copper wire. Next up I tested the IMU sensor but not before accidentally connecting it backwards. Note to self: always indicate the orientation on the PCB. While I was eventually able to talk to the IMU over I2C, the acceleration outputs I was getting were highly inaccurate and jumping all over the place, I strongly suspect that the reversed connections damaged it the first time, so I have a new one being shipped now. With the IMU out of commission for the moment, I moved onto the motor controller. While the motors were originally intended to be bolted in from the front of the gearbox, I learned when they arrived that these holes were thru drilled instead of tapped. The only real way to mount these seems to be tiny screws or an external holder. Given the tightness of the fit already, I just used some JB weld around the bottom of the motor cans to mount them permanently I soldered the motor leads, loaded some sample code, and to my surprise:

It worked the first time. Now hopeful that I would not need a new board revision, I soldered the Xbee headers in, finishing the board. This is where the robot sits at the moment. Assuming the new IMU arrives this week, it should be optimistically possible to get a proof of concept working in the near future. Stay tuned for more updates coming in the next few days.

Return of MechEtroller, revisions 1 and 2!

Way back in the warmer days of September, I posted the creation and almost immediate destruction  of my first brushed motor controller, MechEtroller. While the result was unsurprising given my limited experience in power electronics and PCB design, I'm won't let this project die with only one failure. I'm a huge advocate of learning by doing, and each MOSFET detonation is another valuable piece of education in how not to electronics! So the adventures of a MechE student attempting to build a robust, compact motor controller continues.

 Not long after the voltage regulator smoke cleared, I embarked on the revisions to solve the grounding issues that plagued the first version.

If only it happened this quickly in real life

No new features were added in this iteration, only an attempt to resolve the problems I identified last time and some rerouting. I also took the more intelligent approach of soldering this board in bite sized pieces, moving in the order of voltage regulation, logic control, and MOSFET control. Almost immediately, I identified a new problem. I had apparently foolishly assumed that just because both regulators were from the same company and had the same footprint, that the pin breakout would match. This meant that the 12 volt regulator was out of commission, so I bypassed it by jumping the pins with a small strand of copper. This was less catastrophic that it sounds, because the 5 volt regulator could handle up to 12 volts, and that was the exact voltage needed for the gate drivers. So, with the board now connected to a carefully dialed in variable power supply, I continued onto the ATmega 328 microcontroller and peripherals. The power LED was still giving the all clear, indicating that there were not immediate shorts, so I went ahead and burned the Arduino bootloader onto the chip through an ICSP pogo pin programmer...

...and it started right up, blinking the status LED just like it should. Neat! I took the opportunity to test the FTDI header breakout and confirmed that the test program uploaded successfully. With the simple stuff finally working, I moved onto the FETs and gate drivers. I send a 5 volt signal to the gate pin on the driver and measured the output. The multimeter read 0 volts. Back to the datasheet. Further investigation revealed that the XREF pin of the FAN3111 driver had been mistakenly tied to ground rather than logic voltage. Whoops. Another lesson to read the documentation carefully and not submit PCB designs at 2 in the morning. I spent a little more time chasing down another strange problem involving voltage leaking across a MOSFET, but after examination and input from some friends, concluded it was a result of not cleaning the flux from soldering. 

Excited by how much closer revision 1 had gotten me, I decided to get a little more ambitious. I was dissatisfied by the FETs I was using, now firmly convinced that their tiny size was just too limiting of thermal dissipation. The pitch spacing on the pins was also a concern, just inviting a tiny metal shaving or solder blob to lodge between and ruin a lot of work. I also wanted to include a current sensor, so it could begin making intelligent power control decisions. I settled on the IRLS3036 for the FETS, due to their relatively cheap cost, acceptable Vgs vs Rds relation, and hefty D2Pak footprint. This footprint also gives me the ability to easily upgrade to better components when the detonation danger level has dropped. I chose the ACS712 hall effect current sensor because it was the cheapest component that could measure up to 30 amps (a somewhat arbitrary design requirement that I decided on when starting the project).

The increased footprint of the FETs is pretty obvious right away. You can also make out the current sensor pads to the left of the battery voltage plated hole. Populating the board was uneventful with the exception of a tiny solder bridge from one of the gate drivers shorting to a ground via. Once fixed, power regulation and the microcontroller operated normally.

Now uglier and covered in sawdust

Before soldering the FETs, I ran through each of the gate drivers, checking to see that they outputted the 12 volts being supplied to the gate pin when driven logic high. Everything checked out, so I added in the MOSFETs. Immediately there was a problem. Everything powered on fine for about a second before the microcontroller began switching the outputs. Then, a brief current spike would occur and everything would reset and repeat the process. I tried to track the source of the shorting in numerous ways, before finally deciding to just allow the board to draw more current and seeing what got hot the fastest. The board sustained about three seconds on an electric drill battery before smoking in multiple areas, but it was enough time to see the issue. Somehow, certain MOSFETs were conducting even when their gate pins were low. The only way I could imaging that happening would be voltage spikes over 60 volts (impossible), or that the current was flowing source to drain. I checked the eagle schematic and confirmed my suspicions. In my eagerness to copy and paste the new FETs into the schematic, I had accidentally flipped the position of two of them. Another facepalm moment, but another opportunity to add more functionality in the next revision...