AME 3623: Project 10: Finite State Machines II
Note: do not seriously start this project until you have completed your
project 9 code review.
- All components of the project are due by Thursday, May 5th
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 finite state machine (FSM) for complex, mission-level control,
- translate the FSM design into C code, and
- debug both FSM designs and code.
Project Outline
The goal for our hovercraft is to navigate through the environment
shown below. The thick lines correspond to visible walls.
- At the beginning of a test run, your hovercraft will be
placed in either the 1, 2 or 3 configuration shown (it will be placed
in the middle of the hallway). Your program will
not be given any information about which configuration it is in.
- On start up, your program should first record the state of the
switch.
- Phase 1: your hovercraft must navigate from its initial configuration to
a subgoal:
- If started in 1, then end in B
- If started in 2, then end in B
- If started in 3, then end in A
Note: "ending" at a location is very liberal; if your
hovercraft stops within 2 feet of the end of the designated
hallway, then it is considered as as having arrived
successfully.
- Phase 2: depending on the state of the switch at the beginning
of your run, the craft must navigate to a second specific subgoal:
- If 0, then navigate to A
- If 1, then navigate to C
Component 1: Hardware
Place your distance sensors strategically so as to simplify the FSM design.
Component 2: Finite State Machine Design
Design your FSM on paper. This FSM must accomplish all of the above
steps, including handling the start and the
stopped states.
In particular, you must:
- 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 value of one of the distance
sensors is within some range.
- Draw the FSM diagram with states, events and actions listed. Include this FSM
diagram as part of your report.
Component 3: Software
Implement and test your 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. This will help you separate the problems of
debugging high- and low-level code (but, in the end, it must
all work together).
- 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
linear 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.
- Keep your batteries charged.
- By rotating your lateral fans slightly inward (so their
thrust vector is perpendicular to the vector from the middle
of the fan to the center of mass), you can
generate more rotation and less forward acceleration.
What to Hand In
All components of the project are due by Thursday, May 5th at
9:00 pm.
- Demonstration/Code Review: All group
members must be present. Given time, this can be done during
class. The demonstration must be completed by Monday, May
9th. It is our expectation that you will make every attempt to
complete your demonstration by May 6th.
- Check in the following to your project 10 area of your
subversion tree:
- Documented code: See the project 1
specification for detailed documentation
requirements.
- FSM diagram. Submit in pdf format.
- Personal report: There is no personal report due for
this project.
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.
References
andrewhfagg -- gmail.com
Last modified: Tue May 3 15:19:09 2016