Pi Wars 2024 Aftermath

Having now spent a few weeks recovering from the panic, chaos, and overall stress of the month or so before the Pi Wars 2024 “disaster zone” competition, I think this is a good point to go over how we did at the competition and talk a bit about what worked well and what didn’t.

This is hopefully the start of an on-going blog about the building of our next robot (which with some luck will compete in a future Pi Wars event). I’m certainly no professional writer, I went into engineering for a reason, so please bear with. With that said, lets begin:

A little history

For context, we’d been to Pi Wars twice before this time - the first year it was run in 2014 and again in 2015. We also applied in 2016, but were selected as a reserve team and dropped out once we fell behind with development (after making a wildly impractical robot which we decided to just have fun with instead - perhaps more on that another time…).

In 2014, we largely had a robot completely made before finding out about the competition, so spent our time mostly working on the code. Granted, “all of our time” at that point was probably a few days at the weekends running up to the competition, so everything was all very basic. Back then we were mostly stumbling our way through everything and in hindsight made some pretty terrible design choices, but I suppose that’s how you learn and develop, so I’m glad we did it regardless. From memory, the 2014 robot consisted of a model B+ raspberry pi which controlled two 12V DC motors using a L298N driver board over the GPIO. We had a bluetooth dongle that connected to a wiimote for control, and I think the only sensor was an ultrasonic distance module we fitted to the front. The driving wasn’t good - we had no analogue control using the wiimote d-pad, and the DC motors weren’t matched so we would gradually drift when trying to drive forwards. All the code was running on the pi (in a single python file), which compounded the motor drive problems.

All that said, it was actually an alright robot for what it was. Our biggest issue was an SD card corruption mid-event which was the only source of the code we had with us at the time. Using the WiFi at the venue to try and access our email to download the code (with mouse, keyboard, and monitor plugged into the pi) was, putting it mildly, not ideal. It lacked speed and control but we felt we did alright on the few challenges we were able to compete in.

A year rolled around, and what did we change for 2015? Not much. We’d made a new robot that was larger (roughly A3 rather than A4), tried stepper motors but couldn’t get them working in time so reverted to DC motors again, and it was effectively the same architecture. Wiimote, pi-2B, DC motors and driver, LiPo battery for motors, power bank for pi. We did pretty badly in 2015 if I remember correctly, we just left everything way too late and didn’t spend enough time on it. I don’t think the quality was worse than our 2014 robot necessarily, but between those two competitions everyone improved a lot and we didn’t which made it look far worse in comparison. We did at least come away with some key learnings:

⦁ Good motor control (with feedback of some sort) is key
⦁ I shouldn’t do the mechanical design
⦁ We like tank tracks but they’re just too slow and lack control

2023 plans

So, let’s fast forward to around September 2023 when we saw that Pi Wars 2024 had been announced. We’d both since been to sixth form and then university, done a number of robotics projects in our own time, built our own racing quadcopters and were now employed as professional engineers. This left us feeling pretty good about what we could manage this time around. Perhaps too good.

So we set out to add our own challenges, along with those set by the competition. The biggest of which was to do everything custom. The mechanical design was always going to be at least a little bit custom, but for the electronics in particular I set out to design from scratch all the PCBs we’d use (except for the main raspberry pi of course). This was a great learning experience, but a lot of work and it meant that software development, integration testing, and all those other important tasks that rely on having hardware to test on were pushed really far back.
A few of the other challenges we set ourselves, as well as plently of other smaller things, were to:

• Consider design-for-service so that most parts could be replaced easily without having to disassemble most of the rest of the robot
• Field Oriented Control (FOC) of brushless DC motors
• Fully autonomous in all challenges where we could

Some of these we managed, but it was very much at the cost of others (looking at the autonomous features in particular).
I’d like to go over some of the 2023/2024 development process, why we made some of the design decisions we did, some of the issues we had, how we fixed (or bodged) them, etc. etc., but that’s for another time. So, how did it actually go?

2024

We did a lot better than we thought we would at 3am the night before the competition. Somewhere, perhaps around 2 months before the competition, our goal changed from “do well and try to win” to “don’t completely embarrass ourselves”. I think we can now say that we at least achieved our secondary goal, but comfortably missed our first goal, coming in at 7/12 in the advanced teams.

