|1||CHARM: CHeap Accessible Resilient Mesh for Remote Locations and Disaster Relief
|Jeff Chang||Viktor Gruev||design_document1.pdf
|# CHARM: CHeap Accessible Resilient Mesh for Remote Locations and Disaster Relief
- Martin Michalski (martinm6)
- Trevor Wong (txwong2)
- Melissa Pai (mepai2)
There are many situations in which it is difficult to access communicative networks. In disaster areas, internet connectivity is critical for communication and organization of rescue efforts. In remote areas, a single internet connection point often does not cover an area large enough to be of practical use for institutions such as schools and large businesses.
To solve these problems, we would like to create a set of meshing, cheap, lightweight, and self-contained wireless access points, deployable via drone. After being placed by drone or administrator, these access points form a WiFi network, usable by rescuers, survivors, and civilians. Our network will have QoS features to prioritize network traffic originating from rescuers. Having nodes/access points deployable by drone ensures we are able to establish timely connectivity in areas where search and rescue operations are still unable to reach.
Over the course of the semester, we will produce a couple of prototypes of these network nodes, with built in power management and environmental sensing. We aim to demonstrate our limited network’s mesh capabilities by setting up a mock network on one of the campus quads, and connecting at various locations.
# Solution Components
## Router and Wireless Access Point
Wireless Access for users and traffic routing will be the responsibility of an Omega2 board, with onboard Mediatek MT7688 CPU. For increased signal strength, the board will connect to a RP-SMA antenna via U.FL connector.
The Omega2 will be running OpenWRT, an Linux-based OS for routing devices. We will develop processes for the Omega2 to support our desired QoS features.
## Battery Management System
This module is responsible for charging the lithium-ion battery and ensuring battery health. Specifically, we will ensure the battery management system has the following features:
- Short circuit and overcurrent protection
- Over- and under-voltage protection
- An ADC to provide battery status data to the microcontroller
- 3.3v voltage regulation for the microcontroller and other sensors
In addition to miscellaneous capacitors and resistors, we intend to use the following components to implement the battery management system:
- The MT2492 step-down converter will be used to step down the output voltage of the battery to 3.3 volts. Between the GPS and extra power the microcontroller might consume with an upgraded Wifi antenna, low-dropout regulators would not provide sufficient power in an efficient manner. Instead, we will implement a 2 amp buck converter to improve efficiency and ensure there are no current bottlenecks.
- We will utilize two button-top protected 18650 3400 mAh lithium ion batteries in series to power each node. Placing two of these batteries in series will ensure their combined voltage never falls below the minimum voltage input of the buck converter, and accounting for the buck converter’s inefficiency these batteries should give us about 21 Wh of capacity. The cells we plan on using include a Ricoh R5478N101CD protection IC that provides over-voltage, under-voltage, and over-current protection. Using a standard battery form factor will make them easy to replace in the future as needed.
- A USB-C port with two pulldown resistors will provide 5 volt charging input with up to 3 amps of current, depending on the charger.
- The MT3608 step-up converter will boost the input voltage from the usb-c port and feed it into the charging controller.
- The MCP73844 Charge Management Controller will be used to charge the batteries. This controller supports CC/CV charging and a configurable current limit for safe and effective battery charging.
- The TI ADS1115 ADC will be used for battery voltage monitoring. This chip is used in the official Omega2 expansion board, so it should be easy to integrate in software. We will use a voltage divider to reduce the battery voltage to a range this chip can measure, and this chip will communicate over an I2C bus.
## Sensor Suite
Each node will have a battery voltage sensor and GPS sensor, providing the system with health information for each node. On top of the Wifi-connectivity, each module would have a series of sensors to detect the status of the physical node and helpful environment variables. This sensor suit will have the following features and components to implement it
- Ultimate GPS Module PA1616D will be used for positioning information. This chip utilizes 3.3V which is supplied through our battery management system.
Battery Voltage Monitor
- The TI ADS1115 ADC (mentioned in the BMS section) is for battery voltage monitoring. It interfaces via I2C to the Omega2.
## System Monitor
A system monitor which provides visibility of the overall system status for deployed network nodes. Information that we will show includes: last known location, battery health, and network statistics (e.g. packets per second) from the physical devices.
We plan on using React to provide an intuitive UI, using google-map-react and other React packages to create an interactive map showing the last known location and status of each node.
The backend will be hosted on a server in the cloud. Nodes will continually update the server with their status via POST requests.
# Criterion For Success
We aim to achieve the following performance metrics:
- 1.5 kg maximum mass
- Cover 7500 m^2 (North Quad) with 4 nodes
- Display the last known location, time connected, and battery voltage for all nodes via our system monitor
- 3 hour battery life
- 5 Mb/s WiFi available to laptops and smartphones in the coverage area
[*Link*](https://courses.engr.illinois.edu/ece445/pace/view-topic.asp?id=71252) *to assciated WebBoard discussion*
|2||HARDWARE ACCELERATED PANORAMA IMAGE STITCHING CAMERA ON EMBEDDED LINUX
|Qingyu Li||Kejie Fang||design_document1.pdf
- Gautum Pakala (gpakala2)
- Cole Herrmann (colewh2)
- Jake Xiong (yuangx2)
Time and energy are resources that aren't plentiful in UAVs. Traditionally when a UAV is used for aerial mapping, it will take a picture every time it flies a predetermined distance interval. Since UAVs must be kept lightweight, it’s uncommon to find any with enough onboard processing hardware and energy reserves to stich hundreds of frames into a map. That’s why most mapping UAVs perform the map generation offsite on more powerful hardware than the onboard camera and flight controller. In time sensitive emergencies (open combat, search and rescue, etc), it may not be possible to land the UAV to render an aerial map, and it would be much more convenient if the drone could render the map itself, which could be viewed on a ground station through a UDP radio link.
We would like to design a camera that has onboard hardware acceleration capability to stitch images together. When stitching images together into a panorama or map, several repetitive operations are required to "prep" the images for stitching. Operations to greyscale, blur, and convolute images can be performed on a traditional CPU, but the processing time and power consumption can be improved when such repetitive operations are pipelined through an FPGA. With Cole’s ECE 397 funding from last semester, he acquired a Diligent Embedded Vision bundle (https://digilent.com/shop/embedded-vision-bundle/), which we plan on using the Zybo Z7020 and PCAM 5C as the basis for the camera. The Zybo board comes with two A9 processor cores which can run Xilinx's Embedded Linux distro called PetaLinux. By running PetaLinux on the camera, I have easier access to the I/O and filesystem on the Zybo board rather than trying to create a baremetal design. After completing this project, I plan to integrate the camera into one of my drones, including adding serial communication between the flight controller and the Zybo board (another pro of building on PetaLinux), which would give access to a plethora of sensors such as GPS, airspeed, etc that could bring a live rendering aerial mapping drone into reality!
# Solution Components
## Subsystem 1: Keypoint Detection/Description, and Matching
As mentioned before, the development of this projecet will be done on the Zybo board that has the embedded Linux environment. The majority of code base and algorithms below would be written in SystemVerilog for the hardware portion. There may be some image pre-processing done in the Linux environment if that is easier to implement.
All image stitching for panoramas has 3 main processes: Keypoint Detection/Description, Keypoint matching, and Homography
Keypoint Detection is the process of identifying keypoints in an image that are recognizable from different angles, lighting, and scale. Many computer vision algorithms accomplish this goal such SIFT, SURF, and FAST to name a few. We are choosing to implement the FAST algorithm for keypoint detection, not just because it is faster than most other algorithms, but also because it is the least resource intensive for the FPGA to execute. These algorithms already take into account scale and rotational invariance for the images.
Keypoint Description gives each identified keypoint a unique descriptor that can be used to identify each keypoint on the image. Again, there are many methods of doing this, but the simplest is to compile a matrix of the gradient vectors around each keypoint that can be obtained through convolving the image with specific filters.
Keypoint matching occurs when the keypoints are detected and described in each image. If the difference between the descriptors is below a certain error threshold, the keypoints in each image are said to be a match. Typically, a minimum of 4 keypoint matches is needed for Homography Transformation.
## Subsystem 2: Homography Transformation
When image stitching, the angle of the images needs to be rectified to create a clean output panorama. Homography Transformation is a common problem that transforms the coordinate system of an image into the plane of the reference image through a 3x3 homography matrix. The homography matrix can be calculated using the keypoint matches matrix and solving a constrained least squares problem in order to find the eigenvector with the lowest eigenvalue. This transformation is then applied. One issue with the homography transformation is that the result can be skewed with outliers in the keypoint matching process, where there are keypoint matches detected, but they are not really matches. A common solution to any outlier problem like this is the RANSAC algorithm. This is easily transferrable to hardware and can be used to make the computation of the homography matrix more robust. After the images are warped (transformed) and overlapped, there may be some image blending required for a cleaner result which can be done in the Linux environment.
## Subsystem 3: HDMI Output
HDMI output is a system that operates with the TMDS protocol. There have been plenty of people who have created image renderers for HDMI. Our goal is to be able to transfer the image that is being processed in the accelerator through an HDMI renderer we design and output to the HDMI port for an instantaneous results viewer. If the process of creating the accelerator is too long, it would be simpler to host a webserver and display the image in the Linux the environment.
# Criterion For Success
Due to the time limited nature of ECE 445, we will not have enough time to write a full mapping application on PetaLinux, and fully integrate it into the UAV’s PX4 cube flight controller. With this in mind, we plan on building a simpler application that can create panoramas and render them once they are fully processed. At minimum, we would like to have our camera be able to generate a panorama from three frames side by side. We also have to have a way to view the final panaorma, which will either be a low level solution from the TMDS video port on the Zybo board, or high level solution where it’s hosted on a local webpage(PetaLinux already has support for hosting web pages).
|3||Robotic Manipulator with User Force-Feedback
|Jason Paximadas||Viktor Gruev||design_document1.pdf
|Robotic Manipulator with User Force-Feedback
- Sohan Patel (sohankp2)
- Noah Franceschini (nef3)
A common need in Industry, and especially in today's increasingly virtual world is to interact with objects where it may not be possible from a logistic or health standpoint to do so. We have robotic manipulators and virtual simulations, but there is still a huge gap between real life and these current solutions. In a setting where an object is hazardous and may be fragile, it is paramount to be able to control how much pressure one is applying to the object, and be able to adjust it quickly and in a way that feels natural.
We would like to make two devices that work together to solve this issue. We want to create a manipulator that mirrors the user's movements and can accurately communicate the amount of force being exerted back to the user. The user would wear a glove that can track each finger's movement independently and apply the force experienced by the manipulator back to the user's hand. This would allow the wearer to easily discern the amount of force they are applying to an object without actually touching it themselves. This both solves the issue of being able to quickly and easily feel the force they are applying, as well as increasing user immersion, as wearing a glove is much more natural than using a different control mechanism. It would also allow a user to differentiate between objects quickly, for example the feeling of a foam ball vs a solid one.
This subsystem will be what the user actually wears, and will both track movements of each finger as well as apply the forces back to the wearer. It will need to support a wide range of resistance to motion, from light resistance as if one was squishing a foam ball, to being able to fully stop the fingers from moving
- Potentiometers or Flex sensors to determine the position of the user's fingers, will experiment with both
- Small motors to provide the required resistance to the fingers, or arrest movement entirely.
This subsystem will be what interacts with the object and relays resistance encountered by it to the glove. The manipulator itself will be 3D printed from an inexpensive plastic such as PLA.
- Small servos modified with low resistance shunt resistors to allow us to measure current, this allows us to know how much resistance each finger is encountering.
- 3D printed robot "hand" that has all the supporting structure needed to mount the electronics.
This is the brain of our project, it will be a microcontroller based device that can process the raw data coming from both the glove and manipulator, then facilitate the communication between the two.
- Microcontroller, ATmega328p or ATmega2560
- Stepper motor drivers
- Drivers for the user force-feedback, in the form of a motor and controller combination that can support dynamically adjusting the amount of tension.
**Criterion For Success**
- Track each finger and have the robot mirror those movements
- Measure the forces experienced by the manipulator
- Apply those forces to the user's hand
- Support resistance as well as stopping hand movement
- The user should be able to differentiate between a force caused by a solid object, vs one generated by a soft object compressing. The glove should not try and stop all movement in the latter case.
- Low latency operation, the manipulator should not have a delay more than .5 to 1 second.
|4||Bluetooth Enabled eWalker
|Akshatkumar Sanatbhai Sanghvi||Arne Fliflet||design_document1.pdf
|# Bluetooth Enabled e-Walker
- Lukas Adomaviciute (lukasa3)
- Darren Domingo (ddd3)
- Gregory Tow (gtow2)
Walkers are primarily used by people over 65 years old with musculoskeletal or neurological problems. Some conditions that require a person to use a walker include arthritis and Parkinson's disease. When a person uses a walker, one or both hands are occupied supporting themselves with the walker which makes it more difficult for the user to access their smartphone's features. In recent years more devices have become smart devices paired with our smartphones for additional features, but walkers and walking canes have been left behind. When looking for existing solutions, we have found some canes that support lighting and charging, but none with IoT. We believe this would be the next logical step in innovation to support people with conditions that struggle to interface with touch screen displays.
We would like to bridge the gap between features that would be used on a smartphone to the walker itself. It would be particularly useful to implement an easily accessible contact system on the walker that could be used in an emergency situation where time is of the essence and the user might struggle to use their smartphone.
# Solution Components
## Walker Construction
- Walker itself
- 3D-printed electronic component housing
- Phone mount
Our solution will be constructed onto a standard folding walker with two forward facing wheels. We plan on constructing a 3D printed housing that will contain the required electronic components. The electronic component housing will attach to the walker below the hand rests and should be positioned in a manner that does not put restraints on the folding machinism or interfere with walking. We also would like to add a physical phone mount to the walker so the smartphone microphone and display can optionally be utilized when the walker’s systems are triggered.
## Communication and Interfacing (IoT)
- 3 contacts - 911, Main (call, text), Backup (call,text)
- Arduino Reader to read in the phone numbers and map those to specific buttons on the walker
- Pressing a button will trigger an automated text or a call through the connected phone through bluetooth
- NFC Readers to store information such as phone numbers or automated texts
Our primary goal for communication and interfacing is to configure a five button system that will allow the user to quickly send text message notifications or preconfigured phone calls through BlueTooth once the device has been paired with their smartphone. One button will be preconfigured for an emergency 911 call. Two buttons can be configured for emergency contact phone calls with phone numbers that can be written by the user. Two buttons can be configured for emergency contact text messages with the contact and message content written by the user. Our group discussed utilizing an NFC reader to store the configured phone contact numbers, text contact numbers, and text message content. The user should be able to utilize an NFC writing app on their smartphone to write the required data to the walker controller. We plan on implementing this system by utilizing an Arduino for BlueTooth communication. We currently plan on utilizing the Arduino RFID module to communicate with the smartphone and read the data written from the user’s smartphone. After the implementation of the button configuration, our group will continue to implement more IoT functionality.
Our Arduino control system will utilize information from our gyroscope sensor to identify when the walker is in a horizontal position or when the walker is on a downwards incline. When the gyroscope indicates the walker in a horizontal position it will utilize the communication and interfacing subsystem to send a text notification that a fall has occurred to the preconfigured button contacts. The control system will also use information from the GPS to text the user’s location to preconfigured contacts in emergency situations.
## Power Management
- Power to Arduino System,
- Integrated USB port for charging internal battery
- Battery Life Indicator
The power management subsystem handles how power is distributed throughout the entire system. We will use an internal rechargeable battery as the main source of power. In order to charge other devices while providing power to the Arduino system, we will make use of a step up DC-DC converter. To turn on the entire system, a power switch will be used in line with the connection to the DC-DC converter, with an appropriate fuse in the positive terminal to prevent damage to the rest of the circuit in the case of a battery issue. To charge the battery, we will use an integrated USB Type C port which connects to the battery. To charge devices, we will use two integrated USB Type A ports connected to the battery which will support quick charging. Lastly, to monitor the charge of the battery, we will make use of LEDs and a LM3914 chip or similar to display the charge status in a color bar approach.
# Criterion For Success
We plan to test if our walker charges properly and if it can be turned on and off. The two charging ports will be tested as well. We will also be ensuring that the walker will be able to make calls and send texts through the push buttons we will have. The text messaging test will also confirm that the GPS is working. Lastly for the gyroscope, we will confirm that it knows the exact orientation our walker is in, and that the text messaging system sends out the proper severity of text.
|5||Efficient Light Control system for Plant Growth
|Zhicong Fan||Kejie Fang||design_document1.pdf
|Efficient Light Control System for Plant Growth
- SungJoo Chung (sungjoo2)
- Christelle Seri (seri2)
- Heonjang Lee (hl8)
Controlling the light intensity into a room can be important to plant growth. Artificial UVA lights have proven to be an effective solution to growing plants indoors. However, over time, the electricity costs will begin to add up.
We propose an energy efficient blind system with UVA lights as a solution. A sensor would be placed on the plant vase to measure the amount of light received. The blinds would adjust so as to optimize the amount of light to the plant. The UVA lights will turn on when the maximum sunlight from the blinds is insufficient.
Thus the UVA lights would only be used when strictly necessary, cutting down on electricity costs as a result. Additionally, the blind system could be scheduled and adjusted to user needs as well.
This system will be easily controlled by a user using a mobile application, and also statistics will be provided on the application.
# Solution Components
Blinds with motors
## Blinds with Motors
We have decided to use the servo motor for our project because of its precision and feedback capabilities. A crucial part of our project is to adjust the angles of the blinds based on its current position and the amount of lights the plants are receiving. In order to do so, it needs a closed-loop feedback system, which the servo motor has. Currently, we are considering using the MG995 RC Servo Motor. This motor will be powered by the microcontroller that we will be implementing for the solution. Using these motors, the blinds will be either tilted or raised/lowered.
## UVA Lights
The UVA lights will be connected to and controlled by a ESP32-WROOM-32E microcontroller. The microcontroller will communicate with the photosensor subsystem and adjust the UVA lights accordingly. The microcontroller we plan to use will have bluetooth and wifi capabilities. As the main purpose of this system is to conserve energy by controlling the brightness of the UVA light in conjunction with sunlight, we will be using a dimmable black-bulb from Green Creative, which works by emitting UV lights, as a source of UVA lights for the plants.
We plan to use photo sensors to sense the amount of incoming ambient light. The photosensors will be connected to another ESP3 which will read and transmit the light intensity data. Multiple photosensors should be well positioned in the vase to minimize the discrepancy of the data. We will be using the TSL2561 Luminosity Sensor for the project as it is precise, small in size and compatible with microcontrollers.
User has to set the intensity and duration of light using this app.
It will also continuously collect the light intensity information from the photosensors and save in the database.
Using the user-defined configuration and collected illumination data, the app will apply an algorithm to control the blind adjustment system and UVA lights.
The application will also aggregate the log daily and provide the statistics about the system including how much of power was saved from the system.
App will be built using React Native and the backend server will run in the AWS.
# Criterion For Success
Regardless of the weather conditions, the system should be offering a constant amount of light for a requested amount of time.
The photosensors on the vase should correctly calculate the illumination on the plant to minimize the discrepancy between the actual illumination on the plant and the collected data
The application should have a enough number of modes to cover various types of plants including cactus, tropical plants, conifers, etc
|Mingjia Huo||Arne Fliflet||design_document1.pdf
Sleep bruxism, more commonly known as tooth grinding, is a condition where one grinds or clenches their teeth unconsciously while sleeping. Depending on the particular study, anywhere from 10-30% of the population can be affected by this condition. Should bruxism be severe and frequent enough, it can lead to jaw disorder(s), headaches, damaged teeth, and other problems. There is not one singular cause for bruxism and as such, current solutions act more as a temporary measure to minimize damage rather than address the issue itself. For example, common dental solutions include using a mouth guard and, in some cases, undergoing dental correction. Similar to treatments, medication serves mostly as a reactionary measure where they attempt to address issues and complications that arise from bruxism.
# Solution Overview
The goal of this project is to develop a two part system: detection and prevention. The main objective is to take on a more active role of addressing the condition rather than addressing consequences of the condition. The detection part will consist of a variety of sensors and the prevention part will have user feedback and data processing/storage.
# Solution Components
## Detection System
### EMG Circuit
We plan to use an EMG (electromyography) circuit to detect muscle contraction of the jaw. The data coming out of said circuit would be processed through an ADC and then be saved into a micro-controller in order to be viewed later.
A mapping will need to be created in order to translate the data into a readable format and useful data for later viewing. Most likely, we will create a feature that will transmit this data to a PC.
## Prevention System
Should teeth clenching be detected, an alarm system and a muscle stimulator will be activated. The muscle stimluator aims to relax the muscles around the jaw.
## Power Subsystem
The entire system will be powered through an outlet in the wall given the fact that the system should optimally be on through an entire night and ideally for multiple nights in a row.
# Criterion for Success
Demonstration can include a participant grinding their teeth, getting feedback from the prevention portion of the system, and then viewing the data after. Criterion for success would simply be the aforementioned steps working as intended.
|7||Microcontroller-based Occupancy Monitoring (MOM)
Vish Gopal Sekar
|Hanyin Shao||Arne Fliflet||design_document1.pdf
|# Microcontroller-based Occupancy Monitoring (MOM)
- Franklin Moy (fmoy3)
- Vish Gopal Sekar (vg12)
- John Li (johnwl2)
With the campus returning to normalcy from the pandemic, most, if not all, students have returned to campus for the school year. This means that more and more students will be going to the libraries to study, which in turn means that the limited space at the libraries will be filled up with the many students who are now back on campus. Even in the semesters during the pandemic, many students have entered libraries such as Grainger to find study space, only to leave 5 minutes later because all of the seats are taken. This is definitely a loss not only to someone's study time, but maybe also their motivation to study at that point in time.
We plan on utilizing a fleet of microcontrollers that will scan for nearby Wi-Fi and Bluetooth network signals in different areas of a building. Since students nowadays will be using phones and/or laptops that emit Wi-Fi and Bluetooth signals, scanning for Wi-Fi and Bluetooth signals is a good way to estimate the fullness of a building. Our microcontrollers, which will be deployed in numerous dedicated areas of a building (called sectors), will be able to detect these connections. The microcontrollers will then conduct some light processing to compile the fullness data for its sector. We will then feed this data into an IoT core in the cloud which will process and interpret the data and send it to a web app that will display this information in a user-friendly format.
# Solution Components
## Microcontrollers with Radio Antenna Suite
Each microcontroller will scan for Wi-Fi and Bluetooth packets in its vicinity, then it will compile this data for a set timeframe and send its findings to the IoT Core in the Cloud subsystem. Each microcontroller will be programmed with custom software that will interface with its different radio antennas, compile the data of detected signals, and send this data to the IoT Core in the Cloud subsystem.
The microcontroller that would suit the job would be the ESP32. It can be programmed to run a suite of real-time operating systems, which are perfect for IoT applications such as this one. This enables straightforward software development and easy connectivity with our IoT Core in the Cloud. The ESP32 also comes equipped with a 2.4 GHz Wi-Fi transceiver, which will be used to connect to the IoT Core, and a Bluetooth Low Energy transceiver, which will be part of the radio antenna suite.
Most UIUC Wi-Fi access points are dual-band, meaning that they communicate using both the 2.4 GHz and 5 GHz frequencies. Because of this, we will need to connect a separate dual-band antenna to the ESP32. The simplest solution is to get a USB dual-band Wi-Fi transceiver, such as the TP-Link Nano AC600, and plug it into a USB Type-A breakout board that we will connect to each ESP32's GPIO pins. Our custom software will interface with the USB Wi-Fi transceiver to scan for Wi-Fi activity, while it will use the ESP32's own Bluetooth Low Energy transceiver to scan for Bluetooth activity.
## Battery Backup
It is possible that the power supply to a microcontroller could fail, either due to a faulty power supply or by human interference, such as pulling the plug. To mitigate the effects that this would have on the system, we plan on including a battery backup subsystem to each microcontroller. The battery backup subsystem will be able to not only power the microcontroller when it is unplugged, but it will also be able to charge the battery when it is plugged in.
Most ESP32 development boards, like the Adafruit HUZZAH32, have this subsystem built in. Should we decide to build this subsystem ourselves, we would use the following parts. Most, if not all, ESP32 microcontrollers use 3.3 volts as its operating voltage, so utilizing a 3.7 volt battery (in either an 18650 or LiPo form factor) with a voltage regulator would supply the necessary voltage for the microcontroller to operate. A battery charging circuit consisting of a charge management controller would also be needed to maintain battery safety and health.
## IoT Core in the Cloud
The IoT Core in the Cloud will handle the main processing of the data sent by the microcontrollers. Each microcontroller is connected to the IoT Core, which will likely be hosted on AWS, through the ESP32's included 2.4GHz Wi-Fi transceiver. We will also host on AWS the web app that interfaces with the IoT Core to display the fullness of the different sectors. This web app will initially be very simple and display only the estimated fullness. The web app will likely be built using a Python web framework such as Flask or Django.
# Criterion For Success
- Identify Wi-Fi and Bluetooth packets from a device and distinguish them from packets sent by different devices.
- Be able to estimate the occupancy of a sector within a reasonable margin of error (15%), as well as being able to compute its fullness relative to that sector's size.
- Display sector capacity information on the web app that is accurate within 5 minutes of a user accessing the page.
- Battery backup system keeps the microcontroller powered for at least 3 hours when the wall outlet is unplugged.
|8||Hearing Damage Detector and Alarm System
|Hojoon Ryu||Arne Fliflet||design_document7.pdf
|# Hearing Damage Detector and Alarm System
- Alex Yuan (ayuan20)
- Jinzhi Shen (jinzhis2)
- Jake Fava (jfava2)
Middle and high school musicians can be subjected to harmful levels of noise on a daily basis between rehearsals, practice sessions, and performances. Cheap and effective hearing protection is available, but many students neglect using it until they start noticing the effects of their hearing damage years later.
Our solution is a device that provides live feedback to musicians about their noise exposure in an attempt to encourage more regular use of existing hearing protection equipment.
# Solution Components
## Subsystem 1 - Sensor Interface (Microphone)
To capture the sound pressure levels, we’ll need a microphone that is omni-directional, responsive to the frequencies that the human ear is responsive to (about 10Hz-20kHz), and has a suitably high signal-to-noise ratio (~60dB or above). One microphone that fits these criteria is the TOM-1537L-HD-LW100-B-R.
Accompanying this microphone will be a pre-amp circuit to filter out DC noise and prepare readings to be used by the microcontroller.
## Subsystem 2 - Microcontroller Unit
Our microcontroller will need to be able to take input data from the microphone interface and turn it into useful information for the user. There are two types of feedback we’d like to be able to provide: 1 - instantaneous SPL readings in dB and 2 - integrated SPL over time (also called “sound exposure”) to gauge potential hearing damage accumulated over a session. A potential MCU to use for our device is the ATMega4808, which contains a 10-bit analog-to-digital converter and 48 kB of RAM.
Although a future version of this device could be powered by a rechargeable lithium-ion battery for the sake of portability. Due to time and scope limitations of the course, we will be powering this device via USB.
## Subsystem 3 - User Interface
To present live feedback on instantaneous SPL, the device could feature a series of LEDS that light up in response to recorded dB. They should range from green for safe sound levels up to red for potentially dangerous sound levels.
To present a report of sound exposure over the course of a session, we will plan to pull the data from the device onto a computer (just like the computers that would be located in a practice room or classroom) and perform the necessary integration operation there to conserve system resources. This operation will produce a report detailing the amount of sound exposure and what hearing damage it has the potential to cause.
# Criterion For Success
1. The device needs to be able take a signal from a microphone and accurately calculate SPL from the data.
2. The device needs to be able to display instantaneous SPL data in the form of lit-up LEDs
3. The device needs to be able to upload recorded SPL data to a computer to perform the integration and generate a report.
|9||SELF SOLVING/SCRAMBLING RUBIK’S CUBE FOR LEARNING AND TRAINING
|Qingyu Li||Kejie Fang||design_document1.pdf
|# SELF SOLVING/SCRAMBLING RUBIK’S CUBE FOR LEARNING AND TRAINING
# TEAM MEMBERS:
- Byron Lathi (byronl2)
- Colin Choi (colinc4)
- Walter Uruchima (walteru2)
Rubik’s cubes are fun to learn and solve, but scrambling them can be a pain. You have to turn all the sides in random directions, but you may have subtle biases in how you turn the cube. This results in a non-random scramble and worse practice for solving.
For users that do not know how to solve the cube, it can often be difficult for them to learn. There are many algorithms that must be memorized and they can be intimidating for beginners trying to learn.
A cube with integrated motors, for turning all six sides, that can scramble itself with a random (or pseudorandom) scramble. This will help increase skill level by giving users patterns that they were not previously giving to themselves due to subtle biases in their scrambling.
The cube will also be able to use the same motors and controllers to return itself to a solved state. This opens the door for teaching users the correct algorithms that they must use in order to solve the cube.
# SOLUTION COMPONENTS
## POWER AND CHASIS
- Small battery for power
- 3D printed Rubik’s Cube:
- The cube will need to be custom designed to hold the electronic components and motors within it. It will likely be larger than the classic Rubik’s cube as a result.
## CONTROL SYSTEM
- Micro Controller (STM32)
- Reads sensors and controls motors. Runs algorithm to scramble and solve cube
## TURNING SYSTEM
- 6 motors are needed to rotate the sides of the cube.
- Hall effect sensor and Magnets
- The hall effect sensor will use the magnets to coordinate stopping points with the motors. This will make sure that each side gets turned the correct amount.
# CRITERION FOR SUCCESS
- Self scrambling capabilities that will put the cube in a randomized state.
- Self solving capabilities that will return the cube to a solved state regardless of previous state
|10||Remotely Adjustable Cast
|Stasiu Chyczewski||Viktor Gruev||design_document2.pdf
|# Remotely Adjustable Cast
- Alice Getmanchuk (aliceg3)
- Jack Burns (jackjb2)
- Saloni Garg (sgarg27)
For broken limbs, there are a couple types of casts: plaster, fiberglass, splint, AirCast. And while they all have their own benefits, they also have drawbacks. The non-AirCast types are durable but also heavy, can get mold, and require doctor visits. The AirCast is lighter, but can be expensive and hard to properly put back on by the patient. Currently, patients with AirCasts have no method of setting exact levels of strap tightness by themselves as originally done by the Doctor.
The solution to the above problem is to modify an AirCast so that it can be tightened remotely. The doctor would help install the cast once and save the position of the strap tightness. Then, when patients remove their cast to bathe (which prevents mold), they can press a button in the app to correctly tighten their cast again. Additionally, there is the opportunity to have further tele-health visits with the doctor which they can use to remotely adjust the cast and help the patient regain strength. This way, the cast doesn't just act as a stabilizer for broken limbs but can further help as a rehabilitation device. No current auto-adjusting casts exist on the market.
# Solution Components
## Subsystem 1
Pressure Adjustment/Gauge Subsystem maintains and manipulates the air cells in the cast which may be hard for the user to self-inflate (especially if the cast is on the arm)
- Sensor to detect pressure of air cell: [http://eshop.ece.illinois.edu/parts/Parts_List.htm](http://eshop.ece.illinois.edu/parts/Parts_List.htm) (Pressure sensors from ECE shop?)
- [Stretch goal] Motor to fill and deflate air cell based on current pressure: [https://www.hackster.io/news/programmable-air-is-an-arduino-based-air-pump-for-your-soft-robotics-projects-9945c6ed96aa,](https://www.hackster.io/news/programmable-air-is-an-arduino-based-air-pump-for-your-soft-robotics-projects-9945c6ed96aa) [https://www.adafruit.com/product/4699](https://www.adafruit.com/product/4699)
## Subsystem 2
Strap Adjustment Subsystem maintains and manipulates the straps on the cast which can be improperly tightened and this subsystem aims to prevent that by restoring straps to original tightness after cast is taken off
- Motor to tighten straps: (from ECE shop, doesn’t have to be fancy)
- Small electronic motor/lever component to unlatch the straps: (from ECE shop)
- Force sensor to detect the force of the straps on the cast for proper adjustment:
## Subsystem 3
Control Subsystem creates and implements boot tightness presets
- Microcontroller (with Bluetooth connection to connect to app) to handle sensor data and control motors
- PCB - microcontroller will interact with sensors on PCB. Power control unit will be on PCB as well.
- Frontend display with preset options and ability to select one option which allows the user to remotely adjust the cast pressure level and strap tightness
- Display of pressure level and strap tightness amount for each preset option
- Allow remote adjustment of presets for doctor/patient
## Subsystem 4
- https://www.amazon.com/United-Ortho-Short-Walker-Fracture/dp/B006L8M2GA/ref=sr_1_27?keywords=air+splint&qid=1662318400&sr=8-27 (possibly one that Alice can borrow)
- Power supply/battery (depends on psi necessary for air pump inflation)
# Criterion For Success
* cast is auto adjusting
* can tighten and loosen without physical user manipulation
* pressure in air cast changes without physical user manipulation
* can be controlled using the app
* have presets for tightnesses
* able to create new presets
|11||Electronic Drawer Organization System
|Stasiu Chyczewski||Viktor Gruev||design_document1.pdf
|# Electronic Drawer Organization System
- Michael Grawe (mgrawe2)
- Nathan Marchosky (nathan7)
- Michael Stoens (mstoens2)
In situations where there are large collections of drawers or file cabinets in one area, finding the right tool or item can be very difficult. I often find myself looking for an item in a drawer and open the wrong drawer multiple times. This occurs even in a shelving unit with a comparably small number of drawers. An example of a place where this might be an even larger problem might be in a large kitchen (i.e restaurant, caterer, etc.) the closet of a person who has a shopping problem, or a large filing cabinet with a variety of documents. It would be great if there was a way to find the correct drawer without searching through each one. In addition, it would be great if these drawers had a locking capability to ensure that children can’t open drawers full of knives.
The proposed solution for this problem lets a user interact with a connected drawer system through an app on a smartphone. The phone will have to be paired to a microcontroller via Bluetooth. A database of all the items stored in the drawers (or all the items the user wishes to keep in the database) will be stored in the microcontroller. When the user wishes to find an item, they select the desired item in the control module by using buttons on the phone app. The controller will communicate to the corresponding drawer via Bluetooth. The drawer in which that item resides will then either 1) open, 2) flash an LED, or 3) ask for a passcode input to unlock the drawer. The user will be able to configure each individual drawer within their system to respond in the chosen manner to the selection.
# Solution Components
Provides power to all the board modules as well as the motors used to operate the drawers. Power will come from the grid and will be rectified to dc power for all the components.
## Drawer Sensor system / moving/indicator system
Allow Drawer to perform basic functions like opening the drawer by using a Servo, lighting an external LED, or Locking the drawer. It will also be able to sense whether a drawer is closed or not through the use of a switch at the front of the drawer. Finally, the locked status of the drawer will be tracked by an IR sensor surrounding the locking mechanism. These different physical components will be connected to the MCU through some PCB necessary to regulate.
Parts (still need specifics)
-(x2 per drawer) DC Servo motor (motor = MG996R) attached to small hammer at back of drawer to open drawer
-LED w/Resistor (LED = SLR-56VRT32 from Digi-Key, should be red)
-Drawer with rollout (may have to build ourselves)
-(x2 per drawer) Stepper motor (motor = NEMA17) to swing metal bar up as locking mechanism (latches on top of drawer)
-(x2 per drawer) IR laser sensor to make sure it is locked (IR = SEN-00241, includes emitter and detector
- Push Switch to check its closed (Switch = RB-Pol-791)
-Alternatively, Hall effect sensor (HE sensor SS411P) at back of drawer to sense drawer closed (close enough to the back of the drawer frame
## Control Module (Microcontroller)
This module acts as a go-between from the user and the physical drawers. It mainly consists of a microcontroller, which will store all the user-defined item-drawer pairs. The microcontroller will be connected to the user interface (smartphone app) through bluetooth. It will have different GPIOs coming to and from the sensors and mechanisms on each drawer.
-MCU with Bluetooth - ESP32
## User Interface
This module is a smartphone app that will allow the user to communicate to the microcontroller via bluetooth. It will allow the user to view configurables for each drawer, as well as all their stored items. Through the app, the user will be able to select an item, thus opening/LED flashing/unlocking then opening the corresponding drawer. They will also be able to add more item-drawer pairs through the app interface.
-smartphone app, no extra parts needed
# Criterion For Success
-User must be able to initially pair an object with drawer through smartphone app
-Selecting an item on phone app must perform desired action on the correct drawer
-User must be able to configure desired drawer actions (flash LED, open drawer, prompt passcode, etc.)
-Drawer components must not impede too much on drawer space
-circuitry must be less than 10000 mm^2 in area and have a height < 20 mm
-Phone and controller must be able to interact within bounds of a large room, around 1000 sq. feet.
-Final prototype must include at least 3 drawers
-Drawer must function as normal (i.e, completely close (front flush with drawer frame), securely lock (can’t be opened without unusually large force))
|12||Cycling Assist System with Rear Camera Detection
|Jeff Chang||Kejie Fang||other1.pdf
|# Cycling Assist System with Rear Camera Detection
- Jacob Betz (jmbetz2)
- Trisha Yadav (tyadav4)
- Jingdi Liu (jingdil2)
Many cyclists run into different dangerous situations while biking on the road. For example, a vehicle may be rapidly approaching in their blindspot, which could cause serious injuries. Another possible danger is the bike leaning too far to the left or right. We are hoping to create a detection system to help distracted drivers and riders from potential accidents.
Our solution is to create a low power, user friendly system that can assist cyclists in all of the safety areas listed above. The system would monitor and detect approaching objects in the rear using a camera as well as inform the user if they are leaning too far in one direction. Our system will be competitive compared to other assistance systems in the market on cost and functionality aspects.
# Solution Components
List of Components:
- 1080p USB Camera
- MPU6050 6-axis IMU
- Raspberry PI 4 (4GB)
- Arduino Nano
- Custom PCB
- LED Indicator Lights
- Rear Camera: On the rear of the bike, a camera will be used to monitor the rear of the cyclist. The camera feed will be used to show the cyclist a rear view on the dashboard and will be fed into OpenCV with object detection to detect vehicles, other bikes, etc. We will use a small 1080p USB camera and 3D printed enclosure to mount on the back of the bicycle seat.
- Stability IMU: This sensor is a unique idea to monitor the cyclists roll stability on their bike. It would let the driver know if they were leaning too far in one direction. The IMU we have selected is the MPU6050 6-axis. The IMU will be located on the custom dashboard PCB.
- Custom Dashboard: The driver would be notified using our dashboard. This dashboard, mounted near the handle bars, would have a 3.5 inch LCD display showing the cyclist its rear view from the camera feed. It would also include an array of LED indicator lights to warn the cyclist how close a vehicle, other cyclist or bus is to the driver from behind. Lastly, it would include a brightening LED that tells the driver how far it's leaning to the left or right using the IMU feed. The dashboard would include a Raspberry Pi 4 and Arduino Nano. The Raspberry Pi will be used for OpenCV object detection as well as driving the LCD display. The Arduino Nano will be used with the IMU I2C communication and light up the necessary LEDs. Both of these microcontrollers would connect to the custom PCB that holds the sensors, LED lights and attaches the display. The enclosure would be a 3D printed case that mounts to the bicycle handlebars.
- Small Battery: A small battery will be needed to power the system. This battery will be located next to the dashboard, part of the same enclosure as the PCB.
# Criterion For Success
- Priced competitively with other bike sensors in the market
- Device needs to be able to scan for approaching objects or vehicles, and effectively warn the cyclist of the approaching object on the user’s custom dashboard
- Device needs to be able to inform the user that the bike is leaning too far in a certain direction through a brightening LED
- The camera needs to be small enough and secured well to be able to stay attached to the bike, even in rough terrain
- Camera and dashboard should be waterproof in order to ensure that the driver can utilize the device in different weather conditions
|13||Smart Health System for Plants
|Hojoon Ryu||Arne Fliflet||design_document1.pdf
|# Smart Health System for Plants
- Tilak Patel (tpatel80)
- Rohan Prasad (rprasad3)
- Yash Parikh (yparikh2)
There are many families in this world that - for a variety of reasons - are away from home and have plants sitting at home waiting for them to come back and provide water and sunlight. Further, many families love to have plants but don't have time to watch over them due to jobs and busy schedules. In these times, many plants can die out causing the owners to either purchase a new plant or throw out the old one completely. This is not only a problem of neglect, but also sustainability on a broader scope.
To solve this problem and have plant owners save money by not having to buy new plants, we would create a Smart Health System for Plants with a Phone UI for the owner. We would create a plant potter which is built in with our Smart Health System and provides connectivity to the owner through a UI. In our system, we would use different sensors to measure values like humidity, soil moisture and sunlight provided to determine exactly how much water/sunlight the plant will need. We then pump in water from our water reservoir straight to the roots and provide light when needed. Further, through the UI, the owner would also be able to provide manual water and artificial light when they want to and see critical values from the sensor module. Overall, this Smart Health System for Plants will provide plants with the most ideal conditions they need to grow and survive and owners will never have to worry about dead plants due to their busy schedules and family vacations. Further, this system will consist of a sensor module, microcontroller, watering system, artificial sunlight system and a phone UI.
# Solution Components
## Sensor Module
In this system, we would use the sensors listed below to provide values to our microcontroller to be used in our algorithm to determine when the plant will need water and light. These sensor values will also be reflected in our Phone UI where the owner will be able to see all the critical values around their plant.
- Soil Moisture Sensor (Waveshare Moisture Detection Sensor Module)-https://electropeak.com/waveshare-moisture-sensor
- Humidity and Temperature Sensor (DHT22 Temperature Sensor)-https://www.sparkfun.com/products/18364
- Light Sensor (Grove-Sunlight Sensor or Photoresistor)-https://wiki.seeedstudio.com/Grove-Sunlight_Sensor/
In this system, we will connect all of our sensors, watering system, artificial light system and phone UI to control different parts of our Smart System. We will take values from our sensors and turn on/off the watering system and artificial light system. Further, we will also use the commands from the Phone UI to control the watering system and light system.
- Arduino (https://store-usa.arduino.cc/products/arduino-mkr1000-wifi?selectedStore=us)
## Watering System
In this system, we will use a water reservoir which will be controlled by a pump connected to our microcontroller. When we determine the plant needs water, we will run the pump for a specific amount of time which will be determined by our algorithm and controlled by our Arduino microcontroller. We will also use a water level sensor to notify the owner when the water is running low and needs a refill
- Water Pump (12 V pump)- https://www.amazon.com/Peristaltic-Liquid-Dosing-Silicone-Tubing/dp/B075VN1QZM
- Water Level Sensor- https://electropeak.com/liquid-level-sensor-waveshare
## Artificial Light Module
In this system, we will connect an overhead light system to help provide light to the plant when our algorithm determines the plant needs some light. We will connect this module to our microcontroller to help control turn on and off the light when we need to. This can also be controlled by our Phone UI on a manual basics when the owner needs it
- Light Ring Module- https://www.amazon.com/DIYmall-WS2812-WS2812B-Arduino-Raspberry/dp/B0774JNSCF
## Phone UI
In this system, we will create a UI for the owner which will interact with our microcontroller and provide graphs for the sensor values and ability to water the plant manually. We will also provide a way the owner can select their plant from our created plant library or create their own plant and enter specific values we need to make sure their plant gets enough water to stay healthy and survive.
- Software Code
# Criterion For Success
With the time given to us in ECE445 to complete this project, we want to be able to see our watering system run automatically using the sensor values and the microcontroller. Further, we at least want to see our Phone UI be able to provide water to the plants on a manual basis. Further, at minimum we want our system to have a few coded algorithms for plants which can be run on its own to water the plants automatically.
- Automatically use sensor values and provide water/sunlight throughout the day
- Use the phone UI to see sensor values and manually provide the plant water
- Use the phone UI manually provide the plant artificial sunlight
|14||Hardware Accelerated High-Frequency trading system
|Mingjia Huo||Kejie Fang||design_document2.pdf
|# Hardware Accelerated High-Frequency trading system
- Richard Deng (ruichao4)
- Siyi Yu (siyiyu2)
In the financial market today there is a lot of need to optimize the trading/execution latency to support automated quantitative trading systems. While most of the computer software run on generic operating systems and the CPU executing the logic has many parts of unnecessary instructions/procedures, the automated trading strategy can be highly optimized with hardware to achieve low latency and high frequency
We plan to build a trading system that uses one PCB to connect to a fake exchange and get/send binary market data and use highly optimized FPGA to consume this market data and make decisions based on the data
# Solution Components
## Fake exchange
This will be a piece of software that simulates an exchange in real-time. This fake exchange will only have one security to trade and will be receiving three types of binary-encoded messages (add order, cancel order, update order) from the market participants using a certain protocol, building a full-depth limit orderbook based on the order received, automatically trade two orders when the bid side and ask side meet, and re-broadcasting the trade message with the other three client messages in binary encoded form following the same protocol. To test our strategy we will simulate the market data received from market participants, constantly adding limit ask/bid at the same price level in high frequency
## Networking Hardware
This will be a PCB with ESP8266 and other parts/ports to communicate with the fake exchange through the network. We plan to use UDP since it is what most exchanges will use. This part will be optimized to reduce the connectivity latency between the fake exchange and the trading system and feed the data to the FPGA.
## FPGA Trading Strategy
This will be an FPGA optimized for trading strategy, making decisions based on the binary data received from the Networking Hardware, sending the decision back to the networking PCB and which will send it back to the exchange. We plan to have two simple strategies:
1. High-frequency market-making: making a spread of $a ~ $b by sending limit bid at $a and limit ask at $b, adjust the spread based on Best Bid Offer (BBO) market data. This part is to test how fast our trading system can be adjusted based on real-time information changes.
2. High-filling rate limit order: send a limit bid order whenever there is a limit ask order at $a. This part is designed to test the latency of our trading system and is extremely useful in options trading where the bid-ask spread is very large and has a low order filling rate.
# Criterion For Success
We plan to test the latency and frequency after the project is finished. We will use another pure-software trading system running on a computer that has exactly the same strategy as the one using hardware, and we expect the highest possible frequency and the average latency of our hardware trading system when connecting and trading on our fake exchange to be significantly faster than purely software trading strategies.
|15||Emotionally Intelligent Mirror
|Akshatkumar Sanatbhai Sanghvi||Arne Fliflet||design_document1.pdf
|# Emotionally Intelligent Mirror
- Aishwarya Rajesh (arajesh4)
- Apurva Chanda (apurvac2)
- Tala Aoun (taoun2)
These past few years have highlighted the need for strategies alleviating mental and physical health issues especially during Covid-19. In particular, many who live alone face loneliness and seek comfort/companionship. A potential solution to provide accessible technology to all is a smart mirror that can understand your emotions in real-time and communicate with you. The mirror should also be able to track a user’s emotions on a long-term basis to see if any improvements or deteriorations are occurring.
The mirror will be able to understand the user’s emotions such as happiness, anger, sadness and neutral and respond accordingly to each emotion by reciting comforting words, playing music and sympathizing with the user. On a long term basis, the mirror will store information about a user’s mental health that has been gathered from facial expressions and emotions to track a user’s progress and see if any improvements or deteriorations are occurring. If a user’s emotions are obviously getting worse in the long term, the mirror would be able to provide resources like crisis hotlines or telehealth to help the user. In regards to privacy issues, the mirror will be password protected so that each user can have their own profile and data.
# Solution Components
## User Detection System
The components in the user detection system will be used together to detect a subject in the space (the user). The depth sensor will be able to distinguish the user from their surroundings. Then the camera will evaluate their facial features using the Viola-Jones framework, which will compare the user’s facial features among set standards (generally the Haar features) to determine their emotion. The microphone and speaker will be used so that the mirror can communicate with the user.
- Depth Sensor (Lens Board OV5647 or TeraRanger Evo Mini)
- Camera (Digikey IMX219 Camera Sensor NVIDIA Jetson Nano)
- Microphone (3.55 mm pc microphone)
- Speakers (Portable Speaker JBL GO)
## Power -
To power the project, we are planning on utilizing power from a wall source. A combination of regulators, AC to DC converter, and USB port will be used to power all the components
- Regulators (Switching and/or Linear Voltage Regulator)
- USB port (Depends on the chosen microcontroller)
- AC to DC converter (3.3 V, 5 V, 12 V – Standard values that will be helpful)
- External Supply (Wall 130 V AC Source)
In order to display all the information and interface with the user, there will be a monitor attached on a wall. To reduce overall power consumption from the external wall source, we will include LED lighting to better see and receive visual input from the user.
- Monitor/TV (LCD TV, Mid-Size Mirror)
- LED Lighting (LED Strip Lighting)
All the components will be integrated using the brain of our overall system. The microcontroller will facilitate communication (such as I2C and UART) and inputs (such as microphone) coming in between the microcomputer and other components.
- Microcontroller (ATmega328p, Attiny85, or Raspberry Pi)
- Microcomputer (ATmega32 series, Arduino Y)
# Criterion For Success
- Camera detects a person looking into the mirror and greets them based on the sensor system correctly identifying whether the person is feeling a negative, positive or neutral emotion
- After identifying if an emotion is negative, positive or neutral, the mirror will be able to recognize which emotion the person is feeling (joy, sadness, anger, fear, disgust, and surprise). It will be able to identify the six basic human emotions.
- The microcomputer will store data about each person who uses the mirror and it will store the amount of negative and positive emotions they experience over a period of time (i.e. a month) and recommend resources if a negative trend is detected.
- Emotion profiles will be password-protected so each user can only see their own data.
|16||Poker Chip Counting Companion
|Qingyu Li||Kejie Fang||design_document1.pdf
|# Poker Chip Counting Companion
## Team Members:
- Forrest Hare (fhare2)
- Adish Patil (adish2)
- David Hahn (davidh7)
In our free time we enjoy playing Texas Hold’em poker. Before, during and after every game,
we have to count different colored chips that equate to different cent/dollar values. Having to do
this by hand is not only very time consuming but can also lead to errors which would result in a player
having too much or too little chips. Furthermore, calculating the buyouts for each person can be a cumbersome
task. These time consuming and easily mistakable tasks pose a serious problem for every game.
To solve the problems introduced above, and improve the overall poker experience, we’d like to design a cohesive chip counting machine. With the Poker Chip Counting Companion, setting up and playing a game of Poker becomes a much smoother experience! The Poker Chip Counting Companion will accurately dispense poker chips based on user inputs about the game such as the buy-in and big/small blind metrics (Dispensing State). The device will also calculate the appropriate amount of each color chip required which takes the guess-work out of figuring out the proper chip stacks when starting a game. At the end of a game, the device will switch to a buy-out operating mode (Collection State), which will then correctly count the remaining stack sizes of each player. The entire machine will be powered from the USB-C Power Subsystem. The user interaction will occur through the web app subsystem where a user can input information, control the state of the machine, and receive information about the game. The User input data will be communicated to the rest of the machine from a bluetooth connection. Data from the app will be used in the Dispenser control subsystem.
## Solution Components -
- 4 PVC tubes (4.5cm diameter and 30cm tall so the poker chips can fit inside)
- 4 bipolar linear stepper motors with screw shaft (used for raising and lowering the chips from the PVC tubes)
- 1 bluetooth transceiver
- 1 counter IC (CD74HC4017EE4)
- 1 USB-C power connector (digi-key 10132328-10011LF)
- Assortment of AND/OR logic gates
- Several LEDs (for indication that the device is in operating mode)
## USB-C Power - Subsystem 1:
Provides Power from a USB-C connection. The proper voltages and currents needed for each other sub system will be given.
## Bluetooth Connection - Subsystem 2:
Bluetooth Connection [HiLetgo 2pcs HC-05 Wireless Bluetooth RF Transceiver Master Slave Integrated Bluetooth Module 6 Pin Wireless Serial Port Communication BT] takes the input data from the user and puts the user inputs into registers so that the proper chips can be dispensed. This subsystem will also be used to send information back to the app to tell the user that the machine is done dispensing and to also communicate any errors that occurred.
## Dispenser Control - Subsystem 3:
A series of pvc pipes will be used to house the different color of chips, a platform will be placed at the bottom of the pipe to move the chips up and down. A gear system controlled by a linear actuator [Iverntech NEMA 17 Stepper Motor with Integrated 300mm T8 Lead Screw for RepRap Prusa i3 3D Printers Z Axis or CNC] will move the chips in steps of one chip. This subsystem will take the information given by the user and convert it into a signal the linear actuator can understand.
## User Web Application - Subsystem 4:
The user interface will come in the form of a web React application. We will be using Bluetooth as the way for the application to communicate with the Poker Chip Companion machine. There’s a few ways users interact with the machine…
At the start of the game, the user will turn the companion on to its dispensing state, and can input the value of each chip, the amount of players, the small & big blind, and the buy-in (this will be preselected, however the user can alter is based on each player if needed).
The application will take these values and input them into an algorithm to calculate how all the poker chips are divided, and the amount per player if buy-ins are different. This information will be sent to the companion.
At the end of the game, the user will turn the companion on to its collection state, and will be instructed to input the chips of each player one by one. As the user completes the input of one player, they will press a “Next Player” button (like a timer lap button) to signify to the machine the collection process of the next player. Once complete, the user presses a “End Collection” button, and will be presented with the complete scoreboard of player buyout.
## Criterion For Success
- We will need to maintain a proper Agile Board guiding our development and construction the entire semester.
- We will need a well maintained Github repository for our code.
- We will need an established working schedule among the three of us to work inside and outside of the lab.
- We will need to establish a good line of communication for TAs to report our progress and also ask for guidance.
- Determine the dimensions of a poker chip and calculate the corresponding motor rotational angle.
- Build a chip housing case and chip platform. This will be the main housing for our device.
- Calculate the algorithm for determining chip stack sizes based on buy-in and blind values.
- Calculate the state logic to dispense the correct amount of chips for each color for communication with the motor.
- Get the linear actuator running.
- Begin testing & debugging.
|17||Multi-Party, Multi-Factor Authentication Lock
|Zhicong Fan||Arne Fliflet||design_document1.pdf
|**Multi-Party, Multi-Factor Authentication Lock**
- Shelby Doty (sdoty4)
- Noah Hill (noah5)
- Akshay Sundaram (akshay5)
Governments and government agencies, banks, hospitals, or companies may have rooms, safes, or vaults requiring controlled access to protect their contents. These areas and their contents are prone to physical security attacks such as severance of critical cables, theft of communication equipment, or theft of data servers. Existing methods to protect physical systems from malicious insiders include auditing, job rotation, and separation of duties. Auditing access to a restricted area is reactive and does not prevent unauthorized access from occurring. Job rotation and separation of duties only limit prolonged access to certain areas or physical systems.
Multi-factor authentication (MFA) is an electronic authentication method used to grant an individual access to an application or place only after successfully presenting multiple factors for verification purposes. Multi-party authorization (MPA) requires multiple individuals to authorize access to an application or place. An example of multi-party authorization usage occurs in banks when one accesses a lockbox. This requires both a bank official and the lockbox owner to act together to open the lockbox.
This project is the implementation of an electronic lock mechanism that provides a proactive approach to physical access control by employing both MFA and MPA methods. Access is granted only when a configurable number of individuals (multi-party) successfully authenticate with an inherence factor and a one-time token received via SMS text (multi-factor). The inherence authentication factor is a fingerprint. The mechanism is applicable to, for example, a lockbox in a bank. A bank lockbox already requires multiple parties to be present to gain access, however, the inherence authentication factor, the fingerprint, is not easily lost or misplaced as lockbox keys are.
- The mechanism unlocks only when connected to WiFi
- SMS texts are sent to all enrolled users when the authentication process is initiated
- SMS texts are sent to all enrolled users when the system loses then regains power
- The number of enrolled users and parties required to successfully authenticate (thus, disengaging the lock) are configurable
**Functionality upon initial boot and configuration**
Upon receiving power, the system connects to WiFi and prompts for the following parameters to be configured:
- Number of users to be enrolled
- Number of successful user authentications required to disengage the lock
One by one, each user is prompted to scan a fingerprint and enter their phone number.
**Control unit / authentication verification:**
When a user attempts to authenticate with a fingerprint, the fingerprint module will attempt to verify the user’s identity and provide the ESP32 with the user's identity if successful, or inform the ESP32 an unsuccessful authentication attempt was made.
ESP32 uses Wi-Fi connectivity to provide the TCP client with the identity of the user that successfully authenticated via fingerprint or to notify of a failed authentication attempt.
In case of successful biometric authentication, ESP32 then awaits a one-time token sent via SMS to the user to be input on the tactile keypad. Access is granted/denied depending on whether the user inputs the correct token generated by the TCP client.
The ESP32 will control the LCD display and the servo motor for locking/unlocking.
This subsystem consists of the fingerprint sensor module for gathering biometric data and an LCD screen to display warnings and instructions.
-AS608 Optical Fingerprint Sensor Module for storage of biometric data, fingerprint scanning and digital signal processing
-LCD2004 Character-Type Liquid Crystal Display for user feedback regarding system status, authentication success/failure messages, remaining successful authentications before unlock, etc.
-D72 Tactile Keypad for user to enter one-time token received via SMS
**Mechanical relay & lock status indicator:**
This system will be responsible for the following: indicate to the user when the lockbox is locked and unlocked via LED indicators and a speaker beeping noise, and open and close the locking mechanism using a servo. Additionally, there will be a magnetic contact switch that, when triggered, sends a signal to relock the lockbox. Servo for lock mechanism:
-Red and green LEDs (from ECE lab kit)
-Speaker (from ECE lab kit)
-SG90 9g Micro Servo
-Magnetic contact switch (NTE Electronics, Inc 54-637)
-Connect to ESP32 microcontroller as a TCP client to send and receive signals and data. Additionally, store logs of authentication attempts with timestamps on the server. The micropython network module can be used in Python by connecting to a python socket.
-Initial setup will include connecting devices to the Wi-Fi network and storing initial configuration data. The web app can then authenticate data read after initial setup to send a lock or unlock signal to the controller. The application will also send SMS messages to the correct parties after fingerprint data has been authenticated.
-Application then sends the correct pincode to the ESP32 and the signal to wait for pincode authentication.
**Criterion For Success**
-Lock and unlock after all parties (at least 2) have been verified
-Data written and stored is accurate
-Works plugged in to outlet and/or with battery back-up power
-Easy to use and straight forward web application / web server
-Sends message to parties when verification has failed
|Jason Paximadas||Arne Fliflet||design_document2.pdf
|# Refill Dispensary
By: Micheal Blyakhman (mlb11), Jackson Wiessing (jtw6), Lyla Zegelstein (lrz2)
## Problem Description:
Plastic waste happens all over the United States. It’s problematic because plastics don’t decompose and end up in landfills or waterways. There have been traces of plastics found in fish. The environment would benefit greatly if there was a shift away from plastic and instead towards more reusable bottles. We will target the single-use plastic crisis by designing a refill station where a customer can bring their own containers or bottle and refill it.
Many refill stations already exist which provides concept validation. One competitor is Henkel that has both makeup and laundry detergent refill stations in Europe. The makeup refill is simply a bottle with a pump where users are expected to dispense their own product. One potential issue is expecting users to be honest about the amount they take and not spill any of the product. Henkel’s laundry detergent refill station operates similar to a soda machine where each type of product has its own dispenser. These machines are very large and only offer laundry detergent.
We would like to innovate on this concept by designing a machine where multiple types of unrelated products can be offered to customers. The competitive advantage is being able to tailor the machine to different areas. One neighborhood might buy lots of quinoa, shampoo, and cereal, but another one may demand laundry detergent, rice, and ketchup. Different types of goods should all be able to be stored in the same machine and fit the demand of an area.
## Solution Overview:
Our design is highly scalable and customizable. By creating 3 types of dispensing methods that take up the same amount of space in the machine, we are laying the foundation for future machines to hold any combination of the types of dispensing methods. Furthermore, more types of dispensers can be added to the machine for more specialized items(e.g. eggs).
## Solution Components:
The machine will consist of 6 main parts: item storage, dispensing method, cap chooser, dispensing hole, container spot, user interface.
- Item storage - we will have a round circular holder. In this holder, items to be dispensed will be held in a container. For our demo, we will probably use bottles and load them into a 3D printed part. The item storage will be attached to a motor that spins the holder circularly until it gets the selected item in a spot directly above the dispensing hole.
- Dispensing Method - The method used will depend on the type of item that needs to be dispensed and will live inside of the holder for this machine. Here is what this might look like for our project.
A bottle that has a plunger inside that will push liquids of varying viscosities out.
A catchment system that dispenses items 1 at a time (ex: roll of toilet paper, single tide pod).
A measurement system for dispensing precise quantities of items that would come out fast (ex: rice).
- Cap chooser - for contamination purposes each item that gets dispensed, will have its own protective layer over the dispensing hole.
- Dispensing hole - the area in which an item is passed outside of the machine
- Container spot - the area where a user places their own container. This should feature some system for ensuring that the container is present.
- User interface - method for a user to select a quantity and item. Most likely a screen with physical buttons.
## Criterion For Success:
A 100% successful product would complete this story from beginning to end with no issues.
1. Machine gets stocked
2. User goes to the machine and selects the blue item.
3. Item storage spins until the blue item is above the dispensing hole
4. Cap chooser moves left/right to get the proper cap over the hole
5. Cap chooser inserts the cap into the hole
6. Item storage lowers the blue item bottle into the cap
7. Item gets dispensed
8. User takes their newly filled container
|19||Distributed Bike Locking System
|Hanyin Shao||Kejie Fang||design_document1.pdf
|# Distributed Bike Locking System #
A bicycle is stolen every 30 seconds and the problem has exacerbated to such an extent that nearly two million bikes are stolen every year, amounting to over $350M. As such, we propose a distributed bike locking system that remotely controls pre-installed bike locks and significantly enhances the security of the bikes being temporarily locked. More specifically, our solution is to program and retrofit a durable computer-controlled locking box onto an existing bike rack, which would automatically facilitate the locking, unlocking, and payment method for the service.
**Unique Value Proposition**
We are going to create a public automated, passcode-driven lock that is designed to deter theft. There will be detectors and buttons embedded to sound a very loud and high-pitched alarm when a thief tries to physically break the lock.
- Don’t need your own lock, so users can carry less on their persons or bikes
- Bicycle rack manufacturers do not need to alter their manufacturing process, because they can simply retrofit our solution
- Cheap and convenient, and users must pay with coins to use the appliance
- Passcode-driven security
- Keeps the bike safe and locked for a specific amount of time based on the user input
- Keeps the bike locked even if user goes over time (and further charges the user later)
- Could be purchased by bicycle rack buyers as an accessory for the racks, or by bicycle rack manufacturers and sold alongside the racks
The Distributed Bike Locking System (DBLS) presents a number of advantages over contemporary solutions of securing a bicycle. Some of the core unique value propositions involve the fact that it allows users to lock their bike safely to any DBLS-enabled bike rack, and ensures a high degree of security. We utilize a passcode-driven security system so that users can lock and unlock the bicycle at any time with a simple 4-digit PIN, which each user can set for that parking session. For bike rack manufacturers, DBLS is an easy solution that can be retrofitted onto virtually any bike rack and customized a variety of ways according to the physical structure of the bike rack. Moreover, we offer this solution to the end user at an affordable price that makes more sense than purchasing an individual bike lock.
- Buying a lock and wrapping it around a standard wave-shaped bike rack or tree
- Public bike storage (can be expensive)
- Renting a veoride or electric bike temporarily
- Citi bike racks - https://citibikenyc.com/how-it-works. This a bicycle sharing service where you temporarily rent a bicycle from Citi and return it to a Citi bike station when you are done.
- https://linkafleets.com/products/original-linka-smart-bike-lock-fleets?variant=31954112086080 - Individual smart lock, designed for mounting on a bicycle
There are alternatives to distributed bike locking systems. Those would include buying a separate lock and wrapping the lock around a standard wave-shaped bike rack or a tree. This would require the bicycle owner to carry some sort of chain or purchased bike lock, which costs at least $10, and quite a bit more for better-quality locks. There is often the possibility of destruction of the lock by a thief, however. The public bike storages in the cities have lockers to store the bikes temporarily. However, lockers can be expensive to rent out up to $48 plus other fees. Another alternative would be to rent a Veoride or an electric bike. However, there will be people using their own bikes to get around and they won’t have much use of renting a Veoride or an electric bike. There is also the option of purchasing a personal Linka smart lock that mounts to the bicycle, but that is at the cost of $135 to the bicycle owner, and even then, our locking device is quite different.
The Distributed bike locking system will utilize a microcomputer that will run the algorithms for the User Input, the Bike lock, and the detectors to sound the alarm when strange activity is being detected such as with the motion of the bike lock. The general price for the user will be $0.50 per hour for the automated lock. However, the price will increase to $1.00 per hour when the user overstays their number of inputted hours.
The Distributed Bike Locking System is a network of several identical appliances, welded or heavily bolted to existing bike racks so as to become essentially integrated into the racks, and connected by wire to a central Raspberry Pi computer somewhere within several yards, perhaps buried a foot underground inside a waterproof box. This computer will be programmed in Python and powered either by mains or a large rechargeable battery, with an algorithm to control all of the appliances connected to it in the way that they should operate. This reduces the cost of each individual appliance, because a central computer for 15 or 20 “dumb” appliances removes the necessity to have a Raspberry Pi or other computing device onboard every appliance. However, if a hidden central computer with wires running everywhere is impractical to install, then the design could easily be modified to include a computer board inside every appliance, making them fully independent devices.
A single appliance will be a durable rectangular metal box, about twice the dimensions of a box just big enough to accommodate a typical bicycle seat, maybe around half the volume of a small desk printer. The face of the box that is longest in proportion to its other dimension will have two U-shaped brackets for attachment to the rack, bolted from the inside of the mostly hollow appliance. The brackets may be larger than the thickness of the rack, in which case the appliance would hang loose and be able to slide and rotate on the rack, but that poses no issue as long as it does not make severe impact with the ground or become separated from the rack, the latter of which would be impossible without a cutting wheel or some dedicated power tool. This also has the advantage of permitting user adjustment of the lock position to suit the shape of the bicycle. The face directly opposite that with the brackets will feature a servo-controlled sliding steel bar, about an inch in diameter, which will lock around the bicycle frame. There will also be an internal solenoid-controlled latch to keep the bar immobile in a closed position when locked.
The upward- or outward-facing face of the box, which is also the one with the most area, will have a three-digit seven-segment LED display (for showing the parking duration), a ten-digit keypad for passcode entry, a number of single LEDs with various status messages written next to them on the exterior, and a coin slot for payment by the user, leading to the mostly hollow interior and with optical coin size sensors embedded in the side of the slot. Inside the appliance will be a pair of smoke detector alarms (for a doubly loud sound in case of attempted theft), a few buttons or pressure sensors touching the side of the steel latch as force sensors to sound the alarm in case of attempted bicycle theft, and an accelerometer or shock sensor for the same purpose, in case a thief tries to smash the device with a hammer. The sensors could be wired directly in parallel series arrangements with the smoke detector alarms, without the need for intelligent activation of the alarm, so that a continuous ear-splitting beep is heard as long as there is enough force applied. If the thief abandons his mission, the alarm will stop. There will also be a servo and a solenoid-actuated latch for locking the bicycle, some relays to forward computer signals to these higher-powered components, a central board to consolidate all signals to and from the components and forward them to a port on the exterior, and a set of standard C or D batteries to power the appliance. Power will then be local to each appliance in the network, rather than supplied by wire, so that anti-theft alarms are functional even if the wire to the computer is severed. A wired approach is simpler than a wireless one, and immune to radio interference or jamming; and if the wire is severed by a malicious actor, the appliance will lose computer control and remain in its locked or unlocked state, providing no incentive to cut the wire if theft of the bicycle or the appliance is the intention. The wires may be buried a few inches in the ground, or run along the ground inside metal guards.
The face opposite that with the controls and lights will have a small hinged door in one of the corners, made of thick sheet metal like the rest of the appliance, for replacing batteries and emptying coins. It will have a mechanical key lock, accessible only by a custodian under the party that owns the racks and appliances. The little door is located in the corner in case a thief or other person with ill intentions is able to breach it, with some powerful crowbar or otherwise special tool for breaking through tough metal. The coins can unfortunately be emptied (which risk may be mostly averted by ensuring that coins are collected every day or so), but if that person wanted additionally to try to destroy the internal electronics with some screwdriver or sharp durable probe, it would be easiest if the door were in the center of the face, because then nothing inside is very far from the opening. A door located in the corner, particularly the corner furthest from the most sensitive electronics or from all electronics, would be a simple measure to minimize the ability of someone to inflict internal damage. This door could also be alarm-protected, with a button or force sensor on the lock if someone tries to pry it open, and it would also have to be sealed from rain with a rubber gasket.
Alternatively, instead of having access to the entire interior via the door, a special compartment could be made inside that corner of the appliance, to which the coin slot leads and where the batteries are mounted. This may be a superior design, because damage to electronics is not possible, and it is easier for the custodian to remove all of the coins, and change the batteries. If normal C or D batteries are used, they would last at least several months in an outdoor application requiring occasional small amounts of power for the servo and lights; although the purchaser of the appliances might do better to invest in rechargeable C or D batteries, which would last years with recharging every few months. These typically are rated at 1.2 volts rather than the 1.5 for standard single-use batteries, so the design would have to take that possibility into account. Perhaps these rechargeable batteries could be sold with the appliance.
**Scenario of Operation**
The user walks up to the bike rack. If it is not in use, a green LED will be on, and a seven-segment LED display will show 0:00, indicating that it is ready for use. If it is in use, and there is a bike locked there, a red LED will be on. The first thing the user does after approaching an available rack is to press the up-arrow and down-arrow buttons to increase or decrease the desired parking duration by half hour increments. The seven-segment display changes to 0:30, then 1:00, etc., with each press of the up arrow. When the desired duration is shown, the user presses an “enter” button, and a light comes on next to text that says “Enter new passcode.” The user can enter a 4-digit PIN via the keypad, and then press “enter.” Another light comes on saying “Confirm passcode.” The user enters the same PIN, and presses “enter.” It is the responsibility of the user to remember this PIN. The light turns off, and another comes on, saying “Insert coins.” The appliance will charge 50 cents per half hour of bicycle parking, which will be stated on a decal or other inscription on the outside of the device. The user inserts coins into the coin slot, and when at least the proper amount has been inserted (according to computer interpretation of data from the optical coin slot sensors), another light will come on, saying “Position bicycle and press enter to lock.” The user positions the bike properly, with one tube of the frame placed inside the deep rectangular recess in the appliance, and presses “enter.” The servo slowly slides the metal bar out of the side of the recess, over the bicycle frame tube, and into a hole in the other side of the recess, and resets the seven-segment display to 0:00. The user can now walk away knowing that the bicycle is secure.
If the user wishes to cancel parking and unlock the bike early, the user can walk up and enter their unique passcode, without a refund. The user has ten attempts to get the passcode correct, after which the appliance will keep the bike locked for the next 24 hours (free of additional charge), as a theft deterrent. If the number of tries were any less, then there is a greater risk of a prankster coming by and deliberately entering incorrect passcodes to keep all the bicycles locked there, which would deter people from using the appliances in the future. If the number of tries were greater than 10, there would be a greater chance of correct guesses by potential thieves. If the user does enter their passcode correctly, the appliance will unlock, and the appliance will await the next user.
If the user has not entered their passcode to unlock their bicycle after their duration has expired, a light will illuminate next to a message saying “Parking reservation exceeded,” and the appliance will keep the bike locked indefinitely and require additional payment of $1 per half hour past the initially specified duration in order to unlock it. The first dollar will be incurred at the very second of expiry, and the second dollar at one second after the first half hour has passed, etc. A clever user will always make a point to redeem their bicycle a little early, to avoid these charges, or deliberately to overestimate the time they will need when specifying the parking duration. The user must enter their passcode, after which the “Insert coins” light will come on. As soon as the last coin is inserted totaling at least the amount due, the locking bar will slide back into its hole in the side of the recess, releasing the bicycle, and the “Parking reservation exceeded” light will turn off. There will be no coin return or change.
- Main microcomputer (Raspberry Pi)
- Detectors and sensors (alarm buttons, ultrasonic sensors, PIR motion sensor)
- LEDs (display signals to help with the user input and to display messages for the lock)
- Buttons (for user input)
- Batteries (for everything)
- Wires (to create the circuit with the Raspberry Pi)
- A hollow box to hold the Raspberry Pi along with the components mentioned above
- A locking mechanism with a bar, servo, latch, and solenoid (example of what the lock could look like: https://linkafleets.com/products/original-linka-smart-bike-lock-fleets?variant=31954112086080)
**Criteria for Success**
The bike is successfully locked and stored for the amount of time input by the user. The system will have to sound an alarm if suspicious activity is detected by the sensors embedded in the appliance. A specific example would be when the lock is forcibly moved when locked for the specified user inputted time, there would be a beeping noise and this would be similar to a smoke detector. The only difference would be that the sensor is going to detect unexpected motion of the latch. This would be achieved with either an ultrasonic sensor which detects the distance the latch has moved, or a PIR motion sensor which can help detect an intruder with unusual movement with the use of infrared light. This is a way to signal a warning. This is also a passcode generated lock so the system has to make sure it has the user passcode stored in memory so when the user tries to unlock it, the program will refer back to the stored passcode and be able to unlock the latch when the user correctly enters it. However, the bike should stay locked unless the user is able to enter the correct passcode to unlock it. The program should successfully take in the right amount of money based on the coins and set the time also based on the money inputted and charge the user an extra $1.00 per half hour if the person keeps the bike for a longer period of time.
|20||ZZZ-Mate : Pulse Driven White Noise Generator
|Jeff Chang||Kejie Fang||design_document1.pdf
|Team Members: Sanjana Chunduri (sc65) / Vakaris Ragauskas (vragau2) / Haruya Kamitani (hkamit2)
According to the CDC, about 70 million Americans suffer from sleep deprivation. Lack of sleep causes various issues in our daily lives such as tiredness, lack of concentration, and in extreme cases, heart failure, diabetes, and various serious conditions.
Some of us rely on external sound sources for falling asleep. Currently, there are various white noise machines out in the market. However, most of these devices output a single, continuous signal. According to one article (https://krisp.ai/blog/background-noise-impact/), “the continuous background noise also known as white noise which comes from machines and other appliances, can harm your brain, it does so by overstimulating your auditory cortex”. According to one Healthline article (https://www.healthline.com/health/parenting/white-noise-for-babies#cons), a 2014 study concluded that “regular exposure to these sound pressure levels may be damaging to infant hearing and auditory development.”
White noise is typically beneficial during the earlier sleep stages, when people are more likely to be awoken by distracting noises or thoughts. However, rather than continuously playing background noise through the night and overstimulating the auditory cortex, our design aims to combat typical sleep deprivation issues by supporting users through all stages of their sleep cycle: Wake, light sleep, deep sleep, REM, and repeat. By taking pulse rate measurements as an indicator of the user’s current sleep stage, our sound generation device will adjust the volume of the white noise. A wristband with a photo sensor and green LEDs will be used to detect the user’s heart rate and will wirelessly relay the information to the white noise generator to adjust the volume as necessary.
-Subsystem 1(Noise Source):
Power Supply Section: Noise source unit will be powered by 9-15VDC voltage. AC/DC adapter cable will be used. This power supply will provide a necessary power for MPU and if necessary, for speaker power amplifier as well as noise source.
MPU: ESP32 or related with built in Bluetooth/WiFi. This will be used to communicate with another ESP32 which will be built into the wearable band. The pulse rate data received from the wearable band will be used to control the output level of the noise source.
Speaker: Speaker with a wideband output frequency range (100Hz - 20kHz) will be used as white noise has an even power level across the full frequency spectrum. We may implement a power amplifier circuit with a simple transistor topology.
Noise Source: If it is manageable through ESP32, this will be programmed in MPU. Otherwise, transistor/opamp based white noise source will be implemented.
-Subsystem 2 (Wearable band):
MPU: another ESP32 microcontroller to send the pulse data to the main speaker/source unit.
Heart rate sensor: MAX30100 or MAX30102 or SEN11574
Battery: Lithium ion 3.3/5VDC
#Criterion For Success
One high-level goal of our project is to have wireless communication between a heart rate sensor wristband and a white noise machine. This wristband should be able to detect the heart rate of the user and differentiate between the four sleep stages of the user and differentiate between slight increases in heart rate to detect unrest. With software implementation, the WNG should decrease in volume when transitioning between sleep stages and after detecting an increase in heart rate.
|21||Automatic Pet Sitter
|Hojoon Ryu||Viktor Gruev||design_document1.pdf
- Tyler Huang (tylerh4)
- Joseph Choi (jschoi5)
- Abhi Chebiyam (abhijit3)
Describe the problem you want to solve and motivate the need:
If an owner is away from home for vacation or away daily because of work, it can be hard to give the proper care for your pet. Solutions today are too one-dimensional when each pet requires different types of care even amongst the same species. Pets have unique and distinct preferences and the owner shouldn’t have to compromise because of the limitations of the feeder system.
The solution to this problem is to design an automatic dispenser setup that delivers food and water to the user’s pet. Our solution will involve a couple of subsystems in order to provide users’ pets with the most comfort and care. The first and main subsystem will revolve around a pressure pad/sensor that will act as the main trigger for the dispensing system. The next subsystem is the dispensing of food and water, and all the features related to that.
# Solution Components
## Pressure Pad
Our main trigger system will be based on the pet’s weight. Our aim is to have the pet sit or walk onto a pressure sensor that will lead to food or water being dispensed.
Some features we are hoping to implement with this subsystem are:
Pressure pad being configurable to the pet’s weight (i.e., trigger weight for German Shepherd will be much higher than trigger weight for Chihuahua)
A camera that is activated after a set time of pressure on the pad that will take a photo of the pet and send it to the owner
Directly triggering the second subsystem to dispense food and water
## Dispenser Subsystem
This subsystem will center around our dispensing of food and water into our pet’s bowls. While this may seem simple in concept, we hope to incorporate features that raise the complexity of this subsystem.
Some features we are hoping to implement with this subsystem are:
Dispensing triggered by first subsystem
Amount of food and water dispensed will be calculated and can be combined with pressure sensors on the bowls to know how much food or water the pet has consumed
Dispensers will know when to stop filling bowl based on light sensors- this will also serve a dual purpose of not filling the bowl while the pet is consuming the food or water
This subsystem is mainly to send information to the dispenser system and communicate when dispensing should continue or stop.
Alerts the dispenser when to stop filling the bowl using load sensors
Vibration creator to create movement in the bowl for pet preference
## Mobile Application
This subsystem allows the owner to customize and set the dispenser settings to a highly customized level for their pet. The dispenser will be able to send data through the Raspberry Pi to the application, so the owner will be able to keep track of their pet and its well-being.
- Load Sensor (SEN-10245): https://www.sparkfun.com/products/10245
- Water Pump: https://usa.banggood.com/Excellway-Mini-Micro-Submersible-Motor-Pump-Water-Pumps-DC-3-6V-100L-or-H-Low--p-1249338.html?imageAb=1&rmmds=search&ID=514182&cur_warehouse=CN&akmClientCountry=America&a=1661970223.2113&akmClientCountry=America
- Camera for Arduino: https://www.amazon.com/Arducam-Megapixels-Sensor-OV5647-Raspberry/dp/B012V1HEP4/ref=asc_df_B012V1HEP4/?tag=hyprod-20&linkCode=df0&hvadid=385286500280&hvpos=&hvnetw=g&hvrand=3640949845190010298&hvpone=&hvptwo=&hvqmt=&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=9022196&hvtargid=pla-820020083673&psc=1&tag=&ref=&adgrpid=77282054583&hvpone=&hvptwo=&hvadid=385286500280&hvpos=&hvnetw=g&hvrand=3640949845190010298&hvqmt=&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=9022196&hvtargid=pla-820020083673
- Arduino / Rasp Pi
# Criterion For Success
1) We can categorize our goals by priority- focusing on fulfilling the most important features first]
2) Food and Water is dispensed when a pressure pad is triggered
3) The amount of food and water dispensed can be customized
4) The pressure pad sensor trigger weight can be configured
5) The amount of food and water dispensed can be calculated
6) The dispenser will stop dispensing regardless of the pressure pad trigger if the light sensor is triggered
7) Photo can be taken of pet after a set amount of time being triggered
8) Dispenser data is being sent to an external device.
9) The external device is able to set limitations to the dispenser.
|22||ARC Machine Monitor
|Zhicong Fan||Viktor Gruev||design_document1.pdf
|# ARC Machine MONITOR
- Calvin Lee (calvinl4)
- Rohan Inampudi (rohani2)
- Akhil Kodumuri (akhilvk2)
One question that is always on a college student's mind is "Is the ARC busy?" There have been many times throughout our college career where we have gone to the ARC expecting a quick workout just to see lines to the machines we wanted to use. We've always wished that we could see what machines were being used and what were not. That is why, we would like to create an interface where students can use their phone to visually see which equipment at the ARC are being used and which are not.
We would like to create an interface where students can use their phone to visually see which equipment at the ARC are being used and which are not. This way, students can anticipate whether or not they should go to the ARC. At a high level, there would be a button by the equipment being used. The button, upon being pressed by the user when a machine is being used, would then send a signal to an IoT device which would then send a signal to an AWS server. Our website will then use this server to update a UI which users can utilize to see which machine is being used.
# Solution Components
## Subsystem 1 (machine sensor pcb to IoT device)
In order to detect whether or not a machine is in use, we would like to create a PCB with the following components. A button (https://www.amazon.com/Gikfun-Waterproof-Button-Momentary-Arduino/dp/B07F8GBWGG/ref=asc_df_B07F8GBWGG/?tag=hyprod-20&linkCode=df0&hvadid=343224601369&hvpos=&hvnetw=g&hvrand=2325432847971158710&hvpone=&hvptwo=&hvqmt=&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=9022196&hvtargid=pla-757057055269&psc=1&tag=&ref=&adgrpid=70737352522&hvpone=&hvptwo=&hvadid=343224601369&hvpos=&hvnetw=g&hvrand=2325432847971158710&hvqmt=&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=9022196&hvtargid=pla-757057055269) that will be pressed whenever a machine is being used, a timer in order to keep a time a machine is being used, an alarm (https://www.digikey.com/en/products/detail/tdk-corporation/PS1440P02BT/2236832?utm_adgroup=Alarms%2C%20Buzzers%2C%20and%20Sirens&utm_source=google&utm_medium=cpc&utm_campaign=Shopping_Product_Audio%20Products_NEW&utm_term=&utm_content=Alarms%2C%20Buzzers%2C%20and%20Sirens&gclid=Cj0KCQjw39uYBhCLARIsAD_SzMRocrg56djQZdtSr1banc2WuquRuRWNwZ3Xb1x-w5BqNdJqJw-9-HQaAjB5EALw_wcB), a network card (https://www.espressif.com/en/products/socs), and 2 leds of different colors to indicate that a machine is being used.
## Subsystem 2 (IoT device to AWS Server)
This server will host all information on which machine is being used. In order to send data to the AWS cloud, we will install AWS IoT Device SDK (https://docs.aws.amazon.com/iot/latest/developerguide/connecting-to-existing-device.html#gs-device-view-msg) onto our Raspberry Pi 3 Model B. All machine information that is sent to the Pi will be sent to the AWS cloud.
## Subsystem 3 (AWS Server to website)
The website we will design will keep track and display what machines at the ARC are being used by using the AWS server configured in Subsystem 2. This website will be configured using the Python framework Flask.
## Subsystem 4 (load sensor to alarm)
If there is time in the project, we would like to attach load or motion sensors in order to detect use of the equipment that occurred without pressing the button, which would set off alarm.
# Criterion For Success
Ultimately, we define success on whether or not the UI on our website can change the status of a machine at the ARC when it is being used. This can be tested by the following process: Person at ARC working out, button pressed to indicate machine in use, IoT device receives signal from button, IoT device sends data to AWS server, and, finally, machine status on website changes to "Occupied".
# Important Notes
One facet of our project that needs to be tested is power consumption. In order for this product to be used at the ARC, it is imperative that we find the most lightweight solution to our project. Our current proposal is a product of our preliminary research into the most energy efficient solution to our project idea.
Communication between Aruduino and Pi: https://medium.com/@anujdev11/communication-between-arduino-and-raspberry-pi-using-nrf24l01-818687f7f363
Sending Data Between MQTT:
|23||VR Force Feedback Gloves Restricting Side to Side Finger Movement
|| Yoonseo Choi
|Jason Paximadas||Viktor Gruev||design_document1.pdf
- Aaron Gros (aygros2)
- Yoonseo Choi (yschoi4)
Current commercial force feedback VR gloves are too expensive for regular consumers and are only targeted towards industry and research. Open source force feedback VR gloves are economically accessible to regular consumers as long as they’re willing to spend some time putting them together. However, they are bulky and don’t restrict the finger’s side to side movement. The latter would be desired for a greater sense of immersion when for example grabbing an object between the sides of your fingers.
We propose a new design for force feedback VR gloves that are still economically accessible to the regular consumer and that restrict the finger’s side to side movement as well as back and forward movement. The result would be that if a user tried to grab an object in VR with the sides of their fingers, this movement would be reflected in VR, and the movement of the fingers would be restricted when they collide with the object in VR. The same would be the case for trying to grab an object with the fingers’ back and forwards movement.
These are some commercial alternatives that are too expensive for regular consumers: Sence Gloves and HaptiX.
Lucid Gloves is the most successful open source alternative but it lacks side to side force feedback and is bulky.
This includes the physical glove and its mechanical components that will enable the electronics to do their job. We will design and 3D print this component. It will consist of a mount to place all the other components on, a spider leg like fixture attached near the knuckle on one end and on the finger on the other end, and guides along the finger to hold the string.
**Back and Forwards Actuator:**
We will have a string attached to an actuator on one end and a finger tip on the other. The actuator will either be a small motor or an electromagnetic brake. The actuator will resist the extension of the string, which will apply force feedback to the fingers.
**Side to Side Actuator:**
We will have a plastic mechanism attached to an actuator around the knuckle on one end and a finger tip on the other. The actuator will either be a small motor or an electromagnetic brake. This actuator will resist the movement of the plastic mechanism therefore providing force feedback to the fingers.
**Back and Forwards Sensing:**
The string mentioned above will also be attached to a potentiometer. This will measure the movement of the string and therefore calculate the position of the finger.
**Side to Side Sensing:**
The plastic mechanism mentioned above will also be attached to a potentiometer. The movement of the mechanism will be the same as the side to side movement of the finger.
Although the final product should be wireless, to be able to focus on the force feedback components and not make the gloves too bulky, we won’t be incorporating a battery into the design and will instead have a wired connection.
**Processing and IO:**
We will use the ESP32 to read all the sensors and actuate all the motors as well as send the necessary signals to the computer.
**Criterion for Success:**
The gloves are able to:
- accurately track the finger’s position
- restrict the finger’s side to side movement
- restrict the finger’s back and forwards movement
- recreate the finger’s motion in VR
- correctly restrict the finger’s movement when they are in contact with a VR object
|24||Grounded Rope Management System for Belaying
|Jason Paximadas||Arne Fliflet||design_document1.pdf
|# Team members:
Abhyan Jaikishen (abhyanj2)
Chris Zhang (czzhang3)
Daniel Hsu (sehsu2)
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.
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
|25||EarlyBird Alarm Clock
|Stasiu Chyczewski||Arne Fliflet||design_document1.pdf
When I need to wake up early, I usually set an alarm. The problem is that oftentimes I just hit the snooze button and fall back asleep.
We will address the problem by creating an alarm clock that runs around your room blaring an alarm. When the user catches the clock, they need to solve a math equation in order to turn off the alarm.
1. **The Alarm Clock**
The alarm clock will display the current time on a hex display. It will allow the user to change the current time and set an alarm using push buttons. A microcontroller will keep the time using a watch crystal, and display the current time on a hex display. At the specified alarm time, the clock will produce a loud noise through a speaker.
2. **The car**
The alarm clock will be mounted on top of a car. When the alarm is ringing, the car will start navigating around the room with obstacle detection. The car will be a 4-wheel drive, with a servo behind each wheel. The front of the car will have an ultrasonic sensor mounted on a servo. The servo will periodically scan the 180 degrees at the front of the car, looking for obstacles. Based on the ultrasonic sensor, the microcontroller will map a path for the car.
3. **The math equation**
When the user catches the car, they need to solve a math equation in order to turn the alarm off. The microcontroller will randomly pick a single digit number and a double digit number, and compute their product. The user needs to enter the correct the product using push buttons, and then the alarm will be deactivated. The operands as well as the user’s input will be displayed on hex displays.
**Criterion for Success**
To measure our success, we’re basing it on these requirements:
**Clock Capabilities: +2**
The clock unit needs to display the correct time, allow the user to set the time and alarms, and produce a loud sound at the specified alarm time.
**Autonomous Movement: +3**
This part involves the car having the capability to detect it’s path and determine if an object is in the way or not. It should also be able to avoid certain zones (such as under the bed, or in a trash bag).
**Math Equation: +3**
A random double digit multiplicand and random single digit multiplier are displayed on the HEX display. The user can input 3 digit numbers on the hex display. The microcontroller correctly computes the product, and compares the user input to the computed product. If they match, turn off the alarm clock, else, generate a new equation and keep the alarm on.
**Documentation & Paper Work: +2**
Not only is the hardware component a part of our laboratory, we think that setting good discipline with documentation is integral to the success of our senior design project.
|26||Lens Controller for Biomedical Cameras
||Ji Hun Kim
|Zhicong Fan||Viktor Gruev||design_document1.pdf
|#Title : Lens Controller for Biomedical Cameras
In many operations, the margin for error is very slim. This is especially true for cancer treatment, where operation on tumors is considered one of, if not the only solution to cancer sickness. Operating on tumors requires a high degree of accuracy and so, the use of cameras to aid surgeons in the operating room would significantly reduce the risks associated with any mistakes involved in the removal of tumors. According to a study, incomplete tumor removal occurs in 25% of breast cancer patients, 35% of colon cancer patients and 40% of head and neck cancer patients (Citation needed). From this, it can be seen that the problem is significant and requires a solution to this problem.
The solution to this problem is to develop a system where the lens of the camera can be adjusted based on a user input (A surgeon or surgery assistant), which would then help the surgeons in identifying any cancerous tumors and fully removing the tumors. We are planning to use the FPGA to move the lens of the camera so that we can remotely control the lens. The flexible PCB board will be used to provide interconnection between the FPGA and the lens ports. We will be implementing the finite state machine using the FPGA to control the overall operation of the camera. Users will be interacting with the movement of the camera using python code.
Lens Flexible PCB FPGA
##Subsystem 1 Lens
The lens will be responsible for zooming in and out of the target object according to the commands from the user.
##Subsystem 2 Flexible PCB
The flexible PCB board will be used to provide interconnection between the input and output ports of the lens and the FPGA board. We cannot use regular wire because the ports are small and are not one-to-one mapped so we need to figure out the signal value for each port.
##Subsystem 3 FPGA
The FPGA model that we will be using in our project is from OpalKelly with the model number XEM7310. It has a high end FPGA with many digital IO pins for this task. We will be using the FPGA board to control the lens using a finite state machine using SystemVerilog code.
##Criterion For Success
Camera zooms and moves as programmed
Camera functions promptly upon the command
Port mapping is correctly functioning
Image / videos taken from the camera correctly shown on the computer screen
|27||Compact MW Laser
|Optical energy transmission device|