(- Placeholder for video -)
BB (named after the circuit board and the controller - see below) wasn't born with any specific objectives in mind, rather it was just something that came together while I was awaiting materials for a couple of other projects that needed printed circuit boards. And waiting for my Rasperry Pi.
Anyone who enjoys robotics probably wants to build at least one tracked robot, and this is mine. I actually built the chassis some time ago, just to see how the various fischertechnik elements would combine to make a compact, tracked vehicle, and the answer is that they work quite well as can be seen in the photographs. Each side is an independent drive chain built on an aluminium girder for fore and aft rigidity; the two halves are then joined and locked together with additional elements for lateral stability.
The motors are standard 9v fischertechnik, and a 6 x AA battery box, giving 9v with alkaline cells, will fit conveniently across one end of the chassis leaving room for the electronics.
It's not very fast, and while it was an interesting build it also confirmed my suspicion that tracks are not ideal in most circumstances; in future I'll probably stick to wheels. Or legs.
Something else I fancied doing was building a buggy with a breadboard, so that rather than planning and designing I could just make it up as I went along and go where the fancy might take me. Among my collection of breadboards there are a couple of old "Euroboards" that I bought decades ago - they were a special offer for readers of a now long defunct magazine. They're almost square, and at first sight look like two small breadboards in one unit; the centre channel, however, is 0.6in and neatly accommodates big chips or modules, with development areas to either side. I've seen one of these in a picture of someone else's project but they don't seem to be sold anywhere any more, which is a pity.
I've also been itching to do something with the Pololu Orangutan Baby controller I bought a while back because it looked interesting. I used AVRs years ago, before I started using Picaxes at work. I still use Picaxes, in fact I have two current Picaxe projects on the go (Boe-Axe and Axe Avoider), one of them using the excellent 28X2 Module, but variety is the spice of life and I wanted to get back to AVRs and programming in C. The Baby has an Atmega328 AVR with 32k of program space, all its support circuitry, the ISP programming connector, an on-board regulator and a dual H-bridge motor controller - all in a 24-pin 0.6in module.
I used to program AVRs with a simple parallel port programmer in a DOS environment. These days I use Windows laptops, which have neither parallel nor serial ports, so I invested in a Sparkfun Pocket USB Programmer. It's okay, but in hindsight something cheaper from eBay would probably have done just as well. For software I use the free WinAVR bundle, containing WinAVR, the ubiquitous GCC compiler, Programmers' Notepad and AVRDude. The bundle from the Pololu site includes the Pololu AVR library.
Pulling out the six-pin ISP connector whenever the robot is about to move is a bit of a pain: the easiest place to disconnect the programming chain is where the USB-mini plug connects to the programmer, so the picture below shows the USB programmer temporarily stuck to the top of the battery box with Blutak. This is not strictly part of the robot.
I suspect 99% of control programs start with a beep or a flash - mine do, anyway - and after the battery and the controller were in place the LEDs, the sounder and the big pushbutton followed. The LEDs in this project don't have a specific function but it's always useful to have LEDs in any microcontroller project: they're handy for testing and debugging, as also is the sounder. Every mobile robot needs a pushbutton - you program so that nothing moves until the button is pressed, and that gives you time to unplug the programming cable safely before the robot trundles off. The small pushbutton, bottom left, is a reset switch.
The motors connect to the Orangutan's motor outputs, where they can be controlled using pwm and get the full 9v battery voltage, less whatever is dropped in the h-bridge. If the motor connectors either side of the controller look vaguely familiar that's because they are salvaged case connectors from a scrap PC, as also is the power connector in the far corner, clearly but not very helpfully labelled "Speaker".
The character sitting on the battery box serves no useful purpose whatever - he is actually a 1GB USB memory stick (you have to pull his head off). He has a girlfriend somewhere - if I can find her she'll join him for a photo-call later.
The picture above also shows the ultrasonic distance sensor and the voltage regulator. The sensor is one of the HC-SR04 modules available cheaply on eBay from suppliers in Hong Kong - I paid about ten pounds for four. It's as well that they weren't expensive, since I managed to cook one.
I had unthinkingly connected it to the supply line, which is at 9v for the motors. It worked for quite a while, but stopped eventually and on checking the connection I noticed that the sensor was hot. The 5v from the controller's on-board regulator is not conveniently accessible on a DIP breadboard so the answer was a separate regulator to supply 5v for other devices.
The sensor measures the time taken for an ultrasonic pulse to be reflected back to it, and sends the controller a pulse proportional to the distance from the object, over a range of a couple of centimetres to about half a metre. The video shows it being used to maintain a safe distance from an object in its path.
Later I might mount it on a servo so it can scan left and right and pick out a path between objects.
Something else I've wanted to try is controlling a robot with a TV-style remote. I had a play a while back with an IR receiver and a Picaxe, which has ready-made routines for reading and decoding Sony IR codes, using a retired "One for All" remote (retired because it doesn't do Sky+). It was simple to do and worked surprisingly well.
I'd started to research the Sony data transmission format, with a view to writing similar routines for the AVR, when it struck me that a much easier approach would be to use one of the tiny 8-pin Picaxes as the receiver/decoder and feed commands to the AVR as serial data. Nothing that relies on serial data transmission is ever quite that simple, but once the baudrates and protocols were sorted out it worked nicely. Note that the AVR expects a signal which idles high, which is not the Picaxe default.
In the picture, the Picaxe / IR receiver circuit is outlined in blue.
The IR receiver (from the Picaxe website) is quite sensitive; the remote can be pointing anywhere in the room: there is no need to point it directly at the robot. It is connected to a Picaxe-08M, which is not the current version of the chip but it is what I had to hand, using the circuit shown in the excellent Picaxe documentation. The circuit is shown in the diagram and the program is very simple:
serout 1, T2400_4, (infra)
The Picaxe chip was programmed on a breadboard using the Picaxe Breadboard Cable Adaptor (AXE029). (And in hindsight it would have been more elegant to use a while loop.)(- Picaxe cct diag -) (- Picaxe bb adaptor pic -)
Now that the IR link is working, the program waits initially for a number key to be pressed on the remote, determining which of its operating modes the robot will go into. At present there are only two: key 1 selects remote control mode; key 2 selects the ultrasonic demo routine.
The ultrasonic demo routine is what is shown in the video clip above.
In remote control mode so far - I'm still working on it - the Up, Down, Left, Right and Mute keys respectively cause the robot to drive forward, drive backward, rotate left, rotate right, and stop.
Exit from either mode is by pressing the Off key, whereupon the program goes back to waiting for a number key to be pressed.
(Still to come: steering left/right? ultrasonic scanning? IR object locating? table-edge sensing?)