Target audience: Grades 6-7 Focus: Early programming skills (processing input, basic control structures, executing commands)


Did you know that we're moving closer to the day when cars could drive themselves? This is done when a computer is able to follow programmed instructions (although programs can "learn" to a certain extent too) and use those instructions to react to changes read from sensors (like cameras, radar, motion detectors, or even light sensors).

We already have cars that can change their speed based on what the traffic in front of them does. There are lots of names for this technology, one of which is adaptive cruise control. The basic idea is that the car figures out how fast the traffic directly in front is traveling. When the traffic slows down, the car can sense the change and slow down to keep the same distance :

From mindstorms

Automatic Cruise Control

Computers have been inside cars for a long time now, keeping track of how far we've gone, or keeping track of where the car might have a problem. Cars are about to start getting computers that we can use directly (instead of just our mechanics):

Technology's next frontier: In-car computing

You're trying to get a contract with a company that wants to make a true auto-mobile. A car that can drive itself. This will require a lot of effort. There are some pretty smart folks at MIT who have been working on this problem too:

Problem Statement

Taking on the whole task (detecting other vehicles, breaking for pedestrians, etc . . . ) is a little too ambitious, especially since you haven't gotten the contract and the money yet. Your goal for now is to do what's called a "proof of concept." This lets the company know that you are headed in the right direction, and that you can do the kind of work that will be required. For now, you've decided that your best proof of concept will be to a car that can follow the road, using a set of instructions and reacting to the environment. for this proof of concept you will replace a car with a roverbot, and the road will be the black oval track that goes around the border of your test surface. The materials required for this proof of concept only cost about $200. This is expensive, but far less that using an actual car and road (especially in the event of an accident)!


Split your group into the following roles, you should all participate in each phase of the work, but one of you will take on primary responsibility in each area:

  • Project lead - The lead is responsible for the project as a whole. Since your job is the bigger picture keep asking the high level questions. "How will this help us achieve our goal? What do we already know? What information/skills do we need? Where could we go to get them? Is this the best way to use our time?"
  • Lead programmer - The programmer has to provide instructions to the robot, and download them via the infra-red tower that is provided. Keep in mind that small steps are much better than giant leaps get a small part of your program working (like moving the robot) before revising and expanding on it.
  • Lead debugger - The debugger works closely with the programmer to assess unexpected behaviors. Watch the robot itself rather than paying attention to the program. The programmer is going to be caught up in what he/she expects the robot to do, and when that doesn't happen might have a hard time figuring out why. Ask the programmer what they expect to have happen when they test a program, then watch the robot closely. It might turn in the opposite direction, might fail to turn when it runs off the road. Think to y ourself (without looking at the program) what the robot is doing, what the real instructions are. Then convey that to the programmer. Chances are good you will think of something the programmer has missed. Spend some time thinking about how the program might "break" and run a test to see if you're right.
  • Test engineer - The test engineer is responsible for physically manipulating the robot. This involves placing it in front of the infra-red tower when the programmer wants to download a program. Selecting the program to run, turning the robot on and off, positioning the robot for a test and running the program. Make sure the test surface is free of obstructions, the sensor is positioned correctly, and the wheels and motors are working as expected.


To program your rover-bot you'll be dragging instructions or "bricks." and snapping them to the picture of the RCS (the yellow brick you see in this picture). Some of the common commands are shown below including . . .
From mindstorms

. . . forward . . .
From mindstorms

. . . and backward almost all of the bricks have little tabs along the right hand edge. If you click on the tab . . .
From mindstorms

. . . then you can change some of the specifics. In this case, you can change the length of time (in seconds) that the rover-bot can turn.
From mindstorms

These are just the basics, there are options for doing things based on input from a sensor (the Mindstorms kits come with touch sensors and light sensors and you can add cameras as well as microphones). There are repeat blocks that will do a command a certain number of times, or do it as long as a certain condition is satisfied. You can also use a yes/no block to do something if a condition is satisfied (say a touch sensor is pressed) and something different if it isn't pressed.

Your rover-bot is equiped with a light sensor, so you'll have to figure out with your group how to use it in helping your roverbot follow the "road."