Category: Uncategorized

Families of people struggling with addiction in South Asian, Middle Eastern, and other Eastern cultural communities are left completely without support due to cultural shame and stigma around mental health. Existing tools are built on Western, clinical frameworks that don’t account for these cultural realities. No tool currently exists that calms a family member physiologically, speaks their language, and understands their cultural context well enough to actually help them.

The target audience for this problem, solution, and project is a very niche group of ethnic or cultural individuals who struggle with addiction or mental health, along with the corresponding families that care about them, but do not know how to help. These individuals can come in all ages or backgrounds, however an approximate age classification is individuals ranging from about 30 – 70 years of age. For the older members of this audience, there is great stigma (especially for men) surrounding help for mental health, which causes them struggles in the healthy management of emotions or addiction. Moreover, coming from cultural backgrounds, many of these individuals lack technological skills; when paired with cultural nuances in diction and norms, these individuals are often left feeling isolated and become difficult for families to support. 

This research paper contained a substantial amount of information as to the actual thinking and processes that occur in the mind of an addicted individual. Amid this influx of information, I challenged myself to efficiently filter through it and find information that was specifically relevant to my project. 

Hybrid Intentions:

Firstly, I learned about motivational states called hybrid intentions by the author. I learned that these are very closely related to action but are distinct from typical intentions in terms of being subject to free will. I initially was perplexed that the author calls these intentions “motivational liabilities” (129), because in a way, this contradicts his previous statement saying that hybrid states are related to action. However, after analyzing the context in which this was stated, I found that he means that hybrid intentions negatively motivate the “agent” (the individual) to conduct action and are more difficult to control. For my project, this learning about hybrid intentions prompts a deeper question which I will strive to answer in my next phase of research: How can hybrid intentions be mitigated and what causes them to have such an influence on the agent? 

Assess the state of mind:

