SE 101 Design Project

Lego Mindstorms Tracking Robot

Deliverables:

Technical Memo Wednesday September 29 at 4:30 P.M.
Draft Design Report Thursday October 14 at 4:30 P.M.
Scheduling Exercise I Friday November 5 at 4:30 P.M.
Simulation Solution Wednesday November 10 at 4:30 P.M.
Robot Demos and Races Thursday November 11, in lab
Design Report Monday November 15 at 4:30 P.M.
Scheduling Exercise II Thursday November 18 at 4:30 P.M.

Objectives

Lego Tracking Robot

Your project is to write software for a provided Lego Mindstorms robot so that it imitates some of the behaviour of the CS 133 TrackingRobot that is introduced in Practicum in week 2.  We'll call our robot the Lego Tracking Robot.  Like the CS 133 TrackingRobot, the Lego Tracking Robot travels along a grid of avenues and streets, from intersection to intersection, using information that it senses at its current intersection (e.g., the colour of the ground below the robot) to determine what its next move should be.  Although the Lego Tracking Robot will perform some of the same tasks as the CS 133 TrackingRobot, the Java classes for the two programs are very different from each other.

The CS 133 TrackingRobot moves around a virtual world defined by a Java World object.  This World object defines all of the objects (e.g., robots, walls, beepers) in the world and their location.  A CS 133 TrackingRobot can quickly determine its immediate surroundings via simple queries (e.g., frontIsClear(), isBesideThing()).  It can move easily from one intersection to the next via a simple move() instruction.  It can turn left or turn right via simple instructions.  It can pick up beepers and put down beepers it is holding.  Multiple robots can occupy the same intersection.

All of these tasks are much harder for Lego robots because these robots interact with the real world rather than a virtual world.  In fact, most of the code for controlling a Lego robot is concerned with trying to assess the robot's location and surroundings.   In the real world, avenues, streets, and intersections are mapped out by coloured tape.  Each Lego robot has two light sensors, which will be used to sense the colour of the ground beneath the robot.  The robots also have buttons that you can use to load and run programs.  There are primitive instructions that you can use in your code to read the inputs of these sensors.  In addition, each Lego robot has a motorized left wheel, an independently motorized right wheel, and a small LCD display.  These are the only outputs for the robot.  Again, there are primitive instructions that you can use to turn these motors on and off, and to write to the display.
 

Project Requirements

An executing Lego Tracking Robot will follow a trail along a grid of avenues and streets.   At each intersection, the robot identifies the colour of the intersection and uses that information to determine what its next move should be:  at an orange intersection, the robot makes a right turn, and then continues moving forward; at a black intersection, the robot makes a left turn, and then continues moving forward; and at a green intersection, the robot stops moving (i.e., it has reached the end of the path).  

This project is more complicated than it sounds because the Lego sensors and motors are imprecise.  The light sensor, which is used to detect ground colour, may return different values for the same colour (or the same value for different colours!), depending on the amount of light reflecting off of the area it is sensing, or depending on the battery level.  The motors, gears, and wheels are different enough that a robot might not travel in a straight line even when instructed to run both motors at the same power for the same time interval. Your team is responsible for writing code that compensates for imprecision in the sensors and motors.

Controller file

Your solution will be a LegoTracker class that implements all of the methods declared in the Controller interface:

We have provided a partial implementation of this class, LegoTracker.java, that implements the first five of these methods, so that you have to implement only the methods that determine how your robot responds to input events from the robot's sensors.   You will add additional private methods to this class, to make your program modular.  But your solution must provide implementations of the above public methods.

Much of your code will be calls to methods in the AbstractRobot class.  This class implements primitive methods for querying a robot's input sensors, controlling the motors, and writing to the LCD display.  Take a good look at the help file (described under Simulator) for this class.

We expect your solution to be structured so that each distinct task that your robot performs is implemented as a separate private method.  In implementing your methods, you are to adhere to the same coding style guidelines that are used in CS 133.
 

Project Teams

A team of nine to ten students will work on a LegoTracker class to control one robot.  You will be assigned to a subteam of three or four students.  Your subteam will be one of three subteams that make up a team. 

As a team, you will decide how to divvy up the work among the three subteams.   Your team is free to divide the work into tasks and to assign tasks to subteams however it pleases, as long as the entire team agrees to the division of work and to the allocation of tasks.  Your subteam is then responsible for completing its portion of the robot program.  On Wednesday September 29, each student is to hand in a technical memo describing how his or her team has partitioned the project into tasks and has assigned tasks to subteams, and how his or her subteam has allocated work to individual subteam members.

You may not solve any of your tasks by modifying the robot's hardware; you are  allowed modify only the robot's software. There is more than one way to implement most tasks.  As part of your design project, you are to consider different alternative designs and to explain why the designs decisions you made were the best decisions.

Some tasks that your team may consider useful include

Your team will work with one robot throughout the term; this way, the results from experiments that you run one week are more likely to still be true of your robot in subsequent weeks.  As a team, you will coordinate and schedule each subteam's access with the Lego robot.   Your subteam may need to share your Lego robot with another subteam, in which case you will need to plan your scheduled time with the robot carefully.   You may not take any robot out of the WEEF lab.   All of your work on your robot must be performed in the WEEF lab.  We will try to find time outside of SE 101 lab hours for you to have access to your robot in the WEEF lab, but we are constrained by your schedule and by the WEEF-lab schedule. 

Simulator

We expect you to do some work outside of the lab, using the Intellego simulator to test your software.  In fact, you will submit for marks a simulator version of your team's robot software, and you will select representatives from your team to demo your software in the simulator.  In this respect, this project resembles other software-engineering projects, in which the software cannot always be tested in the environment in which it will be used (e.g., aviation software).   The demo presentation of your simulator code is worth 20% of your final-report mark.

Software that you write for the simulator may need to be modified to control your robot.  

The Intellego simulator runs on Windows.  Because the simulator assumes that the user-provided classes will be located within the same file tree as the simulator, you'll need to download into your engfile account a personal copy of the simulator, rather than using a shared executable.  The SE 101 web site has a installation guide file that tells you how to start the simulator.   Documentation on how to use the simulator is provided as on-line help files.

Demonstration and Race

Your simulation solution is due on November 10, which is the day before robot demos are due in lab, and is in the week before your final design report is due.   We will hold robot demonstrations in lab.  We will set up a course for your robot to follow, and everyone's robots will be run through the course.  We will also hold a race for any team that is interested in pitting their robot against the other robots in the class.
 

Design Report

Each subteam writes and submits one formal design report, describing Write your report according to the template for the software-engineering work-term reports.