On the Pedagogy of PiWars

tl;dr I need to get better organised next year to turn PiWars prep into a good learning experience; also it would be good if PiWars rewarded technical effort a little more.

Westpark Club is back from this year’s PiWars competition in Cambridge. It was excellent fun, the weather was great, the atmosphere was friendly and helpful, our team did well in some things and poorly in others. We were finalists in the entertaining Pi Noon competition and we came 4th overall.

Build or Buy?

Riding the wave of enthusiasm after the event, I’ve started thinking about running a workshop during the year and preparing for next year’s event (assuming that Tim & Mike can find it in them to run one). But there’s a tension here which I’m struggling to resolve: the split between preparing in order to win; and preparing in order to learn. Our Club is part of a charity group with educational aims so we’re always trying to find that balance between making something enjoyable and attractive and making sure it has educational or formative value. Obviously teachers and after-school clubs will be in a similar position.

At one end of the spectrum you can design your entire robot from scratch, 3D-printing every part, buying only the components that you can’t make yourself. And you can plan the whole of the circuitry, print your customised PCB, and wire and solder it all by hand, writing the entire software stack. At the other end, you can buy a robot with everything already working, maybe even with software provided by the vendor to do useful things like remote-control driving and image-detection. And all you have to do is to fit it to the specific challenges.

Most teams on the schools / clubs day probably sat towards the right-hand end of that spectrum: buying, rather than building. We ourselves used the excellent ThunderBorg and UltraBorg controllers from PiBorg which give you motor control and handle sensors and servos. This means that you just plug in one of the ultrasonic sensors and call a function and you’ve got a distance. Great for getting things going. But it also means that you’ve not had the experience of wiring in the 4 pins of the sensor, working out the resistors for the voltage splitter, and working through the speed-of-sound-divide-by-2 maths to understand the physics of the sensor.

But this is the educator’s dilemma. With only a limited number of sessions in which to complete a project — whether that’s after-school clubs, curriculum lessons, or Saturday evening workshops — you’ve got to be pragmatic. We tried to achieve a balance by having each family group build its own CamJam Edukit robot to become familiar with the low-level elements before coming together in later weeks to collaborate on the team robot. (Although we did use gpiozero to avoid some of the fiddly work around the sensors).

Coming 4th without meaning to

In a perverse kind of way, I’m unhappy that we came 4th overall because we hadn’t put anything like as much technical effort into our solution as other teams clearly had and I’d guess that our points came from good tactical driving (Obstacles, Golf, Pi Noon), rapidly-improvised mechanical solutions (Golf, Ducks), and a good deal of luck (Pi Noon) which took us through to the finals. And I feel bad for teams who’d worked harder beforehand but whose solutions had failed at the last minute, or who were just unlucky.

So what am I proposing? I suppose it falls into two parts: what PiWars might do differently to better reward the design and build effort; and what we might do as a club to make better use of PiWars as an opportunity for learning.

More emphasis on technical solutions?

I know that the Technical Assessment did count towards our final points. But I wonder whether there’s an opportunity at each of the Challenges for more points to be awarded for a more technically-developed solution. This was the case for the Duck Shoot: that teams who had engineered some kind of Nerf Dart solution scored higher than those who pushed balls. But this would have been offset by the fact that the darts can hit at most one target, whereas the balls can bounce around and flatten several (a loophole which our driver happily exploited). And in the golf challenge, I think the team which came 2nd overall had improvised as we had a basic fork with no capture mechanism — no servos or relays to go wrong.

You can perfectly well argue that, as long as you’re within the rules of the competition, any solution is good. And I agree. We and other teams improvised on the day to produce simpler solutions where more sophisticated ones had failed or not been possible for us in the time. The alternative would have meant simply skipping those challenges and getting less out of the day overall. But I would have been happy for us to have stepped up to those challenges as best we could and still finished up mid-table.

More time spent up-front learning

From our point of view as an educationally-oriented Club, we might go over what other teams’ solutions looked like. Or we might go over the different Challenges now we’ve seen them to brainstorm solutions. Overall we want to generate enthusiasm among the youngsters in developing more sophisticated solutions for the sheer interest and enjoyment, and not just to come higher in the tables next year. (Which, frankly, will be difficult!).

I don’t know if it’ll come off, but I hope to be able to run workshops through the year to develop more slowly the different elements we might use (motors, sensors, servos, relays, lights etc.) so that, when it comes to another PiWars, the youngsters themselves will be able to look at each Challenge and think: I know how we might do that.

Producers, not Consumers

I have a bit of a motto when it comes to talking about youngsters and technology. I want them to be Producers — and not just Consumers — of the technology they use. I love PiWars; I love the atmosphere; I love the technical challenges it offers. What I want is for that to be an opportunity for our Club members to becomes real Producers while having a great time.

