Hints from the Past


 


Subsections

Robot Structure
Gearboxes
Michael Solomon:
Tim Corder:
Patrick Frantz:
Weight Considerations
Michael Solomon:
Patrick Frantz:
General Structure
Michael Solomon:
Patrick Frantz:
Miscellaneous Parts
Shanley Richardson:
Patrick Frantz:
Programming
Size of Code
Shanley Richardson:
Patrick Frantz:
Robot Queries
Shanley Richardson:
Nested Loops and Statements
Shanley Richardson:
Programming Modules
Shanley Richardson:
Programming Style
Shanley Richardson:
Group Dynamics
Patrick Frantz:
Design Time-Line
Week 1
Week 2
Week 3
Week 4
Week 5
Week 6
Week 7
Week 8
Week 9
Week 10
Week 11
Week 13
Week 14
Week 15

Hints from the Past

 

``Progress, far from consisting in change, depends upon retentiveness. Those who cannot remember the past are condemned to repeat it.''

George Santayana, ``The Life of Reason''

This appendix provides some hints from former ELEC 201 LEGO builders and robot programmers. It is hoped that you can learn from their mistakes and experiences as master robot builders (as you will be at the end of the semester).

While some of the advice given is valuable, it should not be taken as gospel. What worked for these students may not necessarily work for you or your group, but then again, it may save you valuable time. It is up to you to decide how to use the information in this chapter, if at all.

In addition, a timetable for robot completion is presented. Again, this is not a strict guideline. The goals presented are there to give you an idea of what progress your group should be making throughout the semester. If you are a week or two ahead or behind, you probably have no cause to worry.

Robot Structure

A successful robot needs to have a well built structure. Most important to this purpose are a working drive train and a stable robot frame. Below are sections covering these major areas of robot design, as well as hints from previous ELEC 201 students.

Gearboxes

An overview of gearboxes is provided in Lego Construction chapter. This chapter provides the basics on interconnecting LEGO beams and gears. In addition, it provides some information on a few of the different types of gear trains that you can build with LEGOs. Reading this chapter first, as well as experimenting a little with LEGO gears, might make the hints presented here a little more comprehensible.

Michael Solomon:

The most important thing here is the gear ratio. This is the difference in speed between the input  shaft and the  output shaft. Hence, the input shaft of a 5:1 ratio would turn five times as many times as the output shaft in the same amount of time. Higher ratios (numerically lower) provide more speed to the output than lower ratios (numerically higher), though with less  torque. A 2:1 ratio would provide more speed and less torque to the output than a 10:1 ratio. Torque is the twisting energy of the shaft. Generally, more torque is more power. A good drive gearbox will have a balance of speed and torque so that it will actually propel the robot. If the ratio is too high, there will not be enough torque to actually move the vehicle. If the ratio is too low, the robot will move slightly slower than a snail. The ratio of a gearbox with only two gears will be the number of teeth on the output gear divided by the number of teeth on the input gear. If there are more than two gears, just multiply each ratio of gear combinations. The standard LEGO gears provided have 8, 16, 24, or 40 teeth.

If you're using four [Mabuchi] motors for drive, try starting with a 25:1 or 27:1 ratio. You may also have some luck as high as 9:1. If you only use two motors for drive, you'll probably have to start out with a lower ratio to have enough torque. Worm gears are usually not very efficient. The  shaft that the worm gear is on will tend to bend away from the gear resulting in a considerable amount of slipping under heavy loads and possible damage to the gears. If you're intent on pursuing worm drive, they have approximately a 10:1 ratio when coupled to a 24 tooth gear, but be forewarned.

When you are building a gearbox, use sleeves on the axles. If there's room, I like to put them on the inside of the beams. They should be carefully positioned so that they are just slightly away from the beam, maybe the distance of a thick piece of paper. This will allow a small amount of free play in the  axle and gears, but will drastically reduce friction. They can also be pushed against the beams tightly if you want to increase the friction. Why would you want to do this? Increasing the friction is handy if you find the robot isn't driving straight and have done everything you can to fine tune the slow side.

