Category: Uncategorized

*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.