Search This Blog

Wednesday, 31 October 2007

Super cute

On arriving home tonight I had the Technobots order waiting for me :) Dinner was put on hold for a few hours while I started to assemble the second deck of the robot.

Included in the order is the tiny Dimension Engineering 2D accelerometer board. It will have to wait until the weekend to test it out, and also rearrange the existing breadboard (housing the Pololu uDSMC and MAX232 circuitry).

I couldn't wait to blog-share photos of the upper deck constructed, including the mounted CMUCam3 turret assembly :) How cute is this...

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 -

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;

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 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... :)

Sunday, 14 October 2007

Source level debugging working

After the success earlier today getting GDB to work through OpenOCD via Olimex ARM-USB-TINY JTAG connector, I thought I'd revisit Eclipse and check out the Insight debugger supplied with the Yagarto tool chain.

I closely followed Jim Lynch's Eclipse/Insight tutorial (PDF link) to get Eclipse setup with CDT, Insight, and OpenOCD. His tutorial is geared towards using an Olimex prototype board, but can be easily refactored to work with Yagarto and OpenOCD.

I setup the Virtual COGs 'touch' example within Eclipse, and also setup two external tools; namely OpenOCD (using the VC config script from the VC wiki, see previous blog post) and the Insight debugger (found in the Yagarto tool chain).

With the MX212+MM1 device connected via USB (as before) and the ARM-USB-TINY JTAG connected, it was a simple case of running OpenOCD server from inside Eclipse, then calling Insight from inside Eclipse. Insight was able to run to 'main', and then source step through the code :)

After some initial teething issues, everything now seems to be falling in to place. Very encouraging. Irrilicht here I come... :)


Before popping out for lunch I thought I'd try JTAG/GDB debugging on the MX212. Wow, how easy :) After the shenanigans of getting the right PID setup on the Olimex ARM-USB-TINY JTAG connector XP driver, I wasn't hopefull that the OpenOCD server would be properly working. I came across the config file from VC wiki for the server and sparked it up (link to config file here). OpenOCD server looked like it was running fine in the cmd window (with the ARM-USB-TINY connected first to a USB port of course).

Making sure that JP300 and JP500 (for stack power via USB) were shorted I connected up the MX212 to another USB port on the laptop. The three LEDs on the back of the MX212 were all lit, so ready to go. Also have the VC21MM1 connected to the MX212 in my current default configuration.

Using the 'touch' VC21 example, that I know worked via uMon download, I called up the arm-elf-gdb from Cygwin. Hey-presto GDB kicks into life (thanks to the .gdbinit supplied with this example) and the VC21MM1 becomes active and the 'touch' example is running. Broke into the program in GDB and single stepped the code. All working lovely.

Now just need to go back and setup Eclipse properly for JTAG/GDB work with the MX212... And then on to looking at writing that software driver for the VC21MM1 touchscreen LCD in Irrilicht.

Pololu chassis up and running...

Yesterday I had great fun setting up the Pololu chassis and controlling it via serial communication from the laptop :) After trying out my soldering on a test kit from Maplin (two LED flashing unit), I started work on the chassis and breadboard work for this ickle robot.

As recommended I soldered a 0.1uF Cermamic capacitors across the two motors and feed each pair of wires from the motors through the chassis to the breadboard. The USB-RS232 connector fed the four serial lines required through to the breadboard, with a simple transistor (2N2222A, high frequency, low power) and resistor arrangement to bring the RS232 levels down to the levels required by the Pololu micro dual serial motor controller. This could then be sent a serial bit stream that the controller would interpret and drive the internal H-Bridge to control the two chassis motors.

I had some teething trouble at first by making the mistake of driving the motor controller logic levels at too high a voltage. Ending up with a smoking motor controller :S Thankfully I had bought two of them just in case this happened.

To send the control data to the motor controller ended up being very simple. A Win32 console app, built through the free Visual Studio 2005 Express Edition IDE, opened up and setup the appropriate COM port that the USB-RS232 converter had mapped itself too (under WinXP). Configured to 9600bps, no parity, 1 stop bit, DTR/RTS turned off, and FILE_FLAG_WRITE_THROUGH|FILE_FLAG_NO_BUFFERING used in the CreateFile call to make sure device writes were not cached (although I also used FlushFileBuffers after each WriteFile just in case). It was then a simple matter of using WriteFile to send the 4 bytes worth of data to the motor controller to control the motor states. Some additional GetAsyncKeyState monkeyness allowed for forward/back/left/right movement control.

Apart from frying the original controller, and making sure that stalls didn't kick in the motor controller thermal cutoff protection, everything went very smoothly. Although this is just novice entry level experiments to get a chassis built and moving, it's a nice starting point. I can now do some stress testing of the chassis and controller, see how they fair with carrying heavier loads, and work out what improvements/replacements need to be made for the final chassis and motor control. But before that, I'm going to switch back to the JTAG debugging investigation/learning with the COGs, and setting up a decent makefile workspace (either in Eclipse or VS EE, not sure yet).

Thursday, 11 October 2007


I tried to get the Olimex ARM-USB-TINY working tonight with OpenOCD. At first I tried the drivers supplied with OpenOCD. No joy. Driver installation kept failing to recognize the ARM-USB-TINY device using the OpenOCD supplied driver. Thankfully it didn't take long to find out that the PID in the inf/ini driver files are for another Olimex devier and not setup for the Tiny USB version. This link, and other posts on Sparkfun's forum, describe the changes required to the inf and ini files. After making the changes I can now get the ARM-USB-TINY device recognized and OpenOCD server running. How stable it'll be I'll check this weekend.

After seeing Rush in concert last night, and last week's holiday, time for an early night. More fun this weekend with the COGs and Eclipse...

Monday, 8 October 2007

Back from hols...

Just got back from a wonderful week in Cairo and Luxor. Seen loads of sights and had a very relaxing time. Got tomorrow off to recover from the journey back and to FaceBook the photos :)

Then back to playing with the COGs and the Pololu chassis..