If you're playing around with using more than one motor and drive wheel on each side for drive, I recommend building separate gearboxes for each motor. Even though this won't guarantee that all the drive wheels are moving at the same rate, it will drastically reduce the friction involved. While I'm talking about drive, I'll take the opportunity to downgrade tread drive. It ranks right up there with worm gears in my book. The chains create a lot of friction, they are difficult to get to exactly the right length, and they tend to tear apart easily. If you again don't heed my warning, your primary concern will be how tight the tread is on the drive gears. Too tight and you'll kill the system with friction, too loose and it'll slip and slide all day long. Careful placement of idle gears will help your endeavor, but not to a large degree.

Tim Corder:

The ideal would be to have all the gears meshed along one beam; having beams stacked on top of each other are less stable and tend to bend in and out.

Try to eliminate redundancy (i.e. two gears of the same size meshed together) and maximize size difference (i.e. 8-24 instead of 16-24).

Use a worm gear only when tremendous  gear reduction is desired, or for greater precision (i.e. rack and pinion steering).

40 tooth gears work, but are generally too large to be of significant practical use; also, they lose more  power (when meshed with other gears) than meshings between 8, 16, and 24 tooth gears.

Minimize diagonal meshing.

I found this gearing ideal for my robot: motor(8) -24, 8 -24, 8 -24(wheel), or 27:1 ratio.

Chains are generally a bad idea, especially if the gears are experiencing high  torque.

Patrick Frantz:

The previous two sections sum up well the major points needed to build a good working drive train. However, I would like to address a few of the individual points they made.

First, worm gears are not totally worthless. This year we have new motors that have much more torque than the old Mabuchi motors. I have built a working drive train with a worm gear that could support both a board and a  battery, all while maintaining a fairly good pace. I tested both the new Johnson motors and the new Mabuchi motors (comparable to last years Mabuchi motors) on this worm-gear-driven gearbox. The results were astonishing, as the Johnson motor drove the robot approximately four times as fast as the Mabuchi.

For most applications, however, worm gears are not necessary, and it is much more advantageous to leave them out of the design. They do lose a lot of  power, so if a gear train can be built without using worm gears, then do it.

Second, I don't agree that the 40-tooth gears are too hard to use. I have built several compact gearboxes using only 8-tooth and 40-tooth gears. I like this combination because it is a quick way to increase the gear ratio in your drive train.

Third, I like the chain link and feel that it can be very useful when trying to transfer torque over a specific distance. I admit, problems arise with chains either being too loose or too tight. The key is spacing the gears to be linked at a multiple of what I call their normal meshing distance (which is a function of the gear radius in horizontal units). To make this more clear, I will provide a brief example. 24-tooth gears have a radius of one horizontal unit. That means that 2 24-tooth gears can be meshed on the same beam with a spacing of four holes. If chain link is to be used, the gears must be spaced at a multiple of this (e.g. 8 horizontal units, 12 horizontal units, etc.). Figure A.1 shows a normal meshing between two 24-tooth gears (4 horizontal unit spacing) and the same two gears linked with chain using an 8 horizontal unit spacing (the distance between two adjacent holes equals one horizontal unit).


  

Figure A.1: Proper Use of Chain Link
\begin{figure}

\fbox {\centerline{\psfig{figure=hints/chainlink.PS}}}\end{figure}


Finally, I would like to say a few words about the new Johnson motors. I have built several gearboxes with them and have found that they are much more powerful than the Mabuchi motors. I advise you to ensure that your drive train is very secure, as the Johnson motors may rip a poorly built LEGO structure apart. This is especially true when they are used to drive gearboxes that use worm gears, chain-link and differentials. These problems can easily be circumvented by building a very stable and sturdy structure to house your gearbox.

Weight Considerations

Weight is important to your robot. In a game where time is of the essence, a heavy robot will not get the job done. Some of your erstwhile colleagues had the following to say about putting your robot on a diet.

Michael Solomon:

