User Tools

Site Tools


Sidebar

projects

wcp1 (due 20240828)
wcp2 (due 20240904)
pct0 (bonus; due 20240905)
pct1 (bonus; due 20240905)
pct2 (due 20240905)
abc0 (due 20240906)
gtf0 (due 20240911)
pct3 (bonus; due 20240911)
wcp3 (due 20240911)
dtr0 (due 20240918)
pct4 (due 20240918)
wcp4 (due 20240918)
pct5 (bonus; due 20240926)
stl0 (due 20240926)
wcp5 (due 20240926)
gfo0 (due 20241002)
pct6 (due 20241002)
stl1 (due 20241002)
wcp6 (due 20241002)
pct7 (bonus; due 20241009)
stl2 (due 20241009)
wcp7 (due 20241009)
bwp1 (bonus; due 20241016)
pct8 (due 20241016)
ptb0 (due 20241016)
wcp8 (due 20241016)
pct9 (bonus; due 20241023)
ptb1 (due 20241023)
wcp9 (due 20241023)
gfo1 (due 20241030)
pctA (due 20241030)
ptb2 (due 20241030)
wcpA (due 20241030)
pctB (bonus; due 20241106)
wcpB (due 20241106)
wus0 (due 20241106)
pctC (due 20241113)
wcpC (due 20241113)
wus1 (due 20241113)
pctD (bonus; due 20241120)
wcpD (bonus; due 20241120)
wus2 (due 20241120)
bwp2 (bonus; due 20241204)
gfo2 (due 20241204)
pctE (bonus; due 20241204)
wcpE (bonus; due 20241204)
EoCE (due 20241216)
haas:fall2024:c4eng:projects:wus1

Corning Community College

ENGR1050 C for Engineers

PROJECT: Wire Up Something (WUS1)

OBJECTIVE

With your explorations from wus0, start to implement some more sophisticated, interconnected solution. This does not have to be a finished product, but it must have some level of demonstrable functionality.

Be sure to contribute useful background and operational information to this project documentation, to serve as a reference for others. Not only because contributing to project documentation factors into your results, but to show off to the class what interesting projects you are pursuing.

OVERVIEW

Your task is to:

  • discover how to hook up and operate some component we've not otherwise utilized so far throughout our explorations in the course.
  • write a program that demonstrates its functionality.
  • there will be two more parts to this project, so if you want to take a broader-term view:
    • wus0: figure out how to use some component
    • wus1: prototype some circuit putting it to greater use
    • wus2: finished product

Example:

  • wus0: figure out how to use an ultrasonic sensor
  • wus1: prototype a “useless” machine, using the ultrasonic sensor as a proximity sensor to determine if the user's hand is still near the switch (to avoid injury)
  • wus2: finished product of a “useless” machine

GRABIT

To assist with consistency across all implementations, data files for use with this project are available on lab46 via the grabit tool. Be sure to obtain it and ensure your implementation properly works with the provided data.

lab46:~/src/SEMESTER/DESIG$ grabit DESIG PROJECT

EDIT

You will want to go here to edit and fill in the various sections of the document:

WUS1

Add a section with supporting information for each project

Theremin using ultrasonic sensor and passive buzzer. First create a function to play a specific frequency. The frequency determine the pitch of a note, which is measured in Hz. The inverse of Hz is period (Hz=1/T). The period is the number of cycles or oscillations per second. To get the buzzer to play a specific note, the buzzer must oscillate at the given frequency for a note. Since you can't directly control the frequency of the buzzer, you have to simply alternate between HIGH and LOW states every “period length” of time, which will cause a vibration of the correct frequency. However, we instead use the “half period.” This is because the period in real life refers to the time it takes to complete one complete cycle, whereas the “HIGH and LOW” states for the buzzer only last for half of each period.

Foe the ultrasonic sensor, the TRIG pin receives an input form the gpio pin, which triggers an ultrasonic pulse to be sent, which is then bounced back and detected by the echo pin. The trick is to use the speed of sound in air (in cm/microsecond) to determine the time that the sound signal is sent and the time that the signal is received back to determine the distance of an object from the sensor.

The final part is bringing everything together, which includes mapping specific frequencies to distances form the sensor. Since we already have the functions for the distance and frequency, the mapping is very straightforward. It just involves using basic algebra using the variable “distance” to map the lowest frequency to the minimum distance, and the highest frequency to the maximum distance.

Joystick and active buzzer. First create a function where the buzzer is sounded off when a button is hit. When the button is hit the active button works by generating sound through an internal oscillating circuit when power is supplied to it. Unlike a passive buzzer which requires an external signal to produce sound, an active buzzer only needs a simple on/off signal to make noise. The second step was to unhook the button and replace it with a joystick which is a component that computes the position of its handle relative to its base as values of x,y,z on a 3-dimensional plane. The x plane of the joystick was hooked up to the buzzer so when pushed down the buzzer would sound off until released

Joystick, Servo and Button First, make sure you've downloaded the appropriate files needed. This includes the Joystick, the ADCDevice, the ButtonLED, and the Sweep (servo) file from Github's Freenove Tutorial page. Then, edit your wus1 file according to the sample commands given to you by the named files, but make sure mot to copy them exactly if you want your components to interact with each other. If you want to Joystick and the servo to interact, make sure that the OUTPUT is the servo, and the INPUT is the Joystick and the buttons, as the buttons and Joystick are what will allow you to manipulate the servo as you'd like. Make sure your components are also hooked up to the appropriate GPIO pins and power supplies with the correct resistors (if needed). The goal is the have the servo rotate independent of any input until you push one of the buttons, which will make it stop, so you'll need to loop the servo command until the condition of the first button being pressed is met. Then, when the second button is pressed, and held down, you should be able to manipulate the servo using the Joystick as a reference for what angle you'd like the servo to rotate towards/away from, hence why the servo is the OUTPUT and the Joystick is the INPUT. Once the second button is released, you should have a code that will let the servo spin automatically until you push the first button again.

