Following the posts on servos and distance sensors, I thought I’d talk about the other peripherals we’re adding to Tigerbot.
A screen is an under-rated part of a PiWars robot. Its really handy not to have to cart a laptop around with you between events and have a way to check that the robot is in the mode you think it is (ask me how we know!). We found this little 128×64 pixel screen on ebay based on the SSD1306. And Adafruit has a lovely tutorial on how to use it.
It can be controlled over either I2C or SPI (just set the pattern of resistors on the back). With this, you can write your code to have a menu of “modes” (one for each event) switch between them using buttons on your controller and display the mode the robot thinks you’re in on the screen. No more laptop on the day!
Another handy peripheral is an IMU. This is a combination Gyro, Accelerometer, Barometer and Thermometer all in one. Of most interest to us is the Gyro. This is a rate gyro – it tells you how fast the rate of rotation is changing (and NOT the absolute rate of rotation). This is a 3-axis device – it tells you about rotation around the X, Y, Z axes. To use it you generally have to calibrate it first – with the robot still and stationary, you take readings from each of the gyros for a while and record the output. These are your zero readings. All future readings from the gyro need to subtract the zero readings. The zero reading can vary with battery voltage and temperature, so be sure to re-calibrate it just before you use it! Now you can turn the rate into absolute rotation by taking lots of readings and integrating them.What use is a gyro? There are a couple of obvious events that could use a gyro:
Straight line speed test
here you’re trying to keep the robot pointed in the same direction all the way to the end
for checking that your turns are exactly 90 degrees (if you’re using wheel rotations for this, how do you know if the wheel has slipped on the surface?)
After some testing (read repeatedly trying to make it do the minimal maze!) we’ve realised that the chassis is very stiff. This means that usually only 3 wheels are touching the ground, which means our turns (and, ahem, straight lines – Shaun) are more variable than they should be.
Solution is to saw the chassis in half 🙂 We’ve separated front and back into separate sections and joined them with a hinge so that the front and back can twist slightly compared to the other end. We’ve added limiters to ensure that it only twists up to 10 degrees of movement so that the obstacle course doesn’t break the robot!
Here’s the print in progress:
And with the rest of the robot installed into it:
Initial testing indicates that the new twisty chassis works better, so that makes me feel much better about totally rebuilding the robot just 2 weeks before the event!
This year I’m lucky enough to have access to a 3D printer. These things are amazing. It is incredible to be able to design something in CAD and then have it in your hand the next day.
Our process has been design the whole robot in a web-based CAD package (like Fusion 360). As an aside: OMG – web based CAD! I can’t believe it exists and is free! Hat tip to Tom Oinn (@approxeng) for introducing me to the idea of it.
CAD allows you to see how the whole thing is going to fit together before you’ve spent a single penny on anything ‘real’. Once you’re happy with the design, you can download an STL file (the 3D model of the part) and load it into your slicer software. The slicer’s job is to turn the 3D model of the part into a list of movements of the print head (aka g-code). It is here that you decide what the infill of the part will be and if you need any support material, etc, etc.
You then send the g-code file to the printer – in our case by copying it onto an SD card, though I’ve recently set up Octoprint on a spare Pi, which gives me a web server to control the printer (i.e. upload g-code files, start prints, etc) and a webcam so I can watch it work while I’m at work. Prints take HOURS. Our V2 chassis took 12 hours to print – which is why being able to monitor prints from work is awesome.
Nothing beats being able to discuss and modify the design of a robot part at lunchtime with your team-mates, then kick off a print and be able to bring in the finished part the next morning to hand over and have them try it out on the robot that evening.
3D printer prices have dropped massively recently – my machine is a slightly more expensive one (a genuine Prusa i3 Mk2S kit for those who care) but clones of this machine can be bought for £100 now! Note that the cheaper kits often take more time to get “dialled in” than the more expesive kits – you need to decide if you are time-poor or cash-poor…
As for running costs, printer filament (usually PLA) costs about 25GBP per kilogram reel. My slicer (slic3r) tells me how much filament will be used to print a part, and our biggest part (the chassis) used about 7GBP worth of filament. I think we’ll end up using most of a reel for Tigerbot and 25GBP is cheap compared with all the electronic parts, and is MUCH cheaper than if you buy ready made parts (wheels, etc). Speciality filaments like the rubbery TPU can be more expensive (we’re using TPU for the tyres).
So two of the PiWars 2018 events suggest using servos to operate something: duck-shoot and golf.
Servos have been around for a long time and have a very simple interface. About every 20ms, you need to send them a pulse. That pulse needs to be between 1ms and 2ms long. A pulse length of 1.5ms will cause the servo to move to the centre position, 1ms and 2ms correspond to the two ends of travel. Note that some servos can move beyond these limits, and some can be damaged if you drive them beyond these limits! If you fail to send a pulse every 20ms, the servo will power down (stop actively driving the motor to a particular position).
See https://www.raspberrypi.org/forums/viewtopic.php?t=46771 for more details and Pi driven solutions.
In Tigerbot, our servos are driven by the Propeller Hat. This is a microcontroller with 8 cores. It takes some of the load off the Pi and because it isn’t running an operating system, it is possible to *guarantee* pulse timings. Our controlling Pi then sends desired servo positions over to the Propeller using I2C, then the Propeller sends servo pulses. Here’s a demo:
Last year we ran with ultrasonic ping sensors, but a lot of the teams were using the VL53L0X time of flight sensors with good results. So this year we thought we’d have a go with some of those too. We got the ones on a pololu carrier board for about 10 quid each.
And they’re *lovely*. I think that under the covers they’re doing something very complicated/interesting and hiding all that from us, but the readings we get from them are very accurate and very consistent. No need for any averaging or filtering code on the Pi side.
Its not all roses though. The minor downside of that complexity is that you need to initialise them with a C-library. If you’re using the python library, that’s all taken care of for you, but we are writing our code in Golang, so we had to mess about linking in that C-library.
Another quirk to be aware of – they are an I2C device, so they all need an I2C address. They come with a fixed one from the factory. If you only have one this is fine, but if you have more than one, they will all have the same address… Other I2C sensors usually allow you to tune the address with jumpers, but this doesn’t seem to be an option with these boards – at startup you need to hold all but one in reset (using GPIO pins) and then send it I2C commands to change the address, and repeat with a different one in reset. We decided we didn’t have enough GPIO pins for this.
Alternatively, you can use an I2C multiplexer like the TCA9548A (adafruit do a nice carrier board for it too). With this, you attach the ToF sensors to the different buses coming out of the multiplexer, then you send commands to the multiplexer to change which bus you want to talk to.
Here’s Tigerbot wearing a few sensors on its front.
At the centre of the robot’s performance is the motors and motor drivers. We’ve tried many options over the years: old drill motors (cheap and powerful, no position feedback), stepper motors (very controllable, heavy, expensive), brushed DC motors with gearboxes and encoders (fairly powerful, fairly expensive, good position feedback).
We’ve considered (but not yet chosen) brushless DC motors (most powerful for their size, controllers very expensive).
This year (like last year) we went with brushed DC motors with gearbox and encoders. Last year’s units came from China via ebay which caused us trouble when a gear cracked at the last moment and we were unable to get a replacement in time. This year I decided that all our critical parts were going to come from suppliers in Europe, and be a brand name so that they could be easily purchased from multiple suppliers.
We went with Pololu gear motors – 25mm diameter units with gearboxes. These motors come in a range of power/gearing options with the same form factor and we could buy them from both RobotShop and TME. The motor drivers were the same as last year: 13A Cytron units from Robotshop. These should be able to deliver twice as much current as the motors can handle.
Here’s the populated chassis. Motor drivers are on the left, Pi + propeller + interconnect board are on the right. Space for a LiPo battery is at the front. And right at the bottom is a little 5V switch-mode power supply (as used in model aircraft) to power the logic boards.
At the heart of the robot is the Pi. But how does it connect to everything else? Via the interconnect board of course 🙂
This little board is where *everything* connects – where all the sensors, motor drivers, power supplies, Pi, Propeller, etc come together. Its a very custom board for every robot, so I generally make it by hand using “padboard”. This is a cheap, 0.1 inch pitch board with drilled pads. Unlike stripboard, it doesn’t have defined tracks – so you make your own with solder bridges.
This allows a more compact layout than stripboard, while still being fairly quick/easy to use.
Our board has headers on it for logic power supply (in the middle), motor drivers (6 pins, near the edges), sonar pingers (blue) and servos (yellow).
And of course with just a few days to go, we’ve had a major disaster on the robot. This tiny gear has cracked:
And so it won’t stay on the shaft. Sadly, its the main pinion gear of one of our motors, so we’re down a motor and we don’t have a spare. 🙁
We quickly ordered another from China (but that won’t arrive before PiWars). We also ordered some similar looking gear motors from Ireland – hopefully that will turn up in time, and the gearboxes will be similar enough that we can either transplant the entire ‘box or just steal the pinion gear from them. *crosses fingers*
Imagine my dread when I woke up to this message from John:
“Are you around tomorrow? I could do with some advice. I’m having an issue with the propeller board which is resetting itself randomly when the motors run at any speed. I think its an electrical problem rather than software, but really struggling to figure out what’s going on.”
The usual advice here – add decoupling capacitors everywhere!
After lots of hunting around, adding new 0.1uF caps to suppress the motors (one cap between the terminals, one from each terminal to the case), John eventually figured it out:
“I’ve been probing around with my ‘scope this morning and the power supply looks dead smooth, so my latest theory is that the reset line is the culprit and is picking up spikes from the motor. ”
And sure enough – a cap on the reset line to our propellor hat fixed it! Phew…