On one of my shopping trips around North-West London (ON, Canada), I came across this plastic truck toy at a price of CAD $1.00 plus taxes. As a toy it's probably nothing special, just a piece of plastic with wheels but what made me wonder is if it can be used to create a small robot platform. I wasn't sure what this platform will fit better for 'line-follower' or 'obstacle-avoider' project, so I decided to follow already familiar path and turn it into RC vehicle first using nRF24L01 module and RFL remote control. The chassis are rather long so it makes them rather inefficient when it comes to skid stirring (or so I thought). Hence my plan of action is to see how chassis will perform as an RC platform first and if there is a good reason to use them for more complex 'thinking' robot projects. It's nice to know your chassis limitations before you commit time and effort to attaching sensors and other peripheral electronics.

So first things first, the mechanical part. I had to cut off stock wheel holders and attached four micro-motors using Pololu's motor holders/clamps. Four of these motors should provide adequate torque and skid stirring ability to the platform. Next I soldered wires to the motors and ran them from the under-belly to the top side of the vehicle where all of the electronics will be attached.

 For a while now, I have wanted to experiment with the rocker-bogie type chassis, read NASA Mars Rover, and seeing its mechanical merits. However, the time and effort needed to construct one has been preventing me from doing this. Creating this type of chassis without a significant time commitment is easier said then done, unless you already have the right set of components that play well together.

This is where the right blend of build-plate strips, Meccano parts and micro-motors come in handy to build the table-top version of NASA Mars Rover quickly - the 'R0kker-bot'. The build-plate construction system is a set of aluminum strips that can you can drill, bend and cut to any shape or form you wish. And just in case you're not up to speed on what Meccano is, you can look it up here; I highly doubt that though, as you are here and reading this, but just in case :).

The basic chassis setup, excluding wiring and electronics took three hours to complete. You can bolt together the main chassis in an hour using Meccano parts, and it takes another two hours to drill and attach the motors using build-plate aluminum strips. Most of those three hours went into trying to fit Meccano and build-plate components together nicely, and into ensuring that the dual-wheel arch frame has enough clearance for rotation and doesn't get stuck against the main robot body. Meccano’s large bolts do get in the way; therefore it is essential to make sure that there is enough clearance between the frame and the main body. In the picture below, you can see how the motor/wheel combination is attached to the build-plate aluminum strip and then to the Meccano part with regular Meccano bolts. Once the mechanical part was finished, I proceeded with getting everything wired up.

Ever tried to access your Hammer board remotely using XBee? Well here is how you can do it.

You will need to follow these instructions from Tincantools to enable 2nd serial (UART2) port on Hammer module. Once done, re-compile , upload and flash your new kernel. The following link will help you with how to do that. Once this is accomplished, let's move on to enabling getty console on UART2. IMHO, this seems to be the easiest way to test serial port functionality. And this is how we do it:

• gunzip root.tar.gz;
• mount root.tar into temp dir of your choice ( mkdir temp; mount -o loop root.tar ./temp );
• 'cd' into mount directory ( cd ./temp )
• edit etc/inittab: add 'ttySAC2::respawn:/sbin/getty -L ttySAC2 115200 vt100';

• This is how your final serial port configuration block of etc/inittab will look like.

  # Put a getty on the serial port
  ttySAC0::respawn:/sbin/getty -L ttySAC0 115200 vt100
  ttySAC2::respawn:/sbin/getty -L ttySAC2 115200 vt100

• To enable 2nd serial in your build root system, you will need to change target/device/Samsung/Hammer/target_skeleto/etc/inittab

What happens when you need 3.3V controller board and spare DEV-32 board lying around? Well, you end up converting one into 3.3v logic friendly controller board.

The process is not too complicate but requires extra hardware such as ATMega324p or ATMega644, a couple of 3.3V voltage regulators in TO-92 form-factor and some patience. You could use any other newer micro-controllers that support lower voltages and are pin compatible with ATMega32.

 Benefits of running DEV-32 at 3.3V

• you can easily interface with 3V logic level components such as XBee, EM408 GPS, Copernicus GPS, etc. without extra voltage level-shifting components;
• you reduce your power requirements;
• you can use one of the lighter/smaller LiPo batteries to power your micro;

I decided to update BUGGER status while we are switching gears between the projects and I have a few spare minutes to write this up.
The BUGGER finally got it's long promised nRF24L01 transceiver. Now we can control BUGGER with RFL robot remote. It's definitely fun watching this tiny four-wheeler buggering through cluttered table environment while you doing your best not to run it off the table. We also lowered the camera to reduce platform profile so it could squeeze into even tighter places for undercover missions.

On software side, we forgone using Arduino IDE to write code and used AVR Studio with AVRLib instead. The reason for this is that we found a nice nRF24L01 library that works well with Procyon AVRLib. And benefits of saving time on software development process under current circumstances tipped the scales towards non-arduino software. Great thanks to Stefan Engelke and Procyon guys for creating and maintaining great software libraries.

A few words on nRF24L01 handling logic . The code monitors for logic change on PD2 pin. Once PD2 goes low, interrupt handler routine kicks in and sets global dataReceived flag signaling that we received data on nRF24L01 module. The routine also clears nRF data_received status register. During main program loop execution, the code checks if dataReceived flag was set and if it was it will go over SPI to retrieve the data from the transciever module. Now there might be a better way of doing the same thing but it currently works for the BUGGER so we will stick to it for now. The main advantage of this approach is that we don't need to pool nRF24L01 module for data every time we start a new loop, we will only initiate SPI transfer once we were notified by the transceiver about the 'incoming'. This approach should save us a few processing cycles so we could use them for some greater good. :-)