Try to keep the center of gravity of the robot low. This makes the robot more stable and less prone to being knocked over by other robots. The  battery is, by far, the heaviest item you'll be utilizing, so keep it as low as you can. The RoboBoard's location is probably best determined by your particular design, but keep in mind that a light structure with a high RoboBoard can lead to stability problems. Try to keep the weight as centered as you can as well. This isn't a problem with motors, but it is with the battery, and to a lesser degree, the RoboBoard. Putting the battery on one side of the vehicle will cause problems when you try to drive in a straight line, as it will put undue pressure on half the robot. An efficient design with a low center of gravity can package the drive motors and gearboxes, the battery, and the robo-board in less than four inches of height.

Don't underestimate the weight of the LEGO pieces. They may appear to be pretty light, but put enough together and they won't be. Remove any pieces that don't contribute to the structure of the robot. This isn't a beauty contest. Even pieces that seem necessary may not be if you use cross pinning.

Patrick Frantz:

Mike has the right idea about keeping the robot's center of gravity low. However, I offer this advice. Keep your  battery accessible. Last year, we built our main structure around our battery. This helped keep the center of gravity in a desirable location, but whenever we wanted to take the battery out, we had to take apart the robot. A lot of time was wasted because of this. I highly recommend that you place your battery such that it is easy to remove it from the robot.

General Structure

A good LEGO frame is a necessity to a winning robot. Chapter 8 explains some of the basic elements behind building good LEGO structures. Other advice follows.

Michael Solomon:

You may have noticed that when you put some weight on the robot and run it around for a while that the LEGO beams start coming apart and the gears start slipping. That may be because you need to cross pin the beams. This is what I call it when you put a beam on end against a structure of `normally' attached beams. This beam is attached with pins or pegs in the appropriate holes. If done correctly, this will tighten up your structure and allow you to possibly remove some of those beams you thought you needed in between. You'll need some of them, just probably not of the length you thought.


  

Figure A.2: An Example of Cross Pinning
\begin{figure}

\fbox {\centerline{\psfig{figure=hints/crosspin.PS}}}\end{figure}


Cross pinning is pretty straightforward, though the key is finding which holes in which beams you need the pins or pegs in. Just take a beam and span the distance you need to cross pin and start looking for holes. You may want to pin one end in a hole on one side of the distance you want to span that looks inviting. Then you can just swing the beam until you find an appropriate hole for the other end. The key here is to find a hole that either exactly lines up or is just fractionally too far away. We're talking about 1/32" to 1/64" too far away. Any more than this and you can seriously damage the LEGO pieces. You probably won't find holes so that the beam is perpendicular to the row of beams. If you're pinning two sides of a structure you'll need to pay attention to this. Try to make the cross pinning so that the beam on each side is going in the opposite direction. This will prevent the cross pinning from pulling the structure apart at one side.

Patrick Frantz:

Cross pinning is very useful in building a strong and durable robot. It is even more necessary to use some sort of support when using the Johnson motors. These motors are very powerful and require extra support to keep them from ripping the LEGOs apart.

Cross pinning can not only be accomplished using beams, but also by using other parts in your LEGO kit. Axles and 90 degree  axle guides work extremely well as cross pinnings.

Another sturdy structure is the triangle. Multiple cross pinnings can be used to make triangle-shaped structures that are both light and sturdy. Figure A.3 shows a structure made in this fashion.


  

Figure A.3: An Example of (an almost) Triangular Structure
\begin{figure}

\fbox {\centerline{\psfig{figure=hints/triangle.PS}}}\end{figure}


Finally, the  threaded axles and  axle nuts are very useful in building sturdy robots. These can be used to make very tight, and therefore sturdy, connections between pieces. However, these pieces are in limited supply and should be used sparingly.

Miscellaneous Parts

You should not feel constrained to use only those parts offered in your ELEC 201 kit. The $10 rule allows you and your group a little leeway in purchasing extra components. Last year, some groups used non-LEGO components with great success.

Shanley Richardson:

As you peruse your lab manual, you may notice that the vast majority of the motion producing devices (i.e. the Mabuchi motors and the stepper motors) currently available to you only produce circular movement. However, often in the production phase of your robot, you will actually desire to implement linear motion for some reason or another. For example, latches that hold back springs are a prime example of an occasion when you may actually desire this type of straight line motion.

Although there are ways to use joints, wheels and axles to convert circular motion to linear motion, these usually entail enormous gear boxes, flex unbearably under  torque strain and always waste a minimum of one motor port. If you're looking for a more compact alternative that does not waste a motor port, you may desire instead to investigate the possibility of using a  solenoid, a.k.a. linear actuator.

Solenoids vary greatly in size and power ratings, so if you choose to use one, you should probably first talk to one of your lab instructors to avoid frying the   LED ports on your RoboBoard. Solenoids are most often cylindrical in shape with a cylindrical hole bored down the middle of them. In this hole is placed a pipe which, when power is applied to the solenoid via a LED out port on the RoboBoard, will retract into the body of the solenoid.

Therefore, solenoids are particularly useful for simple linear motions as an alternative to motors. For example, consider a spring loaded gun designed to shoot a ball across the playing field. Although the spring could conceivably be cocked by hand prior to the match (assuming that it need shoot only once,) something must hold the spring in position until the opportunity to shoot arises. However, if the spring is sufficiently powerful, (please reference Physics 101 textbook for the technical definition of `sufficiently powerful,') a very powerful pin must hold it in place. This tends to warp thin plastic pieces appreciably. Additionally, the power required to draw this pin due to friction will probably put excessive strain on any LEGO gearbox that switches circular and linear motion. Therefore, this is a prime opportunity to implement a solenoid.

