Hi. 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 thirty-two 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.
As a teacher I often waver between two approaches to unit challenges: 1) to narrowly define the scope of the challenge, so all students work on very similar projects and 2) to leave a challenge wide open so that students get to choose how they want to approach it. The first method allows me to more easily teach and assess specific concepts and the final project usually contains my desired outcomes. As a drawback, when students are given a narrowly defined challenge, there’s little free choice and therefore not a lot of buy-in. The second method increases student buy-in by allowing them free choice. It makes my job as a teacher harder because often times great projects will stray away from the main concept I want them to use; but of course I am loathe to shut down anything I see students engaged in, proud of, and working hard on.
Sometimes I find that sweet spot that combines the two approaches. That is how my sensor unit morphed into the Candy Sorter Challenge.
For this challenge I would start out with some basic information about sensors and a simple obstacle course challenge on my classroom tables.
You can see this team almost made it. This challenge has them use the ultrasonic sensor to sense the cup, the color sensor to stop on the green line at the end and also to sense the black lines and edge of table in reflective mode, and the gyro sensor to try to make 90 degree turns.
This next video illustrates my favorite mantra when working with sensors: Do Something, Sense Something, Do Something Else. Students often forget the last part when using sensors.
This next team made a common mistake. Either they turned because they used greater than their threshold instead of less than the reflective light of the white table or they told the wrong motors to move given what ports their motors were plugged into.
Some students like to add flair, like this group here that played a little music as their robot moved along:
After each group has completed the obstacle course, I used to provide this challenge: Build and program a robot that uses its sensors to accomplish a specific task. A pretty open ended challenge that allows for a lot of interpretation and a variety of projects. From my motivated students I received some really cool projects like these:
And while the above project copied a build supplied by LEGO Education, they at least designed the challenge themselves and solved it. I love how they use the touch sensor to tell the robot when to sense the color, thus negating poor readings by not having the color sensor in the right place.
I did however get a few projects that really didn’t go that extra step that I’ve come to expect or at least hope for from most of my students. While these projects weren’t bad, and some required some difficult work in programming, building, or set-up, they didn’t really get at the heart of using sensors at the level I was hoping for. Two examples below:
The two examples above show a robot that uses an ultrasonic sensor to detect objects and then picks them up, and the bottom one only uses the color sensor to determine what position the arm is in based on the location of that white beam that is sticking up. Neither of these rose to the level of complexity that I was hoping for, but they both were passable given the open-ended way I phrased my challenge.
So again I was stuck with how to leave the challenge open-ended, make it interesting to get buy-in, but also make sure the students use the sensors at some level of sophistication. Part of the problem is in defining what I mean by “use the sensors at some level of sophistication.” And I’ll admit to you that sometimes I’m not sure what I mean by that because life is life and nothing is ever as planned out or fully realized as I would like it to be the first time around. So upon reflection what I was really looking for was for the use of a switch and multiple actions by a robot based upon multiple conditions read by a sensor.
And the way I found to do this was to have my students build color candy sorting machines. Give a 13 year old a bag of colored gumballs and you’ve got them hooked! I had seen these machines on youtube before, but had never done the challenge in my class. But when I tried it, it was like magic. Each group of students came up with their own method of sorting, so I was able to see multiple solutions for the same challenge, which is one of my goals. I did have some students that altered the challenge to separate the “warm” and “cool” colors – red, yellow, orange, versus green, blue. While this didn’t require multiple conditions, I gave full credit the first time a group came up with this.
Before I show you some examples here’s some technical notes on this challenge.
- I use large gum balls, which I buy from a local store. There’s many different colored candy you can use, but these seem to do the job. They’re distinct colors, and can be conveyed easily by LEGO technic pieces.
- I hand out the gum balls in a plastic bag. Each group gets two of each color and no replacements. This stops them from eating any (usually).
- I pair two teams together for this challenge (4 students total). I find that they need more motors and some use two bricks with bluetooth communication between them.
- For grading I give full marks (A) to any team that successfully sorts five colors consistently. I give a B for students that only get a few colors, or use reflective light to sort into two categories only, or build a machine that is not consistently accurate. I give a C for a good idea that is not executed well, and Incomplete for students who don’t try or turn in junk, which rarely happens.
- Here is a slide show I use with my students. It exposes them to the project, has them examine some existing candy sorters, teaches them how to use the color sensor and how to program switches. It doesn’t provide them with full solutions, but does provide a good starting point.
This first video shows a static drop, with a moving sorter. The sorter uses a rack and pinion to move it. On the bottom of the sorter they placed four castor wheels to add some smooth movement.
I had them test different parts of this machine as they were building it.
This next one uses 3 motors operating gates (and a fourth option if all motors remain open) to separate four colors.
Another approach used by a team was a sort of vehicle that moved back and forth.
Finally this next team really knocked it out of the park, building a well oiled machine with two conveyor belts that smoothly moved the gum balls into separate containers.
And next are two of the sorters that sorted the warm and cool colors:
I had the students make their own videos about these projects and I was pleasantly surprised by the results.
To summarize, the candy sorter machines gave me almost universal buy-in with my students. They allowed for multiple solutions for one problem and required reading a sensor in multiple conditions and using a switch to program the robot to respond to those conditions. If you try this with your class, please provide links to videos, I’d love to see what your students come up with.
As always I welcome comments, questions, and critiques.
- Using Switches to program a Candy Sorter (PPTX, 3MB)
A Week in the Life
Ian Chow-Miller covers the highs and lows of his introductory robotics class for 7th graders over the course of a single trimester.
- A Week in the Life #9: Walk This Way…
- A Week in the Life #10: Candy Sorter
- A Week in the Life #11: Sumobot to Battlebot