Thursday, 22 May 2014

CodeClub for years 3-4 Week Two

So after the success of week One I was fairly confident that this next session would go well.  It did, but there were a few obstacles to overcome first.

Problem one: the projector for the smart board was out of action. I had planned to show few things on the screen. Luckily I discovered this during my regular lunchtime CodeClub so I was able to plan around this in between clubs.

Problem two: I'd planned to get everyone started on LightBot this week. Unfortunately when I setting up the machines in the few minutes before the club started the site was down! Once again, good planning got me out of trouble as I quickly switched to the Angry Birds/ blockly tutorial instead. Phew.

It was interesting to see the difference in ability across the attendees. A couple of them had already down the exercises as part of the hour of code so they whizzed through it. Another two (who claimed not to have done it before) were just as quick.  Age did not seem to be a factor here as the high-flyers were split across YR3 and YR4.

Everyone worked hard and noisily for about 40 minutes then I called a halt and introduced the 'unplugged' session.  Following on from last week's jam sandwich extravaganza I wanted to focus on something that robots and computers are good at - sorting numbers. Borrowing from the Sorting Networks activity I took everyone outside to the playground armed with small whiteboards and markers to where my young apprentice helpers had been marking out the sorting matrix with sports cones and chalk. I explained the steps involved, stressing that really there is just one 'operation' - the comparison of two numbers - that is performed several times to build the algorithm (I was ignoring the multi-threaded aspect for this discussion.


First we worked through it in groups 2 groups of six, with each clubber picking their own number between 1 and 1000. Of course the smarty pants maths geeks all tried to pick 999.99999999...

Then I asked them to run it so that the numbers were sorted in descending order and they quickly worked out how to modify their program.

By the time we'd done this we were all very hot (it was the hottest day of 2014 so far!) so we went back inside to carry on with Angry Birds/Zombies. By that time, LightBot had got its act together so I was able to direct those who'd finished the previous exercises to start on that.

So it was a shame that I couldn't really show my Scratch sorter - this would have been a nice introduction to those who've never seen Scratch before. Hopefully it'll be fixed after half term.



Lessons Learned from this weeks session: always have a backup plan for everything you're planning to do!

Tuesday, 20 May 2014

1st attempt at Cress Heads

I want to get my CodeClub to setup some timelapse photography using their Raspberry Pis and the PiCameras. Fortunately there is a great resource for with instructions and ideas for doing just that using quick-growing cress as the subject matter.

Lighting can be crucial to getting decent results when doing timelapse photography. While changes in brightness can be dramatic for landscape scenes, they can spoil the illusion for close-up objects. So I wanted to experiment with a few ideas.

Because this is for CodeClub, I also thought I'd emix the original instructions  thought I'd use the excellent picamera Python module to control the camera. This also has the advantage of making it easier to integrate other peripheral devices into the system... like a PiLite (to provide illumination) for example.

Obviously you need somewhere where the whole operation won't be disturbed. I plumped for the windowsill in my office. It gets plenty of light in the day, and hopefully the PiLite would provide enough balance illumination during the night (obviously you don't have to use a PiLite, just a bunch of leds in a breadboard would do).

Here's my setup. There's nothing significant about the Camus book - it just happened to be the right thickness to keep the Pi level on its side!


I only need to activate the PiLite while a picture is being taken, and this is pretty easy to program.

#!/usr/bin/env python 
import serial, time, sys
import picamera 
from datetime import datetime, timedelta 
s = serial.Serial()
s.baudrate = 9600
s.timeout = 0
s.port = "/dev/ttyAMA0" 
try:
    s.open()
except serial.SerialException, e:
    sys.stderr.write("could not open port %r: %s\n" % (s.port, e))
    sys.exit(1)
with picamera.PiCamera() as camera:
    camera.start_preview()
    time.sleep(2)
    s.write("$$$ALL,ON\r")
    for filename in camera.capture_continuous('img{timestamp:%Y-%m-%d-%H-%M}.jpg'):
        time.sleep(10) #
s.write("$$$ALL,OFF\r")
        print('Captured %s' % filename)
        time.sleep(3600) #
s.write("$$$ALL,ON\r"
)
(I'll need to make this a bit simpler/clearer for the CodeClub posse but it's good enough for government work here).

Here's the end result after 7 days:


As you can see, the difference in light from day to night time remains quite noticeable despite the PiLite's bright leds.  I wanted to make sure the cress got plenty of light during the day, but perhaps it didn't need such direct sunlight.  Next time I think I'll make a 'studio' that surrounds the cress more completely from the sides.

Or you can have some motorised blinds that were also controlled by the Pi and closed just before the images was taken. Hmm that might be a little complicated for this project.