Patrick Frantz:

There are many interesting things in the world that can be added to your robot, and I'm not just talking about decorative effects. All that is required is a little imagination and ingenuity. Last year, we had a problem getting our robot to turn on four wheels, so we needed to find an alternative. We ended up using the roller ball from an empty roll-on deodorant container. We still had problems, but it was a great improvement. It is the implementation of odd, `non-robot' gadgets, however, that leads to a winning robot! I encourage you to look carefully at everyday objects to see if they can serve some function on your robot. I also recommend stores like Builder's Square and Home Depot as great sources for useful items.

Programming

Programming is just as important as building a working robot. Without a well-written program, a well-built robot will be less than impressive on the game board. Some of our more experienced programmers had a few words of advice to give this years' students.

Much of the following advice assumes that you have a working knowledge of IC. If you do not, it is suggested that you read through the IC manual first, for this will give you a better understanding of the topics presented here.

Size of Code

 

Every programmer should be aware of the size of his or her robot's program. While the RoboBoard does have 32k of on-board RAM, which should be sufficient for most applications, size considerations should be made.

Shanley Richardson:

32K of RAM does not allow you to store the entire Library of Congress. If you've never dealt much with computers, you may think that 32K seems insanely large. After all, a 3 page double spaced paper will only take up about 3K. However, you must remember that you're not just storing a POLI paper on the RoboBoard. In the 32K of RAM, you must store Pcode, all the library functions in IC, and your program. Suddenly, 32K doesn't seem so large any more. Additionally, the Robo-Board needs a certain amount of work space in RAM that it uses like scratch paper. Therefore, try to keep your programs to somewhere around eight to ten kilobytes. You'll be much happier in the long run.

Patrick Frantz:

The 32k of RAM on your RoboBoard should be sufficient to store the program of even the most advanced robot. However, problems will arise when duplication of  code occurs. If you notice that you are using similar sections of code in many places, you should consider making these similar sections into one comprehensive function. This will save you a lot of space. By doing this last year, we were able to fit our enormous amount of code onto the RoboBoard. In the end it totaled about 17k (which is about the limit). This year, however, things should be a little easier, since Pcode has been made a little smaller.

Robot Queries

Querying your robot involves asking it to evaluate the status of some variable. Returning the value of a digital or  analog input is an example of querying your robot. Asking your robot questions takes time, and the following comments address this.

Shanley Richardson:

Don't ask too many questions. Every time you ask a question of your robot (i.e. an if clause,) your robot must take valuable time to come up with any answer. Therefore, you may consider structuring your questions so that your robot has to answer as few of them as necessary. There are two techniques that may be useful to limit the questions that you are asking.

