Author: akbarj

Project Goals

What problem did you set out to solve?

Every day, some people wake up unable to feel anything but their head. To eat breakfast, they are fed by a caretaker because their hands are paralyzed. Around 15.4 million people deal with Spinal Cord Injuries(SCIs) in the world. This is such a significant problem because paraplegic and tetraplegic people have much worse quality of their lives. They have to deal with all their daily activities without being able to move so much of their body. Paraplegics can’t move their legs and tetraplegics can’t move their arms or legs, making them almost immobile.

That is a very large problem. To narrow the scope, I decided to prove that the brain’s signals are still there even if they are not able to send anything down to the lower parts of the body. If we can prove they are still present in the body, then later on the technology to artificially move those body parts can be made. Rather than replicating expensive BCI systems, this project looks at: What signals does that body still produce and how can it be used?

Project Constraints

Who are your users?

Because this is such a simple scope of the project, I think the primary user is myself in order to understand the field better. This project could be used by bored patients who wanted to play Flappy Bird, however, it is not at a level to improve their quality of life in any real way.

Eventually when this projects gets to a usable level, I will be catering to SCI patients. Typically, these are males with an average age of injury of 43 years old. According to a study on BCIs after SCI, a survey was done on veterans with SCI, and they all wanted restoration of bladder and bowel control, walking, and arm/hand functionality. Overall, they just wanted independent operation. Although BCI systems for rehabilitation already exist, they face two major problems. The first is that they are still in the experimental phase and are not ready for clinical application. The second is that non-invasive options struggle with consistent signals and are bulky and uncomfortable. This gap is where my project will fit in – a non-invasive option that is convenient to those users.

What is the time frame of the project?

The project ran from early February to early May, making it about 3 months.

What other constraints have you identified?

One of the biggest constraints for me for this project was hardware. First of all, all headsets that would work for this kind of project were very expensive. In terms of budget, we ended up spending $350 CAD on the headset and an additional $15 for access to the platform – MindMonitor – that streamed the headset’s signals wirelessly to my laptop. This headset – the Muse 2 – was one of the cheapest I could find to work with this kind of project. I also had to deal with the problem that the electrodes were not placed on the motor cortex, the part of the brain associated with movement. On top of that, I had never done any projects in this field – one more reason why it was such a simple project – and this constraint made me have to learn how to deal with coding in this environment.

Project Expectations

What is the scope of your problem?

When I was making the project, I knew it should focus on reading the brain signals from the Muse 2 and use them for something. I did not intend to work with actual SCI patients or make a medical device because I knew I was still learning how the field works.

How will you identify or define success?

If I could get an input from the brain and use it, I would call that success.

Design Choices

What is your solution?

I built a system for people to play Flappy Bird with their mind. The framework starts with a Muse 2 headset that receives signals from the TP9, TP10, AF7, and AF8 electrodes. Those signals are sent to my phone using Bluetooth, then streamed to my laptop using the Mind Monitor app. Once the signals are on the computer, the code would watch for the signal’s amplitude to pass a certain threshold, causing a jump in the Flappy Bird game. Every time the user triggered a spike, the bird jumped.

All of these choices were intentional decisions. The Muse 2 was one of the cheapest headsets that was in line with what I was trying to do. Because I decided on the Muse 2, I used Mind Monitor because their app is built for the Muse ecosystem. A simple amplitude threshold detector was used over a more complex algorithm because for this use case, that’s all that is required. All the game needs is when it should jump and when it shouldn’t, and a complex classifier would just be unneeded complexity. Flappy Bird was used because it is just a binary jump or no jump that fits perfectly with the vision.

What does it look like?

Project Planning

What are the steps to get to your goal?

First, I started with making sure the framework worked. I wanted to see if the signals could go from the headset to my computer. I made a file that I later built off of to receive the streaming data and just log it onto my computer. Once that was successful, I used that data to make a threshold reader that would trigger every time the signal passed the threshold. I then made the game with the help of Claude Code. I decided to use Claude Code because I saw the game as a way to test my project rather than the actual project itself.

What feedback have you received? From where? How has your design evolved?

I didn’t receive much feedback on my project because I only showcased it at the project presentations and no sooner. Looking back, I think this is a mistake because some feedback might have helped me evolve my design.

