Garage Gimmicks — Luggage Dispenser

The luggage dispenser was the product of a school project for the Engineering Design & Innovation (EDI) module. 30.007 is the major project for Term Four EPD students in SUTD, and is often considered the most important milestone before the final-year capstone project.

In comparison to the previous project, 30.007 would have a budget of S$1500. The time frame was identical (14 weeks). However, the scale, objectives and skillset required for this project were far grander.

The theme for 2023’s EDI was Travel, largely inspired by the reduced measures at the end of the COVID-19 pandemic. Teams were encouraged to create working prototypes that would facilitate travel in some way or form.

To streamline this post, I will be separating this entry into parts, particularly in the prototyping process. The parts will be as follows:

• Idea Generation
• The Problem
• Analysing Existing Solutions
• Outlining Key Objectives
• Planning
• Component Sourcing
• Building and Prototyping
• Functionality Tests

Unlike the previous post, I will be including the members at the start of the post, as they will be mentioned in detail later:

• Jedrek Teo — Chief Designer, Mechanical Assembly
• Ng Wanxing — Mechanical Design & Assembly
• Ethan Singh — 3D Printing, Programmer, Mechanical Design
• Keith Lee — Mechanical Design & Assembly
• Yan Han (myself) — Electronics, Chief Programmer (GitHub found here)

Idea Generation

Several ideas were proposed at the start of the project, in order to fulfill the theme:

• Portable Espresso Device (not unlike the Wacaco espresso makers)
• Plane Luggage Handler (to facilitate moving luggage to and from the overhead compartment)
• Automatic Luggage Unloader (from the conveyor belt at luggage carousels)
• Luggage Dispensing Kiosk (that directly dispenses luggage onto the trolley instead of requiring lifting off the luggage carousel)
• Portable Walking Assistant (for the elderly or eyesight-impaired)
• Hands-free MRT Gantry (which technically already exists but still under testing)
• Personalised Travel Gate (Provides directions based on RFID and facial recognition)

The eventual choice was the luggage dispensing kiosk, for the following main reasons:

• Luggage carousels are a personal pain point for a majority of the team.
• The kiosk is (in theory) relatively possible to build with the given budget.
• The skill set of the team largely leans towards being mechanical, which fits this idea.

The Problem

In most modern airports, luggage from the aircraft is placed onto a moving conveyor belt before being collected and placed onto a trolley. However, these results in a few problems:

• Travellers are required to visually identify their luggage, creating a risk of misidentification in the case of similar or identical luggage.
• Lifting luggage off a moving conveyor belt requires strenuous physical labour, and which requires an unergonomic lifting position. Even healthy individuals often end up injured from lifting their luggage off the carousel.
• Travellers generally end up standing around the carousel for extended periods of time while waiting, resulting in fatigue and frustration (especially so after a long flight).
• Long waiting times also result in overcrowding and a potentially higher risk of infectious disease transmissions.

The severity of these issues vary greatly between airports. Changi Airport is generally better off due to the large real estate available, while other airports like Narita Airport in Tokyo or Newark Airport in New York do not have that luxury.

Analysing Existing Solutions — State of the Art

There are existing solutions in the market that aim to deal with these issues.

Airportr

Airpotr is a service in Europe that collects luggage from home, and delivers them directly to their hotel or destination home. This provides fuss-free convenience for travellers, and comes with the bonus of not having to bring luggage to and from the airport, leaving travellers to have additional time exploring or conduct other necessary business.

BeumerGroup

BeumerGroup trivialises back-end luggage handling, improving luggage distribution efficiency via a rack-based baggage handling system. This thereby reduces waiting times at the airport due to faster processing and movement of logistics.

Changi Airport

Changi Airport itself has implemented baggage tracking (alongside many other airports around the world). This bag-tracking technology relies on an internal database, allowing passengers to know where their luggage is at all times for peace of mind.

The above solutions have their use and benefits. However, they also come with their drawbacks.

• Airportr comes with additional cost, which may not be appealing to the traveller (despite appearances). In addition, it requires trust from the traveller and adds variables to luggage handling.
• BeumerGroup has massively improved back-end baggage handling to reduce waiting times and logistical costs. However, it still requires the traveller to use the traditional luggage carousel.
• Changi Airport’s solution can only be considered a novelty and feature that travellers may appreciate, but also does not remove the need for the luggage carousel, nor does it significantly reduce waiting times.

