All the news that's fit to assimilate
[ Home | Blogs | Events | Robots | Humans | Projects | About | Account ]Name: Dean Hall
Member since: 2002-10-10 00:05:10
Last Login: 2009-06-19 13:59:20
Notes:
Past Bots:
Current Projects:
1 Aug 2007 (updated 1 Aug 2007 at 18:58 UTC) »
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 .
8 Jun 2007 (updated 14 Jun 2007 at 01:25 UTC) »
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 made the following measurements on just one of the motors using a crappy DMM:
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); } }
dwhall certified others as follows:
Others have certified dwhall as follows:
[ Certification disabled because you're not logged in. ]
Become a fan on facebook
Follow us on twitter
Subcribe to our RSS feed