Background & Objective

In their final year at UBC, engineering students pariticpate in a Capstone project, a project which takes place with a real company and intends to produce a real product or prototype. The project is meant to engage students in the entire engineering design process, from stakeholder consulation to requirements generation, concept generation to prototyping, and analysis to validation. While teams generally form and choose projects in September, my team formed the April prior, and reached out to a client during the summer. Our client tasked us with developing a pressure sensor for use short-term use aboard a satellite or similar spacecraft.

The project was intended to address a market gap emerging alongside a revolution in satellite technology. Over the last decade or so, satellites have become much easier to launch, which has given rise to "small-satellites": small, short-mission satellites that can be cheaply produced, launched and iterated upon. For such projects, there is a lack of sensor options. Traditional space-rated sensors generally have long lead times, high costs, and feature more robustness and mass than is necessary for shorter-term missions. Automotive pressure sensors are cheaper and more compact - desirable qualities for small-satellite applications - but lack the necessary features for reliable sustained operation in harsh space environments. The purpose of this project was to design a sensor to bridge the gap between these two mature technologies to supply the emerging small-satellite market.

Development and Challenges

The project spanned the entire design process, and as such, as I had a multitude of roles throughout the project. I will detail some of the most meaningful and challenging experiences.

Vibration Analysis
A standard requirement of space-rated sensors is the ability to withstand the vibration environment they will be exposed to during launch. These vibration environments are quite extreme, and special care must be taken to identify and resolve any potential vibration-induced failure modes. I took responsibility for performing the random vibration analysis for the project.

I began by familiarizing myself with relevant theory for vibration analysis, such as interpreting Power Spectral Densities plots and using Laplace transforms to compute stress responses in simple structures. Once I had familiarized myself with the theory, I created a MATLAB script to calculate the vibration response of a simplified version of the sensor, iteratively adding complexity as I was able.

Once I had reached the peak complexity that could be analyzed by manual calculations, I moved on to random vibration simulation. Using SOLIDWORKS, I first recreated the simplified sensor and performed a simulation, whose inputs matched those of the MATLAB script. After corroborating results and determining I was performing the simulations correctly, I performed the simulation on the detailed model of the sensor. Using the results of this analysis, I was able to determine the parameters most influencing the vibration response of the sensor, and identified possible failure paths and modes to be resolved.

Testbench Design
One of the key requirements for the second was thermal and baric compensation, for which a second-order compensation scheme was needed. Without compensation, the sensor would produce highly inaccurate readings near its operational limits, which is visualized below.

To enable testing, I constructed a testbench which used a LabJack to collect data. I soldered thermocouple and pressure sensor connections onto perfboards, and connected them to the LabJack. I also added strain reliefs and other mechanical features to the testbench, which prevented the lead-ends of the connections from being damaged. Once the testbench was constructed, we connected it to various points along a manifold and collected data at different temperature and pressure points; this data was used to produce a second-order fit for the compensator to use.



Ultimately, the second-order compensation scheme was mostly succesful, bringing measurement error within project requirements. This could not be validated at lower temperatures, due to formation of ice and a lack of time to resolve this issue.

Statistical Analysis
To evaluate the effectiveness of our solution compared to others, performing statistical analyses was essential. One key analysis was the full-scale error of the solution. The analysis involved with this task was left to me. I determined that two data were necessary to computing the error:
1. The confidence interval for our sensors, based on the readings produced by a calibrated reference; and
2. The prediction interval for the compensation model, based on the standard deviation of readings
Distinguishing between the prediction and confidence intervals became central to understanding the total error analysis. A key challenge with this was to convey the analysis intuitively. I used several diagrams to attempt to do this, and with help from my teammates, determined how best to explain the analysis to laypersons.

Overall, this experience was extremely beneficial. It was a major contributor to my understanding of statistical analysis, exposing me to use of essential tools such as standard deviation and confidence. Using the analysis, we successfully characterized the reliability of our solution to accurately predict temperature.

