AME 3623: Project 1

• All components of the project are due by Thursday, February 16th at 8:55 am
• Discussion within your assigned 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:

• create simple microcontroller-based circuits,
• read digital information from a switch, and
• convey information using a set of LEDs.

Circuit Overview

• one Teensy 3.5 with supporting hardware,
• two motor driver boards for control of the fans (12 digital lines),
• two switches (2 digital lines),
• four LEDs arranged in a circle (for indicating heading and heading error; 4 digital lines), and
• ten LEDs arranged in a line (for indicating heading velocity or sensed distances; 5 digital lines).

Not on the breadboard, but connected to it will be:

• four ducted fans,
• one inertial measurement unit (1 I2C connection)
• two analog distance sensors (2 analog inputs), and
• a power system.

Component 1: Microcontroller Circuit

• Mount your Teensy board to the solderless breadboard. The USB connector should hang off one edge of your breadboard.

• Add a set of 4 LEDs that will be used to display the current heading of the craft (organized in a circle). Each of these LEDs should be driven by a digital output pin (all of the same port). We recommend that these LEDs be mounted near the Teensy board and that one LED be of a color different than the other three (this one will correspond to a heading around zero degrees).

• Add another set of ten LEDs that will be used to display the heading velocity (you have been supplied with a 10-LED "bar graph" module). Each pair of LEDs should be driven by a digital output pin. We recommend that these LEDs be mounted near the Teensy.

• Add a switch. One end of the switch will be connected to ground, the other to a digital input pin. This pin should also be "pulled up" to +3.3V using a 10 K-Ohm resistor. We recommend that the switch be mounted on the edge of the breadboard opposite from the Teensy

Component 2

• void display_heading(int16_t heading) changes the state of the heading LEDs to reflect a heading. The range of the input parameter is -1799 and 1800, encoding tenths of a degree in a left-handed coordinate system. Notes:
  1. Eight different heading ranges must be displayed with different lighting of the four LEDs

  2. For a given call to this function, you must execute exactly one assignment to GPIOx_PDOR (i.e., only one "GPIOx_PDOR =" line will be executed, though there may be several different assignments that are possible, depending on the conditions).

  3. Only the bits corresponding to the four heading LEDs may change state with this function call.

• void display_heading_velocity(int16_t velocity) will change the state of the ten LEDs (and no others) to reflect the current heading velocity. velocity is in 10ths of a degree per second and has a range of +/- 3000. Notes:
  1. For a given call to this function, you must execute exactly one assignment to GPIOx_PDOR.

  2. Only the bits corresponding to the five LED pairs may change state with this function call.

• In your main() function:
  • If the input switch is in one state: slowly increment heading from its minimum to its maximum value in 1-degree increments and display it. This value wraps-around when it reaches its maximum value.

  • If the switch is in the other state: slowly increase the heading velocity from its minimum to its maximum value in 1-degree-per-second increments. This value wraps around when it reaches its maximum.

What to Hand In

• Code: Check your documented code into your subversion tree.

  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 number, group members, date and the group member responsible for the code.

  2. Each function must be documented (above the function header) 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 must also be documented here.

  3. In-line comments must be used to describe logically what is happening at that line or group of lines.

  See an example.

• Demonstration/Code Review:
  • The review triggers the grading process.

  • The review must be completed by the Monday following the deadline. However, the sooner you have feedback, the better prepared you will be for the next project.

  • The code and circuit must not have changed since the deadline (unless your group is taking a time penalty).

  • All group members must be present.

  • If a code review is completed before the deadline, you have the option to resubmit for an improved grade, as long as the submission is done before the deadline. Note that the resubmission may require a new code review.

• Personal report: fill out the CATME survey. This will be due shortly after the deadline. These personal reports are used to provide feedback to you and your group members.

Grading

• 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." If another group member must make dramatic changes to your code to get it to work, then this will not count as your personal component. For the most part, personal programming credits are checked off or not (checked off = full grade credit).

• 35%: Project implementation
• 30%: Demonstration of working project (to either of the TA or the instructor)
• 35%: Code 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. Generally, this weighting will be uniform across the entire semester.

andrewhfagg -- gmail.com

Last modified: Thu Feb 9 09:21:27 2017