25 July 2012

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...

2 comments:

  1. Wow this is such a interesting post! I was looking online at different cable manufacturers when I came across your blog. I must say I'm happy I did because I can't believe you built something like this, that's amazing! Thank you for sharing this with us!

    ReplyDelete