Harness Design
Several pressure transducers were tested throughout the course of this project. One such transducer measured just 9mm in diameter, and required a custom harness to interface with the testbech. I constructed this harness using a set of crimps held in place by a 3D-printed frame. This required carefully designing features on the frame, since the 3D printer was limited in its capacity to produce fine details, and the frame was quite small and weak due to size constraints. The result was a "snowflake-like" frame, which had radial insertion lines and ridges to hold the crimps in place once inserted.



Finally, wires were soldered to the crimps, and the construction was held together by heat shrink. The harness was succesfully able to interface the sensor with the testbench, allowing for smooth data aquisition to take place.

Achievement

Ultimately, the project was highly succesful. Thanks to our combined strong presentation, details-focused design, and effective documentation, our team was awarded the Capstone Project Award among our cohort. I also received a 95% score in the class.

I learned a great deal of practical and technical skills throughout the project. I learned a great deal about random vibrations, and how to use SOLIDWORKS and hand calculations to analyze them for failure modes. I learned about test bench design and data analysis techniques. I also learned about mechanical design principles which have helped me become a more well-rounded engineer.

Project Poster, IPPW 2019

Background & Objective

In 2019, I worked for eight months at Thin Red Line Aerospace. One of the key projects I took part in was the development of an interplanetary probe platform, the "Altitude Control Balloon". The probe was based on a novel elevation control mechanism, described in the company's patent of the technology (US10196123B2).

I arrived at the company just a few weeks prior to the 2019 Interplanetary Probe Workshop, where the technology was to be demonstrated: in particular, the company intended to demonstrate a successful flight test. Developing the probe - both to enable the impending flight test, as well as to refine it afterwards - were primary tasks of mine.

In the following sections, I will describe some of the key challenges during the weeks preceding the flight test.

Development and Challenges

Most of my work concerned the mechatronic systems aboard the probe, which were many and complex. Upon my arrival, I began by identifying the most critical subsystems of the probe, and mapped the relationship of these subsystems using a UML diagram. This allowed me to prioritize development of systems within the limited development period preceding the test flight.

Control Systems
Perhaps the most fundamental task for this project was developing an appropriate control system. This task was highly nontrivial, in particular due to the novel control mechanism of the probe. As described in the patent document, a motor is driven to adjust the length of a tension cable. This tension cable runs through an envlope comprising a series of gastight ellipsoidal segments filled with a lifting gas. Adjusting the length of the tension cable causes the probe's envelope to compress or expand, depending on which way the motor runs, thus increasing or decreasing the density of the lifting gas. As the density of the gas changes, so does the average density of the entire probe. Buoyancy dictates that the probe will drive itself to that altitude where its average density is equal to the ambient air density, i.e., the equilibrium altitude of the probe. This is the fundamental control principle of the probe.

Given the novelty of this control mechanism, I could find no corellary control systems on which to base the ACB's. While an altitude could be achieved by driving the ACB to a certain internal pressure, there would be significant lag in achieving the desired altitude, as the buoyancy effect would diminish while approaching the altitude. Moreover, a knowledge of system characteristics, such as mass and gas density behaviour as a function of motor position, were vital to achieving optimal control.

I approached designing the control systems by first familiarizing myself with relevant control theory, mainly through online resources. Once I was confident in my understanding, I developed a control diagram outlining the control algorithm for the probe, and the way in which it interacted with an operator.



Tuning and testing of the control system represented another significant challenge. The size of the probe, in addition to its flight parameters (namely, the altitude range over which it could operate), made it impractical to test indoors. To address this challenge, I developed a comprehensive simulation of the balloon, which allowed me to tune the control system prior to field testing. This paid off hugely: A viable control algorithm was developed in simulation, and adjusted during field testing, producing higher-value results during field testing. Moreover, flight data was recorded on-board the probe, allowing for the simulation to be further refined, thus allowing control systems to be more precisely tuned prior to testing.