First of all, whenever possible, use else if clauses instead of plain if clauses. else prevents asking a question of your robot if a prior condition has already been met. For example, consider  the following:


void main()
  {
    int left;

    if (left < 0)
      {
      forward(0);
      }
    if (left >= 0)
      {
      reverse(0);
      }
  }
      

If left is less than zero, it will be picked up by the first question: if (left < 0). By the time it gets to the second if clause, it already knows this. You should not have to ask if the opposite is true. Try instead:


  void main()
  {
    int left

    if (left <= 0)
      {
      forward(0);
      }
    else
      {
      reverse(0);
      }
  }
      

This kind of time saving becomes even more valuable if there are more than two different logical possibilities. Consider these two alternatives:


  void main()
  {
    if (analog(20) < 85)
      {
      forward(0);
      }
    if ((analog(20) >= 85) && (analog(20) < 170))
      {
      forward(1);
      }
    if (analog(20) >= 170)
      {
      forward(2);
      }
  }
       

  void main()
  {
    if (analog(20) < 85)
      {
      forward(0);
      }
    else if (analog(20) < 170)
      {
      forward(1);
      }
    else 
      {
      forward(2);
      }
  }
      

If this were all of your code, this extra question asking would not be a primary concern. However, your robot will need to deal with many different conditionals to function well in the real world. Try not to push more questions through the processor than necessary.

Nested Loops and Statements

  

Nesting loops and statements is an efficient way of compressing the size of your code. In addition, nested statements can reduce the amount of time it takes for your robot to complete an action. This section explores some of the major points behind nesting statements.

Shanley Richardson:

You may wish to use a tree structure to curb unnecessary question asking. Consider the following program:


  void main()
  {
    int x;
    int y;

    if ((x >= 0) && (x < 100) && (y >= 0) && (y < 100))
      {
      forward(0);
      }
    else if ((x >= 100) && (x < 200) && (y >= 0) && (y < 100))
      {
      forward(1);
      }
    else if ((x >= 200) && (x < 300) && (y >= 0) && (y < 100))
      {
      forward(2);
      }
    else if (x >= 0) && (x < 100) && (y >= 100) && (y < 200))
      {
      reverse(0);
      }
    /* continue this pattern as long as you wish.... */
  }
      

This form of question asking, although better than just if clauses, can be improved upon. Try using nested if  loops to reduce your question asking. For example:


  void main()
  {
    int x;
    int y;

    if ((x >= 0) && (x < 100))
      {
      if ((y >= 0) && (y < 100))
        {
        forward(0);
        }
      else if ((y >= 100) && (y < 200))
        {
        reverse(0);
        }
      else if ((y >= 200) && (y < 300))
        {
        reverse(5);
        }
      }
    else if (x >= 100) && (x < 200))
    /* continue along these lines.... */
  }
      

You'll eventually come to love nested if loops. Frankly, when you're dealing with twenty cases, they're a lot easier to keep track of this way, not to mention a hundred. Furthermore, your robot will like you better.

As a final note, there are certain risks in taking this pattern to the extreme. Your machine keeps track of where it is in an if clause (as well as else clauses,) so if you nest too many of them, you may run into a YACC  stack error. YACC stand for Yet Another   Compiler Compiler, which basically means that you've put too much in one series of questions. However, with any luck you'll never run into this problem.

Programming Modules

During the semester it is important to set goals for your robot. Later in this chapter, a time line will be presented to help you build your entire robot. This section, however, concentrates on the programming aspect, giving you some advice on how to go about making your robot smart.

Shanley Richardson:

Rome wasn't built in a day (a.k.a. walk before you run.) Cliches hold the key to thousands of years of collective human advancement. Extensive fore-thought and careful planning are the keys to success when solving any programming problem. Before you ever sit down at a Macintosh, you should have some reasonable `outline' of what you're trying to encode.

Perhaps the most important point in this whole series of notes is the idea of programming modules. A module is a section of  code that attempts to meet a single goal. For example, if you decided to make your robot follow a black line to an intersection, shoot a ball, and then do a victory dance, you should probably break your code into four sections. First of all, you will want a module that does nothing but follow lines. Second, you would want a module to shoot the ball. Another module should be used to implement your victory dance. Finally, you would need a separate module to coordinate the efforts of the other three modules. (Do the victory dance after you secure victory, not before!)

