Project

# Title Team Members TA Documents Sponsor
24 Grounded Rope Management System for Belaying
Abhyan Jaikishen
Chris Zhang
Daniel Hsu
Jason Paximadas design_document1.pdf
final_paper2.pdf
photo5.jpg
photo6.jpg
photo7.jpg
photo8.jpg
presentation2.pdf
proposal1.pdf
video
# Team members:
Abhyan Jaikishen (abhyanj2)

Chris Zhang (czzhang3)

Daniel Hsu (sehsu2)


# Problem:
When top-rope climbing outdoors or indoors, a climber requires a second person to belay to prevent large falls and minimize injuries. The belayer is responsible for maintaining slack and tension in a rope that is anchored at the top of the climb. As the climber moves up, the belayer reduces the slack of the rope to ensure that if the climber were to fall, the rope would catch them before dropping a dangerous amount. However, it is not always feasible to have a partner to belay you, especially for more spontaneous or frequent climbing.

# Solution:
We propose a ground-based rope management device. There exist auto-belays on the market, but these are very expensive, as well as usually anchored at the top of the wall, which makes them impractical for most outdoor and spontaneous usage. Our system would utilize a grigri (belayer rope management tool), combined with motors and sensors that are able to keep tension on the rope as the climber ascends, and lower the climber when they want to come down.

# Solution Components

- Motors: electric motors to act as the 2 “hands” of the belaying mechanism. These motors do not need to be strong enough to pull an entire human, since they only need to manage the rope, not anchor the climber.
- Servo for descent control: Small, low power servo will be needed to release level on grigri for descent.
- Tension/Force Sensors: Sensors will be needed to detect the amount of tension the rope is facing. Two possible ways to do this, either measure the resistance the motor encounters when taking too much slack away, or utilize tension sensors (something like a YZC-516C sensor)
- Wireless module: For the climber to be able to communicate with the belay system (tell it to lower/hold) remotely through remote control or app. Something like: CC2541 Bluetooth Wireless Module EBYTE RF Module

# Subsystem 1: Power
Will utilize standard wall outlets for power and take the necessary steps to supply motors, pcb, and other components with the correct amount. If time permits, utilizing a battery would be beneficial for outdoor use cases.

# Subsystem 2: Physical Grigri Control
Aforementioned motors will act as belay and guide hands to feed rope through grigri on both ends. A structure containing motor mounts and rope bends for the tension sensors will need to be created to house the main structure. This subsystem will be operated by subsystem 3.

# Subsystem 3: Processor and Communication
Mounted near or on the motor structure, we will house a PCB and other relevant components/controllers to read and analyze incoming data from motors and sensors. This is also where our wireless module will be contained. This subsystem will be responsible for collecting, processing, and transmitting relevant data for proper control of the grigri.

# Subsystem 4: Remote Control
Using the wireless module we decide on, a remote control will be used to determine the lowering and stopping of the rope. This subsystem may be physical, or simply utilize the data sent by the wireless module and process it via an App.

# Criterion for Success
System can detect and manage the slack in the rope properly as climber climbs
System can hold or lower climber while on wall
System can safely support climber’s fall
User can control belay remotely using remote control (or app TBD)

# Safety concerns
We intend to take full precautions against any dangers when testing and demoing the system.
We will have someone attached with a grigri behind the belay system. This way, in the event our project fails, the 2nd manually operated grigri will be able to catch the falls safely. Climbers often use this technique (a 2nd belayer), when first learning how to belay.

To eliminate all safety concerns, we will never climb above a height from which a freefall would be dangerous. Moreover, we intend to take advantage of the mats provided at all rock climbing facilities (crashpads), to ensure that even the small drops will pose no risk.

# Relevant links:
Grigri operation: https://www.youtube.com/watch?v=BAxY-BBSlGc
Double grigri system for testing: https://www.youtube.com/watch?v=jKe72j_mBlU

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.