I.   Technical Implementation:
=============================================
    Much of the work was taken from the "receive-drive-command.c" program
written by Professor Jacky Baltes at the University of Manitoba.

    There were some slight modifications to the program such as a reduced
data requirements of the program, and additional error checking.  Most of the
important parameters can be adjusted by modifying the defined constants and the
beginning of the program.  The only exception is that program assumes the
protocol uses a message of a size of 10 bytes as stated in the assignment 
guidelines.

    There are 4 major parts to the firmware application: 1) the main 
component, 2) The message reception component, 3) The error detection 
component, and 4) The motor drive component.

The main component:
    The main component initializes the system.  The system automatically goes
into suspend mode until an event triggers that takes it out of suspend mode.
There are curently 2 types of events: 1) The program key was pressed, 2) a
message was received.  Pressing the program key on the RCX unit changes the
robot's ID.  When a non-ignore message was received, the system creates a
process to handle the command.  If there were any old processes in effect, they
are terminated.

The message reception component:
    This component receives the message and stores it into it's global memory.
It also changes a global flag in the system to let the other parts of the
system know that a message has been received.

The error detection component:
    The error detection component works by taking the sum of all commands,
and comparing the least 3 significant digits with the least 3 significant
digits of the last byte of the message.

The motor drive component:
    The motor drive component has a simple algorithm.  First it checks to see
if there were any errors in the message by using the error detection component.
The motor drive component executes only when no errors were detected.  It
then evaluates the given command to see if it is a special kick (see note on
special kicks).  If the command is not a special kick, it is assumed a regular
drive command.  It gets the first 4 bits as the turning value, then executes a
turn.  Then it takes the last 4 bits as the distance value to travel, then
moves that distance.  Turning and moving requires calibration of the time units
a robot is given to execute that command while velocity is assumed constant.  
This means in order for a robot to travel twice as far, twice as much time must 
be given to a robot.


* Note: There are 3 specially defined kicks:
1) A straight foward kick.
2) A spin to the right
3) A spin to the left



II.  Related Work:
=============================================
receive-drive-command.c by by Professor Jacky Baltes at the University of Manitoba.


III. Approximate percentage:
=============================================
Terry create the firmware file based on the file "receive-drive-command.c".
Sergei & Greg debugged the firmware.



IV.  Problems encountered & Solutions:
=============================================

Problem:	lnp_logical_init() is undocumented.

Solution:	Left it in for now



Problem:	Sleeping time adjustments.
In the sample code, the robot set to sleep sometimes.
Figure out why and if our robot needed to sleep as well, then how long
should be our robot sleep for.  The sample code puts the robot to sleep
on different commands which also determine the duration of the sleep time.

Solution:	??


Problem:	Direction to consider as the front
While programming the robot, motor-A and motor-C were not known.  Thus, when I 
programmed the robot to turn right, it was possible for it to turn left.

Solution:	Experimentations were required to solve the problem.
