robotguy.net/Blog

#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…

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:

Design Goals for Deskpet

I have decided to limit myself to 3 projects; Deskpet, Tiletoy and notebooks. I just built some notebooks, and my Tiletoy PCB is on the way (maybe more about that later), so I’d like to get back to Deskpet.

Deskpet is a project that I am working on to create a small robot to live on my desk as a pet. One of the things I have learned at work is that it is much harder to build something if you don’t know exactly what it is supposed to do. So here goes; high level design goals for Deskpet:

1. The major goal for the Deskpet is to construct a pet. It needs to live on my desk and generate an emotional attachment.
   • Sufficient output to be “interesting” – If all it has is a pair of motors, I can make it dance, but it would be much easier to generate an emotional attachment if it has other methods of expressing itself.
   • Sufficient input to be interactive – I want to be able to play with my pet, so it needs to be able to sense it’s surroundings, toys and possibly me.
2. Automatic recharge – If it is going to seem alive, I can’t keep having to put it on the charger.
3. Wireless communication and bootloading – This is going to require A LOT of firmware work on my part, so it ould be easiest if I could download new firmware without even toucing the ‘bot.
4. I will not be concerning myself with availablilty or cost of components with respect to eventually making kits available. This will be a project for me.

Well, that should be enough to keep me busy……..

Driving Miss Daisy-wheel

I got the wireless key-fob working:

Family and friends have been having a lot of fun driving it around.

My end goal is to let the ‘bot talk to a base station connected to a PC. I REALLY want to write an RF bootloader, so I can reprogram without touching the ‘bot. This is the hardware for the base station ( Still need to write the software and firmware):

Deskpet pre-proto

I ordered a Nordic-FOB from Sparkfun to make the coding for the wireless module easier. While I’m waiting, I decided to hack together a pre-prototype of the deskpet using a Baby Orangutan from Pololu, that has an ATMega168 and an LB1836M, the same motor driver that the real board will use. If you want one of those Baby-O’s, get it quick, because they upgraded the motor controller on it, and the old version is going fast. On a good note, they added the LB1836M to their IC page for me, so they should be much easier to get now.

Here’s a pic of the prototype:

P.S. If you are looking for a cool off-the shelf ‘bot, the 3pi from Pololu looks really nifty. Can’t wait until it comes out…

Deskpet Update & Pics

I finished laying out the PCB during lunch today. Maybe I can clean it up and get it out to BatchPCB for fab by tomorrow morning:

I finally got around to taking some pictures of the base:

Deskpet Planning – Part B

1) I picked a battery: 230 mAh LiPo from All-Battery. If I raise the standoffs by about 0.05″ I can fit it between the motors and the PCB or I could add a small shelf to the back end of the frame, kinda like a penny-racer.

2) The IS471F requires 4.5V but I want to run from a max of 3.3V. Looks like I’m going to need to find another solution for proximity detection.

3) Charge pump for the color sensor LED’s: MAX1595? I have used some of the Maxim capacitor charge pumps in the past and they work well.

Deskpet Planning – Part A

I am working on the design for the Deskpet, and decided to build a prototype with a minimal configuration to get started. I plan to use an ATMega128 processor because I have several laying around. Here are the required input and outputs:

Input

• Color/Line sensor
• Linear Hall effect sensor
• 2 way IR proximity sensor
• Ambient light level sensor
• Wireless data
• Battery level sensing
• Battery charge input
• Pushbutton

Output

• 2X Motors
• Speaker
• Wireless Data
• OLED “face”

And here’s what I have so far for each:

Color/Line Sensor:

NECM005 RGB LED and TEMT6000 light sensor

Linear Hall Sensor:

Not sure yet. I like the 3 pin SIP devices from Allegro, but they need 4.5V. I would like to keep everything possible running from a 3V or maybe 3.3V supply.

IR Proximity Detect

2X IR LED’s and IS471F modulated detector. Could also be used for IR homing beacon for charging station. To avoid interference with the proximity detect, sending a specific pulse from the LEDs would trigger the charging station to transmit a response.

Light Level

CDS Cell or TEMT6000 light level sensor

Wireless Data:

Nordic nRF24L01 board from Sparkfun

Battery Level:

Voltage divider to ADC on the main processor

Battery Charging Circuit:

MAX1555 Lithium charge controller

Pushbutton:

SMT Momentary Normally Open SPST

2X Motors:

LB1836M Low Voltage Dual H-Bridge and 2X GM10 geared pager motors

Speaker:

Citizen Micro Speaker from Electronics Goldmine.

OLED “face”:

uOLED96 from 4DSystems. I have an older version than the one shown in the link with 8MB internal flash, and no uSD slot.

Still left to work on:

• Battery – Size and mounting locations
• Charging method – How does the robot find & connect to the charger?
• Decide on a Hall Sensor
• Find an LED charge pump since the G and B LEDs require 3.6 V

Route 66

I received the display (no pics yet :’( ). It is teeny, but the contrast is really nice. Last but not least, I just finished the routing of the PCB and should be sending it out for fab at BatchPCB by Friday.

I have three “airwires” left. The auto router choked on this board, so this was the best I could do manually. I added some vias so I could solder a jumper in to connect the nets.