Lesson video

Hi everyone.

My name is Mrs. Jenkins.

I can't wait to learn with you today.

Welcome to today's lesson, Making a Step Counter.

It has come from the unit, Sensing Movement with Physical Computing, and by the end of today's lesson you'll be able to develop a programme to use inputs and produce outputs on a controllable device.

Before we get started, we have three key words.

These words will appear throughout the lesson, so it's really important that we know what they mean before we get started.

Those three words are test, debug, and design.

Test is to try a programme to check that it works.

Debug is the process of finding and correcting errors in a programme, and design is a plan that shows how a programme should work.

Keep an eye out for these words throughout today's lesson, they were test, debug and design.

In today's lesson, Making a Step Counter, we have two learning cycles.

The first is use your design to build the step counter and the second, test, debug and improve your programme.

So we're gonna start with use your design to build the step counter.

We're going to follow our step counter design and write the code we need for the project.

We'll use inputs, variables, conditions, and produce outputs.

Here's a completed step counter design.

You can choose this to use this one or your own.

This plan is provided as an additional resource for this lesson.

So we have variables and the variable we're going to use is step.

We have inputs, so we're going to have when it's shaped or when the button is pressed and what will be displayed, that display the number of steps, and display keep it up if steps are less than 30, and display you are doing great if steps are more than 30.

Here is our algorithm and programme flow.

Our algorithm says set steps to 0, if the shake is detected, change steps by 1, when button B is pressed, a, if steps are less than 30, say keep it up, b, if steps are greater than 30, say you are doing great.

The programme flow says, set steps to 0.

One shake, change steps by 1, button B pressed, if the steps are less than 30, say keep it up, if the steps are greater than 30, say you are doing great.

Izzy asks, "Why do we need a design to start our project?" And Jacob says, "We don't need to think about the code or commands we need yet, but the design gives us a clear plan for our project." That's right, Jacob, it lets us think about what we are going to need for our design.

Izzy asks, "What code blocks will we need?" We will need a variable for steps.

We will need it to have on shake, increased steps, on button press, show steps, and if steps are greater than a number, show a message.

Okay, let's have a little check in now, which block displays a variable to the user? A, set steps to 0, B, show number of steps, C, change steps by 1, or D, button A is pressed.

What do you think? Have a go.

How did you get on? I asked which block displays a variable value to the user? A, set steps to 0, B, show number of steps, C, change steps by 1, or D, button A is pressed.

The answer is B, show number of steps.

Great job, everyone.

Izzy is asking, "How do I start coding?" Okay, to start our coding, we can open oak.

link/makecode.

We can start a new project and name it.

You watch the video to see how to create a variable.

Okay, so we're going to start with our forever loop and then we will put an if-then in and we will then make a variable and call the variable steps.

Once you've created the variable, you need to set the variable to 0.

This can either be on start or when button A is pressed.

On shake, the step count needs to change by 1.

Okay, now we can look at how to show the step count.

Okay, so we use an if-then block and we put button B is pressed, we then click, we then move show number and drag in then our steps to make sure that that shows the number of steps.

Lastly, we need to add a motivational message.

So watch the video again to see how to add a motivational message.

Okay, so we are going to put an if and then we're gonna put R if it's something is less than, so we've used a conditional operator here and we're going to say if the steps, being a little bit more ambitious in this one, and it says if the steps are less than 50, then we are going to leave a message.

We're gonna put in a message.

So we use show string and we we're going to put a motivational message.

So we're gonna say keep on going, okay.

Okay, let's have a little check in here.

True or false, you should build your whole programme before testing anything.

What do you think? Have a go.

How did you get on? I asked you, true or false? You should build your whole programme before testing anything.

The answer is false.

You should test small parts as you go so you can notice errors quickly and correct them.

Great job, everyone.

Okay, we're going to move on to task A now, I would like you to use your design to create a step counter programme using MakeCode, use your design or the example, include a variable for steps, an input to increase the step count and output to show the step count and a condition to display a message.

Have a go.

How did you get on? I asked you to use your design to create a step count programme using MakeCode, use your own design or the example, include a variable for steps, an input to increase the step count an output to show the step count, a condition to display a message.

My code looks a little bit like this.

