This video is from 2.12 (Intro to Robotics), a class I'm taking this semester. I got a Sparkfun MPU6050 Breakout Board to talk to an Arduino Nano via i2c, which then communicates with my Ubuntu laptop via Serial. A Python program interprets the Arduino serial signal as outputs of the sensor's Accelerometer[meters/(second^2)] and Gyroscope[degrees/second]. A second order complementary filter (More info on these style filters in Shane Colton's Blog) then interprets these signals as pitch, roll, and yaw angles. Which you can see on my computer screen represented as a line.
Updates on Melonchopper's build and more details on 2.12 coming soon!
A few weeks ago, in a search for inspiration for a new mechanical build project, I came upon the following Youtube video:
Needless to say, I was, well, inspired. A Delta Robot is a type of parallel manipulator developed by Raymond Clavel as a professor at his alma mater, the Federal Institute of Technology of Lausanne, Switzerland. It is a design that was engineered to solve a very specific problem: high-speed high-precision pick-and-place manipulation of small, light objects in a manufacturing environment. Circuit Board population comes to mind, as does I Love Lucy.
It is a 3-DOF robot whose end effector can move in XYZ, but cannot rotate in Pitch, Roll, or Yaw. Through clever geometry I have yet to fully comprehend, the end effector is always parallel to the base. There are 3 two-link arms (the bottom link being twin parallel links) which are actuated by three feedback-controlled motors at the top. The top links are constrained by the top actuators but the bottom links are held to the top link and end effector by ball joints.
Before I could build one of these, there are some questions I need answered:
What are the robot kinematic and differential equations? (Find end effector position and speed (X, Y, Z, Vx, Vy, Vz) based on actuator angles: (Theta1, Theta2, Theta3) and their first derivatives). Also Inverse Kinematics (What Theta1, Theta2, and Theta3 are necessary to get the end effector to a desired XYZ?))
What magic engineering makes the end effector always parallel to the base?
Why do most Delta robots I see online have L1 (topmost link) smaller than L2 (the second, bottommost link) ?
What will changing the lengths of L1 and L2 do to limit or enhance my workspace range?
Where should my workspace be? If I am picking and placing, how high above my work plane should I put my robot? If I am 3D Printing?
How should I alter my transmission to be able to bear more load, gain more speed, or gain more accuracy?
What is the greatest load I can bear before the strain (% of deformation) on the links becomes unacceptable? (unacceptable being greater than my design end effector positioning tolerance, which I will now shoot for the stars and make an arbitrary .001" in X Y and Z. Interestingly enough, the layer size (and thus accuracy) of a MakerBot Replicator 2 is .1 mm, equal to ~.004". If I can achieve comparable or greater accuracy than a MakerBot Replicator, I can totally use this as a 3D printer!)
Finally, how can I improve on this design?
Here is a Solidworks assembly I put together in a few hours by looking at a bunch of designs online. This is nowhere near a final product, but it is to help me visualize the robot while I work out the kinematics. In this attempt I made L1 and L2 the same length (L1 = L2) and the size of the Base and Effector exactly the same.
Here are the top joints, whose angles make up the robot's generalized coordinates, thetaOne, thetaTwo and thetaThree. These will eventually probably each be driven by a geared motor with encoder feedback. Like my Pittman 655s.
Both joints for each of link 2's twin links are ball joints, which each have two rotational degrees of freedom.
As you can see in the above photos, the DeltaBot end effector is indeed parallel to the base platform. I've determined this to be due to the fact that the each arm is identical (L1_1 = L1_2 = L1_3, etc) and the bottom links of all L2s are tethered together. But why? Pretty soon I'll start applying all this 2.12 I've been doing and work out the forward and inverse kinematics. Between all this schoolwork. And Melonchopper. According to Shane, the difficulty of solving the Delta robot forward kinematics is more difficult than solving the inverse kinematics, which is completely opposite from your standard serial link manipulator. I'll asplain later. I have a Pset to finish.
I got a new job at the Biomechatronics Group in the MIT Media Lab. But that's not what this post is about, it's about the
RASPBERRY PI!
What is a Raspberry Pi, you ask?
SO CUTE! ^_^
A Raspberry Pi is a full Linux computer the size of a wallet. Its 700MHz (256MB RAM) ARM CPU/GPU runs off a 5-volt 1-amp power source, like a phone charger. It has a built-in ethernet, USB, HDMI or composite video out, a useful GPIO (So you can set use IO pins like an Arduino, use UART, SPI, I2C, and other communication protocols). You can plug in a USB hub to use flash drives, keyboard and mouse, a WIFI adapter, an external hard drive... It's supposedly $25.00 from the manufacturer, but an Amazon search puts us at $79.95 for the latest one, Rev B. Not bad for Amazon Prime free 2-day shipping. As for availability, it tends to go out of stock often. I feel this was a bigger issue in the past, though. I also highly recommend purchasing Raspberry Pi User Guide, written by Eben Upton, Co-Creator of the RPi. It not only details the RPi itself, but the recommended modified version of Debian Linux it runs. The Raspberry Pi and this book is an excellent way for anyone to become learned in Linux and python, two skills I deem highly valuable in being able to get things done. The Raspberry Pi is a really nice next step up from an Arduino in terms of DIY Electronics projects. The RPi is perfect for hobbyists looking to use the massive catalog of software available for Linux with the simplicity and speed of Arduino. Funny thing is, this Raspberry Pi is being used for Legit Research. (We're using a $800.00 Maxon motor, a $740.00 Servo Driver/Controller, an external fabrication shop to make our parts...)
After a few attempts to flash the RPi "Raspian" Raspberry-infused Debian OS onto a 32GB SD Card (The main storage method of an RPi), I managed to get write the image in Windows. After booting up the Pi, you log in with user "pi" and password "raspberry", and are at the main command line. To start the LXDE GUI, type in "startx".
YAY!
It comes with Python IDLE, Midori web browser, and other useful little tidbits. It's an $80 Linux box the size of a wallet running on all solid state hardware (No spinning hard drives to deal with). Catch is, it's SLOW. Doing anything on this reminds me of back when my primary computer ran Windows ME. Those were dark days indeed... However, this thing is so tiny, so cute, so inexpensive, so available, and so powerful for the size, that I am SO putting one of these on a robot one of these days.
I use Solidworks extensively in my mechanical designs, and I've used ROS before in the context of mobile robotics. Given my love for armature robotics, I will soon be using ROS for visualization, control, and planning. Now imagine my glee when Willow Garage announces the fruit of one of their summer 2012 interns's efforts: a Solidworks to URDF Exporter!
URDF is an xml-style file format for representing the mechanical properties constraints of your robot. For example, you can have a number of links tied by some revolute joints (generic serial link robot), or a base link with many children and degree constraints for each DOF (Like a robotic human hand). Mobile robots can even utilize URDFs for determining where certain sensors are relative to the base link, etc. TurtleBot's pre-written URDF file contains information on where the wheels are relative to the base link, as well as the position of the Kinect, for the odometry and vision code to use when calculating position or detecting objects. For more information on URDF, check out this presentation from ROSCon 2012:
And It's available like right now right now. I download the file in the above link and try to install it, but:
DAMMIT. I'm running an x86 OS (32-bit) and this program requires a 64-bit OS. I may try to rebuild it from the available source (YAY OPEN SOURCE!) or even modify the code if need-be. Or I can wait until the 32 bit version is released, even email the developer and see if he needs help/motivation in the 32-bit implementation. Also, I want to intern for Willow. They're a kick-ass company, and I believe in their vision for how (the royal) we will advance the field of robotics, through corporate backing open source research. I'm a bit nervous to apply just yet, because I feel I can offer them so much more to judge me by if I apply after I've finished playing with my TurtleBot and using ROS to command TinyArm and design and build DeltaBot and- DeltaBot? What's that?! DeltaBot is a future personal project of mine, scheduled to be completed by the end of January 2013 at the latest. It's this:
A Delta robot is a parallel linkage robot used in manufacturing which has 3 DOFs, X Y and Z. No rotation in this configuration. But mine will be on the scale of this one:
Which is a design I really like and am going to use as my main reference. In fact, I want to contact the make of the above little Delta robot and commend them on how nice their design is. When you stand on peoples' shoulders, best thank them and let them know what cool things their efforts paved the way for =]. Mine will be commanded by 3 of the 7 Pittman motors I bought a couple weeks ago. They will be geared down to allow a higher encoder resolution and payload, and controlled by my trusty XMega16a4u because I have experience with the chip, it runs at 32 MHz leaving me plenty of speed for high-precision motion, has 3 built-in quadrature encoder decoders, and I still have a bunch leftover from my TinyArmTroller project. OH and I got a few samples of these from TI, which have integrated gate drivers and everything. At 12 A peak, 6A continuous, these are perfect for the 10A peak Pittman motors. SO MUCH BLOGGAGE COMING SOON! ENCODER DECODING! MOTOR CONTROL! KINEMATICS! YAY! Oh, and I want to control it with this interface:
Yupp. Freaking sick, right? The future is bright! Blog post on DeltaBot's design coming as soon as I design DeltaBot ^_^!
You caught a wild TurtleBot! Would you like to give your TurtleBot a nickname?
....no.
TurtleBot has been added to the list of things I should blog about!
The Willow GarageTurtlebot is an open-hardware, low-cost, mobile personal robot platform that runs on open-source software. It consists of an iRobot Create, Aluminum standoffs and lasercut platforms, a Microsoft Kinect, a circuit board containing a Kinect power regulator and a single-axis gyroscope sensor, and an onboard laptop to interface with everything and bus data to a separate offboard workstation using Willow Garage's open-source Robot Operation System software (universally known as ROS).
Check out this overview of the TurtleBot, which just skims the surface of its potential:
Thanks to the ROS community's strong efforts to make difficult low-level problems such as motor control, computer vision, navigation, mapping, etc easily implementable, DIY roboticists, hackers, and even university researchers can very quickly develop high-level solutions to high-level problems like getting you a beer. The software base thus allows you to stand on their shoulders to achieve your goals.
The release of the Microsoft Kinect, and the reverse-engineering of its protocol, marked a giant leap forward for DIY/low cost robotics everywhere. Now, a lab could own five Kinect-enabled robots for the price of one with a LIDAR. Anyone could just purchase themselves a Kinect and develop amazing software utilizing its 3D sensing. The TurtleBot is the manifestation of this Kinect revolution, offering a standard and robust platform for professional-quality Kinect-powered mobile robotics.
The iRobot Create base contains the wheels, drivetrain, drive electronics, battery, a wide variety of bump/distance/cliff/encoder sensors, and a parallel port for I/O, in a well-engineered $200.00 package. Essentially, a Roomba sans vacuum cleaner.
Mounted on this base with aluminum standoffs are four platforms made of lasercut MDF for mounting or storing various "required" and additional hardware such as an onboard laptop, a Microsoft Kinect, or an optional robotic arm or something else on top.
Or this Turtlebot's nifty beer tote I found on Google Images.
Like most projects I am going to spend a good chunk of money on, I spent days whether or not I should buy the thing. Then irresponsibly and in a sleep deprived state, I bought the $219.00 iCreate+Advanced Battery+Quick Charger package. Soon enough...
...I had it in hand!
The product is very well constructed, from a design standpoint. Plenty of sturdy injection-molded parts held together with reputable hardware: I don't feel afraid to rough the 'bot around. In fact, when I ran the basic "Explore (vacuum) This Room" demo, it would drive right over cables and other objects (rather quickly, I might add), or just shove them aside altogether. Its large front-mounted dual-bump sensors hit obstacles quite forcefully, but the robot kept on going.
There are three command buttons at the top of the robot, each with its own indicator light. For mounting hardware, iRobot put four 6-32 tapped holes on the top surface, allowing one to easily attach standoffs or screw peripherals to the Create. Taking a further look I found a DIN port for Serial/USB control (with the included cable adapter), a charge port, and the Cargo Bay Connector, which allows you to access various internal Create I/Os and drivers, Battery power and ground to convert as you please, regulated 5V power for peripherals, and other paraphernalia.
When you pick up the robot while it's running, it stops its drive actuators and lets out a cute little "Uh Oh!" sound (^_^ SOO CUTE!!!). This is handy for when your robot is about to do something stupid like harass other MITERS denizens or unexpectedly drive out of MITERS and start exploring the hallway -_-. The killswitch occurs likely due to switches that exist on the wheel mounts, which open when the robot is lifted off the ground. Here you can see the spring-mounted caster and drive wheels (which I have yet to determine the power characteristics of). Not shown is another smaller caster wheel mounted opposite the front, which enables the Create to take on a larger load. When you set the Create down, its weight is enough to depress all three wheels.
It's useful to note here that the iCreate has built in cliff sensors, which can sense the lack of floor right in front of it if it drives toward, say, stairs. Or the end of a table, like I had it run. I left the robot driving on an empty table for a few minutes, without robot-injury. I'm sure my poor robot didn't appreciate being so isolated, though :c.
I'm not building an army, I swear...
Now that I actually had a $219.00 robot to care for in hand, it was time to give it some standoffs and platforms. I could have ordered the parts online pre-built. For $300.00 dollars. Hell, I could have ordered the entire pre-assembled Turtlebot, complete with iCreate, Kinect, Asus Laptop, aluminum standoffs, lasercut MDF, and Power/sensor board for $1,499.00 if I were some top-notch robotics research lab at a leading university with infinite dollars.
Needless to say, I opted for the DIY approach. BECAUSE WTF 300 DOLLARS FOR FREAKING ALUMINUM STANDOFFS AND LASERCUT WOOD?!? I enjoy the prospect of manufacturing what I can out of inexpensive/free raw materials. Luckily, the TurtleBot platform is open-hardware, and you can get more engineering drawings, circuit diagrams, design notes and CAD models than you can shake a KUKA manipulator at. I determined the size of each standoff and how I could make an equivalent one for cheaper. I also exported .DXF files of the platforms for future lasercutter use. I ordered a 6-foot long aluminum rod for $2.00 off Amazon, with free 2-day shipping. I also found a ton of .25" MDF lying around that a lab was getting rid of. I loaded up the .DXFs and fired up the lasercutter at CSAIL machine shop where my friend worked and the incredibly nice shopkeeper let me work. I had used the shop before to waterjet parts for Cruscooter and make the block funnel for my team's 6.141 robot.
Rawr Lazar!
And I had the platforms within minutes! Now it was time to put them together with standoffs.
14 standoffs in total. and each of them needed tapped holes on each side for mounting. I grabbed my trusty Mountain Dew and got to work drilling them out...
One hole down, 27 to go! :D
After drilling them out, I spent hours straight hand-tapping holes at MITERS, and watched Rent and Iron Man in the process. I kept telling myself: You want to be doing this and only spend $2 on hardware. You want to be doing this and only spend $2... In order to interface the standoffs with each other, I sawed the caps off my surplus of 6-32 screws and threaded everything together.
Voila!
Now all I had to do was get a Kinect and a Power/Sensor board and I had myself a full Turtlebot! The issue with the powersensorboard is the recommended sensor breakout board is retired on Sparkfun, and the only package available for the actual gyro sensor IC is one which is impossible to solder traditionally. As a result, I could not etch my own board to spec as I planned, and had to purchase the premade $70.00-ish board. Oh well, at least I didn't have to debug it and drive myself insane like I usually do with my etched boards. I also purchased a Kinect for $50.00 on eBay bringing the project's total cost to roughly $342.00. Not bad, considering a TurtleBot without the laptop from Clearpath Robotics will run you FREAKING $1,049.00. An uneducated consumer is their best customer. Or a filthy rich one. After mounting the Kinect and powersensorboard...
I HAVE A COMPLETED TURTLEBOT! YAY! :D
Now, it's time to code. Which is a lot harder than it sounds because it involves installing ROS and getting it working on both the host laptop and the robot.
Wow, it's been THREE MONTHS since I last blogged. A lot has happened since then, and a lot is on the horizon as well. Time to bring in the updates. tl;dr:
Note: the contents of this post occurred in mid August. I learned a ton from my first attempt at making TinyArmTroller, so I made some speedy revisions:
Here you can see all the through-hole components that covered their traces when placed (USB, JTAG) have been updated with all traces at the bottom to ensure I can just put the component on and solder the connections on the bottom with no hassle. As a result, though I had to make a poor-man's via with a wire (Shown here as a Diode at the bottom, near the USB connector) to bring the USB's 5V up to the top later so the lone regulator (That's right! Now the USB is the only logic power source!) could deal with it. I also removed all thermals so the board could be easier to solder, and added a bunch of indicator LEDs. (Stupidly, I forgot the resistor for LEDs 2, 3, and 4. -_- I also forgot to add a switch to ground on pin C3 so I can easily boot into the bootloader. There was room enough to solder a surface-mount switch afterwards.) Man, I miss Arduino. I now appreciate how easy Arduino has made the microcontroller thing for hobbyists and engineers.
Also, I made a friend! His name's Hao, and he visited MIT from Beijing (Last week of July). He's a robot enthusiast who's been working on Dorabot, an open-source robotic maid (think Rosie from The Jetsons) that's designed with eastern cultures in mind. He also has done a ton more, and you should totally read his blog, which Google can translate for you if needed. When I met him, he was wearing a pair of Crocs and a ROSCon 2012 shirt like a boss. (ROSCon 20xx: added to my list of things to do). Oh, and he offered to work on TinyArm with me.
But the first board we made didn't line up properly like the last one luckily did. We tried using my old method of lining up the images on the monitor and taping them together, but we simply couldn't get a consistent result, leading us to deem the previous method flawed. Everything was off by a little amount, just enough to get us to scrap the board and try to improve the 2-sided board etching process.
Now that's more like it! To get this guy working we measured the thickness of the board we were etching and drew a line in Photoshop of that thickness right between the two other images. After printing, we creased the paper perfectly on the line using flat surface and straight ruler under a magnifying lens. We then taped the overlapping board to the paper when it was snugly between the creased images, and put it through the laminator.
Alas, a board! I went up to the IDC to utilize their ridiculously accurate soldering equipment to get the tricky components in while Hao took a nap. He then woke and put together a good chunk of the board while I went to work.
With the near-complete board in hand, we decided to test whether or not the XMega was working before soldering the power-side components. After running the absurdly large proprietary Atmel Studio software in Windows and updating the firmware of my AVRIspMkii programmer to support PDI programming (the Atmel programming protocol), I was sad to see that the software wasn't recognizing the board. After some debugging with a scope, I realized an LED, which was on a data pin for the PDI header, was messing with the digital signal.
PROTIP: Don't put LEDs on data pins, it messes with the digital signal
AND IT WORKS! IT PROGRAMS AND EVERYTHING! So far. Off to sleep.... I'm Back!
Now that it works hardwarewise, it's time to think about the software, and that means moving back to using sweet, sweet Linux. Hao has left, but he helped me a ton with this thing beforehand. Also, because I had no real use for it, I gave him Giant-Ass-Arm, from a previous blog post. It was a 2-DOF robot manipulator that I purchased at a spring SwapFest. He took the stepper servos and transmission, scrapped the rest. You can see them in action on his Dorabot! Hao had started the job of writing the TinyArmTroller firmware by looking through the Arduino Stepper libraries, which worked well enough when commanding SingleStepperDriver. The biggest issue I had integrating any code I found was atmega compatibility with Xmega. The commands for each are similar, but not quite the same. And because nearly everything out there is written for Atmega, not the much newer Xmegas, support was limited on my journey to get even a blinking LED with a delay to work at all.
But then the C code was just acting dumb. It would randomly restart, slow down, loop in incorrect places... I finally diagnosed it to be serious compiler issues involving avr-gcc and avr-libc. This took me many frustrating weeks to debug and diagnose. Out of desperation, I removed everything from my computer remotely involving AVR and decided to re-install everything fresh, and work from a fresh Makefile. The following link saved my ass with setting up my AVR development environment:
The title is misleading, as the post shows how to set up your environment WITHOUT the need for the large and inflated AVR Studio. The included Makefile also allows you to compile, generate a .hex file, and install your code in one line: sudo make hex install.
SUCCESS!
Now that my board was actually executing code, I soon got I/O, internal clock calibration, interrupt setup, all working. I rewrote the Arduino Stepper code Hao used to work with the Xmega architecture. Pretty soon, I WAS DRIVING MOTORS!
I rewrote more of the higher-level software to get the board driving more than one motor at a time, and then a waypoint navigator shortly after. Issue is, I was driving each motor at the same angular velocity, so each DOF was arriving at its desired position at different times.
Consider trying to move from X-Y position (0,0) to goal point (50,100). The current control implementation would run to (50,50) before finishing my Y motion to get to the goal. Instead, I wrote a control planner to average out each individual motor velocity to get each actuator to its desired angle at the same time. This proved to be quite smooth:
Aaaaaand that's where TinyArm and TinyArmTroller are at for now. I have to program in a set of waypoints and it loops through them infinitely. Next step would be to modify the controller further to be able to command velocities, and to add USB communication so it can get new waypoints/velocity commands via a Python program.
Shaking Bayley's Hand Finger
It's been demoed extensively at the MITERS booth of the MIT Activities Midway and at Makerfaire NYC. It suffered a fall early in this school year, and has had one of its control cables replaced, but it remains today a DGonz Staple, my first extensive MITERS project.
Well, almost. Because it blew up when the ICs and caps rage quit hardcore. :c
Here's how it happened:
I began the design of TinyArmTroller, a board containing six unipolar stepper drive circuits, six digital limit switches, and an atmel microcontroller to process it all. It will communicate with a computer via USB so a python program can provide high-level logic.
Designing around a microcontroller has been the huge hurdle for me, and has lead me to both love and hate circuit design. There are so many components necessary to make the microcontroller happy that I nearly gave up altogether, but I pushed through, asking fellow MITERS-folk questions at a frequency comprable to the clock speed of my Micro.
Speaking of microcontrollers, it was recommended that I use an atmega16u4 or an atxmega16a4u because each board contained built-in ftdi drivers for USB interfacing. Normally some seperate external circuitry is necessary for a micro to communicate via USB. Getting one of these cuts down on the BOM and the board's overall complexity.
Besides, talking vith zee german accent make everysing more legit.
Das Micro!
The atmega16u4 runs off 5V, has 26 IO pins, and can be programmed via USB right from the factory with its DFU bootloader.
The atxmega16a4u runs off 3.3V, has 34 IO pins, and can be programmed via USB with the proper Bootloader installed, but it does not come with the bootloader factory preprogrammed. Atmel will factory preprogram their XMegas special order, but only if you order a few thousand. Given that I don't wish to be a sketchy third party ebay reseller of xmegas, I'll pass!
Now, which board should I take?
Number of I/O:
(6 stepper drivers * 4 channels per stepper) + 6 limit switches = 30 I/O channels. Unless I want to deal with (de)multiplexers...
The atXmega16a4u wins Round 1!
Power:
I want to utilize the 5V from the USB port as well as (uh oh) the 12V motor power (NOOOO!). The atxmega16a4u uses up to 3.6V, wheras the atmega16u4 uses up to 5V. Either way I would need a regulator and smoothing capacitor to clean the output to the board power. Taking a shaky 5V from USB to power a 5V board just will not give me the power I need, while taking the shaky 5V and turning it into a steady 3.3V is more reasonable.
What can possibly go wrong? =] (NONONONO)
Round 2: AtXmega16a4u
Oscillator:
The XMega has an internal 32MHz oscillator, and as *zee above video from zee Atmel company* states, no external oscillator is needed! The atMega16u4 has an 8MHz internal clock, which is plenty fast for my needs, but doesn't have zee video!
Round 3: Draw, or AtXmega16a4u (because of zee video)
Programming:
The Xmega requires an AVRISPmkII programmer with a firmware upgrade to support PDI programming through USB, its own DFU firmware upgrade, as well as some additional hardware on the board to support traditional programming through a 6-pin JTAG connection. The atMega16u4 only requires USB with its factory-preset firmware. As BOM goes up, my happiness goes down, so...
Round 4: atMega16u4
WINNER: atxmega16a4u!
Board Design and Etching
Here's the huge schematic, click to get a better view.
It's a pretty simple board. I scrubbed through the datasheets until I found the example circuitry I needed for USB, programming, and reset. I had one bus capacitor for each motor, as well as one smoothing capacitor per board power input. I purchased surface mount voltage regulators that could step down up to 20V to 3.3V. To prevent the regulators from killing eachother, I put diodes in series with their output (not knowing that they each had about a 1.5V drop: they were soon replaced with wires).
And the routed board! I did most of the routing by hand, and only autoroute for the power components (Dumb, I know. Next one will be all me, I swear!)
Now that I've routed the board, it was time to etch it. I used the same techniques as how I made SingleStepperTroller, this time flipping the top layer so when the toner transferred it would be right-side-up.
The new trick, though, was getting the two-sided thing working. I taped the bottom layer to a computer screen, put some tape on the backside so I could fold it over the front when i was ready, and set forth aligning every hole.
When I thought I got it perfect, I got a friend to fold the piece of tape carefully over the top layer, creasing it at the right spot. I then shoved the 2-layer copper board between the sheets, taped the top layer and the board in place, and put the whole thing in the laminator (making sure some board was sticking out on the sides for traction). A paper-removal scrub rub and Ferric Chloride bath later:
It came out nice on the first try!
AWWWW HELL YEAH!
Here's a closeup of some of the holes from the bottom, after drilling them from the top. You can see where they are ever-so-slightly misaligned, but it's certainly tolerable. Some would harm small animals to get a two-sided board this good on the first try ever. Note the trace clearance tolerances, however: it's a tight fit. I went through the whole board under a Jeweler's Eye-Thing and cut some possible shorts with a Xacto knife.
Now it's time so populate the board!
Here's some general guidelines from my soldermonkey job last summer I found useful to take when I started populating:
0. MAKE SURE THE DAMN POWER SUPPLY ISN'T AC OUT!
Solder Power regulation circuitry and bus capacitors, including power connectors.
Try powering the circuit up with each individual power source and check voltage levels. Make sure there is no short circuit. MAKE SURE THE POWER SUPPLIES ARE NOT FREAKIN' AC! Unless, of course, your circuit expects this. Which mine didn't when it rage quit its ICs and caps.
Solder Microcontroller and anything necessary for micro operation (Resonator, Programming Header, Reset Switch and resistor, Indicator LED, etc.). Then don't solder everything else (like I did) until you've successfully programmed the thing.
As you go along, constantly check with an audible continuity setting on a multimeter to make sure connections are solid where they should be, and that no shorts exist.
The LED lit up with USB power! Hooray!
Then I blew it up.
After the USB power lit up the board power LED, It was time to test if motor power would do it. I connected the 13.5V power supply, which would totally be fine through my regulator, right? It can handle up to 20V and step it down to 3.3V, so it'll be just fine. If I could just find the barrel connector...
The board kindly and audibly let me know that the power supply I used was AC, not DC output.
Me after realizing I had to make a whole new board. After all that soldering...
Shit I learned:
When using USB or other thru-hole connectors that cover the top of the board, make sure the traces are all on the other side of the connector.
Diodes have a voltage drop! Know this before doing things.
MAKE DAMN SURE YOUR POWER SUPPLY OUTPUT IS WHAT YOU NEED. As in DC, not AC. Use a scope, meter, or something, it takes 2 seconds.
Routing boards is fun. Watching Autoroute make nice boards is fun, too.
Use 16 mil logic traces, 24 mil, 32 mil, or greater traces for high power stuff to let high current pass.
When smoking ICS happen, UNPLUG THE POWER SUPPLY FROM THE WALL, don't try to unplug the board from the power supply via the barrel connector, or face the fury of possible exploding capacitors.
Don't solder most of the board before testing the sensitive shit like microcontrollers.
Heat guns are useful for de-soldering surfacemount components from your chicken-fried circuitboard. So are friends!
Try not to require, but always welcome, a redesign.
Oh well. Next one will be great! No more issues with the USB lines being covered by the connector, no more exploding boards due to AC power, no more shorts in need of Xacto cutting. Just wait and see...