Communication Systems
For the flight test to be considered successful, the probe would need to engage a series of altitudes and trajectories. This was achieved by sending radio commands to the probe from a ground station. The ground station would also receive real-time flight data from the probe, allowing for the flight to be monitored. A LoRa radio was used to enable bidirectional communication between the ground station and the probe. LoRa was selected due to its ultra-long-range capabilities and ease of implementation..



One key challenge of the communication system involved feedback. Because of the lag in visible response from the probe (as observed from the ground), it was essential to know whether or not commands were successfully received and acted upon. To achieve this, I extended the base LoRa protocol to include acknowledgements, similar to common protocols such as TCP/IP. This enabled the ground station to indicate if commands had been received and resend commands otherwise. Overall, the implementation was highly useful during flight testing, where discerning whether or not the probe was executing a new command was practically impossible without feedback.

Mechanical Testing
In addition to the key flight test, I conducted a variety of other tests to validate various aspects of the probe. This included pressurizing a representative prototype up to its maximum expected operating pressure (MEOP), testing the mechanical winch which powered altitude control, and evaluating the reliability of various manufacturing processes which were used to construct the probe.

Achievements

Powered by the control and communication systems I developed, the probe carried out a successful test flight, demonstrating user controllability and impressive flight characteristics. The results of the test, as well as the technology more broadly, were presented at IPPW 2019, where they were very well-received.




This flight test represents an extremely significant milestone in my engineering career. It was the first time I was responsible for a major project deliverable that could have serious ramifications on future prospects for the company. I keenly remember the day of the test flight being simultaneously one of the most exciting and stressful days of my life. The success of the test bolstered my confidence as an engineer and informed some of the electives I took in the final years of my university career. I continue to ruminate on the project to this day, thinking of ways the design could be improved.

Improvements

When I took on this project, I was still relatively inexperienced as an engineer. Significantly, I lacked a substantial knowledge of modern control theory that would have been appropriately applied to the control problem at hand. While I was able to develop a highly-functional control system, I now have a much stronger understanding of control theory, and would apply an alternative control algorithm to solve the control problem.

Background & Objective

A few minutes' bike ride away from my house, there is a "Little Library" - basically a "Take a book, leave a book" shelter outside a local home. Many great books come through this little library, and recently, this classic by Don Norman appeared.

In fact, I am quite interested in the field of design. I have been exposed to principles of design, such as Design for Manufacturing / Assembly / Usability (DfM / DfA / DfU), and applied these principles extensively during my term at Novo Nordisk A/S where I designed mechanical tools for cleanroom-grade insulin production lines. This experience left me with a hunger to learn more about design principles.

It was this desire, coupled with my interest in continued learning and some serendipitous timing, that inspired me to read this book.

Key Learnings

Overall, I found the book to be very engaging and readable. Some of the sections were reminiscent of the design principles I learned throughout my education at UBC, which I can only imagine applied some of the principles that are laid out by the author. I found that, where my academic experience constructed a framework that spanned the entire engineering design process, this book offered helpful sub-frameworks to enhance my ability to design effectively. For example, it emphasized the importance of defining and solving the correct problem, the role of iteration within individual stages of the engineering design process, the importance of consideration human psychology when designing, and the effects of business on the practical realizability and viability of excellent designs.

The Double-Diamond Model of Design
This book introduced me to the Double Diamond Model of Design. Introduced by the British Design Council in 2005, the model emphasizes divergent-convergent thinking during the design process not only when producing solutions, but when defining the problem to be solved. My formal education explored the former quite extensively, but the idea of applying such thinking to developing a solution was a novel idea for me.



This way of thinking struck me as being excellent for innovation. To spend significant time defining the problem properly may seem like time wasted, but in reality, doing this enables significant innovation by developing a strong understanding of what is truly needed. As Norman states, Good designers never never start by trying to solve the problem given to them: They start by trying to understand what the real issues are.

Action-Centered Design
Prior to reading the book, I was familiar with the notion of human-centered design. Action-centered design, however, was a new thought to me. Basically, ACD posits that the action itself should guide product design, rather than the individuals. This works because activites across the world tend to be similar. This approach allows for designs to meet the needs of large, nonhomogeneous populations, even if the nonhomogeneity manifests as very different cultures.

