It is time to build a new rover, and to take a different look at how we can determine how it is controlled by a series of behaviours, defined using the tenets of Behaviour-Driven Development. BDD is a superb way to undertake development as it emphasises genuine communication and collaboration between business stakeholders, Developers and Testers. Behaviours are defined as features and scenarios, the latter elicited as specific examples using the Gherkin syntax, for example:
Scenario: Drive forwards
Given Zumo George is greater than 10cm from a wall
When power is applied to the motors
Then Zumo George should drive forwards
BDD scenarios are written before other code, and determine what code is written. Hence no wastage: we develop what is required and it most likely passes first time. When the scenarios (the tests) are executed we can clearly see which steps pass (green), fail (red), or have not yet been implemented (that sort of muddy green-yellowy-brown).
I will be exploring the use of BDD to program this rover in quite some depth over a number of articles, intermixing some electronics to show how BDD is an ideal abstraction to explore behaviour-based robotic control. I’m going to term this BDR, Behaviour-Driven Robotics.
In the above example you will note too important points: firstly in the second feature I am defining scenarios that can be used for an internal diagnostic on Zumo George, for example: “Confirm ultrasonic is responding”. These tests will be executed every time Zumo George boots and if any test fails then he will flash a red light and not commence roving which should avoid the problem of an out of control robot. Perhaps more importantly, you can see that George has no lasers and has not been programmed to use them in any case (the first three undefined steps). This is fortunate for obvious reasons.
You will already have noticed that I have named my robot Zumo George and given him agency. I think this is a good thing as he will be expected to mimic certain human behaviours (e.g.: don’t bump your head on a wall while walking / driving). Agency in a robot enables me to mimic human-like behaviours in code. It does however mean I will find myself leaning towards anthropomorphism, referring to Zumo George as “he” rather than “it”.
The chassis of the rover is based on Pololu’s Zumo (hence the rover’s full name) and Pimoroni’s recently released Explorer HAT Pro. The Zumo is available in a number of variants for Arduino such as the all singing Zumo 32U4 which has sensors, buzzer, LCD, accelerometer and more, and also the bare-bones Zumo Chassis Kit which is perfect for the Raspberry Pi as we can add our own electronics.
The Zumo is very compact meaning that any model B is borderline too large. Whoever would have thought the words “too large” would be used to describe the Raspberry Pi! This is because the Zumo is designed to take part in Mini Sumo competitions where the robot must conform to dimensions of 10cm by 10cm. To be honest, a B/B+/v2B would just about squeeze into the available space and certainly others have created Zumo robots using the B. To minimise the footprint I have opted for a Model A+ which is almost small enough (ahh if only it was 1.5mm thinner. More about this in a later article).
I purchased my Zumo from those excellent people at Pimoroni, and also elected for two 95:1 ratio motors. The motors are intentionally purchased separately to enable you to opt for those that best match your robotics need (essentially outright speed versus torque). You can easily drop in replacement motors if you change your mind at a later date as the plastic motor cover on the chassis is removed with just two screws.
At this point a confession is in order: I like to tinker with things and see if I can break them. I think this is because my day job is in software testing. Unfortunately this tendency to meddle with things caused me to break one of the motors, necessitating ordering a third. The lesson quickly learned is never manually rotate the drive shaft of the motor as you will quickly grind down the gears until it slips horrendously in use. I share this in the hope that you only have to purchase two motors. On the plus-side I do have a (slightly crippled) spare motor I can now disassemble to better understand how the gearing works. To be honest the motor mechanism itself is fine as it is just the cogs that are worn so there is hope yet that I can resurrect this for a future project.
I considered various options to control Zumo George’s motors and in the end put four possible solutions up against each other in a winner-takes-Zumo knock-out:
- PicoBorg from PiBorg
- L298N H-bridge motor controller (generic, available from eBay)
- Ryanteck RPi Motor Controller Board
- Explorer HAT Pro from Pimoroni
PicoBorg is tiny, it really is, and is a great first-step into robotic motor controllers. I’ve had great success using this with a larger robot based on the Magician Chassis. However it is not bi-directional without the use of a pair of 5V relays and including such immediately bulks out the parts list as one also needs a board and cabling to mount them on. Bi-directional capability is essential in a tracked robot (IMHO) as it provides the ability to turn on the spot and not just in an arc. PicoBorg Reverse was briefly considered as a possible solution, but at £31 for the board was felt to be pushing the budget a bit.
The L298N is the go-to staple of bi-directional controllers. With prices in the £1.50 to £4 region it wins on cost. However it is a comparatively bulky thing with a big heat sink rising vertically, and as a 5V device requires additional circuitry for safe usage with the Raspberry Pi. This makes using it in a compact platform somewhat tricky.
The Ryanteck RPi Motor Controller Board is a great bit of kit. It provides bi-directional motors and is compact. Ryan has done an excellent job of documenting the board and providing example code in Python. The GPIO pins are also exposed making it easy to add further electronics (PicoBorg can be mounted on TriBorg for the same effect). I was all set to purchase this board when I spotted an announcement from Pimoroni…
The Pimoroni Explorer HAT Pro is a crazy good board. Using the available easy-peasy Python library one can control both bi-directional motors and take advantage of a large number of other available inputs and outputs. These include four capacitive touch sensors, four pads to attach crocodile leads to, four buffered 5V input and four buffered 5V output pins, two 5V buffered ground pins and 5V buffered analog pins. Also down one edge of the board are an array of 3v3 pins for use that are not buffered. To finish the board off there is even space for an included mini breadboard to be mounted on top. Coming in at the same size as the A+ this is my new favourite wonder board for the Raspberry Pi.
My parts list is now:
- Pololu Zumo Chassis
- 2x 95:1 micro metal gear motors (I needed 3 *ahem*)
- Pimoroni Explorer HAT Pro with mini breadboard
- Generic tiny WiFi network adaptor
- 16GB Integral Micro SD Card
- Raspberry Pi Camera
- Bendy arm thing to hold camera up
- Pimoroni Camera Mount
HC-SR04 ultrasonic distance sensora Sharp GP2Y0A41SK0F IR distance sensor, sourced from eBay (see Part Two)- 3x plastic legs to raise up the Raspberry Pi Model A (more on this next time)
- An assortment of wires to hook everything up.
- Ryanteck 3 Line Follow Sensor (not shown in the above photographs)
You will note two seemingly obvious missing items, namely a battery and some kind of game controller to drive Zumo George for when he is not in auto-roving mode. I am also investigating pan and tilt mechanisms for the camera and / or distance sensor. These parts will be covered in later articles. I have something cunning in mind for the battery but can’t say more about this at present.
View more at: http://bit.ly/1XReQFr
Post a Comment