"Hi Thirsty Plant!"

Note: these blue boxes are instructions to you to make the documentation, and should not be included in your final submission!

1b. A photo that is a good overall view of the project. This image should be one of the "well-shot" images described below, or a cropped subset of one of them.

The "Hi Thirsty Plant!" device connected to two plants. The hand is placed above the sensor, indicating how to trigger the water pump.

Remember to include alt text for visually disabled readers!

1c. A brief explanation of the project. This should be short and sweet.

This project helps me to learn how to add binary numbers up. Each of the vertical toggle switches represents one of the powers of two, so the rightmost switch is the ones, the next one over is the twos, the next over is the fours, and so on. The horizontal switch at the bottom changes the board back and forth between decimal and hexadecimal representation of the sum.

1d. At least four good still images of the final project. If it's possible for you to take higher-quality image, like using a DSLR (here's the class DSLR photography guide) that's fine; but camera phone pictures are ok, too if they're carefully shot and good quality. Images:

Overall photo for proportion and scale (at least 1)
Detail photo of any part that you'd like to highlight (up to 3)
Images showing the thing being used (up to 3)

1e. Moving image (one or more), a .gif, .mp4, or .mov file. Your movie can be as short as a second or two if that's all that needed to show the interactivity of your device, but should go longer as is necessary. It can feature voice narration if you like, but does not need to.

Upload instructions: Do not merely link to an outside hosting service like YouTube and do not embed a YouTube or other video service frame into your page. Rather, the videos are inserted by uploading a video file to this Google Drive folder and then under the Insert tab on the right, selecting "Drive," then clicking on the Shared drive called "60-223 f25." By keeping video files in that Shared drive, we ensure that this documentation page will remain intact for the long term.

If the movie is not audibly narrated, a caption should describe the action of the movie so that a blind person would still be able to understand what is happening.

(Note that videos don't have captions or alt-text options on Google Sites, so you just need to write your own text boxes below them.)

IMG_8409.mov

In this video, I show operation of the machine in decimal mode, flipping different switches on to make different sums. When all switches are off, the sum is 0; when the rightmost switch is on, the sum is 1, and then when that switch is off but the next one over is on, the sum is 2; when only the third switch over is on, the sum is 4; and so on.

2. Process images and review

Your process section should have at least 4 photos each of which is captioned, and ~100–300 words describing any aspect(s) of your process you'd like your readers to know about. Did something surprise you with how well or how terribly it went? Did something take much longer than expected? Did you get lucky and something worked out unexpectedly? Tell us about it.

Add captions and alt text to your images so your reader understands their relevance and meaning.

Process

Don't forget that this section also needs a brief bit of text, ~100–300 words describing any aspect(s) of your process you'd like your readers to know about. You can interleave this with the images or put it all at the top or bottom or however you'd like.

3. Discussion

(instructions are embedded below)

Discussion

Address all of the prompts below. It is best to address all of these topics in a natural piece of prose. However, if you prefer, you may write four disjoint paragraphs, each of which is addressing a prompt. (The first way is better.) In total, this section should be ~300–500 words.

A reminder that as outlined in the course syllabus, you are strictly prohibited from using any generative AI service or writing assistant in your reflection/discussion.

Response to comments gathered during the in-class crit. Quote (verbatim) from *at least* two written critiques that you received (positive, negative, or otherwise) from the in-class crit, and respond to them. (You may agree or disagree—in either case, explain your position.) You can access the written critique feedback by going to the class's Shared Drive and opening "11/5/25 Project 2 Final Critique feedback".
Self critique pertaining to the project. Are you happy with how the project came out? Did it satisfy your own goals? This *should not* simply be a recital of your process, but rather a meaningful reflection.
What you learned about your own abilities and/or limitations through the process of working on this project. These could be technical in nature (i.e. "I found that coding this particular behavior was surprisingly difficult"), or not (i.e. "I enjoyed making cardboard forms very much, and I think it will be a useful prototyping medium for me in the future"). What would you do differently next time? What would your advice to your past self be? Did you get hung up at a particular point in progress, or fail to see an easy workaround to a problem? Did you find a creative spark you didn't anticipate? Etc.?
Next steps. Do you expect to build another iteration of this project? If so, describe what you're planning to do. If not, describe what you *would* do if you were to build another iteration, based on the experience you had with this first one.

4. Technical information

4a. Include **schematic and block diagrams**, drawn in https://draw.ioref.org, and exported from that software as .png images.

The block diagram should legibly show all inputs, computational steps, and outputs of your project. The schematic should be done so that a competent person, reading your drawing and with the appropriate parts, could recreate the electrical system of the project. For both schematics and block diagrams, follow all of the standards described on the course schematics guidance page.

Technical information

4b. Code submission, embedded into the project page

Optionally also including 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 name,
a description (short or long) of what the code does,
a description of pin mapping that would be useful to somebody else trying to recreate your work,
appropriate credit to any other person's/project's code that you incorporated into your project, including specific description of any generative AI service you used to help with the code, and
(optionally) a license notice (i.e. copyright, CC BY-NC-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.

Add your code by using a text box with the "code" formatting option.

Make sure that your final code as it appears on the public-facing post is correct and will compile!

Scotty Driver for ISAM 102 workshop

Reads an infrared ranger as input and drives a servo motor as output.

Code written for an MH-ET Live Tiny 88 board, a cheap ATTiny88 implementation.

(Note that our testing got no analog read values out of pins A0 through A5

for an unknown reason, hence using A6 as our input pin.)

pin mapping:

Arduino pin | role | description

___________________________________________________________________

A6 input attached to output leg of IR proximity sensor

3 output driving a continuous rotation servo

Code released to the public domain by the author, 10/12/2023

Robert Zacharias, rzachari@andrew.cmu.edu

#include <Servo.h>

const int PROXPIN = A6,

SERVOPIN = 3;

Servo gearDriver;

void setup() {

gearDriver.attach(SERVOPIN);

pinMode(PROXPIN, INPUT);

}

void loop() {

// read proximity value

int proxVal = analogRead(PROXPIN);

// map values to appropriate range to drive motor

int motorVal = map(proxVal, 50, 1000, 5, 175);

// ensure that the motor is never instructed to go outside

// of its mechanically possible range

motorVal = constrain(motorVal, 5, 175);

// drive the motor

gearDriver.write(motorVal);

delay(10);

}

Page updated

Report abuse