project idea

components

Ultrasonic Sensor: An ultrasonic sensor measures distance by emitting ultrasonic waves from the sensor head, which are then reflected back toward the sensor to be detected. The sensor determines the distance by measuring the time it takes for an emitted ultrasonic wave to be returned to the sensor. The sensor has 4 legs which are labeled GND, TRIG, ECHO, and VCC. The VCC pin receives the power from the 5V pin. The TRIG pin is responsible for controlling the generation of ultrasonic waves. The ECHO pin is responsible detecting the ultrasonic waves being sent back.

Passive Buzzer: Uses the frequency of an AC input to create an oscillating electric field. The oscillating electric field then causes a thin, inner diaphragm to vibrate, which creates sound waves. Higher frequencies cause a faster vibration and a higher pitch. A lower frequency corresponds to a lower pitch.

Joystick: The joystick is a component that computes the position of its handle relative to its base as values of x, y and z on a 3-dimensional plane. Like on a 3-dimensional graph, the y-axis correlates to forward and backwards and the x-axis correlates to right and left, while pressing the handle down like a button adjusts the calculations along the z-axis. The five pins positioned to the left of the joystick are, from top to bottom: ground, (+)5 voltage power, x-variable, y-variable, and GPIO Pin input. The x and y-variable pins are connected to an analog-to-digital converter (ADC) device used to help process the information regarding the position of the joystick controller to the computer.

Active Buzzer: The active buzzer generates a sound when it receives a voltage signal. Inside the buzzer, there's an internal oscillator circuit that produces a tone when powered. The active buzzer only needs a simple off or on signal to sound it off.

description

Passive Buzzer: Using the diagram and code from GitHub's Tutorial C, wire up the passive buzzer along with a transistor, and a button (as seen in the diagram). Copy and paste the code into a your wus1.c file (don't forget to remove the old code before pasting). Change the “void main” to “int main”, otherwise you will get a warning (Note: you can still run the program with the “void main”, however, you will get a warning when you run the “make” command). Double check the code to make sure everything copied properly and everything makes sense logically. If not, ask Matt to help explain. Once you're sure everything is correct, run your “make” command, then “./wus1”

 

SUBMISSION

To be successful in this project, the following criteria (or their equivalent) must be met:

  • Project must be submit on time, by the deadline.
    • Late submissions will lose 33% credit per day, with the submission window closing on the 3rd day following the deadline.
  • All code must compile cleanly (no warnings or errors)
    • Compile with the -Wall and –std=gnu18 compiler flags
    • all requested functionality must conform to stated requirements (either on this document or in a comment banner in source code files themselves).
  • Executed programs must display in a manner similar to provided output
    • output formatted, where applicable, must match that of project requirements
  • Processing must be correct based on input given and output requested
  • Output, if applicable, must be correct based on values input
  • Code must be nicely and consistently indented
  • Code must be consistently written, to strive for readability from having a consistent style throughout
  • Code must be commented
    • Any “to be implemented” comments MUST be removed
      • these “to be implemented” comments, if still present at evaluation time, will result in points being deducted.
      • Sufficient comments explaining the point of provided logic MUST be present
  • No global variables (without instructor approval), no goto statements, no calling of main()!
  • Track/version the source code in your lab46 semester repository
  • Submit a copy of your source code to me using the submit tool (make submit on lab46 will do this) by the deadline.

Submit Tool Usage

Let's say you have completed work on the project, and are ready to submit, you would do the following:

lab46:~/src/SEMESTER/DESIG/PROJECT$ make submit

You should get some sort of confirmation indicating successful submission if all went according to plan. If not, check for typos and or locational mismatches.

RUBRIC

I'll be evaluating the project based on the following criteria:

156:wus1:final tally of results (156/156)
*:wus1:used grabit to obtain project by the Sunday prior to duedate [26/26]
*:wus1:picture of connected circuit to project page with description [26/26]
*:wus1:picture or video of functioning circuit run by program to discord [26/26]
*:wus1:clean compile, no compiler messages [26/26]
*:wus1:program conforms to project specifications, tests component [26/26]
*:wus1:code tracked in lab46 semester repo [26/26]

Pertaining to the collaborative authoring of project documentation

  • each class member is to participate in the contribution of relevant information and formatting of the documentation
    • minimal member contributions consist of:
      • near the class average edits (a value of at least four productive edits)
      • near the average class content change average (a value of at least 256 bytes (absolute value of data content change))
      • near the class content contribution average (a value of at least 1kiB)
      • no adding in one commit then later removing in its entirety for the sake of satisfying edit requirements
    • adding and formatting data in an organized fashion, aiming to create an informative and readable document that anyone in the class can reference
    • content contributions will be factored into a documentation coefficient, a value multiplied against your actual project submission to influence the end result:
      • no contributions, co-efficient is 0.50
      • less than minimum contributions is 0.75
      • met minimum contribution threshold is 1.00

Additionally

  • Solutions not abiding by spirit of project will be subject to a 50% overall deduction
  • Solutions not utilizing descriptive why and how comments will be subject to a 25% overall deduction
  • Solutions not utilizing indentation to promote scope and clarity or otherwise maintaining consistency in code style and presentation will be subject to a 25% overall deduction
  • Solutions not organized and easy to read (assume a terminal at least 90 characters wide, 40 characters tall) are subject to a 25% overall deduction
haas/fall2024/c4eng/projects/wus1.txt · Last modified: 2024/11/05 12:14 by wedge