Archive for January 19th, 2010
HELP: If anyone has good NXT plans or links for a walking robot or a dog, or any other plans I can use for this class, I would really appreciate an email. Use the Contact Me or post a comment. Thanks.
A quick update and then a bit of a review. We purchased 12 Lego NXT robot kits for the classes. I was at first concerned that each class needed their own robots – not a problem. We pre-built the robot that the classes are using. Sharing robots has not been an issue, but we aren’t making major changes to the robots either. Basically, as we move along, another sensor is added and stays added. Students have not been in the parts bins and I like that. The kids work in groups of two and have one computer per robot.
The kits were missing some pieces, Lego is great about sending them out without a hassle. There are two different “Taskbots” described; one in the paper manual you get with the kit, the other in the Carnegie Mellon University (CMU) Robotics curriculum. I found out the hard way, you should make the CMU Taskbot, not the Lego Taskbot if you are using CMU classroom software. It took 30-45 minutes per robot to build them from scratch.
I started off using the CMU projects and worksheets as included in the software. After a week, I had about eight hundred pages to grade and the kids were spending more time answering questions than programming. Some were getting bored. I’m still not unburied.
I dropped the worksheets, they just were getting in the way, and to be honest, they were very repetitive. Instead, I had my students follow the lesson in the lesson video (which is very well done) and when they were finished, I had an additional programming assignment they had to complete. I came up with a shorthand programming language so they could quickly copy the program onto paper. At the basic level, there is an icon based programming language that is very user friendly, but hard to document. Their assignments had to be accurately documented so that I could re-create their program. Many of them can’t seem to get that concept, but they will, it’s on the midterm next week.
Some things that helped:
- Number the robots and kits with a Sharpie. That way you can keep sensors and parts together. Like I said, students haven’t been in the kits, so everything is in good shape 3 weeks into the lessons. Each robot behaves slightly differently, the sensors and motors are not exactly alike, so fine tuning programs works better when you keep coming back to the same robot.
- The software has “profiles” for different classes to use the software. Unfortunately, profiles aren’t password protected. There was some problems with students checking out the work from another class. This is hard to catch and is a real pain. If you can have classroom accounts for each class, you would be in better shape. I didn’t have that luxury this year.
- I pay attention each day to who is out, working hard, and hardly working. Part of their grade is an effort grade, a daily log give me a better sense of history.
What worked and what didn’t:
- The first couple lessons were how to move forward and backward. Again, paperwork went slow, but the lesson was a good one because sensors count up and back. If you move forward 2 rotations and want to move back 2 rotations, the sensors have to move back to zero then back to negative 2. So learning how the rotation sensors worked was important.
- At the end of the lesson, I always suggested the students play with the robot enough to teach me something. They learned to add sounds, speech, pictures to the screen, and a few other tricks early on. I encouraged playing and didn’t hassle them as long as they were busy.
- The turning lessons were tedious. It didn’t help that my students can’t get the concept of diameter of the wheel being related to the distance the wheel turns in a single rotation. It wasn’t a bad lesson, my kids are horrible at math. When they finished the turning work (including too much paperwork), I told them they had to teach the robot to do a Figure-8. It took some of them more than two classes to make that happen. I put an “X” on the floor using electrical tape. It was the starting point and they had to end up somewhere near there when they ended. That was a good addition.
- Next up was the sound sensor. The software walked them through “Clap-on, Clap-Off” where a single clap starts and stops the robot. It went on to teach about programming loops as well. My addition (from the software), one clap on, two claps off. They had to turn in a written program to get credit.
- For each added assignment, I created a demo program so they had an idea what I was looking for. I tended to add lots of flash and silliness to my programs. For instance, for the “Clap-On, Clap-Off” program, it would start with Hello. After one clap, it would say “Green Light” and start moving. After two claps, it would stop and say “Red Light.” It would then pause, spin in place 3 times while screaming, stop and say “Sorry,” then start over again.
- This week was “Follow the Line.” This is a great lesson that appears harder than it is. Using the light sensor, you stay either to the right or left of a thick line made from electrical tape. The robot works but crawls. My addition was for them to get creative and try to make it go faster. I put down two paths using tape, we used one as the race track. Using the original program, a robot takes about 3 minutes to do the loop. The battle has been intense, the first record was set at about 26.7 seconds, today someone did it in 19.5 second. The track is kind of like a go-cart track, mostly oval but with an extra indented curve that makes this quite challenging.
- CMU’s fix to the original slow line tracker is to move the sensor closer to the wheels and go in reverse, but my students blew that away with their creative programming using the original plan. I like my way better.
Next is touch sensing and using infrared sensors to detect objects. Unfortunately, that won’t be for two weeks, we need to start reviewing for midterms, they are next week. Expect part two in about a month.