For example, the Apple iPod was a great success because it was focused around the entire activity of listening to music, rather than the tasks that comprise it. It's ecosystem combined the tasks of discovering, downloading, organizing, playing, and sharing music, to produce a satisfying experience for the end-user. Indeed, seamless end-user experiences continue to characterize Apple products.

The conjunction of the Double-Diamond Model of Design with Action-Centered Design would seem to enable designs to address human needs at their root, resulting in much more holistic solutions than could be achieved by solving individual tasks (e.g., download music).

Conceptual Models
One very interesting idea from this book is that of the conceptual model. In essence, people using a product have some internal conception of how the system works. Norman stresses that this model need not be correct, so long as it is useful. Confusion and frustration arises especially when a conceptual model is difficult to glean.

The example of a fridge is given. This fridge has two knobs which suggest that the temperature of each unit (i.e., the fridge and freezer) are controlled independently. This immediately becomes the conceptual model of the uninformed end-user.



Unfortunately, this conceptual model is incorrect. Rather than the temperature of each compartment being controlled independently (as visualized below on the left-hand side), the system actually works such that one knob (the one labelled "Freezer") controls the cooling unit while the other knob controls a valve which determines how much cold air is diverted to the freezer. Such a model (depicted below on the right-hand side) is practically impossible to ascertain without consulting external resources, such as a manual.



For a pleasant end-user experience, it is critical that a strong conceptual model is ascertained. Norman offers a framework for the different stages an end-user engages in when interacting with an object which help them to form their conceptual model. He calls this framework the "Gulf of Execution and Evaluation."



I find this framework to be very helpful. A design can be evaluated in terms of each step the end-user will engage in, ensuring that the design meets the needs associated with each step. Thus mappings, signifiers and feedback are considered explicitly.

Other Takeaways
There were lots of little takeaways from this book that I plan to use in my work:
- When receiving feedback on a prototype, aim to have at least five people test it.
- When receiving feedback on a prototype that is designed for a single user, consider having two users: One to dictate what actions to perform, and one to execute these actions. This results in problems being communicated clearly.
- A good design should accomodate a user who is interrupted, such that when they return to the task, they can immediately glean all relevant information. In other words, don't force them to remember things - the Short-Term Memory can only retain a few items at a time, anyway.
- If the design requires too much a priori knowledge, move that knowledge into the world.
- The Five Whys: Japanese procedure for getting at root causes, originally developed at Toyota. When a "root cause" has been found, ask why that was the cause. Do this about five times to get at the real root cause.
- Rather than focusing on improving a products weaknesses to match competing alternatives, consider focusing development on its strengths.
- Standards are important, but must not be developed too early (to avoid fixation on primitive technologies, or introducing inefficient constraints) or too late (where there are so many solutions that it becomes impractical to standardize, or technological development will outpace the need for the standard)
- Though technology changes, human psychology does not; thus, designing around psychology is a timeless skill to have!

Background & Objective

At UBC, I took a fourth-year engineering economics (MECH 431) course. Throughout this course, we routinely performed economic analyses, and the recommended software for doing so was generally Excel. Quite quickly, my classmates and I discovered that Excel, while effective for listing transactions, was cumbersome for performing complex economic analyses, often requiring changes to be manually reflected across several sheets.
The objective of this project was to develop a Python library which would match the simplicity of Excel, while significantly simplifying the work required to perform complex analyses and visualizations.

Development and Challenges

Immediately upon beginning, I encountered the first major challenge of the project: How to structure the software package. There were several possible ways to implement this package, so I began with high-level function design: I designed a variety of function stubs for the core functionality of the library, and showed it to classmates to receive feedback on which was the most intuitive. After selecting my favorite design, I created a UML diagram outlining the design in greater detail. This allowed me to design a class hierarchy.

