AME 3623: Project 2: Microcontrollers and Finite State Machines

In project 2, we designed a robot controller that was capable of orienting to and then moving toward an infrared beacon. The control outputs were direct, logical functions of the sensor inputs. However, it is often desirable for the control signals to not only be functions of the current sensory inputs, but to also take into account some aspect of the history of the inputs. We often refer to this representation of history as the context or state.

Continuing our VOR example from project 1, suppose our aircraft is to follow a particular path by successively finding and locking onto a sequence of VOR beacons. How one searches for the next beacon in the sequence depends not only on the information being received from the current beacon, but also upon where one is in the sequence.

The goals for this project include:

learning how to design circuits around a microcontroller,
exercising our programming skills,
writing programs that interface with the real world, and
designing and implementing finite state machines.

Project Due Dates

Part 1 (basic control): Thursday, March 23rd, 5:00pm
Part 2 (finite state machines): Thursday, March 30th, 5:00pm

Robot Task

In the full task, the robot will operate in two primary phases:

Phase 1:
- Move toward the beacon in front of the robot
- Scan for another beacon to the left
- When the beacon is found, turn toward it and begin phase 2.
Phase 2:
- Move toward the beacon in front of the robot
- Scan for another beacon to the right
- When the beacon is found, turn toward it and begin phase 1.

Within either of these phases, an exception may occur if the robot loses sight of the forward beacon (as defined by both the left and right sensor signal strengths dropping to "00"). If this exception occurs, then:

Phase 1:
- Rotate the turret to the right
- If a beacon is found in the new direction (immediately), then the robot will turn toward it and continue with phase 1.
- If no beacon is found, then turn the turret forward and stop moving.
Phase 2:
- Rotate the turret to the left
- If a beacon is found in the new direction (immediately), then the robot will turn toward it and continue with phase 2.
- If no beacon is found, then turn the turret forward and stop moving.

Test Courses

We will use a set of standard test courses for demonstration purposes (these will be available prior to demonstration). Once the first group is ready to begin testing, we will make sure to always have at least one test setup in the lab.

Design Process

Part 1: Basic Control

Due: March 23rd at 5:00

This part requires the following:

Design and assemble a circuit based on an Atmel Mega8 processor.
Implement the C functions described below and provide test code that will demonstrate that the code is functioning properly.
Demonstrate your functioning code.
Hand-in the code file(s) through D2L.

The required functions are as follows. Do not change these prototypes without first obtaining permission.

The first three functions should be the only direct interface to the pins (i.e., only references to PORTx, PINx should be within these first three functions).

Robot Command


void command_robot(uint8_t command)

where command is an integer in the range of [0 .. 6] as defined in project 1. Note that unit8_t is an 8-bit unsigned integer.

Turret Command


void command_turret(uint8_t command)

where command is an integer in the range of [0 .. 2] as defined in project 1.

Sensor Reading


void read_sensors(uint8_t sensor[4])

After the call to this function, sensor[i] will contain the value corresponding to infrared sensor i (values will be in the range of [0 .. 3]).

Tracking the Beacon


uint8_t track_beacon(uint8_t sensor[4])

The array sensor[4] is an input to this function. If at least one of the forward sensors is receiving a signal, then this function will command the robot to turn to and move toward the beacon (implementing the key logic that you designed for project 1). In this case, a 1 will be returned.

Otherwise (no signals), the function does not change the command state of the robot and will return a 0.

In either case, this function should return quickly (and not do any sleeping)

Orienting Toward a New Beacon


uint8_t orient_new_beacon(uint8_t sensor[4])

We will assume that when this function is called, the robot is already oriented toward a beacon (the beacon is in front of the robot), and a second beacon has been located to either the left or the right. This function should only return once the robot is facing the second beacon.

Notes:

This function will involve multiple calls to read_sensors().
This function will also involve calls to delay_ms()
Before returning, this function should stop the motion of the robot.

Part 2: Finite State Machine

Due: March 30th at 5:00

You must complete the following steps:

Design
- Identify the FSM states
- Identify the FSM inputs (events). How do the FSM inputs relate to the sensory inputs?
- Identify the FSM outputs. What are the actions that your robot must take?
- Define the state transition function.
- Define the output function. What does the robot do at each state transition?
Implementation
- Implement your FSM design in C. You must use the C routines that you implemented for part 1.
- Get it to work (do not underestimate the amount of time that this step will take).
Demonstrate your working code.
Hand-in your code, your group report, and your personal report through D2L.

Hints

See the Atmel HOWTO for details about circuits and programming.
Remember that events are instantaneous (e.g., a change in a sensory input) and that states are about maintaining a memory of the situation between events.
Think about what control actions that your program must issue between events.
Implement and debug your program incrementally. As with many embedded systems, you only understand the complete problem once you begin to work with the hardware. So - expect your design to evolve over the next few weeks. Here is a list of practical steps that you might consider taking before implementation of your FSM:
1. Build the test circuit described in the Atmel HOWTO. Compile and download the test program. (and make sure that the lights blink as you expect)
2. Design and implement the connections to the beacons receivers (the 8 bits), the robot control lines (3 bits), and the turret control lines (2 bits).
3. Write simple test routines that generate a robot/turret movement, followed by a delay, followed by a "stop" (in the case of the robot).
4. Get your FSM to work first without the exception handling (just transition to a HALT state if you lose sight of the beacon). Then - add the exceptions.
LED's on extra output pins can be used by your program to communicate debugging information to you (for example, to represent the current state of your code).
You may construct paper shields for your infrared sensors. This will allow you to better control the angular sensitivity of these sensors.
Sensor filtering: as you discovered in lab 1, despite preprocessing, the infrared sensors can be somewhat noisy. This problem becomes more significant as we add more beacons to our environment. One way to deal with this is to filter these signals. A simple filtering mechanism is to sample the beacon receiver bits multiple times (e.g., separated by 1 msec intervals), and to sum the results. This will tend to give you more reliable sensor readings.

Robot Interface

The interface to the robot is identical to that which you used in project 1.

What to Hand In

Project Report

Your report should include the following:

The names of the group members.
Describe the details of your FSM design (the components listed in the design section).
A diagram of your circuit.
A copy of your documented program (this may be handed in as a separate file). The documentation should be such that a person not familiar with your program (but familiar with the control problem) can understand what you are doing.

The reports are due at 5:00 on March 30th. Please turn these in using the D2L dropbox (one copy per group) in either postscript or pdf format.

Personal Reports

Your personal report must include the following information:

Your name
An estimate of your contribution to the project in terms of percentage of effort.
An estimate of the contribution of each of your fellow group members.
A justification of your contribution assessment.

The personal reports are due at 5:00 on March 30th. These must be turned in via D2L in raw text format.

fagg at ou.edu

Last modified: Tue Mar 21 14:39:26 2006