Bill of Materials and Cost Analysis

$365 seems like a very high price for what I ended up building. The reason is that BCIs are such a new field, and breaking into it requires a high upfront cost. However, the headset I ended up purchasing is not even very powerful for the types of applications I am interested in, but those headsets go into the thousands.

Testing and Validation

Why do you think that your solution will be successful?  What evidence do you have?  If you tested the prototype, how did you do this and what did the test look like?

Once I had everything ready, I needed to test it and play the game. I tried different ways of controlling the signal – jaw clenching, eyebrow raising, and blinking – to see which were the most powerful and most consistent. After trying to trigger a jump with those different EMG signals I understood which were better and worse.

All of them worked to play Flappy Bird. I was able to get good scores with all of these methods.

Although these signals are not actually EEG signals, they would still be useful in helping someone with a SCI. They are either paralyzed below the neck or below the torso, but their face is still able to move in both cases. Knowing when a blink, a clench, or an eyebrow raise is performed could lead to a simple control mechanism for an SCI patient. Even though direct mind control seems ideal, it is hard to train someone who hasn’t engaged their motor cortex in so long to imagine movements like jumping. For this reason, we can use actions they are already familiar with to allow them to use technology that will improve their quality of life.

Sustainability / Code of Ethics

What ethical implications exist in your problem, solution, and process?

Patients with SCIs are very vulnerable with their conditions, and if they are in a situation where they depend on BCI technology that fails, they will be greatly affected. That failure may cause serious problems in their lives and they will probably need to be back in a hospital relying on the old hospital workers they used to have.

In terms of privacy, although my specific project doesn’t present any serious concerns, this technology could be taken advantage of in the future by interpreting the raw data from the brain. The level of damage this could cause depends on the sophistication of the headset and of the interpretation algorithm.

Conclusions and Recommendations

I think that I succeeded because I was able to use an input that came from the brain to do something – jump in Flappy Bird. This matters because now I’ve worked with BCIs and this opens many doors for later on. In the future, I hope to continue my work with BCIs. I hope to get access to a more powerful one so that I can build impactful projects. If someone wanted to continue this work, they should focus on getting access to better hardware. As I worked on this project, I noticed that the limitations of this headset limited what I was able to build. I think that if I had a more powerful headset with electrodes on the motor cortex, I would’ve been able to build a more complex and useful project.

References

World Health Organization. (2024, April 16). Spinal cord injury. https://www.who.int/news-room/fact-sheets/detail/spinal-cord-injury

Collinger, J. L., Boninger, M. L., Bruns, T. M., Curley, K., Wang, W., & Weber, D. J. (2013). Functional priorities, assistive technology, and brain-computer interfaces after spinal cord injury. Journal of Rehabilitation Research and Development, 50(2), 145–160. https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3684986/

Jiang, L., Li, F., Tang, Y., & Liu, X. (2023). Brain–computer interface: trend, challenges, and threats. Frontiers in Computational Neuroscience. https://pmc.ncbi.nlm.nih.gov/articles/PMC10403483/

Appendices

Appendix A — Final Project Code

oscreceiver.py

from pythonosc import dispatcher, osc_server
import argparse
import time

PORT = 5000


def handle_eeg(address, *args):
    labels = ["TP9", "AF7", "AF8", "TP10", "AUX"]
    values = "  ".join(f"{l}={v:+8.2f}" for l, v in zip(labels, args))
    print(f"[EEG] {values}")


def handle_any(address, *args):
    print(f"[OSC] {address}  {list(args)}")


def main():
    parser = argparse.ArgumentParser(description="Muse 2 OSC receiver")
    parser.add_argument("--port", type=int, default=PORT)
    parser.add_argument("--eeg-only", action="store_true",
                        help="Print only /muse/eeg messages")
    args = parser.parse_args()

    d = dispatcher.Dispatcher()
    d.map("/muse/eeg", handle_eeg)
    if not args.eeg_only:
        d.set_default_handler(handle_any)

    server = osc_server.ThreadingOSCUDPServer(("0.0.0.0", args.port), d)
    print(f"Listening for OSC on UDP port {args.port} …  (Ctrl-C to stop)")
    print("Expected channel order: TP9  AF7  AF8  TP10  AUX\n")
    try:
        server.serve_forever()
    except KeyboardInterrupt:
        print("\nStopped.")


