Beagle-Book Update

Doesn’t look a whole lot different, but I’ve added a small cooling fan for the DLP and it’s been rewired to run from a single 5V@2.6A wall wart (sorry for the shoddy cell-phone pic) :
Case 4

Beagle Box

I got a BeagleBoard for Father’s Day. My plan is to put the BeagleBoard, the Pico Projector and a battery in a small box, write some ALife software and carry around a virtual world. Tonight I started mounting the board and projector inside a fake book:
Case 1
Case 1
Case 1

Something useless for xmas

I needed a ~$5 gift for family xmas this year, and was at a loss. Then I remembered the Useless Machine from Make, also known as a “Leave Me Alone Box.”  I had a $5 box from the thrift store, a smaller version of the one I used for my iPad Charger.  After a lot of planning in AutoCAD and even more trial and error I came up with this:

It took me a while to figure out how to put it together with the cam attached to the lid, and my daughter suggested a rod & tube setup:

The cam is connected to the lid through a bearing and a brass “bicycle fork”:

When the cam spins, it lifts the lid enough for the arm to come out and flip the switch.

One thing that I did slightly different was use a 5V DPDT relay to reverse the motor instead of a DPDT  switch. This allowed me to use a SPDT switch with a lower actuation force.

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

Mazetrix Bottom

Mazetrix Bottom

Mazetrix Top

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

schematic

Mazetrix Layout

Mazetrix Layout

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:


Next Page »