Project 5: Finite State Machines

• All components of the project are due by Thursday, April 29th at 5:00pm.
• Discussion within groups is fine.
• Discussion across groups may not be about the specifics of the solution (general programming/circuit issues are fine to discuss).

Project Goals

• design a Finite State Machine (FSM) that performs a specified high-level task,
• implement the FSM in code,
• connect FSM events to sensor events, and
• connect FSM actions to control actions.

Project Outline

Here are the steps:

1. Ramp up the middle fan to a level that enables the craft to leave the ground.
2. Navigate along theta1 while avoiding oblique obstacles (obstacles such that the two distance sensors give very different values).
3. Should an obstacle appear directly in front of the craft (as indicated by the two distance sensors having similar values), then the craft should first brake and then turn toward theta2. If the new direction is also blocked by an obstacle, then the craft should power down and stop.
4. Navigate along theta2 while avoiding oblique obstacles.
5. Should an obstacle appear directly in front of the craft, then the craft should first brake and then turn toward theta1. If the new direction is also blocked by an obstacle, then the craft should power down and stop.
6. Continue with step 2

Project Components

All components are required to receive full credit for the project.

Part 1: Finite State Machine Design

• List the actions. How the actions relate to control signals? For example, an action such as brake requires the reversal of the middle fan and a large middle fan duty cycle for a brief period of time.

• List the events. How do the events relate to internal or external information? For example, an event such as obstacle requires that the values of the two distance sensors are similar and within some range.

• Draw the FSM diagram with states, events and actions listed. Include this FSM diagram as part of your report.

Part 2: Finite State Machine Implementation

Modify your main function such that it is structured as follows (you will of course need to add other code). Here is an outline for the code:

int main(void) {
       int16_t counter = 0;
       int16_t heading, heading_goal, heading_error;
       int16_t theta1, theta2;
       int16_t rotation_rate, distance_left, distance_right;
       uint8_t state = STATE_START;

       #APPROPRIATE VARIABLE DECLARATIONS HERE#
       #APPROPRIATE INITIALIZATIONS HERE#

       theta1 = get_orientation();
       theta2 = ####

       middle_thrust_dir(1);

       while(1) {
           heading = get_orientation();
           heading_error = compute_error(heading_goal, heading);
           rotation_rate = get_rotation_rate();
           distance_left = get_left_sensor();
           distance_right = get_right_sensor();

           // Display
           if(#SWITCH OPEN#) {
                display_orient(heading);
           }else{
                display_orient(heading_error);
           }

           // Steer away from obstacles
           status = steering_control(distance_left, distance_right, rotation_rate, #PICK SOME SMALL VALUE#);

           if(status == -1) {
                // No obstacles: steer to desired direction
                pd_control(heading_error, rotation_rate, #PICK THE SAME SMALL VALUE#);
           }


           // Note that "status" will be useful for detecting some FSM events
        
           // Finite state machine
           switch(state) {
               case STATE_START:
                   :
                  break;
               case STATE_NAVIGATE_1:
                   :
                  break;
                :
                :
               default:
                  // this should never happen
                  #Shut down craft#
                  while(1){};
           }


           // Increment time
           ++counter;

           // Wait for the flag to be set (once every 50 ms)
           while(flag == 0) {};

           // Clear the flag for next time.
           flag = 0;
       }
}

References

• Atmel HOWTO
• Hardware in the Lab (including the USB-TO-RS232 converters -- see the FTDI ft232r section)

What to Hand In

• Demonstration/Presentation: All group members must be present.
  • Demonstrate your final product.
  • Present your design and implementation (5 minutes). The group is responsible for assembling a short presentation consisting of 3-4 slides (on computer or in printed form). Describe the design including:
    • which team members were responsible for what components (including the personal programming components),
    • your FSM design,
    • a proper circuit diagram (not a picture of your circuit)

• Code: Turn in your documented code to the group project 5 digital dropbox on D2L (hand in the ".c" file). Only hand in one copy of the code per group.

  Remember that documentation is about helping you and others looking at your code to understand what it is doing. Therefore, it will generally describe the logic of the code (and not-necessarily the low-level details). For this class:

  1. Each function must be documented (at the top of the function) as to what it does logically, what the meaning is of its inputs, and what the returned value is. If the function has external effects (e.g., commanding an actuator or modifying a global variable, these should also be documented here)
  2. In-line comments should be used to describe logically what is happening at that line or group of lines.

  See an example.

• Personal report: One submission per person to the personal project 5 digital dropbox in text format only (e.g., M$word has a save-as text option in the File menu). In this report, briefly state:
  1. Who performed which personal programming component. Assess the degree to which they performed this task. The ideal scenario is that they performed a large majority (80% or more) of the task.
  2. Of the remaining project pieces, state the relative contributions of you and your group members in terms of percentage of effort. The ideal distribution is equal across all group members. In extreme cases in which effort is not equitable, this distribution will be used to weight individual grades.

Grading

• 40%: Project implementation
• 30%: Demonstration/presentation of working project (to either of the TA or the instructor)
• 30%: Code documentation and group report

Grades for individuals will be based on the group grade, but weighted by the assessed contributions of the group members.

fagg [[at]] cs.ou.edu

Last modified: Sun Apr 18 23:38:35 2010