Search This Blog

Wednesday, 28 November 2007


Consumed with research paper reading (see new list to the right). Some great work out there. Just narrowing down directions to take. Really want to get some practical work done with neural nets and genetic algorithms, but can't be too hasty with those yet :)

Monday, 19 November 2007

The story so far..

A requested update to show my current progress..

URL Key :-

  1. CMUCam3 with Turret Assembly,
  2. Tamiya Twin-Motor Gearbox,
  3. Pololu Micro Dual Serial Motor Controller,
  4. VC21BR1,
  5. VCMX212,
  6. VC21MM1,
  7. Pololu Round Robot Chassis

And the interfaces between the three main systems..

Last week I was hooking up OpenCV with the CMUCam3. I now have a test harness running on the laptop that can grab frames from the CMUCam3 and feed them into OpenCV routines.

Also still battling with the CMUCam3 MMC HAL driver..

Falling behind with keeping up to date with Heroes (S2), Dexter (S2), Bionic Woman, Dirty Sexy Money, ... And consumed with Call of Duty 4 (PC) at the moment..

Wednesday, 14 November 2007


A long overdue post..

I've moved across to looking into why the CMUCam3 HAL driver firmware doesn't like the PQi MMC card I'm using with it. Without access to a scope/analyser it is slow going. I'm testing a custom firmware to step through the MMC SPI startup sequence. So far no indication why it doesn't like the SPI CMD0 sent to the card. Need to head back to that code this week to delve further..

I've also started to hook up OpenCV to the CMUCam3. As a starting point I'm using David Staven's Sparse Optical Flow Demo(PDF) code and AVI. Changing it to UART-talk to the cc3 module and grab camera frames (via a modified CMUCam2 emulation firmware). The Visual Studio workspace is setup, the OpenCV demo working, just need to work on the cc3 interfacing. Then I have a testbed framework to start various image processing experiments :)

Finally, Call Of Duty 4 (PC)... This has sucked up loads of my time. Played solidly all weekend and this week. An initial eight hour stretch to complete single player, before jumping into multiplayer madness.

Wednesday, 7 November 2007


I put a post on the CMUCam forum describing the problems I have with the CAM_RESET line on the CMUCam3 module. And one of the CMUCam developers kindly replied confirming my fears. That line is used to reset the OV6620 camera module, and needs to be pulled low and left along. So it can't be used as a GPIO line connected to the Pololu uDSMC reset pin :( I had thought about dropping in a transistor invertor circuit so that the CAM_RESET could be held low until a motor controller reset is required and a high pulse on that line could have reset the controller (with the appropriate HAL/OV6620 reinitialisation). But with that the mysterious half-voltage drop seen on the CAM_RESET line, it left me fearful of using that approach. Best to leave the camera alone to do it's magic.

The forum reply did make a great suggestion :) I'm only using two of the four servo outputs on the CMUCam3 (for the pan and tilt servos in the turret assembly), so have the spare two servo outputs for use as GPIO lines. I need to make some other cabling to hook it up, but great to have a proper solution for resetting the motor controller.

With that sorted I'm going to head back into the MMC code in the CMUCam3 HAL driver. Fingers crossed I can work out why the current code doesn't like the PQi MMC card I have, then onto fixing it..

Sunday, 4 November 2007

Time for some interfacing..

Before I get onto the interfacing adventure, here's an annoying problem I faced yesterday with the CMUcam3..

I picked up a cheap PQi 256MB MMC card for the CMUcam. Got back home and took the turret assembly apart to fit the MMC card. Reassembled the turret and flashed the CMUcam3 with the 'hello-world' example project. No joy trying the initial file write test in that example. Added some printfs into the HAL driver and hello-world example, and reached a 'DOH!' moment. I hadn't formatted the MMC card for FAT :(
Took turret assembly apart, formatted the MMC card for FAT, reassembled the turret, and tried again.. Still no joy :( I had a dig around further in the mmc_driver and mmc_hardware functions. Referencing datasheets on the SPI programming of an SD/MMC card, it looks like the HAL driver has very limited implementation for MMC cards. The CMUCam WIKI and forum also mention that only certain cards work and some others that CMU guys have tried don't work. So something else to add to the todo list..

Onto interfacing fun..

With the double decker chassis built earlier in the week, it was time to have a closer look at the interfacing of the three systems; VC21 stack, CMUCam3, and uDSMC. Interfacing the VC21 and CMUCam3 should be easy. The VC breakout board has UART4 to connect to the UART0 on the CMUCam3. The issue then was how to get serial data to the Pololu uDSMC board, plus the issue of how/where to get a GPIO line to the reset pin of the uDSMC.

Re-reading the CMUCam3 datasheet lead me to a mini-Eureka moment. The LPC2106 has dual UART built in and CMU have sent UART1 through to a second IDC connector on the module (the Expansion port GPIO). It also looked like the CAM RESET (P0.15) GPIO could be used for the uDSMC reset line. The UART1 sent to the expansion port is already at TTL levels, so no need for the MAX232 line driver, freeing up valuable space for the DE-ACCM2G accelerometer board :)

I made a cable to connect the expansion port IDC socket to the breadboard (only need three lines from it, GND, CAM RESET, and TX2). Then onto changing the 'CMUCam2 emulator' example project to handle GPIO changes and UART1.

It took a little bit of work to get the CAM RESET GPIO setup. The below code is now used to initially select P0.15 as a GPIO output, pull it low for 100ms, before turning it high and keeping it high.
// CAM RESET(P0.15) bit selector
#define CAM_RESET 0x00008000
// Make P0.15 a GPIO
// Set P0.15 as output
// P0.15 low, to reset motor controller
cc3_timer_wait_ms (100);
// Raise P0.15 high

The UART1 setup was a lot easier. The cc3 HAL library is already setup to handle the second UART. It was then just a simple case of adding another input command to the example code. The following shows a simple way to send serial commands to the Pololu uDSMC.

cc3_uart_init (1, CC3_UART_RATE_9600, CC3_UART_MODE_8N1, CC3_UART_BINMODE_BINARY);
FILE * fp = cc3_uart_fopen(1,"r+");
if (fp == NULL)
printf("UART1 is dead\n");
unsigned char buf[8];
// Both motors forward at half speed
buf[0] = 0x80; // Start byte
buf[1] = 0x00; // Device type
buf[2] = (0x00<<1) | 0x1; //M1 forward
buf[3] = 0x40;
buf[4] = 0x80; // Start byte
buf[5] = 0x00; // Device type
buf[6] = (0x01<<1) | 0x1; //M2 forward
buf[7] = 0x40;
for(int i = 0; i < 8; i++)
while((REG(UART1_LSR) & LSR_THR_EMPTY) == 0);
REG(UART1_THR) = buf[i];
I don't think the fflush is needed (and might not even be setup properly) because the cc3_uart_init already setups UART1 to flush it's FIFO after 8 bytes have been written to it. I need to have a further look to see if this is the write way to write out serial data via the UART registers, and whether the HAL code is behaving and thourough.

So two extra commands have been added to that CMUCam2 example firmware image. I've hooked up the 'FW' command to send the motor on commands to the uDSMC, and added the 'MR' command to CLR and SET the P0.15 GPIO line to reset the motor controller. These commands can be sent via the CMUCam3 Frame Grabber program.

So far this 'almost' works. The uDSMC picks up the serial commands and starts turning the motors/wheels. BUT, and a big one, is that after X milliseconds (over 400ish) the P0.15 GPIO line drops half it's voltage and I guess resets/disables the uDSMC stopping the motors. Hmmmm...

Something to look at in the week.

That's all for now folks..