Project

# Title Team Members TA Documents Sponsor
84 AutoServe (Automated Room Service Bot)
 Ethan Jiang
Johan Martinez
Nikhil Vishnoi
 Po-Jen Ko design_document1.pdf
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.

Covert Communication Device

Ahmad Abuisneineh, Srivardhan Sajja, Braeden Smith

Covert Communication Device

Featured Project

**Partners (seeking one additional partner)**: Braeden Smith (braeden2), Srivardhan Sajja (sajja3)

**Problem**: We imagine this product would have a primary use in military/law enforcement application -- especially in dangerous, high risk missions. During a house raid or other sensitive mission, maintaining a quiet profile and also having good situational awareness is essential. That mean's that normal two way radios can't work. And alternatives, like in-ear radios act as outside->in communication only and also reduce the ability to hear your surroundings.

**Solution**: We would provide a series of small pocketable devices with long battery that would use LoRa radios to provide a range of 1-5 miles. They would be rechargeable and have a single recessed soft-touch button that would allow someone to find it inside of pockets and tap it easily. The taps would be sent in real-time to all other devices, where they would be translated into silent but noticeable vibrations. (Every device can obviously TX/RX).

Essentially a team could use a set of predetermined signals or even morse code, to quickly and without loss of situational awareness communicate movements/instructions to others who are not within line-of-sight.

The following we would not consider part of the basic requirements for success, but additional goals if we are ahead of schedule:

We could also imagine a base-station which would allow someone using a computer to type simple text that would be sent out as morse code or other predetermined patterns. Additionally this base station would be able to record and monitor the traffic over the LoRa channels (including sender).

**Solutions Components**:

- **Charging and power systems**: the device would have a single USB-C/Microusb port that would connect to charging circuitry for the small Lithium-ion battery (150-500mAh). This USB port would also connect to the MCU. The subsystem would also be responsible to dropping the lion (3.7-4.2V to a stable 3.3V logic level). and providing power to the vibration motor.

- **RF Communications**: we would rely on externally produced RF transceivers that we would integrate into our PCB -- DLP-RFS1280, https://www.sparkfun.com/products/16871, https://www.adafruit.com/product/3073, .

-**Vibration**: We would have to research and source durable quiet, vibration motors that might even be adjustable in intensity

- **MCU**: We are likely to use the STM32 series of MCU's. We need it to communicate with the transceiver (probably SPI) and also control the vibration motor (by driving some transistor). The packets that we send would need to be encrypted (probably with AES). We would also need it to communicate to a host computer for programming via the same port.

- **Structural**: For this prototype, we'd imagine that a simple 3d printed case would be appropriate. We'd have to design something small and relatively ergonomic. We would have a single recessed location for the soft-touch button, that'd be easy to find by feel.

**Basic criterion for success:** We have at least two wireless devices that can reliably and quickly transfer button-presses to vibrations on the other device. It should operate at at *least* 1km LOS. It should be programmable + chargeable via USB. It should also be relatively compact in size and quiet to use.

**Additional Success Criterion:** we would have a separate, 3rd device that can stay permanently connected to a computer. It would provide some software that would be able to send and receive from the LoRa radio, especially ASCII -> morse code.