Project 4: Proportional-Derivative Control

• All components of the project are due by Tuesday, April 20th 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 and tune a proportional-derivative control law that maintains the hovercraft's heading at some desired orientation,
• implement a steering control law that keeps the hovercraft pointing away from nearby obstacles, and
• implement a high-level control law that decides which low-level control law to employ at a given time (PD or steering).

Project Components

Part 1: Microcontroller Circuit

Part 2: Proportional Derivative Control

Create a function that will implement a proportional-derivative controller:

void pd_control(int16_t error, int16_t rotation_rate, uint8_t forward_thrust) where error is the heading error, rotation_rate is the rate of craft rotation, and forward_thrust is the total forward thrust that should be generated by the left/right fans combined (this latter value will be between 0 ... 127)

This function will:

• compute a left/right differential control signal for the fans using the proportional-derivative control law and the heading error and current rotation rate (note: you should include an error deadband and maximum value),
• add this differential control signal to the forward_thrust input,
• set the duty_left and duty_right global variables (note: make sure that these never fall outside the range of 0 ... 127).

Note: you are strongly encouraged to use integer math instead of floating point math.

Notes on tuning the PD control parameters:

• Start with Kv = 0, and slowly bring Kp up to a reasonable level. You will see oscillations (this is ok for the instant)
• If the craft turns away from the goal, they you have the sign wrong on Kp.
• When you have oscillations, your choices are to: increase Kv or reduce Kp. Make adjustments slowly.
• If the craft accelerates uncontrollably, then you probably have the sign of Kv wrong.
• There is such a thing as Kp being too high. This comes from the fact that from one control decision to the next there is some amount of delay. The larger the delay, the larger the oscillations. In this case, your only choice is to drop Kp (and likely Kv, too).

Part 3: Steering Control

Note: this part will count for one personal programming credit

Create a function that will implement a steering controller:

int8_t steering_control(uint16_t distance_left, unt16_t distance_right, int16_t rotation_rate, uint8_t forward_thrust) distance_left and distance_right are the distances (in mm) to the nearest obstacle for the left and right sensors, rotation_rate is the rate of craft rotation, and forward_thrust is the total forward thrust that should be generated by the left/right fans combined (this latter value will be between 0 ... 127)

This function will:

• compute a left/right differential control signal for the fans using the difference in the left and right distance sensors. In particular the differential should steer the craft away from the nearest obstacle (note: you should include a difference deadband and maximum differential),
• add this differential control signal to the forward_thrust input,
• set the duty_left and duty_right global variables (note: make sure that these never fall outside the range of 0 ... 127).

• For large distances (e.g., > 50 cm), no change should be made to the thrust fan commands and the return value should be -1
• For small distances (e.g., < 10 cm), the craft should produce zero thrust and return a value of zero
• Under all other conditions, the return value should be 1

Part 4: High-Level Control

Note: this part will count for one personal programming credit

For this part, you will implement a high-level control loop that will cycle once every 50 ms. For each of these control steps, the hovercraft will first steer away from obstacles (while moving forward). If there are no obstacles, then the hovercraft will steer toward the goal heading (also, moving forward).

• Configure an Overflow ISR so that it sets a global variable flag to a value of 1 (one) every 50 ms.

• Modify the your main function such that it is structured as follows (you will of course need to add other code):

  int main(void) {
         int16_t counter = 0;
         int16_t heading, heading_goal, heading_error;
         int16_t rotation_rate, distance_left, distance_right;
         
         #APPROPRIATE VARIABLE DECLARATIONS HERE#
         #APPROPRIATE INITIALIZATIONS HERE#
  
         heading_goal = get_orientation();
         middle_thrust_dir(1);
  
         #RAMP UP MIDDLE THRUST TO HOVER#
  
         while(counter < 20*30) {              // 30 seconds
             heading = get_orientation();
             heading_error = compute_error(heading_goal, heading);
             rotation_rate = get_rotation_rate();
             distance_left = get_left_sensor();
             distance_right = get_right_sensor();
  
             // Display
             if(#SWITCH OPEN#) {
                  display_orient(heading);
             }else{
                  display_orient(heading_error);
             }
  
             // Steer away from obstacles
             status = steering_control(distance_left, distance_right, #PICK SOME SMALL VALUE#);
  
             if(status == -1) {
                  // No obstacles: steer to desired direction
                  pd_control(heading_error, rotation_rate, , #PICK THE SAME SMALL VALUE#);
             }
  
             // Increment time
             ++counter;
  
             // Wait for the flag to be set (once every 50 ms)
             while(flag == 0) {};
  
             // Clear the flag for next time.
             flag = 0;
         }
  
        // Shut down hovercraft
        duty_left = 0;
        duty_right = 0;
        #RAMP DOWN MIDDLE THRUST TO ZERO#
        while(1){};   // Spin forever
  }
  
  
  

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 pd_control(),
    • your software solution for steering_control(),
    • 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 4 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 4 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: Wed Mar 30 23:48:46 2011