Piwars: retrospective

05 May 2018

A few weeks back Amy and I competed in PiWars. I’m actually pretty proud we did it, and Amy’s decoration got a lot of compliments and mentions during the day (I basically just said “cut a board, do some stuff around the forest fighters theme” which was the title she’d picked). I had a definite #ProudMentor moment when a dad and his daughter of a similar age to Amy came by to “ask the experts” about them doing the same thing.

What went well

1. She asked to do it again + is super keen to get more into the coding side of things this time.
2. We still talk to each other on a regular basis - given the appauling statistics for diversity in technology this is kind of the main thing I was aiming for. It’s so easy for young girls to get put off early, so I try to give my time to women coming up wherever I can at least to give them someone who they trust and can empathise with later.
3. We entered all the remote challenges and 1 of the autonomous challenges successfully
4. We came second to last (I’m counting this as a win because there was definitely points where I thought it was becoming too much of a challenge to even get to the day), though according to Amy’s dad that’s semi inaccurate having looked at the score sheets? That is also the overall mark so some challenges we probably did better at than others.
5. A lot of people complimented Amy’s design
6. Amy did all the driving (which I kind of nudged her to do, partially because I’m terrible at it) which I think gave her a bit more of a sense of pride when we did well.

Improvements

Start small

The first challenge Amy got excited over was the Somewhere Over the Rainbow challenge where you have to get a robot to recognise colour and go towards coloured balls in a specific order.

My mistake here was thinking her excitement would be enough for me to get her to write and understand most of the code, underestimating that…well…autonomous robots is hard, colour detection is hard, and teaching kids to code is really, really hard.

In the end we attempted it on the “simpler” method of just going toward each ball in turn rather than specifically going “yellow, green blue” or whatever it was. The other trick here was that given we’d got remote control working relatively easily, I thought everything else would just fall into place. Nope nope nope nope. I know Amy’s dad Phil spent several months on it.

In hindsight we should have either:

1. Picked a different autonomous challenge to start on. That knocks out “colour detection is hard”
2. Started with a physical/remote challenge which knocks out colour detection and autonomy, though that brings a mechanical engineering element to it instead.

Check in regularly

Did I mention teaching kids to code is hard? Teaching kids to code over skype is daunting and akin to learning to be remote, it takes relearning how to teach and work.

I should have:

1. Built up to programming from flow diagrams, scratch etc on a weekly basis before assuming I could just bowl straight into Amy understanding everything
2. Written out some of the challenge code into branches/staged release of the right answer rather than just kinda writing then explaining. That I think would have complimented point 1
3. Kept up with weekly meetings + the usual project management stuff.
4. Kept up with monthly in person meetings, if not twice a month.

Don’t take too much on at once

Akin to the way that I am at work, at home I tend to overcommit. During this year I’ve joined 2 bands which means a rehearsal twice a week and gigs every few months, on weekends, which meant more difficult planning for visit days.

I’ve slimmed that down to the one I really enjoy and want to do some proper planning of my free time so I can fit any other ventures in alongside both. Starting earlier and smaller should help with this

Think properly about your development environment + threading issues

During the competition the first entry we did was the obstacle course. Due to running the LEDs on the top from USB power, meaning instead of programmatically switching on and off rapidly to save power they stayed on, we had quite a lot of brownouts. After the first one I hadn’t bothered to set any sort of systemd or cronjob to get it to run immediately after startup. Fixed, did it again, brownout happened again, removed the LEDs, then got a pretty good time.

Additionally on the last couple of days I did some pretty heavy coding trying to get the maze entry working. This failed, but in addition to that, other more heavy going challenges like the straight line speed test were difficult to get back out of due to the control loop being on the same thread as the actioning of challenges. This lead to a lot of laughter and claims our robot had become sentient, but was fairly annoying.

Next time, maybe:

• think a bit about threading
• think about how the code is going to run

It may be the time to also think about switching to a language which is less…finicky with threading. Systems programming languages like Go and Rust I gather handle this better, whereas python is still as scary as other modern higher level programming languages. Again though, this is very dependent on the style of teaching and amount of stuff to get done.

Thanks

Finally a huge thanks to:

1. Mike and Tim for doing a stellar job at organising, and to all volunteers in whatever capacity on the day. You rock.
2. Phil Willis for chipping in with code, giving us their team’s old chassis and generally being the team’s unofficial mentor.
3. Pimoroni for giving us bearables - I’d really like to have done more with them like stuck them up trees or something
4. Everyone else attending piwars for being super nice and friendly the whole day