AME 3623: Project 8: Position-Derivative Control

• All components of the project are due by Thursday, April 16th at 8: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:

• tune PD-control parameters so as to achieve near critically-damped behavior of the hovercraft.

Component 1: Hardware

• If you have removed the switch from your circuit, please add it back.

• Balance your craft so that when the chamber is pressurized, the craft does not drift substantially (note that it will rotate if you are not actively controlling lateral thrust).

Component 2: Software

Implement the following function:

• void pd_control(int16_t forward_thrust, int16_t error, int16_t rotation_rate) synthesizes your previous p_control() and d_control() implementations, adding an additional signal for net forward thrust. The implementation will be along the lines of:

         int16_t thrust = Kp * error - Kv * rotation_rate;  // Your exact implementation may vary
         set_side_motor_magnitudes(forward_thrust - thrust, forward_thrust + thrust);
         

Structure your main() function as follows:

1. Initialize and read current heading to use as the goal.

2. Wait for the switch to be pressed. While waiting, read both the gyro and compass, displaying both rotation rate and heading error.

3. Ramp up middle thrust until the craft begins to rotate.

4. Wait for the switch to be pressed again. While waiting, execute the following control loop:
   • Read the sensors
   • Display rotation rate and heading error
   • Generate control signals to maintain heading goal (forward_thrust = 0)
   • (remember to use flag_timing to ensure that your control loop executes at a reliable rate)

5. Wait for 5 seconds, then set forward_thrust to something positive (and interesting) for another 5 seconds. While waiting, perform the same control loop as above. Note that you will be able to use the "counter" variable to make the decision of when to turn on forward thrust and when to stop this loop.

6. Turn off all fans

7. Enter infinite while() loop.

Component 3: Testing

• At the end of the previous project, you should have a reasonable choice of Kp. This should cause your craft to be relatively aggressive about moving toward the heading goal, though it will likely oscillate around the goal (perhaps damped, perhaps not).

• Slowly increase Kd until most of the oscillation has been removed.

• After tuning, the craft should be able to recover from disturbances from the heading goal. In addition, as the heading error approaches and then crosses 180 degree error, the thrust fans should flip polarity (e.g., shifting from hard right to hard left).

• Remember that fprintf() is an expensive operation in terms of time. Although useful for debugging, it can cause problems when used inside of a control loop.

What to Hand In

• Demonstration/Code Review: All group members must be present. Given time, this can be done during class.

• Check in the following to your group dropbox on D2L for project 8:
  • Documented code:

    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. At the top of your C file, document the project number, group members, date and the group member responsible for the code.
    2. 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)
    3. In-line comments should be used to describe logically what is happening at that line or group of lines.

• Personal report: fill out the CATME survey. This is due by Monday, April 20th at 11:59pm.

Grading

• Each person must accumulate at least three personal programming credits over the course of the semester (this project offers two). This can be one person or split across two people. Their individual contributions must be clearly documented.

• 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."

• 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

• OUlib documentation

andrewhfagg -- gmail.com

Last modified: Thu Apr 9 08:04:15 2015