During this group project, we designed a system to transfer luggage from a platform to another through Autodesk Inventor, while taking in software input on where to place the luggage with Python.
We then built and tested a prototype using 3D printing and mechanical actuators.
I was quite confident in my abilities in coding, since I had experience building my own side projects before. I was not as confident in
my CAD abilities: unlike some of the people I had befriended, Inventor was my first taste of a solid modeling software, and while I finished coursework (Fig. 1) with ease, I was unsure
if I would be able to keep up with my group members.
Fig. 1: 'chenj692_GD4.ipt.' A rudimentary schoolwork CAD submission from early October. Took me around 3 hours.
Looking back, I should have practiced a bit more. I was a bit smug, thinking that my coding prowess would be enough for the project.
I did do some practice with Python, as my skill had decreased over summer vacation and lack of time, working some on my side projects and stretching my muscles on coursework.
■
Problem:
The problem we were tasked to solve was about an airport. The airport was having trouble sorting checked bags for outgoing flights. The project had a
software and hardware component: we were tasked with creating modular programs using
Python to perform data validation and analysis, and then design a mechanism to transport luggage from Point A to Point B (Fig. 2).
Fig. 2: Diagram of the challenge. Note restriction line.
The catch was that equidistant from both Points lay a Restriction Line, past which we were not allowed to build or extend beyond until our contraption began to move. We were granted two
actuators: a rotary actuator, and a linear actuator.
Brainstorming:
Immediately, my group began to think of possible solutions to this problem. We conferred over possible mechanisms using each design, and then both. When we reconvened days later, each member had
come up with a design for each actuator. After further conferring, we settled on two possible designs.
These would thus be dubbed the 'bucket' and the 'elbow'. The design I contributed is the 'bucket' design (Fig. 3). This design integrated
both actuators and numerous custom-modeled parts to catch the luggage smoothly, then slowly lower it to Platform B. Highlights of my design include a smooth ramped bucket to ease delivery,
a counterweighted base to ease stress on base screws, hollowed components to lower rotary torque required and increase level of control, extended pieces to ensure controlled angular movement,
and a ribbed bar to reduce risk of premature sliding.
Fig. 3: My 'bucket' design. Created through three days of iterative development. The 'bucket', attached to linear actuator, rotates using the rotary actuator.
The Solution:
By group consensus, we moved ahead with the 'elbow' design instead, as my 'bucket' design was far too complicated and required too much 3D printing time under our constraints.
After making more quick adjustments and improvements to the design, each member was assigned a part to model. I modeled and submitted my part, a support. Once the model was finished,
printing time began. During this time, we began work on the software portion.
By this point, we had talked on who should be lead on what, and I volunteered to lead the software development. Each member was to complete their own function, and three functions had to
be completed by the whole team. On the first day, I completed two of the simple team functions while taking feedback from group members, and finished my own function, time_delay.py.
You may find the full attributed code on GitHub here. I collected all the Python modules, performed unit tests and
standardized all I/O methods, then linked them together as modules through an external _config.py file. I retrieved the progress made on the final team
function, graphical_teamID.py, finished it, linked all of the other models as inputs, tested it, and validated it.
Fig. 4: The moment I notified my team that I got the graphical_teamID.py module running.
I would go as far to say that I practically rewrote a significant amount of code to fix bugs, solve edge cases and inefficient chunks, and refactored the whole existing base of
graphical_teamID.py, since it became outdated after I standardized the way the modules interacted with one another.
As the date of our project evaluation loomed, I briefed my team on what exactly I had done to the code and how all the modules were connected. I also provided consulting on whether
our solution needed tweaks: we had come close to running out of printing time, having had to reprint numerous times because of software bugs in the slicing software.
Thus, we had no time to test if our solution would actually work or not coming into the evaluation.
Luckily, on the day of the evaluation, when we arrived half an hour earlier for our allotted setup time, the solution worked wonderfully. See Fig. 5 for an image of the full assembled
solution on the deployment pad. Tap on the image to toggle extended and retracted forms.
■
Fig. 5: The finished product, retracted mode. Note additions from initial drafting, like foam rails to prevent luggage damage. I modeled the x-shape blue support.
ON CAD
I feel like I could have done some things better. I think that I was not proactive enough during the CAD section of the project. Another group member took it upon themselves to link together
all of the individual components into an assembly and fix the conflicts and errors that arose, like I did with the code. The group member did not ask the rest of the team for help, but I feel like
if I had made my willingness and ability to work with CAD clearer to the group, the member would have let me help them with the assembling. I potentially could have found and fixed some of the
issues that plagued our 3D printing process. That would have led to us having the testing time that we missed, which could have given us the ability to do better.
However, I feel like I learned a lot about the entire pipeline of 3D printing. I familiarized myself with PrusaSlicer, the integration of assembly parts in
AutoDesk Inventor, how to use motion constraints and animate parts, and the creation of engineering drawings and exploded views.
ON PYTHON
Additionally, I feel as if I did not sufficiently ask my teammates for feedback. While I posted occasional progress checks and git commited my code regularly,
I think that I should have been in active communication with my team members while doing the major refactoring and linking. I wonder if the code could have been even more compact, even more efficient,
even more readable had I been coding live with my team?
All of my hobby projects have some form of rigor or linkage between files, but not to this level. I learned some new things about Python: while I had casual familiarity with using Python files as modules,
reading settings and configuration from a .py file instead of a .yaml or .json file, and working
on code with others through git, this project was my first time putting these principles into action on a real-world codebase. I feel like I gained a greater appreciation for source control,
unit tests, and integration tests. This appreciation was especially evident since I was running and working with code written by others, without guarantees of standardization or proper functionality.
ON PROJECT MANAGEMENT
I have worked on team projects throughout high school, and this project is my first in higher education. I learned how to raise concerns and communicate effectively in official channels, use sharing
functions of common workplace tools like Microsoft 365 (Sharepoint, Teams, etc), and raise team morale through my interpersonal
skills (Fig. 6).
■
Fig. 6: One of my attempts to raise team morale in the midst of the project's toughest crunch time.