TinyArmTroller: Resurrected & Working Beautifully!

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:

http://codbit.wordpress.com/avr-studio-for-linux-11-10/

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. 

See you next post! :D

Next, I tell you about Turtlebot...

TinyArmTroller: Destined for Failure

I DID IT!

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!

1. Solder Power regulation circuitry and bus capacitors, including power connectors.
2. 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.
3. 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. 
1. 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...

I'm off to sleep. -_-

Meet TinyArm and SingleStepperTroller!

Skip to the bottom of a video of it working!

I've recently acquired a robot arm that I hope to learn to control this summer.

This is a manipulator that has been hanging out at MITERS for ages, and I've decided to adopt it as a platform for some personal summer projects. I've christened it TinyArm, because it's smaller and generally more friendly than the Mega-Heavy-Ass-200lb-Arm I got a month or so ago at Swapfest (which I am going to scrap for parts or donate to a friend because its 2 degrees of freedom are not very interesting).

The robot is a Microbot Teachmover, a manipulator for educating engineers in the brand-spanking-new (as of the 1980s) field of robotic manufacturing and assembly. Back in its prime it cost a whopping $5000.00 including the drive electronics and controls. I was able to pull up some these dimensions and specifications from the Microbot website,  but I could not find any information on the stepper motors or the rest of the drivetrain. 

Characterizing The Stepper Motors

A stepper motor has the following characteristics: number of steps per revolution, the configuration of the seperate channels (bipolar, unipolar, etc), the  torque constant [Nm / A] and recommended driving power. 

Using the power of Google, I determined most unipolar stepper motors are designed to move 1.8 Degrees per step, (200 steps per revolution). Most online guides suggest to simply assume 200 steps/rev unless the motor states otherwise or if it is empirically determined to be otherwise, so I'll go ahead and do that. 

The Microbot website states that it can take a 12V - 14V power supply at 4.5 Amps. Dividing among the 6 motors and not taking into account the logic power, that's 0.75 Amps allotted per motor. The steppers on TinyArm are unipolar because there are 6 wires emerging from each motor: 2 power lines and 4 drive channels. 

A Unipolar Stepper Motor is driven by powering all the lines and iterating which of the four drive channels is grounded. The motor will align itself towards the grounded channel statically until it is switched high and the next channel is grounded. 5-lead stepper motors are also unipolar, they just have one power line instead of two. I won't go into bipolar motors, just get yourself Practical Electronics for Inventors. 

Drivetrain and DOF Analysis

In order to properly control TinyArm, I need to determine its degrees of freedom (DOFs) and other constraints. It is actuated by 6 motors and, through an intricate gear and cable system, has 5 degrees of freedom and can close a gripper. 

There is also a switch which triggers as soon as the gripper encounters resistance, supposedly letting the now-nonexistent microcontroller know that it has successfully grasped an object. Theoretically, you can also determine the size of the object you are picking up by counting the number of steps it takes to hit the clicker switch. 

TinyArm's degrees of freedom are completely uncoupled, which is an uncommon design when it comes to robot arms. 

The standard manipulator is configured like this one, where each degree of freedom is an extension of the previous linkage's position. If I move the bottom joint 45 degrees, every joint up the chain to the gripper will move 45 degrees. This is because the actuator exists on the linkage and moves with respect to the origin. The end linkage's angle with respect to the origin is the sum of the angles of all the other previous linkages + the servo's commanded angle. 

Theta_C (with respect to Origin) = Theta A(with respect to origin) + Theta B(with respect to A) + Theta C (with respect to B)

The Teachmover has all six actuators fixed with respect to each other, meaning if one motor actuates one DOF, all the others remain the same (unless one reaches the physical limit of rotation, but more on that later). Comparing the picture above with the picture below, you can see that I only moved the shoulder down 45 Degrees, and the orientation of every other linkage stays the same. 

Going back to the kinematics, every angle (except for the axial wrist roll) is independent of every other angle, except the base's rotation. 

But just how is power transmitted from the stepper motor to each DOF? Looking closer at the gear-and-pulley system, there's a small 10-tooth metal gear on the stepper motor's shaft driving a 30-tooth gear. Then there's a 12-tooth gear on the same axle as the 30, which drives an 84 tooth gear and the drive cables. A 21:1 gear ratio total, meaning, for every 21 rotations of the motor, the DOF will rotate once.

Knowing the dimensions and degree limits from the website yeilds the following properties:

*TO BE UPDATED AS I EMPIRICALLY TEST THEM*

• DOF 1: o_theta_y_a (Base Platform planar rotation)
• Controlled by Stepper Motor 1
• Min Angle: -90 Degrees
• Max Angle: 90 Degrees
• Max Steps: (180 Degrees * 21 * 200 steps)/360Degrees = 2100 Steps
• Dependencies: None
• DOF 2: a_theta_z_b (Shoulder planar rotation)
• Controlled by Stepper Motor 2
• Min Angle: TBD (With Respect to A)
• Max Angle: 145 Degrees (With Respect to A)
• Max Steps: TBD
• Dependencies: None
• DOF 3: a_theta_z_c (Elbow planar rotation)
• Controlled by Stepper Motor 3
• Min Angle: TBD (With Respect to B)
• Max Angle: TBD (With Respect to B)
• Max Steps: TBD
• Dependencies: B
• DOF 4: a_theta_z_d (Wrist planar rotation)
• Controlled by Stepper Motors 4 and 5 in opposite directions
• Min Angle: TBD (With Respect to C)
• Max Angle: TBD (With Respect to C)
• Max Steps: TBD
• Dependencies:C
• DOF 5: d_theta_x_e (Wrist axial rotation)
• Controlled by Stepper Motors 4 and 5 in the same direction
• Min Angle:  TBD (With Respect to D)
• Max Angle: TBD (With Respect to D)
• Max Steps: TBD
• Dependencies: None
• DOF 6: e_grip (Gripper)
• Controlled by Stepper Motor 6
• Max Steps: TBD
• Dependencies: The only exception in uncoupling, the gripper must be driven as the elbow is driven to maintain the same pose. 