After having determined the design for the package, I began implementing the software. The base Project and abstract Cashflow objects were first, as these preceded the rest of the project's functions. I created a Git repository to track my changes, and hosted the repository on Github. Once I had implemented the abstract base Cashflow class, I easily created specific cashflow types, such as Present, Future, and Annuity cashflows. These could added to a project in a single line of code, with the ability to forecast to any period . (Including infinity - more on this later!) I also used Pandas to generate dataframes to represent the cashflows with ease.
A comparison between the Python code and a typical Excel cashflow spreadsheet reveals the simplicity of PyEEA compared to spreadsheets.

Equally simple is visualizing the cashflows.

The real benefit of the project arises once analyses are considered. Typically in Excel, analysis methods such as simulations or sensitivity analyses require a new spreadsheet to be created, with either manual matching or complex linking to maintain parity between sheets. PyEEA offers a much simpler interface, declarative interface. For example, a sensitivity analysis, which valuates the project based on percent deviations in cashflow values, is performed as shown:

Other key features of the project were the implementation of taxes, depreciation-based tax shields, cashflows of higher complexity (e.g., Perpetuities, Geometric and Gradient Series, Learning Curve models) and ability to output Excel sheets from Project objects.

Achievement

During the four-month course, I developed this Python package and used it to complete all my class assignments. At the same time, I began my work term with Novo Nordisk. Thanks to good timing, I conducted my final project for the course in collaboration with Novo Nordisk. For the project, I performed an economic and feasibility analysis on introducing advanced 3D printing technologies into the company's sterile part production workflow. I considered a variety of 3D printing technologies, using PyEEA to compare the cost of each to baseline operational costs. Ultimately, I identified a potential use condition for one 3D printing technology that could reduce costs of procuring spare parts by up to 20%, which I presented to my department manager.

Improvements

I had initially intended to publish the project on PyPi, Python's package indexer. While I did make an initial push of PyEEA to the PyPi test environment (https://test.pypi.org/project/PyEEA/), I ultimately did not have the time to polish the library into a state I would consider worthy of production. If I had more time, and perhaps a business case, I would like the opportunity to dedicate more time to the development of PyEEA.

Background & Objective

At UBC, I took a fourth-year industrial robotics course. The final project for the course involved implementing a control algorithm onto a real-world robot. Some friends and I formed a team, and decided to implement a pick-and-place algorithm to be implemented on a Da Vinci Surgical Robot. The algorithm would identify colored objects on a surface using the robot's endoscopic camera and actuate the two robotic arms to collect these items and place them into a designated bucket or drop zone.

Development and Challenges

This project presented several challenges. First was the time-limited scope of the project: We were given just a few weeks to complete this project, which featured hardware and software we were largely unfamiliar with. There was the additional challenge of availability: These robots are multi-million dollar machines (Two of the three robots in BC are located in this lab) and so any damage to the robot might prevent us from completing our objective in time. This was especially relevant since we our algorithm would need to use both robot arms simultaneously, which posed the threat of arm collision.

After identifying these risks, we began by designing the control algorithm for the robot. The algorithm would need to combine computer vision and pick-and-place steps. Given the tight time constraints for the project, we limited the scope to performing an open-loop pick-and-place, based on a single image capture from the endoscope.

Two control layers were specified for the design. The first layer, known as the Patient-Side Manipulator (PSM) Controller, was responsible for driving the individual robot arms. This included requesting items and receptacles from higher control layers, and executing the actions safely. The control algorithm is visualized in the diagram below.

The second control layer, known as the Pick-and-Place Controller, managed the PSM Controllers for each arm by implementing control measures such as collision avoidance algorithms. The algorithm is visualized in the diagram below.

A Target Dispatcher is also implemented which allows the objects identified by the computer vision algorithm to be dispatched to the most logical PSM for pick-up. This was done by sorting items into a double-ended queue based on an effort function, as visualized below.

Trajectories were generated in task space which presented certain challenges. Of primary difficult was the fact that "optimal trajectories" were often not linear, and could result in the arm colliding with the table. To avoid this issue, trajectory executions were conducted at an offset height, and the arm "lowered" onto objects to pick them up. This also eliminated the possbility of objects being knocked about by the manipulators, which could cause the open-loop algorithm to fail.

