New year countdown with UnicornHat

Now Christmas is over, I'm missing my Unicorn Hat decoration. So how about a New Year countdown?

Using my Scrolling text library, I've knocked up some quick Python to display (in a random colour) the number of seconds remaining until 00:00:00 on Jan 1st 2015. Once that time is upon us it will display a suitable message.

from dateutil.relativedelta import relativedelta
from datetime import *
import calendar
from UHScroll import *
import random
import time

NY= datetime(2015,1,1,0,0)
cols = ['red','white','green','blue','cyan','yellow','orange']
while True:
NOW=datetime.now()
t = relativedelta(NOW,NY)
total = (24 * 60 * 60 * t.days) + (60 * 60 * t.hours) + ( 60 * t.minutes) + t.seconds
countdown = str(total)
if total < 0:
unicorn_scroll(countdown[1:],random.choice(cols),255,0.05)
time.sleep(0.2 * len(countdown[1:]))
else:
unicorn_scroll('happy new year!',random.choice(cols),255,0.1)
time.sleep(0.5)

Unicorn Hat text scroller

After I wrote my Xmas Tree code for the Unicorn Hat I felt like I needed to also be able to display a festive message. Although it is quite narrow, I reckoned a text scrolling app would work quite well on the Unicorn Hat if I kept the character size slightly smaller than full-screen(grid?).

I decided to fix most characters to 6x4 pixels (with the exception of those fatties M and W) which allows for portions of 2 characters on the screen simultaneously.

I've stuck the various Python files up on GitHub. In includes a test script which produces this output:

Anyway, my son liked it and wrote a program to create a random 5 letter word and display it in a random colour:

from UHScroll import*import random import string
bill=['red','white','pink','blue','green','cyan']
def wordpick():    qwerty = ''    for q in range(5):        bob=random.choice(string.letters)        qwerty = qwerty + bob    return qwerty
for w in range(5):    dad=wordpick()    print dad    unicorn_scroll(dad,random.choice(bill),254,0.5)

He likes doing stuff with the Python random module at the moment...

Unicorn hat Xmas tree

The Unicorn Hat from Pimoroni is a great board for the raspberry Pi. It was just crying out for use as a Christmas decoration. So here's a quick bit of Python to generate an Xmas Tree.

A version (which may be updated) is also on github.  You'll obviously need the Pimoroni Unicorn Hat library for this to work!

import unicornhat as UH
import  sys, time
import random
UH.clear()

while True:
# create each row of the tree
for y in range(0,8):
for x in range(6,8):
UH.set_pixel(x,y, 0,255,0)
for y in range(1,7):
for x in range(4,6):
UH.set_pixel(x,y, 0,255,0)
for y in range(2,6):
for x in range(2,4):
UH.set_pixel(x,y, 0,255,0)
for y in range(3,5):
for x in range(0,2):
UH.set_pixel(x,y, 0,255,0)
UH.show()
#now generate the baubles at random
balbs = random.randint(1,5)
i = 1
while i <= balbs:
b1_y = random.randint(1,6)
b1_x = random.randint(4,5)
randr = random.randint(50,255)
randg = random.randint(50,255)
randb = random.randint(50,255)
i+=1
UH.set_pixel(b1_x,b1_y,randr, randg, randb)
balbs = random.randint(1,4)
i = 1
while i <= balbs:
b1_y = random.randint(0,7)
b1_x = random.randint(6,7)
randr = random.randint(50,255)
randg = random.randint(50,255)
randb = random.randint(50,255)
i+=1
UH.set_pixel(b1_x,b1_y,randr, randg, randb)
balbs = random.randint(1,3)
i = 1
while i <= balbs:
b1_y = random.randint(2,5)
b1_x = random.randint(2,3)
randr = random.randint(50,255)
randg = random.randint(50,255)
randb = random.randint(50,255)
i+=1
UH.set_pixel(b1_x,b1_y,randr, randg, randb)
UH.show()
time.sleep(0.4)

