CodeClub: TWSU DIY Gamer Week 10

Nearly everyone was starting the lesson 8 worksheet this week (one superstar is already on lesson 9).  This is really the first session of the final project - building the Simon Says game - and this seemed to be good news for the clubbers as the last couple of weeks have felt a little unconnected and disjointed, There were a few questions about why we'd bothered with the spaceship animation last week and whether this fitted into the final game, but I explained that the idea was that they could use moving images to customise the opening sequence of their game.

The basic premise of this session is to design variations for the various screen images used in the game: left, right, up and down arrows, a tick, a cross and the word go. I must admit I was slightly dubious about this session. Although one thing that I think has been missing from this whole project is the flexibility for the children to customise what they're doing, this seemed like a another distraction with the originality being more about design than coding. I was also sceptical because it seemed to me that there only a few ways to make an arrow on an 8x8 grid different.

As usual, the children demonstrated the power of their imaginations and creativity (and, I guess, the feebleness of my own).

Minecraft axes, smilie faces, stick figures.... just brilliant!

Things to do differently next time?

If I'm honest, I'd completely chuck away the worksheets and either write my own or just try to introduce what they have to do through a demonstration.  It took me a couple of read-throughs to work out exactly what you were being asked to do, so I expected the children to struggle.  The over-achiever who completed this part of the project last week had run into problems so I knew what to expect.   There are a number of areas where I think this session's worksheet could really be improved.

A big problem is that the first 4 pages are basically just information for the children to read.  A couple of the children were asking what they were supposed to do and my only answer was basically  "just read it". That's not so bad, but then the actual practical instructions that follow are quite confusing. 

First of all, there are two many small but important steps that are easily missed out.  Part of this problem is that the children just don't take the time to read them carefully. So crucial steps - like closing the file you've just opened and then opening another one (with a similar name) need to really stand out and be made clear.

Secondly, the description of how to modify the code shows two array blocks side-by-side in a sketch window. So naturally,  a couple of the children tried to type up their sketch to make it look just like that, not really comprehending what the red arrow meant. 

Thirdly, the children wanted to use the DIY Gamer Image Painter software to design their arrows. This is completely sensible, and the worksheet even has a screenshot of the application (even though it says to use the design worksheets).  I don't know why you'd edit the ones and zeroes of the code directly when you have a neat tool that makes the task much easier. However, doing it this way leads to some additional complications. 

The problem is, if you open a sketch window with the code to be modified (i.e. your version of the Simon game) then open the Image Painter app, every time you try to copy the code version of your design (using the insert code button), it will overwrite your entire existing sketch. 

There is a simple work around - open a new (empty) second sketch window and then launch the Image Painter app from that window. That way, the code for the image you create will be inserted into the empty sketch so it is easy to copy-n-paste into your game sketch. 

This still isn't fool-proof. If you close the sketch editor window from which you launched the Image painter app,  it has nowhere to insert the code but doesn't raise any kind of error message - it just does nothing. 

A final problem is that the code generated by the Image Painter is not formatted in the easiest way for easy copy-n-pasting. Several times the children accidentally included the  curly bracket and semi-colon (or missed out the last one or zero) which meant their code would not compile.  By the end of the session they certainly all agreed with the opening sentence of the worksheet: the basic C programming language used by Arduino is very picky!

Suffice to say I was kept busy this week!

Mirobot madness

Following the success of the DIY gamer I've been thinking about what projects might be possible at future CodeClubs.

Earlier this year I funded Mirobot - a wifi robot based around Arduino - and last week it arrived. A wet Sunday afternoon seemed the perfect time for may son and I to have a crack at it.

The main PCB is beautifully manufactured and perfect for young solderers. The instructions are very clear and easy to follow. The issue we encountered is that they never tell you to install the stepper controller IC (although it is shown in some of the pictures).  Working together it took about 45 minutes to get the main PCB and battery pack assembled. I liked that you could perform a useful confidence test by checking the Arduino leds prior to soldering the pack.

With the electronics bit complete, it is time to put together the chassis. All the parts come on 6 laser-cut boards. The componets should easily pop out but I found that some of the smaller parts were quite difficult to extract. Some of them are quite narrow and I needed to go over some of the cuts with a stanley knife to allow them to come away cleanly. My son was struggling and was worried that he would damage some of the delicate pieces. Although the material looks like wood it is really MDF and handles and behaves like thick cardboard: it can easily be torn and split.

I think if I was going to have a larger group of children assemble Mirobot kits I'd be tempted to extract all the pieces from the boards in advance.

The instructions note that the wifi antenna mount is fragile and I found it quite tricky to insert the rigid plastic aerial through the small piece of MDF. The sides are only a couple of mm thick in places and could be easily ruptured. Even with my (relatively) steady hands, some of the pieces came free leaving a layer of MDF behind. I fear that young impatient hands might struggle to complete this step without incident.

As you'd expect, until you get three sides on the chassis it is all a bit wobbly and I wondered whether the finished would need some wood glue to help its structural integrity. However the Mirobot uses an ingenious system of wedges to lock everything into place and the completed unit feels surprisingly sturdy (although I do wonder how long before the transparent wedges come loose and disappear up the hoover). My son is master Lego builder but even he needed an extra pair of hands to hold everything together for some steps.

Once everything is assembled, getting started is super fast. The built-in wifi makes its easy to use a tablet or phone to quickly confirm that everything is working in a few seconds.

However I did find that the connection to the Mirobot sometimes dropped out and the red 'reconnecting message' became a constant presence. I tried configuring the Mirobot to join my home wifi network but although that was successful, it didn't stop the dropped connection problem.

Eventually I seemed to find a workaround which was to keep a ping running from my laptop to the Mirobot. This is a trick I used to overcome issues with wifi dongles on Raspberry Pis suffering from power management issues.

