Team B: Group 10
2025 USC Discover Engineering
Matthew Ren, Ritvik Satapathy, Kerim Reka, Aiden Wu, Neel Sodhi
Embedded Files
Week 1: Windmill Project
Civil Engineering
Civil Engineering
Civil engineering is a field of engineering surrounding the design and construction of infrastructure that supports civilization. Some examples of this infrastructure includes buildings, roads, bridges, airports, railroads, tunnels, and resource management facilities. Civil engineers undertake such projects through different sectors of civil engineering: structural engineering, which involves designing structures that support and carry loads; geotechnical engineering, which involves evaluating earth materials and natural foundations; water resources engineering, which involves the treatment, transportation, and storage of water; and transportation engineering, which involves transporting people and goods in safe and efficient ways through the use of public transportation, ports, railroads, etc.
Environmental Engineering
Environmental Engineering
Environmental engineering is a field of engineering that deals with protecting civilization from negative effects from the environment, as well as protecting the environment from the negative effects of civilization. Environmental engineers generally tackle problems regarding pollution (air, water, and noise), waste and water treatment, and environmental disaster cleanup. To solve these problems, environmental engineers often monitor the environment by performing quality-control checks, evaluate the environmental impacts of proposed construction projects, and design facilities to treat waste and water.
Building Science
Building Science
Building Science is a field of engineering that is a sector that provides people with better indoor environmental quality for comfort and satisfaction. Engineers use both quantitative (measurements and simulations) and qualitative (surveys and case studies) methods to figure out the best indoor thermal environment, indoor acoustic environment, indoor light environment, indoor air quality, and building resource use. In the end, engineers want to optimize the building performance and sustainability of new and existing buildings
Design Process
Design Process
Ideal:
Define the problem
Generate alternative solutions
Evaluate and select a solution
Detail the design
Defend the design
Manufacture and test the design
Evaluate the performance of the design
Prepare the final design report
Actual:
Define the problem
Generate alternative solutions
Evaluate and select a solution
Detail the design
Manufacture and test the design
Evaluate the performance of the design
Prepare the final design report
(Followed a very trial-and-error design process that did not involve defending designs before manufacturing)
Video 1 of Tested Windmill
Video 1 of Tested Windmill
(Footage from in-class test)
Video 2 of Tested Windmill
Video 2 of Tested Windmill
(Footage from Windmill Olympics test)
Discussion Response Zoom Recording
Discussion Response Zoom Recording
Research Paper Link 1: Windmill Design Process Paper
Research Paper Link 2: Alternative Energy Sources Pros/Cons Paper
Week 2: Patient Monitor
Website Link: Week 2
(accidentally documented the second week on a different Google Site)
Week 3: Stage 1 Rocket
Aerospace Engineering
Aerospace Engineering
Aerospace engineering involves the designing, developing, and testing of aircraft and spacecraft such as fighter jets, commercial transport (passenger/cargo planes), helicopters, or even rockets and missiles. Aerospace engineering skills are also applicable to automobiles when optimizing a vehicle's aerodynamics and thus fuel efficiency. Aerospace engineers, like those in other engineering disciplines, typically work under mentors that are experienced engineers before they become more advanced and experienced enough to work on more challenging projects. Eventually, they may promote to a position of experience where they supervise technicians or other engineers. Some common tools that aerospace engineers utilize in their projects such as computer-aided design (CAD) software, lasers, electronic optics, and robotics. As for work environments, aerospace engineers have great versatility in where they can work; they can be found in office environments, research facilities, radar stations, launch sites, or even military installations.
Chemical Engineering
Chemical Engineering
Chemical engineering is a field that combines biology, chemistry, and math and applies them to create products. These products are more or less everything in our day to day lives: pharmaceuticals, processed foods, biotechnology, oil and gas, materials such as plastics and fibers, and more. Chemical engineers apply their knowledge to create new substances that aid humanity. Such projects may involve designing eco-friendly plastic, Covid-19 vaccines, water purification systems, oil refinery systems, and producing clean energy. Chemical engineers often work in laboratory settings where substances are simulated and tested to see if they can be applicable and effective.
Mechanical Engineering
Mechanical Engineering
Mechanical engineering is the engineering discipline that deals with the design, analysis, manufacturing, and maintenance of things that move, have moving parts, or transfer heat. Mechanical engineering heavily applies physics, math, and material sciences concepts in its line of work. Mechanical engineers have goals of optimizing components such as engines and fuel systems to be as clean, efficient, effective, reliable, and safe as possible. Mechanical engineering is such a broadly applicable discipline that mechanical engineers can work in the automotive, aerospace, military, robotic, environmental, and industrial sectors.
Industrial Engineering
Industrial Engineering
Industrial engineering involves optimizing systems and workflows for cost-efficiency and productivity. Their line of work applies to fields such as manufacturing and factory production, healthcare, and logistics. Industrial engineering is similar to mechanical engineering in the way that both commonly involve application of STEM knowledge, and both enjoy versatile field applications and global career paths. Industrial engineers work with systems ranging from complex ones such as factory lines, hospital patient flow optimization, and warehouse layout, to even simple ones such as how people line up for something.
Research Paper Link 3: Airplane Design, Rocket Design, and Sensor Detection Paper
Straw Rocket
The straw rocket was made as a starting model so that we can test the aerodynamics and principles of a rocket before building a bigger version. This rocket was made so that it would fit around a straw and if you blew it the rocket would fly off.
Jump Rocket
We built a rocket out of paper and tape based on the instructions given. The jump rocket was made so that it would fit around a PVC pipe and if you jumped on a water bottle attached to the pipe, the air from the water bottle would make the rocket launch.
Foam Plane
We made a foam plane by gluing the fuselage with the rectangular foam wing. We then built a vertical and horizontal stabilizer out of notecard and inserted it into the back slits of the fuselage. We learned more about aerodynamics and how the stabilizers in the back affect the flight of the airplane and why they are essential for stable flight.
Paper Airplanes
We made paper airplanes to measure the center of gravity and pressure. This exercise introduced us to basic aerodynamics concepts such as angle of attack, the impact of aspect ratio, and dihedral/anhedral wing angles.
Airbeam Data Collection
Airbeam Data Collection
Using the Airbeam, we measured and recorded data on the air quality from three different sites on campus:
Great Lawn
Top of Royal Parking Structure
Associates Park
Trojan Grounds Coffee
Design Process
Design Process
Define the problem
Generate alternative solutions
Evaluate and select a solution
Detail the design
Defend the design
Manufacture and test the design
Evaluate the performance of the design
Prepare the final design report
Step 1: Define the problem.
Step 1: Define the problem.
Our group was tasked with making a model rocket with an A8-3 motor that could reach an altitude of at least 120 ft. and expose a color changing ozone strip to the air at that height to record data. The ozone strip would be collected using a remote-controlled VEX IQ robot that would be able to collect the strip, detect its color, and return a certain reading.
TinkerCAD Model of Conical Nose-cone
Steps 2, 3, 4: Generate alternative solutions, evaluate and select a solution, and detail the design.
Steps 2, 3, 4: Generate alternative solutions, evaluate and select a solution, and detail the design.
Alternative Solution Generation
To tackle the problem, our group decided to create a Stage 1 rocket that would deploy a parachute after popping off the nose cone and exposing the ozone strip.
Design Evaluation
Our group conducted research on optimal rocket dimensions and shapes for the nose-cone, fuselage, and fins. We ended up basing our fuselage diameter on how much volume our plastic bag parachute took up when packed. In addition, we based our fuselage height on a 10:1 height-to-diameter ratio, a ratio we obtained from our research. As for the nose-cone, we opted for a conical shape due to its convenience, and production and material efficiency. Our research sources showed that an ogive or parabolic nose cone was more optimal, though at such low speeds, we decided that the benefits/deficits would be marginal. Additionally, we decided a cone summit angle of 42 degrees would be most optimal, again based off of our research. For the fins, research showed that ellipsoidal fins were the most aerodynamic at subsonic speeds. We decided that our fins would be made out of balsa wood, our fuselage out of layers of rolled paper, and our nose-cone out of 3-D printing plaster. Finally, for the parachute, we were given a large plastic bag and decided that because we wanted the entire rocket to be salvaged, the entire bag should be used to make as large of a parachute as possible in order to bring the entire rocket to a slow descent rather than just the nose-cone. Across the board, our most important design goal was to have a stable rocket that weighed less than 80 grams.
Detailing the Design
Our initially packed parachute required a fuselage at least 3.5 cm in diameter. Following the above-mentioned aspect ratio resulted in a fuselage 35 cm tall and 3.5 cm across. Our 3-D printed cone was made to have the same diametrical dimensions. For the fins, a randomly chosen base and height length were chosen, being 8 and 7 cm, respectively. The fins would extend 2 cm past the bottom end of the rocket so the rocket could stand.
Step 5: Defend the Design (Not Applicable)
Step 6: Manufacture and test the design.
Step 6: Manufacture and test the design.
This section gives an overview of our design tests and differences between our prototype and final design.
First Prototype Rocket Launch
First Prototype Rocket Launch
This was our 7/2 rocket launch. It has several noticeable differences. In this launch, we had not received 3-D printed parts yet, so we were forced to make do with a scrappy and lightweight paper cone, and a motor holder made out of a drilled piece of balsa wood instead of our 3-D printed holder design. We also jammed a bathroom paper towel as recovery wadding between the ejection charge and parachute in order to protect the parachute and shift the center of gravity up from the bottom of the rocket. We also accidentally glued the motor holder to the wrong fuselage, so we were forced to make do with a fuselage that was shorter and lighter (2 paper layers). All of these factors negatively impacted our model rocket's stability, and the calculated center of pressure was 4 cm in front of the center of gravity. Upon performing the string test, the rocket flew perfectly backwards when there was no parachute or recovery wadding.
First Prototype
First Prototype
Final Design Rocket Launch
Final Design Rocket Launch
This was our 7/3 rocket launch. This time, our rocket features a longer and heavier fuselage (4 paper layers), no recovery wadding, a 3-D printed motor holder where the motor is secured by friction, and a 3-D printed nose-cone. The fuselage had to be trimmed in order to accommodate for the nose-cone, since the nose cone was not able to fit neatly into or onto the fuselage. Our final design weight was 93 grams, which was well over our 80 grams design goal. It also explains our rocket's poor performance in the launch; it was too heavy to reach a significant altitude. Though, with the 3-D printed parts and new fuselage, we were able to create a stable rocket that did not have as much of a parabolic trajectory as our initial launch.
Final Design
Final Design
Don't those 3-D printed parts just look so frickin' awesome?!
Don't those 3-D printed parts just look so frickin' awesome?!
Parachute Test
Parachute Test
String Stability Test (Final Design)
String Stability Test (Final Design)
This is the claw. There are two tiny gears used to make the gears open and close. They way the claw works is one of the gears starts turning and since both gears are very close to each other, the other gear spins in the opposite direction.
This is the entire robot. The design process of this took a lot of thinking and imagination. Some key factors in the design process of the robot were using the stoppers for the rods and attaching the motors to the rods. Some problems that occurred were keeping the robot stable and figuring out how to fit parts into the base of the robot. The purpose of the base of the robot is to have the robot move. The only way the robot can move and use its' claw is by a code made in Python in a VEXcode application. If-statements and while-loops were used a lot when making the code.
Step 7: Evaluate the Performance of the Design
We were unable to reach a high enough altitude to collect data with our ozone paper strip.
Our parachute failed to deploy in both the prototype and final design launches.
Our rocket had a stable flight trajectory, but was too heavy.
In all final design launches, the ENTIRE rocket was successfully recovered.
Step 8: Final Design Report
Our final design had a stable flight trajectory, which was a big improvement from the initial prototype whose CoG was far behind its CoP. The stability was probably the biggest difference in results between the final design and prototype.
The final design proved too heavy to launch to a sufficient altitude before deploying its parachute, and did not stay in the air long enough for the ejection charge fuse to go off. However, we had low expectations for our parachute deployment considering in the prototype, the nose-cone did not even pop off (due to the fat recovery wadding blocking the charge). So, all things considered, the fact that the nose-cone came off and the parachute came out (but did not expand) was still a huge success. It should be noted though that the parachute did not deploy due to a lack of recovery wadding; the parachute melted onto itself and became sealed.
Some significant improvements can be made in the areas of planning, size, and weight. First off, our decision to base our rocket dimensions on how well we could pack a parachute severely limited the effectiveness of our design in hindsight. Because the diameter was nearly double that of the motor, we experienced 4x the drag that we would have had we made a rocket with the same diameter as the motor. It would also have simplified our design by removing the need for heavy 3-D printed parts. The decision to follow a 10:1 aspect ratio with our oversized fuselage diameter was another nail in the coffin, as it meant increased weight from the paper layers. Additionally, we taped 2 paper layers and glued 2 paper layers to make the fuselage for the sake of structural integrity, but we honestly could have gotten away with just gluing 2 layers together instead to make the rocket lighter. Requiring 3-D printed parts also limited our ability to test the effectiveness of the actual design, and created additional problem areas such as fitting the parts to the rocket, and being bottlenecked by waiting for the parts to print. Finally, the oversized diameter took away the option of having a balsa wood cone. Being heavier than paper, it would have been a suitable material for making the nose-cone because it would have shifted the CoG up, increasing stability. It would also have been easier to sand down into an optimal ogive shape. However, we had no balsa wood pillars wide enough to match our diameter, and had to wait for 3-D printed parts.
Week 4: Robotics
Computer Science/Engineering
Computer Science/Engineering
Computer science and engineering involves the analysis, design, and evaluation of computer systems, specifically hardware (the physical wiring) and software (the programming that can be done with the physical wiring). Computer science engineers work with flexible manufacturing systems, or "smart" devices. They work on the hardware's interface, and enhance capabilities of devices for consumer, industrial, commercial, and military applications. In addition, computer science engineers work with AI and machine learning for application in areas of image recognition, natural language processing, robotics, autonomous motor vehicles, and autonomous aerial drones. They may also specialize in computer systems such as VLSI, computer architecture, microprocessor design, and more.
Mechatronics Engineering
Mechatronics Engineering
Mechatronics engineering is a field that combines mechanical, computer science, and electrical engineering concepts to create things such as robots, medical devices, self-driving cars, and other smart devices. As shown by the projects and things they create, their line of work extends into various industries, including but not limited to: aerospace, healthcare, robotics, automotive, and manufacturing. Their unique specialty and experience across many different types of engineering make their skills applicable to many different industries and job positions. Mechatronics engineers may work in factories to design robots that assemble cars, or make practical and versatile robots that can carry out different tasks, like in companies such as Boston Dynamics.
Research Paper Link: Application of Robotics in Disaster Recovery
Design Process
Design Process
Define the problem
Generate alternative solutions
Evaluate and select a solution
Detail the design
Defend the design
Manufacture and test the design
Evaluate the performance of the design
Prepare the final design report
Step 1: Define the problem
Step 1: Define the problem
For the Tamiya Tracked Vehicle bot, we had to create a robot using the Tamiya Tracked Vehicle kit, an Arduino board, dual motors and a motor driver, and an ultrasonic sensor that could navigate its environment by avoiding obstacles such as walls and leading people towards safety.
For the RedBot, we were tasked with coding a wheeled, Arduino-controlled bot that could use color sensors to follow a marked path and bumper sensors to avoid obstacles.
For the Zumi bot, our task was to code the bot so that it would drive forward and turn to avoid detected obstacles.
For the JD AI bot, we had to code it so it could recognize human faces, say out loud that it detected a human, and begin walking.
JD AI Bot
Tamiya Base Design
Steps 2, 3, 4: Generate alternative solutions, evaluate and select a solution, and detail the design.
Steps 2, 3, 4: Generate alternative solutions, evaluate and select a solution, and detail the design.
Alternative Solution Generation
This week, the challenge was to code robots that were either already built, wired, or had its steps laid out. The alternative solution generation lied in how the robots would be coded, and what their responses would be to encountering certain stimuli (ex. an obstacle or human face).
For the Tamiya bot, we planned to assemble the base and dual motor gearbox from the provided kit and have a front mounted ultrasonic sensor connected to an Arduino microcontroller that would be hooked up to the motors. The Arduino would control the bot and make it turn either left or right if the sensor detected that an obstacle was too close. We also decided to follow a 110 RPM gearbox design as opposed to a 345 RPM design out of fear the robot would hit an obstacle before the sensor could fire and receive its periodic sound wave.
For the RedBot, our plan was to use the color sensor inputs to turn the RedBot accordingly until the middle color sensor was following the path marked by black electric tape. We would utilize sensor fusion with the bumper sensor to detect if a path that was viable to the color sensor was viable to the bumper sensor (whether the path had an obstacle or not, even if the path was black and could be followed).
For the Zumi bot, we planned to code it in Java to turn either 90 degrees left or right if it detected an obstacle with its infrared sensors.
For the JD AI bot, we planned to use Blockly to code the robot to detect human faces upon activation (with the bot pre-trained on other datasets), and walk afterwards.
Design Evaluation
The Tamiya bot design was crude, but functional. Though, with this design, the bot cannot detect obstacles if it approaches them at an angle, since echoes from the ultrasonic sensor's sound waves would never reflect back to the sensor.
The RedBot design was simple and effective. Three color sensors would allow it to determine if it was following the designated path, and the bumper sensors would send signals to the microcontroller instructing the bot to turn away accordingly.
The Zumi bot design was functional and able to detect obstacles in front of it.
The JD AI bot had sound logic that could be easily implemented through Blockly.
Design Detailing
The Tamiya bot would have a motor driver hooked up to the Arduino microcontroller board and the dual motor gearbox. Both the motor driver and ultrasonic sensor would be housed on an elevated breadboard such that the sensor would be facing forward. The Arduino microcontroller would be beside the breadboard on the same elevated platform. A dual AA battery pack would be attached to the rear of the Tamiya.
The Zumi bot would utilize many conditional statements with actions corresponding to those statements. (For example, if the Zumi's infrared sensors detected an object, the Zumi would turn 90 degrees).
The RedBot utilized many conditional statements in its code to check color sensor inputs for if the bot was following along the path, as well as detect if the bumper sensor was triggered. The bot would turn until the sensor fusion of the color sensor and bumper sensors' indicated that the both was back on track.
The JD AI bot would use its camera and pre-coded blocks of code to detect a human face. It would tilt its head towards detected faces, and use a conditional statement to start walking if it detected one.
RedBot Design
Step 5: Defend the Design (Not Applicable)
Step 6: Manufacture and test the design.
Step 6: Manufacture and test the design.
This section gives an overview of our prototype and final designs for the Tamiya, Zumi, JD, and RedBot, as well as the tests and steps taken to manufacture our final product.
Testing our Dual Gearbox Motor | Double Motor Holder Kit
Testing our Tamiya Base Design | Tamiya Building Kit
Tamiya Bot
Tamiya Bot
For the Tamiya, we followed the provided instruction manuals to assemble the dual motor gearbox and vehicle base.
We tested the motors and base with a dual AA battery pack for equal RPM on each motor, correct motor direction, and track, wheel, and axle functionality.
For the integrated ultrasonic sensor and dual motor circuit, we followed a project manual that mirrored the microcontroller code and breadboard setup for the robot. Our setup tests can be seen in the videos attached.
Our Tamiya's pseudocode was as follows:
> While moving forward, after a set amount of time, turn either left or right (to scan more of the environment and eliminate the issue of approaching obstacles at an angle).
> If the ultrasonic sensor detects that an obstacle is 12 centimeters away from the bot, turn either left or right for a specific amount of time before moving forward again.
> Resume forward motion and repeat
The Tamiya was programmed with case statements that acted as "modes" for it to either drive forward, turn left, turn right, and avoid obstacles. This was done to be able to respond to ultrasonic sensor readings and switch states even in the middle of executing a locomotive block of code.
Testing our Ultrasonic Sensor | SparkFun Kit Project
Testing our Motor Driver and Setup | SparkFun Kit Project
Snippet of Our Tamiya Bot Code
RedBot
RedBot
Our RedBot's pseudocode was as follows:
> If the three color sensors indicate that the bot is on the designated path, drive forwards
> If the three color sensors indicate otherwise, turn right until the bot is back on track
> If the bumper sensor is triggered, override and turn until the bumper sensor is no longer triggered
Working RedBot Path and Obstacle Test
RedBot Problems and Trial Runs
Snippet of Our Zumi Bot Code
Zumi Bot Test (featuring Kerim's football defense)
Zumi Bot
Zumi Bot
Our Zumi bot's pseudocode was as follows:
> Retrieve the distance from an obstacle calculated by an ultrasonic sensor
> Determine if the calculated distance is less than a certain "safe" distance
> Turn left 90 degrees
> Resume forward motion and repeat
JD AI Bot
JD AI Bot
We programmed our JD AI bot using Blockly with pseudocode as follows:
> Wait for/detect a human face
> Track the human's face by turning head accordingly
> Say "I see a human."
> Begin walking
Snippet of Our JD AI Bot Code
Snippet of Our JD AI Bot Code
JD AI Bot Face Detection Test
Step 7: Evaluate the Performance of the Design
The Tamiya was unable to move and detect obstacles properly
The Zumi bot was able to move, detect obstacles, and change paths accordingly
The RedBot was able to follow a designated path by using its color sensors, and obstacles in paths using its bumper sensor
The JD AI bot was able to detect and track human faces, announce that it detected a face, and walk
Step 8: Final Design Report
Tamiya Bot: Despite flawless test performance, in our final design, our Tamiya's "mode" based actuation proved faulty. The ultrasonic sensor kept returning max readings, and the robot was unable to detect obstacles directly in front of it. This was likely due to a coding error. In addition, the sensor was only able to return integer distance values between 55 and 80 in certain test runs that fluctuated like a sinusoidal wave. Our code was supposed to keep the Tamiya in a certain mode for a set amount of time so that it would not switch modes so frequently and essentially freeze up. However, the loop kept repeating itself either way, constantly and inaccurately updating the mode, resulting in movement that rendered the Tamiya immobile. This was likely due to the nature of the case statement model that allowed the loop to run while executing other blocks of code, and was not accounted for. Our cleanest movement was also erroneous; when a hand was placed directly in front of the ultrasonic sensor, the Tamiya would turn on a single track in some test runs, or reverse in other test runs despite there being no code that was intended to allow it to reverse.
Note: Another more ambitious initial design involved two ultrasonic sensors angled 45 degrees left and 45 degrees right from the forwards direction, and a zig-zag movement pattern. However, this proved too difficult to code and debug, and we resorted to a simpler, single ultrasonic sensor detection system. The double ultrasonic sensor and zig-zag movement design would have eliminated the issue of not being able to detect ultrasonic sensor echoes from horizontally angled surfaces.
Zumi Bot: Our Zumi Bot was capable of detecting obstacles and changing directions by turning in response to continue along its path. However, its ultrasonic sensors struggled to detect cylindrically shaped objects and objects slightly shorter than the Zumi, such as the bottom rung of our continuous classroom chair legs (refer to the Zumi bot test video if it is unclear what this sentence is describing).
RedBot: Despite being jittery, our RedBot was able to follow black designated paths. A tedious issue came from the bumper sensor "whiskers" not bending enough after hitting an obstacle to make contact with a conductive screw and signal to the microcontroller that there was an obstacle in the way. However, the code was perfectly functional. A minor setback included making the bumper sensor detection time longer than the color sensor detection time so that the color sensors would not override the bumper sensor response.
JD AI Bot: Our code was able to detect and track human faces, make the JD AI bot say that it detected a face, and walk in response to face detection
Page updated
Google Sites
Report abuse