There’s not much that can compare with the joy students get when they build and program a robot. I’m currently using 2 platforms — the Dash robot from Wonder Workshop, and NXT LEGO Mindstorms. I use the Dash in 5th grade, and the NXT in 7th grade.
What’s the attraction with robots? Well, they can move, make noises, and respond to their environment. What’s cooler than that? Not only that, but we can make them do what we want them to do, so they can become our own little minions!
The secret sauce of robotics is that we can actually watch the results of our code manifest right in front of us! We know right away if the code is right or wrong, so there’s immediate feedback. I always tell students that it’s not like other classes, where they take a quiz or test and have to wait for their teacher to grade them and get them back to you. You know right away! Not only that, but then you can modify your code and run it again. And you can do it as many times as you like in order to get it right. Yes, there’s frustration along the way when your robot doesn’t do what you want, but oh the joy when it does! Happy dance time!
Along the way, students learn something really important about robots — they’re kind of dumb. They can only do exactly what we tell them. They can’t figure out what we mean. We humans can “fill in the blanks” when others try to communicate something with us. We can infer meaning. Robots can’t, at least not yet! So that means we have to be super careful about all the instructions we give them. Welcome to computer science! As a side note, what a great training ground for middle schoolers who have organizational challenges and need to pay attention to detail! And I always tell them when they complain about how their robot is “dumb”, they’re only as smart as the instructions we give them! Ouch.
What about how many students per robot? I realize there is a range of opinion on this, and I get the importance of collaboration. However, I’m a big believer in each student having her own technology, if at all possible. There’s something to be gained from knowing that the success or failure of your robot rests entirely on you! But that may not be feasible in your situation. So work with whatever you have, but be sure that all members of the teams take ownership of the robot’s success and share the challenges as equally as possible.
So how to structure a robotics unit? My approach is to have the robots simulate a real-world series of tasks. In 5th grade, with the Dash robots, we are currently doing the “Robot Olympics”. Most of these challenges mirror Olympic events, but I’ve also taken the liberty to make up my own events. I made a 3X3 grid on the floor with duct tape or gaffer tape, which is where the events take place. Right now I’ve got Olympic tic-tac-toe, diagonal racing, curling (well, kind of), and whatever else inspires me. Teams compete and I keep a scoreboard on my whiteboard to let teams know how they’re doing. Because the Dash robots come pre-built, it’s really a matter of coding. Wonder Workshop provides 3 different platforms for coding Dash (and Dot, his less useful sidekick), and I use Blockly in 5th grade. It’s Scratch-like and fairly easy to do the dragging and dropping, making the coding the harder work. Students generally are fully engaged and love the competition. Since this is my first year of using Dash, I fully expect to build this out further. Wonder Workshop has all kinds of challenges on their site which I have yet to explore, so I anticipate continued success with this platform.
In 7th grade, I use the NXT LEGO Mindstorms platform. I realize that the EV3 has replaced the NXT, but I honestly have not seen enough compelling change in the new platform to convince me to do a wholesale switch. At some point it will happen, as the NXT bricks get harder and harder to find, but for now we’re good.
I have each student build the basic Tribot model, then add sensors as needed. I use the ultrasonic sensor first, then mix in challenges with the touch and light sensors. The sound sensor is less useful for my purposes, possibly because of the volume level of my classes (did I mention that it can get loud?). So I hardly ever use the sound sensor.
In my current iteration of challenges, I model them all after a real-life robot used in hospitals around the world called the TUG robot (built by Atheon). This robot can navigate through the hospital autonomously, avoiding obstacles and making deliveries. It can even call an elevator and choose which floor to exit at! My challenges model some of these functions. I chose the medical robot for a variety of reasons, not least of which is that it’s involved in helping people in a real way.
Some students find the building of the robot challenging, though I give them official LEGO building instructions printed out in official LEGO language (all pictures). Some students have spent much of their childhood playing with LEGO’s and are already “master builders”. Some have never connected any LEGO’s at all. Again, attention to detail is paramount. I tell them to make sure they double and triple check each part of the build, hold their robot up to the paper and be sure everything is correct. Why? In robot building, attention to detail is crucial, and if you find on step 22 that something’s wrong, you’ll have to “unbuild” your robot back to the point where you made the mistake, even if that’s on step 5! Ouch. Hard fun again.
So what does this look like in class? To be honest, sometimes it looks like complete pandemonium. Learning is messy. In one corner of the room, there are students moving a trash can in front of their robot, simulating a moving obstacle in a hospital hallway and trying to get their robot around it. In another corner, one student is helping another rebuild their robot so it works(though they have to follow my rule: don’t touch the other person’s bot!). In another corner, students are getting a mini-lesson from me on how to navigate the software and download it to the robot. On the board, I have my Help List, which determines in what order I answer questions. When students have tested their robot and know they have it working right on a particular challenge, they put their names on the Help List and excitedly demonstrate their bot meeting the challenge (or not. Sometimes it still doesn’t work, and they are back to coding and running the robot again, with some modifications on either the code or the bot). At another workstation, one student is helping another student with the code (again, following Mr I’s rule — don’t touch their keyboard or mouse), pointing to the screen and showing where their mistake is. 2 people are going through the bins in one corner of the room to find that special LEGO piece they’re missing, holding it up against the printout to make sure that axle’s the right size…
You get the picture.
What am I doing all this time? Trying to keep one eye on the Help List on the board, letting kids know they’re next for my help, circulating through the room, fending off questioners who want to skip the HelpList, listening and watching for frustration (not always a bad thing!), nabbing the odd student who isn’t focusing and getting him refocused, checking the clock so I don’t forget to give the 5-minute warning (time to clean up! LEGO sweep at your feet! turn off your robot and put it in the closet! hang up your programming cable and restart your computer!)… every class is a trip.
I wouldn’t have it any other way.