This is a minor niggle and the Mirobot is a great little robot project. As part of the Kickstarter stretch goals I received the add-on kit too which includes a collision sensor which, if our initial tests are anything to go by, will be a useful upgrade. Hopefully we'll be able to get that up and running this weekend.

CodeClub: TWSU DIY Gamer Week 9

Actually, if you follow the official worksheet numbering, we're still on week 6!

By the end of this session each group had successfully got their spaceship to fly across the screen. They had all worked out how to change the speed of the animation and we talked about how we could use a variable to store the time for the delay so that if we wanted to make changes in future we only needed to change the variable and not each individual value. They were all familiar with using variable in this way and seemed pleased at this additional efficiency.

I was also a little dissatisfied with this end of  particular module of the project. The only thing that changes between the different arrays that represent each frame of the animation is the x,y coordinates of the pixels, and they just increment by one each time It seemed to me to be a great opportunity to use a loop!

So I'd prepared a simple challenge sheet to show how to use loops in Arduino and relate it back to some of the loops the children were familiar with in Scratch.

This is quite tricky to implement and even the most accomplished coders were struggling to work out exactly how to do it. It was a shame that the session ended because I think a couple were close to figuring it out. I'll take them through one way of doing it next time.

CodeClub: TWSU DIY Gamer Week 8

We started off today with a short chat about the amazing Philae comet landing. I'd changed the background wallpaper on my laptop to the latest picture taken by the CIVA . We talked about the similarities between what they were doing in CodeClub - programming hardware - to the kind of robotics control needed by something like Roesetta.  I was pleased by how much they knew about the mission and wasn’t surprised to find this group really enthusiastic and excited by the technology involved. 

I don’t want CodeClub to be a ‘sit and listen to teacher’ lesson but after my experience last week I felt I needed to try to get everyone at roughly the same stage. Part of the problem is that there is quite a wide range of ability across the group. A couple of the boys who do a lot of programming at home have been whizzing ahead whereas one pair who haven’t really done much coding outside of CodeClub are struggling a little. It is interesting to see that the age of the children has no relationship to ability (the two high flyers are from years 4 & 5).

So this week I got everyone to follow along with me as I went through the worksheet.  It worked reasonably well. It definitely helped that I could point out to the group that they didn’t really need to do much typing. Once you’ve typed the block of code to display the spaceship once, you can simply copy and paste it and just edit the coordinates. As a lazy programmer that is an obvious approach to me but a lot of the children don’t always think of that and set themselves up for some unnecessary typing. 

Having been shown the shortcut they were able to make much quicker progress  through the worksheet. I was also able to save them having to do a lot of reading by explaining what was happening as we went along. 

Although the session perhaps felt a little more stilted than usual, on reflection I think it was the right approach and I think everyone got a better grip on the concepts as a result. 

I let all the children work individually unless they really wanted to share the typing. Swapping the Gamer devices between PCs doesn’t cause too many problems but it does slow things down a little.  Every now and then the Arduino sketch editor throws and error when trying to upload the new code and needs to be unplugged and then reconnected. 

CodeClub: TWSU DIY Gamer Week 7

With everyone having finished constructing their gamer, I wanted  to get started with the 5th lesson, using the Light Dependent Resistor to control the progress of an animation.

A couple of the groups had started this worksheet in the last session but hadn't seemed to get very far.  In order to make sure everyone was starting from the same place, I demonstrated the key parts of the session to the whole club. There were still a few blank faces and a few questions about why were doing this activity. Quite a few wanted to know how it related to the game we were going to write for the gamer. I'm not sure that my answers - that you could use the LDR as an extra button or that it could used to build some sort of alarm - were very convincing. To be honest, I've never been able to come up with a great use for the LDR in the context of creating games. The fact that it will always need some sort of calibration based on the actual light levels at the time of use makes it seem a bit difficult to reliably use in a working game.

The clubbers started to tackle the worksheet and I got the impression that they found it quite confusing. All of the groups made the same mistake in the first few pages: they created two void loops functions. Looking at the instructions I can see why. First of all it asks them to create two empty functions (the setup and loop). Then a few pages later it asks them to edit the void loop function to add the code to print the light value to the serial console. I think it needs to say "modify the loop you created in step 6" or at least make it more explicit that you're not adding another loop function. 

Every group also struggled with the next section. Opening and closing the different scripts and copying bits from one to the other really had them in a muddle.  It does all seem a little futile.  They may as well just insert their LDR max/min values into the example animationLDR script and run that. I don't think they learnt anything from typing in a couple of quite baffling lines of code. Although there is an explanation of what the code does in the worksheets, they do require a lot of reading and don't really explain how you might use similar code to control something else (e.g. the IR receiver).   

To try to liven it up I suggested they use their own animations from the previous week but I think that just added more confusion.

Certainly compared to the normal CodeClub Scratch or Python projects this all seems quite a slog with very little payout (although perhaps it just feels like that after the excitement of the soldering and assembly). 

I'm also concerned that lesson 6 may have similar problems. Although controlling and moving an on-screen object with the buttons is clearly a key learning point, it isn't really used by the Simon Says Game so it feels a bit superfluous again. 

Things to do differently next time?

I'm not sure I would bother this week's activity at all, unless the use of the LDR can be more integrated within the overall project objective.  An exercise to demonstrate the potential for some of the other gamer components is a good idea but I wonder if a simple program to exchange messages via the IR capability might be more interesting.  

One of the gamer's LDRs was only showing a very slight change in the value it reported through the serial console for different light levels. On closer inspection I think the soldering is a bit ropey and the LDR actually wobbles a little. Hopefully re-soldering it will correct the problem. Next time I'd try to check that all LDRs work correctly before the session.