Category: Uncategorized

  • Progress Update #1

    Since my product pitch, my goal with my personal project has shifted somewhat. Through exploring the market and demand for a medicine adherence device, I saw that there were sufficient products available on Amazon through my competitive analysis.

    My updated definition statement is the following:

    People who take daily medication need a way to manage their dosage timing without double-dosing which could cause harmful or fatal overdoses. Current solutions do not address the problem effectively, because people rely on reminders and user memory.


    My new problem that I have decided to tackle is preventing double dosage in medicine. A lot of people forget whether they’ve had their medicine already, and they have already taken. Double dosing can be harmless or life-threatening depending on which medication is used and the condition that is being treated. This affects people over 60, and people with chronic illnesses that require multiple medications.

    I have looked online and found that various health providers have stated that double dosage can be very harmful to some people. The effect differs person to person based on the medication they are taking and their health condition. According to Poison Control, (https://www.poison.org/articles/medication-errors-double-dosing), double dosage can be very serious for people that take heart medications, ADHD medications, medications that treat diabetes and psychiatric conditions. From the Mayo Clinic, we can see that in America “nearly 70% of people take at least one prescription medication and more than half take two,”. This shows that the problem exists and although the data set is of America, it would likely scale to other countries as well, making the market and audience very large. This product would help a lot of people.

    My solution is to build a dispenser that locks after giving the prescribed amount of medication. They would release at a certain time when they are meant to have it and stay there until they do. Weight sensors would detect and sense when the pills are actually taken out of the dispenser. I will test it by making sure that the medications and the right amounts are dispensed. To make it more realistic, I’ll test it with various medications at different times and see how my product addresses the problem. I’ll also get reviews from other people and ask targeted questions.


    So far, I have changed my problem being targeted and adjusted my focus. I combed through Amazon reviews and products through my research and found that the space already had various products, and even if the solutions could be better, there were most definitely companies already working on it and the market is competitive already.

    I think that I will face challenges in getting all of the technology to work together and to make sure that only one pill or the required amount is being dispensed. I’ll use a servo to open and close the column that drops the medication quickly, and only let a certain amount through. I will also look into how I can lock the medication flap, and keep the flap open, so they can take the medication.

    From now, I plan to create a list of materials or what I need, and look into how I can fabricate the design. I will also get started on the technical aspect of this, such as the coding for the Arduino or other technology I may use. Then I will prototype and build in iterations. With iterations, I’ll use tests to identify gaps in the product functionality and refine the product further.

  • Personal Project Pitch

    My aim for the project is to create an adjustable box that helps elderly patients adhere to their prescribed medicine routine using colour coding and alarms. Along with this, the product will provide users with progress tracking to measure how often their having their medications.

    Why create this, and what problem does it solve?

    Approximately 50% of “older adults” struggle with medication adherence (source: https://www.sciencedirect.com/science/article/pii/S2949761223000913#:~:text=About%2050%25%20of%20older%20adults,and%20morbidity%20and%20mortality%20rates.) This research also shows that elderly patients find apps and reminders too distracting. Younger adults may find it easier to integrate with technology, but the main people that struggle with adherence are the elderly. To help them I would like to create a product that is more affordable than existing medication reminder boxes, and simpler (colour coded medication sections).

    Definition pitch:

    Elderly patients don’t take their prescribed medicine. There are lots of problems that this causes, especially if they’re necessary prescription medication, not optional supplements. To address this problem, I would like to create a simple product that reminds people to take their medication and track their progress in medicine adherence.

    Ideate by thinking of various solutions to the problem – goal of 10 ideas:

    1. An app to remind (already exists)
    2. Medication Box that tracks progress automatically and requires minimal input by user
    3. Vibrating pouch for medication at time of taking it
    4. Medication pouch that attaches to back of phone (magsafe, or velcro)
    5. App that works in sync with medication box to provide reminders if you’re away
    6. Belt strap that has medication tiny box or pouch
    7. Wrist accessory (small pouch hanging from keychain – with good ventilation and medication storage conditions)

    I already eliminated 1. because it wouldn’t be effective or user friendly for elderly patients. Number 3 and 4, is good, but may not be able to store various types of medication – and elderly patients frequently are being treated for various conditions. 3,4,6 and 7 may not have the best medication storage conditions and would require a lot of research. The main issue with the ones that you carry around are that they could get lost very easily – especially with the elderly that have memory problems. I may do 5 if I have more time after creation.

    Plan

    1. I will research how to create the physical prototype and whether my idea of sliding compartments that expand and contract is feasible or not.
    2. Furthermore, I will do research what materials are best for medication storage and are safe to store them in. I need to use the right materials
    3. Set goals on what needs the prototype needs to have strictly (necessary and optional)
    4. Technical design plan. This will include the buzzers, possible angle sensors to detect when the box is opened to see when medication is taken, etc.
    5. Prototyping – creating the build and working on it
    6. Testing and improvements to refine prototype and ensure MVP and goals have been met. The testing will include feedback on the product (does it help, where can it do better, what does it do) and testing basic functionality. Some part of the testing will include data collection from the percentage of the users on how much improvement they made on medication adherence.
    7. Reflection on scaling the vehicle and real world application of it (possible distribution)

    All of this will be done and wrapped up completely by May 1st.

  • PEP Vehicle design

    Image created by AI

    Intro / Abstract:

    • My group (Michael, Dean and I), had a goal of designing a vehicle that would transport 4 astronauts on a potentially habitable planet or moon. Callisto is a moon, and we chose it as the most habitable because of its unique characteristic: a subsurface ocean. This indicates potential for life, likely marine life in that ocean, or at least potential for future development. Also, it is safe from radiation – something we take as granted, but the truth is that the majority of planets and moons are affected by radiation levels so great that they make human life impossible. Callisto is the third largest moon in the Solar System and therefore has potential space to accommodate humans.

      After considering what is realistically possible to achieve in terms of progress on a vehicle, we came up with the following definition statement:
      • The vehicle should be capable of operating independently on a remote, frozen, and airless moon with extreme cold, low gravity, and weak sunlight. It needs to generate power on its own without relying on solar energy, thermal protection is essential to keep engines, batteries, and fuel operational in extreme cold, and travel through rocky, ice covered terrain. Moreover, the vehicle needs to use fuel efficiently, and to accomplish this, it needs to be not too heavy, with a low center of gravity and good mobility.

    Our vision of the product (what we plan to build): We planned to build a vehicle with two or 4 tank treads acting like wheels on the side of our rover vehicle. These would have traction to help it climb over those rocky and icy terrains on Callisto. We aimed to give directions to the vehicle through Arduino code and robotics, and power it with batteries strapped to the vehicle itself. This, along with the tank treads would create an efficient, minimalistic design that generates a lot of power and traction to successfully achieve our design goal. Our primary aim through this is for the vehicle to be able to be versatile and drive through various weather and land conditions. Adaptability and versatility are key, when we are dealing with unknowns – especially unknowns as huge as foreign celestial bodies.

    How we plan to build it: The approach we decided on to achieve this was to build our planned Onshape design through 3D printing the CAD design. 3D designing the parts of the vehicle would be a lengthy process, but we were confident the outcome would be worth it. I worked on the Arduino to program the vehicle and add the robotics component to it. As a group, we all worked planning the CAD designs, and Michael designed the actual components. Dean would later assemble the parts for the tank tread, while Michael and I would do more robotics oriented building (motors, soldering, etc).

    • The planning we did for this project and vehicle included the research phase where we learnt about celestial bodies we could design a vehicle for then shortlisted them. The type of planet or moon we were assigned greatly influenced what our goals would be for the vehicle, and what type of vehicle it would be. For example, some groups chose the path of underwater submarine type vehicles because their planet was largely water. Our place of choice was one of Jupiter’s moons: Callisto. Its characteristics greatly influenced our design because of its rocky terrain and surface with lots of craters. This made a primary requirement of our vehicle vertical ascension and climbing upwards. When we planned our test, this is what we wanted to evaluate in our vehicle. If it could get over an obstacle of some sort, we would be able to measure the progress and success of the vehicle. Throughout the later stages of the project, we learnt that the efficiency metrics of the vehicle were also important. They tell us how much of the energy that is used to power the vehicle is actually converted into useful energy. Factors such as weight can influence this as well. The idea behind measuring efficiency allows us to make sure we are intentional with every component, and that teaches us that if we pursue engineering, environmental concerns and effectiveness are an important part of vehicle design as well. 

    Method / Procedure:

    • Throughout the building and planning process, I kept track of our progress through logging daily progress as we got closer to test day, documented our planning and took photos and recordings of developments in prototyping, Arduino wiring, etc.

      We started the project with research on potentially livable celestial bodies, and gathered information. At the end, we were assigned one of our shortlisted moons, Callisto. Callisto is one of Jupiter’s moons, and the third largest in the solar system. It has multiple characteristics that make it a good choice for livability, and multiple challenges as well. The most promising feature is the fact that there is data that suggests there is a subsurface ocean. The aforementioned size of this moon means that it has the capability to accommodate a large portion of the human population. Challenges of habitability on Callisto include freezing temperatures and 10 times more radiation than Earth. Its radiation is still relatively low compared to the other moons of Jupiter, and this is because it is far from Jupiter. More information on Callisto can be found at this link of my other blog https://wp.stgeorges.bc.ca/shayanc/2025/11/16/planetary-exploration-project/

      Our design was heavily influenced by Callisto’s rocky and icy terrain. We recognised the value of traction and climbing over obstacles in this terrain, so we prioritised those in a vehicle that we wanted to build. Then the brainstorming stage came, where we came up with ideas and created a definition statement:

      “The vehicle should be capable of operating on a frozen and airless moon with extreme cold, low gravity, and weak sunlight. It will need to protect its internal components from the temperature to an extent, and generate power on its own without relying on solar energy. Thermal protection is essential to keep engines, batteries, and fuel operational in extreme cold, and travel through rocky, ice covered terrain. Moreover, the vehicle needs to use fuel efficiently, and to accomplish this,  it needs to be but not too heavy, with a low center of gravity and good mobility.”

      Also, we knew that there were a lot of things that we would not be able to address in a small vehicle that high school students were capable of creating, so we decided to address the things that we could. We shortlisted the issues we can try to combat, and the main thing we concluded on was: driving through rough terrain with good grip and traction. It needed to be a goal that we could test, and we could test this.

      For brainstorming our exact vehicle design to reach this goal, we did something unique. By coming up with the worst ideas, we figured out what to avoid, and accidentally stumbled onto good ideas through creative thinking.
    •  There are many components and stages we used and went through when prototyping this vehicle. At first, we planned on using an Arduino to control the vehicle, but later discontinued that idea after realising that it was a little bit overkill and we just needed it to go straight. We soldered DC motors, and stayed with our idea of using tank treads to build traction, and 3D designed components. The tank tread looks like this:

    Our group decided to use paperclips to attach each of these treads together through the two cylindrical holes. We later found after the first testing day that the paper clips that attached the tank treads got caught in the exterior of the vehicle. The following photo is one we took in the initial prototyping stage. It is only one half of the rover and doesn’t include the chassis or the other duplicate of this (built slightly later).

    Each tank tread rover has one DC motor powering it, and here is what it looks like in action independently:

    https://drive.google.com/file/d/19VbafLCue4fUbuSDJNwZSzcmSvVea2C_/view?usp=sharing


    Michael has the CAD designs for the rotating gear we can see in the image and the other parts of the vehicle. Here is what the vehicle looks like in a slightly more progressed stage:

    To explain what developments we had between these two images, I will go through the process component by component. We simply created another one of the tank tread rovers and added a 3D printed cover for the internals and gears. This serves an important function for the safety of the internals on Callisto. Also, in the first image if you look carefully you’ll notice that the treads are a bit loose. We fixed that by removing one singular tread to make it fit tightly. Another main component is the chassis. On our first test day, we quickly attached it with screws into the previously laser-cut holes. We also used screws to attach the 3D printed plastic on the side of the rover (the one that covers the internals). Inside each of the rovers are a DC motor, and soldered wires. We used a breadboard to distribute battery power to both motors. This is the main design, and after this we mainly made tweaks to optimize directional movement, weight distribution and centre of gravity.

    After our first test, we fixed the paper clips issue (kept getting caught when rotating) by replacing them with small metal rods which we sawed. This was  a simple and easy fix, but the challenging part was getting the measurements right, and the time-consuming exercise of cutting metal rods. The image above actually shows the version of our vehicle where we replaced the paper clips that were binding the treads together with metal rods. In class we also briefly experimented with the idea of placing the battery and the whole setup on the bottom of the vehicle to lower the centre of gravity. We dismissed the idea eventually because it would create lots of contact with the ground – possibly harming our components, creating friction and dents, and reducing speed. None of which we desire.

    Later on in our prototyping and post-test stage (after the first test), we were aware of an issue. Our vehicle was moving slightly to one side when operating. We tried a variety of things such as screwing on our screws again to tighten them, and changing the order and placement of our components on the chassis. Ultimately, we concluded it was a weight distribution problem, and added various counterweights to balance the vehicle. The day before our final test, we went out and tested it – and it worked. Our vehicle climbed upwards, moved through rocky/dusty paths that resembled our testing plan. We were going to test if our vehicle could do these things the next day and if it could, it would indicate that it is Callisto-ready in the aspect we were hoping for.

    Here is a link to a video showing our vehicle drifting to one side:
    https://drive.google.com/file/d/1wuQP8vFziqLjFUxXm44jP1bzDjIydTKm/view?usp=drivesdk

    The following link shows the video where our vehicle moves in a straight line over a gravel road, a non flat surface, the day before our final test:
    https://drive.google.com/file/d/1fFlg4BAhU8V9A5GuMU7MoV80yBsHB-DC/view?usp=drivesdk


    On our final test day, we didn’t have everything go to plan. Our vehicle was being tested on a separate surface, but one that still represented Callisto accurately. We were testing it on sand and rocks – it was not easy for a vehicle to get traction, and our vehicle, which was weighted one one side, took a sharp turn to that side and went out of the tracks. The video is linked below for reference. One likely reason the vehicle veered out of direction is because the distribution of rocks could have been clustered in one spot, pushing our vehicle in the opposite direction. Here is the video link:
    https://drive.google.com/file/d/1svGZp6kUUKKNfIEGIZUK5MpZ8OPa3C3Z/view?usp=drivesdk

    We learnt from this process that repeated prototyping and improvements allows for improvement, and there is always a way to further strengthen a design. Vehicle design is a rewarding process and there’s a lot of learning that comes with it.

    Testing / Data:

    • We had two official tests of our vehicle, and I’ll go through them and what we learnt and how developed from each of them. On the first test day, we were a little rushed to get our chassis attached to our rovers through screws, and used a simple wooden plank with laser cuts. In terms of our performance, our vehicle didn’t perform as well as we would have expected in terms of it getting caught on the ramp sometimes, and the paperclip design interfering with the spinning of the treads.


      On the official test day, we had a test set up with rocks and sand laid out. Our vehicle moves straight at first, but turns left really fast, and heads into the wall. This repeated multiple times, and we concluded it was likely that the rocks indicated the rocks were positioned to guide the vehicles left.

      One way we could have possibly combated this, was to create separate suspension tools such as springs for each side of the vehicle. This worked for another group that 3D printed some of their parts and used lego for others. Our chassis was a wooden board that we laser cut the holes into, so I feel that if we spent more time working on the suspension, it may have been more stable. When the vehicle moved, if one part got guided to the left, it would force the whole vehicle that way. This is not a problem that we anticipated, but it is a valuable real world lesson that we learnt. Our vehicle operated well on flat surfaces, but wasn’t able to go in a straight direction when confronted with adverse terrains.
    • I have the speeds of our vehicle, across a certain timeframe with distance accounted for, using a Video analysis tool. However, I would like to mention that the data is not completely accurate because it started turning to the left, and didn’t make much horizontal movement, so it looks like the vehicle didn’t move very fast. It was just moving towards a different direction which could not be accounted for in the video analysis.

      Here is the graph that tracks the vehicles horizontal movement in m/s from our video and the corresponding data table:
    • Here are the calculations for efficiency. First, we need to recognise that the calculations are not accurate because the vehicle turned to the left and this analysis app registers velocity in terms of horizontal movement. Therefore, if a vehicle turned to one side and continued at the same speed that way, it wouldn’t have been recorded accurately. The peak speed of the vehicle could be accurate, but the slower increase after that isn’t right. Either the rocks slowed him down or the vehicle’s turning meant that it was recorded as less movement horizontally than was actually occurring.

    Analysis:



    • This is the formula to find efficiency. To find the useful total energy output, we need to find the kinetic energy of the vehicle, and the energy input by a formula.

      I’m defining the energy output as the kinetic energy of the vehicle. The energy input is the electrical energy the battery provides which we estimated using the specifications on the battery. To be clear, I used Vernier Video analysis to find the velocity of the vehicle, and the motion speed was recorded in the presence of friction since it was driven on the ground. The calculated efficiency represents an estimate of how much of the battery energy was converted into kinetic energy, because some energy that the battery produced was lost to its surroundings through friction.

      The kinetic energy of the vehicle can be found through the formula:


      We estimate the mass of our vehicle to be around (1.183 kg), and through google sheets, I found the mean velocity of the vehicle using the data from the data table above. To be clear, I included every row in the calculations. Here is the mean velocity:



      So now our equation for the Kinetic Energy is:

      The energy input which we defined as the electrical energy supplied by the battery can be calculated by the formula listed in the calculations below. V is for the Voltage, I is the current in amperes, and the t is time measured in seconds.



      Therefore, the efficiency of our vehicle is:


      From these calculations, we know our vehicle efficiency was around 7.92%. I used the accurate decimal value for the calculations to prevent rounding errors from accumulating, but still preserved the estimates for coherence.
    • I used the following links to format my formulas: https://latex.codecogs.com/editor.html
      https://latexeditor.lagrida.com/
      https://editor.codecogs.com/

    Conclusion / Evaluation:

    From this design process, we learned that repeated prototyping and testing are essential to improving performance, because each iteration revealed new weaknesses and opportunities for refinement. There were always new things to add, whether it be replacing certain components, soldering wires, or adding a counter-weight. Testing reveals flaws that we don’t see coming otherwise. That’s why it’s such an important step in design.

    It’s also really good to use data to help you figure out where you can improve. I was surprised to find out our vehicle only had almost an 8% efficiency rate, even though the design looks great and moves fast.

    When the vehicle is used in real life, its performance may change due to factors like surface friction, uneven ground, and energy losses that were not fully present during testing. However, because the vehicle was tested and improved multiple times, it should still perform consistently. This project showed that vehicle design involves a lot of learning and improvement, and that good designs come from making changes based on testing results.

    How the prototype affects the final scaled model:

    The vehicle with an 8% efficiency actually wouldn’t have a great shot at making the round trip as it is. Realistically, it would be hammered with various types of radiation (some from outer space) and that would affect the vehicle’s physical ability and condition to perform even more. With the current performance, we’d need a lot more electrical energy/fuel than the vehicle would actually end up using. This problem would be further exacerbated if we replaced the battery with fuel, it would freeze on the planet.

    One reason the efficiency was low, was low traction and difficulty to move. If we added a rubbery elastic tread covering to go around the tread , I think that would solve the efficiency problem.

    The current battery produces a lot of power already, so if more of it is converted, our prototype would have functioned better. Also, we would have a scaled up version of the prototype on Callisto. One that could accommodate 4 astronauts. For this, we would need to scale the vehicle’s usable power to that similar to a sedan. It would require slightly less energy because it would have a simplistic design and therefore a lower mass. The current output of power of our vehicle is 5.55 W. This is partly in cause to the 8% efficiency rate, and also the power coming from a battery. We would increase the power to 100 kW on the scaled model for Callisto. The power source would still be battery, but ones similar to those in current electric vehicles. It would need to be adjusted in certain aspects to be weather and radiation proofed, but it makes sense to keep a similar power source as we scale up.

    With this more efficient model (from the traction coating) and the scaled up power source, we predict that a working full size prototype would hold a charge of around 1,250 kWh. This is way more than it should be, but this is how much energy our vehicle would need to store in order to scale up if the efficiency remains at 8%. It is important to recognize that the other 92% of the energy is going to the surroundings, but not only as heat. It is also converting to sound, vibrational energy as the treads are on the rocks, and some energy is further lost as the vehicle tries to struggle and move on rocky terrains (in the prototype test).

    AI acknowledgement

    Our group used AI to create the image at the top of this blog post during our brainstorming phase. None of the work in this post is the result of AI use. I used AI to assist with the robotics component, but the transcript is not attached since we decided not to include any robotics.

  • Planetary exploration project

    Our chosen celestial body: Callisto (one of Jupiter’s moons)

    Callisto: Jupiter’s Ancient Icy Moon

    Introduction:

    Earth is becoming less habitable as global warming, pollution and sea levels rise, prompting the search for humans to find an alternate home to start with a fresh slate. This does not come easily though, because Earth is the only planet we know about so far that is completely habitable without any necessary adaptations for basic living. However, our project across Fusion and Science gives the opportunity to explore exoplanets, moons and other celestial bodies which humans can terraform and adapt to improve livability. My group and I chose Callisto, one of Jupiter’s moons. It has some crucial livable qualities like a possible subsurface ocean, and traces of oxygen in its thin atmosphere called an “exosphere”. 

    • Why did you choose your planet and why?
      • My group chose Callisto because it has exciting potential, especially in terms of the presence of necessary environmental conditions for us. Although it is really cold, the presence of oxygen, ice and possibly a subsurface ocean is exciting. Callisto is a third of approximately the size of Mercury, and has low radiation levels. There’s no planet out there that’s naturally good for humans to live on besides Earth, so we’d have to build systems to help us survive anywhere else. Out of the options, Callisto seems like a solid choice because it already gives us a few important advantages.
    • What opportunities present themselves on your new home planet?
      • There is a chance to terraform the moon and build appropriate adaptations for humans to make it suitable for living. There is no perfect planet for life other than earth, so we chose a planet which would take care of some major things for us, and leave humans less technologies to develop. Positive livability characteristics we notice of Callisto are that its radiation is not extremely high to the point where we can’t combat it with innovative solutions, and it is believed to have a subsurface ocean or at least significant ice content, which suggests water resources may be accessible
    • What challenges do you foresee?
      • Extreme cold
        • The average temperature on Callisto is around -139℃, and the reason for its inhospitable temperatures can be attributed to its distance from the Sun. This is a challenge because humans can’t live in this weather without significant protection and insulation. To put into perspective how cold that really is; the coldest temperature humans have ever experienced is -89℃. Without developing appropriate solutions, it would be unwise to go to Callisto ourselves until we develop gear good enough to keep us safe.
      • Low gravity
        • Having low gravity would have long term negative effects on the human body without appropriate practical technology for our daily lives. Currently, Callisto’s gravity is approximately one-eighth of Earth’s, meaning that everything and everyone wouldn’t weigh down on the moon as much as we do on Earth. Living on a moon with low gravity has consequences for the human body over long periods, such as one’s muscles and bones weakening. Currently, NASA astronauts exercise while in space to keep their mass constant and not weaken their bones or muscles. 
      • Radiation (GCR + SEP)
        • Callisto is one of the safest moons in Jupiter’s orbit in terms of radiation because of its distance from the magnetic radiation emitted by Jupiter. Although it is comparatively safe compared to other moons closer to Jupiter like Europa, this amount is still 10 times more radiation than humans receive on Earth. That level of radiation leads to a higher risk of cancer,  This means we will still need to develop a solution for this, although it won’t be one of the biggest things to tackle. However, Jupiter is not the only celestial body giving off radiation throughout the galaxy. Galactic Cosmic Rays are high-energy particles that can damage DNA over time, increasing the risk of developing cancer. Another dangerous type of particle is Solar Energetic Particles (SEPs). They are bursts of particles from the Sun delivered during solar storms. Callisto’s thin exosphere means there is not as much protection from SEP’s and GCR’s.
      • Thin atmosphere with low oxygen
        • Oxygen supply is essential for humans, and while we have it in abundance on Earth, Callisto has a much more limited supply, all of it in its thin atmosphere. Although this is a good starting point, living there or moving permanently without a consistent oxygen source is not feasible. For now, this means we could only send probes, rovers, and other vehicles to explore the surface and would need to wait on sending people until a solution for our oxygen supply is developed.
    • What implications might there be for vehicle design?
      • Extreme cold
        • Callisto is extremely cold, which means we will have to be creative and aware when designing a vehicle for its environment. External components are likely to freeze, so important electronics should be inside the vehicle and insulated for warmth. We could also place small heaters inside our device to keep all the components working well. Also, we will need to choose materials that don’t crack or break easily in low temperatures. 
      • Low gravity
        • This would mean vehicles would have less friction, traction, and stability. When designing, we would need to address all of these issues. For example, we could add extra weight to keep the vehicle grounded, use wide bases for balance, design good suspension systems, distribute weight evenly on each side, and equip strong tires to improve grip.
      • Radiation (GCR + SEP)
        • We will need to shield our living spaces, vehicles and ourselves from all types of radiation while on Callisto. However primarily we will need to focus on GCR and SEP. These are the two other types of radiation that come from bodies other than Jupiter, and will require a stronger design to shield it from these when on Callisto.
      • Thin atmosphere with low oxygen
        • There are no major vehicle design issues caused by the lack of oxygen, since technology doesn’t need oxygen to survive like humans do. However, the thin atmosphere creates other challenges that vehicles need to be protected against. Radiation from space can damage electronics, so vehicles should be built to resist it and have sensitive components protected beneath the surface. The atmosphere also does not block dust, small particles, or meteoroids, so vehicles need shielding from high-speed impacts. On Earth, our atmosphere burns up most objects entering orbit, but on Callisto we would need to consider all types of design constraints from the ground up.
    • How do we know what we know about your planet?  Be specific.  What research was done?  What devices were used?  How did those devices collect what data, and what conclusions can be drawn from them?  What report speaks specifically to this information?
      • Introduction:
        • Galileo was one of the first and major scientific explorations of Jupiter’s moons, and it provided lots of information about Callisto. It identified that there is a chance there is a subsurface ocean on the moon, observed the radiation levels, gravity strength, and some more atmosphere information. 
      • Subsurface Ocean

    NASA’s Galileo mission is the source of the majority of our understanding of Callisto. Callisto was observed through multiple flybys in the late 1990s. One of the most important discoveries is that Callisto likely has a subsurface saltwater layer, as highlighted in NASA’s summary of the mission. Galileo used its magnetometer to measure how Callisto’s magnetic field interacted with Jupiter’s magnetosphere. Scientists noticed changes in the data from the magnetic fields that could only be explained by a conductive layer underneath the surface. This is most likely a subsurface salty ocean, because it is slightly conductive of electricity like a weak metal. In NASA’s top 10 science result takeaways from the mission, they explain, “Galileo magnetic data provide evidence that Europa, Ganymede and Callisto have a liquid-saltwater layer.” (NASA, n.d.). The Near-Infrared Mapping Spectrometer (NIMS) also detected water ice on the surface, and the Solid State Imager (SSI) mapped Callisto’s geological features. Together, these instruments helped build our current understanding of Callisto as a moon with a thick ice shell and a liquid layer underneath.

    • Extreme Cold

    Scientists have learned about Callisto’s temperature using both Earth-based and Galileo observations. ALMA, a radio telescope, measured how the surface radiates heat, showing how quickly it warms up and cools down. Galileo’s NIMS instrument measured the amount of sunlight reflected and heat emitted from the surface. The SSI camera provided detailed images to find out which areas are ice or rock. Using this data, scientists concluded the estimated temperature of the surface was around –140℃.

    • Gravity

    We also know that Callisto’s gravity is lower than Earth’s, approximately one-eighth of Earth’s. This information was found by carefully tracking Galileo’s motion path during its Callisto flybys. Small changes in the space shuttle’s speed and trajectory allowed scientists to calculate the moon’s mass and gravitational pull. 

    • Atmosphere and Radiation

    Galileo also collected data about Callisto’s thin atmosphere and radiation environment. The spacecraft detected a thin exosphere (thin atmosphere) with traces of oxygen and carbon dioxide. Although the traces of oxygen were small, it was exciting because it is a hint of possible life. Other information we obtained regarding Callisto’s atmosphere is that the particle detectors and the magnetometer showed that, while the radiation is lower than moons closer to Jupiter, it is still higher than Earth’s. In fact, the radiation on Callisto is more than 10x Earth’s radiation. This is why vehicles and habitats on Callisto would need shielding from galactic cosmic rays (GCRs) and solar energetic particles (SEPs).

    • Summary

    By combining all of the measurements from the magnetometer, spectrometer, camera, and tracking data, scientists can draw detailed conclusions about Callisto’s environment. This research established my knowledge basis for understanding its subsurface ocean, extreme cold, low gravity, thin atmosphere, and radiation. I considered all of these environmental factors and their implications when writing this blog.

    • References

    Camarcha, M., de Kleer, K., Butler, B., Akins, A. B., Thelen, A., de Pater, I., Gurwell, M. A., & Moullet, A. (2023). Thermal properties of the leading hemisphere of Callisto inferred from ALMA observations. The Planetary Science Journal. https://doi.org/10.3847/PSJ/aceb68

    Carberry Mogan, S., Tucker, O. J., Johnson, R. E., Vorburger, A., Galli, A., Marchand, B., Tafuni, A., Kumar, S., Sahin, I., & Sreenivasan, K. (2021). A tenuous, collisional atmosphere on Callisto. arXiv. https://arxiv.org/abs/2107.12341

    Carberry Mogan, S., Tucker, O. J., Johnson, R. E., Roth, L., Alday, J., Vorburger, A., Wurz, P., Galli, A., Smith, H. T., Marchand, B., & Oza, A. (2022). Callisto’s atmosphere: First evidence for H₂ and constraints on H₂O. arXiv. https://arxiv.org/abs/2210.14511

    JPL. (1998, October 21). Jupiter’s Moon Callisto May Hide Salty Ocean. NASA Jet Propulsion Laboratory. https://www.jpl.nasa.gov/news/jupiters-moon-callisto-may-hide-salty-ocean

    NASA. (n.d.). Galileo Science. NASA Science. Retrieved November 16, 2025, from https://science.nasa.gov/mission/galileo/

    NASA / JPL. (1999, February 4). Galileo spacecraft finds thin atmosphere on Callisto. Jet Propulsion Laboratory. https://www.jpl.nasa.gov/news/galileo-spacecraft-finds-thin-atmosphere-on-callisto

    NASA / JPL. (1998, October 21). Callisto Cutaway with Ocean (Artist’s Concept). Photojournal. https://photojournal.jpl.nasa.gov/catalog/PIA01478

    • AI transcript and use

      Link to AI transcript: https://chatgpt.com/share/691ab087-cf70-800f-878c-f64ea057c45f

      In this project, I used ChatGPT to help me discover research articles and papers to discover primary sources relevant to Callisto. I did some research on my own, and after identifying some sources, I asked ChatGPT to explain one of them because I found it confusing to read myself. I didn’t end up actually using this research paper, but it gave me a good summary of what research has been done regarding this moon. Using this base knowledge, I discovered other primary sources and wrote about Callisto’s environment and conditions.
  • Robotics assignment

    Introduction

    This assignment was created to allow students to gain exposure and experience with Robotics, Arduino, and programming an Arduino board. The task requirements were to create something moving, and build a circuit that allows an Arduino board to interact with other components.

    Circuit:

    My idea

    I chose to build a traffic directing system that has all the standard colours (green, yellow and red) and also a stop sign. The way this works is, each of the colours display for a few seconds, and then when the colour turns red, the stop sign comes down and acts as a roadblock. This is an idea similar to how there are barriers that block vehicles from moving near train lines. The idea behind this design is that it would improve safety on the roads and prevent people from taking dangerous risks like skipping red lights to see if they can narrowly make it. The incorporation of the stop sign ensures that even if somebody is tempted to squeeze past and make it through, they can’t. Overall, this is a safety-inspired design idea that could be taken further in the future.

    Details of virtual prototype

    Breadboard, LEDs, GND and power:

    The big white piece on the left is the breadboard. It allows multiple pieces to connect and leave from the same part. There are also blue and red rails that I have connected to the ground and 5V power pins on the Arduino board. The 5V is where the electricity is powered through and the ground (GND) is where it comes back. The circuit flows through 3 LEDs for my traffic system, and connects to the respective arduino pin. Each of the LEDs have a resistor on the same row to allow for a safe amount of current to go through. I used Ohm’s law to calculate the resistance required for my resistors. I had them all at 220Ω.

    Servo, battery and regulator:

    The servo is the blue piece on the right – it is what will move the stop sign. There is a wire connecting Arduino pin 9 and the servo to send control signals. The servo piece is meant to lower the stop sign as a barrier, then lift it back up, similar to that of a vehicular roadblock in front of trains. This is the piece that fulfills one of the two major requirements for this requirement: having a moving piece (and having the code to program it to move). I attached a 5V regulator to the 9V battery in the circuit to reduce the amount of current to a safe amount, because 9V is well above the required amount. The regulated 5V of current is sent to the servo. The servo is also connected to the Ground rail on the breadboard and the 5V rail.

    Bill of Materials (BOM)

    Components required:

    Code

    Code:

    #include <Servo.h>

    This tells the Arduino to include the Servo library which later allows us to control how it moves.

    const int redLED = 2;
    const int yellowLED = 3;
    const int greenLED = 4;
    const int servoPin = 9;

    Creates variable for each LED and gives each of the LEDs a constant Arduino pin number.

    Servo myServo;

    This creates a servo object called myServo – essentially defining it with this name.

    void setup() {

    This line runs the code once when the Arduino starts up.

     pinMode(redLED, OUTPUT);
     pinMode(yellowLED, OUTPUT);
     pinMode(greenLED, OUTPUT);

    This tells the computer that the LED will send signals on its output (whether it is on or off).

    myServo.attach(servoPin);
    }

    This line attaches the servo to Arduino digital pin 9 so that the Aduino can send instructions.

    void loop() {

    Runs the code forever

     digitalWrite(redLED, LOW); // Red light off
      digitalWrite(yellowLED, LOW);  // Yellow light off
      digitalWrite(greenLED, HIGH); // Green light off
      myServo.write(180);  // Stop sign is lifted to one extreme (not blocking traffic any further)
      delay(10000);         // This position will be held for 10000 milliseconds (10 seconds)  

    The text after each double slash is the explanation for the line of code. This block of code turns on the green light and keeps the stop sign lifted so it is not obstructing. It stays in this position for 10 seconds.

     digitalWrite(redLED, LOW); // Red light off
      digitalWrite(yellowLED, HIGH); // Yellow light on
      digitalWrite(greenLED, LOW); // Green light off
      myServo.write(90);  // the stop sign is up - signalling driver to stop (after seeing the yellow light)
      delay(2000);        // this position will be held for 2000 milliseconds (2 seconds)
    

    The text after each double slash is the explanation for the line of code. This block of code turns off the green light, turns on the Yellow light and keeps the stop sign lifted so it is not obstructing. It stays in this position for 2 seconds.

    digitalWrite(redLED, HIGH);// Red light turns on
      digitalWrite(yellowLED, LOW); // Yellow light off
      digitalWrite(greenLED, LOW); // Green light off
      myServo.write(90); // servo is in the middle angle meaning the stop sign will be held in front
      delay(5000); // this position will be held for 5000 milliseconds (5 seconds)
    }

    The text after each double slash is the explanation for the line of code. This block of code turns off the yellow light, turns on the red light and drops the stop sign to the middle angle so that it barricades traffic. It stays in this position for 5 seconds.

    Physical prototype

    Unfortunately I was unable to create a physical prototype due to technical errors on the Arduino IDE. However, I learnt a lot about robotics, through learning the programming, safety methods and how Arduino boards work. At the start of this project, all of this seemed overwhelming, but I took it one step at a time, from exploring ideas and planning, to developing it in TinkerCad. This has been a valuable learning opportunity and I look forward to the next opportunity to apply these newly developed skills.

    Since I could not create a physical prototype, here is the circuit diagram and a screen recording of how my prototype works.

    Circuit diagram:


    Screen recording:
    https://drive.google.com/file/d/1055csxvJikc230yCfZwdoriFzZnIfw6K/view?usp=sharing

    I used minimal AI to help me pinpoint why exactly my servo wasn’t working. Unfortunately, since I was using my personal gemini account, the chat didn’t save and I don’t have access to the transcript. AI was not helpful at interpreting images and finding the error. It did however end up providing me with a long checklist of my wiring where I figured out where I messed up.

  • CAD design – Robotic arm eraser

    I built a CAD model for a Multi-Purpose Robotic Arm. I got inspiration for this idea from a video about Quick Return Mechanisms, and modified it into my own design. My build is a Quick Return mechanism (Robotic arm with changing speeds) with some modifications to hold an eraser and move it. The robotic arm can be purposed into several applications. In this version, it has been designed as a Robotic Arm Eraser. This is a step towards building a useful classroom tool.

    Disclaimer: No AI use, only Onshape teaching and tutorial material (referenced below)

    My 3D build (adapted from https://www.youtube.com/watch?v=c2U8ujLMxCI)

    Skills to be demonstrated for successful assignment:

    Sketch, Extruding, Assembly, Mechanical Drawings, BOM (Bill of materials)

    Sketch

    I drew sketches of all the individual parts for designing this 3D build. All of the sketches are available on the 3D build itself which are accessible through this Onshape link. For example, the Robotic Arm sketch below:

    Extruding

    Extruding is the act of expanding a 2D sketch into 3D. This is how I formed all of my parts for this assignment. To have a look at every extrusion, please check out the Feature list in my Onshape build. Here I used extrusion to create my eraser:

    This part of the design shows my application of a Quick Return Mechanism. To create the eraser, I used a combination of the following techniques: Sketching, chamfering and extrusion. This eraser prism was built with 2 parts. The front half of the prism had a hole to fit the connecting cylinder, and the second half would make contact with an external surface to erase. I created the second half without the continuing hole else, to not have a cylinder poking out.

    Assembly

    Assembly is where all the designed parts are put together as a working model. There are connectors holding pieces together, called mates. There are different types of mates. Mates allow pieces varying degrees of freedom, from fixing them in place, sliding them along an axis, to revolving.

    I have used different types like Revolute mate (revolving), Slider mate, Fasten mate (fixes in place), Tangent mate (makes faces touch without crossing).

    For example, the slider mate was used to move the slider horizontally along the rail: Slider Mate Animation

    Mechanical Drawings

    Mechanical Drawings are an important tool for engineers to express the dimensions of their products and for people to reproduce a build. This drawing contains the detailed dimensions without redundancy, and clearly diagrams the product from multiple views allowing for others to try to build it as well.

    For example, mechanical drawing of disk (wheel) for Robotic Arm:

    Bill of Materials (BOM)

    A bill of materials shows the materials used in a product, along with the details of it. This is usually presented in the Assembly Drawing. It shows detailed information for the product which the designer wants to convey. For example these can include mass, material, colour, quantity. This is also helpful for businesses to order specific parts of the product as needed.

    Bill of Material for Multi-Purpose (Eraser) Robotic Arm

  • Cubing Vocabulary Teacher – coding assignment

    • How I learnt across the duration of this project:
      • Across my coding project, I learnt the importance of defining functions so they are easy to re-use later in you code. At the start, I was planning on coding a simple 3×3 (Rubik’s cube) scramble move generator which exist already, and instead shifted to my underlying but exisiting unique feature of teaching HOW to understand and follow cubing vocabulary. This is an innovative solution to a problem beginners face and is not addressed in other tools. I combined my knowledge from Entrepreneurship class with my cubing and coding skills to create this tool that will hopefully help absolute beginners with no prior knowledge learn how to turn a cube with letter directions.
    • Flowchart:
    • Explanation:
      • I had a coding assignment at school, where my goal was to demonstrate my knowledge of python code, and try to create an innovative tool. I decided to combine my knowledge of cubing with python to develop a tool for cubers. Initially it was developing a scrambles for a 3×3 that doesn’t give redundant moves. Then it developed into a tool that teaches beginner cubers HOW to read cubing moves (formally called notation), and provides a tool to practice this fundamental skill further integrated with a simple way to check the user’s learning.
      • The tool “Cubing Vocabulary Teacher” is designed to address the challenges of the beginner cubers. It does not require any cubing knowledge prior to using this tool. It starts to teach cubing vocabulary to the beginners in step wise fashion with visual cues. The aim is to get them familiarised with the cubing notations. As a next step, the tool allows the users to practice their cubing notation.
      • Once they learn the cubing notations, they can make of use the available cubing resources online to advance their skills. We also provide a way to check if the user can do the moves properly. At the moment, the caveat in the field is that nobody explains the basic vocabulary to beginner cubers. This tool is to bridge the knowledge gap and help new cubers on their journey.
    Code summary – how it works and my logic in developing it
    import random

    I knew from the start that I’d need the random library which is a built in python function that randomly selects something (a cubing move in my case) from a dictionary that the programmer provides.

    def get_yes_no(prompt):
        while True:
            response = input(prompt).strip().lower()
            if response in ["yes", "y"]:
                return True
            elif response in ["no", "n"]:
                return False
            else:
                print("Please enter 'yes' or 'no'.")

    In my code, there were many stages where I needed to ask the user for yes or no. It was simple enough to define this function and was worth it for many different parts of my program.

    def get_choice(prompt, valid_choices):
        while True:
            choice = input(prompt).strip().upper()
            if choice in valid_choices:
                return choice
            else:
                print(f"Invalid choice. Please choose from: {', '.join(valid_choices)}")

    This code looks more complex, but all it does is ask the user for a choice and check if it is valid. If it’s not valid – it will tell the user and keep asking until the computer does. Another part of this function is that it breaks down the users response to lowercase and into lowercase to help interpret all cases of inputs. Regardless if the user input “Yes”, “yEs” or ” yes”, the code will work because before processing the code, the computer will remove all spaces before and after the word and making all of the text lowercase. This lets it check what the user actually meant by simplifying their response to the simple yes or no’s the computer can understand.

    def show_orientation():
        print("\n🧑‍🏫 Hold the cube like this:")
        print("  - White face is UP")
        print("  - Green face is FACING YOU (Front)")
        print("\nCube Face Map:")
        print("         [U]")
        print("     [L] [F] [R] [B]")
        print("         [D]")
        print("U = Up, D = Down, F = Front, B = Back, L = Left, R = Right")
        print()

    The explanation for this is very simple. It is simply a function that will be putting the text inside the quotation marks on the user’s screen. The text that will be displayed gives a visual representation of the cube, and explains where each face (side of the cube – top, bottom , etc) is. Furthermore, it tells you the orientation to hold your cube (helpful if doing scrambling from advanced tools).

    def show_visual_clue(face, direction):
        arrows = {
            "clockwise": "↻",
            "counterclockwise": "↺",
            "180": "⟲⟳"
        }
        print(f"\n🧩 Visual Clue for Move: {face}{direction}")
        if direction == "":
            print(f"Turn the {face} face 90° clockwise {arrows['clockwise']}")
        elif direction == "'":
            print(f"Turn the {face} face 90° counterclockwise {arrows['counterclockwise']}")
        elif direction == "2":
            print(f"Turn the {face} face 180° {arrows['180']}")
        print()

    Here I created another function that will visually show the user how to turn the cube depending on the type of move they have to do using arrows. These arrows are either clockwise, anticlockwise, or a double turn which can be done in either direction (clockwise or anticlockwise – same result). So this function will print the specific instructions per the user’s move when it is called upon.

    def explain_move(move, variation, move_dict):
        base = move
        modifier = variation.replace(move, "")
    
        print("\nExplanation:")
        if modifier == "":
            print(f"{move}: Turn the {move_dict[move]} 90 degrees clockwise.")
        elif modifier == "'":
            print(f"{move}': Turn the {move_dict[move]} 90 degrees counterclockwise.")
        elif modifier == "2":
            print(f"{move}2: Turn the {move_dict[move]} 180 degrees in either direction.")

    This code simply teaches the user how to do a cubing move. This isn’t the same as the show_orientation function that will print the same thing repeatedly. The function here reads what the user wrote and delivers the moves accordingly depending on 2 factors (letter and modification following it). To eliminate the boring work of typing out the instructions for each move manually and to eliminate the possibility of a human error (eg. typo), I created this function to read what the user wrote and give them instructions based on the letter (R, U, etc) and modification following the letter (inverse, none, double turn).

    show_visual_clue(base, modifier)

    This line of code calls the function that teaches the user how to hold the cube and showing which face is which. The parameters it checks for are the base move (simple letter), and the modifier (nothing, inverse, double turn).

    def learn_moves():
        while True:
            show_orientation()
            move_type = get_choice("Choose move type to learn (basic/advanced): ", ["BASIC", "ADVANCED"])
    
    #defining basic moves
            if move_type == "BASIC":
                basic_moves = {
                    "U": "Up face (Top Layer)",
                    "D": "Down face (Bottom Layer)",
                    "L": "Left face",
                    "R": "Right face",
                    "F": "Front face",
                    "B": "Back face"
                }

    This function asks user to choose between learning basic or advanced moves. Interestingly, I also used a previously defined function, “get_choice”, to ask the user which move set they wanted to learn. If the user asks to learn the basic set of moves, I print out a guide for the user which helps them understand which move they would like help learning. They have a choice between advanced and basic. If they know they want to learn the top layer, they can read the list provided, and understand that it is a “U move” they want to learn.

    print("\nBasic Moves:")
                for key, val in basic_moves.items():
                    print(f"{key}: {val}")
    
                move = get_choice("Which basic move would you like to learn? (U/D/L/R/F/B): ", basic_moves.keys())
                direction = get_choice(
                    f"Choose the variation of {move} (e.g., {move}, {move}', {move}2): ",
                    [move, move + "'", move + "2"]
                )
    
                explain_move(move, direction, basic_moves)

    This code prints the basic move definitions on a new line. The second print function prints the basic letter moves with no modifications, and then prints the value (what it means – defined in the basic move list) after the colon between key and val. Then the computer gets the user choice (using our custom function) on which of the basic moves they would like to learn. After that the next step is to get the user choice on the specific modification of the move they’d like to learn (whether it has an apostrophe after it – is an inverse move, or a 2 after it – a double turn). The next line of code is to call the function explain_move and let it do its work.

     elif move_type == "ADVANCED":
                advanced_moves = {
                    "M": "Middle slice (between L and R)",
                    "E": "Equatorial slice (between U and D)",
                    "S": "Standing slice (between F and B)"
                }

    In the case the user asked to learn advanced moves when the program gave it a choice between basic and advanced, a variable is defined where there is a list for where the layers of the advanced moves are.

    print("\nAdvanced Slice Moves:")
                for key, val in advanced_moves.items():
                    print(f"{key}: {val}")
                move = get_choice("Which advanced move would you like to learn? (M/E/S): ", advanced_moves.keys())
                direction = get_choice(
                    f"Choose the variation of {move} (e.g., {move}, {move}', {move}2): ",
                    [move, move + "'", move + "2"]
                )
    
                explain_move(move, direction, advanced_moves)
    
            again = get_yes_no("\nDo you want to learn another move? (yes/no): ")
            if not again:
                break

    On a new line, we print the advanced moves variable (shows where the advanced layers are). Again, just like the basic moves, we are printing the advanced cubing letter (the key) and then the text that explains it (the val). This is all from the variable we defined for the advanced moves earlier. We then ask the user which advanced move it wants to learn, and once we have that, we ask which modification (e.g. double turn) they want to learn. Then we use the explain_move function that we defined earlier, to explain the move to them based on their input here. Now that they have learn this move, we ask them whether they are interested in learning another move. If they say no, we will break out of the learning cycle.

    def practice_scramble():
        cubing_moves = ["R", "R'", "R2", "L", "L'", "L2",
                        "B", "B'", "B2", "F", "F'", "F2",
                        "U", "U'", "U2", "D", "D'", "D2"]
    
        last_axis = None
        scramble = []
        n = 1

    I know it’s standard practise to define all the variables at the start of the code, but this is the code for a whole new task. This is to help the user practice their cubing moves so it is in this new section of code. Now getting into the code, I defined all the possible cubing moves that could be used in a scramble. It is important to note that although the advanced moves are not used for scrambling, they are used when memorising algorithms (applies to higher level cubers). The reason I have the axis is a bit complicated to explain, but to put it simply, I wanted to avoid redundancy in my scrambles. Having consecutive moves on the same axis could even cause a situation where you do a turn and then the next move asks you to promptly undo that. That’s why I avoided having this situation altogether – credit to gemini for the idea of making axis’s to circumvent this issue. I also have the blank square brackets for the scramble, because I wanted to print the moves one line instead of having a new line for every move generated (discovered through troubleshooting). N is being used as a counter for how many moves are being generated.

    while n < 25:
            random_move = random.choice(cubing_moves)
    
    #defining the axis's
            if random_move[0] in "RL":
                axis = "RL"
            elif random_move[0] in "BF":
                axis = "BF"
            else:
                axis = "UD"

    Once the program generates 25 valid moves, n will hit 25 and then the program will stop. The random_move selects a random letter from my list of cubing moves used in a scramble. After that we look at the first letter(index 0) of the user’s move they want to learn and based on which letter it contains, it will be grouped into an axis. A quick explanation, if two faces of the cube can turn the same direction, they are on the same axis.

    if axis != last_axis:
                scramble.append(random_move)
                last_axis = axis
                n += 1

    If the axis is not the same as the axis of the last valid move, we can add it to the list of random_move. After that I increased n by 1, because if it passed the axis requirement or parameter, it is a valid move and the counter should increase.

     print("\n👉 Step 1: Scramble your cube with this sequence:")
        print(" ".join(scramble))
    
        input("\nPress Enter once you finish scrambling...")
    
    #reverse of cube moves for them to check if user followed along correctly
        reverse_solution = []
        for move in reversed(scramble):
            if move.endswith("2"):
                reverse_solution.append(move)
            elif move.endswith("'"):
                reverse_solution.append(move[0])
            else:
                reverse_solution.append(move[0] + "'")

    On a new line we are telling the user to scramble their cube with our sequence (helping them practice). Then the program shows the user the scramble we have made. After that, the user is asked to press enter once they finish scrambling. Now we make a blank list where we will add a move one by one for reversing their scramble to see if they followed their moves correctly. The program checks what modifier or ending the move in the list “scramble” has, then depending on that, the reverse move list is generated. This is what I’m telling the computer to think: If the move ends in a 2, it stays as is and goes into the list, if it has an apostrophe, it needs a clockwise move, and if it is a regular move, it needs an anticlockwise move to create the reverse scramble.

    midpoint = len(reverse_solution) // 2
        step1 = reverse_solution[:midpoint]
        step2 = reverse_solution[midpoint:]
    
        print("\n👉 Step 2: Solve your cube in two phases.")
        print("Phase 1 moves:", " ".join(step1))
        input("Perform these moves, then press Enter...")
        print("Phase 2 moves:", " ".join(step2))
        input("Perform these moves, then press Enter...")
    
        print("\n🎉 If you made no mistakes, your cube is solved!")

    I decided to print out the reverse solution in two parts, because a list of 25 might be intimidating. I achieved this by finding the “midpoint”, half the length of the moves, and then putting them into two variables. After that it is a bunch of print statements that tells the user, their cube will be solved in 2 phases as they follow the moves and click enter. If they finish all of these with no mistakes, their cube should end up solved.

    def main():
        print("🧠 Welcome to Cubing Vocabulary & Practice Trainer!")
    
    #checking conditions on what user wants to do with this tool
        while True:
            print("\nChoose an option:")
            option1 = get_yes_no("Option 1: Do you want to learn cubing vocabulary? (yes/no): ")
            option2 = get_yes_no("Option 2: Would you like to practice your cubing vocabulary with a scramble? (yes/no): ")
    
            #subfunctions are called "learn_moves" or "practice_scramble"
            if option1:
                learn_moves()
            if option2:
                practice_scramble()
    
            if not option1 and not option2:
                print("\nThanks for cubing today! Goodbye 👋")
                break
    
    if __name__ == "__main__":
        main()
    

    This is the final segment of code. This is the main section, and to start off the user interface, I get the computer to print a welcome message that tells the user what this tool does. After this, I use some functions to figure out what exactly the user wants out of this tool. Learn moves and check cubing vocabulary are the two options for the user through the two questions the program asks. Depending on what the user wants, the computer will find the function that defines what it needs to do, and will help the user. If the user answers no to both questions (doesn’t want to learn, or use the tool to practice moves), I get the computer to display a goodbye message and the program ends.

    Transcript of AI interaction:
    • Chat:
      • Me: I have a school assignment on coding, where I should make a flowchart then code with variables, conditional statements, defined functions, User-centred design – with a user interface that is friendly and easy to navigate (not necessarily a GUI), and good code commenting. So it has to be python, and i have a little prior experience with python. The project I have in mind is developing 3×3 scrambles for cubers.
      • Gemini:
        That sounds like a great project for your school assignment! Creating a 3×3 scrambler in Python will allow you to demonstrate your understanding of several key programming concepts. Here’s a breakdown of how you can approach this, including the flowchart, code structure, and user-centered design elements.

        Flowchart

        A flowchart is a visual representation of the steps in your program. Here’s a possible flowchart for your 3×3 scrambler.
        Start: The program begins.
        Display Welcome Message: Show a friendly message to the user explaining what the program does.
        Define Moves: Create a list or a dictionary of all possible moves for a 3×3 cube (e.g., R, L, U, D, F, B).
        Prompt User: Ask the user how long they want the scramble to be.
        Get User Input: Read the user’s input for the desired scramble length.
        Validate Input: Check if the input is a valid number. If not, go back to step 4.
        Generate Scramble:
        Initialize an empty list to store the scramble.
        Loop for the number of times specified by the user’s input.
        Inside the loop:
        Randomly select a move from your list of moves.
        Randomly select a modifier (e.g., ‘ ‘ for a single turn, ”’ for an inverse turn, ‘2’ for a double turn).
        Combine the move and the modifier.
        Check for invalid consecutive moves (e.g., R R’ or R R2). If an invalid sequence is generated, re-randomize.
        Add the valid move to your scramble list.
        Display Scramble: Print the generated scramble to the user.
        Ask to Repeat: Ask the user if they want to generate another scramble.
        Get User Input: Read the user’s response.
        Check Response: If the user says ‘yes’ or ‘y’, go back to step 4.
        Display Goodbye Message: If the user says ‘no’ or ‘n’, display a friendly farewell message.
        End: The program terminates.

        Python Code Structure

        Here’s a skeleton of the Python code with the required elements.
        Python
      • #——————————————————————————- # File: 3x3_scrambler.py # Author: [Your Name] # Date: [Current Date] # # Description: This program generates random 3×3 cube scrambles of a user- # defined length. It includes a user-friendly interface, # error handling, and well-documented code. #——————————————————————————- import random # — Global Variables and Constants — # Define the possible moves and their modifiers CUBE_MOVES = [“R”, “L”, “U”, “D”, “F”, “B”] MODIFIERS = [“”, “‘”, “2”] # — Functions — def display_welcome_message(): “”” Displays a welcome message and explains the program’s purpose. This is part of the User-Centered Design. “”” print(“————————————————–“) print(“Welcome to the 3×3 Cube Scramble Generator!”) print(“This program creates a random scramble of any length you choose.”) print(“————————————————–\n”) def get_scramble_length(): “”” Prompts the user for the desired scramble length and validates the input. Returns a valid integer. “”” while True: try: length_input = input(“Please enter the desired scramble length (e.g., 20): “) length = int(length_input) if length > 0: return length else: print(“Length must be a positive number. Please try again.”) except ValueError: print(“Invalid input. Please enter a whole number.”) def generate_scramble(length): “”” Generates a list of valid 3×3 scramble moves. Args: length (int): The number of moves in the scramble. Returns: list: A list of strings, where each string is a valid move (e.g., “R’”). “”” scramble = [] last_move_base = “” while len(scramble) < length: # Select a random move from the list move = random.choice(CUBE_MOVES) # Ensure the new move is not the same as the last one’s base move if move == last_move_base: continue # Select a random modifier modifier = random.choice(MODIFIERS) # Combine them and add to the scramble full_move = move + modifier scramble.append(full_move) # Update the last move’s base for the next iteration’s check last_move_base = move return scramble def main(): “”” Main function to run the scrambler program. “”” display_welcome_message() while True: # Get the length from the user length = get_scramble_length() # Generate the scramble scramble_list = generate_scramble(length) # Display the result print(“\nYour scramble is:”) print(” “.join(scramble_list)) # Ask if the user wants to go again print(“\n————————————————–“) repeat = input(“Do you want to generate another scramble? (yes/no): “).lower() if repeat not in [“yes”, “y”]: break print(“\nThanks for using the scrambler. Happy cubing!”) # — Program Entry Point — if __name__ == “__main__”: main()




      • User-Centered Design and Good Commenting

        User-Centered Design (UCD):
        Friendly Interface: Use print() statements to provide clear instructions and feedback. The welcome message and goodbye message make the program feel more interactive.
        Easy Navigation: The program guides the user step-by-step: first, it asks for the length, then it provides the scramble, and finally, it asks if they want to repeat. This simple loop is intuitive.
        Error Handling: The get_scramble_length() function uses a try-except block to handle non-integer input and a while loop to ensure the user provides a positive number. This prevents the program from crashing and makes it more robust.
        Good Code Commenting:
        File Header: The comments at the top of the file provide a quick overview of the program’s purpose, author, and date.
        Function Docstrings: Each function has a docstring (the triple-quoted string right after the function definition). This explains what the function does, its arguments (Args), and what it returns (Returns). This is excellent practice for documenting your code.
        Inline Comments: Use comments within the functions to explain complex or non-obvious parts of the logic, like the check to prevent consecutive moves of the same face (e.g., R R').
        This structure and these components should help you create a high-quality project that meets all the requirements of your assignment!
      • Me:
        oh, you gave me the coding answer, which I don’t like. I need to learn and improve my coding skills on my own, so I skipped over that part of your response. Can you send me the same thing with prompts to help me think instead of a direct coding answer
      • Gemini:
        That’s an excellent approach to learning! It’s much more effective to build the solution yourself. I can certainly provide the same guidance in a more conceptual way, with prompts to get you thinking about each part of the project.


        Flowcharting Your Program

        Before you write any code, it’s helpful to map out the process. This is where your flowchart comes in. Think about it like a recipe.
        Question to ask yourself: What is the first thing a user sees or does when they run your program?
        Prompt: How do you get from the starting point to the final scramble? What are the key decision points and loops in the process? For example, what happens if the user enters something that isn’t a number for the scramble length?

        Designing the Code Structure

        Now, let’s think about how to organize your Python code. This is a great opportunity to use functions to break down the problem into smaller, manageable parts.
        Prompt: What are the major, distinct tasks your program needs to perform? For example, one task is greeting the user, another is generating the scramble, and another is handling the main loop of the program. How can you define separate functions for each of these tasks?
        Think about variables: What information do you need to store and use throughout the program? For instance, you’ll need a list of all possible cube moves. What’s a good way to store this information at the beginning of your script?


        User-Centered Design and User Interface

        Your project needs to be “user-friendly.” This means thinking about the person using your program.
        Prompt: How can you make your program welcoming and easy to understand for someone who has never used it before? Think about the messages you’ll display.
        Consider the user’s experience: What if a user accidentally types “twenty” instead of “20”? How can you build in a safeguard so your program doesn’t crash? This is called error handling. What Python structure would be good for this?


        Generating the Scramble Logic

        This is the core of your program. A good scramble isn’t just a random string of letters; there are rules to follow (e.g., you can’t have “R R’” in a row).
        Prompt: How can you use Python’s random library to select a move and a modifier?
        Think about the rules: How can you prevent moves on the same face from happening consecutively (e.g., “R” followed by “R’”)? What information do you need to store from the previous move to check against the current one?
        The loop: How do you make sure your scramble has the exact number of moves the user requested? What kind of loop would be best for this?


        Code Commenting

        Good code commenting helps others (and your future self!) understand your code.
        Prompt: Where would it be most helpful to add comments? Think about the top of the file, what each function does, and any particularly tricky lines of code.
        By thinking through these questions, you’ll have a solid plan and a much deeper understanding of the concepts required to build your scrambler. Good luck with your project!
      • Me:
        how do i make a user friendly interface
      • Gemini:
        That’s a fantastic question, and a crucial part of any coding project! A user-friendly interface (UI) is what makes your program accessible and enjoyable for others to use. Even if you’re not creating a full graphical user interface (GUI) with windows and buttons, you can still make your text-based interface (TUI) very user-friendly.
        Here are some prompts to guide your thinking about creating a user-friendly interface for your 3×3 scrambler:

        1. Welcoming the User

        Prompt: When a user first runs your program, what should they see? How can you immediately let them know what the program does and how to start using it?
        Think about: A clear, concise welcome message.
        Example: Instead of just showing a prompt, you could print something like:
        ------------------------------------ Welcome to the Cube Scramble Maker! Let's generate some scrambles for your 3x3 cube. ------------------------------------

        2. Guiding the User Step-by-Step

        Prompt: How do you clearly tell the user what information you need from them at each stage?
        Think about: Using descriptive prompts for input.
        Example: Instead of just input("> "), you could use:
        Python

        scramble_length_str = input("How many moves should be in your scramble? (e.g., 20): ")
        Consider: What happens if the user doesn’t provide the information you expect?

        3. Handling Errors Gracefully

        Prompt: What are the common mistakes a user might make when interacting with your program? How can you prevent these mistakes from crashing your program or confusing the user?
        Think about:
        Entering text when a number is expected (like for scramble length).
        Entering a negative number or zero for the length.
        Typing “yes” or “no” in an unexpected way when asked to repeat.
        How can you provide helpful feedback? Instead of just an error message, tell them why it’s an error and what they should do.
        Example: If they type “twenty” for length:
        Bad: ValueError: invalid literal for int() with base 10: 'twenty'
        Good: "Oops! That doesn't look like a number. Please enter a whole number for the scramble length (like 20)."

        4. Presenting Information Clearly

        Prompt: Once you’ve generated the scramble, how do you show it to the user in the most readable way?
        Think about:
        Using spaces between moves so they’re distinct.
        Perhaps putting the scramble on its own line or within a clear section.
        Example: R U' F2 B R2 U looks much better than RU'F2BR2U.

        5. Making Choices Easy

        Prompt: When you ask the user if they want to do something again (like generate another scramble), how do you make it simple for them to respond?
        Think about:
        Accepting variations like “yes,” “y,” “YES,” or “Y.”
        Making it clear what options are available.
        Example: A prompt like: Do you want to generate another scramble? (yes/no):
        And then, in your code, checking if the input, converted to lowercase, is “yes” or “y”.

        6. Providing a Polite Exit

        Prompt: When the user decides to stop using your program, how do you say goodbye?
        Think about: A simple, friendly closing message.
        Example: Thanks for using the scrambler! Happy cubing!
        By thinking about these prompts, you’re essentially designing the conversation between your program and the user. This is the heart of creating a user-friendly interface, even in a text-based environment!
      • Me: what is the format of using the random library in terms of giving it a set of letters to randomise and then display
      • Gemini: To use Python’s random library to select and display a random item from a sequence, you’ll primarily use the random.choice() function.

        How to use random.choice()

        The random.choice() function takes a non-empty sequence (like a list, tuple, or string) as its argument and returns a single, randomly selected element from that sequence.
        Here’s the basic format:
        Python

        import random # A list of letters my_letters = ['A', 'B', 'C', 'D', 'E'] # Randomly select one letter from the list random_letter = random.choice(my_letters) # Print the result print(random_letter)
        Every time you run this code, it will print one of the letters from the my_letters list at random.

        Applying this to Your Scrambler Project

        For your 3×3 scrambler, you can use random.choice() in a few places:
        Selecting the face: Create a list of all the faces on a 3×3 cube (R, L, U, D, F, B). Then, use random.choice() on this list to pick a random face for your move.
        Selecting the modifier: Create another list with the modifiers (' ', ', 2). Use random.choice() on this list to get a random modifier.
        Once you have the random face and random modifier, you can combine them to form a single move string, like 'R'.
      • Me: i have scramble outputs now, how do i make them not have moves that are repetitive or redundant like: “L, L’ “, or “U, D, U2”
      • Gemini:
        That’s a key part of making a good scrambler. Here’s a conceptual way to approach it.

        The Logic of a Good Scramble

        A good cube scramble follows specific rules to ensure every move is meaningful and non-redundant. The primary rule is that a move should not be on the same axis as the immediately preceding move.
        Axis: Think of the cube’s faces in pairs: (R, L) are on one axis, (U, D) on another, and (F, B) on the third.
        Right/Left Axis: R, R', R2, L, L', L2
        Up/Down Axis: U, U', U2, D, D', D2
        Front/Back Axis: F, F', F2, B, B', B2

        How to Implement This in Your Code

        To prevent redundant moves, you’ll need to keep track of the last move’s axis.
        Map Moves to Axes: Create a way to know which axis each move belongs to. A dictionary or a series of conditional statements would work well for this. For example:
        'R' and 'L' belong to the “Right/Left” axis.
        'U' and 'D' belong to the “Up/Down” axis.
        'F' and 'B' belong to the “Front/Back” axis.
        Generate a Move with a Loop: When you generate your scramble, do it one move at a time inside a loop.
        Inside the loop:
        Randomly select a new move (e.g., 'U').
        Check the axis: Compare the axis of this new move to the axis of the previous move.
        If the axes are the same, you have a potential redundancy. For example, if the last move was 'D' (Up/Down axis) and your new random move is 'U' (also Up/Down axis), you should discard this new move and try again.
        If the axes are different, the move is valid. Add it to your scramble list and update the “last axis” variable for the next iteration.
        This “check-and-retry” loop ensures you always generate a valid, non-redundant sequence of moves for your scramble.