if __name__ == "__main__":
    main()

jaw_detector.py

from pythonosc import dispatcher, osc_server
from collections import deque
import argparse
import math
import time

SAMPLE_RATE_HZ = 256
DEFAULT_WINDOW_SEC = 0.25
DEFAULT_THRESHOLD_UV = 150.0
DEFAULT_DEBOUNCE_SEC = 0.35


class JawClenchDetector:
    def __init__(
        self,
        threshold_uv: float = DEFAULT_THRESHOLD_UV,
        window_sec: float = DEFAULT_WINDOW_SEC,
        debounce_sec: float = DEFAULT_DEBOUNCE_SEC,
        on_clench=None,
    ):
        self.threshold = threshold_uv
        self.debounce = debounce_sec
        self.on_clench = on_clench
        window_samples = max(1, int(window_sec * SAMPLE_RATE_HZ))
        self.tp9 = deque(maxlen=window_samples)
        self.tp10 = deque(maxlen=window_samples)
        self.last_fire_time = 0.0
        self.last_amplitude = 0.0

    def feed(self, tp9: float, tp10: float):
        self.tp9.append(tp9)
        self.tp10.append(tp10)
        if len(self.tp9) < self.tp9.maxlen:
            return

        n = len(self.tp9)
        mean9 = sum(self.tp9) / n
        mean10 = sum(self.tp10) / n
        var9 = sum((v - mean9) ** 2 for v in self.tp9) / n
        var10 = sum((v - mean10) ** 2 for v in self.tp10) / n
        amp = (math.sqrt(var9) + math.sqrt(var10)) / 2.0
        self.last_amplitude = amp

        if amp >= self.threshold:
            now = time.monotonic()
            if now - self.last_fire_time >= self.debounce:
                self.last_fire_time = now
                if self.on_clench:
                    self.on_clench(amp)


def _bar(value: float, max_value: float, width: int = 40) -> str:
    filled = min(width, int(width * value / max_value))
    return "█" * filled + "·" * (width - filled)


def _run_standalone(port: int, threshold: float):
    detector = JawClenchDetector(
        threshold_uv=threshold,
        on_clench=lambda amp: print(f"\n*** CLENCH ({amp:6.1f} µV) ***"),
    )

    def handle_eeg(address, *args):
        if len(args) < 4:
            return
        tp9, _af7, _af8, tp10 = args[0], args[1], args[2], args[3]
        detector.feed(tp9, tp10)

    d = dispatcher.Dispatcher()
    d.map("/muse/eeg", handle_eeg)
    server = osc_server.ThreadingOSCUDPServer(("0.0.0.0", port), d)

    import threading
    t = threading.Thread(target=server.serve_forever, daemon=True)
    t.start()

    print(f"Listening on UDP {port}.  Threshold: {threshold:.0f} µV.")
    print("Live amplitude (TP9+TP10 RMS) — clench your jaw to test:\n")
    bar_max = max(threshold * 2.5, 200.0)
    try:
        while True:
            amp = detector.last_amplitude
            marker = "  <-- TRIGGER" if amp >= threshold else ""
            print(f"\r{_bar(amp, bar_max)} {amp:7.1f} µV{marker}   ", end="", flush=True)
            time.sleep(0.05)
    except KeyboardInterrupt:
        print("\nStopped.")


def main():
    parser = argparse.ArgumentParser(description="Muse jaw clench detector")
    parser.add_argument("--port", type=int, default=5000)
    parser.add_argument("--threshold", type=float, default=DEFAULT_THRESHOLD_UV)
    args = parser.parse_args()
    _run_standalone(args.port, args.threshold)


if __name__ == "__main__":
    main()

jump_detector.py

from collections import deque
from pythonosc import dispatcher, osc_server
import argparse
import math
import threading
import time

ACC_RATE_HZ = 52
DEFAULT_FREEFALL_G = 0.5
DEFAULT_GROUNDED_G = 0.85
DEFAULT_DEBOUNCE_SEC = 0.8


