This is the fourth of probably fourteen posts, each chronicling in detail the ins and outs of my Robotics class. I teach an introductory course using the LEGO Mindstorms EV3 set. My students are 7th graders who are required to take the course and may not necessarily have any background in programming/building. My school is on a trimester schedule so the course runs for thirteen weeks at a time. For this particular trimester I have one class of twenty-four students and one class of thirty-four students. I meet each class for one 50-minute period each day, five days a week. I have thirty-four computers in my classroom and one EV3 kit for every two students. I’ve been teaching this class in its current form for two years, though I’ve been teaching Robotics for eight all together.
Hi. When I left you last week my classes had started doing the Wave. Period 3 (the smaller class) had progressed further than period 4. But they both got it done this week with some time to spare.
This post will illustrate the thrill of victory and the agony of defeat on a small scale as it plays out. So many times the students think they are close only to realize one robot throws off the entire group – for a variety of reasons.
Here’s a few great examples:
Period 3 started their robots out first thing on Monday expecting to be close to done (as they were on Friday) only to realize they were a bit further away than they recalled.
After this run through they decided to adjust their speed, hoping that would calm things down a bit. Once they got things settled, they realized there were a number of smaller issues they needed to work on.
In the video above you see a classic problem. The middle robots have to travel further and therefore are more prone to drifting off a straight line. Students will often blame the operators of this robot (because that’s what students do) until you can get them to realize the middle robots have a tougher job. There are quite a few reasons why robots do not drive straight. The most ubiquitous reasons I’ve found are tires not seated in the rim, bent axles, wheels not evenly spaced apart from the center of the robots, and dirt on the caster wheel in the back (if they’re using the REM Bot or Riley Rover). If possible I like to let the students deduce the possible problems themselves, as this young engineer did in the video below:
Once their robots run as straight as possible they still run into problems where one robot running the wrong program, or an earlier version of the program, can make the entire endeavor unsuccessful.
We are getting towards the tiny details that make this project a success or not. It’s up to the teacher and their time constraints to decide if you want to help your class along or let them work out the details themselves. This latter method can get messy because, as you know, it’s hard to keep all students interested and actively involved in solving a problem, but the conversations you can have with them are worth it. Watch here:
The sound quality is not the best; I asked the students what the problem was and whether it was a mechanical or programmatic error. I had them discuss the answer for a short period of time and then I called on some students randomly. This gives them time to talk about their answer but also makes them all accountable for the information. Unfortunately I still have the old habit of looking for hands and by the third answer I’ve chosen a student whose hand is raised, rather than randomly calling on a student who might not be so confident or sure – and might need more help articulating their thoughts.
While my period 3 class was nearing completion, period 4 was having a difficult time getting it altogether in this second week of the Wave:
With seventeen robots the chance for failure was quite high, all it takes is one. It’s often difficult to remember which robot made which mistake after they all crash into each other. So one of the methods we tried was to only check five robots at a time. This made it a lot easier to isolate problems and fix them.
Eventually both periods got The Wave to work in a way that was satisfactory to them. This happened on Tuesday (per. 3) and Wednesday (per. 4) of the second week. As a teacher you have to decide how long you have for a particular project to go. With Robotics I find that I could go on and on forever with projects allowing students to choose their own paths and extensions and following their own ideas. That being said, with this series of blog posts I wanted to try and keep my projects to one or two week blocks (I failed, but more on that later).
In this case after my classes were done with the Wave, I let them choose their own project to work on using the skills they’ve learned. With the caveat that they have only until the end of the week to finish whatever they start.
Period 4 had a nice idea to turn their project into 3 smaller Waves all facing each other. This was simple enough to finish in two and a half days as they could re-use most of their code.
Period 3 got together on my whiteboard tables in order to plan out and discuss their ideas.
They broke into two groups and came up with two separate ideas. While these groups were small and easy to manage, they spent a great deal of time planning and not enough executing. One group was successful and one was not. This happens often and it’s okay. It’s all part of the learning process and it’s important to allow the students to fail sometimes. As long as you discuss with them what went right, what went wrong, and what they may want to try and do differently the next time.
As I stated at the top, this is the fourth of 14 weekly class posts. I’d appreciate any questions, comments, ideas, strategies, etc. that you may have to help me and all the other Robotics teachers out there improve our pedagogy. Thanks!
Here’s some bonus videos from this week:
Latest posts by Ian Chow-Miller (see all)
- Using Video to Assess Robotics Students - 21 November 2018
- A Week in the Life #12: Dr. E’s Challenges – Robot Monsters! - 9 February 2017
- A Week in the Life #11: Sumobot to Battlebot - 28 June 2016