Project

# Title Team Members TA Documents Sponsor
13 Safe Crib With Auto Hazard-Detection
Bob Yuan
Feng Zhao
Xinlong Dai
Dushyant Singh Udawat design_document2.pdf
final_paper1.pdf
photo1.jpg
photo2.jpg
photo3.jpg
photo4.jpg
presentation1.pdf
proposal1.pdf
video
Team Members:
- Xinlong Dai (xinlong3)
- Feng Zhao (fengz3)
- Yuhao Yuan (yuhaoy3)

# Problem
As we all know, parents with babies at home are most worried about the safety of their babies. Even at home, they always worry that when dealing with things in another room, the baby will not accidentally climb out of the crib or bump into the head of the bed, which is easy to hurt and easy to make the child cry. So we wanted to design a smart crib that uses ultrasonic sensors to detect the baby's posture and prevent accidental falls. In addition, the system monitors whether the baby is crawling on the bed to inform parents that the child is awake, though not crying. The system alerts parents in other rooms to prevent further dangerous movements. According to the posture and danger level of the baby at this time, the LCD screen plays the corresponding image warning to effectively make parents understand the situation in the baby's room to avoid more risk.
# Solution
We will use ultrasonic sensors to detect the baby's position and relative height on the bed to determine whether the baby is climbing the barrier, crawling, or rolling. In the case of the former, the master control system recognizes the action as dangerous and sends the information to a receiver in the other room, which is equipped with an OLED screen and speakers to warn of the danger. For the latter, the main control system considers it a warning action and acts similarly but switches to display a different set of alerts and a more soothing tone. In this way, parents can clearly understand the baby's current state.
# Solution Components

## Power Subsystem

We will use multiple 5V battery sets to supply the power for all the components.

## Ultrasonic Sensor Subsystem

The system will use HC-SR04(Ultrasonic Sensor) to detect the baby's current height through several ultrasonic sensors installed at the top of the guardrail on one long side and one short side of the bed. Because when lying down or climbing, the baby's height generally does not exceed the height of the guardrail. The system can consider the baby in a standing posture if the ultrasound is blocked. At the same time, multiple groups of ultrasonic sensors installed on the guardrail on both sides of the crib can also measure the distance between the baby and the guardrail at this time to precisely locate the baby on the crib. In addition, there is a set of sensors at the bottom of the guardrail, which is at the same height as the mattress. Their role is to measure the distance between the guardrail and the baby to determine the relative position of the baby in the lying position.

## Central Analysis and Data Transmission Subsystem

Suppose the distance between the guardrail is too close and the ultrasound sent by the set of sensors at the top-guardrail height. In that case, the ATMega328p (MCU) uses both information to determine that the baby is at risk of trying to climb the guardrail, causing an accidental fall. The MCU will consider it as a dangerous condition. If the sensors at the top are not blocked, but the bottom sensors detect frequent movement of the baby, the MCU will consider it as if the baby is awake and crawling, which is a warning condition. Either way, the MCU sends a corresponding signal via the Wi-Fi (ESP8266) or Bluetooth (HC-06) module to the receiver next door.

## User Interface Subsystem

Depending on the type of signal received(warning/danger), the ATMega328p (MCU) in the receiving end of the other room will send the corresponding notification image information and audio information from the internal storage to the OLED and speaker. Meanwhile, the user can use the knob to adjust the speaker's volume, display brightness, and reset the notification by pressing the button.

## Audio & Image Subsystem

According to the received audio and image information, we use 8O3W-JST-PH2.0-N speakers and ‎Hosyond B09C5K91H7 OLED to play warning alarms and text messages. Additionally, we use the DAOKI TS-US-115-CA microphone to collect the sound around the crib. This microphone can adjust the threshold and accept sound that is higher than a specific volume. This will allow the user to detect only the baby’s crying.

# Criterion For Success

Our default test environment involves placing a crib in a room the size of a traditional baby's room and placing random baby-sized objects on the bed to simulate the baby's situation in various locations. The actual testing “crib” should be a flat table with four supporting feet, and fences should protect the four sides of the table. The height of the guardrail/fence is unified on all sides, and all are 24 inches (60.96 centimeters). These parameters are determined based on a normal ten-month-old baby whose body length reaches 28.75 inches (73.3 cm).

If we lift the baby-sized object above the bed, which is at the height of the top of the guardrail, the sensor detects the ultrasonic block and sends the signal to the master control board, which then sends the warning signal to the receiving end of the other room. The screen on the receiving end also shows the warning signal of the baby climbing the guardrail and playing the alarm. At this point, the safety warning is successful. In addition, the same test object was moved irregularly across the bed in a second test. If the sensor detected this pattern, it judged that the baby had woken up. In the same order, screens in other rooms showed that the baby had woken up and another bell sounded. In this case, the reminder feature is successful as well.

Microcontroller-based Occupancy Monitoring (MOM)

Vish Gopal Sekar, John Li, Franklin Moy

Microcontroller-based Occupancy Monitoring (MOM)

Featured Project

# Microcontroller-based Occupancy Monitoring (MOM)

Team Members:

- Franklin Moy (fmoy3)

- Vish Gopal Sekar (vg12)

- John Li (johnwl2)

# Problem

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.

# Solution

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.

Project Videos