Michael Syree, Exa Networks Director and team organiser of the ExaBot team at PiWars 2017 takes a look back at the history of PiWars and reviews this year’s competition
I first heard about PiWars during the early discussions about the potential of a contest based around the Raspberry Pi and jumped at the opportunity to sponsor the event in its first year. I thought it was an excellent idea, and as the competition approached in December 2014 I took my son, then 15, to watch the contest. It was a great day out, and we continued to support PiWars in 2015, once again attending as spectators.
For around 3 years, I have been running a coding club at Exa. One of the continuous problems is finding activities for the attendees to do. As such, when, in the summer of 2016, it was announced that there would be another PiWars in April, I put the suggestion of entering the competition to the older attendees. To put it lightly, it would be a lot of work. We had never attempted anything on this scale before. They thought it was an excellent idea. So we submitted our application and waited - and waited.
Finally getting the email, we were in, but the clock was ticking, and the real work was about to start. I reviewed all the information available and it dawned on me what a challenge we were facing. We were meeting once a month for the club, so we had around six club meets to do everything. So 2.5 hours per month over 6 months was 15 hours. It was not a lot of time - it was not enough time.
Starting off, we purchased a couple of robot shells and started to put our first robot together. It was a two wheeled chassis with a rear castor making the third wheel. We also got a small 4 wheel robot, though it was very quickly evident that this chassis was less than ideal, so we decided to focus on developing the two wheel robot.
From the outset it was decided that the programs we used would be our own, nothing lifted from the web, with the team keen on doing the programming themselves. We started off working on the ‘how close to the wall can you get’ challenge, only later realising that the challenge had been dropped for the 2017 PiWars, after quite a few hours of effort programming and testing.
Realising this, we reviewed the other challenges for the year in much more detail. Unfortunately, we came to realise that our two wheeled robot had a problem. The turning circle was far too large, so it would not be able to navigate the corners of the PiWars challenges. We would have to start again.
By now it was January, and time was quickly vanishing. Coincidentally, Martin, one of the teachers from the coding club, had seen his school’s team drop out, and let us use his robot shell rather than wait for a delivery. This shell was a four-wheeled design, with four motors - everything else was for us to sort out.
Taking a look at all the challenges and the robot itself, there were three key steps we needed to move forward on before contemplating the complex challenges.
Firstly, getting the robot working. We’d previously been working for the two-wheeled chassis, and needed to redesign our software for four-wheel drive, having picked up a second L298N two-channel controller.
Secondly, we needed some form of remote control. We hadn’t given much thought to how we’d control the robot, but following a recommendation from Harry (designer of 2015 PiWars winner KEITH the Robot), we chose a PSP4 Bluetooth controller. With remote control and a working robot, we’d be able to take on anything but the autonomous challenges.
Finally, we’d have to add line sensors and ultrasonic sensors to allow us to control the robot for the autonomous challenges. For the line-following challenge, we ended up picking three TCRT5000 IR Line Following Sensors for £4, mounted to cover the left of the line, right of the line and the line itself. We found quite a bargain by getting 5 HC-SR04 ultrasonic sensors for £6.95.
After a final purchase - a LM2596 voltage regulator, allowing us to check the quality of our batteries at any time, I decided to let the team get on with the design with a few weeks to go.
On my return, I found little progress, with three motors not under the control of the Raspberry Pi. As is so often the case, the problem ended up being a simple, three-minute solution - the difficulty lying in knowing what to do, not in how to actually go about doing it.
With the motors running under software control, the next step was getting the remote control working. Using a PiGame library, this was quickly done. We were able to map the buttons of our controller to various functionalities in the robot. Unfortunately, as time went by, we kept getting crashes, all of which pointed to the PiGame library, so we switched to an alternative solution, restoring full control and, importantly, reliability.
We wanted granular control of the robot, so using PWM we configured the robot so we could specify the power on the wheels. To keep it simple, we went for left power and right power so we still had four wheel drive, but with the power distributed between sides. The remote control was programmed up to map the variable feedback from the joystick back to variable power to the robot. This needed mapping between two thresholds which would then determine our slowest and fastest speeds.
With just a handful of weekends left, getting the group together was proving hard, and while some elements could be worked on independently, we only had one robot. The initial phase was complete. The robot was running, but none of the autonomous programming had been started - all we had done was confirm that the sensors were working.
We decided to go with a 3 channel IR sensor, which had managed to get the robot following a line, though it wasn’t very successful. With the individual sensors needing to be mounted, we wanted to focus on locating as many of the fragile electronics as possible in the centre of the robot, and initially moved to mount the sensors in the middle of the robot to give us finer control over the robot’s progression. This ultimately failed, with the robot unable to move around the track - we relocated them in line with the front axel. While the placement wasn’t perfect, time was running out, and the sensors were there to stay.
With just two days to go before the competition on the 1st April, the ultrasonics were added to the robot. We had had a forward facing sensor mounted and tested, but the side sensors were still to be added. It was a struggle to mount them on the sides of the robot, and they were therefore mounted at an angle on the front. While they were working fine, with hindsight, we would have moved them to be more perpendicular to the robot.
On completion, the robot had many wires going to the power and GPIO pins, only two of which had to be swapped during the event. These were the power for the ultrasonics and line sensors respectively, keeping maintenance to a minimum to avoid any potential damage. Finally, we used terminal strip to mount a bent coat hanger for the golf and skittles events.
How do you test maze-solving software? You have to build a maze. We put together a basic maze with some offcuts of wood, then working on the software to solve the maze. It hit 9PM on Thursday the 30th, and the robot was not moving around the maze successfully. With us due to travel down to Cambridge on Friday evening, it was not looking good at all. Across the next few hours, we made progress, but kept running into a problem - our distance sensors threw out different reading after reading.
After investigating, we discovered that the sensors were actually reading the reflective distance from the sensors. With the angle of the sensors and the wood, we were getting measurements that, in effect, went round corners rather than looking at the correct wall. Set to travel in less than 24 hours, there was no time to completely fix the problem, and we made do with building a couple of rules for the side sensors to be ignored, finally getting round the maze by 11:30 and packing up, hopeful that we had done enough to get round the maze on Saturday.
We set up on some desks in room B, and started to prepare for our first challenge. During the day, one of our competitors (I am sorry, but I’m not sure who you were - but thank you, it was very innovative) had a cardboard maze, and let us run a few more tests before we ran the actual maze.
We spent the day rushing up and down through the various challenges - checking floor surfaces, determining which wheels to use and getting ready for the events.
The Challenges (in order)
With our bent coat hanger to manage the golf ball, this was a good start to the competition for us. The ball was swiftly moved into the hole on each attempt. The astro turf was a slight issue, but our wheels managed it quite well. We did see others struggling to navigate the turf.
We didn’t have time to code any logic into the speed test, so we configured the robot with a little bit more power to increase the speed and pointed the robot in the right direction. The press of a button launched the robot. The 1st run couldn’t have been better, straight down the middle of the course. On runs two and three, however, we had an unfortunate touch and got the positioning slightly wrong, slowing down our time a bit.
With a bye in the first round, we moved straight to Round 2. While fitting the balloons to prepare for the round, we discovered that the rod holding the balloons had to be 1cm from the floor - we had overlooked this, making it a problem. We had a mount, but the robot’s chassis was in the way. A quick dash to the work desk with a pair of wire cutters, and one minute later, the front had been hacked away, the plastic had been split, and glue had been applied for reinforcement. But the wire would work.
We returned to the challenge for a battle against our very close neighbours from Bradford Grammar School. Tragically, our robot stopped working. There was a problem which hadn’t showed up previously, but which left us a sitting duck. After a while, normal service was resumed, but the damage had been done. The robot stopped another three times during the challenge, giving the other team enough time to pop our balloons and send us out.
Looking back, we believe this was due to our battery choice. Throughout all testing, we never had a problem, but we were using Eneloop rechargeable batteries. For the contest, we switched to standard cell Duracells. We believe the current draw couldn’t be sustained when switching directions quickly with the standard cells, where the rechargeables would have been fine. A disappointing end to this challenge.
Taking a look at the obstacle course, we expected to fail. We had near zero ground clearance, and our tyres were not brilliant. Wilf drove the robot around the course, missing all the cones and unseating only one marble which returned to its hole, an excellent start. The turntable worked well, even giving us a complementary kick out pointing us straight down the exit ramp. Perfect. When we hit the bumps, we never stood a chance, so the robot needed to be repositioned. Driving around the shark was a breeze with our variable speed control, however the rock paper scissors once again suffered from a ground clearance problem. We came first overall, which really surprised us. We did not expect to do well here at all.
This was always going to be tricky, we had a very simple coat hanger. Our test run was our best, getting 4 pins down. The proper runs however we got none. The ball just ran away with itself. Note to self for next time, this task needs more captive ball control.
The robot was positioned, and the robot was set off. It worked, while getting stuck at one corner (we still don’t know why). Each run was in a respectable time too. Amazing given the last minute programming of the challenge.
Half way though the day, we found out that most teams had a ‘did not finish’ on this challenge. By the time our time slot was due, only two teams had made it on the leader board. We were the last robot on, all we had to do was get a single lap and we would be in third place at minimum.
The decision was made to go safe, the software was configured to go reasonably slow. Which turned out to be really, really slow. It took ages, but with 3 of our 5 permitted repositions we managed to get a lap in at just over three and half minutes. We ran out of time for the second lap. The next day we tried the course again with the speed cranked up a little. The robot came off. We had made the right decision.
We were finished, PiNoon was still finishing off, we started to pack up and then wait for the results. Due to the method of scoring and bonus/penalty points it was impossible to know how we had performed. We had not really seen any other competitors throughout the day so did not know how successful they had been.
What we did know, we had finished third in the line follower and that we had quite a quick time on the speed test - penalties unknown.
As the final placings were announced we were really surprised to be in the top 10, and then the top 5, the top 3, the top 2. When second place was read out, it was not Exabot! Had they forgotten us? We had won, we could not believe it.
It was an amazing end to a brilliant day.
The guys had soldered, modified, cable tied, glued and programmed the majority of what had been used. My input had been more giving advice throughout the whole process. The guys all hope to go to university in September. What a fantastic and satisfying end to their schooling.
The ExaBot team - Wilf Askins, Arran Curtis-King, and Laurence Syree (along with team organiser Michael Syree and judge Dr. Lucy Rogers).