STOMP at Google - Mentorship Program at Bishop Elementary

Glenn Trewitt, Google Engineer

This page, although relevant, is not being actively maintained. You may want to visit our blog - http://google-lego-engineering.blogspot.com/.

This page contains information for teachers, administrators, and volunteers participating in the Student Teacher Outreach Mentorship Program (STOMP) program at Bishop. There is a separate page <TBD> for Bishop parents. You can get a flavor of what goes on in a STOMP classroom by reading a Tufts Journal article about it - it includes a video.

We will be launching the pilot program at Bishop in the Fall of 2009. The program will kick off on Monday, August 24 with a LEGO Engineering Conference at Google in Mountain View. We'll start teaching in the classroom on September 9.

The official STOMP site at Tufts gives general information about the program, but isn't specifically targeted at a school+industry program. In particular, the materials describe the volunteer students from Tufts. The Google/Bishop program's volunteers are, of course, engineers from Google. This site will provide you with information about our program.

Overview of the Bishop/Google STOMP Program

The initial program at Bishop is a pilot, involving the three fifth-grade classrooms, each with 30-32 students (32 is the maximum class size). Two or three Google engineer mentors will partner with each class (and teacher). Each set of mentors will come to Bishop once a week and spend 90 minutes with their class. The students will work in pairs, with different pairings each week. We have a special room set aside for the LEGO Engineering activities, with the following equipment:

    • 16 double desks

    • 16 LEGO Mindstorms NXT sets.

    • 16 laptops with the NXT-G software installed.

    • A video projector with document camera.

The Mindstorms sets will, of course, be shared among the classrooms. That means, unfortunately, that the kids' constructions will have to be taken apart at the end of each session. And, because the students will be paired differently each time, there also won't be much point in saving programs from one class to another. These apparent drawbacks are actually advantages for us - at least for the first couple of months. I've worked with FIRST Lego League teams, and one of the most difficult issues is that kids of this age will develop terribly strong attachments to their robot or program designs. There are two issues. First, it's hard to build a robot or program that comes close to doing what you want. Second, and more important, is that kids this age have a hard time imagining that it would be possible to build a better robot/program than they did. As engineers, I'm sure we've all seen or experienced unwarranted attachment to our designs. Starting from scratch each time will build familiarity with the tools and will get them used to negotiation and compromise with their partner. For the first few sessions, we'll all use the same robot, and the programs will be pretty simple.

The class time will be structured something like this:

    • Review previous related work, if applicable.

    • Introduce the activity:

      • A "hook" to get them interested - show/describe a real-world situation that motivates the activity.

      • Describe the challenge.

      • Describe the schedule.

    • During the work time, we'll do one or more of the following, as appropriate to the activity:

      • Most early activities will expand the student's building or programming "toolbox".

        • Introduce any new sensors or techniques for building or programming.

      • As a group, brainstorm approaches to the problem.

      • We will - intentionally - not pre-answer all possible questions. When students ask questions, we will do one of several things, depending upon the "teachability" of the question.

        • If the question is something that everybody needs to know, reward the students who asked it - "Hey everybody, Mike and Julia asked a great question..."

        • There are some questions that the students (either a pair or the whole class) should be able to figure out, or at least usefully think about. Take that as an opportunity to brainstorm and let them come up with solutions.

        • Of course, some questions just need an answer, like how to operate the robot.

      • Student pairs will work on the problem.

    • Finishing up - demos, review and and analysis. Again, some selection from the following:

      • If appropriate, students will show off their solutions.

      • As a class, discuss the common design challenges that they faced and how they solved them.

      • Have (some) student pairs describe their solution, what they thought was good about it, what problems they overcame, and how they think it could be "better". The last is important - they need to learn to critique their own work (without embarrassment) and keep an open mind. Examples: "the robot turns a little, even though we programmed it to go straight"; "when the robot stops, it keeps going forward a little, so the distance isn't accurate"; "there's got to be a better way to attach that sensor, but we couldn't figure it out". They'll find that many other kids had the same problems.

    • Clean up. Robots and parts back where they belong; laptops back in the cart.

The teachers will not have a direct role in the preparation or presentation of the week's activity. However, they will be observing and helping:

    • Observe the activity and connect the science and math elements back to the regular classroom curriculum.

    • Keep track of which students might need extra help.

    • At some pace, learn how everything works - to eventually do it all themselves.

Assuming that the pilot goes well and after we've gained some experience, we'll consider expanding down to the fourth grade.

Information for Teachers

Tufts has put together a comprehensive Teacher's Manual (PDF) for teachers. This does not include any information about building or programming LEGO robots.

Information for Fellows (Google Volunteers)

Tufts has an I-STOMP Fellow's Manual (PDF) is specifically targeted to the industrial-STOMP program. The first half of the manual contains valuable information and examples about the classroom environment, how STOMP fits into it, and the partnership between you and the teacher. This is really valuable stuff - if you're like most engineers, you probably haven't thought much about how grade-school teachers do their jobs and organize their days. Trust me, it's nothing at all like being a teaching assistant at college. The second half of the manual covers programming techniques and troublshooting tips for the NXT programming environment - NXT-G.