Time to code some autonomous operation

I will have to upload a video of the 'bot maneuvering as a very expensive remote control tracked vehicle but here is a picture that it took of me after a romp around the lounge.   The special effect is due to my telling it to start moving at which point it orients the sensor stalk forward.   This image just happened to be taken at that second.   It is pretty much where I want it to be at this stage of the project.

There are still a few small bugs, or areas for reconsideration, in the controlled operation but not serious enough to keep me from starting the next phase of the project...getting it to do something on it's own!

Following a compass bearing (or NOT!)

One of the things that I would like for my 'bot to be able to do is drive in a straight line.   Seems simple but unfortunately I seem to have one motor pulling slightly differently than the other.

My first try at correcting for this was to simply put in an adjustment factor for the motors.  This helped but to make things interesting it seems that the 'bot motors behave differently at different battery charge levels (and speeds).   So, I said to myself, why not write a routine that detects the drift of our heading and then tweaks the adjustment factor?   I then said to myself, it should probably be sensitive to the amount of variation and raise or lower the amount of each adjustment based on the deviation in our heading.   Finally, and this was turning into a long conversation with myself, I said to myself, you should probably put in a quiesce for a number of cycles to let the adjustment take effect before trying again, and, you should also make these different factors tunable as startup arguments.

So we (me, myself, and I) get all this coded and try it out.   Does not work.  Not even close.  It appears to be doing all the right things but the 'bot is veering radically to the left.   We put in all kinds of debug statements and can not figure out why it would be acting this way.

Finally it dawns on us.   In an earlier post I mentioned that we are renting a place (moving out in a couple of weeks now that we have finally bought a place) that sits just about underneath Brunei's famous Sounding Arches railroad bridge in Maidenhead.   This has to be one of the busiest train lines in the world as it is the major east west line into and out of the centre of London.   I knew that we get a lot of electro magnetic interference from the trains but thought that was only the occasional variation in bearing as a train passes (also plays havoc with TV reception via an ariel).   As you can see from the two compass readins we are getting a lot more than just an occasional glitch.   These two readings are taken long a five foot divider between our kitchen and lounge.   In that five feet we get a variation in bearing of almost 20 degrees!

It is NOT my code that has an issue here!  The 'bot is chasing a compass bearing that is far from constant to the magnetic north pole!

Imagine the look on my face...

...when my RPi would not boot right after I finished some power supply work on the 'Bot!?!?   I was so convinced that I had fried it that I was researching diagnostics to prove the point.   All I got on power on was a red light.   No green flashes.   Nary a one.

What I guess I did not realize is that a bad SD card will result in the same lack of green flashing.   That is good news.   Also on the good news front is that I have a backup of the boot partition and when I dd'ed it back onto the SD card everything in 'Botland was right again.   Err, well not quite.

Somehow, whatever took out the boot partition, also caused some pretty significant damage to the primary partition where everything else lives.   But not to worry we have a backup of that as well, right?  Err, well not quite.   You see, I give the advice, but I don't have to follow it!   The backup that I have is not exactly up to date.   I am not sure how up to date it is, or is not, so I am going to have to rebuild it.

-----UPDATE as of 5/12/2012 ----

It is the next day now and I am still recovering from the above fiasco...the part where my backup of the primary partition was not where I remembered putting it!   So I am re-creating the entire configuration, rationalizing that it is something I wanted to do anyway, and swearing that I will make good backups from now on!

Version control - for hobby 'Bot software?

You may not think that you need version control for a "hobby" project until you need it!   The code base for the 'Bot is getting pretty hefty and I have had a couple of times when I have implemented a series of changes and had some unexpected breakage.  I have implemented some pretty sophisticated version control as part of my Form Builder for PHP project (where all updates to test and production are done via diff files generated from development) but until this week had not been using any versioning for the 'Bot.

There are some simple ways to maintain versions of code.   If your operating system supports file versioning you can simply turn that on.   You can make periodic copies of your code directory.   If you are using a backup solution it likely maintains versions of current backups.   These all work but don't offer the additional functionality of a versioning tool like Apache Subversion combined with a front end like SmartSVN.

