We're all making New Year's resolutions. I have a few personal ones of my own, but they have nothing to do with this blog. This being Yet Another Mechanical Engineering Blog, I will focus on my engi-nerd-hack-robot-ing goals for this year, or at least the coming IAP (January semester) and Spring semester.
It's a dirty hot mess. Needs major rewiring. And a working brake.
1. Build a semi-autonomous Quadrotor
WAY more details about this coming soon. This will be one of my first projects of IAP.
2. Build a Bi-copter/Tiltrotor. A la V22 Osprey.
Something I've been wanting to do since I saw the attack choppers in James Cameron's Avatar. And something I tried to do last year when I knew nothing. Now I know a little something, and building a quadrotor will help give me an intuition for flying things.
It's a ballsy goal. But hey, I'm a freakin' engineering diva.
4. Finish MelonChopper
Cannot wait til I can drift this thing in the snow :p
5. Learn to weld steel.
So I can build Certified Legit vehicles. For cheap.
6. DeltaBot.
I'm going to have the coolest thesis ever ^_^.
7. Write an Instructable on manipulator robotics.
I've learned a lot in the past few years, time to spread the love. But first...
8. Design and build a ~7-DOF robotic manipulator. A la KUKA arm.
I've been controlling these bad boys, now it's time to be a Mechanical engineer for once.
9. Pay attention to TurtleBot.
Of my children, I've been giving a lot of attention to TinyArm and none to TurtleBot, and I don't think TurtleBot can handle neglect much longer :c. Time to turn that around. I owe Shane a SLAM map of the IDC before he goes off into the Real World (c).
10. Get TurtleBot+TinyArm playing together.
I still hold myself to the dynamic duo, TurtleBot and TinyArm, getting me a soda. Maybe now that TinyArm has learned how to talk, and with the release of ROS Groovy Galapagos I'll finally make it happen.
13. Get a summer internship. I cannot spend another summer at MIT UROPing. I need to see the world. See what industry is like. I need experience. I need to make a difference. I'll probably apply in the next few days...
I've been home for winter break, weary from the end of my fifth semester at MIT (I managed to maintain a 4.5 GPA!), and staying up in the odd hours of the night and relaxing... by working on TinyArm.
Before I went home for winter break, I decided to drop by MITERS to pick up TinyArm, among other things. I hadn't really worked on it since the beginning of the school year, where the last breakthrough was getting it to move around using hard-coded step waypoints in the firmware. I tried for many, many nights to get "zee USB" working... to no avail. Now that I was home, I decided to do a few things. I wanted to model TinyArm, to figure out its dimensions and true limits before I started working out the kinematics/inverse kinematics. I also wanted the model because I wanted to test out the Solidworks-To-URDF Exporter (Now that I had a 64-bit computer). I also wanted to finally get my computer talking to the control board, even if it meant not using the USB protocol directly.
I first grabbed my trusty calipers and began modelling the manipulator in Solidworks from scratch. Luckily, every single dimension on the thing is a proper Imperial value. Some lengths were 8.0 inches, some were 2.5, some were 6.375, but they all had some very nice number. Here you can see the final model I made.
And here's a closeup. The most important dimensions are there, though I may eventually add the cables, gearing, and motors. The gripper even closes the way it's supposed to! Too bad the URDF exporter never worked. Even with only the base links and the shoulder link selected, it was not able to identify the points or axes for each joint. Oh well, I may just make myself a custom URDF anyway.
Next, I decided to start getting my board talking. After another few minutes screwing around with USB (At some point this semester I once managed to get the board to show up as a USB device on my computer... once. ) I decided to switch to Serial. I looked into using serial USART communication, and found out the two pins I routed for D+ and D- in USB are the same as RX and TX for one of the serial ports built into the atxmega16a4u chip on TinyArmTroller.
So I cut a USB 2.0-B cable and made an adapter for a Sparkfun FTDI Basic Breakout Board I had lying around. Good thing my dad had soldering equipment at home!
With this setup, and with the help of some example code I found online (which actually exists, UNLIKE F***ING USB) I was able to get it listening and talking! A few more hours of coding and I could send it six step (FROM MY COMPUTER!!) values as a waypoint (OVER SOME WIRES! :D).
I then took some time to re-calculate my estimated mapping of Angle to Steps, by moving each DOF to ~0 degrees, then to ~90 degrees, and seeing what step values took me there. Turns out, these numbers were very clean ones. For example, for the shoulder joint, -500 steps was 90 degrees, and -1400 steps was 0 degrees, leading the angle-to-step conversion to be :
(theta-140)*10 = #steps
The other DOFs followed similar patterns, and soon enough I was typing in a set of angles into the Python command line, and the arm was complying to my will! MUHUHAHAH! :D
Vid again:
Now, what does the future hold for my wonderful TinyArm? I need to solve the inverse kinematics, meaning I need to solve for some functions that will tell me "what angles do I need to command in order to get to a certain X,Y,Z,theta?". With that, I can place some blocks in stacks in front of it and have it rearrange them, or something. I can make it grab a pencil and start moving along the ground plane, tracking my mouse movements. When I click, the robot moves the pencil down, and I can write things with the arm. I can attach it to TurtleBot and use it as a manipulator arm to go get me sodas or something, because it could pick up upwards of 2 lbs. (4 lbs according to the Microbot website...) I can attach it to the underside of a quadrotor...
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...
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:
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...