class JumpDetector:
    def __init__(
        self,
        freefall_g: float = DEFAULT_FREEFALL_G,
        grounded_g: float = DEFAULT_GROUNDED_G,
        debounce_sec: float = DEFAULT_DEBOUNCE_SEC,
        on_jump=None,
    ):
        self.freefall_g = freefall_g
        self.grounded_g = grounded_g
        self.debounce = debounce_sec
        self.on_jump = on_jump
        self.last_magnitude = 0.0
        self.last_fire = 0.0
        self._airborne = False

    def feed(self, x: float, y: float, z: float):
        mag = math.sqrt(x * x + y * y + z * z)
        self.last_magnitude = mag

        if not self._airborne:
            if mag < self.freefall_g:
                now = time.monotonic()
                if now - self.last_fire >= self.debounce:
                    self._airborne = True
                    self.last_fire = now
                    if self.on_jump:
                        self.on_jump(mag)
        else:
            if mag > self.grounded_g:
                self._airborne = False


def _bar(value, max_value, width=40):
    filled = min(width, int(width * value / max_value))
    return "█" * filled + "·" * (width - filled)


def _run_standalone(port, freefall):
    detector = JumpDetector(
        freefall_g=freefall,
        on_jump=lambda mag: print(f"\n*** JUMP (freefall {mag:.2f} g) ***"),
    )

    def handle_acc(address, *args):
        if len(args) >= 3:
            detector.feed(args[0], args[1], args[2])

    d = dispatcher.Dispatcher()
    d.map("/muse/acc", handle_acc)
    server = osc_server.ThreadingOSCUDPServer(("0.0.0.0", port), d)
    t = threading.Thread(target=server.serve_forever, daemon=True)
    t.start()

    print(f"Listening on UDP {port}.  Freefall trigger: < {freefall:.2f} g")
    try:
        while True:
            mag = detector.last_magnitude
            state = "AIRBORNE" if detector._airborne else "grounded"
            marker = "  <-- FREEFALL" if mag < freefall else ""
            print(f"\r{_bar(mag, 4.0)} {mag:.3f} g  [{state}]{marker}   ",
                  end="", flush=True)
            time.sleep(0.05)
    except KeyboardInterrupt:
        print("\nStopped.")


def main():
    parser = argparse.ArgumentParser(description="Muse jump detector")
    parser.add_argument("--port", type=int, default=5000)
    parser.add_argument("--freefall", type=float, default=DEFAULT_FREEFALL_G)
    args = parser.parse_args()
    _run_standalone(args.port, args.freefall)


if __name__ == "__main__":
    main()

bci_flappy.py

import argparse
import threading

import pygame
from pythonosc import dispatcher, osc_server

from flappy import Game
from jaw_detector import JawClenchDetector
from jump_detector import JumpDetector

CLENCH_EVENT = pygame.USEREVENT + 1
JUMP_EVENT   = pygame.USEREVENT + 2


def start_osc_listener(port, clench_threshold, jump_threshold):
    def on_clench(amp):
        pygame.event.post(pygame.event.Event(CLENCH_EVENT, value=amp))

    def on_jump(mag):
        pygame.event.post(pygame.event.Event(JUMP_EVENT, value=mag))

    clench_det = JawClenchDetector(threshold_uv=clench_threshold, on_clench=on_clench)
    jump_det   = JumpDetector(freefall_g=jump_threshold, on_jump=on_jump)

    def handle_eeg(_addr, *args):
        if len(args) >= 4:
            clench_det.feed(args[0], args[3])

    def handle_acc(_addr, *args):
        if len(args) >= 3:
            jump_det.feed(args[0], args[1], args[2])

    d = dispatcher.Dispatcher()
    d.map("/muse/eeg", handle_eeg)
    d.map("/muse/acc", handle_acc)

    server = osc_server.ThreadingOSCUDPServer(("0.0.0.0", port), d)
    threading.Thread(target=server.serve_forever, daemon=True).start()

    print(f"OSC listening on UDP {port}")
    print(f"  Jaw clench threshold : {clench_threshold:.0f} µV")
    print(f"  Jump threshold       : {jump_threshold:.2f} g")
    print(f"  SPACE / click also work as fallback\n")


