Software

Due to the mechanical simplifications made in the design of the robot, the software complexity of the robot was greatly reduced. For example, determination of the free throw and three point lines as well as online control of the ball loading mechanism were problems that could add significant logical complexity to the code design. However, due to certain mechanical design decisions made by our team, it became unnecessary to consider such problems (see the Mechanics section for further details).

State Machine
- States
- Events

Code
- constants.h
- events.h
- main.c
- motor.h, motor.c
- beacon.h, beacon.c

State Machine

Ultimately the behavior of the robot was completely determined by the following four state DFA (deterministic finite automata). Thus, the behavior of the robot at any given point in time was a deterministic function of the input (an event) and the current state of the robot.

States

The final DFA for Cheap Assault consisted of four states; the states were chosen to capture the function being performed by the robot while in the said state. A brief description of the states is as follows:

State	Function
Finding Center	The robot searches until its center phototransistor detects a high reading from the central IR beacon. It does this by rotating in place; ideally, when the center beacon is found, it is perfectly in parallel with the right and left walls of the playing field. Once the beacon is found, the robot halts its rotation and begins reversal.
Reversing	In this state the robot reverses for a set period of time, empirically determined to be much greater than the time taken to reverse from the free throw line to the three point line. Ideally, the robot will collide with the back wall of the playing field, and, as the motors are still running, the robot will align itself using the back wall. This should correct for small scale errors in center detection above. Since the determination of the basket positions are mechanically "hard wired," the error in center determination effectively determines the error rate in the shooting.
Powering Up	In this state the robot energizes the pitching motor, giving it some time to warm up in preparation of shooting balls. It was determined that the pitching wheel slowed substantially following each shot taken; for this reason, it was necessary to guarantee that by the time the first shot was taken that the pitching wheel will have obtained its maximum speed. Note that prior to exiting this state, the robot aligns its turret with the center beacon (it is not started in the center to relieve mechanical stress on the center solenoids) and starts the ball loading column. After leaving this state, neither the column motor nor the pitching motor are ever disabled (see the Mechanics section for further details).
Shoot Balls	In this state the robot merely responds to changes in the currently active beacon by rotating its turret appropriately. Since both the column and the pitching wheel are kept in the active state, balls will continue to be fired as time progresses; only the direction is controlled via software. It is a fundamental assumption of the Cheap Assault design that the turret rotation time, in combination with the active beacon selection change time, is less than the time necessary to rotate the column in place to fire the next ball. As long as this assumption holds, it is not necessary to control the operation of the ball loading column once it has been started (see the Mechanics section).

Return to top

Events

Events provide the inputs to the state machine and incite a change in the robot's behavior. Due to the nature of the Cheap Assault design we were able to reduce the number of events the state machine needed to consider to the following:

Event	Description
Center Adjustment	Since the event was last checked, a change in the robots orientation has occurred relative to the center beacon -- it is now either off center or in complete alignment.
Timer Expired	A general purpose timer has expired. Typically the robot uses this to control the duration of some particular activity (e.g., how long it should reverse before halting and beginning to shoot balls).
Active Beacon Changed	Since the event was last checked, a change has occurred in which beacon is currently active. By virtue of the problem statement, this means that the robot has successfully made the basked under the previously active beacon, and now must rotate its turret (before the next ball loads from the upper column) to face the new target.

Return to top

Source code

Below is a description of each of the code modules used in the project as well as a link to the actual source files containing their implementations. constants.h

This file contains a listing of the various constants and enumerated types that are used throughout the code. A large majority is detected to pin assignments from the MicroCore to specific mechanical parts in the robot.

Return to top

events.h

This file enumerates the states and events described above. It also contains the macros necessary to manage a packed data type required to transmit more than one piece of information describing a particular event (we opted for this technique rather than splitting an event with x parameters into x separate events).

Return to top

main.c

This file contains the implementation of the state machine described above (refer to the inline commentary for further discussion) as well as an implementation for all the necessary event checkers.

Return to top

motor.h, motor.c

These files contain the code necessary to manage the operation of the various motors in use throughout the robot. In particular, the logic required to drive the turret in response to the beacon events may be found here.

Return to top

beacon.h, beacon.c

These files contain the code necessary to determine the strength of the center signal as well as the currently active beacon. For further details, please refer to the code files.

Return to top