Session One

The idea of Project Met was really simple. Pupils at school need more chance to be creative, and so after a chat with the Deputy Head Teacher two Year6 pupils were chosen to work on this project.

Taking inspiration from the "Window on the Weather" RaspberryPi project, the pupils were asked to create their own way of reporting the weather around the world.

They followed the instructions in the guide to get started, with only one problem that cropped up with the provided python code;

Weather_py_-__Users_simonwiddowson_Desktop_weather_py__3_5_2_

(Their Raspberry Pi3 had IDLE2 and IDLE3, and was opening the Python code in the wrong version - causing an error)

Once figured out, they had a working initial programme that used Python, Scratch and the OpenWeatherMap API to display weather conditions in any location they entered on screen.

And at this point, they ran out of time in the first session.


Session Two

This week the two Yr6 pupils looked at their programming so far. They wanted to check that everything worked properly, and so typed in a range of cities around the world to see whether the sun changed size depending on temperature, how much the cloud moved depending on the wind speed and the transparency of the cloud depending on cloud cover.

They noticed after trying several cities that it seemed to work fine, but that they couldn't get the rainfall animation to appear. No matter which city they tried, there seemed to be no rain in world! We even looked on the lightningmaps website to try and locate a city near to a large thunderstorm - but failed!

So, from this we discussed whether it would be a good idea to leave the programming running with the need to type in a city to get the weather - what could a user do if they had a keyboard and mouse available*. They realised that these peripherals would potentially allow users to stop the program and fiddle, and so they had to think of an alternative solution to display weather - at a range of cities - without the user needed to type anything.

They discussed the need for a list (a feature in the variables area of scratch), and perhaps for a single button that a user could press to change the city, but also looked at the number of API calls that could be made and what would happen if this was exceeded.

And so, they began to rewrite the program - this time using a list of preprogrammed cities, and only having the space button working to change the city. They will be continuing with this next week. If all works well, they can then move on to adding a physical button instead of using the space key.

*This led to an interesting question about how the program could be altered if needed, and a demonstration of the built in RealVNC feature that allows my staff iPad to remotely access and alter the Raspberry Pi that is running the weather reporter.


Session Three

More designing how the screen will looks in today session;

  • added a compass graphic for the wind direction arrow to sit on top of to make it easier to work out the wind direction
  • added a thermometer to put the temperature value next to
  • added an extra line of code to the cloud graphic to vary transparency depending on the cloud cover value
  • sourced and added background graphics related to each city that displays data

In addition, they also learnt an important lesson about the use of the operator "a > b" and the values needed within it. They solved the issue they had by logically working through the blocks until they could see where there coding error occurred.

Next week the plans are to decide if we need anymore cities adding to the list, and then how to make all the separate parts of the program automatically start when the pi is powered up.


Session Four

The pupils added a few more cities to their list today - they now have nine (Anchorage, Berlin, Cardiff, Edinburgh, Las Palmas, Leicester, New York, Paris, Sydney) - and also images to use at backgrounds with those new city additions.

As they tested the program, one of the pupils noticed that the weather data for the countries was mixed up. This prompted a discussion about why, and analysis of the code to see what had changed (they soon realised that as they had gone from 5 to 9 locations they had to alter a value within a key operator).

The final addition was the removal of the small variable display of the city name, and creating a custom sprite with 9 costumes that displayed the name on screen in a larger font. Again, they problem solved the issue of the dark text being unreadable over a dark background image by adding a white ribbon along the bottom of their screen.

With all this completed, they ran their program to check everything worked. And crashed the python program!

So as the lesson ended, they left knowing that next session they need to look at the python program and work out what has happened to make it fail whenever their program changes city location.


Session Five(ish)

There was no session five today as the pupils were otherwise engaged. So instead I sat and continued to look at the python code and try and work out just what was causing it to crash when pulling the weather data.

The scratch program always started properly, but then crashed when the second set of city data was called for. No matter what I looked at I could not work out why. Eventually, out of sheer frustration I removed the second city from the list of place names and tried again.

Success! The program ran correctly. But I still had no idea what was going on. I left the program running, became distracted and then turned back to the screen later on to see that the python had once again crashed at some point. 

Where? I wasn't sure, so I restarted everything after adding an extra scratch block that let me use the space bar to cycle through cities quickly.

Sydney worked fine. New York had been removed. Leicester worked fine. Berlin worked fine. Anchorage worked fine. Las Palmas... Las Palmas broke the code once again. 

I removed Las Palmas from the list of locations and reset everything for a third try. Sydney, Leicester, Berlin, Anchorage, Paris, Edinburgh Cardiff. The program worked without error, and looped back to the beginning and repeated without fault.

So what were New York and Las Palmas doing to break everything? What did they have in common? Finally I realised. They were both two word cities. Cities with a space as a character within them. The python code didn't like sending an empty character as part of the data. Simple as that.

And so, without wanting to change the New York and Las Palmas slides in the scratch program, the locations were simply changed to Manhattan and Tenerife (one word locations that wouldn't cause an issue).

Bug squashed. Program working. Finally!


Session Six

With the code working, the children were able to complete the project this week with the addition of a frame around the TV screen (hiding both the edge of the TV, and the large black border a full screen scratch project leaves). They used thumbnails of the city locations to show the order of the weather reports, and also briefly explained how to read to weather on screen.

IMG_0531

The screen itself reports on the temperature and wind direction using images at the bottom of the screen;

IMG_0534

Whilst an animated cloud at the top of the screen indicates wind speed by how rapidly the cloud moves across the background, and cloud cover by the opaqueness of the cloud (the more transparent the cloud, the clearer the sky is). 

IMG_0535

As the project runs itself and automatically changes location every three minutes, all we need to power is a TV and Raspberry Pi with a wifi card in. No keyboard or mouse needed. Any necessary changes are made using VNC via an iPad.

Photo 30-11-2016, 12 25 47