def main():
    parser = argparse.ArgumentParser(description="BCI Flappy Bird")
    parser.add_argument("--port",              type=int,   default=5000)
    parser.add_argument("--clench-threshold",  type=float, default=45.0,
                        help="Jaw clench RMS µV threshold")
    parser.add_argument("--jump-threshold",    type=float, default=1.8,
                        help="Jump acceleration magnitude in g")
    args = parser.parse_args()

    game = Game()
    start_osc_listener(args.port, args.clench_threshold, args.jump_threshold)

    running = True
    while running:
        dt = game.clock.tick(60) / 1000.0
        for e in pygame.event.get():
            if e.type == CLENCH_EVENT:
                print(f"  jaw  {e.value:6.1f} µV -> flap")
                game.jump()
            elif e.type == JUMP_EVENT:
                print(f"  jump {e.value:.2f} g  -> flap")
                game.jump()
            elif not game.handle_event(e):
                running = False
        game.update(dt)
        game.draw()
    pygame.quit()


if __name__ == "__main__":
    main()

Appendix B –

A Kanban board was used to organize the project’s tasks. Daily logs were used to keep track of progress.

I have made progress in understanding the scope of my project since my last update.

There are 15.4 million people with spinal cord injury, which disrupts the connection between their brain and muscles. Current technology does not reliably restore intuitive voluntary movement. A system that would be able to understand what the user wants to do and stimulate their muscles would restore voluntary movement.

As I am writing this, I’ve unboxed the Muse 2 headband, a EEG headset with 4 electrodes: 2 along the forehead (AF7, AF8), and 2 behind the ears (TP9, TP10). Reference channel (FPz) is in the center of the forehead.

I chose the Muse 2 over other options such as the Muse S Athena or the Emotiv Epoc X because the Muse 2 had the highest ROI. Even though the other options are known to be much better, I’ve narrowed the scope of the project to a very simple task that the headset needs to complete, and this can be done even with the Muse 2.

I have simplified the project to a Flappy Bird game you play with your mind. The Muse 2 will sense the trigger in your brain, causing the bird to jump. The game will be played in real time with the user wearing the headset while watching the screen and triggering the jump with the mind.

Currently, I am in the process of making the classifier model that will detect when the trigger occurs. I plan to make two different versions of the model, each with their own trigger to see different triggers and their accuracies. One trigger will be clenching your jaw, and one will be imagining jumping or imagining going up.

Since my previous update, I’ve progressed on my project. I am trying to build a connection between a brain and a computer, and perhaps eventually the body. I define the problem below

There are 15.4 million people with spinal cord injury, which disrupts the connection between their brain and muscles. Current technology does not reliably restore intuitive voluntary movement. A system that would be able to understand what the user wants to do and stimulate their muscles would restore voluntary movement.

Since the last update, I’ve done research to better understand the potential target market to allow me to focus my project more specifically.

There are two main parts of paralysis I’m looking at: paraplegia and tetraplegia. Paraplegia is the paralysis of the legs while tetraplegia is the paralysis of all 4 limbs and the torso.

I have decided I will start as simple as possible. My procedure is as follows: Use the BCI CV 2a Dataset to train a classification model that gets a minimum 95% accuracy score. Then, I will purchase an affordable EEG headset. I will need to make a new model based off the previous one for the specifications of the new headset.

The main part of the definition statement this focuses on is “understand what the user wants to do.” That part is much safer to focus on because once the human body gets involved, I am at risk of harming someone, for example if I tested it on myself(which I probably would), I might damage something in my body.

The biggest challenge I foresee is coding the classification model because it has been some time since I’ve done any big coding projects, so it might take some time for me to remember.

As of right now, my next step is to create the classifier model.

I have used AI to assist me in my project to help me unpack such a complex topic. The transcripts are listed below:

https://docs.google.com/document/d/1CoE7TABSEuxQ2X2NbVKCYMHyMqrHT-zPR7hzq_gNGlI/edit?usp=sharing

Definition Statement

There are 15.4 million people with spinal cord injury, which disrupts the connection between their brain and muscles. Current technology does not reliably restore intuitive voluntary movement. A system that would be able to understand what the user wants to do and stimulate their muscles would restore voluntary movement.

I am solving this problem for the 15.4 million people who deal with spinal cord injury today. There are two main types of SCI: Tetraplegia which is paralysis of all 4 limbs and some of the torso, and paraplegia where the legs cannot move but the arms still work. I will. specifically focus on helping people with Cervical SCI to help restore upper-limb movement.