I also need to make the walls of the studio less shiny to reduce reflections of the PiLite at night (ok, perhaps Lego wasn't the nest choice but is was very quick and convenient).

You can also see that the gooseneck mount does seem to flex slightly during the day (possibly due to thermal expansion). Perhaps a more rigid mount will be better (more Lego!).

Finally, the cress grows really high! I'll need to have the camera framed higher next time. 

Tuesday, 13 May 2014

JamSandwich API

Here's an example of a JamSandwich API.  The idea is that the clubbers pick one robot part (e.g. right hand) and then select an action (e.g. pick up) and an object (e.g. knife).


Monday, 12 May 2014

CodeClub for years 3-4 Week One



After lots of requests from parents, I've just started running a CodeClub for younger pupils (years 3 and 4). Although I could probably jump straight in with Scratch term one, I decided to try to offer some more introductory sessions first, as its the final term of the school year and the year 4s will be year 5s in September and therefore 'eligible' for the normal CodeClub. I also wanted to try some more activities away from the computers.

Here's a session plan, amended in light of what actually happened at the first club.

CodeClub for years 3-5. Week One

Time 1 hour

Preparation:

  • Get enough machines logged in, with Google Chrome fired up and the CodeClub RoboBoogie main page loaded.
  • Find a suitable table for the sandwich making
  • A JamSandwichRobot API  (a list of possible instructions) for displaying on the smartboard (but turn off the projector initially).
  • (optional) Have a voice changer toy available
  • If you can get some helpers - brilliant. I was lucky (I think) to have my sons as helpers, but if you're also running a year 5-6 CodeClub, you could ask some of those attendees if they'd be interested in acting as mentors. 

Clubbers arrival

  • Welcome each CodeClubber and direct them to one of the machines with RoboBoogie running. Encourage them to start playing around.
  • Once they've sat down, try to have a quick chat with each clubber, asking how much coding they've done already. Make some notes! Reassure any clubbers who have not done any programming before that they're in the right place!

First half- RoboBoogie (approx 25 mins)

  • Let all the clubbers mess around with RoboBoogie for 15 minutes or so. Accept that it will be NOISY but try to get them to set the volume to a reasonable level.
  • Keep an eye out for clubbers who investigate the 'code mode'. If needed, encourage them to change some of the values and see what happens. For clubbers who seem to get the hang of it quickly (perhaps they've done it before), challenge them to make their robot do something silly (e.g. 'can you make its head spin a loop round its body?')
  • Normally other clubbers will see what their neighbours are doing and copy them. Give any focussed/oblivious clubbers a nudge.
  • Let them experiment for a bit longer. Give lots of praise and highlight particularly funky robots. Suggest that any high-achievers help other clubbers.
  • Inevitably some errors will occur (missing semi-colons being the most likely/prevalent). Great! Point out where RoboBoogie reports the errors and try to get them to resolve the bug themselves.
End first half (approx 5 minutes)

  • Ask everyone to mute their computers (good luck!)
  • Request that everyone listen. Ask the clubbers what coding is all about and try to get a quick discussion going. Talk about the RoboBoogie experience. Tell them that what they've just been doing is hacking code. Talk about bugs and stress that finding and fixing bugs can be the most fun part of programming. Point out that the RoboBoogie robots were very fussy about their instructions.

Second half – JamSandwichRobot (approx 25 mins)

  • Tell the clubbers they're now going to get to program a Jam Sandwich making robot. The idea is pretty simple, as demonstrated here with some style by the excellent Philip Bagge:

  • Ask for a volunteer to try to program you (the robot) with instructions for making a jam sandwich. If you have one, let the volunteer use the voice-changer. The clubbers will find the antics of the silly robot funny but make sure their laughter is directed at you and not the volunteer.
  • Let a few different clubbers have a go. They should get progressively better as they note the previous mistakes, so start getting stricter with obeying their commands literally.
  • Pause the proceedings and explain that its hard to program anything when you don’t know what commands it will accept. Say that all languages will have a list of instructions. Reveal your JamSandwich API and ask the next volunteer to try their program using the actions and objects on screen. If you have time you could ask them to work in turns to prepare a set of instructions before attempting to run their program. There are some great worksheet ideas at code-it.co.uk. Tell them they can add an extra element to each category of the API if needed.
  • Be aware that the clubbers will be keen to eat the sandwiches regardless of their condition!

Wrap-up (approx 5 mins)

  • Try to provide a quick summary. Ask your clubbers for feedback. Tell them what you have planned for the next session. Thank them for coming.

Tidy-up

  • Clean up your sandwich making station. If the clubbers ended up eating their sandwiches, check keyboards and mice for stickiness and clean as necessary.