CodeClub: TechWillSaveUs DIY Gamer Final Thoughts

I thought I just knock out a few final thoughts regarding the TechnologyWillSaveUs DIY Gamer project I ran at my Codeclub this term. More to get my own thoughts together, but also as an overview for anyone thinking about something similar.

What was really good

1. The whole hands-on soldering part of the project was brilliant. It was great to see everyone's confidence growing over the three weeks when we did the construction. In terms of learning about physical computing, this kind of activity is hard to beat. Even making mistakes - soldering the led in wrong way round - was a learning process.
2. The DIY Gamers themselves are very well designed and engineered. They all worked reliably and had no problem coping with the odd drop or knock.
3. The children became really familiar with attaching devices to their PCs and programming them through the Arduino interface. The first time we download something to the Gamer they found the various steps in the process quite daunting, but by the end of the term it had become second nature. 
4. Exposure to basic electronic components was very useful and the children retained a lot of knowledge about what the various parts did and how they could be controlled or provide feedback to a computer. 
5. The children loved designing their own arrows for the Simon Says game, and the repetitive nature of this task really helped them get to grips with how the led matrix was addressed through the code. 
6. The project as a whole provide lots of opportunities to talk about and discuss areas of computing and computational thinking that don't crop up with the Scratch and Python syllabuses (e.g, robotics, sensors etc). 

What could be improved

1. The soldering irons seemed to be quite low quality. Only one of the three I with which I was supplied still works, and I wouldn't personally like to use it on any serious soldering.  I understand the need to keep costs down but suspect these were a false economy. 
2. The overall design of the course materials as a whole seemed disjointed in places. There were a few weeks where the activity seemed very isolated from the rest of the project. The children spent quite a lot of time getting to grips with the LDR but then never used it again. I think activities where each session builds on the last are much more effective.
3. The quality of the worksheets was also variable in places. The last few session instructions felt quite rushed to me and I think a lot more thought needs to go into what the children will learn from each section. 
4. There was a lot of functionality in the Gamer that was never used. Kids love noisy things, and it seemed a shame not to have the Simon says game make any use of the buzzer. 
5. I think that not being able to keep the DIY Gamer at the end of the project is a real limiting factor. The children who attend Codeclubs are used to being able to work on their Scratch or Python projects at home and show their friends and parents what they've been up to. I realise there are pretty significant cost implications but some form of subsidy might be something worth exploring if you're thinking about this kind of project. 
6. I think the Simon Says game is a little dull. When they were allowed free play with the Gamers, they always downloaded snake or flappy bird. Nobody wanted to play the Simon Says game. I don't think it was inspiring enough and this didn't help motivate the children through the tougher sections. 
7. There wasn't a lot of opportunity to customise the game as they went along and some of the later session were easy to complete by following the instructions but without really learning anything or understanding what was going on. 

Questions

1. What should schools/clubs do with the Gamers at the end of the projects? As the children have been working in pairs, letting them keep the units could be tricky. Options for re-use seem fairly limited though. De-soldering the components and starting the whole project from scratch just really isn't viable in my opinion. You could re-run the sessions  starting with a completed Gamer but without that initial hands-on element, I think the overall impact would be greatly diminished. If there were some more follow-on projects for the Gamer, then that would be great.  Alternatively I might use these Arduino's for other activities that I've been thinking about, although I'm aware that not everyone will have the knowledge or time to do this.

In summary, would I recommend the DIY Gamer project to another club/school?

Absolutely. It was a great experience for both me and the children, and everyone learned a lot.

If I had to give one piece of advice to anyone running a similar project it would be to not worry about the children understanding every single aspect of the code they encounter. This is real programming!

CodeClub: TWSU DIY Gamer The end!

Final week of the DIY Gamer project!