I have on start, steps, set step to 0, and forever, if shake gesture, change step by 1.

If button B is pressed, then if step is greater than 30, show number step and show string, great, else, show number step and show string, keep it up.

So it's going to say you're doing great if you are greater than 30, but it will say keep it up if it is less 30, great job.

Let's move on to learning cycle two now, test, debug and improve your programme.

Izzy says, "Why do we test our programmes?" And Jacob explains, "So that we can check for problems and improve the programme." And Jen explains, "We can compare the programme with the design." A really good reasons guys, well done.

Izzy says, "But how can I see my code run on an actual device?" That's a good question, Izzy.

There are a series of things you need to do to run your code on a micro:bit.

First, connect the micro:bit to your computer using the USB cable, then click on download, locate your the file in your downloads folder, copy the file from the folder to the micro:bit drive and run the programme on your micro:bit.

And she says, "Where should we put the micro:bit to test it?" And Jacob's got some good answers.

It could go in a shoe or strapped onto an ankle.

So here's an example here where it's actually been attached to the shoe laces to keep it nice and secure.

Okay, so we need to make sure we've put it somewhere secure, either wrapped around an ankle or on a shoe so we can test our steps.

What could go wrong? Izzy said, "It counted too many steps." Sam said, "I couldn't see the step count," and Jun said, "My steps didn't increase at all." These are all things that could go wrong with our micro:bits.

And she, Izzy asked, "Well, how can I fix the problems if I find them?" It's best to first test small blocks of code on their own.

We call this debugging.

Thank you, Jacob, great answer.

Jun says, "Then swap to the next part and check that it's easier to spot problems in smaller blocks of code." You are right, Jun, it's much easier than having all the code at once.

Okay, let's have a little check.

True or false, if my programme doesn't work, I should test small sections of code to help find the problem.

What do you think? Have a go.

How did you get on? I ask true or false? If my programme doesn't work, I should test small sections of code to help find the problem.

And it's true, it's much better if we test small sections of code at a time, great job.

The sensitivity can be adjusted.

We can use the acceleration mg block instead of the on shake block.

If the acceleration, mg, is greater than a number, add 1 to steps.

The higher the number, the harder the shake needs to be.

I have set my acceleration number to 1,500.

Izzy ask, "What does acceleration mean?" Acceleration, mg, is how strong the movement is.

The micro:bit can check this and then react.

Okay, another little check for you here.

What does the acceleration mg block do? A, show battery level, B, add steps to your code, C, detect strong shakes, or D, starts the programme.

What do you think? Have a go.

How did you get on? I asked, what does the acceleration mg block do? A, show battery level, B, add steps to your code, C, detects strong shakes, or D, starts the programme.

And the acceleration block detects strong shakes.

Great job.

When you are testing your improvements, it's important to try different values and see how they work.

Make sure you test your on your emulator.

Then you can run it on the physical micro:bit when you are ready.

Okay, let's move on to task B now.

So we are going to test, debug, and improve your step counter.

So I would like you to run your code on a physical micro:bit, test to see if it meets your design, use debugging techniques to fix problems and adjust sensitivity using the acceleration block, retest, and make any final changes.

Note, each time you change the programme, you will need to download the programme again to the micro:bit.

Have a go.

How did you get on, I asked you to test, debug and improve your step counter.

So I'd like you to run your code on a physical micro:bit, test if it met your design, use debugging techniques to fix problems and adjust sensitivity using the acceleration block, retest, and make any final changes.

I did say to note, each time you change the programme, you have to download the programme again to the micro:bit, share your designs with others and test them out.

Izzy said, "I tried my design and it worked really well," and Jacob said, "I enjoyed using Izzy's design, it was slightly different to mine." Great job, well done, everyone.

You have worked so hard today.

Let's summarise our learning.

Designs can be used to plan a programme.

A clear design makes it easier to identify which blocks to use and how the programme should be organised.

Programmes can be compared against their initial designs to check if everything works as it should.

Comparing the code to the plan helps identify any parts that need adjustment.

Debugging can be approached in several different ways.

Common strategies include isolating parts of the programme to test individually and substituting blocks of code to find and fix errors.

Well done everyone.

You have worked really hard.

I hope to learn with you again soon.