Our solution must take these solutions as inspiration and improve on them.

Outlining Key Objectives

The following goals were outlined early on in the planning stage.

• Accuracy (Dispense the correct luggage to the correct passenger)
• Efficiency (Lower waiting times from scanning passport to receiving luggage — <45s per passenger for a single piece)
• Scalability (Minimise further waiting time with additional pieces of luggage — <15s per additional piece)
• Precision (Deposit luggage onto trolley with a less than 2% failure rate)
• Safety (Zero risk of damage to luggage upon dispensing)
• Cost (To keep within the $1500 budget wherever possible)

Ultimately, the prototype seeks to allow passengers to collect their luggage with the following benefits:

• No need to wait in a crowd for extended periods of time
• Visual identification of luggage is no longer required; the system would do it for them
• Unergonomic lifting of luggage from a conveyor belt is replaced by a fuss-free, automatic system that loads the trolley for the passenger
• Overall reduced waiting times due to streamlined distribution process

Planning (Mechanical Design) — Jedrek, Keith, Wanxing

Our solution would take inspiration from BeumerGroup and Changi Airport’s solutions and consist of the following elements:

• Kiosk (for front-end with screen and passport use)
• Storage compartment (making use of baggage tracking techniques employed by modern airports)
• Back-end transportation (for moving luggage to from storage kiosk)
• Unloading bay (into dispenser)
• Dispenser (depositing luggage onto trolley)
• Tray (to hold individual luggage pieces and facilitate transport)

The scale of the project was 1:4 compared to real life. Building a full-size prototype would first take up all the budget, and would, most importantly, take up more real estate than available.

Proposed workflow and original design

Version 0 is shown above that demonstrates the proposed workflow of our prototype. While the designs indicated here were no longer implemented in the later design, the workflow is largely identical.

The initial design is shown below as an exploded view. All the components (except the kiosk) are shown here.

Exploded view

Each other component will be explained below:

Luggage, Tray & Storage Compartment

Some compromise is made with the storage compartment, which is a simple, elevated platform meant to simulate a shelf of stored luggage. Not pictured here is a servo-powered gate, that opens when required.

For this prototype, the system would make use of gravity to transfer luggage onto the transportation belt.

The tray and luggage would be 3D-printed due to the lowered scale. In addition, the luggage’s weight will be adjusted accordingly.

To simulate various sizes and form factors of luggage, three different sizes of luggage would be printed — XL, L & M.

Back-end Transportation

While the original plan was to build the system employed by BeumerGroup (narrow, guided rails with high speed and multi-directional flexibility), budget and design constraints forced the use of a traditional conveyor belt.

The belt is split into two parts. The longer belt transports luggage from the storage compartment to the unloading bay on the left, which would then transfer the luggage onto the dispenser.

Both belts would be driven by stepper motors.

Dispenser & Unloading Bay

The unloading bay is lifted via a lead-screw stepper motor, allowing the luggage to fall into the dispenser.

The dispenser is effectively a miniature elevator, utilising a system that is not unlike the bed movement of a CoreXY 3D printer. The elevation is controlled also by stepper motors. At its greatest capacity, the dispenser can contain up to three pieces of luggage.

A trapdoor below the dispenser would open once all the passenger’s luggage is accounted for, depositing them onto a trolley. This thereby removes the need for the passenger to lift luggage off a moving conveyor belt.

Planning (Electronic Design & Programming) — Yan Han, Ethan

Based on the prototype’s requirements, the following programming workflow was proposed:

The initial plan would break the flow into four components. One would be the central loop that controls the kiosk, storage and unloading bay. The others would then control the belt, elevator/dispenser and display accordingly.

Up until this point, the project relied on a single Raspberry Pi as our singular compute unit. It was later proposed (and tested) that several microcontrollers would have massively streamlined the workflow.

The program will simulate a modern baggage-tracking database using Google Firebase.

Initial planning with the programming was to determine the main compute unit. Decisions were initially split between the Arduino Mega or the Raspberry Pi 4, but the latter was chosen due to its versatility and compute power.

Component Sourcing

The original Bill of Materials can be found here.

Most of the parts were sourced from AliBaba. These include the motors and their drivers, which were far cheaper to source from overseas.

Mechanical components such as 2020 aluminum profiles, acrylic, and shafts were purchased locally in shops at Ubi.

Electronics (Raspberry Pi, power supply, modules) were purchased from a mixture of AliExpress, directly from Sim Lim Tower, and Shopee.