Possible Solutions

1. Noninvasive BCIs connected to electrodes to externally stimulate muscle contraction
   • This idea is the best for my current position. I do not have access to a lab to implant electrodes and BCIs. Noninvasive BCIs are not as powerful because of the noise that they pick up alongside the brain activity. However, using AI I will be able to remove some noise to detect brain intent.
2. Invasive BCIs connected to electrodes to stimulate muscle contraction
   • Although this idea would be much more powerful than the previous, I do not have access to a lab where I could implant an invasive BCI, nor do I have the license to. 
3. Electrodes on the spine to restore connection between brain and muscles
   • This idea would also require a lab to insert the electrodes on the spine, which is not feasible in my position. However, this idea could potentially be more powerful than idea #2 because instead of getting signals directly from the brain and externally stimulating the muscles, this would theoretically restore the original movement because it is the link between the brain and the muscles. 
4. Implant electrodes inside muscle tissue to make precise movement connected with BCIs
   • This is not so much of a standalone idea as something to add on to another idea because implanting electrodes in the muscles to get more precise movement would be much better when retraining motor control to help restore fine movements.
5. BCI controlled exoskeleton
   • A BCI controlled exoskeleton although it would be simpler than stimulating the muscles, it is bulky and the goal of the BCI solution is to make something discreet to make the people who suffer from SCIs feel more normal.

Possible Prototype for #1

The prototype would be a non-invasive BCI to get signals from the brain. Because the brain still sends the same signals to the body even when they can’t move the body parts, those signals can be read to send signals to different electrodes placed on the body. When the electrodes send a small electrical pulse, the muscle contracts.

What I hope to have ready in May at the minimum is a noninvasive BCI that I can read the signals from to determine some sort of action the user would like to do. Depending on how much progress I make I could either show the results on the computer and make the user do something such as play a simple game like flappy bird/dinosaur jump,  or I could connect it to electrodes on my muscles to stimulate them, if I am allowed.

Plan for this Project

The first step of this project is understanding software. I will use an EEG dataset to make a classification algorithm to classify motor intent. Then I will simulate it to see if it works and iterate. 

Once I have a working algorithm, I will purchase a noninvasive EEG and use the algorithm to decode the signals from my brain. I will attempt decoding starting at simple left and right imagery, then go into more complex commands and see how good my algorithm is. I will iterate with the algorithm until it is strong enough to use.

After this I will purchase an electrode to attempt stimulating my muscle. I will need to be very careful at this stage because doing it wrong could cause harm to the wearer, which would be me. I may decide not to use an electrode but instead use the signal to send signal to a robot arm, which would move based on the commands. 

Trappist-1e is one of humanity’s best candidates for a future home. It lies in Trappist-1’s habitable zone, meaning that there is a chance of liquid water, the most important factor to human survival. It’s a rocky planet approximately the same density as Earth.

Even though Trappist-1e is 39 light-years away, it has many good opportunities for humans. Because Trappist-1e has similar gravity to Earth, humans would adjust easily to the new environment. Trappist-1e and the other planets in the Trappist-1 system have a good chance of having water because they are in the habitable zone and Trappist-1e specifically has a rocky composition similar to that of Earth’s. According to the TRAPPIST-1 Habitable Atmosphere Intercomparison (THAI) project, even with many different atmosphere possibilities, Trappist-1e has a good chance of being livable, the main exception being if it has no atmosphere.

Settling on Trappist-1e has some serious challenges. The planet may be tidally locked, which would mean that one side is in constant daylight and extreme heat and the other side is in permanent darkness with extreme cold. The only habitable part would be the twilight zone. Another big problem is that we don’t know what type of atmosphere Trappist-1e has, or whether there even is an atmosphere. Based on research by JWST, Venus and Mars-like atmospheres are ruled out, however there are still a few problematic possible atmospheres. Without an atmosphere, humans would experience extreme cold and strong radiation from the Trappist-1 star, which is known to produce strong radiation that could harm people and damage equipment. Because Trappist-1 primarily produces infrared light, agriculture and energy generation would need to be redesigned to work under the low red lighting instead of the Sun’s bright rays.

