HTMAA 2023 > EECS Group Assignments > Machine Week

THE GERSHENFORCER: Solving Class Problems One Nerf Bullet at a Time

Summary

"There is no worse crime in the middle of class than people dribbling in" -NEIL GERSHENFELD (probably)

Our overall object was create a Nerf dart launcher that punished students as they walked into class. We tackled this by dividing the work into individual components, interfacing the components together, then coming together as a group and integrating the final system into a cohesive product. We were shocked at the results of our launcher and targettings system. We want to thank our wonderful TAs Anthony and Maya for their help. Additionally, recognizing our star players - team leads: Yohan, Ty, Vlada and Masara.

Resources

Overall List of Materials

List of Tools/Software

Planning

Ideation Stage

Our team came up with quite a few ideas.

We then decided to go with the nerf turret idea. Sungi who originally proposed the idea then began dividing teams. We came up with a schedule and a few organizational documents.
We then created a document to sign up on for teams. The teams were divided into four sections: Aferwards, we organized into mini teams. Our team leaders were Vlada - Actuator; Masarah - Launcher; Yohan - Structure; and Ty - Software;

Organization

Our next step was to come up with some idea of what the nerf gun was going to be and how it was going to adequately solve the project.
Sungi drew up a concept sketch to orient ourselves and an idea of what each team was going to do. At this point, we created generic ways to tackle the progblem. Sungi created a concept sketch taht involved various features. We constrained ourselves with the design limitation of making the formfactor "3D printable" using the Prusa/Bambu printers as our maximum dimensions.

Our next step was creating a schedule.
We created a generic schedule that focused on individual workstreams first, then pushed more and more integration. We identified 3 major interfacing points that would require multiple people from two or more teams to integrate.

We made sure that individual features were assigned. This is how we defined each of the team roles based on features they were responsible for. All of the integration pieces that were mentioned previously were then deicded to meet with each of the features. Some of the tasks that were discussed were then combined in order to maximize workflow streams and minimize redundant tasks.
We met as a group during TA hours (in order to get feedback from Anthony/Maya) and then got the below feature sets as part of our group meeting. Note: these responsiblities changed throughout the course of the project/week. This list is what we wound up doing at the end.
Here is what we worked out during our meeting on the whiteboard! Whiteboarding during initial brainstorming was such a good way to get everyone on the same team/page both conceptually and visually.

Launcher Team Feature Responsibilities:

Actuator Team Feature Responsibilities:

Structure Team Feature Responsibilities:

Software Team Feature Responsibilities:

Creating Magic - Spray and Pray

Before anything else had to happen, we needed our Nerf Darts. Here are two packs of 200 for a total of 400. If we assume that there are 10 students late every class, that means we can maximumally fire 40 rounds per student. #theGERSHENFORCER

Launcher Mechansim

We created the project based off the assumption we can leverage the aluminum extrusion in order to best create the structure to best support the launching mechanism. We focused on using the given wheels. Additionally, we utilized a 4cm x 4cm (M4) bolt pattern in order to create our interface. This would allow us to not worry about a bolt pattern with the Actuator team.

Here are some initial designs

Testing - Voltages

Our voltages for our DC motors were super simple - they operated off two leads (positive and ground). In order to test the launcher, we tested voltage ranges from 3V to 7V. One of hypothesis that the bench test proved was that anything abouve 6-7V created too many vibrations for our structure to hold together. Additionally, we had irregular frequency vibrations in the range of 3-4V range. The speed was too slow so the imbalance of the wheels caused the entire launcher to violently shake. Our test showed that our optimal voltage control for our device should be in the ~4.5-5.5V range.

After a few tuning runs, we were able to get consistent pushes through the launcher! WE HAVE A NERF GUN!

Firing Control - Actuator Group

The main reason that our actuator needed to be seperate from our launcher is because that the launcher requires time in order to reach speed. Therefore, our actuator mechansim must be built on a seperate motor/control system and loop. We utilized (a probably overbuilt) actuator system. This was specifically done on our 25kN servo motor. We utilized a rack and pinion gear system to drive the actuator. We left plenty of room in our actuator in order to best drive the bullet in our magazine.
We then made another iteration on this minimizing weight in order to reduce strain on our platform. We made a few lightening cuts as well as integrated our magazine/hopper (and integrated chamber).
All of our parts on the actuator were either part of the motor kit or they were 3D printed out of PLA utilizing the range of printers available to the EDS shop and personal printers.

Platform - Structure Group

Out platform turned out of a few iterations. Firstly, we brainstormed out of creating a pitch mechansim utilizing two double lift mechansims. After realizing this was extremely complicative for no gain, we simplified the mechanism into a single liting servo. This will give us the desired pitch.
We then simplified this drawing and made the paltform out of acrylic. This allowed us to create a single-motor actuator (pinned) really quickly because it wouldnt force us to rely on a 3D printer for a larger, mostly flat platform. This was mostly our design.
We CAD'ed up the rotating mechanism by creating a platform to mate with the given servo and the acrylic. This allowed us to control the yaw mechamism.

Creating Magic

We were then able to pair that up on a breadboard with a ESP32 and control our pitch and yaw. We got movement! TELL US WHERE TO SHOOT SARGE!

Bringing it Home - Software Group

The first challeng in software was that we had to wait until most of the groups had already mostly had a sense of what they were accomplishing before we were able to begin. In this case, we we're mostly concerned about scope creep - where continious features would bog down the project and add additional requirements to our team that would need to finish towards the end.
We split our challenges into multiple requirements:

The easiest mechansim for us to start working on in parallel with the other groups was the camera. This was largely independent of other groups' progess. We settled on using a seperate ESP32 chip with a built in camera in order to conduct our CV modules. This allowed us to import the CV libraries in order to detect parts of human bodies.

We initially used an openCV face tracking. However, utilizing haarcascade, we were unable to reliably detect faces. After while, Ty utilized a TensorFlow human pose estimation called MoveNet . This allowed us to accurately detect body parts.

Integration Hell - Software/Structure

Our next job was to integrate all of the above - Detection >> Tracking >> Launcher Speed Up >> Actuator >> Next Target Sequence.

Jesus Created a custom board in order to maximize our ability to control multiple boards and outputs. We utilized laptop directly to process the "heavier" code - specifically the object recogniziong (CV) in order to timely acquire targets. The ESP boards controlled the rest of our motors and servos in order.

Lessons Learned

Ultimately, machine week is a cool way to put a group together into the "storming" phase of group dynamics really quickly. Here are our team lessons learned:

Disclaimer: That is not actually Neils voice.....

Disclaimer2: We are in no way related or in partnership with Nerf nor Hasbro corporations #pleasedontsueus