Embedded Files
Final images
Final images
Note: these purple boxes are instructions to you to make the documentation, and should not be included in your final submission!
Overall photo for proportion and scale (one per team member)
A clear picture of student 1's transducer with a brief caption and appropriate alt text
A clear picture of student 2's transducer with a brief caption and appropriate alt text
Detail photos
Detail photos
Detail photos of any part that you’d like to highlight (two to five between the team members)
Detail photo 1 with caption and alt text
Detail photo 2 with caption and alt text
Detail photo 3 with caption and alt text
Detail photo 4 with caption and alt text
Final project movies
Final project movies
Brief movie which shows the machine working, i.e. reading an input, passing the data internally, and then driving an output.
Your video should at least show a fixed view of the whole board, with a range of inputs running through to the output, and a clear view of the LCD screen while that happens so we can all see what the Arduino is thinking. You can narrate if you want, but it's not necessary. You may optionally also zoom in to show different aspects of the board running. Film in landscape (horizontal) rather than portrait (vertical). Upload your video file to our class's shared drive and then add it to this page by clicking "Drive" under the Insert pane. (To find the shared drive: go to drive.google.com, expand the "Shared drives" listing on the left column, and select "60-223 s26".)
(one movie per team member)
Zach project 1 video.MOVStudent 1 documentation video with caption.
Zach project 1 video.MOVStudent 2 documentation video with caption, same advice and requirements as listed above.
Narrative description
Narrative description
Write a simple narrative description (one per team) of the thing and usual operation of the thing—the type of plain and straightforward description that you might write in a letter to a child to explain what you had made. Free of judgment and totally literal and straightforward. Try to use as little technical language as possible. (E.g. “A white plastic box has a switch on the top side. When the user turns it on, a green LED flashes five times showing that the system is ready. A small white flag waves back and forth.”) For a study in the art of using simple language, see Randall Munroe’s wonderful Up Goer Five. To use a simple-language filter yourself, try the Up-Goer Five text editor. Reminder: do not use any generative AI to help write this section.
Progress images
Progress images
Four progress images (two per student), each of which could be a step or misstep that happened along the development process, and each with a caption that’s at least a sentence or two long. These images may capture decision points, especially interesting or illustrative mistakes, or other mileposts along the way. The idea is that these medium-quality images (though good pictures work too) are taken along the way to document progress. Sometimes you might understand these as being moments-that-matter only in retrospect!
Each image with caption and alt text.
Each image with caption and alt text.
Each image with caption and alt text.
Each image with caption and alt text.
Discussion
Discussion
Discussion (one per team) pertaining to process and outcome. For instance, what was easy, what was hard, what did you learn? What little tweak, in retrospect, would’ve changed the direction entirely? This is an opportunity for you to reflect on your creative and technical growth through the project, and think about what growth you want to aim for next. This shouldn’t be a recital of your process, but rather a meaningful reflection, 3–4 paragraphs in length. Reminder: do not use any generative AI to help write this section.
Functional block diagram and electrical schematic
Functional block diagram and electrical schematic
Functional block diagram and schematic (one per team), drawn in draw.ioref.org using the conventions we discussed in class. Be sure that the images aren't cropped incorrectly (Google Sites will tend to crop without telling you as you resize images.) Samples shown below.
Code
Code
Code submission (one per team), embedded into the project page, and optionally also with a Github or other version control service public-facing link. Your code should be reasonably commented throughout so that people other than you (the author) can better understand it. You don’t need to explain every single line—that would be overkill—but leave useful notes in a reasonable measure. Write a comment block at the top of the code including:
the project title,
(optionally) your names,
a description (short or long) of what the code does,
a pin mapping table that would be useful to somebody else trying to recreate your work (this is a simple table that lists all of the connections to the Arduino pins),
appropriate credit to any other person’s/project’s code that you incorporated into your project, and
(optionally) a license notice (i.e. copyright, CC BY-SA 4.0, the MIT License, release it to the public domain, or just follow your heart). If you have written code that you wish to keep strictly proprietary for any reason, please speak with the instructor about an exception to this documentation requirement.
/*
Arduino code basic structure sketch
Demonstrates how to structure an Arduino sketch so that
the loop contains four basic elements:
1) read inputs (gather information from the world)
2) compute and make decisions based on those inputs
3) drive outputs (effect different actuators in the world)
4) report information back to the user
While not every interactive device necessarily needs all
four of these steps in the loop, many often do.
For the purpose of this demonstration sketch, this code
is written for a device that will read a button as an
input and drive an LED as an output. When the button is
held down, the LED will be brighter, and when the button
isn't held down, the LED will be dimmer.
Pin mapping:
Arduino pin | role | details
------------------------------
5 input momentary button
8 output external LED
Released to the public domain by the author, January 2024
Robert Zacharias, rzachari@andrew.cmu.edu
*/
/* Pin mapping section of code, creating variables to store
pin numbers. Note that the "const int" data type is used
instead of plain "int" because the pin numbers are
constant--they will never change in the code.
All-caps names are used by convention for variables whose
values won't change.
*/
const int BUTTON_PIN = 5;
const int LED_PIN = 8;
void setup() {
/* We need to ensure that the pins are set up for their
electrical roles as input or output. (Note that it is
possible to change pin mode in the loop, but usually you
don't need to do that so it's easier to do just once in
the setup.)
*/
pinMode(BUTTON_PIN, INPUT);
pinMode(LED_PIN, OUTPUT);
/* We also need to turn on the serial library so that the
Arduino will be able to send data back to the computer.
*/
Serial.begin(9600);
}
void loop() {
/* Step 1 is gathering information from the world and
saving it into whatever variable(s) are appropriate.
*/
// create an "int" variable called "buttonState" with
// a starting value of 0
int buttonState = 0;
// Actually read the button pin and find out if the button
// is pressed or not, then save the result into buttonState.
// We use the command "digitalRead" to tell the Arduino to check
// if a certain input pin has a LOW (0V) or HIGH (5V) voltage.
buttonState = digitalRead(BUTTON_PIN);
// At this point buttonState will be "HIGH" (if the button was pressed)
// or "LOW" if it was not.
/* Step 2 is using gathered data to change different variables,
or doing "math" (can take many forms) to make decisions
*/
// make an "int" variable to store the brightness of the LED
// using a starting value of 0
int ledBrightness = 0;
// change the value of ledBrightness based on whether or not
// the button was pressed
if (buttonState == HIGH) { // if the button was pressed
ledBrightness = 200; // make ledBrightness store 200, i.e. bright
}
else if (buttonState == LOW) { // otherwise, if the button wasn't pressed
ledBrightness = 30; // make ledBrightness store 30, i.e. dim
}
/* Step 3 is driving outputs, in this case lighting the LED */
// The command "analogWrite" will tell the Arduino to adjust the
// brightness of the attached LED.
analogWrite(LED_PIN, ledBrightness);
// Step 3 is very simple in this sketch; that line is all there is to it.
/* Step 4 is reporting information back to the user, and in this
case we'll use the serial monitor (a display on the attached computer
screen) to know what the Arduino is thinking.
*/
Serial.print("buttonState = "); // just write that text to the screen
Serial.print(buttonState); // then send the value of the variable
Serial.print(", ledBrightness = "); // write that text to the screen
Serial.println(ledBrightness); // send the value of the variable
delay(10);
}
Page updated
Report abuse