When it came to testing the algorithms, several measures were taken to avoid causing damage to the robot. Firstly, we began by using simulations to validate our control algorithms. This caused some other issues, however, as we discovered that the origin of each robot was different based on its initial conditions. To remedy this, we implemented a calibration routine, which allowed the robot to have a virtual origin that could be referenced while executing pick-and-place tasks.

Once we began physical tests, we reduced the robot speed to a fraction of its full potential. This not only greatly reduced the possibility of damage from high-speed collisions, but allowed for a greater timeframe during which an emergency stop could be triggered. Once we were comfortable with the algorithm, we gradually increased speed again.

Achievement

Ultimately, our team was successful in implementing and validating the pick-and-place algorithm. The project was presented to the professor and class, and was well-received. I received a 92% score in the course.

Improvements

Though the project was a success, there were certain key limitations of the final product. Most notably, while the CV and Pick-and-Place algorithms were independently verified, some issues arose during final testing which prevented the endoscopic camera from being used, and thus eliminated the possibility of using CV. Thus, the final product has not validated the integration of CV with the Pick-and-Place algorithm. If we had more time to diagnose the endoscopic camera problems, I would have loved to perform the full system test.

Another issue was trajectory generation, as detailed above. In a future implementation, I would attempt to implement a better trajectory generation scheme using the inverse kinematics of the robot (which are published) which would allow for linear trajectories, or even more complex trajectories which offer more sophisticated collision avoidance.

Background & Objective

In 2019, I worked for eight months at Thin Red Line Aerospace. One of the first projects I took part in while there was developing a wheel to be used aboard probes being designed for ocean worlds (e.g., Europa, Enceladus) whose cold temperatures and variable icy surfaces represent significant engineering challenges for traditional mobility solutions.

To address this, Thin Red Line applied its proprietary ultra-high pressure vessel (UHPV) technology to produce a wheel capable of navigating the complex conditions of Ocean Worlds. The design features a series of UHPVs along the annulus of the wheel, which provide structure to the wheel alongside a variety of other components.


I was tasked with developing some of the other components of the wheel, particularly the spokes.

Note: All graphics contained in this entry have been retrieved from Lu et al., 2023). I do not take credit for producing any of these graphics.

Development and Challenges

The wheel features an array of Vectran tendon spokes, which are activated upon pressurization of the wheel segments. I was tasked with developing a method for preprocessing, manufacturing and assembling these tendons. Preprocessing was necessary to achieving predictable behaviour of the spokes, e.g., by eliminating undesirable qualities present within virgin fibers. This process required some trial and error, and I used strategies such as OFAT to guide these efforts. Once I had developed a working preprocessing strategy, I codified a manufacturing and assembly process for the resultant fibers in a technical memorandum.

Soon afterwards, I fabricated a number of tendons, which were used in the assembly of a testable prototype.

Achievement

The prototype wheel above was sent to Purdue University for testing. These tests are described in the paper, "A Single Wheel Test Rig for Ocean World Rovers" by Lu et al, 2023. Overall, the prototype was a scale-model success, proving that such an Ocean World Wheel is feasible.

Background & Objective

At UBC, I took a third-year machine design (MECH 325) course, where I learned how to select machine components based on operational parameters of machines. Throughout the course, I learned how to use selection manuals and textbooks, such as Parker's Hydraulic Cylinder catalogue, and Mott's and Shigley's Machine Design textbooks. For a final project, we were tasked with developing a machine using the principles we learned in the classroom.

My team and I got in contact with Pavillion Renewables, a Bahrain-based renewables firm, who sponsored us in designing a sun-tracking solar panel, with the potential for scaling up to a panel network, for use in the desert environments of Bahrain.

Development and Challenges

