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..
Showing posts with label CMUcam3. Show all posts
Showing posts with label CMUcam3. Show all posts
Wednesday, 7 November 2007
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.
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.
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.
Issues..
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..
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
REG(PCB_PINSEL0) = REG(PCB_PINSEL0)&0xCFFFFFFF;
// Set P0.15 as output
REG(GPIO_IODIR) = REG(GPIO_IODIR) | CAM_RESET;
// P0.15 low, to reset motor controller
REG(GPIO_IOCLR) = CAM_RESET;
cc3_timer_wait_ms (100);
// Raise P0.15 high
REG(GPIO_IOSET) = CAM_RESET;
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);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.
FILE * fp = cc3_uart_fopen(1,"r+");
if (fp == NULL)
{
printf("UART1 is dead\n");
while(1);
}
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];
}
fflush(fp);
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.
Issues..
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..
Saturday, 27 October 2007
This weeks roundup..
Another week of chipping away at stuff. My main attention has been with the CMUCam3 module. I've been able to flash various example firmwares to the CMUCam3 and it's all working lovely.
I now have two GNU Arm tool chains on the laptop. The Yagarto GNU ARM toolchain for MX21 (ARM9) work, and the CodeSourcery "G++ for ARM EABI" one for CMUCam3 (ARM7) work. As far as setup goes; the CodeSourcery toolchain takes priority (directory PATHs, etc.), with the Yagarto one being enabled via the custom makefile scripts used for MX21 work.
I've also place an order with Technobots (UK) They were a later supplier find, stocking quite a few parts I had ordered from the US, including the Pololu parts. My original Pololu order had four round robot chassis bases, but I forgot the spacer rods on that order. So I was able to grab two sets of spacers from Technobots. The intention currently is to put the four round bases together to form two platforms. Drill through the front top one to make a place to securely mount the turret assembly, and have the top back one somewhere to put the VC21 stack. Hopefully with enough space on the bottom deck to place the motor controller board and power supplies. Then it's back to determining whether the tiny motors and gearboxes can handle that much weight. My current gut-feeling is that they can't..
Technobots have also start supplying Dimension Engineering's Accelerometer boards. So I've order from them the +-2g Buffered 2 Axis Accelerometer module DE-ACCM2G. I've been using a similar MEMS device in the Nintendo Wii development in my day job, so I'm familiar with the intricacies of analysing the noisy output from a MEMS chip (to check out the internals of a Wiimote, head over to this SparkFun tutorial). The 5g Accelerometer module from Dimension Engineering uses the same Analog Devices chip used in the Wiimote. I'm hoping the smaller 2g device is just as sensitive, if not more so.
I can't wait to get this tiny module and hook it up to the ADC on the VC21RB1. The VC Robot COG has a LPC2136 (ARM7TDMI-S) core that contains two 8-channel 10-bit ADCs. Perfect for connecting the X-Y outputs of the DE-ACCM2G accelerometer. With this hooked up on the robot it will then be able to work out it's orientation vector with respect to gravity. I'm also think about using it in conjunction with the CMUCam3 analysis to determine if the motor controller has gone crazy and needs to be reset.
Another bit of software to add to this mix is RoboRealm. I picked up a while back a very cheap USB web camera. So cheap it's default resolution is CIF (352x288), intentionally the same as the OmniVision CMOS camera sensor module used on the CMUCam3. I should be able to prototype an image processing pipeline for the CMUCam3 using RoboRealm, before moving this across to CMUCam3 firmware. Initial results from experiments in RoboRealm look encouraging, but I know it's going to be a huge effort to move any image processing pipeline routines from RoboRealm across to the very limited CMUCam3.
Finally here's a cute photo of the CMUCam3 in it's turret assembly -
I now have two GNU Arm tool chains on the laptop. The Yagarto GNU ARM toolchain for MX21 (ARM9) work, and the CodeSourcery "G++ for ARM EABI" one for CMUCam3 (ARM7) work. As far as setup goes; the CodeSourcery toolchain takes priority (directory PATHs, etc.), with the Yagarto one being enabled via the custom makefile scripts used for MX21 work.
I've also place an order with Technobots (UK) They were a later supplier find, stocking quite a few parts I had ordered from the US, including the Pololu parts. My original Pololu order had four round robot chassis bases, but I forgot the spacer rods on that order. So I was able to grab two sets of spacers from Technobots. The intention currently is to put the four round bases together to form two platforms. Drill through the front top one to make a place to securely mount the turret assembly, and have the top back one somewhere to put the VC21 stack. Hopefully with enough space on the bottom deck to place the motor controller board and power supplies. Then it's back to determining whether the tiny motors and gearboxes can handle that much weight. My current gut-feeling is that they can't..
Technobots have also start supplying Dimension Engineering's Accelerometer boards. So I've order from them the +-2g Buffered 2 Axis Accelerometer module DE-ACCM2G. I've been using a similar MEMS device in the Nintendo Wii development in my day job, so I'm familiar with the intricacies of analysing the noisy output from a MEMS chip (to check out the internals of a Wiimote, head over to this SparkFun tutorial). The 5g Accelerometer module from Dimension Engineering uses the same Analog Devices chip used in the Wiimote. I'm hoping the smaller 2g device is just as sensitive, if not more so.
I can't wait to get this tiny module and hook it up to the ADC on the VC21RB1. The VC Robot COG has a LPC2136 (ARM7TDMI-S) core that contains two 8-channel 10-bit ADCs. Perfect for connecting the X-Y outputs of the DE-ACCM2G accelerometer. With this hooked up on the robot it will then be able to work out it's orientation vector with respect to gravity. I'm also think about using it in conjunction with the CMUCam3 analysis to determine if the motor controller has gone crazy and needs to be reset.
Another bit of software to add to this mix is RoboRealm. I picked up a while back a very cheap USB web camera. So cheap it's default resolution is CIF (352x288), intentionally the same as the OmniVision CMOS camera sensor module used on the CMUCam3. I should be able to prototype an image processing pipeline for the CMUCam3 using RoboRealm, before moving this across to CMUCam3 firmware. Initial results from experiments in RoboRealm look encouraging, but I know it's going to be a huge effort to move any image processing pipeline routines from RoboRealm across to the very limited CMUCam3.
Finally here's a cute photo of the CMUCam3 in it's turret assembly -
Saturday, 20 October 2007
MAX232, uDSMC, CMUCam3
It's been a busy week in and out of work, so only been able to chip away at stuff.
I managed to get Irrlicht compiled and linked into a VC21 example (touch example). Plus using the Insight/GDB/OpenOCD/JTAG combo to download it to the MX21 board. It took some makefile monkey'ng to get it built though. Rolling in at a wooping 18MB elf it took quite a while to download. I only enabled a stub device and display drive, but managed to step through to the Irrlicht startup code. Although Irrlicht is quite bloated with some lovely features I intend to use in the future, it's a bit too much for this initial setup work. So for the time being that side of this project is on hold.
The Pololu chassis and motor controller testing I blogged about earlier. The initial setup of the uDSMC used the simple RS232 converter circuit described in the uDSMC manual to check all was working fine. In the week I popped into a local electrical shop and picked up a MAX232 IC and 7805 DC/DC regulator. These are now used as the main RS232 converter for the Pololu uDSMC and chassis.
A variety of schematics were used as reference to setup this circuitry, for example;
http://www.digitalnemesis.com/info/projects/picservo/article.aspx
http://www.flickr.com/photos/todbot/94701997/in/set-72057594051313379/
http://www.iguanalabs.com/adc2051.htm
The motors are powered straight from the battery source, and the MAX232 and uDSMC are powered from the 7805 regulator. This all works very nicely, and seems more stable. So far no heat problems.
It's now possible to revist the power input for this chassis. I ran out of breadboard space to add a power LED and power switch, so need to look into that at a later date. I'm also only using half of one of the dual RS232 line drivers inside the MAX232 (to pull down the RS232 signals to TTL levels needed for the uDSMC), but it does allow for future expansion. It's now possible to add quite a variety of other TTL based devices to this circuit (e.g. sensors, alternative motor drivers). Eventually I'll transfer this to a stripboard and clean up the cabling and power connections.
Once complete I revisited the custom communication software I wrote to talk to the uDSMC. Adding to it a different way of handling cursor keys from the laptop, and using linear ramping for the speed sent to the uDSMC. Still need to revist the braking side of that code, but it was happily moving around the desk controlled from the laptop.
While setting up different software test harnesses, I had intended to start using Eclipse as my main IDE. Annoyingly though Eclipse does some daft things. It's quite an alien IDE to me, so I've ended up ditching it in favour of Visual Studios Express Edition (again free). Creating an extensive makefile system, with proper dependency checking etc. I can now use this as a template build system for further SW development. Insight and OpenOCD are also included in this setup.
Inow have a Subversion server running on the laptop. After many years using RCS it is now ingrained in my SW development pipelines. We currently use SVN at the company I'm working for. It's fairly nice, has it's quirks of course, but it's a lot better than VSS. Thinking about it though I could have grabbed Perforce to handle the SCM/RCS, but then SVN and it's shell integration works well enough.
This setup actually turned out to be really simple. Head on over to http://svn1clicksetup.tigris.org/ for a single installer based method for setting up SVN and your first repository :)
At the end of week the CMUCam3 module arrived from Seattle Robotics :)
Need to pop to the shops today to pickup a power connector for this, then I can check it out and have a play. Can't wait... :)
I managed to get Irrlicht compiled and linked into a VC21 example (touch example). Plus using the Insight/GDB/OpenOCD/JTAG combo to download it to the MX21 board. It took some makefile monkey'ng to get it built though. Rolling in at a wooping 18MB elf it took quite a while to download. I only enabled a stub device and display drive, but managed to step through to the Irrlicht startup code. Although Irrlicht is quite bloated with some lovely features I intend to use in the future, it's a bit too much for this initial setup work. So for the time being that side of this project is on hold.
The Pololu chassis and motor controller testing I blogged about earlier. The initial setup of the uDSMC used the simple RS232 converter circuit described in the uDSMC manual to check all was working fine. In the week I popped into a local electrical shop and picked up a MAX232 IC and 7805 DC/DC regulator. These are now used as the main RS232 converter for the Pololu uDSMC and chassis.
A variety of schematics were used as reference to setup this circuitry, for example;http://www.digitalnemesis.com/info/projects/picservo/article.aspx
http://www.flickr.com/photos/todbot/94701997/in/set-72057594051313379/
http://www.iguanalabs.com/adc2051.htm
The motors are powered straight from the battery source, and the MAX232 and uDSMC are powered from the 7805 regulator. This all works very nicely, and seems more stable. So far no heat problems.
It's now possible to revist the power input for this chassis. I ran out of breadboard space to add a power LED and power switch, so need to look into that at a later date. I'm also only using half of one of the dual RS232 line drivers inside the MAX232 (to pull down the RS232 signals to TTL levels needed for the uDSMC), but it does allow for future expansion. It's now possible to add quite a variety of other TTL based devices to this circuit (e.g. sensors, alternative motor drivers). Eventually I'll transfer this to a stripboard and clean up the cabling and power connections.
Once complete I revisited the custom communication software I wrote to talk to the uDSMC. Adding to it a different way of handling cursor keys from the laptop, and using linear ramping for the speed sent to the uDSMC. Still need to revist the braking side of that code, but it was happily moving around the desk controlled from the laptop.
While setting up different software test harnesses, I had intended to start using Eclipse as my main IDE. Annoyingly though Eclipse does some daft things. It's quite an alien IDE to me, so I've ended up ditching it in favour of Visual Studios Express Edition (again free). Creating an extensive makefile system, with proper dependency checking etc. I can now use this as a template build system for further SW development. Insight and OpenOCD are also included in this setup.
Inow have a Subversion server running on the laptop. After many years using RCS it is now ingrained in my SW development pipelines. We currently use SVN at the company I'm working for. It's fairly nice, has it's quirks of course, but it's a lot better than VSS. Thinking about it though I could have grabbed Perforce to handle the SCM/RCS, but then SVN and it's shell integration works well enough.
This setup actually turned out to be really simple. Head on over to http://svn1clicksetup.tigris.org/ for a single installer based method for setting up SVN and your first repository :)
At the end of week the CMUCam3 module arrived from Seattle Robotics :)
Need to pop to the shops today to pickup a power connector for this, then I can check it out and have a play. Can't wait... :)
Friday, 28 September 2007
CMUcam turret assembly
I've had the CMUcam turret assembly sitting in a box for the last week (ordered from http://www.robot-electronics.co.uk/) waiting for certain missing tools to turn up. They turned up on Wednesday, but a party last night delayed the initial assembly. I'm also waiting on the CMUcam3 module turning up from Seattle. In the mean time I thought I'd get it built and see what size it built to. The size certainly shows that the Pololu chassis is going to be too small.
Wednesday, 26 September 2007
Random babble
While waiting for the other orders to turn up (been a few more, CMUcam3 module to go with the turret assembly, big order of components/parts/tools, Pololu motor controller) I thought I'd jot down some plans and ideas.
The laptop is now charged with all sorts of dev software. Off the top of my head;
The Olimex JTAG and Pololu chassis are sitting lonely, hopefully the other parts will trickle in over the next week or two. Mind you with the Egypt holiday next week, it's going to be maybe a welcome break to step back and hone the direction a bit.
As for direction :p
Current plan is to get the VC21 modules working together, with precidence on the LCD touch screen working alongside the MX212. With a port of the Irrilicht engine to Linux on the MX212 So firstly looking at how that can be done. Possible need to look at a device driver for the LCD handling, and definetely a custom Irrilicht renderer.
Next up will be setting up the Pololu motor controller. Initially breadboard the device to the chassis, and feed it through to the laptop to get it tested. Naturally with the appropriate HW to make sure I dont fry it with the RS232 levels. Need more thought on this. Being a SW guy an all. Although that's the main reason to get this cheapo laptop, just incase I do muck up :) I won't!!
Then it's the CMUcam3 with turret assembly. Not checked this out further, but should be easier to test with RS232. The cam module has better handling for that than the Pololu part.
And while all that is going on, do further investigation of single and dual camera vision research.
Oh, and a trip to a hardware/DIY outlet to see what materials they have to make a bigger base. Possible to buy something like a tank-track based chassis, but want to check out whether something can be constructed around the two Pololu chassis first. But then that's getting a bit to ahead of myself. First need to determine how sensitive and accurate their movement is first, before constructing a larger platform (think 2x CMUcam3 plus turrets and VC21 stack) for this robot :)
I'll have a good think sitting by the pool next week. But currently in my mind is a vision for this little robot to move around unteathered with the CMUcam3 (eventually x2) having it's live feed pulled back into the MX212, and into the Irrlicht engine for display. Appropriate processing on the feed (with possible inclusion of ultrasonic scanning help) building up a 3D representation of the world, feeding navigation/AI. All output on the LCD :)
Then it's on to Neural Nets and Genetic Programming...
The laptop is now charged with all sorts of dev software. Off the top of my head;
- GNUARM toolchain (Virtual COGs variant),
- Yagarto (including OpenOCD, Eclipse & CDT),
- Cygwin,
- Visual Studio 2008 Express Edition,
- CMUcam3 SVN update,
- All the VC21 examples I could find (including the latest PC1 one),
- Irrlicht engine source code (compiles to around 37MB debug build currently with ARM toolchain),
- A variety of Linux eBooks (taken from links on Virtual COGs Wiki, thanks guys),
- Start of the datasheet library,
- OpenCV,
- MS PSDK,
- JRE,
- Silabs driver,
- Tortoise SVN & CVS.
The Olimex JTAG and Pololu chassis are sitting lonely, hopefully the other parts will trickle in over the next week or two. Mind you with the Egypt holiday next week, it's going to be maybe a welcome break to step back and hone the direction a bit.
As for direction :p
Current plan is to get the VC21 modules working together, with precidence on the LCD touch screen working alongside the MX212. With a port of the Irrilicht engine to Linux on the MX212 So firstly looking at how that can be done. Possible need to look at a device driver for the LCD handling, and definetely a custom Irrilicht renderer.
Next up will be setting up the Pololu motor controller. Initially breadboard the device to the chassis, and feed it through to the laptop to get it tested. Naturally with the appropriate HW to make sure I dont fry it with the RS232 levels. Need more thought on this. Being a SW guy an all. Although that's the main reason to get this cheapo laptop, just incase I do muck up :) I won't!!
Then it's the CMUcam3 with turret assembly. Not checked this out further, but should be easier to test with RS232. The cam module has better handling for that than the Pololu part.
And while all that is going on, do further investigation of single and dual camera vision research.
Oh, and a trip to a hardware/DIY outlet to see what materials they have to make a bigger base. Possible to buy something like a tank-track based chassis, but want to check out whether something can be constructed around the two Pololu chassis first. But then that's getting a bit to ahead of myself. First need to determine how sensitive and accurate their movement is first, before constructing a larger platform (think 2x CMUcam3 plus turrets and VC21 stack) for this robot :)
I'll have a good think sitting by the pool next week. But currently in my mind is a vision for this little robot to move around unteathered with the CMUcam3 (eventually x2) having it's live feed pulled back into the MX212, and into the Irrlicht engine for display. Appropriate processing on the feed (with possible inclusion of ultrasonic scanning help) building up a 3D representation of the world, feeding navigation/AI. All output on the LCD :)
Then it's on to Neural Nets and Genetic Programming...
Subscribe to:
Posts (Atom)