Driving a Unipolar Stepper Motor

While my final goal for TinyArm is graceful manipulation with ROS and a Kinect for a benchtop assistant, I first need to learn how to control a stepper motor.

Stepper motors are motors that hold a position rather than continuously rotate. Unlike servomotors, there is no microcontroller feedback loop for position control, but rather the position is determined by keeping track of how many steps you have commanded the motor to run. Precautions need to be taken, especially when commanding the steppers at high velocities and under large loads, to ensure the motors do not slip (leading to error). 

So I made my first custom circuit board, a 1-channel unipolar stepper motor driver. The goal of this project was to learn how to drive stepper motors, how to use EAGLE to design electronic circuitry, and how to manufacture my own PCBs. 

I designed the board and schematic in EAGLE, a program for PCB (printed circuit board) design. Using one N-channel MOSFET per stepper grounding channel I can switch rapidly between grounds to drive the motor forward or backward. The flyback diodes allow for the stepper's inductance to release its energy back to the system.

Here is the (auto)routed board, with a fancy ground plane. While some consider it a sin to use autoroute, I feel if you place the components correctly you can get the software to do its job well. For more complicated board I will opt to manually route, but for tiny boards like this one, the autorouter is sufficient.  I choose to only route on one side of the board because a one-sided board is easier to make.

Once the board is routed, you display only the side you routed (Top in this case), Pads, and Vias (If you used them) to show only the copper traces, and export it as a monochrome (all-black) image file.

You then print it our with a laser printer on glossy paper, cut out a piece of copper-silicon board to size, sand the surface you are etching to ensure the toner adheres correctly, and iron, laminate, or otherwise transfer the image onto the copper side of the board. After the transfer, I used water to gently dissolve the paper and leave behind only copper, rubbing (NOT PEELING) with my fingers until the board was free of paper. You then put the board in a Ferric Chloride bath to dissolve the copper, leaving behind this!:

Here you can see a printout and the resulting board after the Ferric Chloride bath. All the copper that is not protected by the toner is dissolved away, leaving behind the traces you want! Because I made all my leads the top of the board and did not flip the image before printing it, it printed out backwards. Oh well, noob mistake! ^_^

After a quick acetone cleaning to remove the toner, a wild board appears!

After drilling the holes, populating, and soldering the components to my board, I connect some pins from an Arduino Uno to drive the FETs, load an example Stepper sketch, connect the stepper to a bench power supply, and...

My next one will be TinyArmTroller, which will control all six stepper motors in TinyArm. It will also have an input for TinyArm's grip sensor, and will communicate to a computer via USB. A python program using ROS packages for kinematics and motion planning will send signals to the board for its microcontroller to interpret as motion commands.

On the software side, I need to design a system that will take planned motion waypoints from my laptop over usb or serial, and translate it to smooth motion, without jerking to a stop once a waypoint is reached. 

Let's see if it happens before the summer ends...

NerdKit: OMG CNC MACHINING

CNC: Computer Numerically Controlled.
Or, in layman's terms: Robotic. 

I've had the pleasure of using a CNC mill for the first time to make a new mold prototype for the NerdKit I am so diligently working on at my job this summer. And it's one of the coolest things I've ever used in my life. 

This prototype combines many aspects that are closer to the final product: a CNC milled mold, a caselike structure, an insert for compartments and such, a flush hinge, and better designed snapfit invagination/exphallation fasteners.

Also, I've figured out a trick in Solidworks to quickly "prototype" a mold without having to go through the Mold Tools. If you model a mold you can use the Shell feature on the part, which normally removed material from inside your part. If you choose "shell outward", you effectively form the part using a specified thickness material. Then you can "take it to a bandsaw" by cutting away excess "material" and...

...Voila! Much simpler than those gurshdurned mold tools. 

There's a handy Solidworks extension called HSMWorks Express which is the free 2.5-Dimensional cousin to the full 3-D CAM program HSMWorks. While machining in X and Y along a certain Z is all I need for this mold, 3D milling is nice for smooth curvatures and fillets. Unfortunately, I have to take into account the limitations of Express in my designs for CNC. 

But it doesn't come out so bad!

Someday I'll do some 5-axis CNC milling...

Engineer daydreams...

Here is some of that High Density Polyurethane I will be using as a stock material, mounted onto the Bridgeport EZ Track CNC mill.

Once I've localized the mill at the stock's origin, I'm ready to rip...

It even gives you an option to call for a tool change halfway through machining, so I can switch out the flat endmill for a ball endmill and touch it off before it cuts the hinge channel in the center. 

Can you see the resemblance?

And the next day it's off to the vacuum former! I drilled dozens of tiny holes along the hinge, edges, and invaginations to ensure the plastic truly takes the shape of the mold. 

I was sure to add plenty of this special non-stick spray to make the removal of the mold from our cheap plastic easier. 

Because of the small scale, I had issues with the material webbing along the hinge, but I managed to get one good part.

The insert my coworker made from a CNC mold fits perfectly.

The live hinge works pretty well, too! We'll have to test the design with the type of plastic we're using for the final product, however. 

Next, we make a full-scale prototype!