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