A module is nothing more than a logical division of a program. However, you may find it useful to put each module in a separate function. At any rate, you should always break your programming up into smaller portions. If you can't even do a victory dance, you can hardly expect to do the entire series of modules to work. If you complete modules one at a time, you will soon find that your robot can do just about everything you wanted.

One final note, you should always set interim goals for yourself. Your final goal should be to have a fully functional robot. However, set personal goals for yourself for the middle of the semester. For example, try first to get your robot to move forward. Then, try to make it turn. Maybe next you would care to follow lines. At any rate, every goal you meet increases your skills and large portions of your code will be useful for later purposes.

Programming Style

 

Style is an important consideration in programming. You should want others to be able to read your code, especially your lab partners. This section presents some hints from former IC hackers on stylizing your code.

Shanley Richardson:

The three S's of programming are style, style and style. There are an infinite number of trivially different ways to solve the same programming problem. However, you should shoot for some consistency in your solutions, at least as far as your programming style. Style is used generally to denote your choices between trivially different alternatives. Consider the following:


  void main()
  {
    int x = 100; y(x);
  }
       

  void main()
  {
    /* set the constants */
    int DISTANCE_TO_GOAL = 100;
    /* move forward until you're in front of the goal */
    go_forward(DISTANCE_TO_GOAL);
  }
      

