#mazetrix video 1
I spent about 4 hours programming last night trying to simulate the physics of a rolling ball on the AVR. I think it turned out pretty well:
Here’s the timer interrupt that services the analog to digital converter and the multiplexing of the LEDs:
ISR(TIMER2_OVF_vect){
static unsigned char activeLine=0;
static unsigned char adcChannel=0;
PORTC=0xFF;
PORTA=0xFF;
selectLine(activeLine);
PORTC=~green_display[activeLine];
PORTA=~red_display[activeLine];
activeLine++;
if(activeLine>7){
activeLine=0;
}
switch(adcChannel){
case 0: x_accel=(ADCH-x_flat)/10;
if((x_loc<500)&&(x_accel<0)){ x_accel=0; } if((x_loc>7500)&&(x_accel>0)){
x_accel=0;
}
x_vel=limit(x_vel+x_accel,-MAXVELOCITY,MAXVELOCITY);
ADMUX=0xE1;
adcChannel=1;
break;
case 1: y_accel=(y_flat-ADCH)/10;
if((y_loc<500)&&(y_accel<0)){ y_accel=0; } if((y_loc>7500)&&(y_accel>0)){
y_accel=0;
}
//if((abs(y_accel)>1)||(abs(y_vel)>20)){
y_vel=limit(y_vel+y_accel,-MAXVELOCITY,MAXVELOCITY);
//}else{
// y_vel=0;
//}
ADMUX=0xE2;
adcChannel=2;
break;
case 2: z_accel=(ADCH-125);
ADMUX=0xE0;
adcChannel=0;
break;
default: adcChannel=0;
}}
And the main loop:
while(1){
if((abs(x_vel)>STICTION)||(abs(y_vel)>STICTION)){
x_vel=(int)((ELASTICNUMERATOR*(long int)x_vel)/ELASTICDENOMINATOR);
x_loc+=x_vel;
y_vel=(int)((ELASTICNUMERATOR*(long int)y_vel)/ELASTICDENOMINATOR);
y_loc+=y_vel;
}
if(x_loc<0){ x_loc=-x_loc; x_vel=-x_vel; } if(x_loc>7999){
x_loc=7999;
x_vel=-x_vel;
}
if(y_loc<0){ y_loc=-y_loc; y_vel=-y_vel; } if(y_loc>7999){
y_loc=7999;
y_vel=-y_vel;
}
x_pos=(unsigned char)(x_loc/1000);
y_pos=(unsigned char)(y_loc/1000);
plotBall(x_pos,y_pos);
_delay_ms(50);}
Mazetrix Update
I received the pcbs for Mazetrix and started the build. After 4 1/2 hours of troubleshooting I realized that I connected the SCK line to the wrong pin and finally managed to get AVR Studio to recognize the processor. Then I wrote enough code to verify the LEDs would all light up. However I then started having problems with the firmware. Finally, during my 15 minute lunch today, I found the problem was the fuse settings in the ATMEGA128 (either 103 comaptibility mode or JTAG enabled).
I just added the 3-axis accelerometer, but haven’t soldered on the supporting components. Also I still need to add the Li-Po charge IC. I am currently using the STK500 both to power and program the board.
So without further ado, here are some pics…
Mazetrix project
Mazetrix Bottom
Mazetrix Top
Welcome to the Mazetrix
So, I just got an email from BatchPCB that my board has been shipped, so it looks like I’m switching gears again.
My board is for a project based on the Tiletoy, and incidentally not unlike the Space Invaders Button, the Awesome and 64Pixels.
Many moons ago I managed to score several 8×64 Red-Green matrix displays salvaged, evidently, from a casino display. Even though I had managed to reverse engineer them and figure out how to display nifty messages, they were just too large and too COTS for me. I removed the 8×8 LED matrices (matrixes?) and designed a small board to run them. The display is run directly from an ATMega128, using a half-H bridge on each column so I can use the entire matrix as a sensor. Additionally, I have added a MMA7260 triple axis accelerometer. Last but not least is an IR LED pointed in each of the cardinal directions, also connected to be used as an input and an output, for communicating to neighbor modules(PDF link).
The ultimate goal is to create tiles with a red maze and a green “ball” than you can manipulate by tilting, just like the good old labyrinth game. When you get to the edge of a tile, you can connect another, which will attach magnetically, and the maze will continue on the new tile.
I’ll add more updates when I start building.
Here’s a few images to satisfy the curious:
schematic
Mazetrix Layout
Let there be…. uh…. color
I am having so much fun with this PDA/Tricorder project! Although the 128 X 64 mono LCD is cool and all, I just had to buy the 128 X 128 color LCD from Sparkfun that I’ve had my eye on. I wired it to my ATmega128 breakout board and powered the whole thing with my STK500 set to 3.3V
Voila! I had a nifty color LCD for my project. Here are a few screenshots:
I also picked up a few Hammond electronics enclosures ( I love electronics enclosures! I collect them…) from Allied. I get a great deal through work, plus free shipping. I got the 1553B and the 1455J1201. Of course I am also considering putting the electronics into an actual tricorder case. I bought a scratch-build kit from GMProps (look him up on the tricorder props forum), but it proved to be too much for me. Maybe I’ll try a Playmates Tric from Ebay.
Useable accelerometer data
Here’s a few places I found good stuff about filtering…
- http://lorien.ncl.ac.uk/ming/filter/filewma.htm
- http://www.dsptutor.freeuk.com/dfilt1.htm
Toward a Buttonless Interface
I have been struggling for a while with the lack of user input on the PDA project. I had considered adding an interface through the RF transceiver, but that would mean I would need to be near a PC. I have been unable to find any pushbuttons that I like to install on the face. So I did the next best thing. A sharp sideways tap on the right side of the enclosure brings up a menu, with a small circle next to the selected item:
Tilting the unit in the y direction moves the selection circle, and another tap selects the item. It still needs a bit of tweaking. It seems much easier to tilt in the x direction, because I tilt the unit towards my face when looking at the screen, and that makes the selection circle move down the llist.
Here are links to a few thing I found during my research into tiny user interfaces:
- TiltType: An Accelerometer Based Text Entry Method
- Sensing Techniques for Multi-Device Interfaces (PDF)
- Shake Them Up! A Movement Based Pairing Protocol
- Bringing Sketching Tools to Keychain Computers with an Acceleration-Based Interface
- GUI Development: Embedding Graphics Part I Part II
- Variability in Wrist-Tilt Accelerometer Based Gesture Interfaces
- Detecting Freefall with Low-G Accelerometers,Measuring Tilt with Low-G Accelerometers
From the “Because I can” Department…
While waiting for my RF boards to arrive from Sparkfun, I started another project (ooh, look! Something shiny!). I have always liked building things that I could carry around with me, so I decided to build my own PDA. I had the graphic LCD and plenty of processors laying around. I figured adding an RF link back to the PC would not only make it more functional but also help produce code that would be useful for the Spoka project. I also figured that I could combine it with my Tricorder project (notebook pages 3-12) and add as many sensors as I could fit in this little OKW enclosure.
The processor is an ATMega32. I have added a 128 X 64 graphic LCD, a 2.4GHz RF Transceiver, battery-backed real time clock, 2 axis accelerometer, linear Hall effect sensor, and a white led flashlight. The IR receiver is not connected yet. I still plan to add an RGB color sensor and an IR transmitter.
The source code was compiled with WinAVR and is available here. The library for the graphic LCD is from Gregor Horvat (http://www.indata.si/grega/) for the compatible HD61202 controller. After updating a few deprecated commands, it worked first time! I can’t remember where I got the library for the DS1307 clock that I converted for the DS1305. If anyone recognizes it, please let me know. The defines for the NRF24L01 came from S. Brennen Ball.
As you might be able to see from the screenshot, I am currently reading the battery voltage (upper left), magnetic field strength (upper right), x and y acceleration (lower left), and the current time (lower right). The cross-hairs and “bubble” in the center of the screen form a 2-axis level. See the picture of it in my hand for an example with the unit tilted on one axis. The RF transceiver is working well and capable of exchanging data with a PC base unit that connects via serial at 115200 baud.
(BTW, my order arrived from Sparkfun, but I’m having so much fun with this project, I may not get back to Spoka)
Spoka Pt. III – Choosing current limit resistors & color mapping
I was just realizing that I didn’t put values in for the LED current limiting resistors on the schematic, so I thought I would add a little detail regarding their values and how I chose them. I decided from the start to limit the current through each LED to 15 mA. Each PIN on the AVR can source 40 mA so no problem there, but the entire chip can only source 200 mA total. 7 LEDs X 15 mA = 105 mA. Should be no problem. Plus room to spare when the device is AC powered.
First and easiest was the red. I placed my meter in diode check mode and measured the voltage drop across the LED (Vf) as 1.74V. Measuring the battery output as 3.8V, we get a margin of (3.8-1.74=2.06V) which must be limited to .015A. Dividing the two we get (2.06V/.015A=137Ohms). Putting a 220 and a 330 in parallel gives me (220*330)/(220+330)=132. Close enough.
The blue and green LEDs had too high of a Vf for my meter to read in diode check mode. I knew however that the blue LEDs in the original circuit had a 20 Ohm resistor, so I figured that anything larger should be OK, so I scrounged around and found some 47 Ohm resistors. I soldered these to the LEDs and applied the power, then used the meter to measure the voltage across them. I got 3.16V for the green and 3.07 for the blue.
Green: (3.8V-3.16V=0.64V) (0.64V/0.015A=42 Ohms) Just leave in the 47 Ohms.
Blue: (3.8V-3.07V=.73V) (.73V/.015A=49 Ohms) Again, just leave in the 47 Ohms.
Worst case voltage should be 4.8V when the AC is plugged in. This will give (4.8-1.74)/132= 23mA for the red, (4.8-3.16)/47=35mA for the green, and (4.8-3.07)/47=37mA for the blue. All within the per-pin limit of 40mA. Total output would be (3*23)+(2*35)+(2*37)=213mA. Hmmm, I wouldn’t put out a production unit with numbers like that, but for a hack, it’s not too far off.
I was explaining to my wife the kinds of things I could do with this when it is PC controlled, like changing color according to the speed of a download. This reminded me of an article I saw a while back, “Rainbow LED Indicates Voltage with Color.” This article gives a nice mapping of value to color for the range of 0-255, but it is centered around 128. In other words 128 gives black (all off), <128 gives bluish tints, and >128 gives reddish tints. This might be handy for some things, but not for others. So I did some research on “color scales” and here are a few interesting links:
http://www.ks.uiuc.edu/Research/vmd/current/ug/node76.html
http://www.cs.uml.edu/~haim/ColorCenter/ColorCenterColormaps.htm
Spoka – Part II
(Continued from previous post..)
After removing the LEDs, I marked the outside of the shell to indicate where the eyes and nose were on the rubber cover. Then I modified a small prototyping board to fit into the space, aligning the eyes with the marks made previously. (Notice that the marks are on the same side of the shell as the hole for the plug. Whoops. I had to redo them on the other side)
Then wire the new pcb up, program it and install in the housing for a test (notice my chip-clip programming adapter. It’s handy)…
Red Green Blue White Mouth
Reading the Status Register
After playing around with the idea of getting an SD card running in order to get enough storage for the data structures described in my last post, I decided that it would be better, if not neccessarily easier, to get an RF link up and running and prototype the learning algorithm on the PC. So I pulled out the Mirf-V2 that I have bought from Spark Fun for just such an occasion. After perusing the forums for a while I realized that this is a tricky beast to get running, but it should be worth the effort. I also came to the decision that I am not going to hurry, but instead I am going to enjoy the process.
Knowing all of this, I began programming the base unit that will connect to the PC and convert serial to SPI for the Mirf. I built this board almost a year ago, and it has an ATMega8, a MAX233, a 7805 and a Mirf. I had a little trouble getting the SPI working, but using the scope, I managed to figure out the problem.
Finally knowing that I would need two to tan.. er send data, I wired the Mirf up to an ATMega128 breakout board that I also got from sparkfun. Tomorrow I can start writing code that will make the ’128 board send a packet continuously, and receive it with the Mega8 board.
