Relevant Technical Skills:

• Prototyping and Design
• CAD Modeling
• Programming (Python)
• 3D Printing and Laser Cutting

Relevant Soft Skills:

• Collaboration
• Communication and Presentation
• Planning

Project Narrative

Problem Statement

Airports need a new system to check in passengers, autonomously sort luggage, and subsequently transport them, because airlines and passengers both suffer from an excess of carry-on luggage.

Summary

In this project, our team was tasked with streamlining the process of checking baggage. This involved a physical mechanism that moved luggage from the baggage tunnel (Platform A) to plane baggage storage (Platform B), code to control the robotic Q-Arm as it sorts luggage to be rejected or taken to Platform A, and a program that takes in the passenger and flight information for the day and displays relevant information such as seats sold / oversold, overweight bags, etc.

Fig 1. Final Mechanism Design and Physical Environment.

Fig 2. Draw Bridge Mechanism Exploded Drawing.

Project Timeline

Team’s Work and Personal Contributions

Mechanism

Design Work Flow:

1. Several rough sketches.

2. Selected design:

   1. Based on reliability, simplicity, modularity, and fabrication time

3. Iterate:

   1. Initial model was fully comprised of 3D printed parts, which we realized would take too long and be difficult to modify. (Fig 3.)
   2. I took the responsibility of updating the CAD to integrate laser-cut acrylic and reduce fabrication time, attaching to the 3D print by glue. This was also flawed, as glue joints reduce modularity and could be an issue.
   3. I then finalized a model that used screws to fasten the acrylic to the 3D prints. After assembling and installing on the platform we realized that the mechanism sat over the restriction line and needed tweaking. (Fig 4. , Fig 5.)
   4. Dimensions were edited to allow the bridge to shut further and to increase the clearance from the line.

   In the end, the mechanism was able to retract and deploy using the rotary actuator but we unfortunately encountered issues with the Raspberry Pi and physical code so we were unable to complete a full successful test during the presentation.

   Additionally, I was responsible for creating the exploded engineering drawing of the mechanism as seen above in Fig. 2.

Fig 3. Initial CAD model - Fully 3D printed

Fig 5. Final assembled mechanism

Fig 4. My final CAD model- Mixed 3D printed and laser cut acrylic parts fastened with nuts and machine screws. I used the Thode Makerspace drill press to drill and tap a hole for the string anchor in the lighter blue acrylic piece.

Code

Fig 6. Fleet Data function flow chart

As a team, we worked together to create flow charts for several functions. I was assigned Layover, and a group member and I agreed to complete Graph Team ID together. I took care of the data processing, and he dealt with the turtle graphics display component.

Fig 7. Successful test of Graph Team ID

Since Graph Team ID takes input from all the other functions, each one needed to produce the expected output. In cases where this was not true, I went through and debugged each with input from the original authors. All that said, I added some polishing tweaks to the turtle code to colour code each flight and scale the format for varying numbers of planes.

The physical environment code was largely dealt with by the other members as I focused on CAD and Graph Team ID.

Both the physical code and the passenger check-in code did function as intended, not accounting for Raspberry Pi malfunctions.

P-1 Reflection

This project was very enjoyable in that I got a lot of hands on CADing experience. It was certainly a lot of work modelling, but as I continued through, it became faster and more streamlined. It has given me a better handle on the tools in inventor and a new appreciation for good constraints. I found that going back and iterating on the design became infinitely easier with clean workspaces and well dimensioned parts.

Additionally, as a first experience with a formal design report, this has been an educational experience. It’s given me a dip into the realm of connecting Engineering to the real world. Speaking with TAs and engineers was very informative in terms of the goal of the whole thing. Sure it’s one thing to say that a luggage goes from A to B, but who cares? That is the question that you have to answer in a design report, draw the scope back into a field of view that has a tangible impact.

Now that I have had to debug someone else’s code, I understand the stress and importance put on documentation and commenting. It really makes a night and day difference when navigating foreign code searching for issues. I had been treating as something of a chore or a waste of time, but it really became detrimental combing through trying to decipher code to find a specific error.