Main menu

Monthly Archives: October 2018

Post navigation

This week we looked at animations, and how to make objects move in p5.js.

We covered:

How to animate things in p5

Some mouse interaction

Animation in javascript (or all programming really!) is basically changing some variables in the draw function before we actually draw the object. If we change each variable by a little bit, it looks like smooth movements, just like a cartoon!

To save some typing, there is a video below with a quick overview of what we did:

Okay, it’s pretty simple stuff and not exactly the most exciting animation in the world, but you guys did some playing around and came up with several interesting variations and now we know how to do it, the sky is the absolute limit on what we can build 🙂 !

As usual, the code is up on the github to be pulled down and played with or changed to your heart’s content!

This week in the Bodgers group we started working with Pygame Zero. Pygame Zero allows us to write our own games quickly and easily by doing a lot of the work involved in setting up and running a game in the background. This allows us to focus on the more creative aspects of the game.

You will have to install Python and Pygame Zero if you’re going to use Pygame Zero at home, details on how to do this are in my slides. A few of us had installation problems on Saturday, so don’t worry if you have issues we will help sort it out when we return after the break.

This week in the Hackers group, Kevin led the way in completing the work on the principles of the soldering iron station. While our relay can switch on/off a 220V device like the soldering iron, we tested it with a … Continue reading →

Introduction

This week we looked at what happens to water molecules when they are heated up.

We started with a little science experiment to demonstrate Brownian Motion, this was done with a glass of very hot water and a glass of very cold water and some ink.

When the ink is dropped in the two glasses it behaves very differently, in the cold water the ink stays suspended and visible as ink for a long time, but in the hot water the ink gets mixed into the water molecules very quickly, this is because the water molecules in the hot water are moving around much faster and bashing into the ink molecules and mixing them up.

Can you guess which glass has the cold water in?

The Plan

The plan was to build a scratch program that would show the water molecules moving around faster or slower, depending on temperature. In order to do this we needed the following:

A Sprite for our water molecule

A slider to control the temperature

Some code to make them move around.

The Sprite

Water molecules are made up of 2 Hydrogen atoms and 1 Oxygen atom (H2O), the Oxygen atom is quite large compared to the Hydrogen atoms and the Hydrogen atoms stick to the Oxygen atom at about a 45 degree angle, they end up looking like Mickey Mouse, so our Sprite looked something like this:

We changed the settings of the Clone so it didn’t rotate.

The Temperature Slider

In order top control the temperature we created a variable, making sure that it was set for “All Sprites” and that it was set to be a slider. We also set the minimum and maximum values:

The Code

As we needed lots of these Sprites we decided to use the Create Clone block (Control) to create 100 of them.

In order to move the Sprites around we needed to keep looping, picking a random direction and then moving a little bit. We also needed to change the amount we moved and also the direction as the temperature went up. The direction needed to be more upwards as the temperature got higher so the water molecules would start floating like steam if the temperature got high enough.

We used a Gravity variable to make sure the Sprites pointed upwards as the temperature got higher, because this needed to be different for all the Sprites so they moved in random directions, we created the Gravity variable “For this Sprite only”

The code ended up looking like this:

Initialise the Temperature variable and then create 100 clones.

Initialise the Sprites Gravity variable

Pick a random spot along the bottom of the Stage

Make sure we are pointing more towards the top, depending on the temperature.

If the temperature is > -1 move around, otherwise we are frozen, so just go back to the bottom of the screen.

Introduction

This week we decided to create a Lunar Lander game that demonstrated the effects of Gravity.

The Plan

As always we started with a plan:

A Spaceship Sprite with 4 Costumes

No power

Up Rocket firing

Left Rocket firing

Right Rocket firing

Buttons to control the Space Ship

Stage which should be a picture of the moon.

A landing pad to land on – just draw on the Stage

Code to control the Space Ship

3 Variables, to store Gravity, Power and LeftRight information.

Space Ship Sprite

This what mine looked like:

Space Ship Sprite