We did pretty well at Pi-Noon, getting knocked out in the quarter finals (although having later reviewed some of the videos we think we should have got to the semis). Regardless, solid motor control did us incredibly well here, despite not having the best speed or mobility, we were able to accurately go where we wanted.

We did really well at Minesweeper and Eco-Disaster (for doing them remote controlled), again the same solid control as before was key to our performance in these. Unfortunately we just didn’t have time to get the LiDAR navigation working properly with some level of permanence (e.g., it could tell us we were in a corner  but not which corner), which was our entire strategy for these challenges.

Lava Palava line detection using a camera and openCV worked really well for us - much better than our previous attempts with IR LEDs. We could have done with more testing but oh well. On our first two runs we needed a single rescue, but after a quick re-calibration we had a clean run. Not the fastest, certainly not the slowest.

Escape route was a bit of a disappointment, our LiDAR was positioned so that it could just barely see the blocks, which were then lowered at short notice a few days before the competition. Nothing we could do about it, so we had to drive using the camera instead but only got about 0.3 frames per second.
Obstacle course was pretty good, although we do often tend to design with it in mind a little too much at the expense of the other challenges. The only bit we had any issue with was the treadmill which we just didn’t have the speed for.
Zombie apocalypse went badly, but we always knew it would be bad after we abandoned making a ball shooter.

So what have we learnt?

Having good control is absolutely critical
This includes motor control, but also on the user input side as well. We had analogue inputs from a dualshock 4 (PS4) controller, with code robust to disconnections. Field oriented control of the motors wasn’t necessary (but was very nice to have), we could have probably done the same thing with DC motors with a lot less effort, but having the motor encoders that it used was so important.

Embedded development is slow, high-level software is quick

Even more so when it’s from scratch. It took us something like 5 months to go from concept design to actually driving it around, in a week we were able to do all of the high level code (after completely restarting it). Full custom design isn’t the way to win, but it’s what we enjoy so we’re not going to give it up. Throwing something together in python and testing it (as long as you have a platform to test on which we now do) should be done as early as possible so that everything has been de-risked by the time you get to system integration. This should be easier this time, but we might consider looking at hardware simulation as well?

Drivetrain choice is important

Belts worked reasonably well for us, but we had a number of issues with the tensioning. It's probably a better trade-off to accept a little more backlash from gears next time to avoid this, but perhaps I'll be cursing backlash this time next year. Making sure that motors, wheels, and anything else don't slip on shafts is important, I'm pretty sure we've ended up adding superglue to our wheels at least twice now, it would be nice to not have to do that again. We need a higher top speed to be more competitive though, 1 or 2 m/s is probably a nice target to aim for. We ended up having plenty of torque in the end, so a better gear ratio could probably have done us some good. We have a better idea for our target specifications now.

We should properly implement protection/safety systems next time

I should preface this by saying that we didn't have any safety issues, and we are both used to using "unprotected" LiPo batteries from flying quadcopters. Our batteries were even over-speced enough that we only used 3 out of 4 and those we did all ended at storage voltage so we never got close to damaging them. However, it would give me some extra piece of mind to have some overcurrent, undervoltage, & overvoltage protection features built into the battery. Some better motor protection features would be welcome too - we burnt out a motor the day before the competition after I mistyped and command 10 times the desired pwm pulse length to the motor.

Hardware & software needs to be robust

As far as everyone else we saw on the day I think we had a pretty robust robot, the main issues we had were at boot, and once solved it would run pretty reliably. There were certainly a bunch of hardware and software bugs which were patched over. Improving the hardware to make it less succeptible to faults is a big priority, as well as making sure that the embedded software can cleanly reset, or ignore unimportant error, to allow for smooth operation is also important. The python software worked pretty well in this regard, and we even had a separate thread that would monitor the controller input thread, kill it and restart if it detected an issue.

Time to do it all again

So with these lessons in mind, along with plenty of other design goals and smaller learnings we have in mind, it's time to start on the next robot. It's already shaping up to be an almost from the ground up re-design... we just can't help ourselves.