P.S. I’m not really talking about Pedagogy, rather about Learning, but the alliterative opportunity was too good to pass up.

8 Replies to “On the Pedagogy of PiWars”

  1. Excellent musings. As a competitor in the intermediate section on Sunday, we weren’t concerned with winning, just not coming last (and it wouldn’t have been the end of the world if we did). Our emphasis was very much on learning, and doing the best we could within the constraints we set ourselves (a Lego-technics-based chassis, including Lego motors). The joy for us was the learning, not the thought of winning (though it was fun coming 5th).

  2. A really good summary, Tim. We want Pi Wars to be as educational as it is fun. That’s why we have a schools’ day as well as Beginners/Inters/Advanced. We wanted more school teams, which is why we moved it into April. Anything you (or other educators) can do to help us to change things so that Producers rather than Consumers get more points would be very welcome.

    One thing we’ll probably change for next year, for example, is on the Somewhere Over the Rainbow challenge. This year, using OpenCV did not give extra points over use of the easy-to-use Pixy camera. I think this was a mistake – OpenCV is difficult even just to install on the Pi, let alone use it for colour recognition. We did at least reward for “own firing mechanism” on the Duck Shoot. However, we should’ve restricted it so that only the first target hit counted to avoid the bounce-around issue.

    Technical Merit, by the way, counted for more than just the score that was written down – there was a multiplier applied so that those teams who put more effort in technically were rewarded.

    Anything you can recommend, in terms of tweaks and ideas, are appreciated. You know where to find me 🙂

  3. Hi Tim,
    Thoughtful piece. Congratulations of the 4th spot.

    As a first time participant, I had a fabulous experience at PiWars. We went in the Beginners category on Sunday. For us, we were building a competitive robot for the first time. There were lots of first:
    1. First big 3D printed project (first robot CAD as well)
    2. First time writing code for moving things
    3. First time trying to figure make sense of multiple sensor data.
    4. First time using Lithium batteries in a big project etc. etc.

    To add to that we joined the party late (backup team made it to final list in Jan).
    We used similar tech stack to yours, Thunderborg + UltraBorg and we used Pixy cam instead of OpenCV. People say Pixy make things easy for you, well it makes installation of a certain library easy, you still have to figure out the algorithm to use the data it was reporting. Lesser challenge but challenge all the same. On the flip side you can’t use Aruco markers that may have been an advantage at some places.

    What I am trying to say is there was learning at every step and while other may complain I took the easy way out, I know I learned a boat load.

    Now, if I make it to next year, I am better equipped, to take the challenges further, push myself to learn other different things (yes Open CV is right there on the top of the list).

    Also different people with different interests learn different things, I want to learn Stereo Vision and Machine Learning but I am perfectly fine if someone designs a perfectly good voltage regulator + motor controller that I can use with eyes closed. Others want to actually use H-bridge chips and build their own motor controller, more power to them.

    As long as the team is learning new bits all the way, its a win and coming 4th because of those bits coming together on the day is a big deal so good job to you and the team (we came 10th even though we probably had one of the costliest Robot in town).


  4. Hi Tim,

    Really do echo your thoughts on this, there is definitely a balance to be struck. Our robot (with the 2nd placed golf fork!) was very much leaning towards the bought in solution (again, thanks piborg). To prepare anything that worked in the time constraints of an after school club was a massive challenge. Even the most minor technical hitch could set us back weeks and it was often muggins here doing the bulk of the trouble shooting.

    However, in spite of this the students still learnt a huge amount, particularly when they were forced to take ownership of the project towards the end (I let them take the robot home over Easter). Now that we have a basis around which to work, without the pressure of just wanting to produce something that works on the day, my hope is that they will start to be more creative and focus on being effective in some of the more difficult autonomous challenges. I want to give them a strict budget but otherwise complete freedom, freedom to screw it up completely if necessary!

    Would it have been nice for them to have pieced together each element from first principles? Perhaps yes, but practically the time implications are nightmarish to contemplate, not to mention the technical difficulties it presents for the club/school leader. I think your model of workshops on individual aspects is a much more sensible approach.

    I think there is also a danger in rewarding overcomplexity too much as, with my physics/engineering hat on, simplest is so often best, and having the students try to think this way is a powerful learning point (Russians taking a pencil to the moon etc etc). I will also defend our superb golf ball fork to the hilt!

    I think Mike and Tim did a fantastic job and the challenges were really
    well pitched but agree it’s so difficult to have a level playing field when you can just import ready made solutions. I think as facilitators we would all rather kids took the time to work these out for themselves rather than just being happy that someone else has done the hard work/code. It’s good to see Michael clarify the technical merit score multiplier because I think realistically this is the best way to combat it. I certainly prefer this to making the challenges inaccessible to beginners, who I think get a huge amount from the experience however their robot was made.


  5. Thanks to all who have commented so far. People seem broadly in agreement with my point: that it’s good for PiWars to be a motivation for learning, but it’s not always obvious where to draw the line on DIY vs DFY. A few responses below to specific points:

    @Michael Horne: thanks to you & Tim obviously for PiWars itself but also for its intended educational value. I know from long experience of running Club activities that, no matter how hard you think through your points scheme, someone will spot a loophole. I suppose what I had in mind was basically more points for a more technical solution — although I agree with Tim Benson’s caveat that simplicity is a virtue. (In case you didn’t see it, our Duck Shoot approach was to attach an empty Coke can to the front of our robot as a shunt!).

    @Sumit: I appreciated your point about focusing on the things you want [your team] to learn. When thinking this post over, I knew that I wouldn’t really think of proposing to build our own H-Bridge — although a sufficiently motivated person might want to. Likewise, I would use OpenCV but I wouldn’t try to *write* it! So you’re always standing on the shoulders of someone, no matter how hard you work.

    @Tim Benson: Nice points. One area I’m trying to work out is: what would a suitable budget look like? Mike mentioned the Pixy camera, which I hadn’t heard of so I searched around for it. It looks like it’s upwards of £70 — which is more than I’d like to spend on a single fairly specialised piece of kit. I think you mentioned making use of the school laser-cutter facilities and several teams had access to school CAD systems & 3D printers, both of which are still fairly pricey items. But at the same time, these are all useful things to have and to learn about, especially since they’re already at your disposal. So it cuts both ways.

    I do take your point about keeping things simple — and it once again comes down to that tension between: using any approach which works to “solve the problem” (in this case: score according to the points system for a particular Challenge); and producing a more sophisticated solution for the benefit of learning about it.

    Thanks again to those who have commented and I hope other people have at least been given food for thought even if they haven’t felt the need to comment back.

  6. Hi Tim,

    I’ve only now got time to read your post – cool down time from last weekend is still in full swing with only half unpacked stuff and not charged batteries. Anyway, I think you managed to touch the nerve with mentioning balance between competing and teaching – and that’s what I had personally struggled with. I was constantly torn between scaling it down and making it completely accessible to students at our club and doing it at the level that will bring us some results. Often I had to let students start designs guiding them until we hit some major obstacle (and by obstacle I include prolonged breaks like Christmas and Easter or installing OpenCV) and then completing it myself. Then as a afterthought, clean up half I did and re-do it again with the students. That way things lasted twice as much as they could have and still feel that I failed on both fronts: teaching and completing build. Only consolation I have now is that things that I pushed beyond what students themselves did I can always return to in the (hopefully near by) future – like I am now doing – preparing sessions with OpenCV for coloured ball recognition. I would probably not even considered it if it wasn’t for the PiWars and community help on the discord chat and blogging.

    On the other hand I am really glad that at least I managed to pass some ownership to the students through last two years – all the control of non autonomous challenges code was done and owned by them and broken in last moment before the competition just to be hacked back to usable on the day.

    I still think that competition is quite well balanced as on both days I saw both adults and kids engaged at various levels without being in each other’s way: adults did give controls to younger kids or, as I mention, ownership of various aspect of design and coding, while steering them and picking up ‘hard’ parts.

    Beside that, I am quite happy to see both ends of spectrum regarding complexity and cost: I am yet to do in depth analysis I mentioned to a few people, but it seems that there’s not a simple and straightforward answer. It seems that both won and lost some – that people are not penalised for not engineering a lot and when they over-engineer for sheer fun of it.

    Also, I think that balance (of the PiWars challenges) actually has reflected through the scoring and teams that put more effort did score more. Even we did ‘fail’ quite a few challenges due to (technical?) issues but we attempted all challenges this time and hard work did reflect in place we’ve got. I believe similarly in your case as well.

    So, from that perspective, I don’t think a lot needs to be changed. I am OK with fine tuning, but what I have seen in last two years lead me to believe it (the competition) is pretty spot on for the people who apply for it. I am really glad to see this many schools and clubs this year. Only issue I had was with perception that one day is quite tight for all I wanted to achieve – have fun, attempted all challenges, mingle and talk to all the competitors and have some spare time. But that’s the thing I can easily live with and fix it by attending both days.

    Congratulations on your success and hopefully see you there next year again! 🙂

  7. We have one single Saturday group – the schools. You are all competing against each other. It’s hard to split that in a way that seems fair, but you have given an idea – perhaps split between pre-built chassis robots and school built ones? It’s a nice idea.

Comments are closed.