Showing posts with label ATmega48. Show all posts
Showing posts with label ATmega48. Show all posts

2007-12-05

Project Lull

I am officially in a project lull. The microscale is pretty much done (I do need to send it with Erica for final testing), and Robotics season is starting up in the first week of Jan. I theoretically have a week and a half that I could accomplish something with, but I don't have any good ideas.

My micromouse board is at a difficult point. I managed to set some of the fuses wrong, and now I can't talk to two of the three boards. I have one spare processor, so I could replace one, but TQFP-64 is no fun to remove from a board with no soldermask. The alternative is to guess what I set the fuses to, and try to generate the required clock long enough to make them normal again.

I could always work on the program for the micromouse motor controllers, since I have a few of those built up. I can always use an oragutan to test those. After the fun I had implementing PID, UART, and LCD code in an ATMEGA48 (4k codespace, 512B SRAM), it should be quite a bit of fun to put PID and UART into an ATTINY13 (1k codespace, 64B SRAM). at least most of the problem was LCD code. I also need to work in PWM for the speed control, but an interrupt should be able to handle that.

Possible control algorithm notes (while I'm thinking about it):
position registers are basis of PID
  • Current position
  • Final Target position
  • Moving Target position
"moving target" is how I can do speed control. It is the point that the PID errors are calculated against. It moves at a (likely) steady rate towards the Final Target. This is a place where I could put in some acceleration control, but codespace already seems at a premium. The rate at which it moves would be the speed command (counts per small unit of time). This might be the part where I find out why moving slowly is apparently difficult. We'll have to wait and see.

PID normally has just those three gains (P, I, D). I think I might want to try to implement some of the more complex gain types like velocity feed-forward.

This might be a good point to bring up the fact that I plan on using avr-gcc, and not learning assembly for AVR. (One of the best things Atmel has done is to build avr-gcc into AVR studio, IMHO.)

Perhaps I can find some time this week to work on the motor controllers. Remind me to post later about the design of the board itself, and some of the good and not-so-good things I learned while doing it. (Preview of not-so-good: For some reason, Atmel decided to make the SPI programming pins on an ATMEGA128 NOT the same as the normal SPI pins, which caused hours of frustration while debugging the first time I turned it on. Of course I used the SPI programming pins for some completely different function on the board.)

2007-11-18

Microscale v2.5

I meant to be writing about this as it happened, but instead I will summarize. After the last attempt, we decided to make the scale out of metal, so it would be a bit more robust. The new version was designed in Solidworks in about a day, ported over to FlowMaster, and cut on a waterjet at work. The waterjet process took all of two hours, including polishing. The cut itself was around 7 minutes. Sadly, I didn't take any pictures of the individual pieces, but the final assembly photos are nice.



The scale is made out of 1/4" Aluminum. I hand drilled and tapped all the holes with bad equipment. The tap actually twisted if I applied too much torque. It's quite possibly the cheapest. tap. ever. At least it didn't break on me. I did break a screw that I was using to clean up the holes, but it wasn't strictly required, right? You can just make out the copper wire counterweight on the lower right side of the assembly. It's the hokiest part of the design, but it works.

Here's the best view you'll get of the new flag design.

The idea is that when it is centered, the IR beam is half blocked. When the arm is off balance, the changing radius of the flag blocks more or less than half of the beam. The advantage is that the arm can move up to 5 times further than it could before and still get a valid reading. The flag was drawn in Solidworks and cut out of 0.06" Aluminum on the waterjet. I then polished the cut face to make readings a little more consistent. There is an adjustable block above and below to limit the motion of the arm, and to protect the flag in general. Th flag hitting the lower stop actually makes me think of the big hammering guy sculpture out in front of SAM.




While assembling and tweaking the new flag design (using the capacitor as a simulated sample), I somehow damaged the galvanometer itself. It got really sticky, and would stay in the balanced position without being balanced. We ended up heading out to Radio Shack to get a new one (and another spare) for ~$16 each. While I was at it, I made the arm longer by about 50%, bringing the scale to about 150 counts per milligram. The longer arm and new flag allowed me to re-tune it to respond faster.

Here's a picture of the computer taking data via hyperterminal. The serial stram is simply recorded to a text file, and can be imported directly into Excel later.



Note: Remember to ask Erica for a picture of the scale in use, and a screenshot of the resulting graph.

Also, while trying to fix the balance arm, the screen went blank! It was fairly easy to trace. The scale still worked, but the negative voltage for LCD contrast went away. The only problem with having a donated collection of stashed parts is that the parts are old, and actually require some work to make them function. Current LCDs are fine with ground on the contrast pin, but older ones want -3 to -10 volts. Fortunately enough, the MAX233 creates -10 volts for itself to use for RS-232 communication. Since it's just a tiny load, I ran the LCD contrast to this supply. The problem turned out to be a fleck of loose solder shorting out the supply. Good thing the Max233 is resilient.


I'm calling it done at this point (Hence the completed tag). Erica's brought it to school, and she'll calibrate and tell me how it goes. It's version 2.5 because of all the mechanical upgrades, though the code is essentially the same as the v2.0.

Now for the next project...

2007-11-17

MicroScale v2.0

Erica found an article at Scientific American describing how to make a small micro-gram balance using a part ripped from an analog multimeter and some other electronics.
























I love voiding warranties.

I first built the "manual" version, and we were able to detect the change of mass by adding individual grains of salt to the scale. Each one caused a 0.004 volt change on the sensing voltmeter. Using this info, and some of the ideas from the automatic version, I proceeded to make my own version of the PID controlled scale.

I used an Atmel Mega48, and a tweaked version of the Orangutan Library for Pololu. I can get away with this because I bought a Baby Orangutan and a regular Orangutan controller from them at Robothon 2007. I did the first prototype of the code in the Baby O processor, but then decided I wanted it for another project. The Mega48 is smaller, but otherwise identical to the Mega168. I added a few routines to the LCD code, and patterned my UART functions off of the same.

I tried a new wiring technique on the circuit board for this project (jumpers on top), and didn't really like it that much. I'll go back to pseudo-traces on the next project.



You can't see much in that photo, but I am using A MAX233 for RS-232 conversion, as well as creating some negative voltage for LCD contrast (It's an OLD LCD. Newer ones only need Ground for contrast). I also have a 5 volt precision reference (MAX675), a really nice 16-bit DAC (MAX541), and a basic Quad Op-Amp for amplification. The closed box looks WAY better, don't you think?



Shown on the screen is a very early version of the code. Here is the mounting arrangement for the scale itself. You can see I took a slightly different tack that the original article, but have borrowed some ideas from them. The coil on the right is actually a counterweight, to (mostly) offset the weight of the glass coverslip and holder.



In the next update, I should have an actual measurement and some code details.