The environment has a large implication on vehicle design. Even though humans would live in the twilight zone, travel to the hot and cold sides would be necessary to get resources like frozen water and metals. This implies that vehicles need temperature-control systems. Vehicles would need to be able to handle radiation flares. The atmosphere of Trappist-1e is unknown, but there is a chance that there is no atmosphere at all. If there isn’t, the vehicle must be equipped to handle travelling in an environment like this. Depending on what atmosphere, the planet has, the vehicle should be properly equipped for those conditions. Lastly, they would need to be equipped to drive the probably rugged terrain of the planet.

In order to build solar-powered vehicles, the design would need to be modified to work with infrared radiation because the Trappist-1 star primarily emits infrared light. Infrared light does not have as much energy as visible light, which means stronger solar panels would be needed.

Everything we know about Trappist-1e is from telescopes and analyses. It was discovered using the transit method. The transit method works to detect exoplanets by measuring light from a star and when the light gets lower for a bit, it could mean a planet passes over it. If this happens repeatedly in a cycle, it likely means there is a planet. The Trappist-1 system was discovered by the TRAPPIST-South telescope. Later, NASA’s Spitzer telescope captured much more precise transit data which told them about all the planets, their radii, orbital period which is how long it takes for a planet to orbit its star, and that it is likely a rocky planet.

In 2018, researches such as Grimm et al. published a paper called “The nature of the TRAPPIST-1 exoplanets” documenting how they used something called TTV which stands for Transit Timing Variations to calculate the masses and densities of all Trappist-1 planets. This told us that Trappist-1e has an earth-like density and confirmed it is a rocky planet.

More recently, the James Webb telescope was used to analyze starlight passing through Trappist-1e’s atmosphere using powerful tools such as NIRSpec, NIRISS, and MIRI. These can determine what gasses are in the planet’s atmosphere. The data says that Trappist-1e likely doesn’t have a Venus or Mars-like atmosphere, however it doesn’t mean that the atmosphere is suitable for humans yet.

Lastly, there was a large climate modelling project called the THAI project(Trappist-1 Habitable Atmosphere Intercomparison). It was a community project with multiple supercomputers to run multiple GCMs(global climate models).

Trappist-1e promises a good future for humankind. If we’re lucky, Trappist-1e will be the perfect planet for human beings to settle in the future, once we figure out how to travel to it.

Reflection on AI Use

I used AI to help me research about the project and to write the APA sources list. It was very useful to learn specific things that I found harder to find by surfing the web. I also found it very easy for the APA sources because it knows how to do it.

Transcript: https://docs.google.com/document/d/1PwG_k8H0EBNdnPvLWE5l5KgVPdC9LNNfrlcBej1qcsQ/edit?tab=t.0

Citations

Gillon, M., Jehin, E., Lederer, S. M., Delrez, L., de Wit, J., Burdanov, A., Van Grootel, V., Burgasser, A. J., Triaud, A. H. M. J., Opitom, C., Demory, B.-O., Sahu, D. K., Bardalez Gagliuffi, D., Magain, P., & Queloz, D. (2016). Temperate Earth-sized planets transiting a nearby ultracool dwarf star. Nature, 533, 221–224. https://doi.org/10.1038/nature17448

Gillon, M., Triaud, A. H. M. J., Demory, B.-O., et al. (2017). Seven temperate terrestrial planets around the nearby ultracool dwarf star TRAPPIST-1. Nature, 542, 456–460. https://doi.org/10.1038/nature21360

NASA. (n.d.). What’s a transit? NASA Science. https://science.nasa.gov/exoplanets/whats-a-transi

Grimm, S. L., Demory, B.-O., Gillon, M., Dorn, C., Agol, E., Bolmont, E., Delrez, L., Sestovic, M., Triaud, A. H. M. J., Turbet, M., Queloz, D., & Leconte, J. (2018). The nature of the TRAPPIST-1 exoplanets. Astronomy & Astrophysics, 613, A6. https://doi.org/10.1051/0004-6361/201732233

Fauchez, T. J., Turbet, M., Wolf, E. T., et al. (2020). The TRAPPIST-1 Habitable Atmosphere Intercomparison (THAI) Project: Motivation and overview. The Planetary Science Journal, 1(2), 17. https://doi.org/10.3847/PSJ/ab9ffd

