Project

# Title Team Members TA Documents Sponsor
16 Handheld Rocket Tracker
 Ben Olaivar
Manas Tiwari
Max Kramer
 Sanjana Pingali final_paper1.pdf
other1.pdf
proposal3.pdf
video
# Handheld Rocket Tracker

Team Members:
- Ben Olaivar (olaivar3)
- Max Kramer (mdk5)
- Manas Tiwari (manast2)

# Problem

Locating a rocket after a launch can be difficult. When the rocket reaches apogee (peak height), it deploys parachutes and glides back to the ground, often landing several miles away from the launch site (check out this video from the Illinois Space Society). Some tracking solutions exist, such as altimeters and radio beacons, however they all suffer from similar issues of being clunky, unintuitive, or expensive. Radio beacons don’t send out their exact location, and are tracked by following the strength of their signal, which only gives the general direction of the beacon. Altimeters send out their exact location, but are costly ($380+) and often require a laptop to receive their position, which is inconvenient to carry during a search. A few handheld trackers exist, however they are costly ($475+), difficult to reconfigure, and unintuitive. Additionally, all of these solutions are limited to 1 device.

# Solution

We want to make a 2-part tracking system: A tracking beacon (referred to as a “puck” or “beacon”), and a handheld tracking device (referred to as “tracker”). The beacon will be placed inside the rocket, and will continuously transmit its coordinates. On the receiving end, the tracker will compare its own GPS location with the coordinates from the beacon. To make this intuitive, the tracker will display the direction (using an arrow on the screen), as well as the distance to the beacon.

# Solution Components

## Subsystem 1: Microcontroller Processor (both beacon and tracker)
This will house the codebase for this project. This will mainly be to display to the screen of the tracker and handle button inputs by the user.

## Subsystem 2: TRACKING SENSORS
This subsystem consists of all required sensors/peripherals required for acquiring the location and direction from the tracker to the beacon
- **GPS Module (both):** To get longitude and latitude values of both components
- **GPS Antenna (both):** For connecting to satellites.
- **Magnetometer(tracker):** For measuring the heading of the user.

## Subsystem 3: COMMUNICATION SYSTEM
The entire project depends on successful communication between the beacon(s) and the tracker. Therefore we will need the following components to set up an ability for the tracker to search out certain frequencies and for the beacon(s) to send out the same frequencies.
- **Transceiver (both):** Required generating signal between beacon and tracker
- **Antenna (both):** Mid-ranged antenna capable of transmitting/receiving signals between 3-5 miles. Can be replaced in future with better antennas.

## Subsystem 4: BATTERY AND POWER SUPPLY
Create a battery management system that supplies consistent 3.3V to the necessary sensors and MCU.
- **LiPo Batteries (tracker):** 3.7V. Compact, have long battery life, and are readily available.
- **Voltage Regulator (tracker):** Regulating voltage from battery pack to sensors/MCU (3.3V)
- **Battery Holder (tracker):** Holding batteries

## Subsystem 5: DATA DISPLAY
This will simply be the screen we use to display all needed information for the user to track their beacons using the tracker
- **E-Ink Display:** For displaying compass, frequency, and distance data

# Criterion For Success

- Primary Criterion: Demonstrate that the “Beacon” or “Puck” can be found by an end user being guided by the “Tracker”’s on-screen information

- Additional Criterion: Demonstrate the ability to change frequency at which the “Beacon” and “Tracker” Communicate

# Github Link

https://github.com/ben-olaivar/ECE445_software

Electronic Replacement for COVID-19 Building Monitors @ UIUC

Patrick McBrayer, Zewen Rao, Yijie Zhang

Featured Project

Team Members: Patrick McBrayer, Yijie Zhang, Zewen Rao

Problem Statement:

Students who volunteer to monitor buildings at UIUC are at increased risk of contracting COVID-19 itself, and passing it on to others before they are aware of the infection. Due to this, I propose a project that would create a technological solution to this issue using physical 2-factor authentication through the “airlock” style doorways we have at ECEB and across campus.

Solution Overview:

As we do not have access to the backend of the Safer Illinois application, or the ability to use campus buildings as a workspace for our project, we will be designing a proof of concept 2FA system for UIUC building access. Our solution would be composed of two main subsystems, one that allows initial entry into the “airlock” portion of the building using a scannable QR code, and the other that detects the number of people that entered the space, to determine whether or not the user will be granted access to the interior of the building.

Solution Components:

Subsystem #1: Initial Detection of Building Access

- QR/barcode scanner capable of reading the code presented by the user, that tells the system whether that person has been granted or denied building access. (An example of this type of sensor: (https://www.amazon.com/Barcode-Reading-Scanner-Electronic-Connector/dp/B082B8SVB2/ref=sr_1_11?dchild=1&keywords=gm65+scanner&qid=1595651995&sr=8-11)

- QR code generator using C++/Python to support the QR code scanner.

- Microcontroller to receive the information from the QR code reader and decode the information, then decide whether to unlock the door, or keep it shut. (The microcontroller would also need an internal timer, as we plan on encoding a lifespan into the QR code, therefore making them unusable after 4 days).

- LED Light to indicate to the user whether or not access was granted.

- Electronic locking mechanism to open both sets of doors.

Subsystem #2: Airlock Authentication of a Single User

- 2 aligned sensors ( one tx and other is rx) on the bottom of the door that counts the number of people crossing a certain line. (possibly considering two sets of these, so the person could not jump over, or move under the sensors. Most likely having the second set around the middle of the door frame.

- Microcontroller to decode the information provided by the door sensors, and then determine the number of people who have entered the space. Based on this information we can either grant or deny access to the interior building.

- LED Light to indicate to the user if they have been granted access.

- Possibly a speaker at this stage as well, to tell the user the reason they have not been granted access, and letting them know the

incident has been reported if they attempted to let someone into the building.

Criterion of Success:

- Our system generates valid QR codes that can be read by our scanner, and the data encoded such as lifespan of the code and building access is transmitted to the microcontroller.

- Our 2FA detection of multiple entries into the space works across a wide range of users. This includes users bound to wheelchairs, and a wide range of heights and body sizes.