As much as I would have loved to have been in Melbourne all week for ACEC 2010, it just wasn’t on the cards for me. A pity, because it sounded like there was a lot of really interesting sessions to attend, and one that particularly caught my eye was the Lego Robotics one with Chris Rogers, a professor of engineering from the Centre for Engineering, Education and Outreach at Tufts University in Boston. I’ve been a Lego fanboy for a long time, and have worked with kids to do some pretty awesome stuff with it over the years, but unfortunately my current school doesn’t really do very much with Lego. (In fact, computer programming in general gets a pretty rough deal at PLC, something that I’d really like to see change)
However, we do run a Computer Club every week in our junior school and we’ve decided that we will introduce programming to these kids to start with. We’ve begun by getting them going with Scratch, with a plan to get some Lego Robotics gear and maybe even try to put a team in RoboCup. The kids – mainly Year 5 – have really taken to Scratch and are starting to do some very cool things with it. We also have plans to do something for Scratch Day this year as well.
But back to Lego. Just before school finished for Easter I received an email saying that Chris Rogers would be running a 2 hour Lego workshop at Sydney’s Macquarie Uni. Because I couldn’t get to Melbourne for the first few days of ACEC, naturally I jumped at the chance to do this one in Sydney with him, even if it was on Easter Monday!
I was really impressed with what Chris got us to do; it was an excellent example of just how the open ended nature of Lego can cover so many angles of our existing curriculum in a spirit of real constructivist, collaborative learning. Working in pairs, Chris started us off with a very simple non-robotic building project – each team of two people had a small bag of Lego bits on the table in front of them, and our job was to open it and construct the tallest tower we could out of those parts. Just to make it interesting, we only had about 5 minutes to do it and we had to limit ourselves to only using only our non-dominant hand! Of course, this made teamwork and communication very important. At the end of 5 minutes, he stopped us and asked us to look around at what we and the others had done. Important lesson 1: everybody built something quite different and clearly demonstrated that there is often no single “right” way to complete a task. Important lesson 2: You learn far more from failure than success, and the process of “fixing your mistakes” is where the true learning happens.
With that small but important introductory exercise done, our next task was to take the Lego NXT controller brick and, using another limited set of parts, build a “car”, or at least something that had motorised wheels and could drive in a forward direction. (Also worth noting that no two “cars” were the same either. Everyone took a different approach, yet everyone made something that did what it needed to do. I think there is a hugely significant lesson for educators contained in just that simple idea!)
Once our car was built, Chris showed how to create a very simple NXT-G program that simply ran both motors for 1 second in order to drive the car forward. That’s it. It took him no longer than 30 seconds to “instruct” us. Now that we had a car and knew how to make it move forward for 1 second, he told us what we had to do…
On the floor was a “starting line” made of masking tape, and a long ruler to measure distance. We were to program our “car” to travel for 1 second and then accurately measure how far that 1 second would make our car go. The we were to modify the program to run for 2 seconds, and measure how far that took us. Then modify for 3 seconds, measure, and so on. He gave us about 30 minutes to build our car, write the program and then do all of our testing to establish how far our cars would travel for various motor-on timings. At the end of that time, he said, we would be given a specific distance and we would have to figure out, from the data we’d collected using our car, how long we had to run our motors for in order to stop exactly at that distance. To make it interesting, we would place a little Lego Person at the specified distance and our cars were to just “kiss” them – not stop short, and not run them over.
The excitement and buzz in the room as people built and tested their models was quite palpable. And people took it really seriously too! There was some real competition to get it right on the mark.
As we worked through the process, we had to address a number of really valuable learnings and skills. Building the model required some engineering and science skills, and of course a whole lot of teamwork and cooperation skills too. Measuring the distances taught us to be accurate, to learn how to collect data in a consistent repeatable way, how to measure and record distances. As we worked, we had to think about the best ways to record the data. This got us using valuable mathematical concepts including the creation of a graph (which turned out to be a fairly linear graph – a great discussion starter for a maths lesson) Overall, it was amazing just how broad and deep the learning was, and how we had to construct our own knowledge as we completed the task.
Once the target distance was announced, a second masking tape finishing line was put on the floor. People furiously calculated the required motor-run timing that they needed to program into their cars in order to stop exactly on the line, and the models were lined up. On the starters orders we all pressed out Go buttons and tested our theories and our calculations. It was a lot of fun and had so much embedded learning in it!
Some of the important reflections for me was a reminder of just how powerful learning can be when it is open-ended and focuses on the creation of a solution to an interesting and engaging problem. It also struck me that a problem does not need to be particularly complicated in order to embed some really rich learning. And finally, it was a great reminder that the creation of rich tasks – whether they are based on the use of technology or not – are not an “add on” to what happens in a classroom. We need to remind ourselves that it’s not about “covering the curriculum” and then hoping there is enough time left over to do some interesting projects. Getting students working on interesting projects should be the primary way in which we get them to cover the curriculum in the first place.