The Left and Right costumes can be confusing, to move left, the flame needs to come out of the right, and to move right the flame needs to come out of the left hand side.

Stage

My Stage looked like this:

One thing to remember is to have the landing pad in a different colour.

Buttons and Code

I’ll put these 2 parts of the plan together as it makes more sense.

We decided to use 3 different buttons to control the Space Ship

Up Arrow – This would fire the rocket at the bottom of the Space Ship

Left Arrow – This would fire the rocket on the right side of the Space Ship

Right Arrow – This would fire the rocket on the left side of the Space Ship

And now the code.

We needed code for each of the buttons, code to move the Space Ship and code to know when we have landed. This meant we had lots of small pieces of code all running together in Green Flags with forever loops.

We also decided that we would need 3 variables to store information so we could work out how far to move the Space Ship.

Gravity – This would change as the Space Ship got higher, just as real gravity does.

Power – This would change when the Up arrow was pressed and also when nothing was happening

LeftRight – This would change when the left or right arrows were pressed

And don’t forget if we have variables, we should set them to starting values when the Green Flag is clicked.

This also has the code that puts the Space Ship in to a starting position. Note the Y value as this is used later in the code to see if we are on the ground or not.

For example, when the one of the left or right arrow keys was pressed we would change the Costume and change the LeftRight variable.

We did the same for the left arrow. Note that we just add (or subtract for the left arrow) a small amount from the LeftRight variable.

The delay is to make sure that the variable is not updated too fast if the arrow button is held down.

For the Up arrow we have to change a different variable

Note the wait is much shorter, this is to match the wait in the forever loop that moves the Sprite.

We also change the Power variable by a large amount as this helps with the calculations.

Once we had the buttons working we could move on to the Code that moved the Sprite.

The Left or Right movements were easy, that would just be the amount in the LeftRight variable.

The Up or Down movements were a little trickier as we had to account for Gravity as well. So we just used the Y position of the Sprite and added 180 (to make it a positive number). This meant that Gravity changed as the Sprite moved up or down, which is exactly how Gravity works in real life.

This is how the code ended up

We move first and then check how high we are.

If we are above the ground, we know this by checking that we are above the starting position of the Sprite, then we adjust Gravity and adjust the Power down.

Note the wait is the same as the Up Arrow code.

Also, if we are on the ground, we set Gravity and Power to 0.

There was one final piece of code that we didn’t do but I have added here, this was to check if we had landed and if we had, display a message and end.

It was just another Green Flag with a Forever loop and we kept checking to see if we were touching the colour of the landing pad.

We started of this week’s session by looking at the recent Soyuz rocket launch which was to send two people to the ISS. During the launch one of the booster rockets failed and the launch had to be aborted. Both crew members, astronaut Nick Hague and cosmonaut Aleksey Ovchinin, escaped without injuries.

It’s longer than before, but notice how the same two lines now keep repeating. If we had a way to say “do these two lines four times” then this would get much shorter, and we do. We use the for statement:

This means that i will have the values 0, 1, 2 and 3 and our two lines will be run four times in total. Result! Our code can draw a row of circles. If we increase the value in the check, we can have as many as we like. We choose to have 8.

Nested Loops

Nesting a loop means putting one loop inside another. What’s the point of that? Well in our case we have a loop that can draw a single row of circles. If we put all of that inside another loop we could draw several rows. The row outside has a different variable j and also runs eight times. After we draw our row we do two things:

Then down in our code, where we’re deciding what colour to make our circles, we change the check to read:

if (pattern[j][i] == 1){
: : :

What does this mean? Well, j is a counter that goes from 0 -> 7 as we go down our eight rows. Given that, pattern[j] means get entry from our list for that row. Since pattern[j] is a list too, we need to say which entry we want in. The variable i goes from 0 -> 7 as we go across each row. So, pattern[j][i] gets the list for the row and then picks out the number for that column.

Once it’s set up, we can then change zeros to one in our pattern and have our circles turn red to match (red in the text below to make them stand out):

This week, I helped Bo Peep found her sheep! Some of you did the same and some used ideas like Minecraft Steve finding Iron Ore and Diamonds, Knights finding dragons or a Princess finding flowers.

Before we even started our game this week we talked a little bit about File Management and about the importance of keeping your files somewhere you can access them quickly and giving them a meaningful name.

So to this end, we all created a folder where we will be keeping our files in the future and within that we had a sub folder for this weeks files.

We started our game by drawing our background on our stage:

Unfortunately, due to internet problems we could not search the internet for images for our Sprites, but we could still use the sprites from the Scratch Library.

This week, we decided to move our main sprite using the arrow keys. For this we had to learn a small bit about the X and Y axis and I gave you a little tip on how to remember which is which!

Hope you all enjoyed this week, aee you next week when we will be starting a new game!

Last week, we used an LM35 temperature sensor to read the temperature in the room and report it on the Arduino serial console.
We were able to get a reading for the temperature of the air in the room, and the temperature of a cup of coffee touching the sensor. We couldn’t be sure, however, that the readings were correct. So, we decided to test with a potentiometer and a voltmeter.

We supplied 5 V to the potentiometer and fed the output to the Arduino. We used a voltmeter to measure the output from the pot and compared it to the reading from
the Arduino. Once we got the code working, we got good agreement on voltage readings between the meter and the Arduino.

The sensor presents a voltage on its output pin that represents the temperature its measuring. In its basic mode, the sensor reads temperatures between 0.2 and 150 degrees Celsius. Every degree is 10 mV, so the output voltage ranges from 2 mV to 1500 mV. Converting our voltage reading to a temperature is simple then: divide the voltage reading in millivolts by 10.

We can use one of the analog I/O pins on the Arduino to read the voltage. The analogRead() function returns a value between 0 and 1023 for voltages between 0 and 5 V.

We digressed into how to use a multimeter correctly. The first thing to do is make sure that our meter is set up correctly.
We tried measuring a 9 V DC battery with the DC voltage setting and got 9.2 V. We then tried measuring the same battery with the AC voltage setting. This time we got 19.6 V.
There’s a lot of potential (sorry) to get confused, then. Worse again, if we try measuring 220 VAC with the meter set to DC, we get a reading close to zero. In other words, a live AC supply looks safe if we set our meter wrong.

Next, we start with the highest reading range and step down. For a 1.5 V battery, we start with the 200 V reading, then step down to 20 V. This is to protect the meter: if the voltage is higher than we expected, we might damage the meter.

Voltage readings are taken in parallel with the circuit, and while it is live.

Resistance and continuity readings, on the other hand, are taken with the component disconnected from the circuit.
We worked out why with a simple circuit:

F is a fuse. W is a wire between the two ends. We’re not sure if the fuse is blown. We try testing for continuity across the fuse by putting our meter leads on A and B.
Even if the fuse is blown, we will get continuity because W provides a circuit. We need to cut the wire to get a true reading.

Our first attempt at Arduino code for the voltage reading gave us a surprise. Our meter displayed 2.5 V. The Arduino displayed 2 V. We used this formula to calculate the voltage:
v = 5 * analogRead_reading / 1023.
V was declared as float variable. analogRead_reading was declared as an int. The Arduino code multiplied two ints and divided the result by another int, truncated the result and stored the int as a float. When we made the 5 and 1023 floating point numbers (5.0 and 1023.0), we got the right answer.

Once we were happy with the Arduino code, we replaced the potentiometer with an LM35. Unfortunately, we didn’t notice the “bottom view” label on the datasheet drawing. We connected the 5 V supply to the wrong side of the sensor. It’s amazing how hot a temperature sensor can get! It was too hot to touch. And we couldn’t measure the temperature because…
After we disconnected the LM35, we made another discovery: we continued to get random voltage readings displayed on the Arduino even though there was no voltage to read. The analogRead() function happily outputs values from random noise.

Next week, we’ll use an LM35 connected the right way around, and try controlling a relay to switch power on and off to an external device. We’ll build a temperature controlled soldering station carefully – we want to solder with the tip of the iron, not the temperature sensor.