Building and Prototyping

Due to the scale of the project, only a few notable cases will be illustrated here.

• Main Conveyor Belt Assembly

Assembling the initial prototype was relatively straightforward; holes were drilled in order to fit the aluminum rods that would later house the conveyor belt.

The two rods at the end were eventually replaced with steel rods due to their increased strength and stiffness.

The original material considered for the belt was an industrial PVC conveyor belt. This would be the belt most commonly used in manufacturing lines. However, the belt performed best when driven by extremely powerful DC motors, which we did not have on hand.

Tensioning issues were also discovered with this PVC conveyor belt, as the downsized scale of the prototype meant that significant bending was required for the belt. Given its relative inflexibility, the PVC was soon ruled out as a poor choice.

Later experimentation with cling wrap and sandpaper yielded decent results, with the latter chosen for its better durability and aesthetics.

• Elevator

Preliminary Build

The elevator was built in a way that resembled the bed movement of a CoreXY 3D printer. The platform would be driven by lead-screw motors to move the luggage up and down, while linear rods would ensure the platform’s evenness.

It was later discovered that a single stepper motor was not enough to drive the whole elevator (there were originally two, but one had to be used for the unloading bay).

Resolving the issue required knowledge of moments and force distribution. The linear rods were adjusted such that there would be zero net moment at the points where the platform was connected to the rods.

Bottom trapdoor

The bottom trapdoor would be driven by a rack-and-pinion system, similar to how a car would be steered. This was driven by a DC motor.

• Electronics

The team had access to the Fabrication Lab’s PCB Maker, which allowed the creation of single-sided copper PCBs on which modules can be soldered to.

The final (third) version of the main PCB and schematic are below:

Full schematic, including sub-PCBs that are not shown in the previous image

Other PCBs were also created for power distribution to motor drivers and RFID modules.

This final PCB would be connected to a large number of modules which include (but are not limited to):

• 1x Raspberry Pi
• 1x LRS-350-24 power supply
• 2x Buck Converters (stepping 24V down to 5V and 3.3V output)
• 5x Screw-in Connectors, 3pin
• 4x DM420 Motor Drivers (a Chinese equivalent of the T6600 for stepper motor control)
• 2x Self-designed DC Motor driver (later replaced by a LN298N driver)
• 6x Servos
• 1x MFRC522 RFID Module (originally 5, but were scrapped due to programming issues)
• 1x HC-SR04 Ultrasound Module
• 2x KY-008 Laser Transmitters & Receivers
• 2x IRF9540N and IRF540N MOSFET pairs to simulate a NAND gate

Problems identified early on were the high power distribution that would be occurring on a copper surface. This was later remedied by having large traces (calculated via a trace width calculator) and with tape to cover the exposed traces.

Other problems identified with the PCB was its purported complexity. Due to the large number of components to be soldered to the PCB, there were several points of failure that would require significant amount of work to repair. This would be resolved by having additional, contingency connections (with excess GND pins) and extensive quality checks before adding it to the system.

• Self-designed DC motor driver

As part of a requirement for the Circuits & Electronics module, the following dual motor driver was designed:

The motor driver is flawed as the driver produces large amounts of heat. In extended periods of operation, this would be unsustainable (and very potentially dangerous).

This problem is somewhat resolved by the double driver, which engages in constant switching (through the programming) such that each driver operates only about half the time (inspired by motherboard MOSFETs). The driver also only operates for a limited amount of time, often only working for a few seconds for each passenger.

Lastly, the motor driver itself was not very reliable, having experienced multiple failures mid-operation. The reason for this has not been identified.

It is likely that more work would be needed in order to turn this into something more useful. At some point, the double driver was replaced by the commercial LN298N DC motor driver.

• Programming

The code, including its previous versions, can be found here. The key to the Firebase, however, has been removed.

One major adjustment for the code from the original workflow is how there is only one file that runs the entire prototype (other than a separate functions library). This is a significant downgrade from the previous plan to have four concurrent programs working with each other.

The main reason for such a downgrade was a misunderstanding of key Python rules that was the direct consequence of inexperience. Future iterations would likely have involved the addition of several, smaller micro-controllers such as ESP32 which would run each component individually, while the Raspberry Pi controlled them from above.

Overall, however, the code achieved all our required objectives.

Functionality Tests

Experiments were conducted at regular intervals to check whether the prototype was achieving our objectives. Of the six mentioned above, the brief overview of the results are shown below:

• Accuracy — Success
• Efficiency — Failed: Largely due to regular mechanical issues with the conveyor belt.
• Scalability — Indeterminate: The failure of the conveyor belt prevented accurate measurements of subsequent luggage pieces. However, should we ignore the malfunctions, scalability is entirely possible.
• Precision — Failure: The frequent malfunctions of the trapdoor at the elevator resulted in relatively poor precision
• Safety — Success: In all success and failures, the luggage experienced forces that did not result in any damage, even when scaled up.
• Cost — Success: The final expenditure was $1497.50, which included purchases for contingency purposes.

As far as the project is concerned, the prototype is a failure. Mechanical issues with the conveyor belt resulted in a 35% success rate, which is grossly unacceptable by industry standards. Given that this would be used in a customer-facing application, this failure rate is made even more apparent.

From a conceptual perspective, however, the project is actually relatively successful. While the project has yet to be integrated with existing infrastructures (especially bag-tracking technologies by Changi Airport), the experiments have shown that it is not difficult to do so. As a result, logistical challenges on the part of Changi Airport would not involve the creation of new technologies or systems.

From an architectural perspective, things get a bit more complicated. The kiosk dispenser system would require a revamp of the entire back-end and front-end luggage handling network that exists in the current luggage carousel system. This would, of course, be more challenging in terms of cost and assembly. For our part, we would therefore propose the solution’s implementation in new terminals instead, which would reduce the need to replace whole systems altogether.

Even then, cost would still be a significant concern. Current unloading and luggage distribution methods, while inefficient and slow, is very reliable and requires very little intervention and maintenance. While our solution may not necessarily be costly to build, it adds more points of failure (user input, mechanical dispensing errors, etc.) that may be unacceptable to the airport or the service industry. In that sense, there may perhaps be a need to take another look at the concept, in order to bring it closer to reality.

Personal Reflection

My part in the project is, as mentioned above, the programming and electronics.

In the previous project (SafeEntry gantry), the programming was done on an Arduino Mega and the electronics was limited to a few jumper wires. This time, however, we were now dealing with moving parts and far more modules than before.

One of the greatest challenges was the integration of the modules into the mechanical prototype. The eventual, final product is actually lacking a large number of modules that were sacrificed for the sake of reliability and functionality. Certain features were removed from the prototype due to a variety of reasons:

• Automatic database updates via RFID in each storage bay (Removed as the design of the storage bay failed to account for the RFID module)
• Parallel unloading from the storage bays (Removed due to a failure to integrate parallel programming)
• Double kiosk operation (Removed due to excessive cost)
• Elevator operation via pneumatics (Replaced by a lead screw stepper motor instead due to cost)
• Sorting luggage on the elevator via computer vision (Discarded due to excessive complexity)
• Using Arduino Uno as the sole communicating device for all input modules (i.e. lasers modules, RFID, ultrasound) to improve efficiency and lower code complexity (Discarded due to complications with packages, which were not updated up until the project)

Most of these features were discarded early on, while others were removed later on (in favour of more relevant functionality).

Other things, however, were a general success, and provided me much insight in the following:

• Single-layer PCB Fabrication, especially in the realm of power electronics. Sending up to 50W of power at a time through a single trace meant that I had to calculate (and give margin) to the width of the trace, and isolate the trace in order to prevent shorting (which would be disastrous).
• KiCad. As a beginner electrical engineer, the experience provided to me via PCB design was very valuable, though my design process could be optimised further.
• Integration of Raspberry Pi: Python is not hard to use, neither was programming the prototype particularly difficult. Learning to use the Raspberry Pi itself, however, proved to be very valuable. It has opened my eyes to other implementations such as in 3D printers or combining it with ESP32 micro-controllers.
• Mechanical design: While my input in the mechanical design was fairly limited, it has provided me some insight into assembly. The main insights involve cable management and handling of aluminum profiles, which I would soon be putting into good use when building of a Voron Trident 3D printer.

Overall, the project could be considered a general failure, as the prototype did not work properly, neither was it a proper and good design. However, given the scope of the project, I believe that what we achieved was well beyond our capabilities, and it is likely a matter of planning things better and further in advance, rather than a lack of our skills.

I would like to give special thanks to my teammates (whose LinkedIn profiles are provided in the top of the post), as well as the professors, Prof Pablo and Prof Teo for their guidance and support.