Problem
Our team decided to attempt to create a LEGO robot that could traverse an obstacle course, record the location of obstacles, and then traverse the obstacle course again and not hit as many obstacles & nbsp; By repeating this sequence with our robot, we hoped to have the robot improve its performance with each run and to eventually traverse the course without hitting any obstacles.

Project Details
Because it is currently a novelty, we decided to use the LEGO RCX 1.0 Brick as our microprocessor in order to drive the robot. The nice thing about this is it allows for us to deal with some basic hardware without having to deal with all the finer details about the processor (compared to the 68332). The only requirement of us was to design a robot that we will use to traverse the course and to program the code that will attempt to accomplish this.

Implementation
The first thing that we needed to do was to decide on the basic body of the robot, specifically how the robot will move around. The natural choice was to use 4 wheels, but unfortunately we only had 2 motors. This cause problems when we needed to steer the robot left or right because the wheels not attached to the motor would drag across the ground creating an unknown amount of friction that would have been very difficult to compensate for.

So our next choice resulted in a 3 wheel configuration, with 2 wheels (on opposite sides) attached to motors and a third balancing wheel that would help 'steer' the car. This model worked better in terms of turning, but it had problems when it would go in reverse.

The models that seemed to work best was one that used two treads and operated much like a tank. This allowed each side to turn indepentantly without having problems faces when using the 4 wheel configuration. There is still however the problem with stabilization as the motors are not exactly the same. As we tested the motor, one or the other would end up running faster than the other resulting in the robot veering off at an angle when it should be going straight. This would definitely cause problems with aligning the robot to the obstacle course which is on a square grid system.

Our next concern was coding. Since the LEGO RCX 1.0 Microprocessor has its own language that was an obvious first choice, but looking furthur, the actual code lacked enough substance to make this, and any others, a real worthwhile project. It features a easy-to-learn drag & drop method for programming the processor, which is nice if you're a beginning programmer. But for those who are somewhat more familiar with programming there is the alternative called Not Quite C (NQC) that uses familiar, but simple, C routines and function calls. We decided to choose the NQC programming language over the RCX programming language because it allowed you to define variables which for our purposes will serve as the memory for our robot.

The plan of how this project is supposed to go is as follows. Define a N x N area with N-squared tiles. Each tile represents a location that the robot can be in. The robot's goal is to get from the start position to the finish position avoiding obstacles along the way. The robot is only allowed to move to an adjacent tile from the one he is currently in. If the robot encounters an obstacle as he is moving into a tile, he will back up and mark his memory with that point being occupied (by an obstacle). Then the robot will turn and avoid the obstacle on it's next pass. This repeats until the goal is reached.

Results
There were a few complications while programming using NQC, which also apply to the RCX programming language. The primary problem is that of a limited memory capacity. As was mentioned in the NQC documentation, programmers have relatively 6K to store programs. It's relatively because our current code exceeds 6K (8K actually), so unexpected problems might occur.

Another problem is that there is not an array type defined in NQC. This means that alternative ways must be found if one wants to implement an array. We had intended for the program to run using the array as a map of where we are in the square tiles. The only problem is that to get to the next tile you need to hardcode in a way all the possible places that you can go to from your current tile, unlike arrays where the adjacent tiles can be calculated through a mathematical formula.

The last problem that we encountered is lack of sufficient memory storage. NQC provides a maximum of 32 variables for the programmer to use. This severely limits the scope of what the LEGO RCX can actually do. This in turn limited us to provide a glimpse of what would actually happen if there were more memory, not to mention pre-defined functions, that can implemented using NQC.

Currently, the robot is able to go forward until it detects an obstacle. It will then go into reverse and make a right turn, go forward a little more, turn left, and stop (in essence attempting to go around the obstacle. As it is doing this, he robot is storing various values into variables for memory. If you pick up the robot and place it in the original starting place and press the touch sensor on top of the robot, the robot will proceed to go forward again, but this time it will turn right (continuing with the rest of the process), entirely avoiding the obstacle that it hit the first time. If we were given the ability to store more variables, we could generate a fairly decent plot of where the obstacles are within the grid.

Conclusions/Discussion
What we have learned is not to overestimate what a toy can do. It is an expensive toy and that may have led us to believe that it should be able to do all sorts of interesting things, but in reality it can't. There is a limit to what LEGOs can do. Among other things that we have learned from this project:

- Navigation is a tricky thing, even for something a simple as manuevering a robot through an obstacle course. Although, we've simplified the actual process, imagine what programming is needed to have a person navigate in the real world.

- Memory is a good thing. It allows our robots to remember certain events and possibly avoid them at a later time when it may be potentially dangerous. In this project, memory was a limiting factor, and in further projects, we recommend that this be one of the first considerations when designing some LEGO project. The simple functions and routines are actually adequete enough to write larger more complex routines and an avenue may be open if someone can simplify and generate this code. This might led to greater potential for what the LEGO RCX can do.