Project 3: Interrupt Service Routines and Pulse-Width Modulation Control

• All components of the project are due by Tuesday, April 6th at 5:00pm.
• 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).

Project Goals

• implement interrupt service routines (ISRs) that produce control outputs,
• implement communication between the ISRs and your main program, and
• control the speed of the three fans on board your hovercraft (and hence the thrust that they generate).

Project Components

Part 1: Microcontroller Circuit

The board and connections to your circuit are documented on the Lab Hardware page: see the Motor Control Board section.

Connect the current amplifier board to your three fans and to motor power:

• Add wires to connect the motor control board to the fans and to the batteries
• Connect GND and VIN directly to the battery (not to your 5V regulated power supply)
• Connect the middle fan to port 2 (OUT 2A and 2B)
• Connect the right fan: red wire to OUT 1A and black wire to GND
• Connect the left fan: red wire to OUT 1B and black wire to GND

• Connect 1PWM and +5V(IN) to your Atmel's +5V power supply
• Connect GND and GND to your Atmel's ground
• Connect the following to your Atmel (you will need to select pins that are not shared with the programmer):
  • 1INA: Pulse-Width Modulated (PWM) input for the right fan
  • 1INB: PWM input for the left fan
  • 2PWM: PWM input for the middle fan
  • 2INB/2INA: direction control for the middle fan (0/1: one direction; 1/0: the other direction)
• Note: if you are having difficulty finding enough free Atmel pins, please come see us

Part 2: Interrupt Service Routine

Create an interrupt service routine that will generate the PWM signals for each of the three PWM inputs to the motor control board.

• Implement three global variables for communication between the ISR and the main program:
  • volatile uint8_t duty_left = 0; // Range: 0 ... 127
  • volatile uint8_t duty_right = 0; // Range: 0 ... 127
  • volatile uint8_t duty_middle = 0; // Range: 0 ... 127

• Implement an ISR that is configured to execute at an interrupt frequency of approximately 2 KHz. This ISR will generate PWM signals for all three outputs at this same base interrupt frequency.

• Implement the following function:

  void middle_thrust_dir(uint8_t dir) that sets the direction bits for the middle fan.

  If dir = 1, then the craft should hover (assuming an appropriate level of thrust).

  If dir = 0, then the craft should be pulled to the ground.

• Only turn one fan on at a given time (i.e., we want to use the max available current for each fan).

• At the beginning of one PWM cycle, copy duty_left, duty_right and duty_middle to local variables (to the ISR). If duty_left + duty_right > 127, then the value of these local copies should be reduced so that the sum is 127.

• During one PWM cycle:
  • First turn on middle fan
  • Once you turn off middle fan, then turn on right
  • Once you turn off right, turn on left
  • Wait for the end of the PWM cycle to complete

• You should plan to achieve a maximum of 50% duty cycle for the middle fan and 50% for the left and right fans total. This should be sufficient for our needs (but may need adjustment if you are adding more mass to your craft)

• The ISR can actually manipulate (on-the-fly) the time that the next interrupt will be generated by explicitly setting the timerX counter (you will need to choose which timer is the best to use). Use the timerX_set(val) method for this. The time it takes to count from this set value to zero is the length of time before the next interrupt occurs.

• Use an integer variable to keep track of which ISR phase you are in at a given time.

• The first phase of the PWM cycle corresponds to pulsing the middle fan. Configure the timerX counter so that the next interrupt (the time that you will turn off the middle fan and turn on the right fan) happens duty_middle counts later. Assuming that the right fan is going to be pulsed (duty_right > 0), then the next interrupt will happen duty_right counts later. This continues through the left phase and the wait phase.

• The total number of counts for a full PWM cycle should be exactly 256 (so that we maintain a constant frequency).

Part 3: High-Level Control

Note: this part will count for one personal programming credit

Modify the your main function such that it executes one of two segments of code, depending on the initial state of your switch.

• Case 1:
  • Set thrust direction to HOVER
  • Note the original heading (call it your "goal")
  • Slowly ramp the middle fan thrust upwards until the heading error is above 45 degrees
  • Set thrust direction to BRAKE
  • Slowly ramp the middle fan thrust downwards until at zero

  Note: use your LEDs to indicate which phase of the program that you are in.

• Case 2:
  • Slowly ramp the left fan up to a duty cycle of 25%
  • While ramping the left fan down to 0%, ramp the right fan up to a duty cycle of 25%
  • Slowly ramp the right fan down to 0% duty cycle

  Note: use your LEDs to indicate which phase of the program that you are in.

Part 4: Hovercraft Layout

• Make sure that all components and cables are secure
• Make sure that the compass is far away from the motors
• Check that the Frisbee is balanced (i.e., the center of mass is at the center of the Frisbee)

References

• Atmel HOWTO
• Hardware in the Lab (including the USB-TO-RS232 converters -- see the FTDI ft232r section)

What to Hand In

• Demonstration/Presentation: All group members must be present.
  • Demonstrate your final product.
  • Present your design and implementation (5 minutes). The group is responsible for assembling a short presentation consisting of 3-4 slides (on computer or in printed form). Describe the design including:
    • which team members were responsible for what components (including the personal programming components),
    • your software solution for generating the three PWM signals,
    • your software solution for "Case 1" of your main program
    • DO NOT include low-level code (only give the general logic)
    • a proper circuit diagram (not a picture of your circuit)

• Code: Turn in your documented code to the group project 3 digital dropbox on D2L (hand in the ".c" file). Only hand in one copy of the code per group.

  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. 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)
  2. In-line comments should be used to describe logically what is happening at that line or group of lines.

  See an example.

• Personal report: One submission per person to the personal project 3 digital dropbox in text format only (e.g., M$word has a save-as text option in the File menu). In this report, briefly state:
  1. Who performed which personal programming component. Assess the degree to which they performed this task. The ideal scenario is that they performed a large majority (80% or more) of the task.
  2. Of the remaining project pieces, state the relative contributions of you and your group members in terms of percentage of effort. The ideal distribution is equal across all group members. In extreme cases in which effort is not equitable, this distribution will be used to weight individual grades.

Grading

• 40%: Project implementation
• 30%: Demonstration/presentation of working project (to either of the TA or the instructor)
• 30%: Code documentation and group report

Grades for individuals will be based on the group grade, but weighted by the assessed contributions of the group members.

fagg [[at]] cs.ou.edu

Last modified: Sun Mar 28 01:15:57 2010