de Wit, J., Wakeford, H. R., Lewis, N. K., et al. (2018). Atmospheric reconnaissance of the TRAPPIST-1 exoplanets with Hubble. Nature Astronomy, 2, 214–219. https://doi.org/10.1038/s41550-017-0374-z

Greene, T. P., Tamburo, P., Lustig-Yaeger, J., et al. (2023). Thermal emission from the TRAPPIST-1 system measured with JWST. The Astrophysical Journal Letters, 948(1), L6. https://doi.org/10.3847/2041-8213/acc1e5

Lustig-Yaeger, J., Grillmair, C. J., Stevenson, K. B., et al. (2023). JWST transit spectroscopy of TRAPPIST-1 c shows no evidence for a thick CO₂-rich atmosphere. Nature, 623, 71–75. https://doi.org/10.1038/s41586-023-06694-0

For this project, I built an Arduino robot that detects the proximity of an object. This robot uses sensors to understand its surroundings and gives an output. Even though there is no movement, it is still a robot because it senses its environment and acts upon it.

I built a proximity-sensing robot. It uses an ultrasonic sensor to measure how close an object is to the sensor. With this it will light up one of three LED lights.

• Green if object is in a safe distance
• Yellow if object is getting close
• Red if object is too close

At the same time it will turn a servo to a specific direction, representing an very oversimplified way of a car backing into a parking spot.

My idea is inspired by how parking sensors warn the driver how close they are to something when parking.

Virtual Prototype

Below is a video of my virtual prototype.

The circuit uses:

• A 4-pin ultrasonic sensor to measure distance through sound waves
• An Arduino Uno which is the brain behind the whole mechanism
• LEDs of three colours to represent distance

When the object comes closer, the Arduino calculates the distance of it by the difference between the time the sound wave is sent and when the echo is received. Then it lights up the specific LED based on the distance and turn the Servo to a specific direction.

Bill of Materials

• Arduino Uno R3 x1
• Ultrasonic Distance Sensor (4-pin) x1
• 220 Ω Resistor x3
• Green LED x1
• Yellow LED x1
• Red LED x1
• Positional Micro Servo x1

Code – how does the code work?

I learned how to code using Arduino from ChatGPT. I structured my code by starting with setting the wires, then using the Ultrasonic Sensor, and then lighting up the LEDs.

In this code snippet, the ultrasonic sensor is first set to low, then after 2 microseconds, it is set to high, then set back to low after 10 microseconds.

Here, pulseIn() measures how long it takes for the sound to travel to the object and back. 30000UL adds a timeout to make sure no errors occur. If duration==0 just restarts the code immediately if no object is detected.

This line is interesting because it turns time into distance. Sound travels at about 0.0343 cm per microsecond. It is divided by 2 because the sound goes to the object and then back.

This final code snippet tells the Arduino when to turn on which LED.

• Green if distance over 30cm
• Yellow if distance over 15cm
• Red if distance is less than that
• It also will turn the Servo to a rotation based on the distance to the object.

Physical Prototype

Unfortunately, due to the time constraint on this project, I did not make it to actually building the physical prototype.

Below is the circuit diagram.

Reflection

This was a fun project to do and it taught me a lot. I had never built anything with Arduino, but I’ve heard a lot about them. I used to do robotics in my old school for the VEX V5 Robotics Competition and that taught me a lot of the basic skills for robotics, which were helpful for this project and gave me a leg up in the beginning. However, this was much more realistic and complicated. In VEX, I found it much simpler because they had pieces to build the robots and very comprehensive coding. This was a much newer experience and made me learn a lot more.

When I was working on this project, the biggest problem I had was actually building the physical prototype. I originally thought I would have enough time, but when I didn’t, that presented a problem where I realized it would make my grade worse on the project, but I didn’t see anything to do. The other problem was that I wanted to include the whole car so it can back up. This was way too much work, so I simplified it to just including a microservo spinning to certain directions depending on the distance to the object to simulate the wheels of a car spinning.

AI Use & Transcripts

I used ChatGPT when I was building this project. It was useful to help me find a good idea for the project and to teach me how to code with Arduinos, which was new to me.

https://chatgpt.com/share/690cdb07-a204-8004-bded-d07880577438

https://chatgpt.com/share/690cdb8a-574c-8004-8c76-560ebe2d8a90