I'm fairly sure that when the kits were first released, it was intended to be a 12 week project.  The final worksheet certainly seems to have crammed a lot in, with 20 pages of stuff to do.

To add the final features to the game (start screen, scoring etc), the idea is to use a code library which contains the various functions needed. I like this as a concept as it reflects real-world coding practice, although the worksheet doesn't really explain this apart from a brief mention on the front page. Obviously I try to talk things through as we're going along, but this is not always easy when you're spending a lot of time trying to find the missing (or extra) semi-colon(s) in the clubbers' sketch programs!

My observation has been that the children generally skip over the 'code comprehension' pages which is a shame as they are normally very useful. However I have to say that the examples in Lesson 10 were quite skinny. The explanation for the code block:

for(byte b=0; b<sequenceLength;b++) sequence[b]=0;

was:

"Clear the sequence. A 1-line for loop doesn't need parenthesis, but we have added them for consistency."

I know the children at my CodeClub are very bright but unsurprisingly, none of them could make head nor tail of this particular gem.

Only a couple of groups managed to get to the very end having completed everything (and one of those only because they came to my afterschool codeclub to finish it off - there's dedication for you). I suggested to the whole group that we could have an extra session at the start of next term so that everyone could complete the whole project, but the general consensus was that we should start something new. They've definitely got the hardware bug though, so I'll have to dream up some suitable projects to keep them satisfied.

Things to do differently next time?

I think it would be worth really taking more time to explain what's going on with the 'Advanced tab' and the code library. 

When you are dealing with this much code, debugging problems can be quite tricky. The compilation error message generated by the Arduino Sketch editor are not always the most helpful and the line referenced is often not the origin of the problem - typically it is a missing } further up. Sometimes the code has become such a kludgy mess that the easiest fix is to start from a known-good state. I think more liberal use of 'save as' as the children progress - essentially saving a new version at every stage - would make it easier to revert in the event of problems.  Although I had the various 'working' examples to hand, the kids were reluctant to use these as they didn't contain their unique arrow designs and copy-n-pasting them from one file to another often generated more problems. 

So this is the end of the DIY Gamer project. I will try to post some general comments over the next few days but I'd be really interested to hear about other CodeClub's experiences. Drop me an email, tweet or leave a comment below. 

CodeClub: TWSU DIY Gamer Week 11

The advantage of having one pupil who is slightly ahead of the others is that they provide an early warning of potential problems in the next part of the project. So I knew that there were a couple of 'gotchas' in the instructions for Lesson 8 - Button Press.

The first one is that one particular section asks you delete a big swathe of code from the existing project. The worksheet says to delete the code highlighted in red. Unfortunately it isn't actually highlighted, its just in a red font, as is a lot of the other Arduino sketch code shown in the examples. This includes the void loop() line immediately above the block of code to be deleted. Very confusing!

It also raises a good point about the worksheets. Not every one will be able to print/photocopy multiple copies in colour. Certainly the main copier at my school is B&W.

The actual code that is used in the session is fairly minimal and most of the groups got through it in plenty of time. It certainly feels a lot skinnier that the previous sessions and is really just coding by numbers. The challenge at the end didn't make much sense either, it asked "can you think of a way to use another for loop?' But the code used for this part of the project doesn't include a for loop - that was the bit that was deleted. I'm not really sure what the children were supposed to do here.

As we're approaching the end of this project and the end of term, I was asking the children what they'd like to do next year in CodeClub. The unanimous answer: MORE SOLDERING!

Things to do differently next time?

As usual there was quite a lot of debugging needed. The children are certainly learning how unforgiving the Arduino sketch language is! Finding the error can be quite hard even for me. To be honest, the children really don't have enough experience to have much of a chance of correctly the interpreting the error messages. This means their efforts largely centre around spotting the difference between their code and the sample at the back of the worksheet. I think this discourages them from ever attempting to try their own modifications so I might omit the cheat-sheets from the handouts next time.