Project

# Title Team Members TA Documents Sponsor
84 AutoServe (Automated Room Service Bot)
Ethan Jiang
Johan Martinez
Nikhil Vishnoi
Po-Jen Ko proposal1.pdf
**AutoServe (Automated Room Service Bot)**

**Team Members:**
- Nikhil Vishnoi (nikhilv4)
- Ethan Jiang (ethanj4)
- Johan Martinez (jmart454)

**Problem**

In hotels, apartments, and dormitories, guests or residents often request small amenities such as snacks, toiletries, chargers and more. Fulfilling these requests often requires manual labor, such as a staff member traveling long distances across hallways and between floors which is time-consuming, inefficient, and labor intensive. While some automated delivery robots exist, commercial solutions are extremely expensive, and often impractical for smaller deployments or retrofitting existing buildings. There is a need for an affordable yet flexible indoor delivery system capable of autonomously transporting small items within multi floor buildings while operating within existing infrastructure constraints.

**Solution**

We propose a small autonomous indoor delivery robot capable of transporting items between locations in a multi-floor building such as a hotel. The robot will navigate hallways autonomously and use an elevator to travel between floors, allowing it to deliver items from a central base location such as the hotel lobby snack bar to a specified destination room. The robot will move autonomously and be monitored wirelessly by staff through a remote UI that can display status updates on deliveries, or when the robot is ready in the elevator to be transported by hotel staff calling the elevator from the lobby. Elevator actuation is assumed to be externally triggered by the building as is most common in real hotels, while the robot will autonomously handle entering, riding, and exiting the elevator at the correct floor with sensor detection. This design choice reflects realistic constraints of existing building logistics while allowing the project to focus on autonomous navigation, system integration, and practicality.
An ESP32-based controller located on the central unit and the navigation unit will coordinate wireless connection between each other with the integrated Wi-Fi module. We would also incorporate graphed routes that are optimized for avoiding obstacles, with a proximity sensor to detect obstacles such as people and send the appropriate warnings. Items will be transported in a box with a rfid lock that can only be opened by residents such as with a hotel keycard or something of similar nature. This system would reduce staff workload, improve response time for guests, and demonstrate how embedded robotic platforms can be useful to automate common but repetitive manual logistics tasks.


**Subsystem 1: Microcontroller Unit**

- Two ESP microcontrollers will be used, one for the Central Base Unit and one for the actual Robot Navigation Unit.
- Both microcontrollers will communicate with each other using their integrated Wifi connection modules with transmitters and receivers.

**Subsystem 2: Robot Base Unit**

- Will have USB keyboard input (DS_FT312D) and Display to allow user input commands to robot
- Display (NHD-0216KZW-AB5) will show a UI for user to see robot status (charge, where it thinks it is, connection)

**Subsystem 3: Robot Unit**

- 2 Stepper motors (17ME15-1504S) to accurately move robot with predetermined distances.
- Will be 3D printed or machined with the machine shop
- Motors will be driven using motor driver (A4988SETTR-T) with MCU
- Display (NHD-0216KZW-AB5) for robot unit to communicate with nearby people

**Subsystem 4: Navigation and Sensing**
- Position Tracking sensor (TLV493DA1B6HTSA2) to track x,y,z motion data of robot. Actual map data and floor data will be hardcoded into the robot; this data will be used to make sure that stepper motors are moving correctly.
- Proximity sensors (TSSP40) for MCU to tell when it is being blocked by an obstacle and if it is boxed in it will communicate with the Base Unit for help.

**Subsystem 5: Robot Charging Station**
- The robot will have battery charge detection and will be able to inform the central base Unit when it is low on power.
- When delivery is completed and robot is done working it will dock into a base charging station that will flow a reverse current into the Lithium Ion batteries using a charge management controller (MCP73811).

**Subsystem 6: Security Subsystem**
- RFID based lock system for storing delivered items that opens for residents (Either from base station or with smart lock)

**Criteria for Success**
- The central base station can send commands to the navigational robot unit which is able to use predefined data to go to programmed/stored locations accurately.
- The navigational unit is able to identify its location, calculate the route to its next destination, and then move precisely towards it and stop correctly.
- Robot unit can avoid obstacles and send back status messages to the central base station indicators.
- The robot unit can operate through the elevator and can tell when it is at the right floor and when to exit.

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