Finished_Projects--;

The microscale may be dead. I think the bearing is sticking (for the second time). There can only be one solution to a mechanical problem... software! I tried to work around it in some interesting ways.

• Adjust the indicator flag to be more like the original article
• Adjust the flag most of the way to normal
• Attempt to calculate the mass as a function of both the current force and the current error
• Adjust the gain so that it moves faster
• Adjust the gain so it moves more slowly
• Adjust the gain so it moves WAY more slowly
• Put the gain back where it was
• Add 2 to the gain instead of 1
• Undo
• Stop averaging the last two error readings
• Undo
• On Even seconds, reduce the force by 5mg to break the friction
  
• 10mg?
• 15mg?
• Undo back to 10mg
• When seconds MOD 4 == 0, reduce the force, ==1 and ==2 go back to the regular force, ==3 actually try to balance
• Same, but with MOD 5
• Same, but break the 5 second cycle into 1,2,2 instead of 1,3,1 (Fake, recover, balance)
• reduce the force by 20mg

So, after all that (half of which is in the SVN), It is repeatable to within +/- 0.3 mg (when it stabilizes), or it will flail around wildly +/- 70mg. The only difference between the two states is when you put the sample on the scale.

Possible "improvements"/Next Steps(that don't involve the 2kW heaters from the last UW project, just to see if they still can melt aluminum in 10 minutes)

• replace the galvanometer
• add springs to support the flag (stabilize)
• make the moving parts lighter (reduces accuracy - HA!)
• Realize that Erica can manually take the data faster than I can fix the scale
• Offer to set up webcam and OCR the regular scale into data
• Offer to write AHK script that will show pictures from the Nikon of the regular scale, so data entry is faster

Sigh...

(for those keeping track, Finished_Projects is now back to nil,m not counting FIRST)

Stupid, or just Crazy?

I've been thinking more an=bout my PID motor controllers based on the ATtiny13, and have determined that I must be crazy. I did some googling, and everyone else that is making a motor controller using an AVR is using something like an ATmega168, an ATmega32, or other large controller (almost always a mega). The application note on Atmel's website (look for AVR221) doesn't recommend a certain controller at all. So am I crazy to try to shove this all into an tiny13? We'll see how it goes.

I went over to AVRfreaks.net to see if there is anything larger than the tiny13 that has the same pinout. It looks like I can use the ATtiny25, ATtiny45, or ATtiny85 for 2, 4, or 8kb of Flash space. Too bad I already bought a dozen tiny13 chips.

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

Blog Fodder

Erica sent me an email titled Blog Fodder with some pictures of the microscale in action.







And she also gave me a nice graph of a few sample runs



It's clear that the scale can be improved, but is pretty close to working now. Erica brought it home for me to work on. I think I have enough code space left to add the Derivative and Integral terms back into the PID loop, which should make it less noisy.

I also want to compensate for flag position in the final readout formula, so it can predict what the mass would be if it were perfectly balanced. This part is harder, and I'm not sure if it's needed.

Microscale documentation

This document describes how to use the microscale.

Powering Up

- Boot the computer.
- Open microscale.ht on the desktop.
- Turn on the scale by moving the switch to the right. The LCD should turn on in about a second, and the scale will start balancing.

Calibration

- Zero the scale, by typing z into the terminal window. The Zero value can be adjusted manually via the [ and ] keys. The zeropoint is shown on the LCD's top row.
- Place a 100mg mass on the scale, wait for it to balance (about 10 seconds).
- Adjust the slope until the readout is close to 100mg, using the + and - keys.
- Verify the calibration with a smaller mass.
- Verify the zeropoint with no weight on the scale.
- Type s in the terminal window to save the calibration. This calibration will automatically be recalled next time the scale is powered on.
- To reduce the noise during the calibration, you can reduce the gain on the scale. The gain is controlled with the , and . keys (, decreases)

Operation

- Type h into the terminal if the scale is currently sending data to the laptop.
- Select the Transfer menu, Capture Text.... If a submenu pops up, choose Stop, then repeat this step.
- Choose where you want the data saved. The current default is under My Documentsmicroscale data. The file should have a .txt extension, but that is not required.
- The scale is now ready to record. Type r into the terminal just before the sample is started. The scale will reset the seconds counter to 0 and send a header row to the screen, followed by data every second.
- When the sample is finished, type h into the terminal to stop the data.
- From the Transfer menu, choose Capture Text, Stop. The file is now ready to be moved to another computer or opened in Excel.

Data format

- Column 1 is the time since r was last pressed.
- Column 2 is the temperature in C at the interface Circuit board.
- Column 3 is the calibrated reading in milligrams.
- Column 4 is the analog reading of the flag position. 512 is "balanced". If this reading is within 524 to 500, the scale is getting a reasonably good reading.
- Column 5 is the number of counts being applied to the DAC beyond the zeropoint. It is only here so that a bad calibration can be fixed after the measurement is taken.

Notes

- The data can be made less noisy by adjusting the gain down. The cost is a slower response time.
- Gain can be adjusted on the fly during a reading with no side effects.
- The gain is saved with other calibration data when s is typed.
- It may be a good idea to write down the calibration data for a particular run, as a backup.

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

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.