What has been happening with my Little Coders? Well, we have been building bridges! A little step into STEM, sort of, though not based on a real life purpose but working to a set criteria. We have once again challenged ourselves and learnt a lot along the way.

Like most of us who are learning as we go, we made mistakes along the way and one mistake was a whopper! So here is how to do it or not, and suggestions on what I would do should I endeavour to teach this project again.

My initial goal was to create a project for the students which was more hands on and gave students the opportunity to delve into Design and Technology, STEM (in particular Math and Engineering), plus expand their knowledge and skills on using the Ozobots (for Digital Technology). A word of warning, it took the whole term! If you are a classroom teacher definitely integrate the project into your other learning areas, if you are a specialist teacher consider negotiating with other teachers (in the learning areas covered) and work collaboratively on the project.

The plan was to have students design and create a track for the Ozobots to travel, the track needed to incorporate a bridge. Sounds simple, doesn’t it? Yes, that is what I thought. How hard can it be getting two dozen Year 2/3 students to make a track? They’ll have fun cutting, gluing, constructing and evaluating their work as they create. They’ll be immersed in Math without realising it. A lot of critical thinking will be required and we will be building capacity and perseverance. It will be great and it was, almost every student was engaged, students who normally struggle academically worked tirelessly to complete their tracks and demonstrated their creative skills. Our more advanced students delved into higher level bridge building and set themselves challenges, and only one student did not complete their track in the timeframe.

So, how did we start? We began by discussing the project together and as a class, we set the basic criteria.

• What the minimum length of the track could be?
• What materials we could use and what was available to us?
• What did we need to consider regarding the Ozobot? Suitable surface awareness for traversing the track.
• What type of bridges could we make? What materials would be suitable?
• How do we set out our track, in relation to the Ozoblockly codes available? The degrees and movements which Ozobot can travel. Can we make curved tracks?

We then began designing our tracks and bridges. Once students had drawn up both their track design and bridge design we got into the hard stuff. We had used 1cm graph paper for our track design, we then needed to work out how to scale up our design to meet the needs of our Ozobots. How wide must the track be? How big would a 1cm block need to scale up to? This linked in well with arrays which they had been learning in Math. Most students chose to scale up to 5 x 5, some went with 5 x 6.

Then we had the challenge of using a ruler to measure and draw our track blocks onto graph paper. This was a surprise to me, very few had any idea how to measure and rule accurately. I had intentionally decided to use the graph paper to make it easier and quicker for students but even then we were challenged, it required explicit teaching (several times over). Once students understood the process and the most effective and quickest way to rule up the paper they quickly got into production mode, cutting long strips of 5cm wide graph paper.

The students then began glueing their track onto the cardboard base. They needed to refer back to their original design as they worked, making sure they identified the starting point and the direction. It is important at this stage that you remind/teach students about left and right. I get the students to physically move when checking which direction they need to glue the track. Have them face the start direction and follow the turns by changing the direction they are facing with each turn. A lot of arm waving and jumping is involved along the way, we could direct flight traffic!

After several lessons, they had their tracks glued down and we got started on our bridges. It was at this stage that we realised bridges are designed to go over something and most students chose to add a blue paper river to their track.

The students had chosen a selection of materials to build their bridges and some changed their initial selection along the way as they discovered some materials were not suitable or there were construction problems during the making process. Several students hooked onto the successful ideas of others and completely changed both their bridge design and the materials used.

Once our tracks were completed the students began their initial programming challenge by creating the sequence required (for the Ozobot to traverse their track) on paper. To make it quicker and easier to scribe our sequence we use a few symbols and abbreviations. I always feel a little mean doing this, making them write it out by hand, but it makes them really think about which codes they will need to use when they get to the block coding stage. It also makes it easier for them to use as a reference when creating their sequence on the computer and helps them identify any errors. What have I missed out? Did I select the correct direction (degree) code?

 

The first step, in order to write down our sequence, is to work out how far is an Ozobot step? I have them run a test on a piece of graph paper and turn this into an Ozobot ruler (10 Ozobot steps). They can then use the ruler to mark the distance Ozobot travels (10 Ozobot steps) and calculate the number of steps they need to include in their sequence for each straight length of the track. *Note: I use 10 Ozobot steps as most students know their 10 times tables and can count by tens. When a length of the track goes over, for example, 48, they use the ruler to mark to 40 and then use the ruler to estimate how many more steps to the centre of the last block in that track section (this is the corner block where they then include a turn/degree code).

When the students finish their written sequence, we look at it together, comparing it with their track. I then sent them off to the computer lab to independently use the Ozoblockly software, create their code sequence and load the programme onto the Ozobot. Are you shocked? What? Independently? By themselves? Alone? Well, yes. This class has had two or three semesters (over two-three years) of using block coding software. There are a few students who are not as capable but the other students become the teachers and they support each other. Now, the why of how this happened. When we started the project we (the class) realised there was no way we could construct our tracks in the computer lab, there just wasn’t the room. Luckily, being the Visual Art specialist I had access to the art room and so we used this space for most of the term. It meant that it freed up the computer lab and I happily let another class use it in that time frame. When my students began to finish at different stages and needed access to a computer, I arranged with the other teacher to send them through to the computer lab and she was happy for them to be in the same space as her class. It wasn’t any burden to her as the students knew what to do.

It was a little crazy, however, I had students at all different stages of production and coding. I did have to move between both classrooms to support and check on progress. I had students moving back and forth between the computer lab to code and the art room to test run their program using the Ozobots. There were only a few minor BM issues as most students were excited about testing the robots on their track and eager to fix any errors and then celebrate any successes. Any staff passing the art room were ambushed by students and dragged into the room to witness what the students had achieved.

Now, here’s the kicker and what went wrong, big time! The error was completely my fault and I should have thought about the potential outcomes when planning the project. We did not have many successes 😦

Why? Well, Ozobots cannot handle traversing bridges! Most students did a great job creating the correct sequences to get the Ozobots to stay on track but when presented with a bridge the Ozobot would either stop completely or only move up and across the bridge for a very short distance. The reason being often the angle of the bridge was too steep for the Ozobot to traverse, and/or they are not designed for traversing bridges. Occasionally one would make it to the centre of a bridge (if it had been constructed at a suitable low angle) but then it would just slide down the other side…which created lots of laughs but was not the goal. No one really minded and there was lots of discussion on how we could make changes to the bridges and we hypothesised about why it might be happening. No one was disappointed (except me), we had all enjoyed the process and learnt a lot along the way but if we had had more time we would have experimented further and tried to solve the problem.

What I learnt from it:

• run some tests before you set the project (if you want success)

or

• go with the flow and learn together, the process can teach you and your students more than you expect.