I need a wireless data connection for my next bot, Argonaut. I am choosing Zigbee, specifically the Series 2 module from MaxStream (now Digi). The modules arrived from Digikey, but I'm still waiting on the carrier boards. I'll detail my work with Zigbee as it progress here .

Instead of the USBasp, me and the SHARP guys have made our own version of the UsbProg. We call it, oh so cleverly, UsbProg-SHARP. It works like a charm.

I also reworked my website so I edit reStructured text files, use a Makefile to build the static pages and rsync to upload to my web host. I wrote up some details on how I did it .

I designed the MMB103 that I am using for my controller board to have an Atmel-standard 6-pin ISP header as well as a PonyProg serial interface. I had been using the PonyProg interface with its software on a Win32 system for years. I lived with the 7 minute programming time (for 128 KiB Flash on the ATmega103). Even after I switched to a PowerBook in 2003, I would always borrow my wife's Dell to burn my chips.

Well, I finally got fed up with the long waits to test my code. I got an STK500 from Digikey. I got the package deal where the STK500 comes with the JTAG ICE MkII. I connected my Mac to the STK500 via a USB-to-serial adapter. I set "AVRDUDE_PORT = /dev/tty.KeySerial1" in my Makefile. I typed "make program" and BOOM! My programming time went from 7 minutes to less than 20 seconds.

This is SUCH an improvement in quality-of-robot- programming- life that it was well worth the money. Next I intend to find something smaller than the STK500 so it is portable. Hopefully I can also find something that is all-in-one, so I don't have to use a USB-to-serial converter and can use power from the USB port.

Follow up (2007/06/13): I plan to make my own version of the USBasp for my portable, USB programmer. I might even etch the PCB with the help of my club-mates at SHARP.

I was recreating my encoder measurement set-up on my breadboard, but having significant trouble. I was just sticking copper wires into the motor ribbon connector. These wires were shaking loose and not giving good connections. I swapped-in some 2x and 1x headers and some Connectamundos and had a much more reliable connection. However, I still wasn't getting good numbers from my test software. It took me about 30 minutes to realize I had a floating ground between my MMB103 board and my breadboard. Once I connect their 2 ground planes, I was back in business. With this better test setup, I am finding that the encoders aren't that reliable. Supplying a short-duration (0.25 s) low current pulse to the motor and returning both motor leads to Vcc results in erradic counts: often little to no change in the count; sometimes the count is even backwards! I attribute this to back EMF: the motor is trying to overcome inertia and fight friction. The magnetic encoders are getting a larger back-current reading. A second source of trouble is when a low "leak" current is supplied to the motor leads. The output shaft doesn't spin any, but the encoders are counting away almost at the same rate as a full-speed spin. I can't explain this one.

I ordered some motors from BG Micro at 3pm on Thursday last week. They arrived two days later at noon via the USPS! They are small MicroMo motors with Faulhaber gearboxes and, best of all, built-in magnetic quadrature shaft encoders.

I made the following measurements on just one of the motors using a crappy DMM:

• No load current @ 5 V: 18 mA
• Stall current @ 5 V: 180 mA
• Angular vel @ 5 V: 84 RPM
• Encoder output (low, high): 0.25 V, 4.87 V

Then today, I connected the encoder output (ChA only for testing) to pin PE4 on my Atmel ATmega103. I used that input so I could get edge-triggered interrupts. I wrote an interrupt handler in C that incr/decrements a 16-bit counter variable. The main program prints the counter variable to an LCD once every second. Here is the code (minus comments so it all fits):

#include <stdint.h>
#include <avr/io.h>
#include <avr/interrupt.h>

 #include "libmmb103.h"


 volatile int16_t encoderCount;


 void
init(void)
{
    encoderCount = 0;
    DDRE = DDRE & ~(_BV(PE4) | _BV(PE5));
    EICR = EICR | _BV(ISC41);
    EIMSK = EIMSK | _BV(INT4);
    sei();
}


 ISR(INT4_vect)
{
    uint8_t chBA;

     chBA = (PINE >> 4) & (uint8_t)0x03;
    if ((chBA == 1) || (chBA == 2))
    {
        encoderCount++;
    }
    else
    {
        encoderCount--;
    }

     EICR = EICR ^ _BV(ISC40);
}


 int
main(void)
{
    init();
    mmb_init(BAUD19200, ADC_CK_DIV_16, PWM_CK_DIV_8, 2);
    mmb_lcdPrintStr("EncA:");

     for (;;)
    {
        mmb_lcdSetLine(1);
        mmb_lcdPrintHex16((uint16_t)encoderCount);
        mmb_sleepms(500);
    }
}

I've done a lot of work on PyMite. PyMite runs on Atmel AVR and ARM7TDMI processors.

Status: All robot hardware work is on hold while I focus on PyMite, my flyweight Python interpreter for 8-bit microcontrollers. I have a paper accepted at the Python Conference: PyCon2003. I want to develop PyMite as much as possible before that time. Demo programs are running and the garbage collector is underway.

Snaggletooth: Through experiment, I found that the ADC encoder software is unable to sample the encoders fast enough (as a background task) to work properly. It reaches about 0x12 ticks/sec then reflects and starts giving smaller tick-per- second values for increasing speed in typical ADC-sample- aliasing fashion. A solution involving comparators and a hardware interrupts is pending.

In the meantime, I wired up a homebrew ultrasonic emitter/detector pair. The emitter uses an LM386 amplifier, and is pretty loud, despite being inaudible. I can determine the loudness because it takes my 3"-thick Physics book to eliminate crosstalk between the emitter and detector in order to get reliable measurements. Range was 5 inches min to 3 feet max. Resolution was nice... about 0.1" per count.

I also started using Larry Barello's AvrX RTOS for the AVR. I've used it before on another project, but this is the first time for Snaggletooth. The motor control system (with velocity measurement) is on a separate task. For the record, AvrX works great! Work on the motor control system is pending the new digital encoders.

Snaggletooth: Shaft encoders are IR reflectance-based sensors mouted inside the gearbox of both servo motors. The sensors read black/white marks painted on the penultimate drive gear. Encoder ticks come in via ADC. Wrote software to count encoder ticks.

Highlights: 100% PWM on a slightly discharged battery yields about 24 ticks per second. 25% PWM yields about 9 tps.

Next: Write feedback-based motor speed control routines. Long term: move to digital encoder sensors.