AME 3623: Project 9: Finite State Machines
- All components of the project are due by Friday, April 26th
at 11:59pm
- 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
Your hovercraft will be placed at a location and orientation on the
field. Your craft will take the following steps:
- Wait for the switch to be pressed.
- Record the current orientation. This will be your goal
orientation.
- After a 5-second delay, ramp up the middle fan.
- After a 5-second delay, move forward until a wall is detected
to the front.
- Stop
- Make a 90 degree turn to the left.
- If a wall is detected immediately, then make a 90 degree turn
to the left.
Otherwise, move forward until another wall is detected to the
front.
- Stop, including shutting down all fans.
Component 1: Hardware
If you have not already, re-add the distance sensors. One
should be mounted on the front of your craft; the other should
be mounted to either the left or right side on the top ring
(not the bottom ring).
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 a
stopped state. Note that you will need some new FSM events and
actions that what you have already used.
Component 3: Software
- Add the distance sensor query process to the
sensor_task. The calibrated distances should be stored
in a global variable (an array) for use by other tasks.
- Implement a new fsm_task that corresponds to your
newly-designed FSM.
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 and with the center fan turnd off. This will
help you separate the problems of
debugging high- and low-level code. Note that, in the end,
these pieces must all work together.
- This is an involved project. Start early.
- Keep your batteries charged.
What to Hand In
All components of the project are due by Friday, April 26th at
11:59pm.
- Demonstration/Code Review: All group
members must be present.
The demonstration must be completed by Tuesday, April 30th in
order to receive credit for the project.
- Check in the following to your project 9 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: Catme surveys must be completed by
Tuesday, April 30th.
Grading
Personal programming credit:
- 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."
Group grade distribution:
- 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 17 20:58:04 2019