*STOMPers: *Pami Anderson, Samir Chowdhury
Teacher: Josh Wairi
Semester Overview: Coming back from a successful semester doing a service learning curriculum, we set ourselves the goal of implementing an NXT curriculum this Spring. After talking to Mr. Wairi, we learned that the students already had a good deal of experience building with NXTs. This allowed us to diverge from the usual NXT building activities and set up a more open-ended curriculum.
The main idea behind this curriculum was to work on large-scale design projects where students "learn as they go," instead of trying to teach a standard set of lessons to everyone. So instead of having everyone do short, 1-hour activities where they work with a touch sensor one day and an ultrasonic sensor the next, we tried to create a slower-paced atmosphere where students first decide which "functions" they want to include in their design project, and learn about the specific sensors/programming concepts which help them achieve those functions. Ideally, structuring the semester around a specific end goal would provide more motivation in learning about the NXTs.
We set about choosing a design project in the following way: at the end of the second week, we showed them a few Youtube videos of Rube Goldberg machines, as well as one of a LEGO amusement park. In the next class, Josh asked all the students to brainstorm possible design projects. One idea that came up was a LEGO Mini-Golf course, and this became very popular with the class. It was decided that the 10 pairs would each create a different mini-golf course with a unique theme (e.g. Monsters, Celebrities).
As of 3/14, the main issues we have had to (or still need to) address are:
- Ensuring that students implement sensors and motors in their design, so as to embed a concrete engineering component in their work
- Teaching basic Mindstorms programming concepts (especially the Wait For and Loop blocks) well enough that students can confidently program their own NXTs
- Ideally, we will be able to teach the students about the Switch block as well. Not too many students will use it, but we can give targeted lessons to the students who seem interested in it.
Week 1: Build your favorite animal (great way to see how good the students are with building)
Week 2: Build your favorite animal continued. We made sure that everyone presented their animal to the whole class. Having this goal ensured that students remained focused on their work (we probably have video footage of one of the students voicing this exact opinion). After the presentation, we saw the Youtube videos referred to above.
Week 3: Brainstorm possible design projects
Week 4-5: Start building the mini-golf course. Some groups also received a primer on programming.
Week 6-10: More building/programming, final presentation
- Large base plates (you can find them in the CEEO back wall)
- Long beams (also available in the back wall)
As of today, we are still working on completing the mini-golf course. About three of the groups feel like they have finished, five of the groups are on track to finish by the deadline, and two will probably need more help. Here are some issues we're having at the moment:
- Certain groups could be working on more complex projects, but they aren't. Perhaps due to "fear of failure"?
- Groups are still having trouble with programming - they seem to understand it when we give them explanations, but they don't produce working programs on their own.
Complications down the road:
- Pushing groups to improve their design after they feel they are "done"
- Some groups have great ideas which are very hard to implement. Does "narrowing the scope" work better?
Pertinent Observations (4/23/20120)
- Providing each pair with two base plates instead of one seems to be a really good idea. It gives them more room to build, and makes the designs look far more elegant. In the next iteration of this unit, it might be a good idea to give them multiple base plates right when they start building. (Food for thought: what's the "upper limit" on the number of base plates we could/should provide?)
- Next weekend, we'll take videos of all the groups as they display their projects. They've been working on this the whole semester, and keeping a record of their achievements is very, very important (both to them and us).
- There are several groups for whom we did the bulk of the programming. Whether or not this is a good idea is debatable. Ideally, we would want the students to do their own programming, but when they hit a wall, we have two choices: 1) try and teach them how to program, and 2) write most of their program, eliciting their input in each step. Choice 2 is a quick way of getting the students re-energized about their project, because once we remove the programming roadblock, they become free to come up with new ideas and embellishments. Of course, choice 1 is still the ideal one, but it doesn't always work well with the time constraints we typically have in STOMP.
- Programming difficulties: one group had a beautiful idea which would end up as a programming nightmare. Unless you're the Zen Master of Mindstorms programming, it would probably be ill-advised to write a program involving multiple switch blocks while other groups are constantly calling you from all the way across the room. In this case, we decided to simplify form, while maintaining function.