WEDNESDAY

Zhuoyue swooped in with an incredible automatic tracking system, which ran off a camera and enabled our machine to recognize a person and turn toward them before and while launching.



Meanwhile, Alexia and Jessica finished their final iteration for the marble deployment mechanism. Alexia’s contained marble ramp was equipped with a gravity-driven trapdoor. Jessica’s code would trigger a servo to open its latch when a human was detected.

And it worked! Beautifully. It sent marbles scattering everywhere to trip our poor boobytrap victim.

Before we get to the actual assembling, we took a quick tea break:

Assembly Process

We started off by placing the marble team’s box and the fan into the metal frame Taili built. Arthur, Treyden, and Cedric finalized the mechanisms of the input devices and how many boards would be installed in the design.



At the lab, it was mayhem indeed:



And look at those smiles :)



Meanwhile, Claire and Noy were figuring out the dispenser system. Noy cut PVC to length while Claire screwed the 3D printed feet to a few sheets of OSB. This wouldn’t be the final platform, but we needed the rigidity of a base in order to organize the rest of the structure correctly.



Once the PVC was in place along with Arthur’s 3D printed mounts, we discovered an issue: the follower didn’t quite make contact with the driver. We experimented for a while as a group before Noy cut two wooden pieces and drilled a hole in them for the rolling mechanism to stand. In order for the PCB’s to be able to be placed on the structure, Selin cut a piece of plexiglass and mounted the boards on it. Selin, Danny and Sondos tried to find the right drill for this process.

We had some difficulties in finding the right power source for our system. The boards needed more than 2A to start the movement. Treyden, Arthur, Cedric and Selin placed the boards and connected each one of them to separate USBs.



Then Treyden started the process of checking if the boards are functioning properly. We toiled through some debugging in order to get everything functional, but finally did! The last step was to transfer the dispenser subsystem to the more polished plate. We cut one corner off the square, base, but found that the plate sat lopsided due to unequal weight distribution. There was some back and forth about whether to shift the balance point underneath the system or to cut off the diagonally opposite corner as well to balance things out. We eventually settled on the latter, and things worked! HOORAY! Lots of cheering ensued.

INPUT TEAM

Once we had decided on building a TP shooter with a marble trap, the input team (Treyden, Cedrick, Caine, Selin, Kia, Zhuoyue, & Arthur), started considering the inputs of the device and which sensors would be the best fit for the tasks. With the goal of creating a Home Alone inspired machine, some thoughts that immediately came to mind were how we would detect an intruder, how we will target the intruder, how the traps will be triggered, and more. The features and execution plans we initially considered were:



Firing Speed:

• The firing speed was initially intended for us to be able to vary the speed of the motor that would be firing the tissue paper. This would affect how far the toilet paper is to be shot. We initially considered a potentiometer or a joystick to control this function.
• We decided not to control firing speed as it did not seem to have a great useful effect on tissue firing.

Firing toiler paper:

• For input to control toilet paper dispensing, we wanted to have a toggle that would control if the dispensing would be automated or manual. Manual would allow for firing to occur along with the manual controlling of the positioning to target and fire. Automation would allow us to run at a default speed where the toilet paper could be dispensed for a certain amount of time or user tracking.
• A button will be used for this toggle. 

Rotation on the Z axis:

• We wanted the shooter to be able to work like a tank. For rotation around the z-axis, it would enable us to direct the shooter to the left or right for targeted firing.
• We decided that a potentiometer or joystick should be used for the input values that will control the output of the motors.

Rotation tilt:

• Tilting would give us the ability to move the firing head up and down for a wider firing range. We decided that a potentiometer or joystick should be used for the input values that will control the output of the motors.
• We decided not to have motion in this direction for the scope of the machine and to fit into the timespan we have.

Reverse mode:

• A key consideration was that we didn’t want to waste a ton of toilet paper, so we wanted to be able to reverse the toilet paper roll after firing. We realized that this could be controlled by the same toggle that will trigger the dispensing of toilet paper.

Track Target:

• A consideration was to use facial recognition and body/person tracking to control the direction of the firing mechanisms and dispensing. This would give us the ability to follow a person and fire at them while they are detected. The direction of the tilt and rotation plus the firing mechanism would be triggered by the detection, which has the added benefit of tracking versus only detecting.

Driving:

• In initial considerations, we considered having the shooter be mobile on four wheels. The idea behind that decision was that the machine could follow an intruder to continue firing toilet paper. We planned to use joysticks to control the drive motors as an easy way to drive around.
• We decided this was out of scope for the timeframe but would be something to do in the future.

When empty/time to reverse:

