Project

# Title Team Members TA Documents Sponsor
71 Power Rack Occupancy System
Benjamin Wang
Brandon Ramos
Cooper Ge
Vassily Petrov design_document1.pdf
design_document2.pdf
design_document3.pdf
final_paper1.pdf
proposal2.pdf
proposal1.pdf
# Problem
Power racks are often the most important piece of equipment at a gym for an individual’s work out. Due to the popularity of the equipment, it is pretty rare to find an empty rack at either CRCE or the ARC at most convenient workout times. Busy students who can only go to the gym on a tight time schedule are often met with the frustration of just standing around waiting for a rack to open up with no established method for who gets the next available rack. As it stands, there is no system in place to monitor the occupancy of the power racks, no system for being notified when there are empty power racks, and no way of determining how long someone’s been using a power rack.

# Solution Overview
We propose a grid of sensor systems that rests on the bar holders of the power racks in a gym to detect occupancy of the power rack, how long the exercise has been performed and provides an online interface for viewing this information for all the equipped power racks at the gym. By making this information available to students, our system can provide the following quality of life improvements to the gym-going experience:
- Gauge how many racks are available for use
- Be politely notified of when they are using the power rack for an inordinate amount of time
- Have access to a method of being notified when there are available power racks

We believe that by designing a system that can be installed on any power rack with minimal hardware modification that is connected to a central processing unit with an arbitrary amount of connections, modern gyms would find this as a realistic service to implement.

# Solution Components
Our system will consist of two primary design components and a web design: a processing unit (likely a single board computer or microcontroller) to aggregate the data and act as a data source for the web server, a sensor system to collect data on how the power rack is being used, and a web front end that allows individuals to interact with the data and subscribe to a notification system for empty power racks.



## Processing Unit
This subsystem must be able to collect data from each of sensor-equipped power racks (possibly wirelessly over WiFi), process/organize it, and send it to our web database (likely Google’s Firebase).

## Sensor System
This subsystem must be durable enough to survive on the power rack, able to provide information to the individual using the power rack, able to transmit data to the central processing unit, and detect if the power rack is being used. There we divide the system by the three system specifications.

### Detecting rack occupation
We will be using infrared sensors to detect human movement, an accelerometer to detect bar movement, and pressure sensors for detecting rack-use and weight loads on the rack.

### Human interface system
We’d like to be able to provide visual alerts to the individual using the power rack such as how long they’ve been using the power rack. This will likely utilize an LCD with light indicators to denote time information.

### Transmission system
This system must be able to poll the sensors for detecting rack occupation and send it to the central processing unit. There is a good deal of flexibility in the communication protocol that will be used but WiFi seems most likely.

## Web framework
We would like to provide individuals with the ability to access our data regardless of mobile platform, so we believe a web page is the best choice for users to interface with the system. This web system must allow individuals to view the power rack data for a given gym and allow users to enlist into the notification system. When the system detects an empty rack, all users within the notification system will be notified. Likewise, they are able to remove themselves anytime. The notification system can be implemented with SMS using APIs like Twilio.

# Criterion for success
- Successfully transmit power rack usage data from multiple power racks to be displayed on a web page.
- Implement a working notification system to notify users of empty racks
- Accurately identify when a power rack is in use and how long it has been in use

Control System and User Interface for Hydraulic Bike

Iain Brearton

Featured Project

Parker-Hannifin, a fluid power systems company, hosts an annual competition for the design of a chainless bicycle. A MechSE senior design team of mechanical engineers have created a hydraulic circuit with electromechanical valves, but need a control system, user interface, and electrical power for their system. The user would be able to choose between several operating modes (fluid paths), listed at the end.

My solution to this problem is a custom-designed control system and user interface. Based on sensor feedback and user inputs, the system would change operating modes (fluid paths). Additionally, the system could be improved to suggest the best operating mode by implementing a PI or PID controller. The system would not change modes without user interaction due to safety - previous years' bicycles have gone faster than 20mph.

Previous approaches to this problem have usually not included an electrical engineer. As a result, several teams have historically used commercially-available systems such as Parker's IQAN system (link below) or discrete logic due to a lack of technical knowledge (link below). Apart from these two examples, very little public documentation exists on the electrical control systems used by previous competitors, but I believe that designing a control system and user interface from scratch will be a unique and new approach to controlling the hydraulic system.

I am aiming for a 1-person team as there are 6 MechSE counterparts. I emailed Professor Carney on 10/3/14 and he thought the general concept was acceptable.

Operating modes, simplified:

Direct drive (rider's pedaling power goes directly to hydraulic motor)

Coasting (no power input, motor input and output "shorted")

Charge accumulators (store energy in expanding rubber balloons)

Discharge accumulators (use stored energy to supply power to motor)

Regenerative braking (use motor energy to charge accumulators)

Download Competition Specs: https://uofi.box.com/shared/static/gst4s78tcdmfnwpjmf9hkvuzlu8jf771.pdf

Team using IQAN system (top right corner): https://engineering.purdue.edu/ABE/InfoFor/CurrentStudents/SeniorProjects/2012/GeskeLamneckSparenbergEtAl

Team using discrete logic (page 19): http://deepblue.lib.umich.edu/bitstream/handle/2027.42/86206/ME450?sequence=1