Project

# Title Team Members TA Documents Sponsor
17 Habit Forming Key Station
Ali Husain
Cedric Mathew
Yuxuan Ma
Abhisheka Mathur Sekar design_document2.pdf
final_paper1.pdf
photo1.png
photo2.jpeg
presentation1.pdf
proposal2.pdf
video
# Team Members:
- Ali Husain (alijh2)
- Cedric Mathew (cmathe26)
- Marsh Ma (yuxuanm4)

# Problem

People have a difficult time building habits. Specifically, a common issue that many have is losing or misplacing their keys/wallet whenever they enter their place of residence. If they were accustomed to placing and grabbing their keys from a specific designated location, then the likelihood of losing their keys and wallet would be significantly low.

# Solution

Our solution utilizes negative reinforcement to build positive habits for its users. We will build a designated station for placing one’s keys, or any small item of their choosing, when entering or leaving their home. It will begin detecting the proximity of the keys a few minutes after the keys have initially been removed from the dish, indicating the resident is not home. Once the resident returns home with the keys, a sensor should detect its presence with an RFID tag and continue ringing an alarm through a speaker until the keys are placed correctly. There will be a pressure sensor at the bottom of the dish that will indicate whether the keys have been put into the device. Our solution will have 5 subsystems: proximity detection, control and processing, alarm, confirmation, and power.

# Solution Components
## Subsystem 1: Proximity Detection Subsystem
This subsystem is responsible for detecting the presence of the keys when they are in close proximity to the station. It will use an RFID system comprising an RFID reader inside of the dish and an RFID tag attached to a keychain that the user will carry. When the RFID reader senses the tag, it triggers the alarm system. We will use the MFRC522 RFID Reader (Part No: MFRC522) and compatible RFID tags.

## Subsystem 2: Control and Processing Subsystem
The core of our project, this subsystem processes inputs from the Proximity Detection Subsystem and controls the Alarm Subsystem and Confirmation Subsystem. With the input from these three subsystems, we can compute whether the alarm needs to ring or not. When the user leaves with the keys, it will wait a few minutes before activating the proximity subsystem. This will await the RFID tag to come within proximity. Once detected, it will prompt the alarm subsystem to ring. Once it receives notification from the confirmation subsystem that the keys have been placed in the dish, the alarm will turn off. We will use ATmega2560 (https://www.microchip.com/en-us/product/atmega2560# ) as our microcontroller chip.

## Subsystem 3: Alarm Subsystem
Activated by the Control and Processing Subsystem, this subsystem emits an audible alarm when the keys are detected but not yet placed in the station. It consists of a small alarm or speaker, like the Piezo Buzzer (Part No: PSE-2907), that generates a distinct sound, prompting the user to place the keys in the designated spot. When the user places their keys in the dish, it will promptly turn off.

## Subsystem 4: Confirmation Subsystem
This subsystem confirms the placement of the keys in the station. It uses a pressure sensor/button at the bottom of the station, which, when pressed by the weight of the keys, signals the Control and Processing Subsystem to deactivate the alarm.
We plan to use the Thin Film Pressure Sensor (Part No: SEN-09376).

## Subsystem 5: Power Subsystem
This subsystem provides power to the device. We plan on using a 9V battery to power the device, as we need a power source that can last for several weeks at a time while also maintaining lightweight portability.

# Criterion For Success

1. The proximity detection subsystem can reliability detect keys within 15 feet of the dish
2. The alarm subsystem projects within 80-90dB (the standard level of an alarm clock) so it may be heard outside the room
3. The confirmation subsystem can detect a change in the weight of at least 20 grams which is the expected weight of 1 key and our keychain
4. The microcontroller accurately sends and receives signals from the subsystems 100% of the time
5. The power subsystem provides adequate power to the device with a multi-week battery life

Prosthetic Control Board

Caleb Albers, Daniel Lee

Prosthetic Control Board

Featured Project

Psyonic is a local start-up that has been working on a prosthetic arm with an impressive set of features as well as being affordable. The current iteration of the main hand board is functional, but has limitations in computational power as well as scalability. In lieu of this, Psyonic wishes to switch to a production-ready chip that is an improvement on the current micro controller by utilizing a more modern architecture. During this change a few new features would be added that would improve safety, allow for easier debugging, and fix some issues present in the current implementation. The board is also slated to communicate with several other boards found in the hand. Additionally we are looking at the possibility of improving the longevity of the product with methods such as conformal coating and potting.

Core Functionality:

Replace microcontroller, change connectors, and code software to send control signals to the motor drivers

Tier 1 functions:

Add additional communication interfaces (I2C), and add temperature sensor.

Tier 2 functions:

Setup framework for communication between other boards, and improve board longevity.

Overview of proposed changes by affected area:

Microcontroller/Architecture Change:

Teensy -> Production-ready chip (most likely ARM based, i.e. STM32 family of processors)

Board:

support new microcontroller, adding additional communication interfaces (I2C), change to more robust connector. (will need to design pcb for both main control as well as finger sensors)

Sensor:

Addition of a temperature sensor to provide temperature feedback to the microcontroller.

Software:

change from Arduino IDE to new toolchain. (ARM has various base libraries such as mbed and can be configured for use with eclipse to act as IDE) Lay out framework to allow communication from other boards found in other parts of the arm.