• In order to not waste a ton of toilet paper, we wanted to be able to rewind up the toilet paper roll. This means that we would need to detect when the paper runs out. We ideated on a couple of input options for this challenge.
• Gyroscope
• Using the measure of orientation and angular velocity to determine the amount of rotations it would take for the toiler paper roll to be finished, then that variable can be used to know when the limit has been reached and to trigger reverse.
• Magnet
• Using a magnet was a solution designed to allow us to create an encoder on our motor. From there we could design a counter based on the electrical signal and utilize that to control when the motor is reversed.
• Motor with encoder
• A motor with an encoder already on it would allow us to count the amount of rotations it would take to empty the roll. The benefit is that the motor has an encoder.
• The dispensing mechanism team let us know that the motors we had available with encoders did not have the power needed to dispense the toilet paper at the desired ideal rate.
• Light sensor
• light sensor could be used to detect the change in color between the white or the toilet paper and the brown of the roll.
• Scale
• Detecting the weight of the toilet paper roll changing using a pressure sensor or scale was considered.
• We opted against the option due to variations in toilet paper rolls and a lack of options for placement in the mechanical design.
• Offset switch
• This idea was to have a clamp under the toilet paper roll tube and on top of the toilet paper. Once the clamp was within a certain range or pressing together on both ends, it would trigger the reversal.
• This idea was not compatible with the desired mechanical design, and we were hesitant about how the reversing of the role would be able to go smoothly. It seemed more complicated than it needed to be.

Intruder detection

• We needed to detect when a person was within a certain range to trigger the machine's start. The PIR and ultrasonic sensors were considered for this. The PIR detection uses heat to detect when a person is within a wide range. The ultrasonic sensor worked similarly since it sent out a signal to echo back, which is used to calculate the distance of an object.

Testing

We began by testing the sensors. We started with an Adafruit ItsyBitsy, and collected the desired input devices, a breadboard, and wiring needed to get the data feedback from each device.



Unfortunately, this was unsuccessful, and the board did not appear through usb or on Arduino.



Next, we went to the parts that we were given for the week and soldered the pin out board.



We spent some time troubleshooting, we had some floating pins and poor connections. Once this was fixed, we were able to bootload and program this board.



After the board was made to be able to be programmed, we collected the sensors and a breadboard to begin coding in Arduino to observe their data outputs.



PIR

• The PIR sensor was very sensitive and did not seem to accurately read the detection of a person. We created a shielded tunnel for it which increased the detection accuracy. We adjusted the potentiometers on the PIR to adjust the sensitivity and timing delay. With changing and manipulating these features, we were able to get a fairly responsive reading. We connected an LED that was triggered when an object was detected to give more visual output since we were reading values from all of the sensors.

Ultrasonic

• The ultrasonic sensor had the benefits of being able to adjust the ping rate and distance from the object that we wanted to detect. This gave us a more focused range, but the timing delay did not allow for the program to be responsive as quickly as we would like. We concluded that the ultrasonic may be best for close range detection

Button, Switch

• This worked effectively, returning values of 0 and 1 depending on the state.

Potentiometer

• The potentiometers worked and displayed the desired range of values based on turning.

Boards

Next, we utilized the provided boards to support the different desired inputs. We created the firmware for the pin out board we soldered to use with the PIR sensor. The other boards provided that we used are the potentiometer board, button board and motor board. Modular things allowed us to flash the boards and then program them to talk to eachother. Once the usbs are connected to the same device they are able to send data to and from one another as needed.



Here’s the set up for and part of the code the code we used in modular things.

//—------------------- 

//This is the code for the breadboard // button // potentiometers // and motors 

const div = document.createElement("div"); 

div.style = ` 

    padding: 10px; 

    background: lightblue; 

    color: black; 

    height: 100%; 

` 

div.innerHTML = ` 

    on 

` 

const lightSwitch = div.querySelector(".light-switch"); 

turnt.setCurrentScale(0.75) 

turnt.setStepsPerUnit(30) 

turnt.setVelocity(200) 

turnt.setAccel(750) 

let counter = 1; 

let value = 0; 

lightSwitch.addEventListener("click", () => { 

    value = value === 0 ? 1 : 0; 

    mossyBoi.setGate(value); 

    lightSwitch.innerText = value === 0 ? "off" : "on"; 

}) 

snowflake.onButtonStateChange((state) => { 

    if (state) return; 

    iawgz.setpin(counter % 2); 

    counter++; 

}) 

loop(async () => { 

    const data = await Promise.all([ 

    harvardpot.readPotentiometer(0), 

    harvardpot.readPotentiometer(1) 

    ]); 

    console.log(data[0]); 

    turnt.absolute(-data[0]*10); 

}, 30) 

render(div) 

//—-------------------- 


                                  

These are the three boards we used:



And these were all mounted on clear sheet of PVC which was then mounted on the side of the machine.



There was some trouble with powering the board. We tried various power supplies before settling on using the voltage regulator to provide the needed 4amps.

Facial Recognition & Tracking

Using modular things, allows us to talk to the motor using facial recognition software. Opencv.js (an open source computer vision and machine learning software library) was implemented into the module to do facial tracking, then the information was written to the motor. The motor's direction depends on the face location within the screen. The screen is divided by the center (i.e face on the left then the motor turns left. Face on the right then the motor turns right.) The face detection information is used to update the direction variable every second. Initially, we wanted to have two motors to do up/down &left/right, but with the decision to have one motor, we only look based on the vertical center line.