Secondly, I learned that instead of asking whether or not to blame the addict, it is more accurate to assess their character (their more or less stable set of cognitive, behavioural, and affective disposition. This is crucial for the way in which I construct the AI portion of my solution, as it means that I must program the AI to come across as comforting and not at all condescending, even if it is by AI error. This will pose an ethical concern over whether or not this AI can in fact use this research to comfort an individual, or whether it instead derails them further into their state of mind. 

Here is the link to the paper: https://research.ebsco.com/c/m7jfwd/viewer/pdf/l3xn462isf

This research contained comprehensive information as to the intrinsic motivators behind addiction, specifically drugs or alcohol. Once again, I was challenged to filter through to only the most relevant information for my project. 

Humans need stimulation:

One of my crucial findings from this paper was that it is part of the primitive instinct for humans to crave stimulation. This craving for stimulation comes when we fall below the “comfortable equilibrium” (7), according to the paper. I found that this is a particularly dangerous zone, as this is where individuals begin to turn to harmful substances such as drugs or alcohol. After this finding, I found that it would be particularly interesting and effective for my project if I could find a way to trigger the same dopamine of stimulation from a calm and comforting AI device.  

Drugs release dopamine:

While we hear about the dopamine that we are all addicted to in the form of social media, this same dopamine is released from drugs. This is the dopamine that cures our craving for stimulation and fuels the heart of addiction for addicted individuals. As I came across this section in the paper, I found myself asking the question: What if there was a way to cure a state of vulnerability and longing for dopamine, by triggering a small amount of a positive kind of dopamine? This is a question that I will continue to explore in my continued research, and if I can find a way to integrate it into the AI’s framework, I believe that it will have a positive effect for individuals.

This is a biography by Marc Lewis, which outlines his addiction, starting with childhood experiences and moving through a 15-year struggle with drugs, including heroin, LSD, and meth. It describes a life of desperation, crime, and, ultimately, recovery. This is especially useful for my project as it clearly provides the addiction process, which is something that I will be learning from throughout my project. In terms of specific concepts, I have not yet comprehensively read the novel yet. More details about specific psychological concepts will come in a later blog post. 

This is a physical source, therefore no link can be provided.

This solution will be a physical device that includes a button. In times of need or emotional vulnerability, it is easily accessible for the struggling individual to press. Once it is pressed, an AI audio begins to play that speaks to the person in a calming and comforting manner in their language and understanding their cultural nuances. The person has a conversation with this automated assistant until they feel comfortable and stable, from which point they can ask the audio for a recommendation or seek help of their choice. This prototype would go beyond addiction to create safe space for mental health in communities that have never had one. 

Throughout the building process, It will include several intricate components:

Physical Components

• Haptic feedback motors for calming vibrations
• LED lighting system for breathing guidance
• Built-in speaker and microphone for voice AI interaction
• Discreet design to look like an ordinary object, not a medical device
• 3D printed housing with handcrafted elements

AI Components

• Understands cultural norms around emotional expression and family honor
• Built using Claude 
• Multilingual capability: Punjabi, Urdu, Hindi, Arabic, Mandarin, and more
• Trained on CRAFT methodology and culturally specific communication strategies
• Voice-only interface. No text or screen

In terms of testing, it will involve a testing plan that includes the following: 

• Present prototype to addiction counselors for clinical validation
• Present to members of South Asian and other cultural communities for cultural accuracy
• Test whether biofeedback component effectively reduces stress
• Validate whether AI responses are culturally appropriate and helpful
• Cannot test on actual families in crisis due to ethical boundaries

These phases correctly test the prototype against the definition statement, as they account for cultural nuances and testing against real addiction centred areas.

The first step to this project for me was to create an organized notion board which allows me to track my progress and outline clear tasks within a measurable timeline. In this board, I created several unique phases including: research, learning, design, building, AI development, integration and testing, refinement and documentation, and presentation. 

As previously mentioned, I focused the past few weeks on cementing my understanding of addiction psychology. This involved reviewing several unique sources such as the research papers previously mentioned along with the novel. I still have much to learn about cultural nuances and CRAFT methodology, which is what I will continue to cement into my learning.

The major challenge for this project will be the learning phase. My understanding of skills such as coding, Arduino, AI development, and others is highly limited, which is why truly learning these skills for my ambitious project will be challenging. 

Ensuring that I follow my timeline and do not fall behind is crucial, as this project involves several phases and steps to ensure it is completed to make the most impact possible. 

While I have already completed significant research into addiction psychology and intrinsic motivation, I still have research to execute. My understanding of cultural nuances, CRAFT methodology, and other psychological concepts is still not where I would like it to be. This learning for me, is extremely significant and interesting for this project, and solidifying a comprehensive understanding will serve me well in the later phases.

This phase will be crucial for my project, as it will equip me with all of the skills necessary to build both my physical prototype and the AI model. Specifically, I will be learning skills such as 3D printing, Arduino, Claude AI development, coding, and several others. I believe that using AI to learn these skills will be significantly efficient and helpful.

I have always been fascinated by how the human body works and the science behind it. In particular, I have always wondered about how the brain works, what goes on behind its decisions, responses, and how these are reflected through our actions.

For this project, I was interested in exploring the brain and our psychological state during the most vulnerable or dire times. As I began to think about how our brain may behave and what our response may look like during this moment of vulnerability, I came to the realization that there are several nuances behind each person.

As I reflected upon existing tools to support people during these times, I noticed that many were based on a Western ideology of support and high technological ability which do not resonate with several cultural and ethnic groups. This led me to define a significant problem that I have personally observed and researched.

Families of people struggling with addiction in South Asian, Middle Eastern, and other Eastern cultural communities are left completely without support due to cultural shame and stigma around mental health. Existing tools are built on Western, clinical frameworks that don’t account for these cultural realities. No tool currently exists that calms a family member physiologically, speaks their language, and understands their cultural context well enough to actually help them.

Pain Points:

• Addiction affects families across all cultures but creates unique barriers in South Asian, Middle Eastern, East Asian, and other cultural communities.
• Cultural shame and stigma prevent families from ever taking the first step toward help.
• Existing resources are built on Western frameworks that fail to understand cultural nuances.
• Family members suffer in silence, watching someone they love struggle, with no guidance on how to help them.
• In these cultures, emotional expression is suppressed (especially for men) making conversation based tools ineffective.
• The physiological stress of watching a loved one’s addiction id not currently being addressed.

The target audience for this problem, solution, and project is a very niche group of ethnic or cultural individuals who struggle with addiction or mental health, along with the corresponding families that care about them, but do not know how to help.

These individuals can come in all ages or backgrounds, however an approximate age classification is individuals ranging from about 30 – 70 years of age. For the older members of this audience, there is great stigma (especially for men) surrounding help for mental health, which causes them struggles in the healthy management of emotions or addiction.

Moreover, coming from cultural backgrounds, many of these individuals lack technological skills; when paired with cultural nuances in diction and norms, these individuals are often left feeling isolated and become difficult for families to support. 

During my initial brainstorming and ideation sessions, I considered some solutions that I believed would solve the problem, could be created as a prototype within the given timeframe, and could be tested. However, though all solutions were legitimate and realistic solutions to the problem, some simply were not unique, testable, or feasible to create.

An app that empathizes with and consoles users experiencing mental health or addictive issues:

The idea of an app was an idea that I considered carefully throughout the entire process of ideation. I had initially envisioned a detailed app that would include a unique personalized and automated artificial intelligence that would be designed to support individuals experiencing addiction or mental health issues during the most difficult moments.

While this would have been testable, it did not completely address the problem and it was simply not feasible. I quickly found that navigating an app, especially for older generations and those with language barriers would be a major challenge.

Moreover, I also was forced to show realism in this phase of ideation. Due to my limited experience in coding, this would be a major learning curve that I believed would take away from the significance and true concept of this project.

A wearable device or tracker that monitors behavioural changes and alerts family members accordingly:

The idea of monitoring behavioural changes fascinated me at first, however I quickly realized that it would not fully address the problem and would include other problems. While monitoring behavioural changes is a logical and scientific approach, a wearable device or tracker may make individuals feel an invasion of privacy and can be easily taken off.

This idea would appeal more to the families of the individuals; however due to the isolation that individuals experience from their own families, they may not be comfortable sharing their behaviours and feeling controlled. Moreover other problems such as a lack of coding skills would plague my ability to create a prototype.

A physical device that people can connect with. With the click of a button, it triggers a culturally nuanced AI audio empathizer which consoles and provides people with comfort:

Ultimately, this is the solution that chose to create a prototype because it best addresses the problem and was the most feasible. More on this idea is explained under the prototype section. 

This solution is a physical device that includes a button. In times of need or emotional vulnerability, it is easily accessible for the struggling individual to press. Once it is pressed, an AI audio begins to play that speaks to the person in a calming and comforting manner in their language and understanding their cultural nuances.

The person has a conversation with this automated assistant until they feel comfortable and stable, from which point they can ask the audio for a recommendation or seek help of their choice. This prototype would go beyond addiction to create safe space for mental health in communities that have never had one. It includes several different components.

Physical Components

• Haptic feedback motors for calming vibrations
• LED lighting system for breathing guidance
• Built-in speaker and microphone for voice AI interaction
• Discreet design to look like an ordinary object, not a medical device
• 3D printed housing with handcrafted elements

AI Components

• Built using Claude 
• Multilingual capability: Punjabi, Urdu, Hindi, Arabic, Mandarin, and more
• Trained on CRAFT methodology and culturally specific communication strategies
• Voice-only interface. No text or screen
• Understands cultural norms around emotional expression and family honor

Testing Plan:

• Cannot test on actual families in crisis due to ethical boundaries
• Present prototype to addiction counselors for clinical validation
• Present to members of South Asian and other cultural communities for cultural accuracy
• Test whether biofeedback component effectively reduces stress
• Validate whether AI responses are culturally appropriate and helpful

Task List:

1. Through research into addiction psychology, cultural nuances, and responses during moments of vulnerability.
2. Address the learning curve by learning how to use 3D printing, using Claude to create a personalized AI, and audio and arduino installation within a physical device.
3. Design physical prototype and components
4. Construct physical prototype
5. Develop automated AI conversation framework, cultural adaptation, and audio integration
6. Integrate and test the prototype with families
7. Refine prototype based on feedback and validate with experts
8. Outline final presentation

Timeline (10 Weeks):

• Weeks 1-2: Deep research into addiction psychology, CRAFT methodology, and cultural stigma
• Weeks 3-4: Design physical prototype and source components
• Weeks 5-6: Build physical device and integrate sensors
• Week 7: Develop AI conversation framework and cultural adaptation
• Week 8: Integration and testing
• Weeks 9-10: Refinement, validation with experts, final presentation

Key Benchmarks:

• April 24th – May 1st – (Spare Week for Extra Focus)
• February 27th – Research Due
• March 6th – Learning and Technical Skills Mastery Due
• March 13th – Design for Physical Prototype + Components Due
• April 3rd – Physical Prototype Due
• April 10th – AI Framework Due
• April 17th – Integration and Testing Due
• April 24th – Final Adjustments + Prototype + Reflection Due 

This planetary explorations project provided my team members and myself with the unique opportunity to explore an exoplanet of our choosing and design a prototype for a hypothetical vehicle that could traverse it. Throughout the design process of this vehicle, we considered factors such as terrain, energy efficiency, and structural integrity, to create an effective and innovative solution. Ultimately, heading into the testing phase of this project, we sought to build a vehicle prototype that overcame these challenges, taught us valuable lessons (about engineering and design), and revealed the implications of these test results on our exoplanet, Teegarden’s Star b. 

During the early stages of the project, we developed a specific, and clear definition statement to guide us through the process. It details all of the challenges that the vehicle needed to overcome, the exoplanet’s conditions, and the implications of these elements for our proposed solution. Here is the full definition statement:

Four human astronauts need a safe and efficient way to travel 10 continuous km across Teegarden’s Star b due to unique atmospheric, gravitational, and geological conditions. We must overcome challenges such as a differing gravitational pull, rocky terrain, and uncertain atmosphere by creating a testing environment that models these conditions. 

Our solution to overcome the several challenges stated in the introduction experienced several changes/alterations from the beginning to the end of this exploration. 

In the early stages of ideation, we honed in on specific functions of the vehicle, brainstorming solutions for each function. We later put together our findings for each function to create a vehicle that could traverse the terrain of Teegarden’s Star b. 

Mobility:

Based on our background research for our planet’s surface, we believed that our system for mobility must include traction, stability, power, and endurance. We considered three primary features: A solid wheel based system, treads, and spider legs (for climbing rocky terrain). 

Here is an image of our physical brainstorming whiteboard: 

1. Wheel based system

For a wheel based system, we conducted research on several off-roading and heavy duty vehicles, allowing us to take inspiration and apply it to our vehicle. Firstly, we made the observation that many vehicles built to traverse mountainous terrain, such as the Jeep Wrangler use a wide tire base, along with a mud terrain tire pattern. We learned that a wide tire base could be essential in providing stability, weight distribution, and traction surface. It does this by distributing the vehicle’s weight over a larger surface area, resulting in a lower ground pressure. Secondly, we learned that suspension would be essential in maximizing traction, absorbing high-impact shocks from rough terrain, and providing stability. During our initial research, we observed that many of these off-roading vehicles use a coiled spring suspension, which is what we later used in our vehicle design. Finally, we found that the axle must be firm yet flexible, allowing the parts of the vehicle to move in unison, and increasing its ability to climb rocky slopes. 

2. Treads

Throughout our research, we found that several secure vehicles such as tanks utilize treads to reduce ground pressure, increase off-road mobility, and provide better grip for climbing steep hills compared to wheels. This was intriguing to us, during our initial research, however we also considered the negative effects of treads. These included a significantly limited maximum vehicle speed, a poor energy efficiency, and a reduced control system. 

3. Spider legs

For a large part of the early stages of our project, we considered spider legs due to their unique ability to effectively climb mountainous terrain, provide stability, and reduce dependence on atmospheric conditions. Unfortunately, our research showed that spider legs also included risky features such as a high centre of gravity, maintenance requirements, and weight vulnerability. Choosing not to proceed with this mobility system was a significant change throughout our process. 

Body design:

Based on our background research, we believed that the body of our vehicle must focus on three primary elements: shape, thermal insulation, and the optimal materials. Although all of these elements are crucial in testing our vehicle on Teegarden’s Star b itself, this project narrowed our focus down to the vehicle’s shape. This was due to the fact that radiation and solar flares were extremely difficult to test and may have provided misinformation about our vehicle’s performance.

Here is an image of our physical brainstorming whiteboard: 

1. Shape

Regardless of the mobility system we chose, we concluded that our vehicle’s shape must include hexagonal designs. Hexagons have been proven to provide the most structural stability, optimal weight distribution, and largest surface area. Structural stability and weight distribution are essential in traversing the rocky terrain of Teegarden’s Star b; Specifically, when climbing steep slopes, hexagons share the pressure from external force and weight, preventing the bending or collapsing of walls. For these reasons, we believed that a hexagon would be optimal for our test, however we also considered other angular configurations such as trapezoids and rectangles. For similar reasons, we concluded that while hexagons are optimal, these angular shapes would also be suitable. 

2. Thermal insulation + Material

While we could not directly test thermal insulation during this project, it remained a significant factor to consider, given Teegarden’s solar flares and potential radiation. Conducting extensive research led us to the conclusion that we would use polycarbonate in the form of rigid hexagonal panels, as an outer shell. Polycarbonate blocks almost the entire UV spectrum, including UVA and UVB rays, which would significantly protect our vehicle throughout its journey. Moreover, through utilizing this material in the form of micro hexagonal panels, and their rigid fit, we learned that our vehicle could safely reflect or absorb radiation. 

Energy, Fuel, & Power

Modeling our solutions for energy, fuel and power were difficult, which is why we ultimately used an Arduino circuit. However, during our early brainstorming sessions we established three primary features of this system: solar panels, a motherboard (to control all vehicle systems), and a lithium ion battery pack.

Here is an image of our physical brainstorming whiteboard: 

1. Solar panels

Due to the extensive exposure to solar radiation and flares, we sought to leverage our environment to our advantage through harnessing its energy. Through the installation of solar panels, our vehicle would intake energy without dependence on an atmosphere, which was a significant reason for this choice. Moreover, making these solar panels adjustable to intake solar radiation from various angles and quantities, would equip our vehicle with the longevity to successfully travel the required distance. 

2. Motherboard

Our initial motivation behind a motherboard was a simple way to control all systems of the vehicle, from one compartmentalized place. However, after conducting research, we also found that the Mars rover RAD750 uses a motherboard similar to what we envisioned. Therefore, we were able to draw inspiration from this, including components such as a bridge chip, a voltage revolver, an L2 cash, and others. For more information on the motherboard, here is a visual of what it would have looked like.

3. Lithium Ion Battery Pack

Finally, for another source of energy, in the event of a hardware issue in the solar panels, we chose a lithium ion battery. We found that these could be rechargeable, provide short and strong bursts in crucial situations, and easily integrated into the vehicle system. For these reasons, we chose this for our backup option, however we simulated this through the use of a traditional AAV battery pack. 

Selecting an effective and efficient path for each of the elements previously discussed was crucial in shaping the process of our vehicle design. These fundamental aspects of the vehicle included its shape, mobility method, and additional features.

1. Shape

While we did consider a hexagonal shape at first, the shape’s geometry presented challenges when mounting motors and aligning axles, as the angled edges reduced the available flat surfaces required to attach additional components. This led us to pivot towards a rectangular shape for our first test and for the rest of this project, as it provided long, parallel edges that simplified motor installation, improved axle alignment, and increased structural support for the materials at hand. Moreover, we reasoned that for our first test, the priority would be testing the robotics components to ensure that the vehicle moved efficiently and carried enough energy to traverse our terrain. 

2. Mobility Method

In terms of our choice between treads, spider legs, and wheels, we ultimately decided to proceed with a wheel based system. We deemed that the risks of the spider legs supporting the vehicle’s weight and effectively moving in direction eliminated this option for our prototype. In addition, we found that using treads would expose the vehicle to rapid changes in direction, and the slope of mountainous terrain. Therefore, we selected a wheel based system, because reviewing our background research reminded us that the sheer size and detailed patterns of the tires would be best for our planet’s terrain.

3. Additional Features

In terms of adding additional features to support and guide the vehicle strategically through the test environment, we sought out to create a ramp and a suspension system. However, the need for these systems were evident after our first test, as prior to this test, we believed in a simplistic design which included simply the essential features. More on these features after the debrief of our first test and iteration.

CAD Design:

In the development of our 1st iteration of our vehicle, we used CAD minimally, as we did not find a need for 3D printing or complex features. However, we did use it to visualize the base of our vehicle.

Here is an image of our base in Onshape:

As mentioned previously, this rectangular base would serve as a suitable base for our first test, as we learned to acquaint ourselves with the movement of our vehicle. 

Physical prototype:

1. Base

For the rectangular base of this first prototype, we used a sheet of foam board about 16 x 18 cm. We believed that foam board would be a sturdy, yet lightweight material for our first test, and that these dimensions would be an optimal balance to secure our centre of gravity. 

2. Wheels

In terms of the specific wheels that we chose, we reasoned that standard Arduino wheels would be optimal for our base due to their appropriate size and deeply engraved tire patterns. 

3. Electronics

For the electronics portion of our first prototype, we used a simple Arduino Uno and a breadboard to distribute power to all motors. Our circuit also included 4 AA batteries placed in a battery holder and connected to the Arduino Uno, effectively powering the vehicle. Finally, we wired the motors to the power source, by connecting 2 male-male wires from the 5V and the GND of the Arduino to the VCC power rail and the GND power rail.

Here is an online image of our circuit:

The purpose of our first physical prototype was to test how effective its mobility system would be against both flat surfaces and mountainous terrain. At this stage, we prioritized whether or not it could overcome such terrain with the current wheel based system, rather than testing specific features that would assist it in this. Energy efficiency testing would come during our second phase.

Specifically, we decided to test the vehicle’s ability to traverse and combat various conditions and terrain. 

1. Flat/smooth surface

Before testing any unique sorts of terrain, we decided to establish the traditional plywood base as a constant used to measure relative performance. We tested the vehicle’s performance travelling 2 metres in a straight line, and this proved to be an overall success. However, the back left wheel was positioned too high on the side of the base, therefore it was unable to turn effectively, causing a reduced efficiency in the vehicle. This significantly impacted its ability to travel in a straight line, hindering its sense of direction. Finally, we had to hold the battery pack and walk as the vehicle moved, which was problematic, as we had no way of turning the vehicle on and off from a distance.

2. Paper balls

A similar yet even more challenging test can be discussed for our vehicle when analyzing its performance against paper balls. While we faced similar challenges to our first test in terms of the various elements such as electronics, this obstacle brought to the surface a new fundamental problem. This problem was the fact that our vehicle had no suspension system or way to climb uneven terrain or overcome obstacles. To combat this, we learned that we would need to implement a strategic suspension system that would allow the vehicle to climb mountainous terrain. 

3. Rocky Terrain + Sand

For this aspect of our project, our vehicle could not climb over the rocks or the slope of the sand. This was our final reminder that we absolutely needed to prioritize a suspension system. Finally, to facilitate this test, we used foam rocks and kinetic sand.

Here are some videos of our first test:

For the second iteration of our vehicle design, we decided to hone in on a way to climb slopes and mountainous terrain. At the same time, we also had to ensure energy efficiency.

Design alterations:

1. Spring suspension system

As previously mentioned, it was evident that we needed a way to climb mountainous terrain, because our previous design was too low profile and delicate. Through utilizing a spring suspension system, we aimed to tackle these problems, and maximize energy efficiency during climbing phases.

2. Underside ramp

In addition to a suspension system, we also needed a feature that would allow the vehicle to have a large amount of momentum during its uphill ascent of a slope. This where a ramp on the underside was implemented.

3. Wooden base

After witnessing how the first prototype’s delicacy hindered its ability to overcome various obstacles and terrain, we decided to create a new, wooden base. This base was installed to stabilize the vehicle and allow it to climb with more security. 

Final CAD Design:

For our second test day, our vehicle unfortunately did not function at all; it simply did not move across our intended terrain. For context, our testing environment for this test was in large part similar to our first test, however the only change was that instead of foam rocks, we used gravel. This was a direct result of our electronics components and structural designs.

Firstly, the copper wires that we used were thin and flexible, making them unable to reach the holes on the breadboard. As a result, the wires did not receive current from the breadboard, causing the test to fail.

Secondly, the spring suspension was not securely attached to the base and motors. This was extremely problematic due to the fact that the vehicle became fragile and easily prone to structural damage.

Thirdly, the wheels of the vehicle were far too wide, and the corresponding wooden dowels used as the axes were also too long. Although this happened to be a mistake in our measurements, it was still a major flaw in our design due to the fact that it made the vehicle fragile.

Subsequently, a failure in our vehicles movement ability led us to an energy efficiency of 0%. Due to the fact that the voltage being supplied was not turned into useful energy, it led us to realize that we would not be able to measure other values and calculate efficiency. However, to gain a better understanding of how our vehicle would fare with a functioning electronic system, we used the measured values of another group’s vehicle to perform calculations. 

Here is an image of the calculations performed by hand:

The final efficiency we found for this comparative test was about 0.02234 %, which is an accurate representation of what our energy efficiency would have been, based on our structural flaws.

While it was simple to calculate this energy efficiency, we did formulate an original plan to measure it for our own vehicle. This plan included, using the formula for energy efficiency through values such as input and output energy. Our input energy would have been found using the formula in which the average voltage, average current, and time are multiplied.

Meanwhile, our output energy would have been found using the formula for kinetic energy, as it represents the useful energy that was used by the vehicle. Other than this comparative calculation, there was nothing else that we could have measured when calculating energy efficiency. The same can be said for creating graphs and other visual representations of data.

After undergoing the design process, I have drawn the conclusion that for a project such as this past vehicle project, it is wisest to begin and solely focus on the vehicle’s mobility and structure. In the beginning of this project, we spent some time considering fuel and power, however those considerations did not prove to be useful for our tests, due to our usage of standard electronics.

Moreover, this project reminded me of the importance of self advocacy and establishing firm boundaries within team projects. Our group did not successfully work together to achieve one goal, and had it shown cooperation from all members, our final result would have been different. Finally, the largest takeaway from this project for me was the importance of a flexible, yet rigid wheel base.

After watching other groups’ tests, I learned that many of them used wheel bases that could adjust according to the vehicle’s movements. For example, the Trappist 1 group’s usage of a “rocker bogey” system taught me the importance of flexibility, as it allowed their vehicle to persist amid all conditions. 

The implications for this vehicle on the surface of Teegarden’s star b would not lead to success. This is due to the vehicle’s lack of a secure suspension system, and flexibility in the wheel base, causing it to struggle significantly when climbing mountainous terrain. 

Ultimately, I learned about several unique elements of design, the application of physics, and other skills such as team cohesiveness throughout this project. It was a truly unique experience that I will forever learn from. 

Artificial Intelligence was used to guide me through my relatively novice CAD skills in Onshape.

Here is a transcript of my usage:

*Runaway greenhouse effect: a process where a planet’s temperature rises uncontrollably because its atmosphere traps too much heat, causing an endless cycle of warming that evaporates the oceans

Cornell University’s department of Earth and Planetary Astrophysics employed simulations of three dimensional climate models for Teegarden’s star b and both showed a different result. While one simulation showed that, with its most recently estimated instellation of 1481 Wm^-2, Teegarden’s Star b remains below the runaway greenhouse threshold (for both ocean-dominated and land-dominated surface albedos), the other estimated an instellation of 1565 Wm^-2, surpassing the threshold.

For context, instellation is a term that describes the amount of heat a planet receives from its star. The uncertainty around this effect is most definitely a challenge because if it is indeed present and uncontrollable, humans would not have access to liquid water (lost in evaporation).

Firstly, we must understand that Teegarden’s Star b is a red dwarf, which may either be inactive and stable or extremely violent and active. According to Cornell University’s department of Earth and Planetary Astrophysics, two large flares were detected by TESS (Transiting Exoplanet Survey Satellite) observations.

The estimated flare fluence (10^29 and 10^32) was comparable to the largest solar flares, which is a grave concern due to radiation towards human inhabitants, the destruction of the atmosphere, and the damage to human electronics/technology. While these flares and others were detected, this exoplanet does not flare as explosively in comparison to other exoplanets such as Proxima Centauri. Understanding this, the atmosphere is less likely to be destroyed which shows promise towards habitability.

Scientists report that Teegarden’s Star b has a mere 3% chance of retaining an atmosphere, which is a significant challenge for human life. Without an atmosphere, we would have to find a new source of oxygen to breathe, shield ourselves from harmful solar radiation and meteoroids, and find a way to maintain a habitable temperature by trapping heat. Despite a 60% chance of liquid water being present, it may not be possible to harness it without an atmosphere.

Since Teegarden’s star b is a red dwarf, it is most likely tidally locked (its rotation period equals its orbital period, causing it to always show the same face to the object it orbits). This may present a challenge since only half of the planet will face its star, while the other will face darkness. If this were to happen, we would need to establish different living methods to combat each side’s conditions.

To combat this exoplanets potential runaway greenhouse effect or increased heat (compared to Earth), our vehicle design must include heat resistant shielding through specialized materials (refractory metals like tungsten, tantalum, molybdenum, silicon carbide, and specialized alloys like Inconel and stainless steel) and strong cooling systems.

Some implications for our vehicle facing radioactive flares may be materials that protect against radiation (lead, tungsten, bismuth, tin, antimony, etc) and specialized garages or bases for it to protect itself during flaring. Furthermore, hardware and electronics must be able to withstand radiation, so that they do not fry or cause damage to the vehicle. 

To combat the dual temperatures created by tidal locking, our vehicle must use different forms of energy (not solely dependent on solar energy), carry warming systems for batteries in cold environments, and potentially have two different modes for different environments. Having different modes or attachments for the two sides of the planet could allow the vehicle to traverse both sides with efficiency. 

Since Teegarden’s Star b has a rocky, earthlike terrain, the vehicle would need to find ways to travel either over or on it safely. This could mean, having a hovering function to travel over these areas, or making adjustments to tires/wheels to swiftly make contact with the terrain.

If there is an atmosphere present, a vehicle would need filters to provide oxygen to humans inside, potentially an ability to hover over rocky terrain, and a method to use oxygen and water for combustion. These implications could make a vehicle similar to one on Earth in some areas, which would save resources, and allow us to apply our current knowledge rather than conducting significant new research.

However, if there is not an atmosphere, a vehicle would need to be able to handle the vacuum of space (low pressure and density of matter), account for a change in gravity, and require humans to wear space suits at all times. Due to this uncertainty, it would take several attempts and learning to perfect a vehicle that confirms uncertainties and is able to combat challenges.

Of course, before beginning the construction of the virtual prototype, I had to determine exactly which various parts would be needed. Firstly, an Arduino Uno R3 would be needed to facilitate the project. Secondly, a breadboard was needed because while I first wondered why we could not just connect wires from component to component directly, I learned that a breadboard would avoid the need to solder wires physically. Thirdly, a micro servo was needed to rotate the gate. Fourthly, a push button was needed for the user to engage with the circuit. Fifthly, a resistor was needed to prevent the over supplement of energy to the button. Finally, jumper wires were needed to connect all of the components to the breadboard. 

As for the circuit itself, it uses components such as specific wired connections through the breadboard to function efficiently. Firstly, the servo’s ground wire (brown) is connected to the breadboard’s – rail, which is also connected to the GND pin on the Arduino board. This allows ground to be delivered from the Arduino to the servo and vice versa. The servo’s red wire connects to the + rail which is also connected to the Arduino’s 5v pin. This allows voltage to be supplied from the Arduino to the servo. The servo’s signal wire (yellow) is connected to row 2, which is connected to pin 9 through the breadboard. This allows the servo to perform functions through the Arduino’s pin 9. 

The arduino’s pin 2 is connected to row 10 on the breadboard which is the same row that the push buttons terminals 2b and 1a are connected to. This again, allows the Arduino to read on and off signals based on the button’s press. The ground pin on the Arduino connects to row 8 on the breadboard to allow other components such as the resistor and the button’s other two legs to read “low” (when the button is not pressed), so that the circuit can return to ground. 

Finally, the resistor is connected to the ground rail on the breadboard and row 3 to prevent an overload of power flowing through the circuit. 

For the coding portion of this project, I asked Chat GPT to first write it out, then explain it to me, and then guide me through writing it out myself. This portion may have been the most challenging for me, as I had to learn a whole new language. However, throughout the process of learning this language, I related it back to my understanding of Python commands, which helped me understand similar concepts in different words.

Line 3 tells the Arduino to load the servo library, so that it can understand future commands such as “myServo.attatch(9);”.

Line 5 is like defining a variable in python. It gives a name to the servo motor, so that Arduino knows that there will be a servo involved and what it is called.

Line 7 starts the setup function which occurs when the Arduino is turned on or resets. The curly bracket stores the setup commands to come.

Line 8 attaches the servo to pin 9, telling it which pin to send control signals to.

Line 9 tells Arduino to treat pin 2 as an input pin. This means that through this pin, it will read whether the button is pressed or not, setting up later commands.

Lines 12 through 18 contain a loop that repeats forever containing crucial if else statements that form the base of the code. It says that if the button is pressed (reads LOW), the servo will rotate 90 degrees, and if not, it will return to the same position (0 degrees).

Here is a video of the functioning prototype!

I was not able to document my attempt at a physical prototype, however I did learn some things during the process. One thing I learned was that, while you may connect more than 1 wire to a pin in TinkerCad virtually, you cannot do the same physically. This is why I ended up adjusting my virtual model to look more like a physical one. I also got a general feel for physical circuit building, connecting wires, buttons, and other components. While I did not end up creating a functional physical prototype, I did give it an attempt, and learn some things along the way which I would not have through my virtual prototype alone. 

The first part of this project was the sketching of the plate. This sketch represents the base of the plate, before I added extra details. The diameter is 17.7 inches (standard), and there is also a smaller circle in the middle (1 inch diameter). Two circles are needed because later on during the extruding phase, I only wanted to extrude the area around the small circle, leaving a hole in the middle. 

The second step in designing this plate was extrusion. This process involved selecting the part that I wanted to be turned 3 dimensional, and making it happen. I selected the larger circle and this is a preview of what it would look like once extruded. I chose the depth of the extrusion to be 2 inches, as this is the standard thickness of weight plates. 

The previous two steps were simply to demonstrate my understanding of sketching and extrusion. However, I repeated this process multiple times to reach my completed weight plate.

For example, the outer ring required a sketch and extrusion of a 17.7 inch diameter circle, with a much larger inner circle (to create a thin outer ring). The dark red innermost circle also required a sketch and extrusion following a similar procedure. These three circles allowed me to practice and get comfortable with this skill, so that I found it easier to demonstrate in other parts of the project.

By layering each circle on top of each other, I learned that when drawing, you can select an already extruded part as the plane. An interesting feature that I learned in my pursuit to add detail to a once simple plate was the ability to add text. Notebook LM aided me in this process, and youtube videos were especially useful in visualizing it. Finally, I learned how to choose the colour of each part (again through Notebook LM), which made the final design look especially polished. 

The first step in creating the barbell was sketching the bar itself. This included using the centre circle tool to draw a circle centred to the origin. The diameter had to be slightly smaller than the hole in the middle of the plates to allow them to slide on. 

The second phase in creating the bar was extruding the sketch. This process was quite straightforward, as it was a solid bar without anything in the middle. The depth of the extrusion had to be 64 inches due to the extra parts that would allow it to be functional. 

The final barbell was created by adding more parts to the initial bar shown previously. Of course, the bar needed stoppers to prevent the weight plates from colliding. In order to include them, I was required to do mathematical calculations regarding the length of the overall barbell.

This involved creating 2 separate 8 inch bars which I added to the original bar and stoppers using the extrude tool. Through this process, I learned that two separate extruded parts could be merged, which helped me with the previous part as well. The completed barbell set the stage for the creation of the final part – the outside stoppers. 

The first step in the creation of the outside stoppers was again sketching. For this phase, I used a heptagon to best represent the strapped stoppers that are usually used in gyms. Each side is 0.7 inches, and the inner circle had to have a diameter of 1 inch to allow the barbell to fit through. Again, the sketching was simple, getting ready for the extrusion phase.

The extrusion phase was similar to the process used for the plates. I had to select the part outside of the inner circle to leave the hole. Other than this, it was again, a simple process. This part was the simplest as it was 1 part, without any additions. 

The assembly part of this process was difficult to understand at first. Elements like mates, and finding a way to add restrictions on them was challenging at first. During this process, I set the barbell as the fixed element, making it easier to slide the rest of the elements on it. I used cylindrical mates to connect the plates and the bars. I learned that these allow the user to spin/rotate them and slide them along the plate.

During this phase, I learned about setting restrictions on the distance that they could slide. Of course these were necessary, as I did not want them to slide past the built in stoppers. I set the restriction to 8 inches for the plates because this was the distance to the stoppers. After completing these cylindrical mates, I created slider mates for the sliders because realistically they should not be able to rotate. I set the restrictions to 7 inches for these mates.

After this, the assembly process was complete, but it took me some time to understand that the Bill of Materials had to be created in this assembly tab. Notebook LM helped me with this, so I was able to create the table listing the various parts used for the project. 

During this final phase of the project, I learned that various angles of the assembled product could show different sets of dimensions. For example, the horizontal view showed the length dimensions of each element, while the vertical view showed the width dimensions. I included the front of the product, to show circular elements in greater detail. As a whole, this was a straightforward process, however, it took me some time to understand it. 

Finally, the Bill of Materials needed to be inserted into the mechanical drawing document. Again, this was straightforward, as I had already created it during the assembly phase. 

The below section of code introduces the user to the program. Lines one to five simply describe what the program does, which was helpful for me to refer back to, as the programmer. *Note that all of the writing in green is not run by the computer, as they are simply comments for the programmer (myself) to refer back to. Line eight allows access to the computer system, which will be useful later in the program.

Lines eleven through thirteen are shown on the console to the user, detailing the program. Line fourteen asks the user to enter their name for personalization, which is stored in a variable called “name”. Line sixteen defines another variable called msg, which contains braces to store the variable name.

Finally, on line seventeen, the message is printed to the console, with the help of .format, a string method that fills the empty braces with the variable “name”. 

This below section defines a crucial function (allows repeated lines of code to be stored as one action) in the code. Lines twenty-one and twenty-two ask for the user’s question and answer which will create a flashcard later on. Line twenty-four may be the most crucial however, as it stores the question and answer to a list called “flashcards”.

It does this by using the .append string method, with the brackets containing the question followed by the answer. Through this method, the question and answer is stored in the list, so that if the user enters multiple questions and answers later on, they will all be printed in order. Finally, line twenty-seven defines the list known as flashcards through square brackets.

The above section of code comes after the function “ask_q_and_a” is called. Line thirty-two is straight forward, asking whether or not the user has any more questions to enter. The “while” loop on line thirty-five states that the program will repeat the process (asking the user for information, and then asking whether or not there is more), until the user finally enters that there are no more questions.

It sets this condition by setting the another_question.lower() method equal to the lowercase letter “y”. The .lower() string method converts a capital letter “Y” to a lowercase letter “y”, so that the program can accept both capital or lowercase letters “y” from the user.

The above section of code ties back to the “import os” call at the very beginning of the program. It uses its access to the computer system to clear the console so the user cannot see the answers to the questions. Without this portion of the program, the user would be able to simply look at and copy the answer that they had entered earlier into the console.

The if else statement is required to account for different computer systems: Mac/Linux or Windows. On Mac/Linux, the call to clear the console is os.system(‘clear’), but on Windows it is os.system(‘cls). After clearing the console, the message on line forty-six is printed to the console. 

The portion of code above is the integral for loop that allows the questions that the user previously entered, to be asked back to the console. Line forty-nine is a loop that continues until every card in the set of flashcards has been asked to the user. Line fifty-one explains that one card includes both the question and the answer (a bundle). Line fifty-three asks the question, and the process continues until there are no more questions.

Without the list called “flashcards” and the .append string method from earlier, the computer would not remember each question and answer to be different. It would simply print that latest question and answer that the user entered, overriding each of the previous pieces of information. This is the most integral aspect of the program. 

The above portion of code includes an if else statement that accounts both for if the user answered correctly or incorrectly. If their answer is correct, the message on line fifty-seven is printed to the console, and if it is incorrect, the correct answer and the message on line sixty-one is printed. The rest of the program is simply a message that sends off the user, and concludes the code.