Hydraulic actuators were selected for actuation of the solar panels, which I was primarily responsible for designing. To do this, I referred to Parker's Hydraulics design guidelines which allowed me to select properly-rated cylinders for the job. Due to the high potential wind loading that the panel would experience, in addition to the sheer weight of the panel, the cylinder would need to be able to support significant load. Based on the forces and (low) speed requirements for the solar panel, I selected a PH 2HX Cylinder, which achieved a safety factor of four based on operational requirements.

In addition to the above, I also specified some additional features for the hydraulic cylinder to accomodate the desert environment, such as PTFE wiper bushings to prevent sand and grit from entering the hydrualic chamber.

Once the hydraulic cylinder had been specified, I then designed the pump network, which was needed to achieve the client's vision of a networked series of solar panels. Based on customer specification of ten solar panels, This allowed for a centralized system and fewer machine components overall. This setup is visualized below.

I again referred to Parker Hyrdaulics guidelines to select the pump, motor, tank, piping and hosing necessary to create the network. The connection of these components is shown in the circuit below.

Achievement

At the end of the year, the project was presented to the professor and classmates. It received positive reviews, with the professor suggesting that the project could be considered for a Capstone project (i.e undegraduate final project).

Improvements

While it was exciting to design this solar panel, the design was purely theoretical. Had we had more time, or perhaps chosen to pursue this project as a capstone project, I would have liked to try building the mechanism, especially the integration and validation of hydraulic cylinders. Still, I believe my experience in this project has prepared me to specify and integrate hydraulic cylinders in a future project.

Background & Objective

In 2020, some friends and I decided to form a team to participate in RookieHacks, a hackathon based around learn after the arrival of the COVID-19 pandemic, and was part of the surge of online hackathons that took place in its wake, We saw the hackathon as a great opportunity to learn some new frameworks (we ended up learning ReactJS and MongoDB), and of course, we hoped for a chance to win one of the first-place prizes!

As always, the hackathon began with a brainstorming session. Our team considered a variety of web applications to build. Ultimately, noting that COVID-19 relief efforts were largely global in scale, we decided to develop an app to facilitate support for COVID-19-related initiatives on a local scale. The app would achieve this by bringing awareness to projects in one's community.

Development and Challenges

I was primarily responsible for developing the front-end application using ReactJS. To do this, I created a declarative routing framework for navigating between windows, and developed the various navigable pages. This especially included the home page, where users could browse COVID-19-related projects, and the login page, which connected to our MongoDB database.

One major challenge for the project was how to distinguish the app from competitors. This was partially resolved by our focus on local projects and initiatives, but we felt that this was still not enough. To further distinguish the application, I implemented a project sorting system. The system allowed users to sort through COVID-19-related projects based on a variety of categories. These included:
- How close the project was to completion, both in absolute (dollar) and relative (percentage) terms;
- The physical proximity of the initiative to one's location, as determined using reverse geocoding;
- Other common filters such as alphabetical sorting, sorting by newest/oldest project, etc.
Using these filters and sorting methods would allow users to sort through the many COVID-19-related initiatives in their area with relative ease. Those wanting to "boost" projects near completion would be able to do so, while others who wanted to make donations to the nearest initiative would have the means of discovering them.

Achievement

Ultimately, our team was awarded "1st Overall Beginner" among the 371 total particiapnts for our development and presentation of COVIDONATE. The application was presented to all participants at the awards ceremony. We hosted the app for a year as a Heroku app. (The website has since been decomissioned, but can still be viewed on the RookieHacks website.

One of the first place prizes was a pair of Snap Spectacles, which I have used to record many POV videos of my travels, longboarding sessions, and more, which can be viewed on my YouTube channel.

Improvements

Given the rapid turnaround time on the project (as is typical of hackathons) the functionality of the website was favored over aesthetics. There was very minimal styling done on the website, which I would address if given the chance to work on this website again. (I have, incidentally, spent much more time styling this website than that one!)

Background & Objective

Dodgems was a quick game I developed while trying to familiarize myself with the PyGame library. I wanted to create a skill-testing game that would be fun to test, while allowing me to implement a bunch of features I was interested in.

Development and Challenges

The game is rather simple in nature, and (in my opinion) highly addictive. The user controls a sprite (MegaMan) by teleporting him to one side of the window. The position is determined by crosshairs, which move up and down the screen, while the player stays put. The player teleports by pressing the appropriate arrow key.

The game begins with a single enemy (Thwomp) moving across the screen, bouncing against the window borders. Every few seconds, another enemy spawns, moving in a new direction. Each thwomp moves in a random direction with a random speed. Once a thwomp collides with the player, the game ends. The longer the player survives, the more points he earns.

Achievement & Improvements

I was able to implement the game above, and had some friends playtest it. They thought it was quite fun - even if they did die pretty quickly. :-)