Below is the primary form from SmartSVN.  It shows the directory structure for your project and the files from the currently selected path.   Only files that you choose to be versioned will show in this list (in my case Python files).   If a file has been modified but not committed it will show as changed.

The bottom of the above form shows the latest revisions.   If you select a revision you can then see what changes were made as part of that commit.

You can, at this point if you realize where you have shot yourself in the foot, reverse those changes!

Bright Idea re RPi GPIO - NOT!

So I had this bright idea that I could use the RPi's GPIO pins to offload some processing from the Arduino and save some latency in my command processing loop.   Got my ribbon connector all nice and sorted out, connected up the appropriate sensors to voltage dividers to get them down to 3.3v, and only then read the f-ing documentation.    The pins are binary!!!  Doop!

Easy access for the Raspberry GPIO Bus

The Python code that drives the 'Bot functions around a processing loop that has to do a number of routine interactions with the 'Bot's physical contraptions.  This includes checking the bearing along with the 'Bot is traveling, proximity detection from both IR and Ultra Sonic detectors, current detection for stall warnings, and the check for commands from the web interface.

The interactions that go through the Arduino impart an obvious delay but the Arduino is necessary given the limited capacity of the RPi GPIO bus.   What I am doing, however, is offloading some of the above mentioned functions, though not all.   I am also using the GPIO bus to light up a RGB LED to visually show some status indications as the Python script runs.

All this means a number of wires connected to the GPIO bus.   Since it is critical that I be able easily remove the RPi from its resting place on the 'Bot to gain access to the Arduino and Explorer PCB I also needed some way to easily disconnect and then reconnect the GPIO bus.

My solution is shown by the photos to the right.

First I ordered a GPIO cable.  Since it only came with one connector I had to also order a 26 way IDC Ribbon Cable Connector that I attached to the end of the GPIO cable with the connector facing up.   

Next, I ordered a Right Angled IDC PCB Box Header to which I am able to connect my leads on the 'Bot side.   This connector allows me to easily mess with things during development and allows the RPi to be easily disconnected and reconnected as well.

I am not using power from the GPIO bus as everything is powered from the Explorer PCB.  I am using one of the GPIO 5v power pins to feed voltage readings to the Arduino.   The other 5v pin, and the 3.3v pin, are protected with a sawed off jumper connector to prevent any possible RPi frying short circuits.

Last of the hardware mods for the 'Bot

My wife and I just bought a new house so I have been, and/or will be, a little distracted over the coming weeks.   That said I am still making a little progress as shown by these pictures which represent what should be just about the final hardware configuration for the 'Bot.

First the an overall picture and then I will dive into some of the changes and why I have made them.

Some of the most major of the changes for this version of the 'Bot are the new RPi and case that FINALLY came after having ordered them in June.   The RPi case sits on a breadboarding platform above the Explorer PCB.   I expanded that platform a little to give some more room which pushes the RPi further to the stern of the 'Bot.   On top of the RPi is a new USB V2 Hub that seems to be helping with some of my USB issues (devices dropping offline).

 I have also made some power improvements by adding a Li-ion battery pack (2 x 3.7v 4000mAh cells) dedicated to the RPi with it's own power regulator and LED to indicate when it is on.

RPi Power Regulator

RPi Power Switch

RPi Batteries

Since I have decided to use the GPIO capabilities of the RPi to augment the Arduino (more elsewhere) I decided to bring the GPIO bus outside of the RPi and have connected it to a socket that allows me to plug and unplug the RPi when I need to lift the hood to get at the Arduino or the Explorer PCB (more on this here as well).

Finally, at the rear of the 'Bot I have added a little breadboard with an RGB LED (under the bottle cap) that I am using to signal status for the 'Bot (flashing green means all is well, a flash of blue when a command is received, SOS in red if all is not well...and of course solid on or off if the RPi has crashed).   The mini breadboard also has a reset switch for the Arduino since things have gotten croweded!