Pi Wars has many challenges where fast acceleration and cornering are important for the fastest times. Certainly last year Piradigm, whilst it wasn’t the most powerful robot, when running well it was still traction limited in the Minimal Maze and Over The Rainbow Challenges. This year the Straight-ish Line speed test may also require good cornering and the Pi Noon challenge always favours good drivers (or code!) even more if the chassis has good handling. We’re hopeful that our software and hardware this year will be capable enough that extra traction would increase performance. To that end, we’ve started testing a novel ‘vortex generator’ style of generating downforce:
Before we explain the weird design, some background:
Formula one cars corner much faster than normal cars due to their aerodynamics: as they move along, they use wings to deflect the air upwards, pushing them into the ground, increasing grip without increasing weight. This works great if you have the power and speed to do that. unfortunately most Pi Wars challenges are completed at less than 5mph, so the wings would need to be huge to have any effect.
In another, more closely related analogy, Micromouse robots need to accelerate and corner quickly to solve their mazes in the fastest time. As designs have developed, the winning teams in this competition now all use fans to generate downforce. The mice have a flexible skirt under their chassis, much like hovercraft have, but these are arranged so the fan sucks the air out, creating a low pressure even when the mouse isn’t moving, sucking the robots to the ground. This works well since their course is very flat and smooth, so the skirt has almost no leaks. Check out their incredible performance in this video from a competition this year:
Inspired by those, and the small toys that can run on ceilings, I first included a downforce generator in one of my projects in my entry for power tool drag racing:
This design was a little different to the above mechanisms, it used a vortex suction generator, which is a vaned, high speed spinning bowl that spins the air rather than sucking it, to generate the required low pressure with lower power consumption and less reliance on a good seal with the ground. The theory is that because the air is spinning, there must be a pressure gradient to keep the air going in a circle. Since the outside of the bowl is at atmospheric pressure, the centre must be at a much lower pressure, sucking the bowl down.
For Pi Wars we’re hoping to use a similar design but on a smaller scale, and only if the rest of the system is fast enough to benefit from it. So far we have 3d printed the above CAD:
And done some spin up tests in a test rig:
In this test, we held the rotor above a metal toolbox, that was supported by some scales. We were hoping to both test if the rotor could survive the very high speeds required and, if it did, what level of downforce we could generate (measured by the lift or reduction in weight of the toolbox). For the test we were stood well back, with a full face shield on in case the worst happened.
From the test video, you can see it was a successful test: the rotor survived spinning up to ~14000rpm and generated over 900grams of downforce, despite having over 5mm of ground clearance! For comparison, from the latest CAD model we have of the overall robot design, we’re expecting the all up weight to be about 800grams. Which means we should be able to corner at up to 2g, if we have sufficient control.
On the software side, we’ve been further researching kalman filters and how we might be able to fuse encoder data with the data from the IMU to give us the best possible positional information, and we’ve also had a few more components arrive:
What an event! We came away exhausted but with smiles on our faces and three prizes! Here’s how we did in each event: Skittles – 1st
The skittles challenge was one of the only ones where our innovations really paid off, our attachment worked just as we’d hoped and we got spares on every round. We even managed to get a strike on our practice go! We only had one minor issue- there was a slight issue with one of the rotor motors that meant it didn’t always spin up properly but we managed to overcome this on the day by repeatedly spinning up and slowing down until both rotors were spinning properly. The laser pointer worked great for lining up, knocking the pins down to get the spares was really satisfying, we had so much ball speed we not only knocked the spare pin over, we smashed it into the backboard! (back board added just because of our attachment : – ) We also had a very minor issue with maneuvering. We knew we would be very front heavy, but the front tyres compressed so much that the attachment hit ground, adding friction and reducing the grip the rear tyres had. Luckily Mike had time to make some nice little ptfe skids and put lead ballast in the ‘booster’ battery holder. This meant we could actually maneuver, but it was still slightly challenging to line up sometimes.
score: 8,2 9,1 9,1
Speed challenge – 1st
The time spent choosing the motors/voltage/wheel sizes really paid off here, and we got times within 0.1second of what we predicted! Unfortunately we didn’t get the sensor feedback working in time but luckily it wasn’t actually required. Four grippy wheels, tuning the motor speeds to be equal and aiming straight was all that was needed to avoid the sides. We really should have done more tuning beforehand, as we hit the sides on the first few runs whilst dialing the motor speeds in but after that it went straight as an arrow. When we did hit the sides, we just lightly glanced off or continued relatively straight whilst sliding along the sides, so the front bearing guide worked as hoped. Starting at the back of the starting box also allowed us to get some speed up before entering the timed section, saving about 0.1s (fairly significant when your overall time is 1.5s :-). The motors didn’t seem to mind being significantly overvolted for that short period, so we might actually be able to go to an even higher voltage next time, if we can find some suitable motor controllers.
times: 1.618s, 1.54s, 1.526s
Proximity – 3rd
This event was a total fluke for us! We didn’t manage to get the code for our secret (blog post to follow), super accurate sensor finished in time so we were just using a regular IR sensor as many others were. In the hour of testing we got on the day, we were getting +/- 5-10mm of noise in the stop positions, so we settled on a fairly conservative target of 13mm. When we got on the course, the judges commented that many robots using IR had really suffered, so we were then even more nervous. On our first run we got 4.5mm! That was a great, lucky start but we were worried, was that just random luck or was the wall colour or reflectivity causing the robot to stop late? If we got 4.5mm+/-5mm or more, we were quite likely to hit the wall on the next run! We decided to risk leaving the code as it was and lined up for another run. We got 4.5mm again! We’d never been that close or consistent in or practice runs. Maybe the wall reflectivity was actually doing us a big favour. We had originally been testing with a wooden wall, then switched to paper. We had found that the paper might be more consistent but it’s always hard to tell when the results are quite variable. We crossed our fingers and went for the third run: 0.5mm! What a set of results! We were more shocked then anything after the dodgy test performance. It was clearly a fluke but we were just happy we had finished without incurring a fault. We weren’t sure he we’d do in the results, as we’d heard of others getting 0.5mm results and several with consistent few ~3mm scores. In the end we got third.
scores: 4.5mm, 4.5mm, 0.5mm
Three point turn – 7th
This was another challenge where we had grand plans of clever sensors that didn’t quite pan out due to being behind with the code. Like the proximity challenge, we spent an hour on the day of the competition tuning the timing in the basic code we had. We knew the floor surface would have quite a strong effect on the turn speed, so we tested on the closest surface we could find: the textured tiled floor. It didn’t take too long to get the timings pretty close and our test results were surprisingly repeatable. Once we got on the actual playing surface of the challenge though, we quickly found we needed to change a few parameters. On the first one we over shot and drove straight off the platform after the first turn. Luckily there’s just enough time allowed to tune your code once you’ve started the challenge, so we quickly ran back, got the laptop and guessed some new numbers. On the second attempt we were much closer but again slightly went outside the playing surface on the second leg and overshot the finish at the end. Again, we tuned the numbers and went for it again. It wasn’t a perfect run but we at least got back behind the starting line. Dave proved himself as the master of guessing the magic timing numbers , every one of his guesses gave the spot on correction we needed for that element.
times: 16s, 16.04s, 14.5s
Obstacle course – 9th
We were quite hopeful of doing well in this challenge as we had speed, grip, ground clearance and a reasonable amount of driving practice under our belt. We weren’t too worried about most of the obstacles as they were less severe than the wooden obstacles we’d attempted in testing; the one unknown was the turntable, it looked like it might be tricky to line up and time the entry. We’d also noticed in some of the previous challenges that the gearbox that started clicking during testing now wasn’t reversing correctly, so the robot didn’t turn around the centre as it usually did. Rob did a good job of compensating for the dodgy gearbox, getting through the first few obstacles with no faults. The gearbox really scuppered us with turntable though, he struggled to line up and the robot didn’t accelerate straight forwards when asked to, causing us to get caught by the rotating bollards. By an unlucky design fluke, the bollards were a close fit with the gap between our wheels and we got wedged. We have nearly enough grip to climb vertical walls so we initially hoped we’d be able to climb out but we then got wedged against the wall and couldn’t move. In retrospect, we should have been clearer on the rules as none of us knew what the penalty was for getting rescued, so we took some time deliberating. If we’d known it was no penalty for a rescue, we would have moved the robot much more quickly and could have got a much faster time. The rest of the course was uneventful, although we were slightly disappointed with the run over the seesaw. In testing, we’d found the robot was fast enough to hit small wooden blocks and fly quite a distance, so we were hoping we could hit the ramp at speed and finish the course in the air. In reality, the dodgy gearbox hindered s again, and Rob couldn’t quite get it lined up as he hoped. We were still in the air over the finish line, but only because we were bouncing… Still, 1:26 with one rescue wasn’t too bad, good enough for 9th place. We shouldn’t dwell too long on the could haves and might have beens, but after looking at the video for our obstacle run, if we’d rescued the robot immediately after we got stuck, we could have finished in less than a minute with one rescue (no penalties), possibly putting us in first place.
time: 1:26 with one rescue
Pi Noon – second round
Our first round was over very quickly: Rob expertly maneuvered TTOS alongside Bedford Modern then turned in for the kill, popping the balloon in less then ten seconds! The second round didn’t go as well. Mark volunteered to drive this one (mistake?) and we hadn’t had chance to replace the dodgy gearbox (definitely a mistake), so turning was hampered. Westpark Club had the interesting idea of mounting the balloon/spike on the back of their robot, pointing forwards, making it easier for them to keep the balloon out of the way. After a short period of jostling for position, with TTOS failing to get around their side/back, the two robots came together. Westpark Club had lined up better and burst our balloon first. We were out.
Line following – not placed
Before the day we had made the mount for the line sensor and got some simple code written, but it was completely untested. As soon as we saw the course we knew it was pointless to distract ourselves with trying to get it working. The course was so narrow and twisty that we would really struggle to get around it. We had designed our sensor mount to work best on relatively fast line following courses, with no turns over 90 degrees and lots of space between turns, like the course was last year. Those courses favour a sensor that is well in front of the centre of mass. This tight course strongly favoured robots with the sensors very close to the centre of turning, allowing them to follow the very twisty bends and switch backs. So a no score on this one.
Code – 20th
Our low position in the coding probably reflects more on how little coding we’d done when we submitted it than the actual quality of the code. We’ll do better next year!
Aesthetics – 9th
Given we were one of the few entries that didn’t have a mass of wires sticking out, we were hoping to score higher in this challenge.
Build Quality – 9th
Like the aesthetics ‘challenge’, we were hoping to do fairly well here, as the core robot was solid and had some nice features. Maybe not actually having enough room for the wiring and connectors let us down, or maybe we didn’t ‘sell’ the design enough to the judges.
Blogging – 12th
Not a bad score, considering we didn’t start until pretty late in the day and some of the other blogs were excellent.
Overall – 3rd!
A fantastic result for our first time at the competition! With a bit more consistency and preparation, we’re hoping for higher next year
🙂
Other awards
Most featured
We knew we’d got more attachments than many of the other competitors but hadn’t considered this was an award during the run up to the event, so we were quite surprised when we were announced as the winner!
or “How I Fell in DooDoo and Came Up Smelling of Raspberries”
OK. Picture the scene. It’s late on a Friday night, and you’ve been hacking on your Pi Wars robot all evening. It’s been productive. Between you and co-roboteer, you’ve ironed out glitches in your Remote Control code, you’ve soldered up the wiring looms, and you’ve even designed and printed custom parts to mount the pi onto the baseplate you laser cut earlier. You’re robot building machines. Go you. High fives all round.
Flushed with success, you both decide to power up the pi and take it for a spin. So, you plug in the USB cable that you wired up to that adjustable 5v regulator earlier to step down the power from the lipo battery, and… uh. I’m pretty sure the activity light doesn’t normally do *that* when it’s booting. what the..? yank the power! yank the freaking power!
Welcome To Cockupsville. Population: You
OK. wait a second. what just happened? Well, remember that 5v regulator you wired up earlier? The key word there was adjustable, Dingus. And you didn’t check it, did you? You buzzed every single other thing you soldered, but you forgot to check that the output voltage was actually, y’know, ADJUSTED to 5v. So you just sent how many volts into your Pi? 12? Excellent work. well done. Slow hand clap.
You decide to check the damage, hoping against hope that the Pi just kind of wouldn’t notice that you just rammed 12v up it’s tiny USB port and you can pretend like nothing happened. After all, no blue smoke came out, so … fine, right? Fine. Probably fine.
Except, no. Adjusting the voltage regulator to 5v (triple checked – bit late now, but whatevs) and trying to boot again does nothing. Well, not exactly *nothing*, but only some flickering of the activity light and no actual booting. Saddest of sad faces.
Alas Poor Pi
So that’s that then. You’ve fried your pi. It has gone toes up. Time to give it a viking funeral.
But. BUT. A bit of Googling seems to suggest a few things:
There is such a thing as a polyfuse
They can heal themselves when they’ve tripped.
Actually flipping *HEAL THEMSELVES*
The Pi has one on the USB power input.
So you leave it an hour and, with great hope in your dumb little heart, you plug it in.
…
…
Nothing. Just a bunch more flickering. Probing across the polyfuse seems to suggest that it’s maybe a bit better, but still a loooong way away from being useful as part of a functioning computer. sigh.
M. Night Shyamalan style plot twist
Fast forward two weeks. You’ve nearly forgiven yourself for frying a perfectly innocent Pi. You’ve ordered a replacement and plumbed it in to your Bot, and you’re sitting at your desk idly surfing the web when you see out of the corner of your eye that poor little dead Pi, half hidden under a pile of papers. “I wonder…”, you, um, wonder.
So, you dig out a phone charger and a cable, and you plug it in. <DEITY> be praised! It’s booting. It lives! You’re like the Doctor freaking Frankenstein of consumer electronics! Except that he made a sort of patchwork quilt of chopped up people and you’ve reanimated a credit card sized computer. Same thing apart from that though. Probably.
Step aside Pi Zero, I give you Pi Zombie!
So, there you have it. You too can get away with stuffing 12v into a 5v hole, if you’re very, VERY lucky. But what have we learned? Well, we’ve learned:
If someone gives you an adjustable voltage regulator and tells you that it’s set to 5v, don’t believe a damn word of it.
Stick your multimeter across EVERYTHING.
Raspberry Pis don’t like 12v up them, Corporal Jones.
Polyfuses are an actual thing. They freaking HEAL THEMSELVES, people. Insane.
Sometimes you can fall in the doodoo and come up smelling of Raspberries.
