Older blog entries for dwhall (starting at number 5)

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.

21 Oct 2002 (updated 22 Oct 2002 at 15:12 UTC) »

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.

X
Share this page