AME 3623: Project 10: Finite State Machines II

• All components of the project are due by Thursday, May 4th. at 9:00 am
• 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 complex 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. The orientation of the field will not change for the demonstration.

3. Your program must wait for a press of switch A before proceeding. With the switch press, you program will:
   • Record the state of switch B.

   • Begin to ramp up the middle fan to a point where the craft begins to turn (as measured by the gyro).

4. Phase 1: 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. In this position, your hovercraft must make at least a 90 degree turn.

6. Phase 2:Your hovercraft must then navigate from its current position to a second goal, depending on the recorded state of switch B. In particular:
   • If switch B was not pressed at the beginning of the sequence, then the goal is position C.

   • If switch B was pressed, then the goal is position D.

7. Your hovercraft must then ramp down the central fan.

Component 1: Hardware

Component 2: Finite State Machine

Design your FSM on paper. This FSM must accomplish all of the above steps, including handling the start from the switch press and the stopped state.

Notes

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

• Think carefully about the possibility of sharing states across different branches of the task.

• 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).

• This is an involved project. Start early.

• Keep your batteries charged.

What to Hand In

• Demonstration/Code Review: All group members must be present. The demonstration must be completed by Tuesday, May 9th in order to receive credit for the project.

• Check in the following to your project 10 area of your subversion tree:
  • FSM Diagram: in PDF format. This diagram must use the "event/action" notation for the arrows.

  • Documented code: See the project 1 specification for detailed documentation requirements.

• Personal report: There is no personal report due for this project.

Grading

• Each person must accumulate at least three personal programming credits over the course of the semester. This project offers one.

• 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.

andrewhfagg -- gmail.com

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