At present, the game still has many bugs. The enemies despawn, but their hitboxes do not, so there becomes an "invisible kill zone" for the subsequent games. While the added challenge may be appreciated by some, this becomes especially tricky when the player dies in the top left corner, where they spawn. (They enter an infinite death loop!) Really, the only reliable way to play the game right now is to restart the client after death.

Nevertheless, I am quite pleased with the game. Though simple, my friends enjoyed playing it, as did I. If I were to return to the project, I would love to publish it to the Play Store as an app - I think it's a great game for mobile platforms!

Background & Objective

Longboarding has long been a passion of mine. I began longboarding in 2012, have skated across Vancouver annually since 2017, and have recorded several of my longboarding adventures in videos, which I post to my YouTube channel. (Check out my YouTube playlist!) A friend of mine had access for a time to a wood compressor. He gifted me a fresh longboard deck, which kicked off this project. After having skated for many years, how cool would it be to make my very own board? My objective with this project was to better understand the longboards I so love riding, and to put my own style into a board of my own.

Development and Challenges

Designing the Board
The immediate challenge for this project was producing the design. I began the project by recruiting my sister, Anna - who is far more artistically gifted than I am. Together, we collaborated on producing a design for the board. All of my boards are named after fish, and the friend who gifted me the deck called me "Squid" - so a squid design seemed obvious. I initially found a picture of a squid as inspiration for the board:



My sister and I then discussed how to best apply this inspiration. We both agreed that a design spanning the entire length of the board would be extremely cool. I also wanted some room for stickers around the design. She suggested a technicolor aesthetic, which I thought sounded awesome. This brainstorming session concluded with her producing a sketch of the design:



We repeated this concept a few times, before finally settling on having the squid on a background of deep blue, with bubbles surrounding him and plenty of blank space around the border. I also decided to paint a danish flag design on the top of the board (I am half-danish). To get a better feel for the design, I scanned it and produced a mockup of the longboard on my computer:



After settling on this design, I got started on finishing and painting the board.

Construction
To begin the construction process, I determined first to finish the board to eliminate the blemishes it had, which I feared would present difficulties during the painting process and lead to premature deterioration of the board. This was done using a belt sander.



Once the board was sanded to my liking, I then primed and painted it. I started by painting the top design of the board, using tape to achieve the white stripes.



I then sought to paint the bottom of the board with a blue base. Unfortunately, I noticed some imperfections in the bottom of the board after priming it: Small gouges in the wood which would make it difficult for paint to stick. To solve this, I made a slurry of wood glue and wood chips to fill the gouges, then applied another layer of primer.



Now it was finally time to paint the bottom of the board. I wanted to make a blue gradient, like one would see in the ocean such that going higher makes the blues brighter. I experimented with producing a gradient on some cardboard, then painted multiple coats of blue onto the board to achieve this effect.



Once the board had dried, my sister Anna meticulously painted the board.



While painting was ongoing, I ordered the parts for the board. I specifically wanted to build the board to be able to slide, so for wheels, I chose Abec 11 Flashback Amber Thane wheels, which are known for being especially buttery smooth.



After letting the board dry, I applied a few layers of Clear Coat. At this point, it was late August, which meant the temperature was still high enough in the evening to be within the paint's specification.



After a few more days, the clearcoat had dried, and I prepared to apply the grip tape.