Admittedly, these two programs do exactly the same thing (assuming that y(int) and go_forward(int) are the same program. However, the second alternative is infinitely more desirable. When you go back over your work, you'll be glad that you have followed good style cues. Remember, the key is consistency.

Indentation:

Indentation greatly enhances readability. Try to indent after braces. For example:


  while(1)
    {
      sleep(.1);
    }
      

Comments:

Comment extensively. Not only will you be able to figure out what you were trying to do, your lab-mates will as well. ``Just do it!'' Comments do not take up any room in your 32K of RAM.

Naming:

The first rule of naming is to intuitively name your variables, constants and function. For example, if you have a function that follows lines, name it something like line_follower(). Do not name it y().

Additionally, constants, named numbers that do not change in value in your program, should be denoted by all capital letters (i.e. DISTANCE_TO_GOAL). Variables, named numbers that change value, should be denoted by all lower-case letters (i.e. distance_moved). This makes programming much less confusing.

A final note on naming, if you have some number that you use extensively, you should probably name it. For example, consider the following:


  void main()
  {
    int LEFT_FRONT_SWITCH;
    int RIGHT_FRONT_SWITCH;
    int NO_COLLISION = 0;

    while ((digital(LEFT_FRONT_SWITCH) == NO_COLLISION) &&
    (digital(RIGHT_FRONT_SWITCH) == NO_COLLISION))
      {
      forward(0);
      forward(1);
      }
  }
      

This means more than just vague references to numbers to anyone reading your program, including yourself. At any rate, whatever you choose to do concerning style, stick to your decision. Any single style choice is better than a conglomeration of differing styles.

A last point on style: you will find that it is incredibly useful to have some organization to which I/O ports you use for motors and  sensors. I suggest that you use lower numbers for the front, and then lower numbers for the left side. For example, if you were to have four IR reflective sensors on each extremity of your robot, you should place the front left one in port A, the front right one in port A+1, the rear left in port A+2, and the rear right one in port A+3.

Group Dynamics

Good group dynamics is important ingredient for a successful robot. Groups that get along well will have an easier time of assembling a finished product.

Team Organization

In many ways, the quality of the interactions of the members of your team will profoundly affect the quality of your overall experience in ELEC 201. There are important questions to be answered when thinking about the organization of your ELEC 201 team:

Will each participant be responsible for one portion of the design? Conversely, will all participants take part in all activities?
How will major design decisions, like the overall machine strategy or physical configuration, be made? Will there need to be a consensus amongst all of the team members before these types of decisions will be made?
How will disputes be resolved?

These are tough questions that rarely have simple answers. We recommend that questions like these be taken seriously, and that each team spend time discussing these issues at the start of the course. Each team should come up with a solution that works best for them.

A former group member had the following to say about group dynamics.

Patrick Frantz:

It sounds like a pretty easy task to get three people together and build a robot during the span of one semester. But anyone who tells you so is a liar. Getting along with your group members is the single most important part of building your robot. It doesn't matter how smart each individual member is, if they can't get along together, they won't produce a winning robot.

My group is an excellent example of how working together brings success. The group consisted of two senior History majors and one freshman SE, not exactly the combination you would expect to produce a competitive robot. However, we worked well together and we all had a similar attitude toward the course: we wanted to win.

While I can't say that every group should act like us, I would like to give a few pointers on dealing with your work members. First, loosely divide the tasks among the members in your group. For example, in my group one person worked on the drive train, another concentrated on picking up blocks, and the last developed a method of getting them into our bin. However, we did not exclusively work on our assigned projects, but rather maintained awareness of what the others were doing. We were also willing to help out when one member got frustrated with his task.

Second, be helpful.  If you are writing the code for your group, comment it profusely and make it as clear as possible. If another group member wants to read your code, he or she will be able to do so. Also, don't hesitate to give assistance to a fellow group member if they request it. On the other hand, don't try to do everything yourself. Your other group members won't like it if you want to `approve' everything.

Finally, try not to get too mad at each other. Arguments will occur, but try to remain as calm as possible. Getting mad and frustrated only wastes time. Talking out your problems with your group members will make it easier to solve the problem.

Design Time-Line

This time-line should serve as a guide to your progress as a robot builder. While you are not required to stick to it, it is advised that you pay attention to the listed goals from each week and compare them to what you have already achieved. The information here is drawn from former students. They have done this before, and following their advice could save you a lot of time spent in the lab at the end of the semester.

Week 1

This week you will obtain your robot design kits. You might also want to consider some basic strategy, as well as decide who your lab partners will be.

Week 2

This lab should be spent carefully constructing the RoboBoard.

Week 3

You should try to have your RoboBoard completed by the end of this week. Do not, however, rush the completion of your board. A sloppy construction job will be far more problematic than an extra week spent on assembly.

Week 4

Your RoboBoard should be complete by now, making way for the building of your robot. Start with the basics, like a drive train and some sensors. In addition, at least one member of your group should be experimenting with IC. Start writing small, but functional programs.

Week 5

More intensive programming should be taking place. Get a working geartrain and some IRreflective sensors and try to follow a line. Try to follow a wall on the game board. Try to have your robot track light. In short, start trying to interact with your environment. The code you write now probably will not resemble your final product, but it is a good place to start.

Week 6

Again, concentrate on the structure of your robot and programming. You should be beginning to have an idea of what your final robot will look like, as well as what it will have to do.

Week 7

By now, you should be giving some serious thought to strategy. How is your robot going to accomplish its objectives? How will it interact with other robots? How will it play defense? These are just some of the things you should be considering.

Week 8

After midterms we suggest that you have an informal discussion with your lab assistants. During this meeting you should talk to them about your goals and the current state of your robot. Most of the lab assistants have had experience in building robots and will probably be able to give you some valuable advice.

Week 9

You should now have a ``working copy'' of your robot, something that will resemble the final product. This not only means that you should have a robot structure built, but also that you should have some sort of  code written that will move your robot about the game board.

Week 10

Refining your robot should be the focus for this week. Concentrate on design improvement and robustness in both design and programming.

Week 11

Continue to improve your robot. Also, begin observing the other robots in the lab and start thinking about how to deal with their potential strategies.

Week 13

Your robot should be ready to go! Again, we suggest a meeting with some lab assistants to discuss any problems you might have at this point. If you are behind schedule, you will want to spend extra time in lab to catch up.

Week 14

You robot should be able to cope with other robots. Arrange informal matchups with other groups in your lab to test the performance of your robot. Above all, keep improving!

Week 15

This is the last week of lab, and you should have a finished product. Visualize success.