As I said in my previous post of this series, we had miraculously made it through to the National Finals, despite our car being made out of an unsustainable material and not even navigating the course properly at the Regionals! We were truly surprised at the result, but still aware of the challenges that faced us.
On the ride back to the school inside my teacher’s cramped black Mini Cooper, we discussed various things that we would have to do within the 27 days before the Nationals: we would have to rewrite our presentation according to the judges advice, rebuild the entire buggy out of a more sustainable material and design an entirely new algorithm to even stand a chance of winning the Nationals. We were representing the South East of England, and we wanted to at least achieve a respectable ranking!
Following a day of chit-chat, discussing the various things that had to be done, we consulted a few technology teachers as to what material would be best to use and could be assembled into a buggy quickly enough. All signs were pointing towards aluminium, being an infinitely recyclable material, but I was sceptical about the timescale it would take to build this, especially considering that it took us two and a half weeks to assemble a laser-cut case. The aluminium would need to be drilled, cut and sanded to precise specifications and then assembled with nuts and bolts.
After a short, but convincing argument, we concluded that rebuilding the entirety of the buggy, including base, chassis and lid out of aluminium would be feasible, and we went ahead with the planning. Sides needed to be individually cut out, done by me during my games session for two and a half hours in the workshop, and drilled to accompany the holes that would hold them together. After three days, we had all the parts cut, and by the middle of the following week, all holes were drilled.
During this time, the systems engineer had been working on 5 different algorithms, to prepare us for any eventuality at the nationals, in case of “compass capitulation,” as we called it. These were all being tested on the older buggy, now named Mark 1.
Actually assembling the new buggy proved to be somewhat difficult! The holes were not drilled precisely, meaning that only certain aluminium angles would join certain sides specifically, turning the buggy into a kind of jigsaw puzzle! This needed to then be disassembled to drill some more holes we had forgotten, like those for the hinges on the lid, followed by another after school session of fitting the jigsaw puzzle together while the Mark 1 buggy was being tested on brutally by the systems engineer.
With the new case assembled, we had to deactivate buggy Mark 1 by removing the ball bearing mount, SRF05 sensors and the PCB containing the electronic control systems. All this, we believed, would be relatively easy to install, before we noticed the fact that the whole thing would short circuit due to the L298N motor driver IC heat sink being connected to ground, which was connected to the metal case, meaning that any loose connection, solder, track or wire touching the case would render the system useless (temporarily). This meant that sticky pads were used to hold the PCB down, not bolts, and the heat sink on the motor driver chip had to be connected to the case with a spacer and a plastic nut and bolt.
After redesigning the SRF05 sensor mounts to incorporate a microswitch mount, which was incredibly well designed by the chief designer, we had a nice, new, shiny buggy to show off to the world! I am most likely missing out some information about the case, for which my team are going to complain to me about, but I honestly cannot remember anything else!
Now that we had an assembled buggy, it was time to test the algorithms that the systems engineer had been working so hard on. It turned out that, much like the Mark 1, Mark 2 would curve to the left in an exponential manner, making it very hard to correct its course on the fly. PIC.hacks, our team name, Mazebuster was the most promising algorithm, using the compass to automatically realign itself while on the course. We also coded up other algorithms, like PIC.hacks InCap, which would work in case of a sensor failure, and PIC.hacks WallStalker, which hugs the right hand side wall of the course. The chief designer also coded an algorithm up, called PIC.hacks Theodore, which turned out to be one of the most reliable.
The systems engineer then came up with an interesting idea on how to implement a PD Proportional Derivative control loop to keep the car straight on the course, alongside various other variations, such as PID and PI. I had no idea what these meant, but it seemed promising. Unfortunately, they all displayed the same problem: they would start out well, but then the gain of the values, or something like that, would start to deviate or change or become inaccurate (I have really no idea!) and the car would swerve out of control, putting pressure on the worm drive system, causing the gear to slip.
This testing went on for longer than it should have with the ever impeding promise of a straight travelling car, but the gears had had it, and had been worn down to the extent that they were unusable. It became a race against the clock to remove the chassis, glue some new axels together and replace them as quickly as possible. Buy the time all this was complete, we now had a week to go until the Nationals, and we still had no fully functional algorithm.
Although PD and PI loops were becoming more promising with time, we decided to abandon these and replace it with a more simple solution. Having asked the supervising teacher for a course to practice on, we yet again took matters into our own hands and put our own one together out of recycled pieces of timber and cardboard boxes, which provided a nice mobile test track. All the algorithms were tested thoroughly, but all except three were abandoned due to lack of time to troubleshoot the code or the high possibility of that algorithm being useless on the day, such as those involving the use of a compass.
In the end, only two were deemed reliable enough: PIC.hacks Theodore, which had been coded up by the chief designer in one evening, and PIC.hacks InCap, the simplest of the algorithms the systems engineer had coded.
We were again in school until 8pm on the Friday before the Nationals, trying desperately to get a functional algorithm. After a gruelling day, we were semi-confident that we had at least one algorithm that would successfully navigate a course. We ran through our presentation one last time to ensure we had learned it and all went home to get an early night for a 6am departure from school on the next day, a Saturday.
I could go on to talk about the national finals now, but it is 11pm and I have already written 1200 words, so I am tired. You are going to have to wait until part 4!
