AME 3623: Project 9: Finite State Machines

• All components of the project are due by Tuesday, April 28th at 9:00 pm
• Groups are the same as for project 1.
• 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).

At the end of this project, you should be able to:

• design a finite state machine (FSM) for mission-level control,
• translate a FSM design into C code
• connect FSM events to sensor events,
• connect FSM actions to control actions, and
• debug both FSM designs and code.

Project Outline

1. At the beginning of a test run, your hovercraft will be placed in one of four configurations: A, B, C or D (both position and orientation are defined). Your program will not be given any direct information about which configuration it is in.

2. On start up, your program should record the current orientation. (note that the orientation of the field will not change for the demonstration).

3. Your program must wait for a button press before proceeding. With the button press, it must ramp up the middle fan to a point where the craft begins to turn (as measured by the gyro).

4. Your hovercraft must then navigate from its initial configuration to a specific goal. In particular:
   • If the starting location is A, then the ending location must be B.
   • If the starting location is B, then the ending location must be A.
   • If starting in C, ending is B
   • If starting in D, ending is A

5. Once your hovercraft has reached its goal, it must slowly ramp down the central fan and turn off the lateral fans.

Component 1: Hardware

• If you have removed the distance sensors from your circuit, please add them back. Remember that the distance sensors should be positioned such that the minimum distance to an obstacle is 6cm. Also, make sure to orient your sensors so that they are useful for the task described above.

Component 2: Finite State Machine

Design your FSM on paper.

Component 3: Software

Add a new variable type to "project.h":

typedef enum {
   START,
   #LIST YOUR OTHER STATES HERE#
} State;

int main(void) {
       int16_t counter = 0;
       int16_t heading, heading_last, heading_goal, heading_error, heading_error_clipped;
       int16_t rotation_rate, distance_left, distance_right;
       State state = START;   // NEW
       int16_t forward_thrust = 0; 

       #APPROPRIATE VARIABLE DECLARATIONS HERE#

       
       #APPROPRIATE INITIALIZATIONS HERE#

       timer0_config(TIMER0_PRE_1024);   // Prescale by 1024
       timer0_enable();  // Enable the timer 0 overflow interrupt
       sei();  // Enable global interrupts

       #INITIALIZE VARIABLES HERE#

       #RAMP UP MIDDLE THRUST TO HOVER#

       // Loop forever
       while(1) {
           // ////////////////////////////////////////////////
           //  Sensors
           heading = read_orientation();
           heading_error = compute_orientation_error(heading_goal, heading);
           heading_error_clipped = clip_error(heading_goal, #DB#, #SAT#);
           rotation_rate = get_rotation_rate();

           distance_left = get_distance(LEFT);
           distance_right = get_distance(RIGHT);

           // Display
           #APPROPRIATE CODE FOR DISPLAYING SENSOR STATES WITH YOUR LEDS#

           // ////////////////////////////////////////////////
           // Finite state machine
           switch(state) {               // NEW
               case STATE_START:
                   :
                  break;
               case STATE_NAVIGATE_1:
                   :
                  break;
                :
                :
               default:
                  // this should never happen: but take safety steps
                  //   if it does
                  #Shut down craft#
                  while(1){};
                  break;
           }

           // ////////////////////////////////////////////////
           // Control
           // NOTE: forward_thrust and heading_goal should be set by your FSM
           pd_control(forward_thrust, heading_error, rotation_rate);

           // ////////////////////////////////////////////////
           // Handle loop timing
           // Increment time
           ++counter;

           if(flag_timing) {
               // Error condition: your code body is taking too much
               //  time.
               #Indicate this with an LED display of some form#
           }else{
               #Indicate with LED display that everything is OK
           }

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

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

Notes

• Implement your FSM incrementally: get one piece working well first and then grow it.

• Draw your FSM before you implement it in code. If you change your implementation, make the change on the diagram first, then work on the code.

• You can do a lot of testing with your craft being held by a group member. This will help you separate the problems of debugging high- and low-level code (but, in the end, it must all work together).

• Introduce STATE_STOPPING and STATE_STOPPED early into your design/implementation.

• Your hovercraft can easily accumulate a lot of momentum. You can "burn" this off using a number of techniques. Reducing middle fan thrust in general can cause the craft to drag a little against the ground, effectively giving you a form of damping. You can also explicitly have states in your FSM dedicated to powering down the middle fan to stop the craft before continuing with the next phase of the task.

• This is an involved project. Start early.

What to Hand In

• Demonstration/Code Review: All group members must be present. Given time, this can be done during class.

• Check in the following to your group dropbox on D2L for project 9:
  • Documented code:

    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. At the top of your C file, document the project number, group members, date and the group member responsible for the code.
    2. 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)
    3. In-line comments should be used to describe logically what is happening at that line or group of lines.

  • A drawing of your final FSM.

• Personal report: the Catme survey is due by Thursday, April 30th at 11:59pm.

Grading

• Each person must accumulate at least three personal programming credits over the course of the semester (this project offers two). This can be one person or split across two people. Their individual contributions must be clearly documented.

• To receive credit, you must be the primary designer, implementer and debugger of the component. This does not mean that your other group members should not be looking over your shoulder. But: you must do the "driving."

• 35%: Project implementation
• 30%: Demonstration of working project (to either of the TA or the instructor)
• 35%: Documentation

Group Grading Rubric

Grades for individuals will be based on the group grade, but weighted by the assessed contributions of the group members to the non-personal programming items.

References

• OUlib documentation

andrewhfagg -- gmail.com

Last modified: Wed Apr 12 23:27:11 2017