Raspberry Pi CodeClub week 9

This week was our last chance to talk about Astro-Pi ideas and so I handed out these excellent worksheets and invited them to all come up with their final ideas for next week. I also supplied my son with some spares to hand out in the event of the original copies being eaten by dogs or siblings.

We're starting to get into some tricky Python now. A couple of the group are now well on the way to completing the Intruder alarm project. In fact, one boy had assembled all his circuit on the breadboard and finished the coding. He'd fixed a few syntax errors (the usual missing colons) and was confident that everything would work.

He called me over to demonstrate, hit F5 in IDLE and the program started running. It printed out a message to say that the PIR was armed and so we waved in front of the sensor... and nothing happened. No buzzing buzzer.

We looked at the code: I was suspicious because the PIR had seemed to settle too quickly. I couldn't see any problems so we looked at the wiring. Ah. Two pins on the PIR connected the wrong way round (despite my red, bold text on the diagram, warning of the dangers of getting those connections wrong).

We corrected that problems and tried again. Still not working.

I wondered whether the mis-connection had damaged the PIR so I swapped it for a spare. Still no good.

We checked the code again and it looked OK.

I hadn't actually tested these PIRs - they were fresh out of their bags. Maybe I had a dodgy batch?

Conscious that other children were asking for help, I asked him to re-re-check the code while I went to assist them.

By the end of the session it still wasn't working so I took his SD card, Pi and breadboard circuit home to test it myself.

After tea, my son and I set up the Pi and started debugging. First of all we tested the PIR with code that I knew was correct. It worked.  Not a hardware problem then.

Within a couple of minutes looking at the code, we spotted the problem. A couple of code blocks were incorrectly indented, messing up the logic that triggers the alarm when the PIR state changes. Easy to identify with 2 pairs of eyes in the calm environment of my study, obviously harder to spot in the noisy, hectic Computing suite.

Things to do differently next time?

Looking at the worksheet, I can see why the problem occurred and why I didn't spot it. My indentation in the sample printed code wasn't always consistent and it is quite tricky to follow. When I was debugging during the club I wasn't actually checking the logic: I was just comparing what was on the screen with what was on the sheet. And getting it wrong.  

The code for this project is as about as long as I want the children to be typing: one side of A4. But even then, it can be quite difficult to reproduce correctly. So to try to help with this, I've updated the worksheet to include dotted lines that clearly indicate the position and alignment of the various indented blocks. I will also encourage the children to always use the tab key rather than a bunch of whitespace. 

We'll see how this goes when some of the others try this project next week. 

This was the last week for most school clubs but I asked my bunch if they wanted to have a session next week and the unanimous answer was yes!