Projects
| # | Title | Team Members | TA | Professor | Documents | Sponsor |
|---|---|---|---|---|---|---|
| 2 | Non-Shock Ultra-Wideband Virtual Boundary Pet Collar |
Peter Gao Shi Xian Chng Shi Yang Ng |
Tianda Huang | Cunjiang Yu | design_document1.pdf proposal1.pdf |
|
| # Non-Shock Ultra-Wideband Virtual Boundary Pet Collar **Team Members:** - Yujia (Peter) Gao (peterg4) - Shi Xian Chng (schng2) - Shi Yang Ng (syng2) ## Problem Existing wireless pet fences are unreliable indoors: GPS gives 3–5 m error and RSSI 1–2 m, environment-dependent. There is a need for an indoor virtual boundary that people can walk through but pets are trained to avoid, without physical barriers or electric shock. ## Solution Wall-powered UWB anchors placed in a chain define virtual wall segments. A collar measures its distance to adjacent anchors via UWB two-way ranging, computes its distance to the nearest wall segment locally using anchor spacings, and gives progressive vibration → sound feedback as the pet approaches. No central controller, fail-safe on link loss or low battery, high precision. Anchor and collar share one custom PCB with different populations. Role and anchor ID are assigned at flash time, so any spare board can replace any node. # Solution Components ## Anchor System ### Ranging Subsystem - **Hardware:** Qorvo DWM3000 UWB module communicating via SPI, with a dedicated RF antenna keep-out zone along the board edge. - **Software:** responds to collar polls with timestamps for double-sided two-way ranging. Self-surveys neighbor distances at power-up, re-verifies periodically; spacings ride in response payloads, large changes trigger a fault state. Ranging frames double as the data channel. ### Control Subsystem - **Hardware:** Espressif ESP32-C3-MINI-1 microcontroller module, status indication LEDs, and test points/headers for USB-serial programming and debug. - **Software:** anchor state machine - respond to polls by ID, schedule surveys, manage faults. Debug logs over USB serial. ### Power Subsystem - **Hardware:** USB-C connector for 5 V wall power input, AP2112K-3.3TRG1 LDO linear voltage regulator (3.3 V, 600 mA output), input/output MLCC decoupling capacitors, and unpopulated footprints for battery charging/feedback circuitry. ## Collar System ### Ranging Subsystem - **Hardware:** Qorvo DWM3000 UWB module connected over SPI with matching antenna keep-out layout identical to the anchor design. - **Software:** polls each anchor by ID, computes time-of-flight; collects spacings and status from responses. ### Control Subsystem - **Hardware:** Espressif ESP32-C3-MINI-1 microcontroller module, system status LEDs, and programming/debug headers. - **Software:** computes distance to each wall segment from two anchor ranges and the segment length, takes the minimum, and runs the feedback state machine (safe → warning → boundary) with hysteresis. Fail-safe on link loss or low battery. BLE for debug telemetry and stretch-goal phone notifications. ### Feedback Subsystem - **Hardware:** Piezo buzzer (TDK PS1240P02BT or CEM-1203), coin vibration motor (Vybronics VC1030B028F / 2265 ERM), dedicated haptic motor driver (TI DRV2603) or discrete N-channel switching MOSFET, with a flyback protection diode. - **Software:** maps zone to output - vibration in warning, escalating to tone at boundary. ### Power Subsystem - **Hardware:** 3.7 V (150–500 mAh) Li-Po battery with JST connector, Microchip MCP73831 charge management controller, integrated battery protection circuit (DW01A protection IC + FS8205A dual N-channel MOSFET), AP2112K-3.3TRG1 LDO regulator, USB Type-C charging port, and charge status LEDs. - **Software:** battery monitoring for low-battery fail-safe; duty-cycled ranging for battery life. ## Criterion For Success 1. Collar to wall distance error ≤0.5 m (UWB achieves 0.1 m to 0.3 m of accuracy) at 10 tape-measured test points, including through a doorway and with obstacles. 2. Feedback within 50 ms of entering the warning zone, correct vibration→tone escalation. Cats/dogs can run at 13 m/s; assuming wall deterrent radius is 1 m, we need to detect it within at least 0.077 s to avoid sprint-throughs. 3. Stable output during 15 minutes stationary on the boundary between vibration and neutral zones. 4. Fail-safe within 10 seconds if the pet gets stuck in the deterrent zone. 5. ≥24 hr collar battery life (assuming no vibrations and sound). 6. Collar weight < 60 g. |
||||||
| 3 | Menstrual Product Bathroom Tracker |
Anna Wilkowski Erin Rothenbaum Sarah Lau |
Eric Tang | Arne Fliflet | design_document1.pdf proposal1.pdf |
|
| # Menstrual Product Bathroom Tracker Team Members: - Anna Wilkowski (annaw7) - Erin Rothenbaum (eroth8) - Sarah Lau (lau29) # Problem Finding menstrual products on a college campus can be unexpectedly difficult. At UIUC, some bathrooms may have menstrual products available while others may be empty or not stocked at all. When someone unexpectedly needs a product, they may have to check multiple bathrooms or ask staff where products are located. This can be inconvenient, time-consuming, and especially frustrating when they are in a hurry. There is currently no centralized way for students to determine which campus bathrooms have menstrual products available and how much stock remains. # Solution We propose an IoT-based system that monitors menstrual-product availability in bathrooms across UIUC and makes this information accessible through an app. In boxes made specifically for the project, time-of-flight sensors would be installed on the inside of the lid; these sensors would bounce an IR light signal off the top of the period product stack, and use the time it takes for the signal to return to calculate the distance to the top of the stack from the lid. We can use the inverse of that, i.e. the distance from the top of stack to the bottom of the box (total height - distance from top of stack to lid), to measure the total height of the stack and divide by the individual height of a pad container, confirming the amount of products available. This sensor would periodically transmit its measurements to a centralized server. The mobile application would aggregate this information and display nearby bathrooms along with their estimated product availability. Users could quickly identify the closest bathroom with products rather than searching multiple locations. The system could also provide useful information to campus facilities staff. When a bathroom's supply falls below a predefined threshold, the system could automatically flag the location for restocking. # Solution Components ## Subsystem 1 - Menstrual Product Dispenser Box Description: This subsystem consists of a constructed box which holds the menstrual products. In a sense, it is meant to be a placeholder for the actual metal boxes used by the school to contain menstrual products, but can be its own standalone product. The bottom of the box may have a dispenser for products, or the lid will be removable. The lid of the box will have two Time-of-Flight sensors installed (for pads and tampons) on the underside to determine the height of the stack of menstrual items, and a transmission box installed on the side. Components: [Time-Of-Flight Sensor](https://www.digikey.com/en/products/detail/stmicroelectronics/VL53L4CDV0DH-1/16123816): VL53L4CDV0DH ([datasheet](https://www.st.com/resource/en/datasheet/vl53l4cd.pdf)) by STMicroelectronics - I2C interface: Up to 1 MHz (fast mode plus) serial bus, Address: 0x52 - Operating Voltage: 2.6 to 3.5 V - 4.4 x 2.4 x 1 mm size - Operating Temperature: -30 to 85°C - IR: 940 nm - Minimum detection distance: 0mm, Minimum ranging distance with linear response: 1mm - 90% detection rate at 450mm for low reflectance - Non-volatile memory ALSO: Status indicator LEDs, RESET button STRETCH: OLED display for showing the current projected number outside of the box ## Subsystem 2 - Transmission / Embedded System The transmission box will contain an internet-connected module (Likely via Wifi as there are no ethernet cables in the restrooms). ESP32 is needed to provide WiFi capabilities. The transmission box may also contain other components such as an SD card to track product usage information and/or the last time a box was stocked. [ESP32-S2](https://documentation.espressif.com/esp32-s2_datasheet_en.html) or [S3](https://documentation.espressif.com/esp32-s3_datasheet_en.html): - 2.4 GHz Wi-Fi 4 - BLE 5.0 (None if using S2) - 240 MHz CPU - 512 KB SRAM (320 if using S2) - Xtensa L7 - USB On-The-Go - DAC converter (only if using S2) ALSO: Battery-or-USB power circuits with protection and automatic switching, Status indicator LEDs (For Power, WiFi Connection, I2C Rx/Tx), RESET button, USB connection (firmware flash, power, data) STRETCH: SD card to save user analytics ## Subsystem 3 - Phone App The phone app will be able to display the location of restrooms with available menstrual products and the amount of pads and tampons available. The time of flight sensor will give an approximate estimation of the amount of products available. The mobile app would be created in Flutter or Android Studio. There will be a hard-coded address added at the node level and sent over wifi as the first information bit (appended to the front of the I2C data). This will allow for the app to use GPS to assign the location of the Data using the address and avoid too many WIFI protocols. # Criterion For Success - Measure menstrual product levels using compact low-power ToF sensors - Detect product usage and restocking - Wirelessly transmit sensor data - Store and organize inventory data for each bathroom - Display bathroom locations and product availability on a mobile app - Show when inventory was last updated - Allow users to report inaccurate information |
||||||
| 4 | Secure Chain-of-Custody Container |
Alp Oguz Selim Mamak Sena Tiryaki |
Alex Lee | Arne Fliflet | design_document1.pdf proposal1.pdf |
|
| **Team Members:** - Selim Mamak (smamak2) - Serdar Alp Oguz (soguz2) - Sena Bahar Tiryaki (stiry2) ## Problem Confidential engineering prototypes may need to be transported between labs, offices, and authorized employees before they are publicly released. A standard locked case can restrict access, but it provides little information about who opened it, when it was opened, or whether someone attempted to bypass the lock or tamper with the enclosure. Paper custody logs depend on users recording every interaction and can be modified after the fact. Shipping data loggers may record events such as impact or temperature but generally do not control access, while electronic lockboxes primarily focus on restricting entry rather than maintaining a detailed physical tamper and custody history. A reusable system that combines controlled access, tamper detection, and persistent event logging could provide a more complete electronic chain-of-custody record. ## Solution Overview We will build a battery-powered secure container that opens only for authorized NFC credentials and records access and physical tamper events. An electronic latch will control access, while a lid sensor, conductive tamper loop, and accelerometer will monitor the enclosure for unauthorized opening, physical damage, and significant impact events. Each event will be time stamped and stored in nonvolatile memory. Event records will be hash-linked so that modification of previously stored records can be detected when the log is exported and verified. Low-power operation will be a major engineering focus of the project. Because the container may remain unused for long periods, the design will minimize standby consumption using low-power sensing components and power gating. Higher-power components such as the NFC reader and electronic latch circuit will normally remain disabled and will only be powered when needed. The complete system will be implemented using a custom PCB containing the microcontroller, power-management circuitry, sensor interfaces, storage, NFC interface, and latch-control circuitry. ## Solution Components ### 1. Power Subsystem The container will use a protected rechargeable Li-Po battery with USB-C charging. Low-quiescent-current regulation and power gating will be used to reduce standby power consumption. The NFC reader and electronic latch circuit will normally remain powered off. A low-power wake mechanism, such as a Hall-effect sensor or pushbutton, will activate the main system when a user wants to authenticate without requiring the NFC reader to continuously scan. Low-power sensors used for enclosure monitoring will remain active while the rest of the system is in standby. The firmware will control transitions between standby, wake, authentication, latch actuation, event logging, and return to standby. Battery voltage and current consumption will be measured so that standby and active-state power consumption can be experimentally characterized. ### 2. Access Control and Tamper Sensing Subsystem An NFC reader and enrolled credentials will identify authorized users. The exact NFC reader and credential pair will be selected through early compatibility testing. The design will use authenticated credentials rather than relying only on a card UID, which would provide weaker access control. An electronically controlled latch will remain mechanically locked when unpowered and will only consume significant power during lock or unlock actuation. A Hall-effect sensor will determine whether the container lid is open or closed. A conductive tamper loop routed through protected portions of the enclosure will detect interruption caused by cutting, drilling, or other physical penetration. A low-power accelerometer will detect significant impacts above a defined threshold. Tamper and lid events will wake the control system so that suspicious activity can be time stamped and recorded even while the system is normally operating in its low-power state. ### 3. Control, Logging, and Readout Subsystem A low-power microcontroller will coordinate access control, sensing, power management, latch control, and event logging. A real-time clock with backup power will maintain accurate timestamps if the main battery is disconnected or replaced. Nonvolatile FRAM will store event records containing the event type, timestamp, and user identity when applicable. The event records will be hash-linked so that altering a previously stored record can be detected when the history is verified. A USB-C connection will allow the event history to be transferred to a computer. A simple desktop program will display the stored chain-of-custody record and indicate whether the log passes its integrity check. ## Criterion for Success 1. **Authorized Access:** The container remains locked until an enrolled NFC credential is successfully authenticated. An authorized access is recorded with the user identity and timestamp, while an unenrolled credential is denied access. 2. **Tamper Detection:** Opening the lid without authorization, breaking the conductive tamper loop, and producing a predefined significant-impact event are individually detected and recorded with timestamps. 3. **Low-Power Operation:** The completed system achieves a measured standby current below **100 µA** while the NFC reader and latch circuitry are inactive. Standby, authentication, and latch-actuation current will be measured and documented. 4. **Reliable Locking:** The electronic latch performs at least **20 consecutive authorized lock/unlock cycles** without resetting or disrupting the control electronics. 5. **Persistent Event Logging:** Stored event records remain available after complete loss of the main battery, and modifying an existing stored record causes the log-integrity verification software to report an error. 6. **Timestamp Preservation:** The real-time clock continues to maintain time during a main-battery removal and provides correct timestamps after the main system is powered again. ## Alternatives A standard mechanical lockbox provides physical access restriction but does not automatically identify users or maintain an electronic record of access and tamper events. Electronic lockboxes can provide credential-based access control, but their primary purpose is generally controlling entry rather than monitoring multiple forms of physical tampering and maintaining a persistent chain-of-custody history. Shipping data loggers provide another alternative and can measure events such as shock or environmental conditions during transportation, but they generally do not physically control access to the protected contents. Our project combines **identity-linked access control, physical tamper detection, persistent timestamped logging, and low-power battery operation** in a single reusable container intended for maintaining the custody history of confidential engineering prototypes. |
||||||
| 5 | Adaptive Power Factor Correction Device |
Luke Kang Ryan Irvin Saadullah Ehsan |
Zhuoer Zhang | Arne Fliflet | design_document1.pdf proposal1.pdf |
|
| # Adaptive PF Correction Team Members: - Ryan Irvin (ryanri2) - Luke Kang (lukejk2) - Saad Ehsan (sehsa2) # Problem Many electrical loads such as motors, transformers, and power supplies are inductive in nature, which causes current to lag behind voltage. This results in a low power factor, increased current draw, and inefficient use of electrical power within AC systems. Poor power factor leads to higher real power losses, reduced system capacity, and inefficient power delivery. Most power factor correction methods usually use fixed capacitor banks, which are not adaptive to changing loads or done at a large scale and are not achievable for small commercial tenants. As a result, they are unable to maintain an optimal power factor when loads vary over time. There is a need for a low-cost, real-time system that can measure power factor and automatically apply corrective compensation based on load conditions our project aims to achieve this with the goal of laying the foundation for a model that can be scaled up to a 480V 3phase commercial electrical panel. # Solution Our proposal is for the design and implementation of an adaptive power factor correction system that measures voltage and current waveforms in real time, computes power factor using digital signal processing, and switches capacitor banks to improve the power factor. The system operates at low-voltage AC for safety while prototyping and demo purposes while maintaining scalability for other real-world AC power systems. The system has three main subsystems: 1. Sensing (of the voltage and currents) 2. Microcontroller Unit (Processing and computation) 3. Switching stage (Switched capacitor banks for Q compensation) A microcontroller continuously samples voltage and current waveforms using ADC channels, computes real power and power factor, and determines the required capacitance for the desired PF. Capacitors are switched in discrete steps using controlled switching synchronized to the AC waveform. # Solution Components ## Subsystem 1: Sensing This subsystem measures the AC voltage and current waveforms and converts them into safe analog signals for the microcontroller. For the voltage sensing, the input is scaled down by a voltage divider and is biased to shift it into the Microcontroller’s ADC voltage range. - Components: - Resistive voltage divider components - Biasing network (mid-supply reference ~1.65V) - Potentially a filter for any signal noise For current sensing, the input would be fed into a current transformer to convert into appropriate voltage and then biased the same as the voltage for the ADC. - Components: - Current Transformer (CT), SCT-013-005 (5A:1V) The output of both sensing circuits would be a centered AC waveform with a 1-2 V peak biased around the midpoint of the MCU’s voltage range. ## Subsystem 2: MCU This subsystem processes digitized voltage and current signals to compute power factor and determine required compensation. ADC: It would first convert the signals into digital by sampling both the voltage and current at 5-10 kHz. Then, it would unbias the signals to recreate the original zero-centered waveforms. PF Calculation: After that, it would compute the rms voltage and currents then multiply them to get the apparent power (S = Vrms × Irms). Then, it would compute the real power (P = avg(v(t)*i(t))) and divide it by S to obtain the current power factor (PF = P/S). Capacitance Calculation: Once the current power factor is obtained, it would find the current reactive power Q = sqrt(S^2 - P^2). Then we find our desired apparent power by dividing the real power by our desired PF target of 0.95. Using the target apparent power, it calculates the target reactive power which is used to find the required capacitance value. We would implement a lower bound for the PF (~0.92) to prevent oscillation and rapid capacitor switching. - Components: Microcontroller (like STM32) Software for real-time sampling and computation ## Subsystem 3: Capacitive Switching This subsystem dynamically connects or disconnects capacitors to correct reactive power. The switching subsystem will take GPIO outputs from the microcontroller and safely add or remove parallel capacitance to the load to improve the power factor. To safely perform power factor correction, two major considerations must be addressed: zero-cross detection and inrush current. The switching path will be: GPIO Output -> Gate Driver -> Power Triac -> Inrush Resistor -> Capacitor The gate driver isolates the microcontroller from the AC portion of the circuit and provides the gate-trigger current needed to turn on the power triac. The power triac acts as a solid-state AC switch, connecting the capacitor to the AC circuit when triggered. The inrush resistor limits the initial current when the capacitor is switched on. We potentially may after a safe delay, have the resistor be bypassed to provide a nearly purely capacitive load in parallel for optimal power factor correction (the bypass is dependent on later calculations if it is not needed we may not implement it). A bleeder resistor is connected in parallel with the capacitor to safely discharge it after the microcontroller determines that the capacitor is no longer needed and switches it off. Components: - Capacitor bank (discrete stages, 1, 2, 4, 8… magnitude to be determined by general load size) - Power TRIACs (STMicroelectronics BTA16-600SW) - Optocoupler-based gate drivers (MOC3023 random-phase optotriac driver) - Inrush-limiting resistor (approximately 10–100 Ω, final value determined through testing) - Inrush resistor bypass switch to short inrush resistor (second TRIAC + MOC3023 driver) - Bleeder resistors (high-value resistors across each capacitor for safe discharge, while having limited effect on PF Correction) Function: - Switch capacitor stages in/out based on controller command - Safely synchronize switching with the AC waveform using zero-cross detection on the sensing subsystem and limit capacitor inrush current during initial connection - Safely discharge disconnected capacitors using bleeder resistors - Use multiple capacitor combinations to provide different levels of reactive power compensation # Criterion For Success For our project to be deemed successful we need to properly integrate all 3 subsystems and be able to demo it. This we be measurable if the following are successful: Accurate Measurements: The system can accurately measure voltage and current AC waveforms The microcontroller can accurately calculate the PF and required capacitance The microcontroller outputs are used to switch capacitive loads and dynamically adjust them. PF correction is seen on output display for user verification. Safe switching operation: Matching 0 crossings and adding hysteresis for safety of in rush Real time operation/Demo: 15V AC can be applied to a variable inductive load(potentiometer and inductor in series), and that load can be changed in real time by changing the resistive value to demonstrate real time PF correction as loads change. # Alternatives Commercial reactive power compensation systems already exist, but they are generally designed for larger installations, often above 75 kVA. Our project targets a smaller scale application, such as individual tenant electrical panels where a large commercial compensation system would not be practical. The prototype is designed as a single-phase system, but the architecture is intended to be scalable. The same sensing, control, and capacitor-switching structure could be applied independently to each phase for split-phase residential systems or 3 phase commercial tenant panels. For the ECE 445 prototype, the system will operate at approximately 15 V AC. This voltage allows the design to demonstrate the same power factor correction concepts while remaining manageable for safe laboratory development using standard bench equipment. |
||||||
| 6 | SMART GLASSES FOR HANDS-FREE DATASHEET RETRIEVAL |
Hridik Hingorani Preity Varanasi Shiv Bahl |
Yushi Zhou | Viktor Gruev | design_document1.pdf proposal1.pdf |
|
| Team Members: Hridik Hingorani Shiv Bahl Preity Varanasi Problem When working with electronic hardware, engineers frequently need to stop what they are doing to identify a component, search for its datasheet, and locate specific information such as pinouts, voltage limits, timing specifications, or recommended operating conditions. This interrupts the workflow and is particularly inconvenient when the user is soldering, probing a circuit, or otherwise using both hands. Our goal is to reduce this interruption by creating a low-cost wearable system that can identify an electronic component being viewed by the user and automatically retrieve the corresponding datasheet. Solution We propose building a pair of smart glasses containing a camera and a custom embedded PCB. When the user looks at a component and activates the system, the camera will capture an image and send it wirelessly to a laptop. The laptop will use computer vision and OCR to extract identifying information such as the component's part number or package markings. Once the component has been identified, the laptop will locate the appropriate datasheet and process it so that important information can be retrieved quickly. The result will initially be displayed on the laptop. The system is intended primarily for clearly labeled electronic components such as integrated circuits, modules, sensors, and other devices whose identifying markings can be captured by the camera. High-Level System Smart Glasses Camera → Embedded PCB → Wi-Fi Communication ↓ Laptop Image Processing/OCR → Component Identification → Datasheet Retrieval → Datasheet Processing → User Output Hardware We will design a custom PCB mounted on or integrated into the glasses. The PCB will include: ESP32-based microcontroller Camera interface Wireless communication User input for triggering image capture Power regulation Battery/power management Necessary supporting circuitry The embedded system will be responsible for capturing images, managing the camera, handling user input, and wirelessly transmitting data to the laptop. The glasses themselves will be inexpensive commercially available frames modified to hold our electronics. Software The laptop-side software will: Receive the image from the glasses. Process the image to improve readability of component markings. Use OCR/computer vision to determine the component identifier. Search for and retrieve the correct datasheet. Parse the datasheet and make relevant specifications accessible to the user. Display the component identity, datasheet, and requested information on the laptop. The LLM will only answer questions using information retrieved from the identified component's datasheet rather than relying solely on its existing knowledge. Requirements For a successful final demonstration, the system should: Capture a usable image from the wearable camera. Wirelessly transfer the image from the glasses to the laptop. Correctly identify a predefined set of clearly marked electronic components. Retrieve the correct datasheet associated with the identified component. Extract and display relevant information from that datasheet. Operate using our custom PCB rather than a standalone commercial development board. Be wearable and operate without a wired connection between the glasses and laptop. We will create a test set of electronic components and quantitatively evaluate component-identification accuracy and end-to-end response time. Stretch Goal Our stretch goal is to make the system fully hands-free after component identification by adding voice interaction. The user would be able to ask questions such as: "What is the maximum supply voltage?" "What does pin 4 do?" "What value capacitor does the manufacturer recommend here?" The system would transcribe the question, search the retrieved datasheet, and provide an answer grounded specifically in that datasheet. Future Work A future version could integrate a small near-eye or AR display into the glasses so that information could be presented directly in the user's field of view. An AR display is not part of the scope of this semester's project. Complexity The project combines several independently testable hardware and software subsystems: Custom wearable PCB design Camera interfacing Battery and power-management circuitry Wireless embedded communication Image processing OCR/component identification Automated datasheet retrieval Datasheet parsing and information extraction Integration between the embedded hardware and laptop software A major technical challenge will be reliably extracting part markings from small electronic components under different viewing angles, distances, orientations, and lighting conditions. Uniqueness Existing smart glasses and visual assistants are generally designed for broad image recognition or general-purpose AI assistance. Our project is specifically designed around electronics work. Instead of simply describing what the camera sees, the system will identify a specific electronic component, locate its technical documentation, and provide information grounded in the manufacturer's datasheet. The project therefore combines a purpose-built wearable embedded platform with a specialized datasheet retrieval and processing pipeline. Scope The core project will focus on labeled electronic components and laptop-based output. We will not attempt to recognize every possible component or construct an AR display during this semester. Restricting the identification problem to a controlled but varied set of components allows us to quantitatively evaluate the system while still addressing the major technical challenges of wearable image acquisition, wireless communication, component identification, datasheet retrieval, and system integration. |
||||||
| 7 | Adaptive Light-Filtering Glasses |
Jahnavi Thejo Prakash Kewal Ghosalkar |
Lukas Dumasius | Viktor Gruev | design_document1.pdf proposal1.pdf |
|
| # Team Members: - Kewal Ghosalkar (kewalkg2) - Jahnavi Thejo Prakash (jahnavi7) # Problem People around the world struggle with photosensitive epilepsy, migraines, TBI, and other such photosensitive medical conditions that increase sensitivity to light. Intense flickering lights can worsen sensitivity and in some cases also lead to convulsions and seizures. Current solutions include remedies like avoiding triggers, or using tinted glasses. In unfamiliar situations, these passive solutions can prove to be unreliable since they cannot update dynamically. # Solution We propose adaptive smart glasses that can detect lighting conditions that may trigger such photosensitive conditions and adapt the tint on the lenses accordingly. The glasses can also provide warnings and possibly contain a system to detect seizures. # Solution Components ## Optical Attenuation Subsystem - LCD light valve attached to the lenses of the glasses. These can darken proportionally to the perceived level of risk. ## Sensor Subsystem - Set of 3 photodiodes for detecting the intensity of incoming light. - Wide FOV photodiode placed in the front for measuring ambient light brightness - Narrow FOV photodiode placed in front to measure light incident on the users eyes - Feedback photodiode placed behind the lenses to measure the actual light exposure on the user's eye. This provides feedback for a closed feedback loop to make adjustments based on the attenuation of the LCD light valve on the lenses. - Transimpedance amplifiers for each of the 3 photodiodes in the sensor subsystem to utilize the full range of the ADC ## Processing Subsystem - STM32L series microcontroller, with an internal ADC sampling rate of 1000 Hz, which is large enough to avoid aliasing within the Epilepsy ranges of 3-60Hz - Signal processing will first estimate and remove average brightness or DC component from each signal in the amplifier results. A band-pass filter will remove slower flicker changes caused by movements and noise. An FFT & modulation depth measurements will determine the frequency and strength of the dominating flicker. - Similarity flicker frequency checks will run for the two forward facing photodiodes over several sampling windows. If risk is detected, the lens will become more attenuated and adjustments will be made based off of the flicker magnitude on the behind-lens sensor with a close loop feedback system. ## Power Subsystem - Single LiPo to power the entire system. - Boost converter to step up 3.7V of the LiPo to 5V for the Light valve. - 3.3V LDO for the STM32, photodiodes and amplifiers. - USB C charging. - The Power subsystem will live on a separate hip mounted pack out of concerns for weight, space and safety. # Criterion For Success - Our solution can be considered successful if the glasses can: - Accurately detect epilepsy triggering frequencies around 3 to 60Hz with an accuracy of at least 80% - Accurately reject non-hazardous changes in light caused my sudden movements or environment changes with a false positive rate of less than 10% - Assign a replicable risk score to each situation and activate the optical attenuation system within 0.5s of hazardous inputs - Have a reasonable battery life for daily use of around >8 hours on a single charge. # Alternatives A paper titled “EpilepSee” from 2024 attempts to build a device very similar to ours, however there are a few improvements we are trying to make: - The sampling frequency in the paper was limited to 40Hz which can lead to aliasing at flicker frequencies above 20Hz leading to faults in signal processing. We plan on using a much higher sampling frequency at around 1 kHz to avoid aliasing. - The paper is measuring light inputs using a single sensor, we want to use multiple sensors to provide more data for signal processing. - The device in the paper is a prototype and is not very portable. We are attempting to make our design more portable, hence more comfortable for use. - The paper uses an open loop design. We are going to use a closed loop design which should allow for more precise attenuation The response time for the device in the paper is 1-1.5s, we plan on having a much faster response time of <0.5s # Extensions - The ability for the users to input the exact frequencies they are susceptible to. This can be done through Bluetooth or with an extra serial debugger module to input this data. - An IMU can monitor for seizure-like body movements and trigger a safety response, alerting the user’s emergency contact. - A display that provides a warning before any optical attenuation takes place and allows users the option for manual overriding. # Links - [EpilepSee Paper](https://ora.ox.ac.uk/objects/uuid%3Aabb3258d-264e-42e0-8967-40408397f96f/files/scj82k980j) - [Small Liquid Crystal Light Valve – The Pi Hut](https://thepihut.com/products/small-liquid-crystal-light-valve-controllable-shutter-glass) |
||||||
| 8 | Accurate Pick and Place Arm |
Ian Chan Michael Talapin Nithin Durgam |
Abdullah Alawad | Viktor Gruev | design_document1.pdf proposal1.pdf |
|
| # Accurate Pick And Place Robotic Arm Team Members: - ndurgam2 (Nithin Durgam) - ianchan2 (Ian Chan) - talapin2 (Michael Talapin) # Problem With the rapid growth of automation, robotic arms are becoming increasingly common in manufacturing facilities, research laboratories, and other environments that require precise and repeatable manipulation. Our goal is to design and build an accurate pick-and-place robotic arm and demonstrate its capabilities using a chessboard. A chessboard provides a challenging and intuitive test of the system’s precision. To reliably pick up and place individual chess pieces without disturbing the surrounding pieces, the arm’s end-effector must achieve approximately 1 mm of positional accuracy. Reaching this level of precision requires every part of the system (mechanical design, electrical components, computer vision pipeline, kinematics, and control algorithms) to work together accurately and consistently. Our primary demonstration will allow a user to select any chess piece or position on the board and specify a destination. The robotic arm will then identify the requested location, pick up the piece, and place it at the desired position while avoiding interference with nearby pieces. If time permits, we would like to extend the project by allowing the robotic arm to autonomously play a complete game of chess against a human opponent. This would add another layer of complexity by combining the arm’s existing perception and manipulation capabilities with board-state recognition, move planning, and a chess engine. Since accuracy is the goal and not speed, we will follow a 5+10 and 10 + 10 format. # Solution At a high level, our goal is to avoid the complexity and cost associated with traditional multi-joint robotic arms, where every additional degree of freedom requires another motor, sensor, and control system. Instead, we plan to use a simpler and more elegant mechanical architecture designed specifically around the requirements of the task. The arm will consist of two links that provide planar motion across the x-y plane, while the end-effector moves vertically along the z-axis to pick up and place chess pieces. On the electrical side, custom PCBs will integrate sensors such as magnetic encoders and Hall-effect sensors to accurately determine joint position and provide reliable feedback for the control system. The software stack will tie the entire system together. Closed-loop PID controllers will provide precise joint positioning, while a computer vision pipeline will identify chess pieces and determine their locations on the board. These positions will then be converted into robot coordinates and passed through the inverse kinematics system to determine the joint commands required to move the end-effector to the desired location. # Solution Components ## Mechanical Design The mechanical architecture of the robotic arm consists of three actuated joints: Joint 0, Joint 1, and the Z-axis joint. Joint 0 will use a NEMA 34 motor, Joint 1 will use a NEMA 23 motor, and the Z-axis joint will use a NEMA 14 motor. The overall goal of the mechanical subsystem is to provide a rigid, accurate, serviceable, and easily accessible structure while creating enough space for the electrical hardware, sensors, PCBs, and wiring required by the rest of the system. Because the electrical and software subsystems depend heavily on the physical geometry of the robot, mechanical accuracy and repeatability are critical. Joint 0 is located at the base of the arm and provides the first rotational axis. Because this joint must move the combined mass of the remaining arm, end-effector, motors, and payload, it will experience the largest torque requirements and will therefore use a NEMA 34 motor. The base will also contain the primary power distribution hardware for the system. Adequate space should be provided for power distribution, the PCBs, terminal blocks, protection circuitry, connectors, and cable routing. Communication and programming interfaces should also be externally accessible so that a computer can connect to the robot without requiring the enclosure to be opened. An overhead camera mount will extend from the rear of the base and position the camera above the chessboard. This structure must be rigid and accurately positioned because the computer vision system depends on a known transformation between the camera and robot coordinate frames. Movement or misalignment of the camera could introduce errors that propagate through the vision, inverse kinematics, and motion-control systems. The mount should therefore provide a repeatable camera position and allow for calibration when necessary. Joint 1 provides the second rotational axis required for planar x-y motion. This joint will use a NEMA 23 motor and must maintain high structural stiffness while minimizing backlash and mechanical play. The surrounding arm structure must provide enough internal space for encoders, Hall-effect sensors, and wiring. Cable routing should prevent wires from being pinched, excessively bent, or interfering with joint movement. Serviceability is also an important design requirement. Components located around Joint 0 and Joint 1 should be accessible through removable covers or panels so that faulty electronics or sensors can be replaced without significantly disassembling the arm or disturbing its alignment. Bearings should support the primary mechanical loads rather than relying entirely on the motor shafts. The Z-axis joint provides vertical motion for the end-effector and will use a NEMA 14 motor. A lead screw, linear rail, or similar mechanism can be used to provide controlled vertical movement while minimizing lateral play. The required travel distance should allow the end-effector to clear the tallest chess piece and safely move across the populated board. The end-effector should also provide some mechanical tolerance for small positioning errors produced elsewhere in the system. A wider capture range, tapered gripping surfaces, or compliant features could help guide slightly misaligned pieces into the gripper. Additional mechanical requirements that should be defined include joint ranges of motion, link lengths, payload capacity, allowable backlash, z-axis travel, mechanical end stops, cable strain relief, motor cooling, bearing selection, and clearly defined mechanical reference points. These specifications will directly affect motor sizing, forward and inverse kinematics, computer vision calibration, and the overall positioning accuracy of the robot. ## Electrical/PCB Design The electrical and PCB subsystem acts as the bridge between the robot’s mechanical hardware and software. Its two primary responsibilities are motor/joint control and power distribution. The overall goal is to provide the software with reliable sensing and communication interfaces while safely distributing power throughout the arm. For motor and joint control the current design will use NEMA 23 stepper motors paired with MKServo57D CAN motor drivers. CAN will serve as the primary communication bus across the robot, allowing the Jetson, custom PCBs, and motor drivers to communicate over a shared network. This reduces wiring complexity and provides a robust communication architecture that can be expanded as additional sensors or joints are added. Each joint will also require accurate position feedback. Magnetic encoders will be incorporated to measure joint position with sufficient resolution for precise end-effector positioning. Hall-effect sensors or limit switches will also provide known mechanical reference positions during startup and calibration. These reference sensors remain useful even when absolute encoders are used because certain encoders, such as the AS5047P, may require a known physical position when establishing or verifying their zero offset. The custom PCB in the arm will interface with these sensors, handle signal conditioning where necessary, and communicate sensor information to the Jetson over CAN. The electrical architecture should also include accessible debugging and programming interfaces to simplify testing and component replacement. The second major responsibility is power distribution. A central power-distribution system located within the base will take power from a single external source, a laboratory power supply, and distribute it to the different voltage domains required throughout the robot. The primary rails are expected to include 24 V for the stepper motors, **5 V for servos (if used) or sensors that require 5v, and 3.3 V for low-voltage sensors and PCB logic. The Jetson will utilize its own wall plug, since it will not be directly located in the arm and will just plug into the CAN interface. A small OLED status display may also be incorporated into the base to display information such as joint states, CAN connectivity, faults, and power status. Alternatively, these diagnostics may be presented through a locally hosted software dashboard. ## Software Subsystem The software subsystem is critical to the overall accuracy, reliability, and robustness of the robotic arm. It can be divided into three primary components: the state machine, the computer vision pipeline, and the joint control system. The goal of this subsystem is to coordinate the complete pick-and-place operation while minimizing positioning error and ensuring that the robot behaves predictably under different operating conditions. The state machine manages the sequence of actions required to move a chess piece. A typical operation begins by identifying the requested piece, either from a user command or, as a stretch goal, from a chess engine. The vision system determines the piece's position, after which inverse kinematics calculates the required Joint 0 and Joint 1 positions. The arm then moves above the piece, lowers the Z-axis end-effector, secures the piece, raises it to a safe clearance height, moves to the destination, lowers and releases the piece, and finally returns to a home position where the camera has an unobstructed view of the board. Each state will contain specific completion conditions and fault checks before transitioning to the next state. This structure keeps the software organized while making debugging and error recovery significantly easier. The computer vision pipeline is responsible for detecting and classifying chess pieces and determining their positions relative to the robot. An overhead camera will capture the chessboard, and a custom vision model will identify each piece and determine its location. Camera calibration and coordinate transformations will then convert image-space measurements into the robot's coordinate frame. If a stereo camera is used, depth information can provide additional distance measurements, although the known geometry of the chessboard may also be used to determine positions. These coordinates will then be passed through the inverse kinematics system to generate target joint positions. If the chess-playing stretch goal is implemented, the detected board state will also be provided to a chess engine, which will determine the desired move and detect game-ending conditions such as checkmate. Finally, the joint control system ensures that each commanded joint reaches and maintains its desired position within an acceptable error tolerance. Closed-loop PID controllers will use encoder feedback to continuously compare commanded and measured joint positions and correct deviations. A startup homing and zeroing procedure using Hall-effect sensors, limit switches, or encoder reference positions will establish a consistent robot coordinate frame each time the system powers on. Together, these components provide the perception, decision-making, and low-level control required for accurate and repeatable pick-and-place operation. # Criterion For Success * Achieve end-effector positioning accuracy within 1 millimeter. * Successfully pick and place chess pieces without collisions. * Correctly identify and localize all chessboard pieces. * Repeat commanded motions consistently across extended operations. * Establish accurate joint zero positions after every startup. * Complete pick-and-place sequences without manual intervention. |
||||||
| 9 | Dieagnosis |
Josh Hartman Megan Zeng The Minh Pham |
Yushi Zhou | Arne Fliflet | design_document1.pdf proposal2.pdf |
|
| # Automated Optical Wafer Inspection System Team Members: - Megan Zeng (meganlz2) - Josh Hartman (joshh3) # Problem In ECE 444, wafers are inspected under a microscope after fabrication steps to make sure the process was completed correctly. Since a wafer can contain dozens of dies and hundreds of devices, it is not practical to inspect every device after every fabrication step. Instead, only a small number of locations are usually inspected, and the rest of the wafer is assumed to be similar. This can make it difficult to determine why a device fails after fabrication. For example, a problem with photoresist removal, etching, or deposition may affect a region of the wafer without being noticed during manual inspection. If the problem is only discovered during electrical testing, it can be difficult to determine which fabrication step caused it. An automated inspection system could scan a much larger portion of the wafer after each fabrication step and identify regions that differ from the expected surface condition. This would provide additional information about where a fabrication problem may have occurred without requiring manual inspection of the entire wafer. # Solution We propose an automated optical wafer inspection system that uses a laser and photodiode to measure the optical response of different locations on a wafer. A low-power laser will illuminate the wafer, and a photodiode will measure reflected or scattered light from the surface. The measured signal will be compared against a baseline from an "ideal" wafer. Differences in the measured signal can indicate changes in the surface caused by fabrication anomalies. The wafer will be mounted on an X-Y stage that moves it through a grid of measurement locations. The laser and photodiode will remain fixed while the wafer moves underneath them. A microcontroller will control the stage, collect measurements from the photodiode, and record the measurement location. The measurements will then be sent to a computer, where they will be compared against the baseline and displayed on a map of the wafer. The system will be enclosed to reduce the effects of ambient light and keep the optical components in fixed positions. One intended application is inspecting a wafer after photoresist removal to identify regions where resist may remain before the wafer proceeds to a thermal processing step. Removing PR before a furnace step is important because PR can both severely contaminate the furnace and ruin sections of the wafer. Other surface anomalies may also be detectable depending on the optical response of the wafer at different stages of fabrication. # Solution Components ## Subsystem 1: Optical Sensing The optical sensing subsystem will illuminate the wafer and measure the reflected or scattered light. A low-power laser will be used so that the system can provide a consistent optical measurement at a small, localized point. Lenses may be used to control the size and focus of the laser spot on the wafer, depending on the results of initial testing. The subsystem will contain: - Laser: 650nm 5mW laser, specific part will be chosen based on cost and availability - Photodiode: Vishay BPW34 - Transimpedance amplifier: Texas Instruments OPA380 - Filtering: RC low-pass filter - Optical components: Lens and mounts for the laser and photodiode The photodiode will produce a current based on the amount of incident light. The transimpedance amplifier will convert this current into a voltage that can be measured by the microcontroller. Filtering will be used to reduce noise in the measurement. The exact optical geometry and lens configuration will be selected during development based on the measured signal strength and repeatability. ## Subsystem 2: Wafer Motion and Positioning The motion subsystem will move the wafer through a predefined scan pattern and allow each optical measurement to be associated with a location on the wafer. The subsystem will contain: - Stepper motors: NEMA 17 stepper motors - Motor drivers: Texas Instruments DRV8825 - Position sensors: Mechanical limit switches - Stage: Custom X-Y motorized stage - Wafer holder: Custom holder for a 4-inch wafer The stage will be brought to a known origin using the limit switches before a scan begins. The microcontroller will then move the wafer to each measurement location based on the number of commanded motor steps. The system will pause briefly after each movement before taking a measurement so that vibrations from the motor do not significantly affect the optical measurement. ## Subsystem 3: Data Acquisition and Control The data acquisition and control subsystem will control the scan, collect the photodiode measurements, and communicate with the computer. The subsystem will contain: - Microcontroller: STM32G474RET3 - ADC: Integrated in the MCU - Motor control: Digital step/direction outputs for the DRV8825 drivers - Limit switch inputs: Inputs for bringing stage to origin - Communication: USB or UART connection to a host computer - Custom PCB: Contains the microcontroller, optical sensing circuitry, motor interfaces, and power regulation The microcontroller will control the motors and take one or more photodiode measurements at each scan location. Each measurement will be stored along with the corresponding X-Y position and then transmitted to the host computer. ## Subsystem 4: Data Processing and Wafer Mapping The data processing subsystem will process the collected measurements and produce a map of the wafer. The subsystem will contain: - Host computer - Python data processing software - Python-based wafer mapping and visualization A baseline scan will be used to determine the expected optical response for an ideal wafer condition. Measurements with a significant difference from the baseline will be marked as anomalies. The software will associate these measurements with their positions on the wafer and display the results as a two-dimensional map. ## Subsystem 5: Enclosure The subsystem will hold the wafer, stage, laser, and photodiode in fixed positions while limiting ambient light reaching the photodiode. The subsystem will contain: - Enclosure: Custom machined housing - Mounts: Mounts for the laser and photodiode. Possibly integrated into the enclosure The enclosure will provide an environment for optical measurements and reduce noise caused by ambient lighting. # Criterion For Success 1. Wafer positioning: The system will automatically move a 4-inch wafer through a predefined scan grid and return to a known home position. 2. Measurement repeatability: Consecutive measurements taken at the same wafer location under identical conditions will not have large swings (within 10% of each other). 3. Optical anomaly detection: The system will distinguish between two wafer surface conditions with a measurable difference in optical response. 4. Spatial mapping: The system will record the X-Y location of every optical measurement and generate a two-dimensional map covering the scanned region of the wafer. 5. Ambient-light rejection: With the enclosure installed, changes in ambient lighting will cause insignificant change (less than 5%) in the photodiode measurement. |
||||||
| 10 | Automatic Music-Reactive Lighting System |
Annie Mak Disha Ghosh |
Eric Tang | Cunjiang Yu | design_document1.pdf proposal1.pdf |
|
| # Automatic Music-Reactive Lighting System Team Members: - disha4 - anniexm2 # Problem Lighting plays a large part in setting the mood at events and small gatherings. However, manually adjusting colors, brightness, and movement to match a song requires constant attention. Preset effects may also miss changes in the rhythm or energy of the music. We want to create a device that automatically matches detected musical notes to colors, follows the rhythm through lighting effects, and adjusts brightness based on volume. The device should be simple to use and allow users to customize how the lighting responds to music. # Solution We propose an automatic lighting device with a microphone, a high-power RGBW LED light head, and a custom control PCB. The microphone will capture nearby music, and the microcontroller will estimate pitch, detect changes in audio energy, and measure volume. The device will start in an automatic mode without requiring a phone connection. The microcontroller will map estimated fundamental frequencies to musical notes and their assigned colors. Changes in audio energy will trigger lighting pulses, while the measured signal amplitude will control brightness. Pulse-width modulation (PWM) will independently control the red, green, blue, and white LED channels to produce mixed colors and smooth transitions. When the pitch estimate falls below a confidence threshold, the system will briefly hold its previous color to prevent unstable switching. The main focus will be audio processing, RGBW lighting, physical controls, and operation from our custom PCB. If time allows, we will add motors to move the light and Bluetooth controls to customize the settings! # Solution Components ## Main Control PCB Subsystem The custom PCB will connect and control the audio, lighting, and user interface subsystems. A Nordic nRF52832 microcontroller will process microphone samples and determine how the lights should respond. The software will check whether a pitch estimate is clear enough before changing the color. This will help prevent the light from rapidly switching between uncertain estimates. The final system will use individual chips and supporting circuitry mounted on our PCB rather than development boards. Components: - Nordic nRF52832-QFAA-R7 microcontroller IC - Clock crystal and supporting components - Programming and debugging header - Supporting resistors, capacitors, and connectors - Antenna circuitry if Bluetooth is included ## Audio Subsystem A microphone and amplifier circuit will capture nearby music and produce a signal the microcontroller can read. The circuit will amplify and filter the microphone output and keep it within the microcontroller’s input voltage range. The software will estimate the pitch of clear sounds and match it to the nearest musical note. Changes in audio energy will trigger lighting pulses, while volume will control brightness. Adjustable sensitivity will help reduce unwanted responses to background noise. Components: - PUI Audio POM-3535P-3-R electret microphone - Microchip MCP6002-I/SN operational amplifier - Bias and gain-setting resistors - Coupling and filtering capacitors ## Lighting Subsystem The light head will use a high-power RGBW LED to project colored light onto a nearby wall or surface. Controlling the four channels separately will allow us to create mixed colors and smooth transitions. Constant-current drivers will control the LEDs, and a heat sink will remove heat. A mixing optic will help blend the colors. We will choose the final LED operating currents and heat sink based on the brightness we need and the temperature measured during testing. Components: - Cree XLamp XM-L Color Gen 2 RGBW LED, with exact part number pending - TPS92512DGQR LED driver ICs, one per independently controlled color channel - Driver inductors, diodes, resistors, and capacitors - LED mounting PCB - Heat sink and thermal interface material - Mixing optic and light-head housing ## Power Subsystem An external DC adapter will power the device. We initially plan to use a 12 V input for the LED drivers, with regulated 5 V and 3.3 V supplies for any included motors and the control electronics. We will select the power supply based on the current needed by the LEDs, control circuit, and motors. Filtering and careful PCB layout will help prevent the lighting and motor currents from interfering with the microphone signal. Components: - External 12 V DC power adapter, with current rating selected after power calculations - LMR51430 buck regulator for the proposed 5 V supply, depending on motor current requirements - AP2112K-3.3TRG1 regulator for the 3.3 V supply - Power connector and switch - Input protection components - Filtering capacitors and test points # Additional Features ## Motion Control Subsystem If time allows, we will add positional servo motors to rotate or tilt the light head in response to rhythmic changes. We will start with side-to-side movement and add up-and-down tilt if the first axis works reliably. The motors will be selected based on the weight and balance of the LEDs, housing, and heat sink. Movement speed and travel will be limited to prevent the light head from hitting the housing or pulling on its wiring. Components: - Positional servo motors, with exact part numbers selected after load calculations - Rotation or pan-and-tilt brackets - Mounting hardware - Flexible wiring and strain relief ## User Interface Subsystem The device will have physical buttons or a knob to adjust brightness and microphone sensitivity. This will allow users to change basic settings without connecting a phone. If time allows, we will add a Bluetooth app using the nRF52832. The app would let users change the note-to-color assignments, sensitivity, brightness, and any included movement settings. Components: - Physical buttons or adjustment knob - Supporting resistors and capacitors - Bluetooth functionality through the nRF52832-QFAA-R7 if included - Optional phone app # Criterion For Success The project will be considered successful if it can: - Automatically respond to nearby audio without a phone connection or external computer. - Display the correct assigned color in at least 90% of repeated individual-note tests across one selected octave. - Change to the assigned color within 250 milliseconds after a sustained test note begins. - Produce a lighting pulse for at least 90% of the events in a test track with evenly spaced percussive sounds. - Produce increasing brightness when the same audio is played at three increasing volume levels from a fixed distance. - Control all four LED channels independently and demonstrate fades between assigned colors. - Run from the custom PCB for at least 15 minutes without resets or exceeding the components’ operating temperature limits. If Bluetooth is included, users should be able to change brightness, sensitivity, and color assignments while the device continues running. |
||||||
| 11 | Digitally-Controlled Isolated DC-DC Converter for Automotive Applications |
Curtis Lam Jayden Dang Mark Sorial |
Lukas Dumasius | Cunjiang Yu | design_document1.pdf proposal1.pdf |
|
| # Digitally-Controlled Isolated DC-DC Converter for Automotive Applications **Team Members:** - Curtis Lam (cjlam2) - Mark Sorial (msorial2) - Jayden Dang (jtdang2) ## Problem Automotive 48V-100V mild-hybrid architectures need to step down to the 12V rail that powers legacy electronics, while maintaining galvanic isolation between the two domains for safety and noise immunity. Existing solutions often rely on analog control loops that are inflexible, hard to tune, and lack the telemetry/fault reporting needed for modern automotive diagnostics (e.g., CAN-reportable fault codes). We propose a digitally controlled isolated DC-DC converter using a half-bridge topology, demonstrating a control and magnetics design approach that scales toward higher-voltage (e.g., 400V-to-48V-class) automotive systems, implemented and validated at a reduced-voltage scale (48V-to-12V) for lab safety. ## Solution We will design and build an isolated DC-DC converter using a half-bridge topology, chosen for its efficient transformer utilization and straightforward scaling path to higher input voltages via component re-rating and turns-ratio adjustment. All primary-side switching, closed-loop voltage/current regulation, and protection logic will be implemented digitally on a microcontroller, with no analog compensator ICs, so the control firmware is the portable, scalable part of the design. Rectification on the secondary side will be Schottky diodes for bring-up, with MCU-timed synchronous rectification planned as a stretch goal. A central focus of the project is the transformer design itself: core selection, turns ratio, winding construction, and leakage inductance management for a half-bridge-driven isolated converter. The prototype will target a DC-DC conversion of 48V to 12V at 100W. The design breaks down into five subsystems: digital control, sensing, the isolation barrier and isolated power, the power stage, and telemetry. ## Solution Components ### STM Digital Control An STM32H743 (480MHz Cortex-M7) runs the whole converter, chosen for its timer and ADC peripherals plus prior experience with the chip. Its high-resolution timer (HRTIM) clocks at 480MHz. The 16-bit ADCs run at 12-bit for speed (6.25Msps), sampling Vout and Iout simultaneously on an HRTIM trigger. The STM32H743 also has 2x native FDCAN peripherals for fulfilling our CAN Telemetry requirements. **Part numbers (subject to change):** - STM32H743 ### DC/DC Sensing Based on our control algorithm, we will need to sense different parts of the input and output of the power converter, namely Vout and Iout. We will use shunt resistors and current sense amplifiers along with the ADCs on the STM32 to provide analog data at the bandwidth we need for our control algorithm. Input voltage is measured across the isolation barrier with an isolated amplifier so the controller can enforce undervoltage lockout and report Vin over telemetry. We will also add both hardware and software fault detection to prevent any issues while debugging. **Part numbers (subject to change):** - Current sense amplifier: TI INA185 - Isolated input voltage sense: TI AMC1311 - Board temperature: TI TMP61 thermistors at the transformer and MOSFETs ### Isolation Barrier/Power The isolation barrier provides safety and noise rejection between the "high" voltage side and the low voltage side. In automotive applications, these two power domains must always be galvanically isolated, so a fault on the high-voltage bus can never reach the 12V electronics. Only four paths cross the barrier in our design: the main transformer, the gate-drive signals, the input voltage sense, and the isolated bias power. That bias supply provides the logic rails for our detection and gate-drive circuitry before the main output exists. On the PCB, the two domains get separate ground planes with a copper keepout strip between them, and we will verify barrier integrity with a resistance test at bring-up. **Part numbers (subject to change):** - Isolated gate driver: TI UCC21520DW - Gate-drive bias: Murata MGJ2D051505SC - Startup logic bias: RECOM REC3.5-4805SRW/R ### Power Stage The power stage chops the input bus into an alternating square wave across the transformer primary using a half-bridge switching cell, transferring power magnetically to the "low voltage" side, where it is rectified and filtered back to DC. The transformer is a custom design and one of the main deliverables of the project: core material and size, turns ratio, winding construction, and leakage inductance all have to be worked out together. The turns ratio in particular has to hold regulation across the full 20V-60V input range, which sets the usable duty cycle window and drives the rest of the magnetics design. **Part numbers (subject to change):** - Half-bridge MOSFETs: TI CSD19532Q5B (100V) - Transformer core: TDK N49 or Ferroxcube 3F36 ferrite, ETD29 or PQ26/25 size, wound in-house with litz wire - Rectifiers: ON Semi MBR20100CT Schottky (baseline); TI CSD18540Q5B sync FETs if we reach the synchronous rectification stretch goal - Output filter: ~3.3uH inductor (Coilcraft SER2915H class) plus polymer/ceramic capacitor bank ### Telemetry The converter should act as a modern automotive ECU with a CAN-FD interface running at 1Mbps arbitration rate and 4Mbps data rate. This provides enough bandwidth to telemeter statistics about the converter, control algorithm internals, housekeeping monitoring, and faults. Messages include a periodic heartbeat with the converter state machine state, measurement frames (Vin, Vout, Iout, power, temperatures), and event-driven fault frames that report which protection tripped and the value at the moment of the trip. We will publish a DBC file for the message set and interface with the bus from a host PC with an OTS CAN Viewer, so no custom decode software is needed to verify the telemetry. **Part numbers (subject to change):** - CAN transceiver: TI TCAN1042HGV (CAN FD to 5Mbps) - Host interface: Canable 2.0 Serial Adapter ## Criterion For Success ### High-level goals - Regulated 12V average output, within ±5%, across the full load range - Operation across a 20V - 60V input range - 90% efficiency at 50W, 48V input, measured with calibrated instruments - Output ripple below 5% peak-to-peak at full load - 100W continuous output at thermal steady state (below 60°C) - 100Hz CAN telemetry, decodable in a CAN Viewer with our published DBC ### Stretch goals - 250W output - Ripple below 1% - Synchronous rectification, with a measured efficiency improvement over the Schottky baseline - Standalone telemetry viewer application - Variable output voltage, commanded over CAN ### Testing/Demo The board will have test points along the power path plus the gate drives and logic rails. We will test with a current-limited bench supply on the input, an electronic load on the output, and an oscilloscope with differential probes for anything on the primary side. We will also use the CAN telemetry itself for validation by comparing reported Vin, Vout, and Iout against the bench instruments. For the demo, the converter powers the e-load with live telemetry in a CAN Viewer, we sweep the input and step the load to show regulation on the scope, and force an overcurrent to show the hardware shutdown and fault reporting over CAN. |
||||||
| 12 | Automatic Solder Fume Extractor Positioning System |
Franklin Liu Noah Zhang Yubo Wu |
Pusong Li | Arne Fliflet | design_document1.pdf proposal1.pdf |
|
| # Automatic Solder Fume Extractor Positioning System Team Members: - Yubo Wu (yubowu2) - Noah Zhang (noah7) - Franklin Liu (fl26) # Problem Local fume extractors used during hand soldering must be positioned close to the active soldering location to effectively capture fumes. When working across larger circuit boards or repositioning a workpiece, the extraction hood may need to be repeatedly moved. This interrupts the soldering workflow and can result in the hood being left too far from the active soldering area. # Solution We propose a motorized fume extractor arm that automatically positions the extraction hood near the active soldering location. A thermal sensor mounted near the extraction hood will detect the heated soldering iron and determine its position relative to the center of the extraction region. A microcontroller will use this information to control a two-link planar arm and follow the soldering iron across the work surface. The planar arm will use an existing SCARA-style mechanical design as the basis for its structure, modified to support the extraction hood and sensing hardware. The entire planar arm will also move vertically using a motorized linear axis. A distance sensor mounted near the hood will measure the distance to the work surface, allowing the system to maintain a desired extraction height automatically. A commercially available fume extractor will provide airflow through a lightweight flexible hose connected to the moving hood. # Solution Components ## Subsystem 1: Thermal and Distance Tracking A Melexis MLX90640ESF-BAB-000-TU 32 × 24 thermal sensor array will be mounted near the extraction hood and directed toward the work surface. The thermal image will be processed by the microcontroller to identify the heated soldering iron and determine its displacement from the desired extraction location. A VL53L1X time-of-flight distance sensor will measure the distance between the extraction hood and the work surface. This measurement will be used to control the vertical position of the hood. ## Subsystem 2: Motorized SCARA Arm The extraction hood will be mounted to a two-link planar SCARA-style arm with two powered rotary joints. The mechanical structure will be adapted from an existing open-source SCARA arm design. The two planar joints will be driven by NEMA 17 stepper motors. The entire planar arm will be mounted on a motorized vertical linear stage driven by a third stepper motor and lead screw. Three D2F-01L-A microswitches will provide home-position references for the two planar joints and vertical axis. The arm links, sensor mounts, and extraction hood mounting components will be 3D printed. A lightweight flexible hose will connect the moving hood to the fume extractor. ## Subsystem 3: Control and Power PCB A custom PCB will control the sensing and motion systems. The board will contain: - ESP32-S3-WROOM-1 microcontroller - Three TMC2209-LA stepper motor driver circuits - Interfaces for the MLX90640 thermal sensor and VL53L1X distance sensor - Interfaces for the three D2F-01L-A home-position sensors - 12 V DC power input and motor power distribution - Voltage regulation for low-voltage logic - Hardware emergency-stop circuitry that disables the motor drivers # Criterion For Success - The thermal sensing system will correctly detect a heated soldering iron within the defined tracking region in at least 90% of test cases. - The planar arm will automatically move the extraction hood to keep the detected soldering iron within a predefined central region over the designed workspace. - The system will maintain the extraction hood within a horizontal and vertical distance from the soldering location that is experimentally demonstrated to provide effective fume capture. - The vertical positioning system will automatically maintain the extraction hood within a predefined distance range from work surfaces at multiple tested heights. - Activating the hardware emergency stop will disable all three motor axes independently of the microcontroller software. # Stretch Goals - Automatically control the fume extractor based on whether active soldering is detected. - Adjust extractor airflow based on the distance between the hood and the soldering location. |
||||||
| 13 | Tennis Ball Collector |
Mohammed Alnasser Yousef Khojah Zeyad AL Ruwaily |
Junyan Bai | Cunjiang Yu | design_document1.pdf proposal1.pdf |
|
| **# Tennis Ball Collector** **Team Members:** Mohammed Alnasser (ma138) Yousef Khojah (yousefk2) Zeyad Alruwaily (zeyadta2) **Problem:** A lot of time during tennis practice is spent picking up tennis balls instead of actually playing. After a drill, players or coaches usually have to walk around the court and collect the balls one by one. This becomes especially inconvenient when a coach is running a practice alone or when there are multiple courts being used. There are already some ball collection options, such as manual ball hoppers, but these still require someone to operate them. Autonomous ball-collecting robots also exist, but they can be expensive. Our goal is to build a smaller and more affordable robot that can collect tennis balls on its own and reduce the amount of time spent picking them up. **Solution:** We will build a small battery-powered robot that can move around a tennis court, detect tennis balls, and collect them into an onboard hopper. The robot will use a camera to locate the balls and help identify the court boundaries. A microcontroller will use this information, along with data from sensors on the robot, to control the motors and decide where the robot should move. When the robot does not see a ball, it will systematically move across the court to search for them. When it detects a ball, it will drive toward it and use a roller mechanism to pull the ball into the hopper before continuing its search. The robot will also have sensors for detecting obstacles and the court boundaries. A wireless connection will allow the user to start and stop the robot and view basic information such as its battery level and number of collected balls. The project will be divided into three main areas: vision and navigation, power and drive, and ball collection and storage. **Main Components:** **Vision and Navigation** A camera with onboard image processing will be used to detect tennis balls and identify the court boundaries. The STM32 microcontroller will use this information along with an IMU and wheel encoders to control the robot's movement. The robot will follow a back-and-forth search pattern to cover the court. When a ball is detected, it will temporarily leave its search path, collect the ball, and then continue searching. We will also use separate sensors to detect the court boundary and help prevent the robot from leaving the designated area. This gives us a backup in case the camera does not correctly detect a boundary. **Power, Drive, and Communication** A rechargeable battery will provide power to the robot. Our custom PCB will contain the main power regulation, motor drivers, and connections between the different sensors and the microcontroller. The robot will use two independently controlled drive motors, allowing it to move forward, turn, and adjust its direction. Additional distance sensors and physical bumpers will be used to detect obstacles and stop the robot if necessary. A wireless module will provide a simple interface for starting and stopping the robot and viewing information about its current status. **Ball Collection and Storage** A motorized roller at the front of the robot will collect tennis balls from the ground and move them into a storage hopper. An infrared sensor will detect balls as they enter the hopper so that the system can keep track of how many balls have been collected. The hopper will also include a sensor to detect when it is full. Once the hopper reaches its capacity, the robot will stop collecting and can return to a designated location. **Criteria for Success:** The robot will be tested on a marked indoor test area using standard tennis balls. The following measurements will be used to evaluate the system: 1. Ball collection: Number and percentage of tennis balls successfully collected during an autonomous run. 2. Search coverage: Percentage of the test area covered by the robot during a collection run. 3. Boundary detection: Number of times the robot crosses or approaches the designated boundary. 4. Intake performance: Number of successful ball pickups compared with the number of pickup attempts. 5. Ball counting: Accuracy of the system's ball count compared with the actual number of balls collected. 6. User interface: Response time of start/stop commands and accuracy of the information displayed to the user. |
||||||
| 14 | Household Smart Scheduler |
Amanda Schmitt Maddy Sullivan Shailee Patel |
Tianda Huang | Cunjiang Yu | design_document2.pdf proposal1.pdf |
|
| # Household Departure Board Team Members: - Amanda Schmitt (amanda51) - Maddy Sullivan (maddys2) - Shailee Patel (shailee2) # Problem People often know when an event starts but still leave late because they do not keep track of when they actually need to leave. They may also forget important items, such as their keys, when rushing out of the house. Phone calendars can provide reminders, but they do not provide a shared physical display for a household or interact with the items people need before leaving. Our goal is to build a wall-mounted departure board that shows each household member's next event, how long they have before they should leave, and whether their keys are still on the hook. # Solution The Household Departure Board will contain a physical section for each household member. Each person's section will display: - Name - Next event - Time until they should leave - Key status The system will retrieve each user's next calendar event and calculate a departure time using a preset travel time and time buffer. For example: **Departure Time = Event Time - Preset Travel Time - Time Buffer** As the departure time approaches, LEDs will change color and an audible alert will notify the user when it is time to leave. Each person will also have a key hook containing a sensor. The board will detect whether their keys are still hanging on the hook. If departure time is approaching and the keys have not been removed, the board will display a warning. A microcontroller and custom PCB will control the displays, key sensors, LEDs, buzzer, and calendar communication. # Solution Components ## Central Control Subsystem A Wi-Fi-capable microcontroller will control the board. It will: - Retrieve each user's next calendar event - Calculate departure countdowns - Read the key-hook sensors - Update the displays - Control LEDs and audible alerts A custom PCB will contain the microcontroller, power circuitry, sensor connections, display connections, and output-driver circuitry. Components will include: - Wi-Fi-capable microcontroller - Voltage regulation and power circuitry - Sensor and display connections - LED and buzzer driver circuitry - Supporting resistors and capacitors ## User Display and Alert Subsystem Each household member will have a dedicated section of the board displaying: - User name - Next event - Departure countdown - Key status Each section will also contain a status light. For example: - Green: plenty of time remaining - Yellow: departure time approaching - Red: time to leave A buzzer will provide an additional alert when the user reaches their departure time. Components will include: - Small digital displays - Status LEDs - Piezo buzzer - Supporting driver circuitry ## Key Hook Sensing Subsystem Each user will have a designated key hook containing a mechanical sensor. When keys are placed on the hook, their weight will activate the sensor. When the keys are removed, the sensor will change state. The microcontroller will use this signal to determine whether the user's keys are still present. If departure time is approaching while the keys remain on the hook, the board will display a warning. Removing the keys will automatically clear the warning. Components will include: - Key hooks - Mechanical switches or pressure sensors - Basic input filtering circuitry ## Scheduling Subsystem The system will retrieve the next upcoming event from each user's digital calendar. Each user will have a preset travel time and additional departure buffer. The system will calculate: **Departure Time = Event Time - Preset Travel Time - Time Buffer** The countdown will automatically update until the user needs to leave. This subsystem will intentionally avoid more complicated route, weather, and transit calculations to keep the project focused on the physical scheduling board. # Criterion For Success 1. The board must support at least three household members. 2. Each user's section must display their next event, departure countdown, and key status. 3. The system must successfully retrieve upcoming events from a digital calendar. 4. The system must correctly calculate departure times using a preset travel time and time buffer. 5. Departure countdowns must update automatically. 6. Each key hook must correctly detect whether keys are present in at least 90% of controlled tests. 7. Removing or replacing the keys must automatically update the corresponding user's key status. 8. If departure time is approaching while the user's keys remain on the hook, the board must provide a visible warning. 9. The LEDs must indicate normal, leave-soon, and leave-now conditions. 10. The system must generate an audible alert when a user's departure time is reached. 11. The completed prototype must successfully demonstrate: - Three independent users - Calendar synchronization - Automatic departure countdowns - Key presence detection - Key reminders - Visual departure alerts - Audible departure alerts |
||||||
| 15 | Clogged Gutter Detector |
Aryan Kataria Eric Zhou Nyle Raina |
Jianchong Chen | Arne Fliflet | design_document1.pdf proposal1.pdf |
|
| # Clogged Gutter Detector Team Members: - Aryan Kataria - akata5 - Nyle Raina - nrain3 - TBD - netid # Problem Homeowners have no easy way to know when their gutters are clogged with leaves or standing water until they overflow, which can cause damage to foundation or roofing. Checking them proactively requires repeatedly climbing a ladder, which is dangerous and annoying. A low-maintenance, automated monitoring solution is needed to alert users before damage occurs. # Solution We plan to create a small, weather-resistant PCB node that mounts next to the gutter's primary downspout. It will use a rain sensor to detect active precipitation and a flow sensor to detect water moving down the spout. If it is raining but there is no water flow, the system will recognize the gutter is clogged. To avoid the need for battery replacements, the board will feature a solar trickle-charging circuit. It will utilize an ESP32 microcontroller that stays in deep sleep most of the time, waking up periodically to take readings and transmit the data to a cloud dashboard. # Solution Components ## Microcontroller Subsystem This part handles the logic, sleep cycles, and wireless transmission. We will use an **ESP32-WROOM-32E** module because it has low-power deep sleep capabilities and built-in Wi-Fi to upload the sensor data to our backend. ## Sensor Subsystem This subsystem detects active rain and monitors water clearing through the downspout to infer a clog. * **Precipitation Sensor:** We will use a resistive rain sensor board on the top of the enclosure. This will detect when it is actively raining and wake the ESP32. * **Flow Sensor:** We will mount a Hall-effect water flow sensor (like the YF-S201) at the top of the downspout. If the rain sensor detects water but the flow sensor registers zero movement, the system infers a clog. ## Power Subsystem This subsystem makes sure the board can run on its own outside. * **Charge Controller:** We will use a **Microchip MCP73871** charge controller to trickle power from a small 5V solar panel into a standard **18650 Lithium-Ion battery**. * **Voltage Regulation:** A **Texas Instruments TLV70033** 3.3V regulator will step down the battery voltage to provide a safe, steady 3.3V to the ESP32. # Criterion For Success 1. The precipitation sensor must output an analog signal that wakes the ESP32 from deep sleep within 10 seconds of active rainfall. 2. The Hall-effect flow sensor must output a reliable pulse signal that the ESP32 can read to accurately detect water movement in the downspout. 3. The power circuit must successfully provide charging current to the 18650 battery when the solar panel is under a bright light, while the regulator outputs a stable 3.3V. 4. The ESP32 must successfully execute its logic check (Rain = True, Flow = False), connect to a 2.4GHz Wi-Fi network, send a JSON alert packet to a test server, and go back to sleep in under 10 seconds. |
||||||
| 16 | Cost-Effective Signal Processing Solution for Bat-Call Detection and Hearing |
Liwei Koh Michael McNally Theo Xiong |
Tim Jiang | Arne Fliflet | design_document1.pdf proposal1.pdf |
Dr. Joy O'Keefe |
| # Cost-Effective Signal Processing Solution for Bat-Call Detection and Hearing Team Members: - Theo Xiong (tyxiong2) - Michael McNally (mm153) - Liwei Koh (liweitk2) Sponsored by Dr. Joy O'Keefe and the Human-Wildlife Interactions Lab # Problem Reliable heterodyne bat-call detectors are difficult to obtain for under $150 in the United States. Affordable options such as the Magenta Electronics Bat4 (approximately £80) generally require international purchasing and shipping, while comparable devices available in the US, such as the Elekon BATSCANNER (approximately $395), are significantly more expensive. This limits researchers, students, and bat enthusiasts who want an affordable and accessible way to detect and listen to ultrasonic bat calls. # Solution Build a portable heterodyne bat detector with a 3D-printed housing that is able to detect ultrasonic bat calls and convert them into frequencies that can be heard by the user. The device will aim to provide similar core functionality to the Magenta Bat4, minus the flashlight, while also using signal processing to recommend a frequency range for the user to tune to. # Solution Components ## Processing Subsystem * Processes the microphone signal and performs an FFT to determine the most prominent frequency range being detected. * Sends the detected frequency range to the display subsystem to recommend where the user should tune the detector. ## Microphone Subsystem * Uses a directional ultrasonic microphone to pick up bat calls. * Feeds the captured signal into both the processing and heterodyne subsystems. ## Heterodyne Subsystem * Passes the microphone signal through filtering and amplification. * Mixes the signal with a tunable local oscillator signal. * Shifts the ultrasonic bat call into the human-audible frequency range. * Filters and amplifies the resulting signal before sending it to the audio output. ## Power Subsystem * Uses a 4×AA battery pack as the main power source for the device. A voltage regulator is used to provide a stable supply voltage to the microphone, processing, heterodyne, display, and audio subsystems. Basic filtering and an on/off switch are included to help provide clean and controllable power throughout the system. ## Display Subsystem * Uses an Inland 1602 I2C LCD display module. * Displays the recommended frequency range determined by the processing subsystem. * Helps the user determine where to tune the detector. * Also displays potential species detected ## Buttons/Dials * Frequency Tuning Potentiometer: Allows the user to tune the detector through different frequency ranges, with approximately ±5 kHz of fine adjustment around the selected frequency. * Calibration Button: Allows the user to calibrate the detector and initiate frequency analysis. * Volume Dial: Controls the volume of the audible output. # Criterion For Success * The device should reliably detect the ultrasonic output produced by a bat-call simulator and convert it into an audible signal. * The device should be practical to construct using readily available and accessible components. * The device should provide adjustable tuning capabilities, allowing the user to cycle through different frequency ranges to improve detection performance. * The device should be able to analyze the microphone signal and recommend a frequency range for the user to tune to. ## Stretch Goal * Collect and analyze enough bat-call data to provide an estimate of the species of bat being detected based on characteristics such as its dominant frequency range. |
||||||
| 17 | NFC Selector and Running-State Indicator for Concurrent AI Runtimes |
Achintya Mohan Kevin Wiszowaty Tommy Zeng |
Shiyuan Duan | Viktor Gruev | other1.pdf other4.pdf |
|
| # NFC Selector and Running-State Indicator for Concurrent AI Runtimes Team Members: - Ziyan Zeng (ziyanz6) - Kevin Wiszowaty (kevinjw4) - Achintya Mohan (mohan19) # Problem When multiple concurrent AI coding-agent runtimes are running for different projects, it is difficult to determine which runtimes are active, which projects are waiting for input, and which tasks have produced new feedback. Screen-based project-management tools and software notifications are easy to miss when several projects progress simultaneously. We want to create a physical interface that limits the active working set to a manageable number of projects and provides an immediately visible indication of which projects are running or require attention. The system will complement an existing project-management system rather than replace it. # Solution We will design and build a vertical electromechanical device with three fully functional card slots and an architecture that can scale to six slots. Each NFC card represents one project. Its writable NDEF record contains a project ID, display label, path metadata, and revision information. The card UID is treated as its immutable hardware identity and is associated with a project by a host-side authorization system. The device supports NFC reading and writing. An authorized operator can initialize a blank card, assign it to a project, and write its project record. An existing card can be overwritten only after the host displays the old record and receives explicit operator confirmation. Every write is followed by read-back verification. At the beginning of a work session, the user inserts up to three authorized cards and presses each selected card down once. While the associated runtime is operating normally, the card remains lowered. When the runtime finishes, becomes blocked, or requires input, the host control hub commands the corresponding actuator to raise the card. RGB LEDs, an OLED display, and a buzzer provide additional feedback. After the user acknowledges the event through the host computer, the card is lowered again. Removing a card releases its project from the active working set. The host-side control hub bridges the physical device, local project-management software, and concurrent runtimes. A runtime adapter will connect to Codex pre-run and post-run hooks for the final demonstration. A simulator will generate deterministic events for hardware and regression testing. The control hub will also synchronize versioned NFC system state with a private GitHub repository. GitHub provides cloud backup, version history, and audit information, but it is not required for real-time mechanical control. If the network is unavailable, the local system continues to operate and queues changes for later synchronization. # Solution Components ## NFC Reader and Card Memory Subsystem This subsystem identifies cards and supports card initialization, metadata updates, and write verification. Planned components: - ST25R3916B NFC reader IC: one per slot, three total in the final prototype. - 13.56 MHz antenna and matching/tuning network: one per slot. - NTAG213 or NTAG215 NFC cards: at least three. - PN532 reader modules for early NFC read/write bring-up. The final PCB will use independent reader channels and physically separated antennas to reduce cross-reading between adjacent slots. The PN532 implementation is only an early validation path; the final design uses the custom ST25R3916B-based reader channels. ## NFC Data Format and Provisioning The user memory of each card will contain an NDEF project record with: - format_version - project_id - project_label - project_path - metadata_version - card_revision - provisioning_timestamp - record_checksum The UID is a manufacturer-programmed hardware identity and is not overwritten. Existing-card overwrite means replacing the NDEF/project record in writable user memory. Blank-card initialization: 1. Read the UID. 2. Confirm that the UID is not already registered. 3. Select or enter project information. 4. Write the NDEF record. 5. Read the record back. 6. Verify the project ID, revision, and checksum. 7. Add the UID-to-project binding to the local authorization database. 8. Generate a provisioning audit event. Existing-card overwrite: 1. Read and display the existing record. 2. Require administrator confirmation and an overwrite reason. 3. Increment the card revision. 4. Write and read back the new NDEF record. 5. Verify its checksum and fields. 6. Update the local binding. 7. Generate an overwrite audit event. If writing or verification fails, the allowlist and cloud state are not updated and the card enters a WRITE_FAILED or QUARANTINED state. ## Software Authorization Subsystem The host control hub will use a UID-to-project allowlist and operator confirmation. The local authorization database will maintain card_uid, project_id, authorized_at, authorized_by, card_revision, last_seen_revision, card_status, last_write_status, and last_sync_revision. Authorization rules: - Unknown UIDs cannot select or start a runtime. - Blank-card initialization requires administrator confirmation. - Existing-card overwrite requires administrator confirmation and old-record review. - The runtime adapter may report runtime state but may not overwrite NFC cards. - Acknowledgement requires host-side operator confirmation. - Duplicate project bindings are rejected until resolved. - A failed write does not update the allowlist or cloud state. NTAG213/215 password protection may be enabled as an additional tag-level protection layer, but it does not replace host-side authorization. ## Cloud/GitHub Synchronization and Versioned State The control hub will synchronize the NFC system state to a private GitHub repository using the GitHub repository contents API or an equivalent Git interface. Each legal provisioning, overwrite, insertion, removal, acknowledgement, and runtime state change produces a local event and a versioned state update. The repository will contain files similar to: - state/current_state.json - state/cards.json - state/project_bindings.json - state/permissions.json - state/system_config.json - audit/YYYY-MM-DD.jsonl The state snapshot will include schema_version, state_revision, device_id, slots, cards, last_event_id, and generated_at. Each audit event will include event_id, event_type, slot_id, card_uid, project_id, old_revision, new_revision, operator, timestamp, and device_state. Synchronization behavior: - The local control hub is the real-time source of truth. - Events are written to a durable local queue before upload. - Network availability causes pending state revisions to be committed in order. - Network loss does not stop local NFC, mechanical, or runtime operation. - A remote/local revision mismatch produces SYNC_CONFLICT and requires administrator resolution. - Synchronization failure never directly commands a card movement. The GitHub repository will be private. A fine-grained GitHub token with access only to the required repository will be stored in the host computer's secret store. No token, credential, or project file will be stored on an NFC card, in firmware, or in the repository state data. ## Card Presence and Position Sensing Each slot will use three optical interrupters: - Vishay TCST2103 for card-present detection. - Vishay TCST2103 for raised-position detection. - Vishay TCST2103 for lowered-position detection. The three-slot prototype therefore uses nine sensors. The controller will distinguish card_absent, card_present, card_raised, card_lowered, position_transition, and mechanical_fault. Position will not be inferred only from servo angle or timeout. ## Mechanical Card-Lifting Subsystem Each slot will contain: - One MG90S metal-gear micro servo. - One spring mechanism. - One servo-driven cam/latch mechanism. - Card guide rails. - Raised and lowered mechanical hard stops. The spring biases the card toward the raised position. The servo cam/latch holds it in the lowered position while the runtime is operating normally. Position sensors verify the final state. The formal prototype target is three complete slots. The frame and electrical interfaces will be designed for possible expansion to six slots. ## Embedded Controller and State Machine The main controller will be an ESP32-S3-MINI-1. It will provide USB Serial/JTAG, SPI or I2C for NFC readers, PWM for servos, GPIO inputs for sensors, I2C for the OLED, and control signals for LEDs and the buzzer. The state machine will include EMPTY, CARD_DETECTED, UNKNOWN_CARD, PROVISIONING, AUTHORIZED, SELECTED, RUNNING, ATTENTION_REQUIRED, BLOCKED, ACKNOWLEDGED, MOVING_UP, MOVING_DOWN, RELEASED, WRITE_FAILED, SYNC_PENDING, SYNC_CONFLICT, and MECHANICAL_FAULT. ## User Feedback Each slot will use one WS2812B RGB LED. The device will also use one SSD1306 0.96-inch I2C OLED, one 5 V active buzzer, and an N-channel MOSFET buzzer driver. Suggested indications: - Released: LED off. - Selected: blue. - Running: green. - Attention required: flashing red. - Blocked: flashing orange. - Acknowledged: yellow. - Unknown card: flashing purple. - Write failed: flashing white. - Mechanical fault: alternating red and white. The OLED will display the slot number, project label, runtime state, card revision, provisioning or overwrite status, GitHub synchronization status, attention reason, and error code. ## USB-C Power The device will use USB-C 5 V power and will not use a battery. The input will feed a protected servo 5 V rail and a regulated 3.3 V logic rail. The custom PCB will include a USB-C connector, CC resistors, fuse or resettable overcurrent protection, TVS protection, servo bulk capacitance, local ceramic bypass capacitors, separate servo power routing, and 5 V/3.3 V test points. The power subsystem must prevent simultaneous servo startup from causing an MCU reset, NFC communication failure, OLED corruption, or false sensor events. ## Host Communication and Runtime Integration The device will use a documented USB serial protocol. Events will include CARD_INSERTED, CARD_REMOVED, CARD_PROVISIONED, CARD_OVERWRITTEN, CARD_WRITE_VERIFIED, CARD_WRITE_FAILED, UNKNOWN_CARD, RUNTIME_START, RUNTIME_RUNNING, RUNTIME_COMPLETE, ATTENTION_REQUIRED, BLOCKED, ACKNOWLEDGED, RESUME, MECHANICAL_FAULT, SYNC_PENDING, SYNC_COMPLETE, and SYNC_CONFLICT. Messages will include slot_id, card_uid, project_id, event_type, runtime_state, card_revision, acknowledgement_state, timestamp, and error_code. The runtime adapter will connect to Codex pre-run and post-run hooks for the final demonstration. A host simulator will generate the same protocol events for repeatable tests. # Criterion For Success - Three slots simultaneously identify three different NFC cards. - A blank card is initialized with a valid NDEF project record. - An existing card is overwritten only after administrator confirmation. - Every successful write is followed by read-back verification. - Unknown UIDs cannot select or start a runtime. - Unconfirmed writes are rejected. - The runtime adapter cannot directly overwrite cards. - Card revision increments after every successful overwrite. - Failed writes do not update the allowlist or cloud state. - GitHub stores the current NFC system state in a private repository using versioned JSON snapshots. - Provisioning, overwrite, and runtime state changes produce traceable cloud revisions. - Local NFC and mechanical operation continue during GitHub or network failure. - Pending local changes synchronize after network recovery. - Remote/local revision conflicts are detected rather than silently overwritten. - GitHub tokens do not appear on cards, in firmware, or in repository state files. - Card insertion and removal detection accuracy is at least 98%. - Adjacent slots do not incorrectly identify each other's cards. - An attention event causes the corresponding card to begin rising within two seconds. - An acknowledgement or resume command causes the corresponding card to complete lowering within two seconds. - The system completes at least 100 raise/lower cycles without a jam or lost state. - Three servos can actuate simultaneously without resetting the MCU or losing NFC, OLED, or USB communication. - The host simulator can send at least 1,000 events without slot/project mismatches. - Removing a card prevents old runtime events from controlling a subsequently inserted card. - The system operates from USB-C power without a battery. - NFC cards and GitHub state files contain no credentials, project files, or other sensitive information. # Verification Plan ## NFC and Authorization Tests Test blank-card provisioning, NDEF encoding, existing-card overwrite, revision increments, checksum verification, read-back verification, tag password protection, unknown UID rejection, duplicate bindings, unauthorized writes, and write-failure rollback. ## GitHub Synchronization Tests Test initial synchronization, repeated synchronization, offline queueing, network recovery, unavailable repository handling, missing credentials, commit or snapshot verification, remote revision conflicts, and restoration from a previous state snapshot. ## Hardware Tests Test NFC read range, antenna isolation, adjacent-reader interference, optical sensors, servo actuation, RGB LEDs, OLED, buzzer, USB-C input, 5 V servo rail, 3.3 V logic rail, and simultaneous servo startup. ## Integrated Tests Test provisioning, card selection, runtime start, normal running, attention-required state, acknowledgement, card overwrite, card removal, release, and synchronization of every resulting state. ## Full-System Tests Test all three slots in parallel, simultaneous servo movement, power disturbances, repeated NFC writes, long mechanical cycling, offline operation, queued GitHub synchronization, and conflict recovery. # Optional DLC: Portable NFC Project Key and Context Synchronization This section is intentionally separate from the base project. It is not required for the three-slot prototype to succeed. The DLC would extend the card record with required_context_id, context_revision, agent_configuration_revision, verified_manifest_hash, and last_verified_sync_revision. When a card is inserted into a device connected to another computer, the control hub could check whether the required project context and agent configuration are locally available and current. If they are missing or outdated, it could retrieve a context bundle from GitHub or another designated server, verify its manifest and checksum, and write the verified revision back to the NFC card. The DLC is included so the course staff can judge whether the base runtime selector already has sufficient scope and complexity. If the base project is sufficient, the DLC remains future work. If additional system-level complexity is needed, a limited part of the DLC can be implemented after the base hardware and control system are stable. # Scope and Safety Notes - The base project is a three-slot prototype; six slots are an expansion target. - The device uses USB-C power and no rechargeable battery. - NFC cards do not store credentials, project files, or sensitive data. - GitHub synchronization uses a private repository and host-side secret storage. - GitHub is not required for real-time mechanical control. - Mechanical hard stops, sensor feedback, protected power distribution, and explicit fault states reduce risk from stalled actuators or unexpected movement. |
||||||
| 18 | Smart Vision-Assisted Pet Feeder with BLE Proximity Sensing and Remote Monitoring |
Jiaao Zhang Junwei Pan Ziteng Qian |
Pusong Li | Viktor Gruev | other1.pdf other2.pdf other3.pdf |
|
| # Smart Vision-Assisted Pet Feeder with BLE Proximity Sensing and Remote Monitoring Team Members: - Junwei Pan (junweip2) - Jiaao Zhang (jiaao2) - Ziteng Qian (zitengq2) # Problem Pet owners are often away from home for extended periods and may not be able to directly monitor whether their pets are approaching the feeder, eating normally, or ignoring food. Conventional automatic pet feeders typically dispense food at fixed times and provide little information about the pet's actual interaction with the feeder. As a result, an owner may know that food was dispensed but not whether the pet actually approached or consumed it. We propose a smart pet feeder that automatically detects when an authorized pet approaches, activates computer vision to monitor the pet near the feeding area, dispenses a controlled amount of food, and reports feeding activity to the owner remotely. The system will also monitor simple abnormal feeding patterns. For example, if the pet repeatedly approaches the feeder or remains near the bowl for an extended period without a measurable decrease in food weight, the system can notify the owner. # Solution Our system combines BLE-based proximity sensing, computer vision, weight sensing, motorized food dispensing, and wireless communication. A small BLE tag attached to the pet's collar continuously broadcasts an identifier. The feeder's main controller monitors the received BLE signal strength (RSSI). Rather than using BLE for precise positioning, the system uses RSSI only as a coarse proximity indicator. When the signal strength exceeds a calibrated threshold corresponding approximately to the pet entering the feeder vicinity, the system activates the camera and computer-vision subsystem. The camera then provides the primary confirmation that the pet has entered or remained within the feeding area. Once the pet is visually confirmed, the main controller activates an auger-based food dispensing mechanism. A load cell underneath the food bowl provides feedback so that the system can stop the motor after the desired amount of food has been dispensed. After dispensing, the system continues monitoring the bowl weight and camera state to determine whether the pet remains near the feeder and whether food is actually being consumed. Feeding events, food consumption information, system status, and abnormal-behavior alerts are transmitted over Wi-Fi to the owner's phone through an Internet-based messaging service. The system is divided into four major subsystems: proximity and wireless communication, computer vision, feeding and weight control, and the main embedded control PCB. # Solution Components ## Subsystem 1: BLE Proximity and Wireless Communication This subsystem detects when the tagged pet is approaching the feeder and provides remote communication between the feeder and the owner. A BLE tag attached to the pet's collar periodically broadcasts its identifier. The ESP32-S3 on the feeder scans for the designated BLE device and measures its RSSI. A moving average and hysteresis threshold will be used to reduce false triggering caused by RSSI fluctuations. When the averaged RSSI exceeds a calibrated threshold, the ESP32 will signal the vision subsystem to begin camera processing. BLE is used only as a coarse proximity trigger rather than as a precise ranging or positioning system. The ESP32-S3 will also use its integrated Wi-Fi interface to send information such as feeding time, amount of food dispensed, food consumption, and abnormal feeding alerts to the owner through an Internet-based messaging service. Components: - Espressif ESP32-S3-WROOM-1-N8R8 Wi-Fi/BLE module - ESP32-C3-MINI-1-based BLE tag or equivalent BLE beacon for the pet collar - 2.4 GHz PCB antenna integrated into the ESP32 modules - Status LEDs and buzzer for local system indication ## Subsystem 2: Computer Vision and Pet Behavior Monitoring This subsystem provides the primary confirmation that the pet is actually interacting with the feeder. A Raspberry Pi connected to a camera will run the computer-vision software. The camera does not need to operate continuously. Instead, it is activated when the BLE subsystem indicates that the pet is likely approaching. The vision system will determine whether a pet is present in a predefined feeding region and monitor simple behaviors such as: - Pet enters the feeding area - Pet remains near the bowl - Pet leaves the feeding area - Repeated approaches to the feeder The system will not attempt to diagnose medical conditions or recognize complex behaviors such as chewing. Instead, visual presence information will be combined with bowl-weight measurements to determine whether feeding actually occurred. The Raspberry Pi will communicate its detection results to the ESP32 through UART or another serial interface. Components: - Raspberry Pi 5 - Raspberry Pi Camera Module 3 - Sony IMX708 image sensor - UART interface between Raspberry Pi and ESP32-S3 - OpenCV and/or a lightweight object-detection model ## Subsystem 3: Food Dispensing and Weight Measurement This subsystem controls how much food is dispensed and measures whether food is subsequently consumed. Dry food or equivalent test pellets will be stored in a hopper. A stepper-motor-driven auger will transport the food from the hopper into the bowl. Rather than controlling the amount of food only according to motor operating time, the system will use closed-loop weight feedback. A load cell underneath the bowl continuously measures the amount of food present. For example, if the target dispensing amount is 20 g, the controller will operate the auger while monitoring the load-cell reading and stop the motor when the measured increase reaches approximately 20 g. After dispensing, changes in bowl weight will also be used to estimate whether food has been consumed. If the vision system detects that the pet remains near the feeder while the bowl weight does not decrease beyond a defined threshold, the system may classify the event as an abnormal or incomplete feeding event. Components: - TAL220B single-point load cell, approximately 5 kg range - HX711 24-bit load-cell ADC - NEMA 17 stepper motor, model 17HS4401 or equivalent - Allegro A4988SETTR-T stepper motor driver - Custom auger and food hopper - Limit switch for mechanical safety, if required ## Subsystem 4: Main Control PCB and Power System The custom PCB will serve as the main embedded controller of the feeder rather than only as a power-distribution board. The ESP32-S3-WROOM-1 will be mounted directly on the PCB and will coordinate the other subsystems. Its responsibilities include: - BLE scanning and RSSI processing - Wi-Fi communication - System state-machine control - Load-cell data acquisition - Motor control - Communication with the Raspberry Pi - Feeding-event logging - Alert generation The PCB will also contain the load-cell interface, motor-driver circuitry, sensor connectors, status indicators, and power regulation required by the embedded electronics. The Raspberry Pi will act primarily as a vision-processing coprocessor, while the ESP32-based custom PCB will remain the main controller for the overall feeder. Components: - ESP32-S3-WROOM-1-N8R8 - HX711 load-cell ADC - A4988SETTR-T stepper motor driver - 3.3 V voltage regulator for the ESP32 and low-voltage electronics - Power input and protection circuitry - Decoupling and bulk capacitors - UART connector for Raspberry Pi communication - Load-cell connector - Motor connector - Programming/debug interface - LEDs and buzzer - Raspberry Pi power supply # Criterion For Success 1. **BLE proximity triggering:** After calibration, the system must detect the designated BLE tag entering the intended feeder vicinity and trigger the computer-vision subsystem within 2 seconds in at least 90% of 20 test attempts. 2. **Vision-based feeding-zone detection:** The computer-vision subsystem must correctly classify whether a pet is inside or outside the defined feeding region with at least 90% accuracy on a labeled test set. 3. **Controlled food dispensing:** For example, a target dispensing amount of 20 g, the closed-loop auger and load-cell system must dispense food within ±10% of the target in at least 9 out of 10 trials. 4. **Consumption detection:** The system must detect a meaningful decrease in bowl weight after feeding and distinguish between a feeding event with food consumption and an event without food consumption in at least 90% of controlled trials. 5. **Abnormal feeding alert:** If the pet is detected in the feeding region for a predefined period or repeatedly approaches the feeder without a corresponding decrease in food weight, the system must generate an abnormal-feeding alert and send to the owner's phone. 6. **Remote notification:** Feeding-completion information and abnormal-feeding alerts must be transmitted over Wi-Fi and received by the owner's remote device within 10 seconds under normal Internet connectivity. 7. **End-to-end operation:** The complete system must successfully demonstrate the following sequence without manual intervention: BLE proximity detected → camera activated → pet presence confirmed → food dispensed → food weight monitored → feeding event classified → event information transmitted to the owner. |
||||||
| 19 | Soccer Tracking Laser Gimbal |
Aaron Zhang Colin Smithsuvan Jayden Kim |
Wesley Pang | Viktor Gruev | design_document1.pdf proposal1.pdf |
|
| \#\#\# Soccer Tracking Laser Gimbal Team Members: - Colin Smithsuvan ([colin9@illinois.edu](mailto:colin9@illinois.edu)) - Jayden Kim ([jaydenk2@illinois.edu](mailto:jaydenk2@illinois.edu)) - Aaron Zhang ([aaronz4@illinois.edu](mailto:aaronz4@illinois.edu)) \# Problem Typical sports broadcasting cameras are human controlled for tracking objects. We'd like to try to automate this with a vision-based system and track a soccer ball, specifically two people passing the ball to each other. This could help reduce human error and smooth out the motion of the camera and keep the object being tracked more centered in the filming camera's field of view. An extended scope of this project is tracking of an entire field. \# Solution We aim to solve this problem by having a camera positioned on a gimbal’s arm, which follows the movement of the soccer ball. This way, the ball is always positioned in the center of the camera frame, regardless of where the ball is being moved. For tracking the ball, we plan to deploy a vision detection model, which is trained to detect the soccer ball with real-time accuracy and latency. From there, we will have an arm with a camera at the base along with a laser which points at the ball for human verification. This arm will track the movement of the ball, which in turn will move the camera with it. This way, we can fully track where the ball is moving at all times with the ball in the center of the frame. \# Solution Components Laptop, Custom PCB, Motors, Power Supply \#\# Subsystem 1 Laptop - HP Pavilion Plus with RTX 4050 GPU and Intel Ultra 7 CPU with 1 TB storage and 32 GB of RAM. \#\# Subsystem 2 Custom PCB 1) Power 1) Based on motor nominal voltage, the input bus voltage/dc link voltage will be 24V 2) To power the CAN transceiver, there needs to be 5V as characteristic of CAN 3) To support the logic level components like the microcontroller, gate driver logic supply, ethernet PHY, and others there will need to be a 3.3V rail 1) There will potentially be both an analog and digital 3.3V rail where the two are separated by a ferrite bead to keep any switching or digital noise from propagating onto the analog rail 4) To generate the 5V, 3V3\_D, and 3V3\_A rails, we plan to not design a custom switching converter circuit and buy a power conversion “brick” 2) Microcontroller 1) STM32H753 1) Contains CAN/CANFD controller, ethernet MAC, 16-bit ADCs, 16 and 32-bit high-resolution timers 2) Depending on number of ADCs and GPIOs needed can select from the different pin packages 1) ADCs and GPIOs will be used for sensing circuits, encoder interfaces, or telemetry we want 3) Inverter 1) Gate Driver 1) Smart gate driver IC \- DRV8304 2) H-bridge FETs 1) N-channel fets for the three H-bridges \- will need to size the FETS to fit within the maximum phase currents of the selected BLDCs (1.4A) \- 06N06L 1) 60V VDS, 5.5A 4) Communications 1) CAN 1) TCAN3403DRQ1 2) Ethernet 1) PHY \- LAN8742 2) RJ45 Connector \+ Magnetics \#\# Subsystem 3 Motors - The motors will be used to drive the motion of the two axis gimbal and allow the object to remain near center of the camera’s FOV - Initially planned to use a brushless DC motor in order to learn the inverter stage design - Fallback plan to use an integrated servo or brushed DC motor if unable to get brushless design working - Motor will need an encoder interface for position tracking at low speed - Motor PN: DFRobot 4015 3-phase brushless motor - 24V, 1.4A \#\# Subsystem 4 Power Supply - Any power supply capable of 24V at \~10 A \#\# Subsystem 5 Firmware - State machine should look similar to this: INIT, CALIBRATE, IDLE, TRACKING, COAST (target lost, extrapolate briefly), SEARCH (scan pattern, FAULT) - Input capture on camera trigger latches encoder counts at exposure where the timebase is shared with the laptop - Potentiometer open-loop mode for inverter bring-up to test hardware before any vision/software code exists - Telemetry streaming at full loop rate - Drivers for Ethernet packing/unpacking, SPI, MAC, Auxiliary functions, timer, led controls, logic level gate control, etc \#\# Subsystem 6 Vision Model - Any on-device model for real-time streaming that can accurately provide bounding boxes. We will take these bounding boxes and take the middle of the bounding box for the location that the laser should point to. The SOTA model that we will try first is YOLOv26 since it provides fast on-device inference and is primarily trained on datasets such as COCO, which include a class for “sports ball.” - We may also need the camera intrinstics and extrinstics to map the image pixel coordinates to real world coordinates to understand how much to move the turret arm in the real world relative to the image detected bounding box. - In order to map from pixel coordinates to real world coordinates, our biggest challenge is accurate depth estimation which is required for perspective projection. Single camera depth estimation is an on-going research challenge with many models not being industry ready. Therefore, we may have to implement two gimbals for triangulation or to use a simple lidar for more accurate depth estimation for backup. However, our primary method of approach is to try monocular depth estimation models for our single camera use case. \# Criterion For Success Primary Objective: Demonstrate a closed loop, vision guided camera platform that keeps a moving target centered in frame. High Level Goals - Standalone vision model provides accurate bounding boxes on a soccer ball on laptop - Camera can successfully send gimbal position data to the MCU - MCU successfully ingests data and passes to the laptop - Laptop can run vision model inference and send position of where the gimbal should point back to the gimbal - Gimbal is able to move within a 120 degree field of vision both vertically and horizontally to match the position of the object detected - Keep a moving target centered in frame at all times autonomously - Gimbal is able to move fast enough to keep the target in frame. - Inference is developed with low-enough latency to have a fast closed-loop |
||||||
| 20 | Whiteboard Assistant Robot |
Avneet Kaur Morris Yu Saj Patel |
Junyan Bai | Viktor Gruev | design_document1.pdf proposal1.pdf |
|
| Team Members: - Saj Patel (spate709) - Avneet Kaur (avneetk2) - Morris Yu (morrisy3) # Problem Whiteboards are still commonly used in classrooms, labs, and meeting rooms, but adding information to them usually requires someone to stand at the board and write everything by hand. This can interrupt a presentation or discussion because the presenter has to turn away from the group to copy information onto the board. It also creates extra work when content already exists digitally. In addition, a large vertical whiteboard can be difficult to use for people who may not be able to comfortably reach or write across the entire board. Our goal is to create a portable robot that can attach to a whiteboard and automatically write or erase user-provided content, allowing information to be placed on the whiteboard without requiring a person to physically write it. # Solution The project focuses on developing a robot that can write on and erase a whiteboard automatically using the information given by the user. The user would be able to provide the content by typing it in or using voice input. The robot would attach to the whiteboard using magnets and move across the surface with the help of wheels and servo motors. By adjusting the direction and speed of the wheels, the robot would be able to travel horizontally, vertically, and diagonally. A spring-loaded marker holder would be able to keep the marker pressed against the whiteboard with consistent pressure while the robot is writing. # Solution Components ## Subsystem 1 - Movement and attachment to the board This subsystem will focus on allowing the robot to attach itself securely to the whiteboard and move across the surface of the board vertically, horizontally, and diagonally. Magnets will be used to keep the robot attached to the board while the wheels and the motors will be used to control its movement. Wheel encoders and other feedback systems will be used to track and provide feedback for the distance travelled, allowing it to trace predetermined paths for letters. An IMU will also be added to help track its orientation and detect unexpected rotation or slipping, while the wheel encoders will be used to estimate the robot's displacement. Parts: Motor driver (DRV8833PWP) 2 DC motors with encoders (DFRobot FIT0482) IMU (Bosch BMI270) Wheels (Pololu 32×7 mm silicone wheel) (smaller wheel = less mm/counts per output shaft revolutions) Others: magnets ## Subsystem 2 - Writing and erasing This subsystem will focus on the robot writing the information provided by the user. The user will be able to enter text through a computer or other device, and the program will convert the text into the paths that the robot can follow. A small spring loaded system with a microservo will be used to ensure that the pen can be lifted during gaps, and consistently pressed on the board (via the spring) in case of uneven surfaces. A similar system can/will be used for the eraser. To ensure the wheels do not drive over text or erase unintended sections, we plan to have the robot move from left to right, top to bottom, with the pen at the top of the robot such that the robot is always below and to the right of the most recent character. Parts: Micro servo for marker Micro servo (TowerPro SG90) Others: Marker, Eraser, springs ## Subsystem 3 - Control and text processing The control subsystem receives text from the user and converts each character into a path that the robot can follow. Characters will be represented using a simplified vector or single lined font. The controller will then convert each line and curve into wheel movement commands, and the encoder and IMU measurements will be used in a feedback loop to correct the robot's motion while it writes when necessary. Parts: ESP-32 (ESP32-S3-WROOM-1-N8) Others: PCB, Wifi/bluetooth connection # Criterion For Success The project will be considered successful if the robot can: - Remain attached to a steel-backed whiteboard without external support, including when it moves. - Move in two dimensions across the whiteboard, including horizontal, vertical, and diagonal motion, with little to no slipping. - Be able to receive some sort of text for it to recognize and write out via the pathing of the robot, whether it is through text, audio, or another format wirelessly. - Be able to write recognizable letters of the alphabet (a-z) - Raise and lower the marker automatically with a spring loaded system to maintain good contact, and prevent strokes outside the letters. - Erase the board completely when done. |
||||||
| 21 | WEARABLE ADAPTIVE RESONANCE MATCHER |
Austin Zhuang Tian Tu Xinyang Liu |
Shiyuan Duan | Arne Fliflet | design_document1.pdf proposal2.pdf |
|
| # WEARABLE ADAPTIVE RESONANCE MATCHER Team Members: * Yanheng Zhuang (NetID: yzhua2) * Xinyang Liu (NetID: xl157) * Tian Tu (NetID: tiantu2) # Problem Small implanted devices can receive power wirelessly from an external coil. This works best when the external and implanted circuits are properly matched near the same resonant point. In practice, coil movement, changes in distance or angle, and nearby tissue-like materials can change the electrical response of the system. This can increase reflected power and reduce transmission to the implanted coil. A fixed matching circuit may work well for one condition but perform poorly after the environment changes. Our goal is to build a system that can automatically detect this mismatch and retune the external matching circuit without manual adjustment. # Solution We will build an adaptive wireless power matching prototype using a custom PCB, two coils, a laboratory vector network analyzer (VNA), and computer control software. The PCB will contain two electronically adjustable capacitors controlled by an STM32 microcontroller. Changing these capacitances will allow the system to adjust the resonant behavior and input matching of the external coil. The VNA will measure S11 and S21 and provide feedback to a Python program. The program will read the measurements, command the STM32 to try different capacitor settings, and select the settings that provide the best measured performance. The VNA is an essential part of our final ECE 445 prototype and demo because it provides the measurement feedback needed for automatic tuning. We will not attempt to integrate the full VNA measurement functionality onto the PCB. Testing will be performed on a bench using two representative coils, an adjustable nonconductive fixture, and tissue-like loading material. No human or animal testing is included. # Solution Components ## Main Control PCB Subsystem This subsystem controls the tuning circuit and communicates with the computer. An **STM32F072CBT6** microcontroller will generate two independent tuning control signals. A **TLV75533PDBVR** regulator will provide 3.3 V power. A **TPS61040DBVR** boost converter and an **OPA2192IDR** dual op amp will provide the larger adjustable voltages required by the tuning components. Components: * STM32F072CBT6 microcontroller * TLV75533PDBVR 3.3 V regulator * TPS61040DBVR boost converter * OPA2192IDR dual op amp * USB connector and protection circuit * SWD programming header * Voltage test points ## Adjustable Matching Subsystem This subsystem connects to the external coil and changes its electrical response. It will use one adjustable capacitor in series and one in parallel with the coil. We plan to use **MAVR-000404-0287FT** varactor pairs. Fixed-capacitor and zero-ohm resistor footprints will also be included so the tuning range can be adjusted after measuring the actual coils. Components: * 2 × MAVR-000404-0287FT varactor pairs * Murata GJM C0G/NP0 fixed capacitors * RF connectors * Bias resistors * Decoupling capacitors * Zero-ohm resistor footprints ## Measurement and Control Software Subsystem This subsystem measures the system response and performs automatic tuning. A laboratory two-port VNA will measure S11 and S21. A Python program will communicate with both the VNA and STM32. It will first perform a coarse search over capacitor settings, then search more closely around the best result. The program will automatically save the measurements and selected settings for each test. Components: * Laboratory two-port VNA * Python measurement and tuning program * USB serial connection between the computer and STM32 ## Coil and Test Fixture Subsystem This subsystem provides a repeatable physical setup for testing the adaptive matching system. We will use an external transmit coil and a smaller implant-representative receive coil approved by our mentor. A nonconductive fixture will allow repeatable changes in distance, lateral position, and angle. Tissue-like loading material will be used to test whether the system can retune after the electromagnetic environment changes. Components: * External transmit coil * Implant-representative receive coil * Nonconductive positioning fixture * Mentor-approved tissue-like test material # Criterion For Success The project will be considered successful if it can: * Independently control both adjustable capacitor channels. * Automatically collect and save VNA measurements without manual data entry. * Detect a loss of matching after coil position or nearby loading changes. * Automatically select new capacitor settings without manual electrical adjustment. * Improve S11 by at least 6 dB, or reach S11 ≤ -10 dB, in at least three repeatable test conditions. * Improve VNA-measured S21 by at least 2 dB in at least three repeatable test conditions. * Complete one automatic tuning cycle within 60 seconds. * Repeat one selected test three times with final S11 results within 2 dB of each other. |
||||||
| 22 | MULTI-MODE TABLE TENNIS TARGET TRAINING SYSTEM |
Alice Xu Ben Seo Brandon Dang |
Abdullah Alawad | Arne Fliflet | design_document1.pdf proposal1.pdf |
|
| MULTI-MODE TABLE TENNIS TARGET TRAINING SYSTEM Team Members: Brandon Dang (bd16) Ben Seo (seo58) Alice Xu (alicex2) PROBLEM Shot placement and the ability to quickly adjust where the ball is directed are important skills in table tennis. Traditional accuracy drills often use tape, cones, or other passive markers placed on the table. These targets can show a player where to aim, but they cannot automatically determine whether the player successfully hit the intended location or record performance over repeated shots. Reaction and placement drills also commonly require a coach, partner, or ball machine operator to repeatedly tell the player where to aim. This makes it difficult for a player to independently perform randomized targeting drills and quantitatively track their accuracy. Our goal is to create an electronic table tennis training system that automatically selects target locations, visually indicates where the player should aim, detects ball impacts, and records performance. The required system will include a Rapid-Fire Placement Mode and a Serve Accuracy Mode. A Reaction Return Mode will be pursued as a stretch goal. SOLUTION The proposed system will consist of at least three low-profile electronic target pads placed on the opponent's side of a standard table tennis table and one central controller. Each target will contain a rigid low-profile impact surface, piezoelectric impact sensor, analog signal-conditioning circuit, high-brightness LEDs, ESP32 microcontroller, wireless communication, and a custom PCB. The targets will be movable so that they can be positioned at different locations on the table depending on the drill. Example locations include the left corner, center, right corner, short serve location, and deep serve location. When a target is selected, LEDs around its perimeter will illuminate. The player will attempt to bounce the ball on the selected target. The piezoelectric sensor will detect the impact and report which target was struck to the central controller. All targets will continue monitoring for impacts even when they are not illuminated. This allows the system to distinguish between a correct target hit, a wrong electronic target hit, and a shot that misses all electronic targets. The three target units will use the same PCB and firmware architecture, with each unit assigned a unique software identifier. The system will support two required training modes. RAPID-FIRE PLACEMENT MODE For Rapid-Fire Mode, the three targets will be positioned at different locations on the opponent's side of the table. A player will receive consecutive balls from a training partner, an existing ball machine, or a controlled manual feed. The electronic training system itself will not be responsible for launching the balls. One target will illuminate at a time. The player must redirect the incoming ball so that its first bounce on the opponent's side lands on the illuminated target. After the correct target is struck, another electronic target is struck, or a configurable timeout occurs, the controller will automatically select and illuminate another random target. A typical sequence would be: 1. Target 2 illuminates. 2. The player receives an incoming ball. 3. The player attempts to hit toward Target 2. 4. Target 2 detects the bounce. 5. The controller records a correct shot. 6. Target 1 immediately illuminates. 7. The drill continues with the next incoming ball. The controller will record correct target hits, wrong-target hits, misses or timeouts, overall accuracy, and consecutive-hit streaks. Target response time may also be recorded. If this feature is used, target response time will be defined as the time between target illumination and target impact. It will not be described as pure human reaction time because the measurement also includes stroke execution and ball flight. The primary performance metric for Rapid-Fire Mode will be shot-placement accuracy. SERVE ACCURACY MODE For Serve Accuracy Mode, the same electronic targets will be repositioned to represent different serve locations on the opponent's side of the table. Possible target locations include short left, short right, deep left, deep right, and center/body. At least three target locations will be used during the required demonstration. Before each serve, one target will randomly illuminate. The player will perform their normal serving motion and attempt to make the legal serve bounce on the selected electronic target on the opponent's side of the table. Serve timing will not be used as a performance metric because rewarding a faster serving motion could encourage the player to rush their normal technique. A serve will be classified as one of the following: Correct: The selected target was struck. Wrong Target: Another electronic target was struck. Miss: No electronic target was struck. If a target is hit, the result will be recorded automatically. If the serve misses all electronic targets, the player will press a Next Serve / Mark Miss button on the central controller. The previous attempt will then be recorded as a miss and another target will be selected. The controller will maintain total serves, correct target hits, wrong-target hits, misses, overall serve accuracy, and, if time permits, accuracy for each target location. SOLUTION COMPONENTS TARGET MECHANICAL AND IMPACT-SURFACE SUBSYSTEM Each target will be constructed as a low-profile impact pad approximately 10 inches by 10 inches. The final dimensions may be adjusted after prototype testing to balance target difficulty and reliable impact detection. The initial target design will use a thin rigid impact plate made from polycarbonate, thin plywood, or another lightweight material that produces a consistent table tennis ball rebound. The target will be kept below approximately 0.5 inches in total height. Each target will include: Thin rigid impact plate Piezoelectric sensor mounted beneath the plate High-friction rubber or silicone bottom surface Protected LED perimeter Small protected electronics enclosure positioned near the rear edge The high-friction bottom surface will prevent the target from moving significantly when struck. The LEDs will be positioned around the perimeter rather than in the center of the impact area so that the table tennis ball cannot directly damage them. Because placing a target on the table changes the surface the ball contacts, the target material will be selected through rebound testing. A ball will be dropped from a known height onto both the normal table surface and the target plate. The target should provide a rebound reasonably similar to the bare table so that successfully hitting the target does not completely stop normal play. The targets will be removable and repositionable so that the same three electronic modules can be used for both Rapid-Fire and Serve Accuracy Modes. IMPACT SENSING AND SIGNAL-CONDITIONING SUBSYSTEM Each target will detect table tennis ball impacts using a piezoelectric vibration sensor mounted underneath the impact plate. The proposed sensor is the PUI Audio AB2036B piezoelectric element. A table tennis ball impact produces a short mechanical vibration in the target surface. Because a table tennis ball is relatively light, the impact-sensing circuit will be designed and experimentally calibrated to detect small impact signals reliably. The raw piezoelectric output may contain positive and negative voltage transients, mechanical ringing, environmental vibration, and electrical noise. The piezoelectric signal will therefore pass through a custom analog front-end circuit before reaching the microcontroller. The circuit will include: MCP6002 dual operational amplifier Input current-limiting resistor Voltage clamping and protection circuitry RC filtering Adjustable or programmable gain Adjustable impact-detection threshold ESP32 ADC input The microcontroller will continuously monitor the conditioned sensor signal. The detection algorithm will approximately perform the following steps: 1. Sample the conditioned piezoelectric signal. 2. Reject low-amplitude background vibration. 3. Detect when the signal exceeds the calibrated threshold. 4. Identify the first impact peak. 5. Register one target hit. 6. Ignore mechanical ringing for a short lockout period. Impact thresholds will be determined experimentally using actual table tennis ball impacts at several locations across each target. If a single piezoelectric sensor does not provide reliable detection near the target edges, the mechanical design will support adding a second piezo sensor without changing the overall target architecture. TARGET ILLUMINATION AND DRIVER SUBSYSTEM Each target will contain high-brightness LEDs around the perimeter of the target surface. The LEDs will allow the player to quickly determine which target is currently active from the opposite side of the table. The LEDs will not be powered directly from the ESP32 GPIO pins. The custom PCB will include driver circuitry using an AO3400A N-channel MOSFET, current-limiting resistors, a gate resistor, a gate pull-down resistor, and an ESP32 GPIO control signal. The target will support several visual states: OFF: The target is inactive. ACTIVE: The player should aim for this target. SUCCESS: A brief visual indication after a correct impact. WRONG TARGET: An optional alternate indication when an incorrect target is hit. Different LED colors or flash patterns may be used to distinguish these states. EMBEDDED CONTROL AND WIRELESS COMMUNICATION SUBSYSTEM Each target will contain an ESP32-C3-WROOM-02 microcontroller. The microcontroller will locally control LED activation, piezoelectric signal sampling, impact detection, impact timestamping, target identification, and wireless communication. Performing impact detection locally reduces communication delays and allows each target to operate independently. Each target will continuously monitor for ball impacts regardless of whether it is currently illuminated. This allows the system to identify a wrong-target hit. For example, if Target 2 is active but the player hits Target 1, Target 1 will send an impact message to the central controller. The controller will recognize that Target 2 was active, record the shot as a wrong-target hit, and then select the next target. Each target PCB will have identical hardware. Individual targets will be assigned unique software identifiers. Communication between the targets and central controller will use ESP-NOW or another suitable peer-to-peer protocol supported by the ESP32. CENTRAL CONTROLLER AND USER-INTERFACE SUBSYSTEM A central controller will coordinate the training session. The controller will include: ESP32-C3-WROOM-02 microcontroller SSD1306 0.96-inch I2C OLED display Start/stop button Mode-selection button Next Serve / Mark Miss button Status LEDs Wireless communication with the target units The controller will support at least Rapid-Fire Placement Mode and Serve Accuracy Mode. During Rapid-Fire Mode, the display will show information such as the current trial number, number of correct hits, wrong-target hits, misses, overall accuracy, and current hit streak. If target response timing is enabled, the most recent and average target response times may also be displayed. During Serve Accuracy Mode, the display will show the selected target, total number of serves, correct hits, wrong-target hits, misses, and overall accuracy. The system will not place any timing requirement on the player's serving motion. POWER SUBSYSTEM The system will use external low-voltage power rather than custom rechargeable batteries. Because all targets are located on a table approximately 9 feet long, a single external 5 V supply may be distributed to the target units using low-voltage cables routed along or underneath the table. Each target PCB will include: 5 V power input AP2112K-3.3 voltage regulator Input and output decoupling capacitors Local bypass capacitors Power indicator Input protection The LED driver circuitry and sensitive piezoelectric analog circuitry will be physically separated on the PCB as much as practical to prevent LED switching from causing false impact detections. CRITERION FOR SUCCESS 1. Multiple Target Operation The system must independently operate at least three physical electronic targets and randomly select one target at a time. 2. Target Visibility The active target must be clearly identifiable from at least 3 meters away under normal indoor lighting. 3. Impact Detection Each target must correctly detect at least 90% of direct table tennis ball impacts during a controlled test of at least 30 impacts per target. Test impacts will include multiple locations across the target surface rather than only the center. 4. Multiple-Impact Rejection A single physical table tennis ball impact must register as no more than one hit. 5. Background Noise Rejection Normal table vibration, nearby ball bounces, and LED switching must not create more than one false impact detection during a 5-minute stationary test. 6. Target Stability During 20 representative table tennis ball impacts, each target must remain flat on the table and must not move more than 2 cm from its initial position after any individual impact. 7. Target Rebound Performance A table tennis ball will be dropped from a fixed height onto both the target plate and the bare table surface. The average rebound height from the target surface must be within 25% of the average rebound height from the bare table over at least 10 trials on each surface. This requirement ensures that the electronic target does not completely absorb the ball's energy or prevent normal play. 8. Correct/Wrong Target Identification When one target is active, the controller must correctly distinguish between an impact on the selected target and an impact on either of the other electronic targets. During a controlled test of at least 30 total target impacts, the system must classify at least 90% correctly. 9. Rapid-Fire Placement Mode The system must complete a drill containing at least 20 randomized target activations without requiring the user to manually select the target for each trial. After a target hit or timeout, the next target must automatically be selected and illuminated. The controller must record correct hits, wrong-target hits, misses or timeouts, total trials, and accuracy percentage. 10. Serve Accuracy Mode The system must complete a serve-accuracy session containing at least 10 serves and at least three selectable target locations. For each serve, the system must classify the result as a correct target hit, wrong electronic target hit, or user-confirmed miss. The system must display overall serve accuracy at the end of the session. 11. Wireless Communication Each target must successfully communicate activation and impact information with the central controller at a distance of at least 5 meters in an indoor environment. 12. Performance Recording For Rapid-Fire Mode, the central controller must display: Correct hits Wrong-target hits Misses or timeouts Total trials Accuracy Current hit streak For Serve Accuracy Mode, the central controller must display: Selected target Correct hits Wrong-target hits Misses Total serves Accuracy 13. Custom Circuit Design Each target will use a custom PCB containing: ESP32 microcontroller interface Piezoelectric impact-sensor analog front end Amplification and filtering circuitry Input protection circuitry LED driver circuitry Power-regulation circuitry At least three physical target units will operate using the same PCB architecture. 14. End-to-End Demonstration During the final demonstration, the system must demonstrate both required training modes. For Rapid-Fire Placement Mode, the system must: 1. Randomly select a target. 2. Illuminate the selected target. 3. Detect a table tennis ball impact. 4. Determine whether the correct or wrong electronic target was struck. 5. Record the result. 6. Automatically select the next target. For Serve Accuracy Mode, the system must: 1. Randomly select a serve target. 2. Illuminate the selected target. 3. Allow the player to complete a normal untimed serve. 4. Detect a correct or wrong target impact. 5. Allow the player to manually record a serve that misses all targets. 6. Update the accuracy statistics. 7. Select the next target. STRETCH GOAL: REACTION RETURN MODE After the required Rapid-Fire Placement and Serve Accuracy modes are working reliably, the system will be extended to support a Reaction Return Mode. In this mode, balls will be supplied by a training partner or existing ball machine. The target location will not be revealed until the incoming ball has been fed toward the player. A feed trigger may be implemented using an optical ball-detection sensor near the feed source, a physical trigger button operated at the moment of feed, or synchronization with an available ball machine. When an incoming ball is detected or triggered, the controller will immediately select and illuminate a random target. The player must recognize the newly selected location and redirect the incoming ball toward that target. The system will record the selected target, correct target hits, wrong-target hits, misses, and target response time. Because synchronization with the incoming ball adds additional sensing and timing requirements, Reaction Return Mode will remain a stretch goal and will not be required for successful completion of the base project. |
||||||
| 23 | Robot Desk Lamp with User Interaction |
Chris Shan Qianyu LI Yiming Niu |
Wesley Pang | Cunjiang Yu | design_document1.pdf proposal1.pdf |
|
| **Project Title:** Robot Desk Lamp with User Interaction **Team Members:** Chris Shan(chriss4) Yiming Niu(yimingn4) Qianyu Li (qianyul4) **PROBLEM** In everyday work or study, people frequently need to adjust the direction of a desk lamp's light depending on the task at hand, but traditional desk lamps are either completely fixed or require both hands to physically bend the lamp arm to change direction -- which is inconvenient when one hand is already occupied with something else. We want to build a robotic desk lamp that can automatically reposition its light direction, allowing the user to precisely aim the light at a desired area on the desk using only a single hand. **SOLUTION** We will design and build a 3-4 degree-of-freedom (3-4 DOF) articulated robotic desk lamp, running on a custom ESP32-S3 PCB. The lamp's mechanical structure includes three base joints - base rotation, upper arm, and lamp head tilt - with a possible fourth joint (a forearm/elbow) added depending on mechanism tuning, to expand the reachable workspace. To address the core need of single-hand lighting adjustment, we plan to evaluate three candidate human-machine interaction schemes - ToF distance sensing, camera-based visual tracking, and a phone-based BLE remote - and select one as the primary interaction method after preliminary feasibility testing. Once the interaction module provides a target direction, the system computes inverse kinematics (IK) based on current joint angles, drives the servos into position, and continuously corrects based on the interaction module's next reading. **SOLUTION COMPONENTS** - SUBSYSTEM 1 -- Mechanical Structure & Joint Actuation: The three base joints (base rotation, upper arm, lamp head tilt) are servo-driven, with a reserved interface for a fourth joint (forearm). All servos receive PWM timing from a shared I2C multi-channel PWM driver chip, offloading this from the MCU. Servo power is supplied independently from the logic rail to prevent high-current draw from causing resets on the ESP32-S3. Parts: 3–4× digital servos (e.g., DS3218MG) / I2C PWM driver module / 3D-printed structural components and bearings / independent high-current servo power supply (barrel jack + external adapter, sized for ~8–12A peak at 4 servos) - SUBSYSTEM 2 -- Human-Machine Interaction & Closed-Loop Tracking Control: This subsystem converts the user's single-hand interaction into a target orientation for the lamp head. As the baseline control method, the robot will estimate the position of the user's finger or hand relative to the lamp and use the perceived distance and position to determine where the lamp should point. The lamp will continuously adjust its orientation so that its facing direction tracks the user's indicated target location. As an additional control feature, specific hand gestures may also be assigned to directly adjust the polar and azimuthal angles of the lamp's facing vector. The table surface is defined as the xy-plane, with the z-axis perpendicular to the table. These gesture-based angle adjustments would allow the user to fine-tune the lamp's vertical tilt and horizontal direction beyond the baseline position-based tracking method. The exact gesture mapping may be refined during preliminary testing. The system then operates as a continuously running closed loop: the interaction module provides the target direction -> the system computes IK based on current joint angles to get target joint angles -> the servos move -> the interaction module provides the next reading, and the error is recomputed and corrected until the lamp head stabilizes on target. Parts: (candidate) VL53L5CX multi-zone ToF sensor ×1-2 (8×8 zone array, needed for angular resolution — single-zone ToF such as VL53L0X/L1X cannot resolve direction) / (candidate) OV2640 or OV3660 camera module + custom-trained single-class lightweight YOLO model / 8MB PSRAM for frame buffering and model weights / phone-based BLE joystick control interface - SUBSYSTEM 3 -- Control PCB & Power Management: The custom PCB integrates the ESP32-S3, power management, and wireless communication, with independent 3.3V logic and 5V high-current servo rails to prevent cross-interference or brownout resets. The board reserves an I2C bus (shared by the PCA9685, ToF sensor, and optional camera module) and a programming/debug header. Parts: custom PCB (ESP32-S3-WROOM-1 + power management ICs + I2C bus routing) / 5V->3.3V switching (buck) regulator -- sized for logic-rail current, not a linear regulator given the current levels involved / USB-C connector for logic-rail power only / programming/debug header **CRITERION FOR SUCCESS** - Joint coordination: 3-4 joints move together within their rated angular ranges, allowing the light spot to continuously cover the defined desk workspace - Gesture recognition success rate: under defined test conditions, the interaction module correctly identifies the target direction/position at least 80% of the time - Power management under load: the system delivers light output at a specified wattage while the servo motion system is simultaneously active, without brownout, overheating, or MCU reset - Closed-loop correction success rate: given the interaction module's directional feedback, the system successfully corrects the lamp head to the target orientation at least 80% of the time |
||||||
| 24 | Automatic Mirror for Plant Lighting |
Lucian Bell Mateus Trigo Sanghoon Kim |
Tianda Huang | Cunjiang Yu | design_document1.pdf proposal1.pdf |
|
| Team Members: Lucian Bell (lb25) Mateus Trigo (mtrigo2) Sanghoon Kim (sk82) Problem: There are many times where an apartment or room does not have a south-facing window, but the resident may want to grow a plant that requires direct sunlight to thrive. Light from an east, west, or north facing window may be adequate for a full-shade plant, but a partial-sun or full-sun plant may not be getting enough direct sunlight. This is a greater issue during winter in the northern hemisphere, where the sun shifts southward in the sky and the hours of daylight decrease. If there was a way for plants in non-south facing windows to get a few more hours of direct sunlight, then full-sun and partial-sun plants could be successfully grown in these windows which would give the resident more freedom to customize their room. Solution: We will build a device that uses a sun-tracking flat mirror to redirect sunlight towards the plant in a non-south facing window or other shady space. The device will be powered by a battery, which will allow it to be mounted outside of a window or be placed on a yard or deck. It will use a GPS signal and compass to determine the time, location, and orientation of the device. This data will be used by a microcontroller to determine the position of the sun in the sky relative to the device. On setup, the device will be calibrated to reflect the sun at the desired angle, and the microcontroller will move the mirror to continue reflecting the sun at this angle. The mirror will be attached to a rod with a base, and be controlled by two stepper motors to allow the mirror to change its orientation. The base will rotate to allow for rotation parallel to the ground and there will be a motor near the top of the rod that allows for rotation perpendicular to the ground. The device will also use a light sensor to determine when it is night time or the weather is poor so that it can save energy. This device will be able to provide the extra sunlight that some plants need to thrive in shady spaces. Main Components: Motors and Frame The frame for the device will consist of a base, a rod, and the mirror itself. One stepper motor will be used to rotate the base to allow for rotation parallel to the ground. Another stepper motor will be used near the top of the rod to allow the mirror to rotate perpendicular to the ground. The stepper motors we are planning on using are 17HS15-1504-ME1K, which include rotational encoders to ensure the motor’s rotation is accurate. DRV8434 stepper motor drivers will also be used to convert the low voltage and current signals from the MCU to higher voltage and current signals for the motors. Sensors The device will use multiple sensors to determine the position, orientation of the device, light level, and time. All of these sensors will be attached to the PCB and will use I2C serial communication to send signals to the microcontroller. The LIS2MDL sensor is a compass, and will be used by the device to find magnetic north. The microcontroller will use this to convert the rotation of the base to real-world cardinal directions. The MAX-M10S-00B sensor will receive a GPS signal and send the time, latitude, and longitude to the MCU. These signals will be used by the MCU to determine the position of the sun in the sky. The final sensor is the VEML7700-TT light sensor, which will be used to measure the amount of light the device is receiving. This will allow the device to stop rotating in bad weather or at night, which will help it to save energy. Microcontroller and Firmware We will use a STM32G071CBT6 microcontroller mounted to the PCB to control the device and process signals from sensors. This microcontroller is low-power since keeping track of the sun position and light level is not computationally intensive, and this will reduce the cost and power consumption of the device. It also has support for I2C serial communication, which we will use to communicate with the sensors. We will write firmware for the microcontroller in C/C++ to make effective use of its small program memory. The firmware will include calibration behavior to calculate the target angle for the reflected light based on the mirror’s current position and the position of the sun. A button or other interface will be added to the PCB to start the calibration process. The firmware will use equations to convert the time, latitude, and longitude from the sensors to the sun’s angle in the sky, and it will position the mirror so that the sun’s light will be reflected to the target angle. If the sun is at a position that can’t be reflected to the target angle, the motors will not move and the device will wait for the sun to move to a position that can be reflected to the target angle. The firmware will also use the light level from the sensors to determine if the motors should not be moved during bad weather or at night to save energy. Power The device will use an 3.6V 18650 lithium-ion battery cell for power to accommodate the high-current requirements of the motors. The use of a battery will allow our device to operate outside and further from electrical outlets, which gives the device more flexibility. It is also more convenient than using a power cable, since the user will not have to worry about cable management. To meet the needs of different voltage components, our device will also step up (boosting) and step down (buck) circuits to convert the battery voltage to higher and lower voltages. Criteria for Success: Our device will be tested on a flat surface outside with multiple marked targets to measure the accuracy of its light reflection. Alternatively, if the weather is poor, a laser or artificial light can be shined from the sun’s angle in the sky to simulate the sun indoors. The first set of tests are meant to evaluate the device’s ability to calculate the position of the sun and target point accurately. The second set of tests are meant to evaluate the device’s ability to correctly move the mirror to reflect light to a given target point and to evaluate correct sensor behavior. Sun Position and Target Point Calculation: 1. The device should be able to calculate the position of the sun to within 5 degrees of error to the known position of the sun at the current time and location. 2. The device should be able to calculate the position of the sun to within 5 degrees of error to the known position of the sun at 2 different simulated positions and 2 different simulated times. 3. The device should be able to determine the angle of the target during calibration within 5 degrees of error to the real target. Real-World Performance: 1. The device should be able to successfully reflect light from the simulated or real sun to a manually entered target point at three different times in the day. 2. The device should be able to run for three hours and keep light from the simulated or real sun on the manually entered target point for 90% of the time. 3. The device should not move the motors when a manually entered target point is outside of the mirror’s reflection range within 5 degrees of error. 4. The device should stop moving the motors if the light sensor is covered. 5. The device should be able to determine the cardinal direction of the mirror’s focus within 5 degrees of error. |
||||||
| 25 | Troll E: Tracked Robotic Outdoor Load-Lugging Escort |
Ben Wang Daniel Ly Hyun Been Park |
Tianda Huang | Cunjiang Yu | design_document1.pdf proposal1.pdf |
|
| **Troll E: Tracked Robotic Outdoor Load-Lugging Escort** Team Members: Hyun Been Park (hbpark2) Daniel Ly (dhly2) Ben Wang (bw34) **Problem** Transporting groceries, tools, camping equipment, gardening supplies, and other heavy items can be difficult when a person is working or traveling alone. Traditional carts can assist people with carrying these weights, but still require the user to manually push or pull them. These carts also become difficult to use when the terrain changes. Gravel, grass, and curbs can make conventional wheeled carts difficult or unsafe to operate. Our goal is to design a robotic load carrier that can follow its user automatically and transport a rated load across different types of terrain without requiring the user to continuously control or pull the device. **Solution** We propose a multi-purpose robotic load carrier that follows a wireless beacon carried by the user. The carrier will follow the user while maintaining a set distance and use onboard sensors to detect nearby walls, people, and other obstacles. If an obstacle is detected, the carrier will stop and adjust its movement to avoid a collision. The main feature of the device will be its ability to travel over several types of terrain, including smooth indoor flooring, pavement, grass, gravel, and sand. The device will also monitor the weight of the carried load. If the load exceeds the safe operating weight, the system will warn the user and will not be allowed to operate until the load is decreased and the safety risk is eliminated. **Solution Components** **User-Following Subsystems** The user will carry a small wireless beacon that allows the carrier to determine the relative position of the user. The carrier will use this information to: Follow the user automatically Maintain a predetermined following distance Stop when the user stops Stop if the beacon signal is lost A beacon-based system is preferred over image recognition because it reduces the amount of image processing required and provides a dedicated signal identifying the correct user. Possible technologies for the beacon include UWB, Bluetooth, or another suitable short-range wireless positioning method. **Obstacle Detection Subsystem** Distance sensors will be placed around the carrier to detect obstacles in its path. The sensors will be used to detect: People Walls Cliff/Slope Large & Small Objects Possible sensors could be distance sensors like LiDAR or Ultrasonic. We are leaning towards a combination of the two, as LiDAR may be good for seeing far, and the ultrasonics can help with managing the path due to smaller/closer obstacles. It may be beneficial to include bumper sensors as a failsafe option to prevent catastrophic failure and potential damage. If an obstacle is detected within the required safety distance, the central controller will stop the carrier or determine whether a safe alternate movement is possible. For this to occur, we may need several identical sensors to check front and side views to find viable options of travel to navigate towards the beacon signal. Additionally, we may need to include a sensor to detect when the cart is on a slope to ensure that no action is taken that may tip the carrier over or cause it to accelerate. **Multi-Terrain Subsystem** The drivetrain will provide the force required to move the carrier and its payload. The system will be designed to operate on several representation surfaces: Indoor flooring (smooth and carpet) Pavement Grass Gravel Sand Wheel diameter, tire material, motor torque, and gear ratio will be selected based on the required load capacity and how well it will fare in all terrains. The drive motors should be capable of steering and regulating their speed while following the user. This may include reversing in case the carrier is blocked off by obstacles. **Load Sensing Subsystem** Load cells or another suitable weight-sensing method will be used to measure the approximate payload placed on the carrier. The system will compare the measured load against the maximum allowable operating load. If the allowable load is exceeded: The user will receive a warning The carrier may prevent movement if the load creates an unsafe condition **Control Subsystem** A central microcontroller will receive information from: The user beacon Obstacle sensors Load sensors Orientation sensors The controller will use this information to determine the required speed and direction of the drive motors. The controller will also coordinate safety functions such as overload protection, obstacle detection, beacon response loss, and unsafe-angle detection. **Power Subsystem** A rechargeable battery will supply power to the entire carrier. The power subsystem will provide the required voltage for: Drive motors Motor drivers Microcontroller Wireless communication Obstacle sensors Load sensors Orientation sensors Battery voltage will be monitored so that the system can warn the user when the remaining charge becomes too low for safe operations. **Criterion for success** Our solution can be considered successful if the carrier can: Reliably follow the user’s beacon while maintaining a distance of approximately 2-3 meters under normal walking conditions. Detect an obstacle in its path and stop before contact. Carry a payload of at least 20lb across indoor flooring and at least three uneven surfaces such as grass, gravel, or sand. Detect when the carrier is loaded above its allowable weight and provide a clear warning to the user. Stop automatically if the beacon signal is lost. **Extensions** If the base project is completed successfully, possible extensions include: A mobile application that allows the user to adjust following distance or operating mode Manual remote-control mode Automatic transition between flat ground Battery state/battery charge display GPS or location tracking Detachable or expandable cargo compartments Additional terrain options Improved autonomous obstacle avoidance rather than simply stopping Possible solar implementation for power conservation **Safety and Ethics** Because the carrier is an automatically moving device capable of transporting a significant load, user and bystander safety will be an important part of the design. The carrier will include obstacle detection to reduce the risk of collisions with people or objects. An emergency-stop function will also be implemented, which will allow the user to disable the motors immediately if necessary. The system will also stop if the user's beacon is lost or if the carrier is at an unsafe position. The maximum load capacity will also be clearly defined so that the user does not operate the carrier beyond the tested safe limit. |
||||||
| 26 | PATH: Proximity Awareness Through Haptics |
Juheon Woo Kori Gillis-Harry Zeead Sowelam |
Eric Tang | Arne Fliflet | design_document1.pdf design_document2.pdf proposal1.pdf |
|
| **Proximity Awareness Through Haptics (PATH)** **Team Members:** - Juheon Woo (juheonw2) - Zeead Sowelam (sowelam2) - Kori Gillis-Harry (korimg2) **Problem** While new assistance devices are being developed, the function of and accessibility to those devices are still extremely limited, and most visually impaired individuals rely only on a white cane or mobile applications that are oftentimes inconvenient to put into action passively at all times. Individuals often face difficulty and delay in avoiding or being notified of nearby obstacles or people in a day-to-day environment. **Solution** In order to help resolve such difficulties faced by visually impaired individuals, we propose an assistive obstacle warning and vibration device that can be attached to a white cane to help the user preemptively avoid approaching obstacles. Depending on the approximate proximity of the obstacle ahead, the device will either vibrate stronger or weaker. The handle will have 2 vibration motors, one on the left side of the handle and another on the right side of the handle. Each vibration motor is attached to the actual handle of the cane through sticker-like pads, one pad on the left side and one pad on the right. The left vibration motor will go into action when the obstacle is approaching from the left and the right vibration motor will go into action when the obstacle is approaching from the right, and this will be felt by the user through the pads attached to the handle. When the obstacle is straight ahead, both motors will vibrate, with the strength of the vibration corresponding to the distance from the user to the obstacle. The detection device that will generate the vibration signal will consist of a multi-zone time-of-flight (ToF) sensor paired with a 6-axis IMU for dynamic tilt compensation. The sensor array will provide directional haptic feedback; vibrating a specific motor corresponding to the zone (left or right) where the obstacle is detected, with intensity scaling based on distance. Real-time orientation data from the IMU dynamically adjusts the sensor grid to compensate for cane angle changes, preserving forward-looking accuracy. This removes the need for the user to manually sweep the device to localize obstacles, prevents false detections due to normal cane motion, and improves on the spatial resolution of existing single-sensor commercial products. **How We Improve on Prior Work** A Spring 2026 team built a modular smart cane attachment (Project 15) that relayed phone navigation audio, provided basic distance-warning vibration cues, and utilized a standard linear power supply. While we retain the foundational goal of improving obstacle awareness for visually impaired users, our design significantly upgrades the system's functionality (especially in terms of local obstacle detection and notification), hardware, firmware, and circuit complexity in three key ways. First, obstacle detection and spatial sensor fusion. Project 15 relied on a single-point distance sensor that could only report a generic distance to an obstacle somewhere ahead, offering no spatial resolution in terms of local obstacle detection. Project 15 does incorporate 2 motors for left and right haptic signals, however, this is strictly to signal left and right turns when navigating a predefined path, and the obstacle awareness/detection itself remains simple and does not provide any complex spatial image to the user. In contrast, our design replaces this 1D single beam with an 8x8 multi-zone ToF matrix, providing 64 independently ranged depth zones. This enables true spatial mapping, allowing us to selectively actuate left or right grip motors so the haptic cue actively points to the hazard rather than just issuing a passive warning with not much spatial information. In addition, our design will also have a special vibration pattern for overhead objects, which is not supported in project 15. Furthermore, we integrate a 6-axis IMU running real-time orientation filtering to dynamically shift active matrix rows as the cane tilts. Project 15 uses its IMU passively for fall detection logic. Our project implements active sensor fusion, combining IMU pitch/roll orientation data with ToF spatial matrix readings via a complementary filter to dynamically re-index active matrix rows. This holds the detection window locked at an upper-body height regardless of grip angle and eliminates false ground trigger, which is an advanced sensor-fusion capability absent in both Project 15 and commercial products like the WeWalk cane. Second, actuator reliability and closed-loop haptic control. Beyond sensing, we add closed-loop fault detection on the output side: each vibration motor is driven through a discrete MOSFET switching stage with low-side current sensing, so the firmware can distinguish a working motor from a stalled or disconnected one in real time via ADC sampling. Additionally, we implement a short initial 100% duty-cycle overdrive pulse to overcome motor mechanical inertia and reduce startup latency. This is a custom circuit-level contribution with no equivalent in Project 15, where the vibration output relied on basic open-loop PWM driving with no diagnostic feedback. Third, power management and hardware circuit complexity. Project 15 relied on a basic LDO regulator and a simple resistor divider into an ADC pin to estimate battery percentage. Our design increases custom hardware complexity by replacing the LDO with a high-efficiency synchronous Buck-boost switching regulator for system power, integrating a dedicated I2C fuel gauge IC for precise state-of-charge tracking, and incorporating a standalone battery protection IC circuit with dual MOSFET switching. This delivers significantly better power efficiency, professional-grade battery monitoring, and robust circuit protection. In addition, we also added a low battery haptic notification system that notifies the user of low battery, which is not done in project 15. In short, our project focuses mainly on the complex obstacle detection aspect, rather than focusing on general navigation assistance along a predefined path like project 15. With this goal, we also introduce much sophisticated hardware and feature implementations like mentioned above. **Solution Components (System Architecture and Subsystems)** - Sensor & Orientation Array: STMicroelectronics VL53L5CX multi-zone Time-of-Flight sensor (8x8 zone output, up to 4m theoretical range but scaled to 2m reliable operating range) and a 6-axis IMU (like LSM6DS3TR-C), both interfaced via a shared I2C bus alongside dedicated hardware interrupt lines, mounted near the top of the handle facing forward/outward. - Processor: ESP32 module (ESP32-S3-MINI dual core module), surface-mounted directly on the custom PCB (not a dev board), housed in a small enclosure on the cane shaft below the handle. - Haptic Output & Current-Sense Stage: 2 ERM (eccentric rotating mass) coin vibration motors, one adhesive-mounted to the left of the handle and one to the right, each driven by a discrete N-channel MOSFET PWM switching circuit with flyback diode protection and low-side current sensing for motor fault and stall detection. Motors will be attached with some type of strong adhesive with wiring routed along the shaft to the PCB. - Power Management: Li-Po (or Li-ion) battery, MCP73831 charge management IC, DW01A battery protection circuit with dual MOSFET switch, USB-C charging input with ESD protection, high-efficiency synchronous Buck-boost switching regulator (like the TPS63020 or the TPS63070) for 3.3V logic supply, and an I2C battery fuel gauge IC (e.g., MAX17048); housed in the same shaft enclosure as the processor. **Core Subsystems Requiring Custom Circuit Design** - Power Management & Regulation Subsystem: Battery charging, protection, high-efficiency Buck-boost regulation, and I2C fuel gauge state-of-charge monitoring. - Closed-Loop Haptic Motor Drive Subsystem: Custom MOSFET PWM switching stage per pad with flyback protection, 100% duty-cycle startup pulse, and low-side current-sense amplification for real-time stall and fault detection. - Multi-Sensor & Spatial Mapping Subsystem: I2C bus conditioning, pull-up network, and hardware interrupt handling for the ToF sensor and 6-axis IMU, enabling dynamic matrix row shifting based on real-time pitch/roll cane tilt angles. **Mechanical Integration** - Retrofit onto an existing standard white cane (rigid shaft, hard or lightly cushioned handle) rather than designing a cane from scratch. - Vibration pads are mounted directly against the rigid handle shell (not buried in soft cushioning) to ensure reliable vibration transfer to the user's palm/fingers. - Sensor and electronics enclosure mounted at/near the top of the cane, angled to detect torso/head-height obstacles (complementing, not duplicating, the cane tip's ground-level detection). - Wiring from pads to PCB routed along the shaft with strain relief to survive repeated gripping and flexing. **Functional Logic (Firmware/Software)** - Read pitch and roll orientation data from the IMU to compute real-time cane tilt angle via a complementary filter. - Read multi-zone distance data from the ToF sensor over I2C. - Dynamically adjust active 8x8 ToF row indexing based on IMU tilt angle to keep the detection field focused at an upper-body level that is not traditionally covered by a white cane. - Classify detected obstacles into left/right zones based on sensor sub-regions. - Map distance-to-obstacle into PWM duty cycle per pad (closer = stronger vibration) with a short initial overdrive voltage pulse to minimize motor spin-up latency. - Have a special vibration pattern for overhead/hanging obstacles by utilizing upper rows of the 8x8 ToF sensor - Sample current-sense ADC channels during motor operation to detect open circuits or stalled motor faults. - Drive corresponding pad(s) via the MOSFET switching circuit in real time. - If an obstacle is at the center, then both left and right motors will vibrate. - The vibration strength from the motor will be proportional to the distance to the obstacle. **Criterion for Success** - Obstacle Ranging & Directional Accuracy: Detect obstacles up to 2 meters indoors with at least 90% correct left/right/center zone classification as well as correct overhead/hanging obstacle classification, and hold that classification accuracy across cane tilt angles up to +15 and -15 degrees. - Have accurate motor vibration strength based on the distance to the obstacle. An obstacle that is farther away should not have a vibration strength greater than an object close by. The distance accuracy tolerance should be +-6cm for obstacles at 1m and should be +-11cm for obstacles at 2m. - System Response Latency: Under 250 ms from TOF data-ready interrupt to motor PWM activation, accounting for the sensor's 15Hz refresh limit in 8x8 high-resolution mode, verified on an oscilloscope. At a typical walking speed of 1.4m/s that is under 40 cm of user travel. - Haptic Control & Fault Detection: Scale vibration intensity proportionally with obstacle proximity while utilizing current sensing to detect a stalled motor or a disconnected motor wire. - Battery Life: Provide at least 4 hours of continuous operation on a single battery charge under standard sensing and haptic load. **Existing Solutions** - There are a few commercial products that already put obstacle detection on a cane such as the WeWalk Smart Cane. It uses a single 40kHz ultrasonic sensor with a 55 degree cone. It covers roughly 80 to 170cm and is aimed at obstacles between waist and head height and the whole handle vibrates when it finds something. - We replace the single cone with an 8x8 time of flight array featuring 63 degrees diagonal (around 45 x 45 degrees) field of view. With 64 independently ranged zones we will be able to tell which side an obstacle is on and vibrate that side of the handle. So the cue points rather than just warning. We also will add a 6 axis IMU to track cane pitch and shift which rows of the grid are active, thus keeping the detection band at torso height as grip angle changes. This is something that none of the existing commercial products do. **Extension** - Expanded Directional Granularity: Incorporate additional haptic pads (e.g., a center pad or top/bottom channels) to provide finer multi-angular obstacle directional awareness directly through the grip. - Adjustable sensitivity/mode via a single button: Oftentimes, you don’t require as much of a range detection inside compared to when you are outside. There could be a button that controls “outside mode” (longer detection range) and “inside mode” (shorter detection range). - Intersection & Crossing Awareness Subsystem + GPS: The device connects to a companion phone and uses the phone's GPS as a location reference. When the user approaches a mapped intersection or crossing, the phone signals the cane and the cane outputs a distinct haptic pattern that is clearly different from an obstacle cue. This alerts the user to an upcoming crossing and, combined with the directional pads, helps them orient toward the crosswalk. - Fall Detection & Emergency Alert Subsystem: Uses the existing 6-axis IMU to detect fall-like acceleration and orientation events through a threshold and timing algorithm, with a canceling window to reject false alarms. On a confirmed fall or a manual SOS button press, the ESP32 triggers the paired phone to send an alert and last known location to a preset contact using the phone’s built-in automation so no custom app is required. |
||||||
| 27 | Pickleball Paddle Sensor Module |
Alex Luckett Levente Deak Peter Brennan |
Eric Tang | Arne Fliflet | other1.pdf other2.pdf |
|
| # Pickleball Paddle Sensor Module Team Members: - [Peter Brennan] (petersb2) - [Teammate 2] ([netid]) - [Teammate 3] ([netid]) # Problem Pickleball has exploded in popularity, but players at every level have no easy way to quantify their performance. Coaches and serious players in other racket sports (tennis, baseball) have long had access to swing analytics, but pickleball lags behind. Most "smart" options on the market today either require a bulky, fully sensor-laden paddle or rely on computer vision, which is impractical for casual, everyday play. # Solution We want to build a small PCBA-based sensor module that mounts to a standard paddle and automatically tracks meaningful in-game stats. Using an IMU, the board will detect and classify swing type (drive, dink, serve, volley, forehand, backhand) and estimate swing speed. A secondary sensing approach like a piezo or contact microphone tuned to the acoustic/vibration signature of ball-paddle contact will handle collision detection, distinguishing an actual hit from a practice swing or incidental bump. As a stretch goal, we would like to refine the collision data further to estimate strike location on the paddle face (center vs. edge/off-center contact), giving players direct feedback on mishits and improving their awareness of the paddle's sweet spot. This project leans harder on sensor fusion and signal processing than on component count. We expect the bill of materials to stay fairly small (IMU, piezo/vibration sensor, MCU, and a BLE module for stat offload), but getting reliable swing classification and clean contact detection out of noisy accelerometer/vibration data will take real iteration. We anticipate several PCB revisions to dial in mounting placement, sensor orientation, and noise isolation from the paddle material itself, along with meaningful firmware work to build out the classification logic. # Solution Components ## Subsystem 1: Motion Sensing & Swing Classification This subsystem captures raw motion data and classifies swing type and speed. It centers on an IMU (accelerometer + gyroscope) mounted rigidly to the paddle handle/frame, feeding data to the MCU for real-time processing. Given the sensor-fusion workload, we plan to use an MCU with sufficient headroom to run classification in real time, likely an STM32, though we will evaluate lower-power alternatives if battery life becomes a constraint on the wearable-scale board. - IMU, part number TBD pending evaluation - MCU: STM32 (family/part TBD), evaluating against lower-power alternatives ## Subsystem 2: Contact/Collision Detection This subsystem determines whether the paddle has made genuine contact with the ball, as opposed to a practice swing or incidental bump. It uses a piezo element or contact microphone bonded to the paddle face/frame, tuned to the acoustic/vibration signature of ball-paddle impact, with supporting analog front-end circuitry (filtering/amplification) to condition the signal before it reaches the MCU. - Piezo disc or contact microphone element, part number TBD - Analog conditioning circuitry (amplifier/filter stage), parts TBD ## Subsystem 3: Data Offload & Power This subsystem handles logging and wirelessly offloading swing/contact data to a phone or companion app, plus powering the whole module in a compact, low-profile form factor that can mount to an existing paddle. - BLE module, part number TBD - Battery and power management circuitry, parts TBD # Criterion For Success * The board reliably detects and classifies swing type (drive, dink, serve, volley, forehand, backhand) from IMU data with demonstrated accuracy across repeated test swings. * The board estimates swing speed from IMU data with consistent, repeatable output across trials. * The contact sensor reliably distinguishes an actual ball-paddle hit from a practice swing or incidental bump, verified through controlled testing. * The PCBA is small and low-profile enough to mount to a standard paddle without interfering with normal play. * Swing and contact data is successfully offloaded via BLE to a phone or companion app and can be logged for a full session. * Stretch: the system estimates strike location on the paddle face (center vs. edge/off-center) with demonstrated accuracy. * Stretch: a companion app or dashboard visualizes session stats (swing counts, types, speeds, contact accuracy). |
||||||
| 28 | Ant-Weight Battle Bot Proposal |
Danilo Markus Matia Choi Nikola Plavsic |
Shengkun Cui | Viktor Gruev | other1.pdf other2.pdf |
|
| # Ant-Weight Battle Bot Proposal Team Members: - Matia Choi (hyunwoo6) - Nikola Plavsic (plavsic2) - Danilo Markus (dmarkus2) # Problem This is our team's entry in the Fall 2026 ECE 445 Battlebots competition (Prof. Viktor Gruev): a bracket tournament of sub-2 lb, fully 3D-printed combat robots. Requirements involve wireless link to a laptop for control and judged on agility, control, and damage. Every entrant is required to carry a custom PCB with an MCU, wireless control, and motor drive. This year every robot must stream a live camera feed and time-of-flight range data to the driver's laptop, rendered live in the driver interface rather than only logged. Our team is entering on the camera-and-ToF track rather than the competition's alternative custom-weapon-ESC track. # Solution We will build the robot's custom PCB around an ESP32-S3 that captures JPEG video from an onboard camera and range data from four perimeter time-of-flight sensors, streams both live over WiFi to the driver station, and executes drive and weapon commands sent back over the same link. Range rings are drawn directly on the live video in the driver UI. The chassis is 3D-printed in PETG rather than PLA or ABS; PETG should give the combination of rigidity and flexibility that we need. The fighting tool is a horizontal spinning disc driven directly off a BLDC motor shaft through a commercial ESC. The system divides into four subsystems: camera streaming, time-of-flight ranging, weapon and drive, and power. ## Subsystem 1: Camera Streaming - MCU: ESP32-S3-WROOM-1 - Camera: OV5640 5MP module over the ESP32-S3's DVP interface (OV7251 as a fallback if arena lighting causes motion blur since it has a global shutter). - Firmware captures frames, hardware JPEG-encodes, and streams 640×480 at 20–30 fps directly into a WiFi socket to the driver UI. ## Subsystem 2: Time-of-Flight Ranging - Hardware: four VL53L1X single-zone ToF sensors, mounted front/rear/left/right on the chassis perimeter, sharing one I²C bus. - Firmware sequences each sensor's XSHUT pin at boot to reassign I²C addresses off the shared default (0x29), polls all four continuously, and pushes ranges to the driver UI as a proximity ring over the live video. ## Subsystem 3: Weapon and Drive - Weapon: a horizontal spinning disc keyed directly to a BLDC outrunner motor shaft (KV and disc mass/diameter subject to change, selected once the chassis weight budget is finalized), spun up through a commercial brushless ESC taking a PWM command from the MCU - Drive: TB6612FNG dual H-bridge driving two brushed drive gearmotors to create a differential drive. Controlled directly from MCU PWM+direction pins. - Safety: a link-loss watchdog opens a MOSFET in the shared motor power path (weapon + drive) within 500ms of losing the WiFi control link, independent of firmware state, plus a manual E-stop through the same cutoff; firmware holds the weapon ESC in a zero-command disarmed state except during a match. ## Subsystem 4: Power - 2S LiPo pack sized to the 2 lb weight budget, feeding motors directly and, through an AP2112K-3.3 and TLV70033, regulated 3.3V/5V rails for the MCU, camera, and ToF array. - Pack capacity subject to change; selected once total system current draw is measured on the assembled board. # Criterion For Success 1. Camera subsystem streams 640×480 JPEG at 20–30 fps sustained for a full 2-minute match with the overlay 2. All four VL53L1X sensors correctly re-addressed and readable over I²C on consecutive power-on cycles; reported range consistent with physical measurement. 3. All motor power cuts within 500ms of an induced WiFi disconnect, and confirm ability to re arm. 4. Functional weapon to defeat enemy teams. 5. Total robot mass, including battery, under 2 lb as weighed at inspection. |
||||||
| 29 | Compact Electronic Nose for Food Identification and Freshness Monitoring |
Haotian Li Torres Zhang Zhenyu Zhang |
Shengkun Cui | Arne Fliflet | design_document1.pdf proposal1.pdf |
|
| # Problem Food freshness is usually evaluated using expiration dates, visual inspection, or human smell. These methods are subjective and may not detect early spoilage. As food ripens or decomposes, it releases volatile compounds such as alcohols, ammonia, sulfur-containing gases, and other VOCs. A single low-cost gas sensor cannot reliably identify food because it normally responds to several different gases. However, an array of sensors with different sensitivities can generate a unique response pattern for each food and freshness condition. Many existing low-cost electronic nose projects use prebuilt sensor modules and passive air sampling. Their results are often affected by airflow, temperature, humidity, and sensor placement. Our project aims to improve repeatability through a custom PCB and a controlled sampling system. # Solution We propose a compact electronic nose that identifies predefined foods and estimates whether they are fresh or spoiled. A small diaphragm pump will draw gas from a food container into a sealed sensing chamber. Four gas sensors mounted on a custom PCB will respond to different components of the food odor. Their signals will be filtered, digitized, and processed by an STM32 microcontroller. The STM32 will compare the sensor responses with a clean-air baseline and generate an odor fingerprint. A lightweight classification algorithm will use this fingerprint to predict the food type and freshness state. After the result is displayed, the system will introduce filtered air to clean the chamber before the next measurement. # Solution Components Gas-Sensor Subsystem The system will use four raw gas sensors rather than prebuilt sensor modules. The proposed sensors are: TGS2602 for general VOCs, ammonia, and sulfur-containing odors; TGS2620 for ethanol and other organic vapors; MQ137 for ammonia and organic amines; MQ136 for hydrogen sulfide and sulfur-containing vapors. The sensors will be placed near one edge of the PCB so that they can extend into the sensing chamber. The remaining electronics will remain outside the chamber to reduce the influence of circuit heat. Each sensor will have its own load resistor, voltage-scaling circuit, and low-pass filter. A TLV9004 quad operational amplifier will buffer the four signals before they are measured by the ADC. # Data-Acquisition and Processing Subsystem The main controller will be an STM32F411RCT6 mounted directly on the PCB. It will control the sampling sequence, collect sensor measurements, calculate odor features, run the classifier, and present the result. An ADS1115 four-channel ADC will digitize the four gas-sensor signals. A separate SHT31 temperature and humidity sensor will record environmental conditions so that the STM32 can compensate for their effect on the gas sensors. The classifier will first be trained on a computer using experimental data. The final model will then be stored on the STM32 so that classification can be performed without a connected computer. # Air-Sampling Subsystem The airflow system will include: A sealed sensing chamber; A food-sample container; A miniature 5 V diaphragm pump; A three-way solenoid valve; Sample tubing; A clean-air filter. The valve will switch between the food sample and filtered ambient air. The pump will draw the selected gas through the sensing chamber. The STM32 will automatically perform the following sequence: Purge the chamber with filtered air. Record the clean-air baseline. Switch the valve to the food sample. collect the sensor responses. classify the food and freshness. display the result. purge the chamber again. Power and Pump-Control Subsystem The system will be powered through USB-C. The 5 V input will directly supply the gas-sensor heaters, pump, and solenoid valve. A 3.3 V regulator will supply the STM32, ADC, environmental sensor, and analog circuits. The pump and valve will be controlled using MOSFET driver circuits. Flyback diodes and bulk capacitors will protect the PCB and reduce electrical noise when the pump or valve switches. The PCB will also include an SWD programming connector, a start button, status LEDs, and USB serial communication for data collection and debugging. # User Interface Subsystem The user will place a food sample in the container and press the start button. Status LEDs will indicate whether the device is purging, sampling, processing, or ready. The final result can be shown using a small display or sent to a computer through USB. It will include the predicted food type and freshness condition. # Criterion for Success The project will be considered successful if: The team designs, fabricates, and solders a custom PCB containing the raw gas sensors, STM32, ADC, analog circuits, power regulation, and pump-control circuits. The system automatically completes the baseline, sampling, classification, and purge sequence after the user presses the start button. Repeated measurements of the same food produce similar sensor-response patterns. The prototype can distinguish at least two predefined foods, initially apples and bananas. The prototype can distinguish fresh and spoiled samples with at least 80% accuracy. The system produces a result within five minutes and successfully returns the sensors close to their clean-air baseline before the next measurement. |
||||||
| 30 | Self-Calibrating Long-Exposure Laser Light Painter |
Alex Chen Billy Huang Michael Shi |
Denghan Xiong | Viktor Gruev | design_document1.pdf proposal1.pdf |
|
| # Self-Calibrating Long-Exposure Laser Light Painter Team Members: * Alex Chen (alex18) * Billy Huang (billyh2) * Michael Shi (mwshi2) # Problem Long-exposure light painting is normally done by hand, so it is difficult to repeat a drawing or reproduce a specific image. A laser steered by galvanometer mirrors can draw a vector image while a camera shutter remains open, but existing hobby systems use off-the-shelf galvo kits without measuring the finished output. Two errors are especially visible in the photograph: geometric distortion caused by mirror geometry and sensor scale error, and uneven exposure caused by the beam slowing at corners and moving quickly along straight segments. Because the camera integrates every error over time, these effects appear as bent lines, bright blobs, and dim strokes. # Solution We will build a laser light-painting instrument on a custom controller PCB. A pair of closed-loop galvos will steer a 650 nm laser onto a rear-projection screen inside an enclosure while a DSLR takes a long exposure. The controller will measure where the beam lands with a removable photodiode calibration target, fit a two-dimensional geometric correction, and modulate laser current based on beam velocity so that each millimeter of a stroke receives similar exposure. The final two-axis demonstration will use the galvo kit amplifiers. We will also design and characterize one custom galvo servo daughtercard containing loop compensation, current sensing, and a bipolar power stage. It closes the loop on one axis using the position signal already produced by the kit driver. The kit driver's output link acts as a hardware selector: with the link removed, the kit cannot drive that coil and the daughtercard does, so the two can never drive the same coil at once. Reach goals, in priority order: a small learned residual model trained on recorded trajectories to correct errors the static correction misses, with training on a laptop and bounded inference on the microcontroller; a second custom servo channel; and a music-driven drawing mode. # Solution Components ## Subsystems 1. Controller and embedded processing. Plays vector stroke files, applies the geometric correction, generates X/Y commands, controls retrace blanking and the camera shutter, and produces the heartbeat. STM32G474RET6, DAC8562SDGSR, OPA2197ID, TPS3823-33DBVR. 2. Photodiode calibration target. Measures beam landing positions for the correction fit; the perimeter cells also retrigger the beam-stall watchdog. Nine BPW34 photodiodes, nine OPA380AID transimpedance amplifiers, nine TLV3501AIDBVR comparators, 650 nm bandpass filters, apertures. 3. Laser driver, exposure control, and safety interlock. Constant-current drive with monitor-photodiode feedback, velocity-dependent current, and the hardware interlock chain. RLD65MZT7, OPA197IDR, 2N7002K, TLV1702AIDR, D2HW-A201D lid switch, key switch, interlock MOSFET. 4. Custom galvo servo daughtercard. Closed-loop position servo and power stage for one galvo axis. This is the main custom analog design in the project. OPA2197ID, INA240A2DR, TIP41C/TIP42C, powered from the kit's ±15 V supply. 5. Camera trigger and power. Isolated focus and shutter contacts, the 3.3 V rail, rail supervision, fuses, soft start. Two AQY212EH PhotoMOS relays, TPS62162DSGR, TVS diodes. 6. Optomechanics and enclosure. Galvo mount, screen, baffles, lid switch, laser mount, and the ND filter holder. 3D-printed or extrusion frame with rear-projection film. Interfaces: the controller sends ILDA-standard ±5 V differential X/Y to the galvo amplifiers, and to the daughtercard through the selector. The daughtercard takes its position feedback from the kit driver's buffered position output. The nine comparator outputs go to controller GPIO with timer capture. The laser driver takes a DAC current command and an enable line. The interlock chain is independent of the controller and can only be reset by the key switch. ## Motion Control and Embedded Processing An STM32G474RET6 microcontroller will play vector stroke files converted from SVG on a laptop. Timer-driven DMA will update synchronized X/Y commands, apply the geometric correction (and the learned correction if that reach goal is met), control retrace blanking, and coordinate the camera shutter. A DAC8562SDGSR dual 16-bit DAC and OPA2197ID level-shifting amplifiers will generate the ILDA-standard differential X/Y commands. A TPS3823-33DBVR watchdog will place the laser in its disabled state if the real-time firmware stops responding. ## Galvo Kit and Daughtercard The galvos are a standard ILDA 20 kpps galvo scanner set, sold as a "20K galvo set" on Amazon and by laser-parts.com for about $70 to $130 depending on seller. The set includes two moving-magnet galvo motors with 7 by 11 mm mirrors, two analog servo driver boards, motor-to-driver cables, ILDA differential input cables, a mount, and a ±15 V linear supply rated +15 V at 1.0 A and −15 V at 0.6 A. Published specifications: ±5 V differential command input, 200 kΩ input impedance, over 20 kpps on the ILDA test pattern at ±20° optical, and driver trim pots for input scale, servo gain, low- and high-frequency damping, offset, and position scale. Several sellers also list a buffered position output at 0.5 V/° on the driver. We will record the exact seller and listing in the design document once the kit is in hand. The galvo motor cable carries two coil leads and a sensor bundle: a sensor illuminator or oscillator supply, two differential sensor outputs, and ground. On these kits the sensor output is a small differential current, optical on some units and capacitive with a megahertz oscillator on others, and the sensor is undocumented, so the daughtercard does not include a sensor front end. The kit driver handles sensor demodulation and gain control, and the daughtercard closes its own loop on the driver's demodulated position signal: the buffered position output where the driver provides one, otherwise a follower on the driver's internal position node, which is a low-impedance op-amp output on these boards. The daughtercard contains an OPA2197ID error amplifier (command minus position), an OPA2197ID lead-lag compensator with a notch near the first mirror resonance, an INA240A2DR shunt current sense with a current-limit clamp, and a complementary TIP41C/TIP42C class-AB output stage running from the kit's ±15 V rails. The coil connects to the daughtercard through a breakout cable. The kit driver's output link is lifted so it cannot drive that coil; nothing else on the kit driver is modified. Before any daughtercard layout, in week 2, we will put the kit on the bench and: find the position node on the driver with a scope and confirm its V/° scale against a known command; measure coil resistance and inductance and the driver's coil current at full swing; and swept-sine the kit-driven galvo to find the mirror resonance. If no usable position signal can be found on the driver, we will drop the daughtercard and present the laser driver and the nine-channel calibration target as the custom analog design, with the two-axis image demonstration unchanged. ## Photodiode Calibration Target A removable target will contain a 3 by 3 array of BPW34 photodiodes behind 1 mm apertures and 650 nm filters, at known positions on the screen plane, machined or printed to ±0.1 mm. Each channel will use an OPA380AID transimpedance amplifier and TLV3501AIDBVR comparator. The controller will sweep the beam across the target. Each time the beam crosses an aperture the comparator fires; a microcontroller timer captures the command-space coordinate at both the rising and falling edge, and the midpoint is taken as the beam center for that fiducial. Each crossing is repeated in both scan directions and averaged to cancel comparator delay. Perimeter detectors will also retrigger the independent beam-stall watchdog. Error definition. For each fiducial i with known screen position p_i and commanded position c_i, the residual is e_i = ‖p_i − M(c_i)‖, where M is the current command-to-screen map. We report the RMS and the maximum of e_i in millimeters over a set of test points that were not used in the fit. Correction model. The main error sources are the tangent geometry of two mirrors projecting onto a flat screen, DAC and galvo position-scale gain error, and axis skew and offset. A degree-2 polynomial in x and y with cross terms, fit by least squares to the fiducials, captures all of these. The firmware needs the inverse map, screen to command, so we fit that direction directly: for each fiducial we know the screen position and the command that hit it. The microcontroller stores the coefficients and evaluates them per vertex when a stroke file is loaded. Between vertices the path is linearly interpolated in command space; the fit script checks the worst-case chord error at our stroke lengths. Nine detectors is a thin set for a twelve-coefficient fit (six per axis), so the target has registration pins and can be placed at four known offsets on the screen frame, giving 36 fiducials from nine channels. The held-out test points come from photographing a printed checkerboard. Velocity compensation. Exposure per unit length of a stroke is proportional to P/v, laser power over beam speed on the screen. We compensate in two places. On the laptop, each SVG path is resampled to points spaced for a constant screen speed, subject to the galvo's acceleration limit; at a corner the path decelerates, blanks for a short dwell, and re-accelerates, so the mirror never has to turn a sharp corner at speed, and the blanked segment is shorter than the spot so the line still reads as continuous. In firmware, the beam speed is computed from consecutive command points and the laser current is set to I = I_th + k·v, clamped to the hardware maximum, so P/v stays roughly constant through accelerations. Below a minimum speed the laser is blanked. The constants k and I_th are calibrated by drawing a test stroke at several fixed speeds and measuring stroke brightness in a RAW photograph. The 5 mm exclusion around corners in the success criteria is where the dwell blanking sits. ## Laser Driver, Exposure Control, and Safety A custom constant-current driver will power an RLD65MZT7 laser diode using an OPA197IDR error amplifier, 2N7002K MOSFET, current-sense resistor, and the diode's monitor-photodiode feedback. The commanded current will vary with beam velocity above the lasing threshold and will be blanked during retrace or when velocity falls below a safe minimum. Operating point. The RLD65MZT7 datasheet gives an absolute maximum output of 7 mW, threshold current 20 mA typical and 60 mA maximum, operating current 28 mA typical at 5 mW, and a wavelength of 645 to 665 nm, so the slope efficiency is about 0.6 mW/mA above threshold. Running the diode within a milliamp or two of threshold gives an unstable, LED-like output with poor modulation linearity, which would defeat the velocity compensation. The diode will therefore run at 2 to 3 mW, about 23 to 25 mA, and a fixed neutral-density filter (OD 0.6 or 0.7) after the collimator will bring the beam reaching the mirrors and screen down to at most 0.75 mW, so the 1 mW Class 2 limit holds with margin even at the hardware current clamp. The filter is mounted in the optomechanics and is not user-removable. Class. Accessible emission of 1 mW or less at 650 nm is Class 2 under IEC 60825-1 and ANSI Z136.1. With the lid closed the accessible emission is zero, so the finished instrument is an embedded Class 2 product. Class 2 does not require registration with the Division of Research Safety; only Class 3B and Class 4 lasers are registered. Safety glasses are not required for Class 2. We will keep OD 2 or better glasses at the bench for alignment and driver bring-up, when the ND filter may be out of the path and the diode can emit up to 5 mW, which is Class 3R. Measurement. We will measure optical power rather than infer it from current: with the lab's optical power meter at the screen plane, with and without the ND filter, at the maximum commanded current, and as a cross-check with a BPW34 behind a known aperture using its datasheet responsivity at 650 nm. The maximum commanded current is set in firmware and also hard-clamped by a resistor divider on the OPA197 reference, so software cannot exceed it. Measured values will go in the design document. Training. All three of us will complete the DRS online Laser Safety module in addition to the ECE 445 Laboratory Safety modules and submit the certificates to the TA before laser bring-up. Interlock. A series interlock MOSFET and an independently powered, latched hardware watchdog will disable the laser after a stalled beam (perimeter photodiodes not retriggered within a window), an out-of-zone command (a TLV1702AIDR window comparator monitoring the X/Y command range independently of firmware), an open D2HW-A201D lid switch, a disarmed key switch, or a missing microcontroller heartbeat. Blanking below the minimum beam velocity is enforced in firmware and backed by the stall watchdog in hardware. ## Camera Trigger and Power Two AQY212EH PhotoMOS relays will provide isolated dry-contact focus and shutter outputs for a standard wired camera remote. The camera is a team-owned DSLR with bulb mode and a wired remote jack; the relays present the same focus and shutter contacts a wired remote does, so any body with a remote port works. The camera is external to the design and not a purchased part. The controller will open the shutter, draw the image, blank the laser, and close the shutter in a repeatable sequence. The galvo kit's ±15 V supply provides the galvo rails and the daughtercard rails; a TPS62162DSGR regulator and local analog filtering will provide the 3.3 V control rail. Rail supervision, fuses, soft start, reverse-polarity protection, and test points will be included on the PCB. ## Controls Background Alex is enrolled in ECE 486 Control Systems this semester and spent two summers doing closed-loop tuning on optical transceivers (bias and equalizer optimization against measured error rates). Billy and Michael have not taken a controls course, so Alex owns the servo loop and the other two own the calibration target, laser driver, and firmware, which are signal-chain and embedded work. To keep the loop design manageable, the daughtercard starts from the kit driver's own topology (proportional gain with low- and high-frequency damping, which is a lead-lag), the plant is characterized by swept-sine on the kit-driven galvo before any compensator values are chosen, and the compensator is a single analog stage with values set from the measured resonance. If the loop does not close cleanly by the week-8 review, the fallback in the success criteria applies. ## Budget ECE 445 provides $50 per student, $150 for the team, through the TA's CFOP. | Item | Estimate | Source | |---|---|---| | RLD65MZT7 laser diode, two (one spare) | $20 | Digikey via TA | | Laser collimator/housing, ND filter, nine 650 nm bandpass filters | $40 | Amazon/Thorlabs via TA | | ICs: nine OPA380, nine TLV3501, four OPA2197, OPA197, INA240, TLV1702, DAC8562, TPS62162, TPS3823, two AQY212EH, 2N7002K, TIP41C/TIP42C | $70 | Digikey via TA | | STM32G474RET6, passives, connectors, twelve BPW34 | $30 | Digikey via TA, ECE Stores | | PCB fabrication, controller plus daughtercard plus target | $0 to $40 | ECE 445 PCB service, PCBway if needed | | ILDA 20K galvo set (two galvos, two drivers, ±15 V supply, cables) | $70 to $130 | personal purchase, not reimbursed | | Enclosure, screen film, mounts | $30 | personal, makerspace | Course-funded parts come to about $160 to $200. Anything over $150 and the galvo kit are personal purchases, which we accept. The laser diode itself is under $10; the galvo kit is the main cost. # Criterion For Success * After calibration, beam-position error measured against a printed checkerboard is at most 3 mm RMS and 6 mm maximum over at least 25 test points across a field at least 500 mm wide at a 1 m projection distance. The test points will not be used to fit the calibration, and calibration must reduce RMS error by at least 60% relative to the uncorrected system. * With velocity compensation enabled, brightness in an unclipped RAW photograph remains within 20% of the median along each stroke, excluding 5 mm around corners and blanking points. * Ten repetitions of the same stroke file reproduce checkerboard positions within 2 mm RMS. * The system draws at least three supplied SVG files, including one containing straight lines, curves, and sharp corners, and in each photograph every stroke in the source file is present as a continuous line with no unintended breaks or extra strokes. * The hardware interlock drops the laser diode below its forward voltage within 10 ms after a stalled beam, zone violation, open lid, or lost heartbeat, verified by fault injection and oscilloscope measurement. * The custom servo holds a static point within 1 mrad optical for 10 minutes after warm-up and settles a 10-degree step to within 2% in 5 ms. If it does not pass by the week-eight go/no-go review, the final image demo will use the kit amplifier and the custom channel will be presented as a characterized subsystem. Reach goals, not success criteria: a learned residual correction model that reduces RMS path error on held-out trajectories relative to the geometric correction alone, running on the microcontroller; a second custom servo channel; a music-driven drawing mode. |
||||||
| 31 | Gamified Focus-Detection Tamagotchi |
Khushi Murthy Michael Yang Noah Yi |
Tim Jiang | Viktor Gruev | other1.pdf proposal1.pdf |
|
| # Problem We are currently living in a time where Gen Z’s attention span is being reduced due to short form media content and various social and technological distractions, leading to decreased productivity. As such, students who force themselves to sit through hours of studying will often find themselves struggling to stay motivated and on task. Methods such as the Pomodoro strategy have been shown to help increase productivity through structure, yet continuous accountability and immediate feedback when a user becomes distracted are still missing factors. # Solution We propose an interactive, desk-based smart companion inspired by a Tamagotchi. The device monitors several indicators of user focus and translates them into the emotional and physical behavior of a desktop pet. A host computer will collect simple focus-related signals, including active application information, keyboard and mouse activity, and whether the user is present at the desk. These signals will be combined into a focus score and transmitted to a microcontroller contained inside a 3D printed enclosure through USB serial communication. The microcontroller will maintain the pet's behavioral state and control its physical outputs. Sustained focus may cause the pet to appear happy or energetic, while extended inactivity or distraction may cause it to appear sad, tired, or perform a physical gesture such as waving its arms to attract the user’s attention. Therefore, our goal is for the companion to create an immediate, external feedback loop that gamifies focus and reinforces effective work habits. The project is divided into three primary subsystems: It will have 3 different subsystems: Software Logic Subsystem: We will connect the board to the laptop to collect focus-related information from the host and compute a focus score. Microcontroller Subsystem: The embedded controller itself that manages the pet’s behavioral state machine and controls the hardware outputs. The Display: Provides the user-facing visual and mechanical feedback for the pet’s state # Solution Components ## Subsystem 1 : Software Logic Subsystem Description: Runs in the background on the host computer to monitor focus. It tracks active application titles, keyboard/mouse input activity, and uses the host webcam to detect desk presence via basic face tracking. To keep the image-processing component feasible, the webcam will not attempt complex activity, emotion, or identity recognition. It will perform a constrained presence-detection task using an existing computer-vision library such as OpenCV or MediaPipe. The system will assume a relatively fixed webcam position and desk environment. It aggregates these metrics into a scoring metric that represents focus state and sends periodic command packets over USB-serial to the hardware. The main software design challenge of this subsystem will be the fusion of multiple imperfect signals into a reliable and explainable focus metric, rather than relying on computer vision alone. Parts: Host PC Software packages ## Subsystem 2 : Microcontroller and Custom Control PCB Subsystem Description: A custom PCB will integrate the Raspberry Pi Pico with the system's power distribution, display interface, actuator-control circuitry, peripheral connectors, and protection components. The board will receive focus-state information from the host computer over USB and generate the electrical control signals required by the display and mechanical actuators. Parts: Microcontroller Board: Raspberry Pi Pico (Part #: SC0915) USB interface Voltage regulation and power distribution circuitry Servo control interfaces Display communication interface ## Subsystem 3 : Display and Actuation Subsystem Description: Provides the physical feedback that makes the device function as a desktop companion. A small display will show animated facial expressions corresponding to the current behavioral state of the pet. One or more servo motors will provide additional mechanical feedback by moving physical components such as the pet's arms. Parts: Small OLED or TFT display Micro servo motors Mechanical arm linkage 3D-printed enclosure Supporting power and signal circuitry # Criterion For Success Success would consist of meeting our objectives for both the hardware and software portion of the project. The software must successfully collect application activity, keyboard/mouse activity, and webcam-based desk-presence information and combine these inputs into a reproducible focus score or state. The host computer must successfully transmit low-latency focus-state updates to the hardware with outputs being shown within 1-2 seconds. The microcontroller must reliably maintain at least four distinct behavioral states, with each state transition determined by documented focus-score thresholds and timing conditions. Finally, Given the same sequence of focus inputs, the system should produce the same behavioral response. Every pet expression and mechanical action should therefore be traceable to a specific focus metric or state-machine transition. |
||||||
| 32 | Air Hockey Playing Robot |
Matthew Feder Micah Wehler Rohan Kapur |
Lukas Dumasius | Viktor Gruev | design_document1.pdf proposal1.pdf |
|
| # Air Hockey Playing Robot Team Members: - Rohan Kapur (rohan21) - Micah Wehler (mwehler2) - Matthew Feder (msfeder2) # Problem Air hockey requires players to track and react to a fast moving object in real time, making it a challenging robotics problem. To solve this, we aim to build a robotic opponent which can autonomously move a paddle to defend and return shots against a human on a mini air hockey table. # Solution Our design will use an overhead camera to track the position of the puck in real time, a raspberry pi for image processing and computation, and a paddle mounted on a H-bot belted mechanism to move. This involves two main subsystems, perception and actuation. # Solution Components ## Subsystem 1: Perception This subsystem will track the position of the puck in real time and determine the ideal intercept location. It will use an overhead mounted Raspberry Pi Camera Module, which will be recording at 720p 120fps. These frames will then be parsed by the Raspberry Pi Compute Module 5, which will be integrated into our custom PCB. The Raspberry Pi will use a color thresholding algorithm to determine the location of the puck, and track it across frames to determine velocity and direction. This information will then be parsed by a simple physics model to determine the ideal intercept location which requires the paddle to move the minimum distance. ## Subsystem 2: Actuation This subsystem is responsible for moving the paddle to the intercept location. It will use two NEMA 17 stepper motors, driven by TMC5160A motor drivers in our PCB, and controlled using SPI by the Compute Module. The stepper motors will drive a linear belt along a H-Bot mechanism to give the paddle two degrees of freedom while keeping both the motors stationary. This allows for rapid acceleration with fewer moving parts. # Criterion For Success The project should be able to contact at least 75% of incoming straight shots and 50% of the single bounce shots where the puck is traveling at less than 4 m/s. |
||||||
| 33 | Consumer-Friendly Spatial Anti-Jamming for WiFi Security Cameras |
Alexander Bessonov Everest Bencher Michael Przybyl |
Pusong Li | Arne Fliflet | design_document1.pdf proposal2.pdf |
|
| Every time I submit a change here it removes sections of the text for no obvious reason. Please see this google doc for the full propsoal: https://docs.google.com/document/d/1VVaIFfs9RK0KfBZxb5jVYl64Iqh2-8qsu0Wub9qeyWo/edit?usp=sharing | ||||||
| 34 | Purrceptron |
Meg Naidu Neel Rajesh Vinny G Smith |
Denghan Xiong | Viktor Gruev | design_document1.pdf proposal1.pdf |
|
| **UPDATED:** # PURRCEPTRON **Team Members:** - Vinny Smith (vgsmith2) - Megna Naidu (megnan2) - Neel Rajesh (neelrr2) This revision responds to the feedback that the project lacked sufficient mechanical complexity. The pet now includes a differential drive assembly consisting of two encoder-equipped gearmotors and a free-spinning ball caster, adding movement as a fourth expressive channel alongside light, sound, and articulated servo motion, together with an H-bridge drive stage and closed-loop control on our PCB. Three additional success criteria cover closed-loop movement accuracy, handling safety, and noise rejection under motor load. ## Problem Companionship and consistent, positive interaction have emotional and psychological benefits, which is why emotional support animals are widely used to help with stress, anxiety, and loneliness. However, owning a living animal is impractical for many people. Housing restrictions, allergies, cost, travel schedules, and the sustained daily time commitment of caring for a pet all act as barriers. Existing alternatives do not fill this gap well. Virtual pet applications have no physical presence, so there is nothing to hold and nothing that persists outside of the screen. Most consumer robotic pets run scripted, non-adaptive behavior loops that become predictable within a few sessions, so no sense of an evolving relationship develops. Adaptive assistive-care robots do exist, but they typically cost hundreds to thousands of dollars. Our goal is to create a low-cost robotic companion that responds to physical touch in a tangible way and develops a history-dependent relationship with its user. The pet's behavior should depend not only on how it is being handled at the moment, but on how it has been treated over the preceding hours and days. ## Solution The proposed system will be a single self-contained robotic companion pet. It will sense how the user physically handles it, maintain an internal emotional state that evolves over time based on that handling, and express that state through light, sound, articulated motion, and movement. The central design decision is that the pet's behavior will depend on its interaction history rather than only its present input. A unit that has been handled regularly over several days will behave differently from an identical unit that has been left alone, even when both receive the same touch at the same moment. Frequent positive interaction will produce energetic, responsive behavior. Extended neglect will shift the pet toward subdued, low-activity behavior. This creates a feedback loop that rewards regular engagement, similar to the reinforcement structure of caring for a real animal. Because behavior is history-dependent, state persistence is a core functional requirement of the system. The pet must survive being switched off, fully discharged, and recharged without losing its accumulated relationship with the user. All emotional state will therefore be owned and stored on the pet itself. The system will not depend on a host computer, a network connection, or an external server for any required functionality. The system will consist of five subsystems: a sensing subsystem that detects touch and handling, an embedded control subsystem that classifies interactions and runs the emotional state machine, an expression subsystem that conveys state through light, sound, articulated motion, and movement, a mechanical subsystem comprising the enclosure and drive assembly, and a power subsystem that supports untethered operation with a controlled shutdown path. ## Touch Interaction and Classification Touch will be the primary input channel, so the sensing design will be built around resolving how the pet is being handled rather than simply whether contact is present. Capacitive electrodes will be distributed across the enclosure at the head, back, sides, and underside. The system will therefore be able to determine where contact occurs and how that contact moves across the body over time. The spatial and temporal pattern across electrodes is what distinguishes a stroke from a tap, and a single finger from a full-hand hold. Contact location will also inform the response, allowing the pet to turn toward the side on which it was touched. The system will classify four interaction types: - **Pet** — Sequential activation across adjacent electrodes, sustained over time, with low motion variance. - **Tap** — A single electrode activating briefly, with no propagation to neighboring electrodes. - **Hold** — Multiple electrodes activating simultaneously and remaining active, with low motion variance. - **Pick up or shake** — Motion-primary. Detected from a change in the measured gravity vector or a spike in acceleration magnitude, with or without accompanying touch. Detection of a pick-up disables the drive motors. A typical interaction sequence would be: 1. The user places a hand on the pet's back. 2. Adjacent electrodes activate in sequence as the hand moves. 3. The microcontroller classifies the event as a petting stroke. 4. The state machine applies a positive delta to mood and attachment. 5. The expression subsystem responds within 100 ms with a brightened expression, a chirp, a tail movement, and a brief turn toward the contact side. 6. The specific response depends on current state, so the same stroke produces an energetic response on a well-cared-for unit and a slower, more muted response on a neglected one. ## Emotional State Model The pet's internal state will be represented by three continuous variables on a 0 to 100 scale. **Mood** will be fast-moving and will respond to individual interactions, with a time constant on the order of minutes. **Energy** will be medium-term. It will deplete during activity and recover during rest, with a time constant on the order of tens of minutes. Energy will also gate movement, so that a low-energy pet responds to touch through light, sound, and articulated motion while remaining stationary. **Attachment** will be slow-moving. It will accumulate through repeated positive interaction and decay under neglect, with a time constant on the order of days. Attachment is the variable that makes long-term care legible to the user. Each classified interaction will apply a bounded delta to one or more variables. Bounding the per-event delta prevents a single burst of interaction from saturating the state and ensures that consistent care over time produces a different result than a short intense session. Between interactions, each variable will decay exponentially toward its baseline according to its own time constant. The current values of these three variables will select the expressive behavior the pet displays at any given moment. ## State Persistence Across Power Loss Because the pet is intended to be handled freely and recharged as needed, the system must define exactly where state lives and what happens when power is removed. All emotional state will be owned by the onboard microcontroller. There is no external device that could hold a competing copy, so there is no possibility of the pet and a host disagreeing about the pet's mood after one of them is powered off. The pet does not need to run while powered off. On shutdown, the system will write a state block containing mood, energy, attachment, and a timestamp of the last update. On power-up, the microcontroller will read the current time from the real-time clock, compute the elapsed interval, and apply the closed-form exponential decay to each variable: ``` S = S_base + (S_0 - S_base) * e^(-dt / tau) ``` This requires a single computation at startup rather than a timer catch-up loop. It also produces an analytically predictable target value, which means the persistence requirement can be tested against a calculated expected result rather than a subjective judgment. Two failure modes will be addressed explicitly in the design. **Write endurance.** Microcontroller flash is rated on the order of 100,000 erase cycles, so state will not be written on every touch event. The working copy of the state will be held in the real-time clock's backup SRAM, and checkpointed to non-volatile storage on a periodic timer, on significant state transitions, and on shutdown. **Uncontrolled power loss.** A soft power button will latch the regulator enable line, so pressing the button triggers a save routine before power is actually released rather than cutting power immediately. A low-battery threshold detected through battery voltage monitoring will trigger the same save path, disabling the drive motors first so that remaining charge is reserved for a clean save. Both an intentional shutdown and a drained battery will therefore produce a valid saved state rather than a corrupted or default-initialized one. The system uses a single cell. Because the power switch is a soft latching enable rather than a series disconnect, the cell remains connected when the pet is switched off, and the real-time clock's backup supply is taken from that same cell downstream of the protection circuit. Timekeeping draws on the order of microamps, which is negligible against the capacity required for normal operation, so no separate backup battery is needed. In the case of complete cell depletion, the clock's oscillator stop flag will be set on the next power-up; the firmware will detect this, restore the last checkpointed state without applying decay, and resynchronize the clock rather than computing an elapsed interval from an invalid timestamp. ## Solution Components ### Sensing Subsystem This subsystem detects how the user physically interacts with the pet. - **Capacitive touch controller — MPR121**, I2C, placed as a bare IC on our PCB. Eight electrodes will be distributed across the enclosure at the head, back, sides, and underside, which is sufficient to resolve contact location and movement while leaving spare channels on the controller. Electrode geometry, spacing, guard traces, and series resistance will be determined experimentally, since capacitive sensing through an enclosure wall is sensitive to material thickness and dielectric properties. - **Inertial measurement unit — ST LSM6DSO**, with the TDK ICM-42688-P as an alternate. Provides three-axis acceleration and rotation. The measured gravity vector will distinguish orientation changes, such as being lifted or tilted, from vibration. This part was selected over the MPU-6050, which is a legacy part; the final choice is pending a distributor stock and lifecycle check. During prototyping, touch will be tested across the full enclosure surface, including near electrode boundaries, to determine appropriate thresholds and to confirm that adjacent-electrode propagation is reliable enough to separate a stroke from a tap. ### Embedded Control Subsystem - **Microcontroller — Espressif ESP32-WROOM-32.** Provides sufficient GPIO, I2C, I2S, and hardware PWM channels for all sensors and actuators, with adequate processing headroom for touch classification, the state machine, and closed-loop motor control. Wireless functionality is unused in the required design and is reserved for the reach goals described below. - **Real-time clock — DS3232.** Maintains accurate time across power loss, which is required to compute how much decay occurred while the device was off. The DS3232 is specified rather than the DS3231 because it includes 236 bytes of backup-powered SRAM, providing a low-wear location for the working state block directly alongside the timestamp it depends on. Its backup supply pin is fed from the main cell rather than from a separate coin cell, so the system carries only one battery. - **Custom PCB** integrating the microcontroller, sensor interconnects, motor and servo drive circuitry, audio drive, battery monitoring, charging, and power regulation. The microcontroller will be responsible for sampling all sensors, classifying interaction events, running the emotional state machine, managing state persistence, and driving all expressive outputs. Performing all of this locally means the pet has no dependency on an external device and no network latency in its response path. ### Expression Subsystem The pet will convey its internal state through four channels operating together, so that states remain distinguishable even if one channel is missed by the user. Each channel is modulated by the same three state variables. - **RGB LED matrix — HT16K33-driven 16x8.** Displays animated eyes and facial expressions. Both the expression itself and the animation rate will vary with state, so a high-energy and a low-energy version of the same mood are visually distinct. - **Speaker and amplifier — MAX98357A I2S Class-D amplifier** driving a 1 W, 4 ohm speaker. The amplifier operates directly from the battery rail across its full discharge range, so no dedicated supply is required. Output at this level is well above what chirps and tones from a device of this size need. - **Micro servo motors — SG90, two units.** Provide head tilt and tail movement, giving close-range articulated expression that remains available while the pet is being held. Both are driven from the battery rail rather than a regulated 5 V supply; reduced torque at the low end of the discharge curve is acceptable for a printed linkage of this mass, and will be confirmed by test. - **Drive motors — two N20 micro metal gearmotors with integrated quadrature encoders**, driven through a TI DRV8833 dual H-bridge. Two driven wheels and a free-spinning ball caster form a differential drive assembly capable of turning in place. Movement is bounded and expressive rather than navigational: the pet performs short forward and backward motions, turns toward the side on which it was touched, and spins in place, with travel distance limited so that it remains within the area in which it was placed. Gear ratio will be selected in the 100:1 to 200:1 range to produce a deliberate pace appropriate to an animal of this size, with the final ratio set once chassis mass is known. Encoder feedback enables closed-loop speed and angle control, which is required because two gearmotors with unmatched characteristics will not track straight or turn repeatably under open-loop drive. The DRV8833 was selected over a discrete FET bridge for board area and integrated protection, and over a motor-driver module because the driver, its decoupling, its current-sense network, and its snubbing form part of our PCB design. Example state expressions: - **HAPPY** — Eyes wide, fast blink, bright. Rising two-tone chirp. Quick tail movement, head upright. Short approach and small excited turns. - **NEUTRAL** — Eyes normal, slow blink. Single short tone. Occasional slow tail movement. Occasional slow reorientation. - **LONELY** — Eyes narrowed, dim, slow animation. Low descending tone. Infrequent movement, head tilted down. Short retreat, then stationary. The actuator loads share the battery rail and are separated from the capacitive sensing circuitry as far as is practical, since switching noise from these loads can otherwise couple into the capacitive front end and produce false touch events. Brushed DC motors make this the most demanding electrical constraint on the board, and it will be addressed at three levels: separated analog and power ground pours joined at a single point with a guard ring around the electrode traces; ceramic snubber capacitors across the motor terminals, ferrite beads on the motor leads, and bulk capacitance local to the H-bridge; and firmware synchronization of capacitive acquisition to PWM off-periods with a short blanking window around motor state changes. ### Mechanical Subsystem The enclosure will be a rounded, hand-sized form designed primarily for 3D printing, with an integrated chassis carrying the drive assembly. Wall thickness in the touch regions will be selected through testing, because capacitive sensitivity falls off with distance between the electrode and the user's hand. Sections directly over an electrode may be thinned relative to structural sections. Servo motion will be transmitted through printed linkages driven by standard servo horns. The two gearmotors will be located on a common axis with sufficient rigidity that misalignment does not introduce tracking error the control loop must correct, and the ball caster will be positioned to keep the center of mass stable under acceleration while leaving the overall form comfortable to pick up and hold. The machine shop will be consulted within the first two weeks of the project to determine which components, most likely the motor mounting plate and the caster mount, require machining, and to establish lead times before the end-of-semester queue builds. The battery, PCB, and speaker will be enclosed and mechanically isolated from the drive assembly and servo linkages so that normal handling does not stress solder joints or wiring. ### Power Subsystem The pet is intended to be handled freely, so it will run untethered on an internal rechargeable battery. Two gearmotors, two servos, and a Class-D amplifier can draw well over an ampere in combination, from a cell whose terminal voltage ranges from 4.2 V down to approximately 3.0 V. Every actuator on the device tolerates that range directly, so the power tree reduces to one switching converter for the logic rail and an unregulated actuator rail taken straight from the cell. - **Battery — a single 3.7 V lithium polymer cell**, with capacity to be determined by a measured power budget. We will produce a per-subsystem table of measured peak and average current before selecting the cell. This cell is the only battery in the system and supplies every rail, including the real-time clock backup domain. - **Real-time clock backup rail** — taken from the cell downstream of the protection circuit and upstream of the soft power switch, so timekeeping and the state block survive with the pet switched off. Backup current is on the order of microamps and is negligible against the operating budget. - **Charging — TI BQ24074**, placed as an IC on our board with thermal regulation and an NTC thermistor. - **3.3 V logic rail — TI TPS63020 buck-boost converter.** A buck-boost topology is required because a single cell falls below the input voltage a low-dropout regulator would need to hold 3.3 V across the full discharge range. - **Actuator rail — supplied directly from the battery**, feeding the motor driver, servos, and audio amplifier. All three tolerate the full cell voltage range, so no boost converter is required, leaving one switching regulator on the board. Local bulk capacitance sized for inrush keeps motor and servo transients from pulling down the logic rail. - **Battery voltage monitoring** through a resistor divider into a microcontroller ADC input, feeding the low-battery save-and-shutdown path described above. - **Soft power control** through a latching enable circuit so that the microcontroller controls when power is actually removed. ## Criterion For Success **1. Touch Interaction Classification** The system must correctly classify all four interaction types, pet, tap, hold, and pick-up/shake, with at least 90% accuracy over 30 trials per interaction type. All classification must run on the onboard microcontroller with no external compute device. **2. Touch Coverage** Touch must be detected at a minimum of 8 defined test points distributed across the intended interaction surfaces, including at least 3 points near electrode boundaries, with a false-negative rate under 5% over 5 trials per point. **3. Response Latency** The time from the onset of a touch event to the first visible or audible feedback must be under 100 ms, measured over at least 20 trials. **4. Closed-Loop Movement Control** With encoder feedback active, the pet must drive a commanded 1 m straight path with lateral deviation under 10 cm, and execute a commanded 90 degree turn in place within plus or minus 10 degrees, each over at least 20 trials. **5. Distinguishable State Expression** The expression subsystem must produce outputs for at least three internal states, such as happy, neutral, and lonely, that are distinguishable through combined light, sound, articulated motion, and movement. In a blind test, observers must correctly identify the displayed state at least 90% of the time. **6. State Persistence Across Power Cycles** After a full power-off of at least 30 minutes, the restored mood and energy values must match the analytically predicted decayed value within 5%. This will be verified over at least 10 trials spanning varied off-durations, ranging from 30 minutes to 24 hours. **7. Graceful Shutdown** State must be correctly saved and restored in both intentional shutdown, triggered by a button press, and simulated battery exhaustion, triggered by a forced low-voltage condition. Over at least 10 trials of each case, there must be zero corrupted or default-initialized state reads on the subsequent power-up. **8. Long-Horizon Behavior** Attachment must measurably increase under a scripted regimen of regular interaction and measurably decrease under a scripted neglect regimen. The two resulting states must produce visibly different expressive behavior in response to an identical test interaction, confirming that the pet's response depends on interaction history rather than only on present input. **9. Noise Rejection** Motor actuation, servo actuation, and audio playback must not generate false touch events. During a test in which the pet exercises all four expression channels continuously for 5 minutes with no user contact, the system must register no more than one false touch detection. **10. Handling Safety** Drive motors must stop within 200 ms of a detected pick-up event, over at least 20 trials, with zero cases of wheels continuing to turn while the pet is held. **11. Battery Life** The device must run untethered for at least 3 continuous hours of intermittent interaction, including movement, before requiring a recharge. **12. Custom Circuit Design** The custom PCB must contain the microcontroller interface, capacitive touch and IMU sensor interfaces, H-bridge motor drive with encoder inputs, servo drive circuitry, audio amplifier interface, battery monitoring, charging interface, and voltage regulation. The PCB must interface with all sensors and output peripherals with no more than a 5% sensor read failure or dropout rate over a 10-minute continuous test with motors running. **13. End-to-End Demonstration** During the final demonstration, the system must: - Power on and restore its prior emotional state, correctly decayed for the elapsed time. - Detect and correctly classify each of the four interaction types. - Update its internal state in response to those interactions. - Produce state-appropriate light, sound, articulated motion, and movement. - Demonstrate that the same physical interaction produces different responses at different internal states. - Perform a controlled shutdown and restore state correctly on the following power-up. ## Reach Goals The following extensions will be considered only after all criteria above are met. Each is additive to a complete system, and no listed success criterion depends on either. **Autonomous surface navigation.** Adding forward-facing time-of-flight ranging sensors and downward-facing reflective optical sensors would allow the pet to detect a nearby user, detect the edge of a raised surface, and move freely across a tabletop rather than performing bounded movements in place. This would extend the existing closed-loop motor control with obstacle avoidance and edge detection, and would require no change to the state machine, which would supply the same behavioral policy over a larger operating area. **Vision-assisted mood input.** A camera module would capture the user's face and stream the image over the local network to a separate host device running a lightweight facial expression classifier, which would publish a coarse mood category back to the pet. The state machine would treat this as an additional weighted input alongside touch. If the host is unavailable or powered off, the pet continues to operate normally with no change to its required behavior. This extension introduces a separate perception problem, an additional compute device, and a network dependency that does not exist in the base architecture, and is therefore not required for successful completion. ## Ethics and Safety **Handling and physical safety.** Drive motors are disabled whenever a pick-up is detected, so the wheels do not turn while the pet is in a user's hands. Movement in the base design is bounded in distance, so the pet remains within the area in which it is placed. Motor and servo pinch points will be enclosed, and the enclosure will have no small detachable parts, since a device that resembles a pet will attract children. **Battery safety.** The design uses a single-cell lithium polymer battery with charging, protection, thermal management, and a controlled low-voltage shutdown path. We will complete the additional battery safety training required by the course before charging any cell in the lab. **Privacy.** The base design contains no camera, no microphone, and no network dependency. All sensing is touch and motion based, and no data leaves the device. Should the vision reach goal be pursued, it would be confined to the local network, with a hardware indicator active whenever the camera is powered. **Emotional dependency and vulnerable users.** The product is aimed at people experiencing loneliness or anxiety. We will not represent it as a therapeutic or medical device and will make no clinical claims. The neglect behavior is intentionally bounded: the pet becomes subdued and withdrawn, but we will not design guilt-inducing or coercive behaviors, and the pet cannot be permanently harmed. This follows the IEEE Code of Ethics obligation to hold paramount the welfare of the public. |
||||||
| 35 | Smart Patient Bed for Pressure-Injury Prevention |
Rayan Soltana Tyler Marrazzo |
Denghan Xiong | Cunjiang Yu | design_document1.pdf proposal1.pdf |
|
| **Team Members: ** - Rayan Soltana (soltana2) - Tyler Marrazzo (tyleram3) - N/A () ## PROBLEM Bedridden patients can often remain in the same position for long periods of time, which could lead to sustained pressure on parts of the body. Nurses and caregivers have to periodically reposition and monitor these patients, and it's difficult to keep track and continuously know how long some areas have experienced pressure. ## SOLUTION My proposed solution is to create low-cost sensing layer/pad that sits underneath a patient and continuously measures their pressure distribution and position. Inside this pad we plan to have an array of pressure sensors connected together in a grid. We will limit the amount of of sensors to limit any ghost current, which comes from the overlap of the circuitry. This array gets fed into MUXs and then to an external ADC as we will probably need more specific values from the sensors. The digital values will the be fed into an MCU, which will processes the sensor array to determine whether pressure has remained concentrated in a region for too long and alerts the caregiver via bluetooth when the patient should be moved. **MAIN COMPONENTS** **_SUBSYTEM 1: SENSORS_** The pressure sensor subsystem provides the physical interface between the patient and the monitoring electronics. The pad will contain multiple pressure-sensitive regions distributed across its surface. Low-cost piezoresistive materials and conductive fabric will be investigated as possible methods of constructing a flexible sensor array. When pressure is applied to a sensing element, its electrical resistance changes. This change can be converted into a measurable voltage and used to estimate the relative pressure being applied to that area. The exact number and arrangement of sensors will be determined experimentally. An initial design may contain approximately 24 to 32 sensing regions, providing enough spatial information to distinguish major changes in body position without unnecessarily increasing the complexity of the sensing circuitry to limit ghost current. **_SUBSYSTEM 2 ANALOG ACQUISITION:_** The analog acquisition subsystem acts as the interface between the pressure-sensitive pad and the MCU. Because the sensors are resistive devices, voltage-divider or similar signal-conditioning circuits will convert resistance changes into analog voltages that can be measured by an ADC. Rather than dedicating an ADC channel to every pressure sensor, analog multiplexers will sequentially connect individual sensing channels to the measurement circuitry. The MCU will control the multiplexer address lines, select a sensor, allow the analog signal to settle, record its ADC measurement, and then proceed to the next sensor. This process will repeat continuously to construct a complete pressure map. The initial design will investigate using the ESP32-S3's internal ADC. If testing demonstrates that additional resolution, stability, or noise performance is required, an external ADC may be incorporated into the design. **_SUBSYSTEM 3: MCU_** The MCU subsystem serves as the primary controller and decision-making component of the system. An ESP32-S3 is currently planned because it provides sufficient processing capability, ADC functionality, GPIO resources, and integrated Bluetooth Low Energy support. The MCU will control the analog multiplexers and periodically scan the complete sensor array. The resulting measurements will be stored as a two-dimensional representation of pressure across the sensing pad. Before making decisions from these measurements, the MCU will perform calibration and filtering to reduce noise and compensate for differences between individual sensing elements. The processed measurements can then be used to identify regions experiencing elevated pressure and determine whether the overall pressure distribution has changed significantly. The system will maintain information about pressure over time rather than making decisions from a single measurement. If elevated pressure remains concentrated in a particular region while the overall pressure distribution indicates that the patient has not meaningfully repositioned, the MCU can transition the system from a normal state to a warning or alarm state. The alarm algorithm will be developed and evaluated experimentally. Important parameters may include pressure thresholds, duration thresholds, the magnitude of pressure-map changes required to classify a movement as a meaningful repositioning, and methods of rejecting brief movements or sensor noise. The MCU will perform this processing locally so that the monitoring system does not depend on an external computer or wireless connection to determine when an alarm should occur. **_SUBSYSTEM 4: BLUETOOTH / ALARM_** The communication subsystem will use Bluetooth Low Energy to transmit patient status information from the monitoring pad to a separate caregiver-facing device. BLE is integrated into the planned ESP32-S3, reducing the need for a separate wireless communication module. Rather than transmitting all raw sensor measurements, the MCU will perform the primary processing locally and transmit the resulting system state. For example, the system may communicate states such as normal operation, repositioning recommended, repositioning required, or a possible bed-exit condition if that stretch goal is implemented. The system will also include a local alarm, such as a buzzer and visual status indicator, controlled directly by the MCU. This ensures that an alarm can still be generated if Bluetooth communication is unavailable. **CRITERIA FOR SUCCESS** - Reliably acquire pressure measurements from all sensing regions without requiring a dedicated MCU input for every sensor. - Detect and display meaningful differences in pressure distribution when a user changes position on the pad. - Correctly distinguish meaningful repositioning from small movements and normal sensor variation under defined test conditions. - Continuously monitor pressure measurements and track how long elevated pressure persists in different sensing regions. - Generate a local warning or alarm when the defined prolonged-pressure condition is reached. - Successfully transmit the system's status or alarm condition using Bluetooth Low Energy. - Demonstrate reliable operation of the complete system during repeated simulated patient-monitoring tests. |
||||||
| 36 | RoadSense: Road Condition Detection and Pothole Mapping System |
Adam Moine D'Angelo Manzo Jovan Kular |
Shengkun Cui | Arne Fliflet | other1.pdf other2.docx proposal1.pdf |
|
| # RoadSense: Road Condition Detection and Pothole Mapping System Team Members: - D’Angelo Manzo (dmanz2) - Adam Moine (moine2) # Problem Describe the problem you want to solve and motivate the need. Road damage like potholes, bad pavement, and large joints on the road can be really difficult to report and keep track of consistently. For someone just driving over it with their car, they aren’t able to gauge just how bad the road is. This isn’t just for roads that cars drive on, its for roads that include bike lanes. These bike lanes accommodate scooters, bikes, skateboards, and other EV devices. From experience, these road conditions, especially for bike lanes, can be dangerous and cause accidents if not careful. It could also cause irreparable damage to these devices, which could cost a lot of money. The main problem is, people who ride on these roads have no idea whether they are safe for the mode of transport they decide to use. # Solution Our solution would be a small sensor system that can be mounted on a car or bike to measure the motion caused by the roads surface. This system would use acceleration, rotation, vibration, speed of vehicle, and gps to identify road events. The system should be able to separate a pothole or rough pavement from normal events like braking, turning, or going over a speed bump. The sensor unit we would build would be mounted to any vehicle, and would use a software application to analyze the recorded data. During a trip, it will measure 3 axis acceleration and angular velocity. It will also provide information from a sensor that measures the frequency of road vibrations as well. The gps data will provide the location and speed. Finally, we would use a microcontroller to compile all the measured data and store it. # Solution Components ## Motion and Orientation Sensing Subsystem This subsystem measures the motion of the vehicle caused by the road surface. The part we would use is a Bosch BMI 270 six axis IMU. It would provide 3 axis acceleration and velocity information. It would be mounted directly on the main pcb. The accelerometer and gyroscope data will be used together to estimate the sensor orientation so the software can calculate vertical acceleration even when the enclosure isn’t perfectly level. ## Vibration Signal Subsystem This subsystem will measure high frequency vibrations caused by potholes and rough pavement. We would use a piezoelectric vibration element to detect the vibrations and covert them into an electrical signal. We would also use an MCP6002 operational amplifier along with resisters and capacitors to amplify, filter, and adjust the signal so it can be safely read by the microcontroller. The conditional signal will be recorded with stm32f411ceu6 adc along with imu and gps data. ## Location and data logging subsystem This subsystem would record the location, speed,and sensor data collected during the trip. A u-blox MAX M10S GNSS receiver will provide the vehicles gps location and speed. The STM 32F411CEU6 microcontroller will conllect the gps data along with measurements from the imu and vibration sensor and add timestamps to the data. ##power subsystem This subsystem would provide power to the sensors and the microcontroller. THe system will receive power from a low voltage usb source using an ap2112k-3.3 voltage regulator. Capacitors will be placed near the components to help keep the power supply stable. There would also be input protection to help protect the circuit from unstable or incorrect input power. # Criterion For Success 1. The system will sample and record data from the IMU, vibration sensor, and gps all at the same time, at a rate of 100 samples per second for the imu. 2. The system will record at least 30 minutes of continuous data to a storage device without losing or corrupting data. 3. The system will detect at least 90 percent of potholes that provide a vertical acceleration. 4. The system will distinguish between speed bumps and potholes with at least a 80 percent accuracy. 5. The system will distinguish between rough road sections from smooth ones with a 90 percent accuracy. 6. Each road event that is detected will induce its time, location, speed, event type, and severity. 7. The mapping software will display the recorded trip and detect road events on a map, including their locations and severity. 8. When the same road defect is detected, the software will provide a caution signal for future trips. |
||||||
| 39 | Rapid Adaptation Rover: Learned Dynamics Compensation for a Differential-Drive Robot |
Bhavya Agrawal Devansh Agarwal Srish Vijay |
Aniket Chatterjee | Viktor Gruev | design_document1.pdf proposal1.pdf |
|
| # Rapid Adaptation Rover: Learned Dynamics Compensation for a Differential-Drive Robot Team Members: - Bhavya Agrawal (bhavyaa2) - Srish (svija4) - Devansh (Da30) # Problem A mobile robot's response to its motor commands depends on physical properties such as vehicle mass, rotational inertia, motor strength, battery voltage, drivetrain resistance, and wheel-ground interaction. A controller tuned for one operating condition can therefore behave differently when these dynamics change. For example, adding payload changes the rover's acceleration and turning response. Increased resistance on one drive side can cause asymmetric motion and heading error. Battery-voltage variation or differences between the left and right motors can also change the motor effort required to achieve a requested speed. A conventional feedback controller can reject some disturbances, but fixed controller gains may produce substantially different transient performance as the physical system changes. In many systems, the controller also has no direct information describing which physical parameter changed. Our project will investigate whether a rover can instead infer information about its current dynamics from its own recent measured behavior and use that information to improve control. The deployed controller will not be told that a payload was added, that one motor became weaker, or that additional drivetrain resistance was applied. It will only observe signals physically available onboard, including previous motor commands, wheel velocities, IMU measurements, motor currents, and battery voltage. The primary engineering question is: **Can a learned controller that estimates a useful dynamics representation from recent onboard measurements improve motion tracking under changing operating conditions compared with a well-tuned fixed-gain controller and the same learned policy without adaptation?** # Solution We will design and build a two-wheel differential-drive rover containing: 1. Two encoded brushed DC gearmotors and an 80 mm wheel drivetrain. 2. A custom STM32-based motor-control and sensing PCB. 3. Onboard current, encoder, IMU, and battery-voltage sensing. 4. A Raspberry Pi 4 executing a learned controller. 5. A simulation and training pipeline for learning dynamics-dependent control behavior. 6. Repeatable physical disturbance mechanisms for quantitatively testing adaptation. The custom PCB will be the real-time interface between the physical rover and the learned controller. It will independently drive both DC motors, acquire both quadrature encoders, acquire IMU data, measure each motor current, measure battery voltage, enforce safety limits, and transmit timestamped telemetry to the Raspberry Pi. The Raspberry Pi will run a learned policy based on a two-stage privileged-training architecture. During simulation training, physical parameters such as rover mass/inertia, left and right motor effectiveness, drivetrain resistance, battery voltage, sensor errors, and delays will be randomized. A privileged encoder will have access to these simulated parameters and produce a compact dynamics representation. A control policy will learn to use this representation together with the current state and requested motion to generate left and right motor commands. For deployment, the true physical parameters will not be available. A second neural network, the **history encoder**, will infer a dynamics representation from approximately the previous 30 policy timesteps of measurements and applied motor commands. The policy will then use this inferred representation to modify its motor commands. The deployed system will contain no explicit disturbance-specific rules such as: - "if payload is added, increase PWM," - "if current exceeds a threshold, switch controllers," or - "if the right motor is weak, compensate by a fixed amount." The network weights will remain fixed during testing. Adaptation will occur because the rover's recent sensor/action history changes, producing a different inferred dynamics latent. The rover will initially operate indoors on a level, dry floor. The target command envelope is approximately 0–0.20 m/s forward speed and up to approximately ±1 rad/s yaw rate, subject to the validated motor operating range. The learned controller will initially run at 50 Hz using a 30-sample history corresponding to approximately 0.6 seconds. The core disturbances will be: - removable payload of approximately 0.25 kg and 0.50 kg, subject to motor-load testing, and - repeatable asymmetric mechanical resistance applied to one drive side. A combination of payload and asymmetric resistance will also be reserved as a held-out physical test condition. # Solution Components ## Subsystem 1: Custom Motor-Control and Sensor PCB The major circuit-level hardware component of the project will be a custom PCB centered around an **STM32G431CBT6** microcontroller. The PCB will be responsible for: - independent bidirectional control of two brushed DC motors, - quadrature encoder acquisition, - IMU acquisition, - independent left/right motor-current measurement, - battery-voltage measurement, - power distribution for low-voltage electronics, - timestamped communication with the Raspberry Pi, - command limiting, - driver-fault monitoring, - watchdog behavior, - and emergency motor disable. Major components will include: - **STM32G431CBT6** microcontroller - **2x Texas Instruments DRV8874** brushed DC motor drivers - **2x Texas Instruments INA240A1** current-sense amplifiers - **2x 33 mΩ, 1%, ≥1 W current-sense shunt resistors** - **SN74LVC14A** encoder-interface/Schmitt-trigger IC - **TDK ICM-42688-P** six-axis IMU - **TLV75533P** 3.3 V regulator - battery-voltage resistor-divider and ADC interface - main fuse, power switch, reverse-polarity protection, decoupling, connectors, and protection circuitry Each motor will use an independent DRV8874 H-bridge. The initial hardware peak-current limit will be approximately 1.2 A per motor, with an additional lower sustained-current limit and stall timeout implemented in firmware. The INA240A1 channels will independently measure signed motor current. With a 33 mΩ shunt and gain of 20 V/V, the current-sense output will be centered near half of the 3.3 V ADC range to permit measurement of positive and negative motor current. The STM32 will generate motor PWM at an initial target frequency of 20 kHz. Wheel-speed estimation and safety checks will run at approximately 1 kHz. Telemetry will be sent to the Raspberry Pi at approximately 100 Hz. Communication between the STM32 and Raspberry Pi will use 3.3 V UART with packet framing, timestamps, sequence numbers, and error checking. If no valid motor command is received for approximately 100 ms, the STM32 will disable both motor drivers. An independent MCU watchdog and a hardware emergency-stop path will provide additional protection. The PCB will also include SWD programming access, reset circuitry, test points, and required supply decoupling. ## Subsystem 2: Differential-Drive Actuation and Mechanical Platform The rover will use two **Pololu #4866 75:1 Metal Gearmotor 25Dx69L MP 12 V with 48 CPR encoders**. The selected motors have approximately 100 RPM no-load output speed at 12 V and use 4 mm D-shaped output shafts. The drivetrain will use: - **2x Pololu #4866** encoded 12 V gearmotors - **Pololu #3690** 80×10 mm multi-hub wheel pair - **Pololu #2676** 25D gearmotor bracket pair - passive caster - rigid rover baseplate - secure battery mount - removable payload mount - adjustable mechanical-resistance fixture With 80 mm wheels and approximately 100 RPM no-load motor speed, the theoretical no-load rover speed is approximately 0.42 m/s. Our initial maximum commanded speed of 0.20 m/s intentionally leaves substantial margin below this value. The motors have a manufacturer-listed extrapolated stall current of approximately 1.8 A. Stall operation will not be treated as a normal operating point. Continuous motor-current limits will be determined experimentally using thermal testing before final disturbance magnitudes are selected. The removable payload will be mechanically secured to the chassis. Payload location will remain fixed between comparable trials because payload placement affects both total mass and rotational inertia. The asymmetric-resistance fixture will apply repeatable additional mechanical load to one drive side without requiring any change to software or controller parameters. ## Subsystem 3: Proprioceptive Sensing The adaptation algorithm will only use signals that exist on the physical rover. The available observations will include: - left wheel velocity, - right wheel velocity, - three-axis acceleration, - three-axis angular velocity, - left motor current, - right motor current, - battery voltage, - previous applied left motor command, - previous applied right motor command, - commanded forward velocity, - commanded yaw rate, - and command-limiting indicators. The two motor encoders require a supply above 3.3 V and will therefore operate from the 5 V rail. Their four quadrature signals will pass through an **SN74LVC14A** operated at 3.3 V before reaching STM32 timer inputs. The **ICM-42688-P** will operate from the 3.3 V supply and communicate with the STM32 using SPI. The IMU provides acceleration and angular rate; it will not be treated as an absolute-heading sensor. Motor currents will be measured using the **INA240A1** amplifiers and 33 mΩ shunts. Current acquisition will be synchronized with PWM to reduce switching-related measurement error. Battery voltage will be measured through an appropriately scaled resistor-divider circuit connected to an STM32 ADC input. The STM32 will transmit both the requested and the **actually applied** motor command so that the adaptation algorithm accounts for any saturation or safety limiting applied by the motor-control board. ## Subsystem 4: Power and Safety The rover will use a **Bioenno BLF-1203AB 12 V-class 3 Ah LiFePO4 battery pack** with its matched **Bioenno BPC-1502DC external charger**. The battery includes an internal protection system and has a manufacturer-listed maximum continuous discharge capability of 7 A. The power architecture will be: Battery → fuse and main switch → protected battery bus The protected battery bus will then supply: 1. the two DRV8874 motor-driver channels, and 2. the 5 V compute/electronics regulator. A **Pololu D24V50F5 (#2851)** regulator will generate the 5 V rail for the Raspberry Pi and supporting electronics. A **TLV75533P** regulator will generate the 3.3 V rail used by the STM32, IMU, current-sense circuitry, and encoder interface. Because a fully charged LiFePO4 pack exceeds the motors' nominal 12 V rating, the STM32 will implement a voltage-aware duty limit so that the approximate average commanded motor voltage does not exceed 12 V. This will operate in addition to current limiting and does not replace current protection. The design will include: - main fuse, - reverse-polarity protection, - adequate bulk and local decoupling, - voltage-rated capacitors, - driver current regulation, - sustained-current monitoring, - stall timeout, - command saturation, - communication watchdog, - MCU watchdog, - driver-fault monitoring, - and a latching emergency-stop circuit that disables both motor drivers independently of Raspberry Pi software. The Raspberry Pi supply will be load-tested during simultaneous processor load and motor startup/reversal to verify that motor transients do not cause compute resets. ## Subsystem 5: Onboard Compute and Learned Controller A **Raspberry Pi 4 Model B with at least 2 GB RAM** will run the learned adaptation and control networks. The policy will update at an initial target rate of 50 Hz. The deployment system will contain two learned components: ### History Encoder The history encoder will initially receive approximately the previous 30 controller samples, or 0.6 seconds of history. Its inputs will contain recent onboard measurements, previous applied motor commands, and requested motion. The encoder will output a compact latent vector representing information about the rover's current dynamics that is useful for control. ### Control Policy The control policy will receive: - the current observation, - commanded forward velocity, - commanded yaw rate, - and the inferred dynamics latent. It will output normalized left and right motor-duty requests. The networks will initially use compact multilayer neural-network architectures. Inference will be benchmarked directly on the Raspberry Pi with a target execution time below 10 ms per 20 ms policy interval. Network weights will remain frozen during the physical evaluation. The system therefore adapts through its sensor history and inferred latent rather than through online weight updates or manually selected controller modes. ## Subsystem 6: Simulation and Training Training will be performed offboard using **Isaac Lab** on a GPU workstation. The simulation will model the physical command-to-motion dynamics of the rover rather than using ideal wheel-velocity actuators. The simulation will include: - rover rigid-body mass and rotational inertia, - wheel geometry, - ground interaction, - brushed DC motor behavior, - gear reduction and effective transmission loss, - driver saturation and current limiting, - battery-voltage variation, - encoder quantization, - IMU bias/noise, - observation filtering, - and command/communication delay. Before training, we will characterize the physical rover by measuring quantities such as: - speed versus motor duty, - motor current response, - acceleration, - coast-down response, - and communication delay. These measurements will be used to construct the nominal simulation and determine realistic randomization ranges. Training will randomize: - rover mass and inertia, - independent left/right motor effectiveness, - rolling/drivetrain resistance, - battery voltage/effective supply loss, - sensor errors, - and communication/observation delay. The first training stage will use privileged simulation parameters to produce a dynamics latent. The control policy will be trained to use this latent. A deployment-side history encoder will then be trained to reproduce a useful dynamics latent using only the onboard observations and recent actions that will exist on the real rover. The initial history length will be 30 samples at 50 Hz, and the initial latent dimension will be eight. The deployed controller will receive no payload mass, disturbance label, motor-strength parameter, resistance value, or external position measurement. ## Subsystem 7: Baseline Controllers and Experimental Evaluation We will compare three controllers: 1. **Conventional baseline:** fixed-gain wheel PI control with feedforward and anti-windup. 2. **Fixed-latent learned policy:** the same learned policy used for adaptation, but with its dynamics latent held at a nominal constant value. 3. **Adaptive learned policy:** the learned policy supplied with the latent produced by the onboard history encoder. The conventional PI controller will be tuned normally on validation trials and then frozen. It will not be deliberately detuned to make the learned controller appear better. All controllers will use: - the same physical rover, - the same sensing calibration, - the same safety limits, - and the same command trajectories. Primary experiments will include: - forward-speed steps, - acceleration/deceleration sequences, - constant-speed motion, - yaw-rate steps, - curved trajectories, - and combined forward/turning motion. Dynamic tests are important because added mass may have little effect on steady-state velocity after feedback has converged. The two primary physical disturbances will be: 1. removable payload, initially 0.25 kg and 0.50 kg, subject to motor-current and thermal limits; 2. repeatable asymmetric mechanical resistance on one drive side. We will additionally reserve a combination of payload and asymmetric resistance as a held-out test condition. An independent overhead camera observing a marker on the rover will provide reference position and heading during evaluation. The camera will only be used for measurement and will **not** provide observations to the deployed controller. The primary quantitative metric will be externally measured forward-velocity RMSE. Secondary metrics will include: - yaw-rate RMSE, - relative heading error, - peak transient error, - recovery time, - RMS motor current, - time spent in actuator saturation, - policy execution time, - and missed control deadlines. Each controller-condition combination will be repeated multiple times, with a target of at least ten trials per condition. Battery voltage and motor temperature will be recorded, and test order will be randomized or counterbalanced. # Criterion For Success The following criteria are designed to be objective and directly testable. 1. **Custom PCB functionality** The custom PCB must simultaneously: - control both DC motors, - read both quadrature encoders, - acquire ICM-42688-P IMU measurements, - acquire independent left/right motor-current measurements, - measure battery voltage, - enforce motor-current and command limits, - and transmit timestamped telemetry to the Raspberry Pi. 2. **Real-time embedded control** The STM32 must reliably execute motor PWM, sensor acquisition, wheel-speed estimation, communication, and safety functions simultaneously during rover operation. 3. **Onboard learned-controller execution** The Raspberry Pi must sustain the learned policy/history-encoder loop at **50 Hz for at least 10 minutes** without missed control deadlines. 4. **Conventional rover control** The rover must demonstrate stable forward-speed and turning control throughout the experimentally validated operating envelope using the conventional PI controller. 5. **Repeatable physical disturbances** Added payload and asymmetric drivetrain resistance must produce repeatable and quantitatively measurable changes in the rover's physical response. 6. **Demonstration of history-based adaptation** The deployed adaptive controller must operate without receiving payload mass, disturbance identity, drivetrain-resistance value, motor-strength parameters, or external tracking information. The same frozen policy and history encoder must be used across all physical disturbance tests without manually changing gains, thresholds, or disturbance-specific control logic. 7. **Adaptation benefit** Our target is for the adaptive learned controller to reduce the primary forward-velocity RMSE by at least **25% relative to the fixed-latent version of the same learned policy** under each primary disturbance. We will additionally target at least a **10% reduction in forward-velocity RMSE relative to the tuned PI baseline without more than a 10% degradation in yaw-rate RMSE**. 8. **Held-out combination test** The frozen controller must be evaluated on a predefined combination of payload and asymmetric resistance that was excluded from controller tuning and from the set of predefined physical test cases. No disturbance label or test-case identifier may be supplied to the controller. 9. **Recovery measurement** For an in-motion resistance change, recovery time will be measured from disturbance onset until: - forward-speed error remains within 0.02 m/s, and - yaw-rate error remains within 0.10 rad/s for at least 0.5 seconds. These thresholds will be verified against sensor noise and frozen before final testing. 10. **Communication and safety** If no valid command is received from the Raspberry Pi for 100 ms, the STM32 must disable both motor drivers within the timeout plus one firmware service interval. The hardware emergency-stop circuit must also disable both motor drivers independently of Raspberry Pi software. 11. **Quantitative final demonstration** The final demonstration must show the same physical rover performing comparable trajectories with: - the conventional PI controller, - the learned controller without adaptation, - and the learned controller with history-based adaptation. We will present commanded versus measured motion, motor commands, motor currents, tracking error, recovery behavior, saturation information, and controller timing so that the effect of learned adaptation can be evaluated quantitatively rather than visually or through inspection of software. |
||||||
| 40 | Variable Speed Running Music Device |
Alan Wan Nithin Boopalan Weston Heard |
Jianchong Chen | Cunjiang Yu | design_document1.pdf proposal1.pdf |
|
| # Variable Speed Running Music Device Team Members: Alan Wan (alanwan2), Weston Heard (wheard2), Nithin Boopalan (nithinb2) # Problem Most people bring their phone on a run to listen to music. It is big and bulky, and unless you have a perfect playlist, there isn’t going to be music that syncs with your running. If you do happen to have music that is the same as your pace, there is nothing to enforce that you are running at that speed. # Solution We intend to fix this by replacing your phone on runs with a device that can react to how fast or slow you are going compared to your intended pace, and a mode where the music will automatically adjust to the speed you are going, in case you don't want to have to worry about keeping on pace. The device clips to your waistband and stores your music on an SD card so it doesn't move around in pockets. A motion sensor in the device picks up each step, and the device can calculate the steps per minute. It can then play a song that lines up with one’s steps, speeding it up or slowing it down slightly to keep it locked on. If the pace changes too much, it then switches to a different track instead. Everything will run on the device, so no phone or internet is needed. ## Subsystem 1, Motion Sensing This subsystem determines the runner’s running cadence. Running cadence usually falls between 140 and 190 steps per minute, which puts foot strikes at 2.3 to 3.2 Hz. An IMU is clipped at the hip in the device and samples acceleration at 200 Hz. The firmware in the STM32 then filters the signal to that range, removing the constant gravitational pull, and projects that reading as the direction of gravity. Cadence is then found by autocorrelation, where the firmware compares four seconds of a signal against shifted copies of itself. Then the computed shift that best matches is used as the time it takes one stride to repeat, ie stm. This is more reliable than individual foot strikes as it uses the whole window together, so one missed step or short peak barely moves the result. The search first covers the Hz for the running range, then widens to cover walking if nothing is found. This prevents a reading of 180 spm from being labeled as walking. However, since this shift is a whole number of samples, the raw result can only land on certain values, around 2.7 spm apart at 180 spm. The STM32 then interpolates between neighboring values to get the accuracy to be within 0.3 spm. Components: 6-axis IMU, SPI interface: TDK InvenSense ICM-42688-P Microcontroller Unit: STM32F4 family ## Subsystem 2, Music Storage and Playback This subsystem stores the songs and adjusts the speed to match the runner. Songs are stored on a microSD card as uncompressed WAV files, preventing the processor from decoding MP3. Audio is read off the card using DMA, a block within the microcontroller that can move data without the processor copying, so that reading doesn’t interrupt playback. Each song’s tempo is worked out ahead of time on a computer before being saved in an index file on the SD card. The device then only has to do a lookup while running instead of processing audio for the BPM. Tempo Matching: Tempo can be changed with WSOLA (waveform similarity overlap-add) by up to 10%. It cuts the audio into overlapping chunks and places them back closer or farther apart to change the speed. This allows for a speed change while preserving pitch. However, the further out the pace is, the worse it will start to sound, and the device will then be forced to change songs. Target Tempo: plays songs at a targeted pace, and when the runner falls behind the set pace, a low-pass filter is placed to muffle the audio to signal falling behind and clears out as they return to pace. This provides the runner feedback without having to stop running Components: microSD card socket: Hirose DM3AT-SF-PEJM5 microSD card: 32 GB SanDisk High Endurance or Samsung PRO Endurance ## Subsystem 3, Audio Output This subsystem turns the digital audio into a signal that can drive headphones. The main analog circuit design in the project. Audio samples will travel from the microcontroller over I2S, a three-wire bus for audio, to a DAC, which converts each sample into voltage. This voltage is held until the next sample arrives, so the output appears as a staircase. They then pass through a reconstruction filter to remove the distortion before it reaches a headphone amplifier, which supplies the current that 16 to 32 ohm headphones need. This amplifier gain is capped so the output never exceeds 150 mV RMS into 32 ohm headphones. Components: Stereo audio DAC: Texas Instruments PCM5102A Low-noise audio op-amp for reconstruction filter: Texas Instruments OPA1662 Headphone amplifier, no capacitor output: Texas Instruments TPA6132A2 3.5mm TRS headphone jack: CUI SJ-3524-SMT-TR ## Subsystem 4, Power This subsystem powers the device from a single lithium cell and handles charging. The lithium cell will fall from 4.2 V to 3.0 B as it drains, and in the process will cross a 3.3 V logic rail; a buck-boost converter can then be used so the rail remains stable as the discharge finishes. The DAC and headphone amp are fed through dropout regulators that keep the noise from the converter out of the audio. An MCP73831 charges the cell over USB-C, and a MAX17048 fuel gauge will report the charge to the microcontroller. Components: Single-cell lithium-polymer battery, 1000 mAh Low-dropout regulator Buck-boost regulator: Texas Instruments TPS63020 Battery Charger: MCP73831 Battery fuel gauge: Maxim MAX17048 # Criterion For Success Cadence is measured within 1 spm of the true value for the range 140-190 spm. The true value can be obtained with a fixed motor setup and verified through video. Once the device is locked onto a speed, play music to within 1 BPM of the runner’s steps per minute. Verify by checking the audio output and comparing the speed to video of the runner. After the pace changes by 15 spm or more, change music to match th e new pace within 10 seconds. Test both speeding up and slowing down by 15 spm or more. Recognizes stops and starts within 10 seconds of them happening. The device lasts at least 2 hours of continuous usage. The device remains lightweight, under 300g, and stays clipped to the waistband over a 15-minute run. |
||||||
| 41 | A smart cup holder for tracking and reminding you of your water intake. |
Lawrence Cheng Shengyuan Wang |
Zhuoer Zhang | Cunjiang Yu | design_document1.docx design_document2.pdf other2.docx proposal1.docx |
|
| Problem Many people do not drink enough water throughout the day because they forget to drink regularly or have difficulty tracking how much water they have consumed. Although smart water bottles are available, they require users to replace their existing cups or bottles and can be relatively expensive. Phone-based reminder applications can notify users at fixed intervals, but they generally cannot determine whether the user actually drank water or how much water was consumed. This motivates the development of a portable hydration-tracking device that can work with a user’s existing cup. The device should automatically estimate water consumption, provide reminders when the user has not consumed enough water, and minimize false records caused by simply lifting, carrying, or shaking the cup. Solution We propose an adjustable smart cup base that attaches to the bottom of an existing cup and remains attached while the cup is moved. Unlike a separate weighing coaster, the device travels together with the cup and can be used on any suitable horizontal surface. The cup rests on an internal weighing platform connected to a load cell. An ESP32 continuously samples the load-cell output through an HX711 converter. Measurements taken while the cup is lifted, carried, or shaken are unstable or unloaded and are therefore ignored. After the cup is returned to a horizontal surface, the system compares the new stable weight with the previous accepted weight. A stable decrease greater than a predefined threshold is recorded as estimated water consumption. An increase is classified as a refill, while small changes are ignored as measurement noise. Because water has a density of approximately 1 g/mL, a decrease of 20 grams can be estimated as 20 mL of water consumed. A display on the base shows the daily hydration goal and estimated intake. The user can select sound, vibration, or silent visual reminders. An optional Bluetooth application can display drinking history and allow the user to configure the daily goal and reminder interval. Solution Components Weight Measurement and Mechanical Subsystem The base will be printed by 3D printing materials to be secure at the bottom of the cup. The cup rests on an upper weighing platform, while the lower enclosure contacts the supporting surface. A load cell placed between these two structures measures the combined weight of the cup and its contents. The mechanical design must ensure that the cup’s vertical load passes through the load cell. 2 kg single-point load cell HX711 load-cell amplifier and ADC Internal Weighing Platform Protective base enclosure Processing and Intake-Detection Subsystem The ESP32-S3 continuously receives weight samples from the HX711. A recent measurement is used to determine whether the cup is present and the reading is stable. A new weight is accepted only when its variation remains below a defined limit for approximately one second. The firmware then compares it with the previous stable measurement. Small weight change: ignored as noise Stable weight decrease: recorded as estimated consumption Stable weight increase: classified as a refill Unstable or unloaded reading: ignored Abnormally large change: classified as cup removal or measurement error This logic prevents lifting and shaking from being recorded because the measurements during these actions are unstable, and lifting without drinking produces approximately the same weight after the cup is returned. MCU: ESP32 Load-cell interface: HX711 Stability-detection and weight-comparison algorithm Bluetooth Low Energy for optional application communication User Interface and Reminder Subsystem A small display mounted on the side of the base shows the user’s daily hydration goal, estimated consumption, and remaining amount. The ESP32 tracks the time since the most recent confirmed weight-loss event and the user’s progress toward the daily goal. If the user has not consumed water for a configured period or falls behind the expected progress, the system activates the selected reminder mode. LED display Buzzer Vibration motor and driver Status LED Control buttons or reminder-mode switch Power Subsystem The device is powered by a rechargeable battery. A USB-C charging circuit charges the battery, while a regulated 3.3 V supply powers the ESP32, HX711, and display. Rechargeable battery USB-C charging circuit 3.3 V voltage regulator Power switch Decoupling capacitors Vibration-motor driver Success requires: Detecting water reductions between 20 and 300 mL with an error no greater than ±10 mL or ±10%. Correctly rejecting at least 90% of lift-and-return trials in which no water is removed. Correctly rejecting at least 90% of shaking and moving trials. Recognizing added water as a refill instead of consumption. Updating the daily total and remaining goal on the display. Operating for at least one normal day before recharging. Because the device uses only weight measurements, it cannot distinguish drinking from intentionally pouring water out. Therefore, the system records a confirmed reduction in water as estimated consumption. |
||||||
| 42 | Position-Sound Accurate Electric Snare Drum |
Kadin Shaheen Oscar Li Tim Dager |
Aniket Chatterjee | Cunjiang Yu | design_document1.pdf proposal1.pdf |
|
| Team Members: Tim Dager (timcd2) Kadin Shaheen (kadinas2) Oscar Li (hongyil9) Problem Modern electronic snare drums are unable to replicate the detail of sound that changes continuously based on how and where you strike an acoustic drum. They generally relegate hits to one of three zones: head, center, or rim, with some degree of velocity sensitivity. The issue with determining strike zones through dedicated zone sensors is a limited resolution sound profile. Our goal is to develop a digital snare that utilizes time difference of arrival (TDOA) with piezoelectric sensors to pinpoint drum strikes to a centimeter level of precision to realistically emulate the sound profile of an acoustic drum. Further positional detection improvements and low-latency benchmarks will be treated as stretch goals. Solution We will utilize three piezoelectric sensors with analog processing components feeding to an STM32 microcontroller to measure and calculate strike position. The piezos will be placed equidistantly from the center of the drum mesh and will detect the first arrival of a wave to triangulate the strike position. Signal processing will account for reflected waves from the rim of the snare drum as well as attenuation across the mesh. The STM32 microcontroller will be used for its DAC module, digital signal processing, and communication through USB as a MIDI device. The drum pad will divide into four subsystems including the piezo sensor array, analog pcb, MCU, and power subsystem. Solution Components Subsystem 1: Piezo Sensor Array A set of concentrically spaced, commonly available piezo vibration sensors will be mounted to an inexpensive single zone mesh drum. A minimum of three sensors are needed to perform the time difference of arrival (TDOA) algorithm, but more may be added (while maintaining concentricity) to allow for cross referencing if necessary. The placement of these sensors will mimic implementations of TDOA systems in similar applications. Subsystem 2: Analog PCB An analog preprocessing board will take inputs from each of the piezo sensors, and convert them into usable analog inputs in the range of the microcontroller. It will consist of an op-amp as an impedance buffer for each piezo, a voltage translator to align our analog signal with the specification of the microcontroller (0 - 3.3v for STM 32), and a clamping circuit to protect from voltage spikes. Subsystem 3: MCU (computation + data output) An STM32 with a 12 bit ADC will be used to accept the three analog signals, perform the TDOA algorithm to compute a positional estimate, and generate the appropriate usb signals as MIDI, that the user may use for triggering drums, or other purposes. Subsystem 4: Power The power subsystem will take input from a USB source and output correct voltage levels to the Analog PCB Subsystem and to the MCU. The device will be powered from a 5V USB input with USB-C preferred. A 3.3V onboard regulator will generate the primary logic and analog supply rail for the STM32 microcontroller and other 3.3 V compatible components. The subsystem will include input protection, local decoupling/bulk capacitors to maintain a stable 3.3V rail. If later component selection requires an additional power supply voltage for the analog subsystem, or other circuitry, an additional regulated rail may be added. Criterion For Success The drum must be capable of distinguishing between a minimum of 10 distinct radial zones, each of which may be mapped to different midi notes to confirm zone accuracy Drum pad USB device endpoint is recognized as a MIDI interface Net latency measured from impact time to USB handshake should be minimal enough to avoid causing an audio-tactile mismatch (delay between strike and sound) sensed by the player- roughly 40ms. |
||||||
| 43 | Secure Stride Walker Assistant |
Harrison Wong Janine Zhu Nick Schroeder |
Aniket Chatterjee | Cunjiang Yu | design_document1.pdf proposal1.pdf |
|
| # Secure Stride Walker Assistant Team Members: - Nick Schroeder (ns58) - Harrison Wong (hjwong3) - Janine Zhu (janinez2) # Problem Older adults discharged after lower-extremity surgery or hip fracture frequently transition from supervised rehabilitation to independent home recovery with limited reinforcement of safe walker use. Customer discovery interviews with physical and occupational therapists identified multiple contributors to falls during this period, including poor walker positioning, walker abandonment, unsafe turning, excessive gait speed, low-light ambulation, and unsafe sit-to-stand transfers. # Solution Stride Secure is a lightweight, reusable clip-on device that transforms a standard walker into an intelligent rehabilitation support system. Using motion sensing and proximity sensing, the device provides configurable visual and auditory cues to encourage proper walker positioning, remind patients to use their walker, promote safer walking speed, improve nighttime visibility, and reinforce safe mobility behaviors during the first 2–6 weeks following discharge. This device consists of 6 subsystems. The first subsystem is the sensing subsystem that is designed to monitor the motions of the user and the surrounding environment. The second subsystem is a feedback subsystem that alerts the user to walk at a slower pace, to use their walker, etc. The third subsystem is the mechanical mounting mechanism that mounts to a variety of walkers, but also serves as the housing for the sensors, feedback devices, and microcontroller. The fourth subsystem is the processing/control subsystem that intakes sensor data and processes it to send instructions to the feedback subsystem. The fifth subsystem is the power subsystem that powers all the electronics and maximizes battery life for a full day of operation. The sixth subsystem is the interface for users to input volume and brightness settings as well as initialize/define basic mobility states for safe and unsafe use patterns. # Solution Components ## Subsystem 1: Sensing Subsystem This system must be able to detect the walker’s motion and orientation and the user’s proximity to the walker. An IMU (MPU6050) would be used to detect falls or excessive leaning of the walker. Integrating the collected acceleration data from the IMU can be used to determine walker speed. This system will have an ultrasonic sensor (HC-SR04) to determine the user’s location relative to the walker, allowing it to detect if the user drifts too far in or out of the walker. We’re also considering a lidar camera either to replace the sensor or in tandem with it to provide a broader set of data. The determination of whether to or not to use lidar is in consideration pending further analysis by the team. ## Subsystem 2: Feedback Subsystem This subsystem provides the user with reminders based on information and data processed from the sensor subsystem and instructions determined by the processing/control subsystem. The instructions and cues are sent audio cues through a microphone. Visual cues, such as reminders to use the walker at night, would be small flashing LEDs for users who are hard of hearing or Deaf. The LEDs would also be different colors for different warnings, which colors such as Red, Yellow, and Blue for users who may be red-green colorblind. Brighter LEDs will be used to improve nighttime visibility. ## Subsystem 3: Mounting Mechanism This subsystem is the mounting mechanism for the device as well as the housing for all electronics parts such as sensors, microphones, and the microcontroller. The mounting mechanism should be adjustable for a variety of walker models. The housing can be made out of wood or 3d printed for this project and will need to account for sensor placement and feedback system optimization. ## Subsystem 4: Processing/Control Subsystem This subsystem processes sensor data to make real-time cues for the user. The subsystem will have a microcontroller (STM32U0) to intake data collected by the sensors and provide real-time instructions to the feedback system. It can use its flash memory to store data as needed, and as the most power efficient current model in STM’s lineup, it will support the need for efficient power consumption. The cues and instructions will be issued depending on predetermined/inputted mobility states to delineate what are safe and unsafe use patterns. The inputs from the interface subsystems, such as volume and brightness controls, will be processed to be reflected in the feedback subsystem as well. ## Subsystem 5: Power Subsystem This subsystem powers the device and all the electronic components. This subsystem will consist of a rechargeable battery and battery status display at its core. We will design it to be charged by USB, thus allowing us to use standard AC-DC wall power blocks and avoiding the need for an onboard rectifier. The system as whole will be designed to minimize power consumption in order to prolong battery life throughout the day. This will be achieved by selecting components specifically for power efficiency, regulating voltage to convert to the most efficient operating voltage of those devices, and allowing the system to entirely cut off conduction to elements which aren’t in use. The cutoffs will be determined by software and achieved by switching power MOSFETs (IRFI1310N) on or off. The voltage regulation can be achieved using either a switching regulator (TPS62A01DRLR) or an LDO (MIC5156YM) depending on how noise sensitive the device being powered is. ## Subsystem 6: Interface Subsystem This subsystem is for users to input volume and brightness settings as well as initialize/define basic mobility states for safe and unsafe use patterns. User inputs can be displayed on a LCD screen with a large font for users who are near sighted. Any user inputs for instruction volume or alert intensity can be adjusted with larger buttons for mobility accessibility. # Criterion For Success The device is successful if it can detect misuse of walkers by a user and provide instructions to prevent falls. The device also needs to be adaptable for a variety of walker models and configurable for different user needs. The one caveat we’re putting on it is that, with the nature of the project, we’re planning to produce a comparatively basic proof of concept prototype with functional sensing, power, and processing systems. The rest will either be an extension in the event of progress moving more quickly or considered for updates after we finish ECE 445. |
||||||
| 45 | PulseGuard: Hardware Encoder Integrity Monitor |
Chinmay Naveen Sanjiv Kondin |
Alex Lee | Cunjiang Yu | design_document1.pdf proposal1.pdf |
|
| * Sanjiv Kondin (skond32) * Chinmay Naveen (cnaveen2) *third student Problem Wheel encoders are commonly used by robots to measure how fast their wheels are turning and how far the robot has moved. If an encoder signal becomes corrupted, such as from missing pulses, extra pulses, or a disconnected signal, the robot may continue using incorrect measurements without knowing there is a problem. We propose PulseGuard, a system that checks whether the encoder measurements are reliable by comparing them with an independent measurement from an IMU. The system will intentionally create encoder faults during testing and determine whether PulseGuard can detect the difference between the encoder and IMU measurements. Solution We will design and build a system that connects two wheel encoders, an IMU, and a microcontroller. The microcontroller will read the encoder signals and calculate the robot's turning speed. It will then compare this value with the turning speed measured by the IMU. If the difference between the two measurements becomes larger than a selected threshold for a certain amount of time, the system will report that the encoder may have a fault. The system will also include a simple fault-injection circuit that allows us to create different encoder problems during testing. This will allow us to test whether PulseGuard can detect real encoder faults in a controlled and repeatable way. The design breaks down into four subsystems: encoder interface, fault injection, IMU sensing, and firmware. Solution Components Encoder Interface The system will connect two wheel encoders to the microcontroller. The encoders will provide signals that show how fast each wheel is turning. The encoder signals will be cleaned up using a Schmitt-trigger circuit before being sent to the microcontroller. This will help make sure the microcontroller receives clear digital signals. Both encoder channels will be used so that the system can determine wheel movement and direction. Part numbers (subject to change): 74HC14 Schmitt-trigger inverter Resistors Capacitors Encoder connectors Fault Injection The system will include a simple circuit that allows us to intentionally change one encoder signal during testing. Three types of faults will be tested: Missing pulses Extra pulses Interrupted signal A switch will be used to choose between the normal encoder signal and the modified signal. The microcontroller will control when the fault is added so that the exact time of the fault can be recorded. Part numbers (subject to change): 74HC4053 analog switch 74HC14 Schmitt-trigger inverter Resistors Capacitors IMU and Fault Detection A BNO085 IMU will be used to measure the robot's turning speed using its gyroscope. The microcontroller will calculate the turning speed using the two encoder measurements and compare it with the turning speed measured by the IMU. If the two measurements are different by more than a selected amount, the system will consider the encoder measurement unreliable. A small delay will be used before reporting a fault so that normal sensor noise does not cause false alarms. Part numbers (subject to change): BNO085 IMU I2C connections Supporting capacitors Firmware and Data Logging The microcontroller will handle the encoder signals, IMU data, fault injection, and fault detection. During testing, the system will record: Encoder measurements IMU measurements Fault type Fault injection time Fault detection time Fault status The data will be sent to a computer through USB serial so that the results can be reviewed after testing. Criterion For Success High-level goals Detect at least 90% of the encoder faults that are intentionally created. Detect an encoder fault within 500 ms. Keep the false-positive rate below 5% during normal operation. Detect all three tested fault types: Missing encoder pulses Extra encoder pulses Interrupted encoder signal Correctly compare encoder and IMU measurements. Record the time when a fault is created and detected. Successfully send test data to a computer. Testing/Demo The system will first be tested without any faults to make sure the encoder and IMU measurements agree during normal operation. The encoder signals will then be tested using an oscilloscope to make sure the system is receiving clean signals. Each of the three fault types will be injected separately. At least 10 tests will be performed for each fault type. During testing, the system will record the encoder measurement, IMU measurement, fault type, and detection time. The system will also be tested during different types of motion, including: Straight-line motion Turning Stopping and starting The detection time will be calculated by comparing the time the fault was created with the time PulseGuard detected it. Normal operation without injected faults will also be tested to determine the false-positive rate. For the final demonstration, the robot will operate normally while PulseGuard monitors the encoder measurements. A controlled encoder fault will then be introduced. PulseGuard should detect the disagreement between the encoder and IMU and report an encoder fault. The final results will demonstrate the system's ability to detect encoder faults, measure detection time, and avoid reporting faults during normal operation. |
||||||
| 46 | Reaction Time Measurement and Training Device |
Michael Griegel Sahil Aggarwal |
Zhuoer Zhang | Cunjiang Yu | design_document1.pdf proposal2.pdf |
|
| # Reaction Time Measurement and Training Device Team Members: - Sahil Aggarwal (sahil6) - Michael Griegel (griegel2) - Looking for one more team member # Problem Reaction time is important in applications including athletic training, driving, gaming, and rehabilitation. Professional reaction-time measurement systems can provide accurate measurements but are often expensive and inaccessible to regular users. Phone-based reaction tests are inexpensive but introduce uncertainty from touchscreen sensing, display latency, and software processing. We want to develop a standalone hardware device that can measure and characterize human reaction time using physical buttons and LEDs. The project will focus on understanding the timing behavior of the complete hardware system rather than simply implementing a reaction-time game. # Solution We will build a benchtop device containing a 3x3 grid of illuminated mechanical buttons. During a test, the device will activate a target LED after a randomized delay. The user will respond by pressing the corresponding button. A hardware timer in the microcontroller will measure the interval between the stimulus and response. We will design and fabricate a custom two-layer PCB containing the microcontroller, button input circuitry, LED driver circuitry, buzzer driver, power regulation, and interfaces for a small display. The system will also expose electrical test points that allow the stimulus and button signals to be measured using an oscilloscope or logic analyzer. This will allow us to characterize the difference between the ideal timer measurement and the actual physical response of the hardware. # Solution Components ## Timing and Control Subsystem The microcontroller will coordinate stimulus generation, button sampling, timing, game logic, and display updates. The hardware timer will be used to measure reaction time without depending on the execution time of the main software loop. Components: - STM32G431CBU6 microcontroller ## Stimulus Subsystem Nine LEDs will be integrated with the nine-button grid. LED driver circuitry will allow the microcontroller to activate individual target LEDs. The electrical stimulus signal will also be routed to a test point so that LED activation timing can be measured with laboratory equipment. Components: - 9x LEDs - LED current-limiting resistors - N-channel MOSFET drivers as required ## Response Subsystem Nine mechanical pushbuttons will allow the user to respond to the stimulus. The button interface will be designed to reduce the effects of mechanical button bounce. Button response timing and mechanical bounce will be characterized experimentally. Components: - 9x mechanical pushbuttons - Input pull-up/pull-down circuitry - RC filtering and/or firmware debouncing circuitry ## Audio Subsystem A piezoelectric buzzer will provide an alternative auditory stimulus for reaction-time experiments. Components: - Piezoelectric buzzer - N-channel MOSFET driver - Associated resistors ## Display Subsystem A small display will show reaction times, scores, and test status. Components: - SSD1306-based OLED display ## Wireless Data Logging Subsystem An ESP32 module will add Bluetooth connectivity so that reaction-time results can be logged to an external database. After each test, the STM32 microcontroller will send the result to the ESP32 over a serial interface (UART/SPI), and the ESP32 will transmit the record over Bluetooth to a paired host (phone or computer) that maintains the database. Because the STM32 performs all timing-critical measurement locally and the ESP32 only handles the non-time-critical data transfer, Bluetooth latency does not affect the measured reaction times. Storing results externally allows scores to be compared across sessions and users and used to build leaderboards. This data can be moved to an app or webapp to make it user-friendly. Each record follows a simple format: | Name | Score | | ----- | ----- | | Sahil | 245 | Components: - ESP32 development board (ESP32-DevKitC-32E, based on the ESP32-WROOM-32E module) - Serial (UART/SPI) interface lines between the STM32 microcontroller and the ESP32 ## Power Subsystem The PCB will regulate the input supply to the voltage levels required by the microcontroller, LEDs, display, and buzzer. Components: - Regulated power input - 3.3 V voltage regulator - Decoupling capacitors - Power protection components as required # Criterion For Success - The device successfully activates each corresponding LED and detects presses from all nine buttons. - The system measures reaction-time intervals with a timer resolution of 1 ms or better. - The difference between the measured timing interval and a known reference timing signal is experimentally characterized using an oscilloscope or logic analyzer. - The device can distinguish valid button presses from mechanical button bounce without producing false reaction measurements. - At least 95% of valid test trials produce a reaction-time measurement without missed stimulus or response events. - The device successfully supports both visual and auditory reaction tests. - The device successfully transmits reaction-time results (user name and score) over Bluetooth to an external database, with at least 95% of records received without loss or corruption. - The custom PCB successfully powers and operates all major subsystems without exceeding component voltage or current limits. |
||||||
| 47 | MaterialID: Identifier for Unmarked Materials |
Sachith Chandran Shritan Bhupathiraju Siddharth Gupta |
Aniket Chatterjee | Arne Fliflet | design_document1.pdf proposal1.pdf |
|
| Team Members: - Shritan Bhupathiraju (shritan2) - Sachith Chandran (src14) - Siddharth Gupta (sg96) # Problem Machine shops, makerspaces, and teaching labs keep bins of offcuts and scrap stock whose markings were cut away long ago. Many of these materials look alike: 6061 and 7075 aluminum, brass and bronze, stainless and mild steel, and several clear or white plastics. Getting them confused causes real problems. For example, 7075 is generally considered unsuitable for fusion welding while 6061 welds routinely, and alloys machine and finish differently. A wrong guess can mean scrapped parts, wasted machine time, or a structural failure. Existing tools each cover only part of the problem: - A magnet only separates ferrous from non-ferrous metals. - Spark testing works only on steels and takes a trained eye. - Handheld X-ray fluorescence analyzers cost tens of thousands of dollars. - Eddy current conductivity meters handle metals only, and operators must look up readings in tables by hand. - Low-cost near-infrared plastic scanners identify plastics only. No affordable tool identifies both metals and common non-metals by measuring their physical properties. As a result, unidentified stock often gets thrown away instead of reused. # Solution MaterialID is a bench instrument with a flat sensing platform and a single button. The user places an unknown sample on the platform (at least 3 mm thick, with a flat face at least 50 × 50 mm) and presses the button. The instrument measures three properties of the material itself, independent of the sample's size and shape: 1. **Electrical conductivity and magnetic response,** from a multi-frequency eddy current probe under the platform. It measures at 60 kHz, plus 250 kHz for low-conductivity metals such as stainless steel. 2. **Dielectric permittivity and loss tangent** for non-conductors, from a guarded fringing-field electrode under the platform. 3. **Mechanical damping,** from a controlled solenoid tap followed by a fit to the decay of the sample's ringing. Damping is used rather than ringing pitch because pitch depends mostly on the sample's shape. The eddy current and dielectric measurements share one digital lock-in amplifier on the microcontroller. It samples the excitation and the response at the same time, so the result doesn't depend on drift in the excitation amplitude or frequency. A physics-based decision tree compares the measurements against a reference table that we build from our own measurements of known samples. The instrument then displays the material, the measured values, and a confidence level. If nothing in the table matches closely enough, it reports "unknown." The system uses no machine learning and needs no training data. The target set is nine materials: 6061-T6 and 7075-T6 aluminum, C110 copper, C360 brass, 1018 steel, 304 stainless steel, soda-lime glass, acrylic (PMMA), and HDPE. The project has five subsystems: (1) excitation and lock-in engine, (2) eddy current probe and front end, (3) dielectric sensor and front end, (4) impulse excitation and ring-down, and (5) control, user interface, and power. # Solution Components ## Subsystem 1: Excitation and Lock-in Engine A DDS chip generates sine excitation at 60, 100, or 250 kHz, and a current buffer drives the selected sensor. The microcontroller samples the excitation and the sensor response simultaneously on two ADCs. It computes their in-phase and quadrature components over thousands of cycles to find the sensor's complex impedance change. - MCU: STMicroelectronics STM32G474RET6 (dual simultaneous 12-bit ADCs at 4 MS/s, CORDIC math accelerator) - Direct digital synthesizer: Analog Devices AD9833BRMZ - Excitation buffer: TI BUF634A - Sensor-select analog multiplexer: TI TMUX1108 ## Subsystem 2: Eddy Current Probe and Front End A ferrite-backed probe coil sits under a 0.5 mm PTFE cover. It is wired in a bridge with an identical reference coil that faces air, and an instrumentation amplifier amplifies the imbalance between them. Conductivity (%IACS) comes from a calibrated map of how the coil's impedance shifts. Ferromagnetic materials raise the coil's inductance while non-magnetic metals lower it, which flags them. A temperature sensor at the probe allows temperature compensation. We will verify the calibration samples' true conductivity with 4-wire resistance measurements on the lab's Keysight 34461A. - 2× ferrite pot cores (TDK B65541 series, P14×8) wound with 0.2 mm magnet wire - Instrumentation amplifier: TI INA828 - Temperature sensor: TI TMP117 (±0.1 °C) - 0.5 mm PTFE sheet as the platform cover ## Subsystem 3: Dielectric Sensor and Front End An interdigitated electrode is etched into the platform PCB, with a driven guard layer beneath it so the sensor ignores objects below the platform. A transimpedance amplifier converts the electrode current to a voltage for the lock-in engine at 100 kHz. We calibrate against air, PTFE, and a glass reference to get relative permittivity and loss tangent. This subsystem runs only when the eddy current probe finds no conductor. - Interdigitated electrode on PCB: 30 × 30 mm, 0.5 mm fingers and gaps, with rear driven guard - Transimpedance amplifier and guard driver: TI OPA2320 ## Subsystem 4: Impulse Excitation and Ring-down A solenoid under the platform taps the sample from below through a small hole, while the sample rests on four soft silicone pads. A MOSFET delivers a timed pulse from a regulated 12 V rail, and a current-sense amplifier confirms the tap energy is the same each time. A MEMS microphone records the ringing. Firmware finds the dominant frequency, extracts the decay envelope, and computes the loss factor, which separates metals and glass (low damping) from plastics (high damping). - 12 V push-pull solenoid: Adafruit 412 - Solenoid driver MOSFET: Infineon IRLML6344, with SS34 flyback Schottky diode - Solenoid current sense amplifier: TI INA180 - Analog MEMS microphone: TDK InvenSense ICS-40180 - Microphone preamp and anti-alias filter: TI OPA344 ## Subsystem 5: Control, User Interface, and Power The microcontroller runs the measurement sequence with the electrical measurements first and the solenoid tap last, so switching noise can't corrupt readings. It then runs the decision tree, shows the result on an OLED, and streams raw data over USB for calibration and logging. A 12 V adapter powers the solenoid directly, a buck converter makes 5 V, and separate 3.3 V regulators feed the digital circuits and the noise-sensitive analog circuits. - 12 V / 2 A certified external power adapter - 5 V buck converter: TI TPS562201 - 3.3 V digital regulator: Diodes Inc. AP2112K-3.3 - 3.3 V low-noise analog regulator: TI TPS7A2033 - 0.96" SSD1306 I2C OLED display, tactile button, USB-C connector (native USB on the STM32G474) # Criterion For Success - Measure the electrical conductivity of non-ferromagnetic metal samples (at least 3 mm thick, flat face at least 50 × 50 mm) within ±2 %IACS over the range 2–100 %IACS, compared against 4-wire resistivity measurements of the same stock. - For each target material, the primary property measured on three samples of different size and shape agrees within ±5% of their mean (within ±0.5 %IACS for metals below 10 %IACS). The primary property is conductivity for metals and permittivity for non-metals. - Correctly identify the material in at least 90% of 90 trials: 9 materials × 3 samples each (at least one sample per material not used to build the reference table) × 3 placements. Each result must appear within 5 s of the button press, with no user-entered sample information. - Repeat damping measurements within ±10% over 10 taps on the same sample, and separate the metal and glass group from the acrylic and HDPE group by a factor of at least 5 in loss factor. |
||||||
| 48 | Low-Cost Wearable Bilateral Teleoperation Platform with Grip-Force Feedback |
Godrein Owusu-Ayeyi Junghyun Kim Junseo Kim |
Junyan Bai | Viktor Gruev | other1.pdf proposal1.pdf |
|
| # Low-Cost Wearable Bilateral Teleoperation Platform with Grip-Force Feedback **Team Members:** - Junseo Kim (junseok3) - Godrein Owusu (gowus2) - Junghyun Kim (jk61) ## Problem Many tasks require a person to manipulate objects without being physically present in the operating environment. Hazardous material handling, remote equipment inspection, and disaster response are common examples. A conventional camera-and-joystick teleoperation system provides visual information but gives the operator little physical information about contact. The operator cannot feel when the gripper touches an object or how strongly it is being held, which makes delicate manipulation difficult: too little force lets an object slip, and too much force damages a fragile one. The appropriate force also depends on what is being held, since a grip that securely holds a rigid object will crush a thin-walled cup. Commercial bilateral teleoperation systems address these problems using multi-axis force/torque sensors and torque-controlled actuators, but such systems are expensive and mechanically complex. We plan to build a small, low-cost proof-of-concept platform that demonstrates the same core capabilities: wearable motion sensing, robotic motion reproduction, bidirectional communication, grip-force sensing, haptic feedback, and automatic grip-force protection. The goal is not a system for actual hazardous, medical, or military use, but a demonstration of the electrical and mechanical subsystems that human-in-the-loop teleoperation requires. ## Solution The system will consist of a wearable leader and a three-axis robotic follower with a gripper. The user will wear a lightweight passive mechanical frame carrying four position sensors: two for shoulder motion, one for elbow motion, and one for thumb and index finger motion. The two shoulder measurements will represent left-right and up-down arm movement and will control the follower's rotating base and shoulder joint. The elbow sensor will control the follower elbow, and the finger sensor will control the gripper. The leader microcontroller will acquire and filter these measurements, convert them into joint commands, and transmit them over a wired link to the follower microcontroller, which will generate the corresponding servo commands. Forward: user motion → leader sensors → leader MCU → wired link → follower MCU → servos → robot motion Reverse: object contact → FSR → follower MCU → wired link → leader MCU → vibration motor → operator This bidirectional sensing and feedback loop is the primary feature that makes the system a bilateral teleoperation platform. The follower will also use the force measurement for local protection. As the gripper closes, the controller will estimate how compliant the grasped object is and select a force limit appropriate to that object, so that a paper cup is protected with a lower threshold than a rigid block without the operator specifying what is being held. If that limit is reached, the controller will override the operator's closing command. The link will be wired rather than wireless. This avoids the added latency, packet loss, interference risk, and battery requirements of a wireless link, and lets the wearable device draw power through the same cable so the user carries no battery. ## Solution Components ### Wearable Leader and Position Sensing Subsystem A lightweight passive frame worn on the arm will carry rotary position sensors at its joints. Two sensors on perpendicular axes will measure the two major directions of shoulder movement, a third will measure elbow bending, and a fourth will measure thumb and index finger motion. The frame is not intended to reproduce exact anatomical joint angles. The human shoulder is a ball joint whose center of rotation lies inside the body, so some residual misalignment is unavoidable. Our requirement is instead that the mapping from user pose to sensor reading be repeatable and monotonic, with a startup calibration routine mapping each user's range of motion onto the follower's joint range. A clutch button will let the operator stop sending commands while repositioning their arm. *Proposed components:* - STM32F103C8T6 microcontroller - Four rotary potentiometers - Analog filtering and buffering - Clutch push button - 3D-printed frame with adjustable links and straps ### Follower Robotic Arm and Gripper Subsystem The follower will be a three-axis robotic arm with base rotation, shoulder rotation, elbow rotation, and a two-finger gripper, driven by four servo motors. Software joint limits, slew-rate limits, and mechanical stops will prevent unsafe or unstable movement. Because the follower has no actuated wrist, the gripper's orientation would otherwise change as the arm reaches farther or closer. A passive parallelogram linkage in the forearm will hold the gripper at a near-constant orientation across the working range, without requiring an additional servo. A position sensor on the gripper joint will measure actual finger position rather than relying on the commanded servo angle, since a loaded servo does not reach its command. *Proposed components:* - STM32F103C8T6 microcontroller - Four metal-gear servo motors - Gripper joint position sensor - 3D-printed arm links, gripper, and parallelogram linkage - Mechanical joint stops ### Grip-Force Sensing and Adaptive Force Limiting Subsystem An FSR beneath a compliant pad inside one gripper finger will detect contact and provide a relative measure of grip force. Because the FSR response is nonlinear, it will be characterized against known loads and used to identify relative force levels rather than absolute values. Once contact is detected, the gripper's closing rate will be reduced and the controller will record the gripper joint angle as the measured force crosses a low and then a high reference level. The difference between these angles gives a compliance index: ``` D = theta(F_high) - theta(F_low) ``` A rigid object requires little additional closure for force to rise between the two levels, producing a small D; a compliant object deforms further and produces a large D. Because both endpoints are fixed points on the FSR curve, D does not depend on absolute force calibration, and measuring the true gripper angle rather than the commanded servo angle removes the servo's own compliance from the result. Reference objects will be tested during calibration to establish classification boundaries, with the number of distinguishable classes determined by the measured separation. Based on the estimated class, the follower will select a grip-force limit and hold the gripper position if that limit is reached. *Proposed components:* - Force-sensitive resistor - Compliant silicone pad - Signal-conditioning circuit - Reference objects spanning a range of compliance ### Communication, Control, and Haptic Feedback Subsystem The leader and follower will each use a separate microcontroller. Placing a microcontroller on the wearable device keeps analog sensor traces short and allows only digital data to travel down the cable. The two will communicate over a bidirectional wired serial link using a fixed packet frame with an error-detecting checksum, so corrupted packets can be rejected rather than applied to the servos. The leader-to-follower packet will carry joint targets, the gripper target, and the clutch state; the follower-to-leader packet will carry contact and force information and a system status field. A small vibration motor near the operator's index finger will be driven with PWM, with intensity increasing with the measured force. At minimum the system will distinguish no contact, light grip, and strong grip. If the follower does not receive a valid packet within a defined timeout, it will enter a safe state and prevent further gripper closing. *Proposed components:* - Bidirectional wired serial link with checksum - Coin-style vibration motor and transistor driver - Microcontroller watchdog timers ### Power and Safety Subsystem The system will run from an external wall supply rather than batteries. A servo rail of approximately 6 V will power the follower servos, and a separate regulated logic rail will power the microcontrollers and sensors. The leader will receive low-voltage power through the communication cable so the user wears no battery. Servo and logic power paths will be separated so that servo current transients cannot reset the microcontrollers, with bulk capacitance near the servo connectors and local decoupling at the supplies. Planned protections include a physical emergency-stop switch that disconnects servo power without depending on software, a communication timeout and safe state, software joint-angle limits, mechanical joint stops, servo slew-rate limits, grip-force limiting, and overcurrent protection on the servo rail. The wearable frame is fully passive apart from the vibration motor, which cannot apply injurious force. *Proposed components:* - DC input from a wall supply - Buck converter for the servo rail - Regulator for the logic rail - Reverse-polarity protection and input filtering - Emergency-stop switch ### Custom PCB Subsystem The design will use two custom PCBs, one on each side of the cable. This keeps the analog sensor traces short on the leader, allows the cable to carry only power and a digital link, and places servo current transients on a physically separate board from the sensor front ends. The leader board will carry the leader microcontroller, the buffered and filtered position-sensor inputs, the clutch input, the vibration-motor driver, the serial interface, and local voltage regulation. The follower board will carry the follower microcontroller, the servo drive connections, the FSR signal-conditioning chain, the gripper-position sensor input, the serial interface, the servo and logic rails with separated return paths, and supply protection. ## Criterion for Success - The follower base, shoulder, and elbow reproduce the corresponding leader motions with a mean angular error of 5 degrees or less over the calibrated range. - Command latency from leader sensor acquisition to follower servo-command update is below 20 ms. - The gripper responds to the user's finger motion, and the arm moves an object of at least 100 g between two marked locations in at least 8 of 10 trials. - The haptic system produces feedback that a blindfolded user can use to distinguish no contact, light grip, and strong grip in at least 80% of trials. - When the selected force limit is reached, the follower prevents further gripper closing even while the operator continues to command it closed. - The system distinguishes between reference objects of clearly different compliance and applies a correspondingly different force limit. - The system moves an empty paper cup between two marked locations without permanently crushing it in at least 8 of 10 trials. - The follower enters a defined safe state when the communication link is disconnected. ## Reduced-Scope and Contingency Plan If the two-axis wearable shoulder mechanism does not achieve sufficient repeatability, the shoulder measurements will be replaced by measurements taken entirely on the arm, such as forearm rotation and wrist flexion, which are simple hinge or coaxial rotations requiring no torso reference and which map onto the same follower axes. Repeatability will be measured early, on a breadboard with a single joint, so this decision can be made before the mechanical design is finalized. If the compliance-estimation method does not separate the reference objects reliably, force limiting will use a fixed threshold instead, with contact sensing, haptic feedback, and force protection all remaining functional. This will also be evaluated early with a single servo and a single FSR. If the arm does not provide sufficient torque, link lengths or the payload requirement will be reduced while preserving the complete leader-follower and force-feedback system. If a custom PCB requires revision, development boards and external signal-conditioning circuits will be used temporarily while the fault is documented and corrected. The minimum functional demonstration will include three-axis leader-follower motion, gripper control, grip-force sensing, vibration feedback, fixed-threshold force limiting, and communication-loss protection. ## Relationship to ECE 398 Independent Study Two members of this team, Godrein Owusu and Junghyun Kim, are also enrolled in a separate ECE 398 independent study on robotic teleoperation, with approval to take both courses. Junseo Kim is not part of the ECE 398 project. We identify this explicitly because the two projects may share the same physical robotic platform. **ECE 445** asks whether a low-cost wearable bilateral teleoperation system can reproduce operator motion, sense remote grip force, return haptic information to the operator, and protect objects from excessive gripping force. Its scope is the complete physical and embedded system, including the wearable frame, the follower arm and gripper, force and position sensing, haptic feedback, compliance estimation and adaptive force limiting, bidirectional communication, custom PCB design, power, and safety. The adaptive input is object compliance and measured grip force, and the adaptive output is the allowable grip-force limit. The deliverable is the working hardware platform. **ECE 398** asks how motion scaling affects the speed-precision tradeoff in teleoperation, and whether operator-velocity-based adaptive scaling improves performance over fixed scaling. It uses the platform as an experimental testbed. The adaptive input is operator movement velocity, and the adaptive output is the leader-to-follower motion-scaling ratio. The deliverable is experimental data and analysis. The separation is along a clear line. ECE 445 addresses the physical interaction between the follower and the object; ECE 398 addresses the mapping between operator motion and follower motion. ECE 398 does not address grip-force sensing, object compliance, haptic feedback, adaptive force limiting, PCB design, or construction of the robotic arm, and will not claim any of these as its research contribution. The ECE 398 algorithm is not required for the ECE 445 system to satisfy its requirements or pass its final demonstration. Within the ECE 445 team, the subsystem that constitutes the project's adaptive contribution, together with the haptic feedback path, is owned by Junseo Kim, who is not enrolled in ECE 398. ECE 398 experiments will begin only after the ECE 445 system has passed its motion-reproduction and communication verification, so the two projects do not compete for the platform during ECE 445 integration and debugging. ECE 445 retains priority access to the hardware through its final demonstration. |
||||||
| 49 | Tactile Screen For Visual Aid |
Joshua Sluis Tyler Wille Walter Chang |
Jianchong Chen | Arne Fliflet | design_document1.pdf proposal1.pdf |
|
| Team Members: Walter Chang (walterc2) Tyler Wille (tmwille2) Joshua Sluis (jsluis2) Problem People with visual disabilities have very limited options for aids. Braille and walking sticks are the most popular options, however, they are both extremely limited by proximity. Additionally, they often require built in infrastructure that may not exist, or may not be well maintained. With the onset of AI, there are many new tools that leverage this new technology in order to assist in these tasks. However, we find that these technologies are severely lacking and extremely limiting. They put an overreliance on AI detection and prevent people from making their own judgements. Our solution gives this power back to the people who are using it. Solution Our system will aim to create a tactile physical screen connected to a camera that will allow users to "feel" images. The camera will be attached to a wearable device, ideally glasses, which allow for head movements to control it. Our solution will use a camera through greyscale processing, and automatically detect edges in real time images. It will then draw these lines on this tactile screen, and the resulting image will be able to be felt through raised and lowered pins. Our screen will feature 32x32 pixels, although this may increase depending on time constraints. Our pins will be around 3mm apart, as this is as close as we can get. There will be three main components to the project, the camera, the video processing, and the screen itself. Solution Components Subsystem 1: Camera The camera will be the first step in our system. The camera we will be using will be a lightweight model that will have autofocus. We would like to be able to switch between two modes, navigation and reading. This will allow for more versatility during operation. Navigation will be focused at around 1-5 m while reading will be focused at around 30-40 cm. We will be using the OV5640 AF module to allow for this. It has autofocus, which allows for more ease of use, as well as being able to toggle this feature on and off, for switching between the two modes. During reading mode, we would switch between processing the entire image to processing a smaller part of the whole, 64x32 pixels in the center of the screen. This would allow us to actually show much smaller letters in finer detail. The camera’s autofocus already has this feature. Additionally, the reading system would have a higher refresh rate as compared to navigation, with much less processing needed. It would also include a reading light, to be able to allow the camera to capture letters more precisely. Subsystem 2: Image Processing Our system will feature lightweight image processing on ESP32-S3. This already has a camera interface, which will simplify programming. We will run two different algorithms, depending on the read vs nav modes. Nav: In Nav mode, we will process our image, and use box binning to smooth it out to a granularity of 160x160 to reduce random noise. Then, we will run a Sobel edge detection algorithm to find edges. Our tactile screen will use edges rather than areas, because this will be easier for fingers to find. Then, we will further reduce the granularity to be able to fit on our screen, down to 32x32 Read: In Read mode, we will not need to use box binning. We will also use Otsu thresholding instead of edge detection, as text should be easier to distinguish. We will also set a baseline depending on the light level of the LED. Then, we will reduce the granularity further to 32x16, to be able to display on the tactile screen. This reduction of screen utilization will also further reduce power consumption The camera and image processing subsystem will communicate with the screen subsystem via UART Subsystem 3: Screen The screen is split into two main parts, a moving carriage, and the screen itself. The carriage wil update 32 bits at once, rather than updating the entire screen. This is a much more feasible design, due to wiring and physical constraints. Screen: The screen will have 32x32 pixels. It will consist of 5 layers, one plastic layer, a metal layer, the magnet layer, another metal layer, and final plastic layer. The first plastic layer will be where the user touches the screen. It will be relatively thick, to make the pins stable. The metal layers will hold the magnet layer together. The metal allows the magnets to stick to either the top or the bottom, allowing for bistability, reducing the amount of power needed. They will need to be fairly thin as well in order to achieve a balance between being strong enough to hold the magnet, and weak enough that we can move it magnetically. Both metal layers will have holes, one side will allow for the pins to pass through, while the other side will allow the magnetic field through. Additionally, we will need to add relief cuts to reduce eddy currents.We will use permanent neodymium magnets that are around 1.5mm in diameter and 1mm in height. We will additionally attach pins to the magnets that will protrude from the plastic to interface with the user. The final plastic layer is on the bottom to prevent the the magnets from falling out. Carriage: Our carriage will consist of 32 electromagnets in two rows. Odd and even pixels will be staggered, which both reduces magnetic cross talk, as well as allowing more commercially available electromagnets, and reducing the peak current needed. We will use a NEMA 14 Bipolar Stepper combined with a GT2 Rubber Belt and a 20-Tooth GT2 Pulley to be able to move the carriage along the screen. On the carriage itself, the 32 electromagnets will be Bourns RLB0608-222KL. They will be powered by H bridges, TI DRV8912-Q1, which will allow us to change the polarity of the magnetization. We will communicate to the H-bridges using the SPI protocol with the main controller. Control The carriage will be controlled by an ESP32, which will store the incoming frame as well as the previous. This will allow us to make changes only when there are updates, and leave the screen as is, reducing power consumption. This will also control the stepper motor. Power We will utilize commercially available battery packs, and use USB C power delivery. We will have 3 distinct power rails, on at 9 V, 5V and 3.3V. The 9 V will be used for the motor, the 5V will be used for the H bridge and the 3.3 V will be used for the camera and image processing, as well as the control of the motor. We will also require bulk capacitors on the carriage PCB in order to supply enough current. Criteria For Success - Navigation Mode can display large objects - doorways, cars. - Read Mode can display letters - Read Mode letters can be felt and read with eyes closed. - Refresh rate is greater than 1Hz - Relatively handheld device < 1 kg |
||||||
| 50 | Closed-loop High-accuracy Universal Drink System |
Aiden Robinson Kevin Lu |
Xiyue Zhu | Cunjiang Yu | design_document1.pdf other1.pdf |
|
| Team Members: - Kevin Lu (Kevinlu5) - Aiden Robinson (Aidenr2) # Problem Preparing mixed beverages requires accurate control of the amount of each ingredient in order to maintain consistent ratios. Small errors in ingredient proportions can noticeably affect the taste of the final drink. Many automated beverage dispensers determine the amount of liquid dispensed using a predetermined pump activation time. This assumes that each pump maintains a constant flow rate. In practice, flow rate can vary due to liquid viscosity, reservoir level, tubing conditions, and pump performance. As a result, operating a pump for the same amount of time does not necessarily dispense the same amount of liquid every time. Our project aims to solve this problem by measuring the amount of liquid actually delivered to the cup and using that measurement as feedback to control the dispensing process. The final system will be demonstrated using non-alcoholic liquids, but the same system can be applied to other mixed beverages where accurate ingredient ratios are important. # Solution We propose an automated beverage dispenser with at least four independently controlled ingredient reservoirs. Each reservoir will use a 12 V peristaltic pump to deliver liquid into a cup placed on a load-cell weighing platform. Instead of relying only on pump timing, the system will continuously measure the change in cup weight while dispensing. The controller will use this measurement to determine how much liquid has actually entered the cup and adjust pump operation as the target amount is approached. The system will also estimate the current liquid flow rate using the measured change in mass over time. When the dispensed amount is far from the target, the pump can operate continuously. As the target is approached, the controller can reduce the dispensing rate or use short pump pulses to reduce overshoot. This allows the system to compensate for changes in flow rate instead of assuming that each pump always behaves the same way. An ESP32-S3 will act as the main controller and will host a local web application over Wi-Fi. A user will be able to connect using a phone, tablet, or laptop to select a drink, customize ingredient quantities, start or stop dispensing, and monitor the status of the system. A custom PCB will integrate the microcontroller, load-cell interface, pump drivers, sensor connections, and power circuitry. # Solution Components ## ESP32 Web Interface and Main Controller An ESP32-S3-WROOM-1 will control the complete system and host a local web interface over Wi-Fi. The web interface will allow the user to: - Select a predefined beverage - Create a custom mixture - Adjust ingredient quantities - Start or stop preparation - View dispensing progress - View requested and measured amounts - View completion and fault messages Because the ESP32 hosts the interface itself, no dedicated touchscreen or external server is required. ## Load Cell Measurement Subsystem The cup will sit on a weighing platform connected to a 5 kg strain-gauge load cell. Proposed components: - TAL220 5 kg load cell - NAU7802 24-bit load-cell ADC - Mechanical cup platform - Analog filtering components Before dispensing begins, the system will measure the initial cup weight. During each pour, the ESP32 will continuously measure the increase in mass. The approximate mass flow rate can be calculated using: dm/dt ≈ Δm/Δt This information will be used as feedback for the dispensing controller. ## Peristaltic Pump Dispensing Subsystem The system will contain at least four independently controlled 12 V peristaltic pumps, with one pump assigned to each ingredient. Proposed components: - Four 12 V peristaltic pumps - AO3400A N-channel MOSFETs - Flyback protection diodes - Gate resistors and pulldown resistors - Food-compatible tubing Each pump will be controlled by a MOSFET driver circuit on the custom PCB. While far from the requested amount, the pump will operate continuously. As the measured weight approaches the target, the controller will use shorter pump pulses to improve dispensing accuracy. ## Adaptive Dispensing Control The controller will continuously compare the requested ingredient amount with the amount measured by the load cell. Rather than assuming a constant pump flow rate, the controller will estimate the current flow rate during each pour. This allows the system to adapt to changes caused by reservoir level, liquid viscosity, tubing conditions, or pump variation. The system can also account for residual liquid that continues to enter the cup after the pump is turned off and use this information to improve future shutoff decisions. If a small dispensing error occurs, the controller may also adjust the remaining ingredient quantities to better preserve the intended final drink ratio. ## Fault Detection The load cell will also be used to detect several abnormal operating conditions. The system will: - Prevent dispensing if no cup is detected - Stop dispensing if the cup is removed - Detect a possible empty reservoir, blocked tube, or pump failure if a pump is active but the cup weight is not increasing - Report detected faults through the web interface A conductive leak sensor may also be placed underneath the dispensing area so that the pumps can be disabled if unintended liquid leakage is detected. ## Custom PCB and Power System A custom PCB will contain the major sensing, control, and power circuitry for the project. The PCB will include: - ESP32-S3-WROOM-1 - NAU7802 load-cell ADC - At least four MOSFET pump-driver channels - Load-cell and sensor connectors - Optional INA180 pump-current sensing circuits - 12 V input protection - 5 V and 3.3 V voltage regulation - Programming/debug connections - Status LEDs and test points The system will use an external 12 V DC supply. The 12 V rail will directly power the peristaltic pumps, while regulators on the PCB will generate the lower voltages required by the ESP32 and sensing circuitry. # Criterion For Success - The system will automatically prepare a beverage using at least four independently controlled liquid ingredients. - For requested ingredient quantities between 20 g and 150 g, the system will dispense each ingredient within ±5% of the target mass or ±2 g, whichever is larger, for at least 9 out of 10 trials. - Ingredient quantities will be controlled using real-time load-cell feedback rather than only predetermined pump activation times. - The controller will estimate the current liquid flow rate during dispensing and use this measurement when determining pump shutoff or pulsing behavior. - The system will continue to satisfy the dispensing accuracy requirement when the flow rate of a pump changes by at least 20% from its original calibrated condition. - The ESP32-hosted web interface will allow a user to select or customize a beverage, start dispensing, and monitor the system from a phone, tablet, or computer. - The system will prevent dispensing when no cup is detected. - If a pump is activated but the measured cup weight does not increase sufficiently, the system will stop dispensing and report a fault within 5 seconds. - After preparation is complete, the system will compare the measured final weight with the expected value and report whether the drink is within the required tolerance. |
||||||
| 51 | BTTL BOT PROPOSAL |
Aditya Saxena Laksh Sharma |
Xiyue Zhu | Viktor Gruev | design_document1.pdf proposal1.pdf |
|
| # Dual Smash: Ant-Weight Battle Bot Team Members: -Aditya Saxena (saxena11) -Laksh Sharma (lsharma2) # Problem This is our team's entry for the Fall 2026 ECE 445 Battlebots competition. We will build a sub-2 lb combat robot that can be controlled wirelessly from a laptop and compete against other robots in the arena. Most battlebot designs use a spinning weapon, wedge, or single attacking mechanism. Our idea is to use two side-mounted hammers that swing horizontally. The hammers can be controlled separately, or both can be activated at the same time in a mode we call "Dual Smash." The goal is to use the two hammers to strike, push, or destabilize an opposing robot while still keeping the robot responsive and easy to control. # Solution We will build a 3D-printed ant-weight battlebot controlled by an ESP32-S3 through WiFi. The robot will use differential drive with two brushed DC gearmotors, allowing it to move forward, backward, and turn in place. The main fighting system will consist of two side-mounted horizontal hammer arms. Each hammer will be driven by its own motor or high-torque actuator. The driver will be able to activate the left hammer, right hammer, or both simultaneously. Activating both hammers together will be called Dual Smash. The robot will also contain an onboard camera and time-of-flight sensors. The camera will provide a live video feed to the driver's laptop, while the ToF sensors will provide distance information about nearby robots or obstacles. This information will be displayed in the driver interface and used to help position the robot before attacking. A custom PCB will contain the ESP32-S3, motor-control circuitry, sensor connections, power regulation, and safety circuitry. The robot will be powered using a 2S LiPo battery. # Solution Components ## Subsystem 1: Camera and Driver Interface - Hardware: ESP32-S3-WROOM-1 microcontroller and OV5640 camera module connected through the ESP32-S3 camera interface. - Software: The ESP32-S3 will capture and transmit camera frames over WiFi to a laptop. The laptop interface will display the live camera feed, robot status, ToF measurements, and controls for movement and the two hammer weapons. The driver interface will allow separate commands for the left hammer, right hammer, and Dual Smash mode. ## Subsystem 2: Time-of-Flight Sensing - Hardware: Four VL53L1X time-of-flight sensors positioned around the robot, with sensors facing the front, rear, left, and right sides. - Software: The ESP32-S3 will configure and read each ToF sensor over I2C. Since the sensors share the same default I2C address, their XSHUT pins will be used during startup to assign separate addresses. The distance measurements will be transmitted to the driver laptop and displayed alongside the camera feed. The sensor data will help the driver determine when an opposing robot is within range of the side hammers. ## Subsystem 3: Drive and Dual Smash Weapon System - Hardware: Two brushed DC gearmotors will provide differential drive. A TB6612FNG dual H-bridge motor driver will control the drive motors. The weapon system will contain two independently controlled side-mounted horizontal hammer arms. Each hammer will be connected to its own high-torque motor or actuator through a mechanical linkage. The final motor and gear ratio will be selected based on the required hammer speed, torque, and robot weight. Motor-driver circuitry will allow the ESP32-S3 to control the direction and activation of each hammer. - Software: The ESP32-S3 will generate PWM and direction signals for the drivetrain and hammer actuators. The driver will be able to activate either hammer individually or activate both at the same time using Dual Smash. The software will also enforce a cooldown or reset period between hammer activations so that the mechanism has time to return to its starting position before another strike. A communication-loss safety system will disable the drive and weapon motors if the WiFi connection to the driver laptop is lost. ## Subsystem 4: Power System - Hardware: A 2S LiPo battery will provide power to the drivetrain, hammer motors, and electronics. The battery capacity will be selected after measuring the final current requirements and checking the total robot weight. Voltage regulation will provide the required voltage rails for the ESP32-S3, camera, ToF sensors, and supporting electronics. The custom PCB will also contain decoupling capacitors, power distribution, motor connections, and protection circuitry. A MOSFET-based motor cutoff and manual emergency stop will be included so that power to the drivetrain and hammer system can be disabled quickly. - Software: The ESP32-S3 will monitor communication status and place the robot into a safe state if the wireless connection is lost. Motor commands will default to zero during startup, connection loss, or emergency shutdown. # Criterion For Success 1. The completed robot will weigh less than 2 lb, including the battery, PCB, camera, sensors, drivetrain, and both hammer mechanisms. 2. The robot will respond correctly to forward, reverse, left, and right movement commands from the laptop during repeated testing. 3. The camera system will provide a continuous live video feed to the driver's laptop during a full 2-minute match. 4. All four VL53L1X sensors will initialize correctly and provide distance measurements that are consistent with measured physical distances. 5. The left and right hammer mechanisms will each complete at least 20 consecutive strike and reset cycles without mechanical or electrical failure. 6. Dual Smash will activate both side hammers together, with both hammer movements beginning within 100 ms of each other. 7. The robot will be able to strike or destabilize another ant-weight robot using either an individual hammer or Dual Smash. 8. Drive and weapon power will be disabled within 500 ms of losing the WiFi control connection. 9. The robot will remain controllable while simultaneously transmitting camera and ToF data to the driver laptop. 10. The complete system will operate continuously for the duration of a full 2-minute match without requiring a controller reset. Disclaimer: We used AI to help format and word this document. |
||||||
| 52 | Posture & Neck Strain Monitor for Long Study Sessions |
Heet Chauhan Hrishikesh Deshpande Praveen Madan |
Xiyue Zhu | Cunjiang Yu | design_document1.pdf proposal1.pdf |
|
| # Posture & Neck Strain Monitor for Long Study Sessions Team Members: - Hrishikesh Deshpande (hd11) - Praveen Madan (madan7) - Heet Chauhan (heetc2) # Problem Long study or work sessions at a desk make it easy to slip into bad posture without noticing until neck or back pain has already set in. Existing solutions are poorly suited to everyday use - desk mounted cameras are expensive and raise privacy concerns, back braces are bulky and uncomfortable for long wear, and app based posture trackers usually require a subscription and constant phone interaction. Single-sensor clip-on posture devices have also historically been unreliable, since one IMU alone cannot distinguish real slouching from ordinary head movement (like glancing down at a book). We need a small, low cost, standalone device that reliably monitors both posture and neck strain, and gives a quick nudge when the wearer starts slouching, without requiring a phone or subscription to be useful. # Solution We propose a small two-IMU wearable system: one IMU mounted on the glasses (tracking head orientation) and one mounted on the collar/shirt (tracking torso orientation). By comparing the two, the device can compute the actual relative angle between head and torso — a true measure of neck strain and slouching — rather than relying on either sensor alone, which past single-IMU posture devices have struggled with. The glasses-mounted sensor board connects to the main collar-mounted board via a thin wire. During setup, the user calibrates a "neutral" posture baseline while seated normally, and the device monitors deviation of the relative head-to-torso angle from that baseline in real time. If the wearer holds a slouched or strained position past a configurable threshold, the device alerts them via a vibration motor, prompting them to correct their posture. The system is built around three core subsystems: sensing (dual IMU-based relative orientation tracking), processing/control (an STM32 MCU running sensor fusion and threshold logic across both IMUs), and feedback/power (vibration motor, LED, button interface, and battery management). An extra goal could be adding a wireless subsystem (BLE) to log posture data over time to a companion phone app. # Solution Components ## Sensing Subsystem Captures raw motion data from two locations - head and torso - which the processing subsystem fuses into a relative head-to-torso angle estimate. This relative angle is what actually indicates neck strain and slouching, rather than either sensor's absolute orientation alone. - IMU x2: ICM-42670-P (TDK InvenSense, 6-axis accel + gyro, I2C, AD0 pin used to assign distinct addresses for both sensors on one bus) - Small sensor sub-board for the glasses-mounted IMU, connected to the main board via thin wire ## Processing & Control Subsystem Runs sensor fusion on both IMUs' data, computes the relative angle between head and torso orientation, compares that relative angle against the calibrated baseline, tracks how long the wearer has been out of range, and triggers alerts when the threshold is exceeded. Also manages the calibration/mute button input. - MCU: STM32L452RE (STM32L4 series, low-power Cortex-M4) - Tactile push button for calibration/mute ## Feedback Subsystem Alerts the wearer when sustained bad posture or neck strain is detected, with both a discreet (vibration) and noticeable (LED) option. - Vibration motor: Precision Microdrives 306-100 - Status LED (0603 SMD), driven via MOSFET (DMG2305UX) ## Power Subsystem Powers the device for a full day of use in a compact, lightweight form factor and handles battery charging. - Battery: 3.7V LiPo, ~150mAh - Charge IC: MCP73831 (single-cell LiPo linear charger) - Regulator to provide a clean 3.3V rail to MCU and both IMUs ## Wireless Subsystem (Extra Goal) Allows posture and neck strain data to be logged over time and viewed as trends on a companion app, rather than only reacting to current posture. - BLE module: STM32WB55CG or nRF52832 as a discrete BLE co-processor # Criterion For Success - The device detects a sustained relative head-to-torso angle change of at least 15° from the calibrated baseline, held for 10 seconds, and triggers an alert within 1 second, which should be verified with >90% detection rate over 20 trials, including trials with independent head or torso movement alone (e.g., glancing down while seated upright, or shifting torso without tilting the head) that should not trigger a false alert. - The calibration button correctly resets the baseline relative angle, verified by no false alerts for at least 5 minutes after calibration while the wearer stays upright and still. - The device runs continuously on a single charge for at least 8 hours of active monitoring, verified via bench testing. - The fully assembled device (both IMU boards, main PCB, battery, vibration motor, enclosures) weighs no more than 25g total, verified by direct measurement, so that its weight does not shift sensor position or affect calibration during normal wear. - The main PCB fits within a 4cm x 3cm x 1.5cm enclosure, and the glasses-mounted sensor sub-board fits within a 1.5cm x 1cm x 0.5cm enclosure, both measured on the assembled boards. - The alert is reliably noticed by the wearer, verified by at least 8/10 test users noticing it within 3 seconds of triggering. - (Extra Goal) BLE logging has less than 5% data loss over a 30-minute continuous session. |
||||||
| 53 | Driver Adaptive Automatic Side Mirror |
Anthony Montalto Bohan Ren Joshua Rio |
Zhuoer Zhang | Arne Fliflet | design_document2.pdf proposal1.pdf |
|
| # Rider-Adaptive Automatic Bicycle Mirror Team Members: - Bohan Ren (bren6) - Joshua Rio (rio5) - Anthony Montalto (amont43) # Problem Bicycle mirrors typically need to be manually adjusted according to the rider’s seating position and riding posture. However, when different riders use the same bicycle, when the seat height changes, or when the rider changes riding posture, the position of the rider’s head and eyes may also change. Once the rider’s viewing position changes, the previously adjusted mirror angle may no longer provide the intended rearward field of view. This problem is especially important on a bicycle because frequently turning the head to check traffic behind can be inconvenient and may reduce the rider’s awareness of the road ahead. Existing bicycle mirrors usually remain at a fixed angle and require manual readjustment when the rider’s viewing position changes. Our goal is to design a compact bicycle-mounted automatic mirror system. The system will estimate the rider’s current head position and automatically adjust the mirror based on that position, allowing the rider to maintain an appropriate rearward view after changing posture. # Solution We plan to design a rider-adaptive bicycle mirror system whose primary function is to automatically adjust the mirror angle based on changes in the rider’s head position. The system will use only **one front-facing monocular camera mounted on the bicycle** to measure the rider’s head position. After the camera detects the rider’s face: - The horizontal position of the face center in the image will be used to estimate left-right displacement along the X axis. - The vertical position of the face center in the image will be used to estimate up-down displacement along the Y axis. - The apparent size of the face in the image will be used, after calibration, to estimate forward-backward distance along the Z axis. The system will use a single monocular camera to estimate the approximate X, Y, and Z position of the rider’s head. The initial prototype assumes that the rider is facing forward and maintaining a normal riding posture during measurement. The estimated head position will be used to approximately determine the rider’s eye position. The control system will then combine the estimated eye position, the known mirror mounting position, and a predefined rear viewing region to calculate the required horizontal and vertical mirror target angles. The bicycle mirror will be mounted on a compact two-axis motorized mechanism, with two motors independently controlling horizontal and vertical mirror movement. Position sensors will be installed on the mirror axes. The microcontroller will read the current mirror position and control the motors to move the mirror to the calculated target position. This avoids accumulated error that could result from relying only on motor operating time. The main prototype will use a **button-activated adjustment process**. After the rider changes posture or head position, pressing the adjustment button will cause the system to measure the current head position, estimate the eye position, calculate the target mirror angles, and automatically adjust the mirror. After the adjustment is completed, the mirror will remain at its current position until the rider presses the adjustment button again. # Solution Components ## Head Position Estimation Subsystem The system will use a front-facing monocular camera mounted on the bicycle to detect the rider’s face and estimate the approximate position of the rider’s head. The horizontal coordinate of the face center will be used to estimate left-right movement along the X axis, while the vertical coordinate of the face center will be used to estimate up-down movement along the Y axis. The forward-backward distance along the Z axis will be estimated using the apparent size of the face in the image. Before use, the system will be calibrated by recording the apparent face size at several known distances and establishing a mapping between image face size and head distance. Because the project uses a button-activated process, the system can capture multiple frames after the rider presses the button and average the measurements to reduce single-frame detection error. Proposed components: - Raspberry Pi Camera Module 3 - Raspberry Pi 5 or a similar embedded image-processing platform This subsystem will output the rider’s approximate: - X position - Y position - Z position and send the results to the main control system. ## Controller and Mirror Geometry Subsystem This subsystem is responsible for receiving the rider’s head-position data and calculating the horizontal and vertical angles that the mirror should reach. The system will calculate the mirror orientation based on: - The estimated position of the rider’s eyes - The fixed mounting position of the mirror - A predefined rear viewing position Proposed components: - STM32G474RET6 microcontroller - Adjustment button - Programming/debug interface - Communication interface between the Raspberry Pi and STM32 After the rider presses the adjustment button, the Raspberry Pi will complete the head-position estimation and send the X, Y, and Z data to the STM32. The STM32 will then calculate the target mirror angles and control the mirror motors to complete the adjustment. ## Motorized Mirror Actuation and Feedback Subsystem The mirror will be mounted on a compact two-axis motorized mechanism. Two small geared DC motors will be responsible for: - Horizontal angle adjustment - Vertical angle adjustment Proposed components: - Two compact geared DC motors - Two DRV8876 motor-driver ICs - Two AS5600 magnetic angle sensors - Permanent magnets coupled to the two mirror axes - Custom two-axis bicycle mirror mounting mechanism The STM32 will drive the two motors using PWM and direction-control signals. The AS5600 sensors will measure the current positions of the two mirror axes. The STM32 will compare the current mirror position with the target position and continue controlling the motors until the mirror reaches the desired position. After the adjustment is completed, the motors will stop and the mirror will remain fixed until the next button-triggered adjustment. The DRV8876 provides basic current limiting and protection, so motor protection will not be treated as a separate subsystem and will instead be integrated into the motor-driver design. ## Power and Custom PCB Subsystem We will design a custom PCB that integrates the main control, motor-driver, and power functions of the system. The PCB will include: - STM32G474RET6 microcontroller - Two DRV8876 motor-driver circuits - Two AS5600 mirror-position feedback interfaces - Raspberry Pi communication interface - Adjustment-button input - Programming/debug interface - Motor and sensor connectors - Power-conversion and filtering circuitry - Necessary protection circuitry and test points The system will be powered by a rechargeable battery mounted on the bicycle. Proposed components: - Rechargeable battery pack - TPS54302 buck converter - TLV75533PDBVR voltage regulator - Input filtering and decoupling capacitors - Basic input-protection circuitry # Criterion For Success The project will be considered successful if the following goals are achieved: - A single front-facing monocular camera can consistently detect the face of a forward-facing rider and obtain the horizontal position, vertical position, and apparent size of the face in the image. - The system can use the same monocular camera to estimate the rider’s X, Y, and approximate Z head position without requiring an additional distance sensor or second camera. - After calibration, the system can distinguish at least three different forward-backward head positions using the apparent face size in the image. - After the rider changes posture or head position and presses the adjustment button, the system can calculate new horizontal and vertical target mirror positions based on the updated head position. - After the adjustment button is pressed, the bicycle-mounted mirror can automatically complete both horizontal and vertical adjustment. - After adjustment is completed, the mirror remains at its current position until the rider presses the adjustment button again. - A clearly visible verification object, such as a red LED light or colored marker, will be placed at a fixed location behind the bicycle. For at least three different rider positions or normal riding postures, the rider must be able to fully see the fixed object in the mirror after each automatic adjustment. - From the same calibrated rider position, the system will perform **10 repeated automatic adjustments**. After every adjustment, the rider must be able to fully see the same fixed verification object behind the bicycle in the mirror. - The camera, motorized mirror, custom PCB, and battery can be mounted securely and compactly on the bicycle without interfering with the rider’s normal seating position or normal bicycle steering. - The system can operate from a rechargeable battery mounted on the bicycle, while the custom PCB provides motor driving, power conversion, mirror-position feedback, and system control. |
||||||
| 54 | # Tabletop Fantasy Football |
Nicholas Goo Parthiv Adimulam Raahil Parikh |
Xiyue Zhu | Cunjiang Yu | design_document1.pdf other1.pdf proposal1.pdf |
|
| Team Members: Parthiv A.: parthiv4 Nicholas G.: ngoo2 Raahil P.raahilp2 ## Problem Fantasy football is popular, but the apps require a ton of commitment. You need to set up a league, coordinate a draft with a bunch of people, manage your roster all season, and stay engaged for months. It's hard to just casually play with friends. Say your friend visits on a Sunday during football season. You both want to watch the games and compete head-to-head right now. But starting a fantasy league means league setup, player selection, and a whole season commitment. There's no way to just pick up and play for an afternoon. Plus, fantasy football is completely digital. You're checking scores on your phone, watching your team on an app. There's no real, shared experience with your friends. Two people sitting together can't actually feel the competition happening between them. Other solutions like LED scoreboards show data but don't let you interact with them, and board games with static scoring need manual updates and don't connect to live sports data. ## Solution Overview We're building a battery-powered tabletop fantasy football system that lets you play casual head-to-head matchups instantly, without any app setup or season commitment. Two friends can just place cards on a board and compete for an afternoon without league coordination or long-term commitment. Place NFC-enabled physical player cards on the board to represent your lineup. Start a matchup. The board pulls live NFL stats over Wi-Fi and updates scores in real time. The microcontroller processes the NFC reads to identify which players are placed and where on the board. RGB LEDs react to scoring events with color changes and pulses. Audio alerts go off for touchdowns and big plays. Brightness adjusts based on score changes. Want to play tomorrow with different players? Swap the cards and start a new game. No app, no league setup needed. ## Solution Components ### Main Control PCB Subsystem A custom PCB will tie everything together. A microcontroller with Wi-Fi will process NFC data, manage the display, handle the game logic, and talk to a backend server for live NFL stats. The software will debounce NFC reads to make sure we're getting stable player identification and not false reads. Clock crystals, programming headers, and support circuitry will all be on the board instead of using dev boards. ### NFC Subsystem NFC tags embedded in the player cards. An NFC reader integrated into the PCB detects which cards are placed on the board and where. Position zones map to roster slots like QB, RB, WR, TE, etc. The software maps detected cards to actual player IDs and checks that lineups are valid before starting a matchup. ### Live Sports Data Backend A backend service connects to an NFL or fantasy sports API to pull current player stats. The system calculates fantasy scores using configurable scoring rules (PPR, Standard, Half-PPR, custom). Player updates get sent to the board regularly. The backend also tracks matchup state and tells the board when scoring happens. ### Display Subsystem A screen shows current scores for both players, the quarter/time remaining, and key player stats. Updates in real time as NFL games progress and players score. Simple and easy to read during gameplay. ### Visual Feedback Subsystem RGB LEDs integrated into the board or on player card positions. LEDs change color or pulse when a player scores, gets injured, or other events happen. Brightness scales with total team score or match intensity to give feedback about the game state. ### Audio Feedback Subsystem A speaker plays sounds for touchdowns, field goals, and major events. Audio alerts signal the start and end of matchups and notify players of scoring updates. Adjustable volume so users can control how loud it gets. ### Power Subsystem The device runs on external power. Voltage regulation provides stable power to the microcontroller, NFC reader, LEDs, display, and other components. ### User Interface Subsystem Physical buttons or controls let users start matchups, swap player cards, and adjust settings like brightness and volume without a phone. If we have time, we could add Bluetooth on the microcontroller to enable an app for customizing color assignments, scoring rules, and other settings. ## Criterion for Success The project will be successful if it can: - Reliably identify and locate NFC player cards on the board. - Validate lineup configurations and prevent invalid matchups from starting. - Fetch live NFL player statistics and calculate fantasy scores based on the configured scoring system. - Update and display scores as NFL games progress. - Produce visual feedback (LED color changes or pulses) in response to scoring events. - Produce audio alerts for touchdowns, field goals, and other major events. - Allow two players to set up and start a matchup in a reasonable amount of time. - Operate reliably for extended periods of gameplay. - Control LED channels independently and show color transitions between events. |
||||||
| 55 | Heterogeneous Multi-Robot Cooperative Localization and Communication Testbed |
Sahil Jain XP Liu Yuxiang Xing |
Tim Jiang | Viktor Gruev | design_document1.pdf other1.pdf |
|
| Team Members: - XP Liu (xpliu2) - Yuxiang Xing (xing14) - Sahil Jain (sahil5) # Revision Summary Following Professor Fliflet's September 10 feedback, our core deliverable is a one-leader, two-follower system based on AprilTags. Both followers B and C are required. We will prioritize simultaneous three-robot operation using one shared follower PCB design and software implementation. UWB, LiDAR, complex navigation, and sensor benchmarking remain optional. The numerical acceptance criteria below are proposed for course-staff review. # Problem Mobile robots working together need to estimate their relative position and heading, exchange task information, and follow a moving leader without contact. A small laboratory platform can demonstrate these functions in a repeatable environment. We address a bounded version of this problem: two differential-drive followers independently estimate the pose of one tracked leader using AprilTags, follow it simultaneously at low speed, and stop at two distinct relative poses after the leader stops. The principal engineering work is a custom follower motor, power, and safety PCB, its embedded control firmware, and integration with onboard AprilTag localization and three-robot coordination. # Solution The required system consists of an existing tracked leader A and two followers B and C. Each follower will use a copy of the same custom PCB design and the same onboard software, with separate robot IDs, calibration values, and target offsets. Completing only A and B is an intermediate milestone, not the final demonstration. Core tests use a flat 3 m x 3 m indoor field with controlled lighting and two obstacle-free marked routes, one straight and one gently curved, each approximately 1 m long. An operator guides A at no more than 0.10 m/s and slows on curves to keep both followers within their validated speed and camera-visibility limits. Autonomous route planning, narrow-aisle coordination, and arbitrary initial poses are not required. Each follower directly observes an AprilTag target on A with its own onboard camera. Encoder measurements and an IMU support short-term motion estimation between visual updates; AprilTags are the primary relative-pose reference. Wi-Fi carries robot IDs, sequence numbers, heartbeat and task/health state. A does not need to provide an absolute map pose, and a laptop does not supply externally measured pose or wheel commands to B or C. B and C occupy separate rear-left and rear-right positions relative to A. The initial proposed targets, expressed at defined robot reference points in A's frame (x forward, y left), are B: (-0.75 m, +0.30 m) and C: (-0.75 m, -0.30 m), both with A's heading. Before scored trials, the offsets and tag/camera mounting geometry will be checked against actual chassis dimensions, camera field of view, marker occlusion, route swept areas, and stopping clearance. Any necessary offset adjustment will be documented and fixed before scoring; error tolerances will not be changed between trials. The robots will not exchange sides or cross each other's approach paths. Core trials start with both followers in their assigned regions, A's target visible to both cameras, and valid communication. Multiple rigidly mounted AprilTags with known transforms to A may be used to maintain both sight lines. Loss of visibility causes a stop rather than an attempt to recover from arbitrary poses. After A stops, B and C settle at their respective targets. This controlled arrangement demonstrates one leader with two simultaneous followers without adding general obstacle avoidance. The custom PCB, firmware, control logic, and integration will be developed for this course. Existing chassis, A's controller, commercial sensor modules, and open-source libraries will be identified as reused components. No employer hardware, software, or proprietary dataset will be reused. # System Operation 1. Place A, B, and C at surveyed starting poses in their assigned regions. Verify both AprilTag estimates, robot IDs, heartbeat reception, and local motor-disable operation. 2. Start a trial and guide A along one marked route within the validated speed and visibility envelope. 3. B and C independently estimate A's relative pose onboard, track their distinct target offsets, and send bounded wheel-speed requests to their own custom PCBs. 4. Each PCB acquires encoder feedback and runs local closed-loop wheel-speed control and a Pi-command watchdog. 5. After A stops, both followers settle at their assigned poses, limiting final-approach speed to 0.05 m/s. 6. A follower enters SAFE_STOP on invalid visual localization, stale required heartbeat/task messages, or a local Pi-command timeout. Each follower monitors the leader and the other follower's health; a reported peer fault or missing peer heartbeat also requests a stop. The operator stops A on a fault. Each follower's local stop must work without relying on the laptop or successful delivery of a fault message. 7. Recovery requires valid inputs and an explicit restart. Independent overhead/manual measurements are recorded for evaluation only. # Solution Components ## Subsystem 1: Leader and Two Follower Platforms - Leader A: existing personally owned tracked chassis and drive controller; exact model and available control interface remain to be documented. - A additions: rigid AprilTag target assembly with measured dimensions and transforms, and a Wi-Fi heartbeat/task-state bridge. ESP32-S3-WROOM-1 is proposed for the bridge; its interface to the existing platform remains to be verified. - Followers B and C: two identical ECE 110/SparkFun Shadow-style differential-drive chassis candidates, with encoder-equipped brushed DC gearmotors. Exact chassis and motor part numbers remain to be selected. - Simple rigid camera/sensor mounts and distinct robot identification; no payload manipulation, rack structures, or interchangeable task fixtures are required. ## Subsystem 2: AprilTag Relative Localization - One Raspberry Pi Global Shutter Camera with Sony IMX296 sensor per follower, proposed; lenses and mounting geometry to be selected for the working distance and both target positions. - AprilTag targets on A with known transforms to its reference frame. Known floor markers may support calibration and initial checks. - Quadrature wheel encoders and a BNO085 IMU per follower, proposed, for supporting motion estimates. We will calibrate each camera-to-follower transform and each tag-to-leader transform. Each follower's relative-pose estimate will refer to defined robot reference points. Only one working AprilTag-based localization configuration is required. Encoder/IMU integration will remain lightweight; an extensive sensor-fusion comparison is not a core deliverable. UWB and LiDAR are not prerequisites for any core test. ## Subsystem 3: Onboard Control and Communication Each follower will use a Raspberry Pi 5 (4 GB), proposed, for image processing, relative-pose estimation, and its state machine. ROS 2 and rosbag2 may be used for messages and logging. The shared states are IDLE, FOLLOW, RENDEZVOUS, SETTLE, COMPLETE, and SAFE_STOP. The implementation is reused on B and C, with individual calibration, IDs, and target offsets. The controller generates bounded left/right wheel-speed requests with experimentally calibrated deadband compensation. Core follower speed is limited to 0.10 m/s. Formation offsets, curve speed, and initial regions will be chosen so simultaneous following does not require a follower to exceed this limit. Neither follower may steer through the other's assigned region to regain its target; invalid localization or a departure from the validated operating envelope ends the trial. Wi-Fi messages contain robot ID, sequence number, and task/health state. Local receipt times detect stale data without requiring precise inter-robot clock synchronization. Each PCB has an independent watchdog for commands from its own Pi. A laptop starts trials and records results; all follower localization and wheel control run onboard. ## Subsystem 4: Shared Custom Follower Motor, Power, and Safety PCB One custom PCB design, assembled and used on both B and C, is the main circuit-level deliverable. Each board integrates: - ESP32-S3-WROOM-1 microcontroller, proposed, for encoder acquisition, wheel-speed control, and watchdog handling. - Two brushed-DC motor-drive channels; TI DRV8876 is a candidate subject to operating/stall-current measurements and final circuit review. - INA226 current/bus-voltage monitoring, proposed. - Encoder input conditioning and appropriate protection. - Battery input fuse, reverse-polarity protection, and regulated computer/logic power rails. - Physical motor-disable/emergency-stop input and local command watchdog. - A defined Pi-to-microcontroller command interface, sensor connectors, and debugging test points. Motor, battery, and regulator part numbers remain pending load characterization. These selections and A's interface will be resolved before schematic finalization. Both board assemblies will be checked first with wheels lifted and then at restricted field speed. C reuses the validated design; it does not require a second independent circuit or software architecture. ## Subsystem 5: Test Field and Independent Evaluation The flat 3 m x 3 m field contains a straight and a gentle curved route of approximately 1 m each. Both routes must preserve direct views of A's tags, separate follower approach regions, and physical clearance throughout motion and stopping. Core tests exclude narrow aisles, route replanning, moving obstacles, uneven surfaces, and deliberate prolonged visual occlusion. An overhead camera with top-mounted fiducials records all three trajectories independently of the onboard cameras. Its exact model remains to be selected. Surveyed static positions and headings will validate calibration and measurement uncertainty. Final poses will also be checked using floor references and manual distance/angle measurements. We will not claim compliance where measurement uncertainty prevents distinguishing pass from fail. Logs will report each follower's relative-pose and following errors, final position/heading errors, joint trial success, and communication/stop events. These measurements evaluate the robots and do not feed their controllers. # Experimental Plan 1. Characterize follower motors/loads, finalize common components and A's interface, and validate the shared custom PCB and local stop functions. 2. Calibrate the AprilTag system and bring up A with B as an intermediate integration milestone. 3. Assemble C using the same design and software, calibrate it independently, and verify simultaneous visibility and safe distinct target positions. Allocate integration time for C before optional features. 4. Tune simultaneous B/C following on the straight route, then the gentle curve, followed by settling at their respective poses. Fix the tested offsets and geometry before scoring. 5. Run the scored three-robot trials and per-follower fault tests. Attempt optional extensions only after the full one-leader, two-follower system meets the core criteria. # Criterion for Success These are proposed acceptance criteria for staff review under the controlled conditions above. Both followers are required; single-follower success does not satisfy the final system criterion. 1. **AprilTag relative localization:** For each of B and C, evaluate ten surveyed static relative poses with A's tag visible, covering 0.5-1.0 m reference-point separation and relative heading within +/-30 degrees, including the selected formation geometry. Each follower shall estimate planar relative position within 5 cm and relative heading within 5 degrees at at least eight of its ten poses, measured against independent references. 2. **Simultaneous following and rendezvous:** The complete A+B+C system shall pass at least eight of ten joint trials, five on each marked route. A moves at no more than 0.10 m/s, reduced on curves as needed. After the first two seconds of motion, each follower shall have absolute reference-point separation error relative to its assigned target separation no greater than 15 cm in at least 80% of evaluated moving samples. Both followers must remain on their assigned sides with physical clearance; missing localization samples count as failures of the sample condition, not omitted data. Within 30 seconds after A stops, both followers shall settle at their distinct assigned relative poses with planar position error no greater than 5 cm and heading error no greater than 5 degrees, and remain stopped simultaneously for at least one second. A trial passes only if both followers satisfy all conditions in that same trial, with no collision or intervention on either follower. Aborted trials and trials where only one follower succeeds count as failures. 3. **Integrated hardware and safe stopping:** Both followers shall perform the motion tests using their own assembled copy of the custom PCB and onboard control. For each follower, independently test loss of required Wi-Fi heartbeat, loss of valid AprilTag localization, and loss of Pi-to-PCB commands. The affected follower shall come to rest within 0.5 seconds of its last valid relevant input at the maximum follower test speed of 0.10 m/s. Test each fault three times per follower; all must pass. Verify each physical motor-disable input disables drive actuation. Also verify the other follower stops on a reported peer fault or peer-heartbeat timeout. Perform fault tests with sufficient clearance and operator control of A; recovery requires valid inputs and an explicit restart. # Optional Extensions Only after A, B, and C pass the core criteria: - Evaluate Qorvo DWM3001CDK UWB boards as auxiliary ranging. - Add LiDAR or short-range ToF sensing, or compare additional localization configurations. - Explore changed lighting, partial occlusion, additional initial poses, or simple obstacle layouts. - Improve stationary rendezvous precision toward 2 cm and 3 degrees. The required deliverable is one existing leader and two custom-controlled followers demonstrating simultaneous AprilTag-based localization, low-speed following, settling at separate relative poses, and local fail-safe stopping. |
||||||
| 57 | Digital Audio Player with Onboard AI Equalization |
Advaith Anand Andrew Cheng Siddharth Salapaka |
Denghan Xiong | Viktor Gruev | design_document1.pdf proposal2.pdf |
|
| # Digital Audio Player with Onboard AI Equalization **Team Members:** - Siddharth Salapaka (svs9) - Andrew Cheng (ac158) - Advaith Anand (aanand10) ## Problem Portable digital audio players let users carry a personal music collection and listen without a phone. However, adjusting their sound usually means choosing a fixed equalizer preset or changing individual frequency bands by hand. A fixed preset applies the same correction to every song. A "bass boost" that helps a thin acoustic recording can make an already bass-heavy track muddy, and the balance can change between sections of the same song. Listeners often describe what they want in simple terms, such as "more bass," "clearer vocals," or "softer treble," without knowing which frequencies to adjust. We want to build a player that turns these listening goals into continuous EQ adjustments that depend on the music being played. The player should keep convenient physical controls and high-quality wired playback. We also need to show with an objective measurement that this adaptive EQ does better than a fixed preset. ## Solution We propose a battery-powered digital audio player with microSD storage, a rotary wheel, physical buttons, an OLED display, a dedicated stereo DAC, a headphone amplifier, and a custom control PCB. Users load songs onto the microSD card, select a track, and choose a listening goal on the device. Each listening goal is defined as a **target tonal balance**: a specific shape for the relative energy across five frequency bands. The target is derived from a reference curve measured on a large, independent music corpus rather than from our own listening. During playback, a compact neural network analyzes the last two seconds of the original, unprocessed audio. It then predicts gains for a five-band equalizer that move the current passage toward the selected goal's target. Because the correction depends on the passage, a thin recording receives more bass boost than one that already has plenty of bass. Only the adaptive controller can make this distinction. A fixed preset cannot. Digital signal processing applies the predicted gains continuously. Gain changes are ramped to avoid clicks, headroom is reserved for boosts, and a final peak limiter protects the output. The same gains are applied to both channels to preserve stereo balance. All analysis, inference, and filtering run on the player without an internet connection. Model training happens offline during development. The required modes are "more bass," "clearer vocals," and "softer treble," plus an EQ bypass mode. The central engineering claim of the project is measurable: **for each goal, the onboard controller brings held-out music closer to the goal's target tonal balance than the best possible fixed preset, by a committed margin** (see Criterion for Success). The training targets, dataset splits, metric, and pass thresholds will be committed to our repository before training begins, and the commit hash will be shared with our TA. ### System Overview Power enters through a 5 V USB-C port and goes to a BQ24074 charger, which charges a protected single-cell lithium-ion battery and supplies the system at roughly 3.0 to 4.4 V. A TPS63070 buck-boost regulator converts this to 3.6 V. Two low-dropout regulators then produce the final rails: a TLV75733P supplies the digital 3.3 V rail for the microcontroller, microSD card, and OLED, and a TPS7A2033 supplies a separate low-noise analog 3.3 V rail for the DAC and headphone amplifier. Audio flows from the microSD card to the STM32H743ZIT6 microcontroller over a 4-bit SDMMC interface. The microcontroller sends processed audio over I2S (using the SAI peripheral with DMA) to a PCM5102A DAC. The DAC output passes through an input attenuator to a TPA6132A2 headphone amplifier, which drives the 3.5 mm jack. Inside the firmware, the WAV reader fills a ring buffer. Audio then passes through feature extraction, the int8 neural network, gain smoothing, the five-band biquad equalizer, a headroom pre-gain, 32-bit digital volume control, and a peak limiter before it is sent to the DAC. The rotary encoder and four buttons connect to the microcontroller's GPIO and external interrupt pins. The microcontroller drives an SSD1306 128 × 64 OLED over SPI and reads the battery voltage through a resistor divider on an ADC input. The board also includes an SWD header, a UART logging header, and test points. ## Solution Components ### Main Control PCB Subsystem The custom PCB connects the processor, storage, audio output, controls, and power circuitry. We plan to use an STM32H743ZIT6 (Arm Cortex-M7, up to 480 MHz, 2 MB flash, 1 MB RAM). Audio leaves the processor through the SAI peripheral in I2S mode using DMA, so model inference, display updates, and SD reads cannot stall the output stream. The audio pipeline is **sample-indexed and deterministic**. Features are computed every 4,800 samples (100 ms). The resulting gain update is applied at a fixed sample boundary one hop later. An inference that is not finished by that boundary is logged as a deadline miss. Because of this, the firmware produces bit-identical output whether it plays in real time or runs in the offline evaluation mode described below. We will use a four-layer board with a continuous ground plane. The analog output section will be placed away from the switching regulator, SD lines, and OLED lines. Final assembly will use ICs and supporting circuitry on our PCB, with a connected display and controls. Development boards will be used only for early bring-up. Components: - STM32H743ZIT6 microcontroller IC - 25 MHz HSE crystal, 32.768 kHz LSE crystal, decoupling capacitors, and reset circuitry - SWD programming/debugging header, UART logging header, and test points - Storage, display, control, and audio connectors Requirements: - Maintain at least 40 ms of buffered output audio. Worst-case audio processing time per 10 ms block must stay below 5 ms (under 50% of the real-time budget). - Log buffer underruns, inference deadline misses, per-block CRC-32 of processed audio, and predicted gains over UART. - Measured output sample rate within ±100 ppm of 48 kHz. ### AI and Equalization Subsystem #### Equalizer bands The EQ uses five fixed biquad filters (RBJ cookbook forms). Only the gains change. Fixed frequencies and bandwidths keep the learned control space small and make the combined response easy to predict for headroom management. The five bands are: - **Band 1, Low:** low shelf at 100 Hz, Q of 0.7, measured over 20 to 150 Hz. - **Band 2, Low-mid:** peaking filter at 300 Hz, Q of 1.0, measured over 150 to 500 Hz. - **Band 3, Mid:** peaking filter at 1 kHz, Q of 1.0, measured over 500 Hz to 2 kHz. - **Band 4, Presence:** peaking filter at 3.2 kHz, Q of 1.0, measured over 2 to 5 kHz. - **Band 5, Treble:** high shelf at 8 kHz, Q of 0.7, measured over 5 to 16 kHz. Each band is limited to ±6 dB. The treble measurement region stops at 16 kHz to avoid encoder low-pass artifacts in the training material. #### Goal definitions and target curves **Reference curve.** For every non-silent 3-second segment of the training split, we compute the energy in each of the five measurement regions in dB and subtract the mean across the five bands. This leaves only the tonal shape, independent of loudness. The reference curve R is the median of these vectors over the training split. It describes a typical tonal balance for commercially distributed music, and no team member's hearing is involved in computing it. **Goal targets.** Each goal's target T is the reference curve plus a fixed set of offsets, re-normalized to zero mean. The offsets are frozen before training and are not changed after we see any results. All offsets are in dB relative to R, and any band not mentioned has an offset of 0 dB. - **More bass:** +4.0 dB in the low band and +1.5 dB in the low-mid band. The low-band gain is constrained to be zero or positive. - **Clearer vocals:** −2.0 dB in the low-mid band, +1.0 dB in the mid band, and +3.0 dB in the presence band. The presence gain is constrained to be zero or positive, and the low-mid gain is constrained to be zero or negative. - **Softer treble:** −1.5 dB in the presence band and −4.0 dB in the treble band. The treble gain is constrained to be zero or negative. The sign constraints keep each goal faithful to what the user asked for. For example, "more bass" never cuts bass, even on a track that is already bass-heavy; the controller simply applies little or no boost there. "Clearer vocals" changes the tonal balance of the whole stereo mix. It does not isolate or separate the singer. #### Training data and dataset separation - **Source material:** Full-length, Creative Commons–licensed tracks from the Free Music Archive (FMA) dataset, a public research corpus of over 100,000 tracks with artist and genre metadata. We will sample about 2,000 tracks stratified across top-level genres. We will exclude tracks shorter than 60 s or longer than 10 min and files encoded below 256 kbps. Tracks are decoded and resampled to 48 kHz, 16-bit stereo WAV with a high-quality resampler (SoX). Audio is not redistributed. - **Split by artist:** Tracks are divided 70/15/15 into training, validation, and test splits (about 1,400, 300, and 300 tracks), with **no artist appearing in more than one split**. This is stricter than separating by song, because tracks from the same artist often share mixing and mastering choices. - **Freezing the test set:** The split lists and their SHA-256 hashes are committed before training. The validation split is used for all development decisions. The test split is used only for the final evaluation. - **Augmentation (training split only):** Random low-shelf, high-shelf, and spectral-tilt changes of up to ±6 dB are applied to training excerpts before labels are generated. This teaches the model to correct a wide range of starting balances. #### How training targets are generated No person sets gains for individual songs. The reference gains are produced by an offline optimization script (the "oracle"), and the team's only choices are the frozen goal offsets above. For each training track, each goal, and each 100 ms hop, the oracle: 1. Takes a **centered** 3-second window of the input (1.5 s before and 1.5 s after the current hop) and computes its magnitude spectrum. 2. Applies the exact magnitude response of the device's five-biquad cascade for a candidate set of gains to that spectrum, and measures the resulting mean-normalized band levels. 3. Uses bound-constrained optimization (SciPy L-BFGS-B) to find the gains that minimize the sum of three terms: the squared difference between the resulting band levels and the target, a smoothness penalty on the change from the previous hop's gains, and a small penalty on the size of the gains. The gains are limited to ±6 dB and must satisfy the goal's sign constraints. The weights of the smoothness and size penalties are tuned on the validation split. 4. Stores the resulting gains as the training label for that hop. The oracle is **non-causal**: it uses 1.5 s of future audio and an iterative solver, so it cannot run on the player. The neural network has to predict the oracle's gains from **past audio only**, within a microcontroller's compute budget. This is the learning problem. The model has to recognize how the current passage's spectrum relates to the target and anticipate where the music is heading. #### Model and on-device deployment - **Features:** Every 100 ms, a 4,096-sample Hann-windowed FFT (CMSIS-DSP) of the mono sum of the *unprocessed* input produces 24 log-spaced band energies. The model input is the last 20 frames (2 s of context), normalized with training-set statistics, plus a one-hot goal vector. - **Network:** A small 1-D temporal convolutional network (depthwise-separable layers, about 25,000 parameters). A tanh output is scaled to ±6 dB, and sign constraints are enforced by clamping. - **Training loss:** Mean squared error to the oracle gains, plus an auxiliary tonal-balance loss computed through a differentiable model of the EQ filters. - **Quantization:** Quantization-aware training to int8. The model is deployed with STM32Cube.AI / ST Edge AI Core, with TensorFlow Lite for Microcontrollers as a fallback. Weights are stored in internal flash, with a target of under 150 KB of flash and under 64 KB of activation RAM. - **Strength control:** The user's strength setting (0 to 100%) scales the predicted gains linearly after inference. All evaluations use 100%. #### Baselines - **Best fixed preset (graded baseline):** For each goal, the single constant five-band gain setting that minimizes mean tonal-balance error over the *entire training split*, under the same ±6 dB limits and sign constraints. No constant preset can score better on the training data, so a network that learned to output constant gains could at most tie this baseline. - **Oracle (upper bound, reported):** The non-causal optimizer's gains, which show how much improvement is possible. - **Causal rule-based controller (reported):** Gains computed directly from the past 2 s of band levels with the same smoothing. This shows how much the network adds beyond a hand-written rule. We will report this comparison whatever the outcome. #### Evaluation metric For each non-silent 3-second segment of processed output, we measure the output's energy in each of the five band regions in dB and subtract the mean across the five bands. The segment's tonal-balance error is the root-mean-square difference, in dB, between these mean-normalized levels and the goal's zero-mean target curve. Segments whose input is below −60 dBFS are excluded. A track's error is the average of its segment errors. Because the metric removes overall level, loudness differences between conditions do not affect the score. #### Evaluation procedure - **Device evaluation (pass/fail):** 100 test-split tracks, stratified by genre and fixed at the design freeze, are processed **on the player** in offline evaluation mode. This mode runs the identical sample-indexed firmware path, reads WAV files from microSD, and writes processed WAV files back to microSD. Each track is processed for each goal with the neural controller and with the best fixed preset, using the same filters, headroom logic, and limiter. - **Host simulation (reported):** The same C DSP code and quantized model, compiled for a PC, evaluate the full 300-track test split. - **Live equivalence:** For 10 tracks, per-block CRC-32 values logged over UART during real-time playback must match offline mode exactly. - **Analog confirmation:** For the same 10 tracks, the headphone output into a 32 Ω load is recorded with a USB audio interface at 48 kHz and 24 bits. After correcting for the analog chain response measured in bypass, the error reduction must agree with the digital result within 5 percentage points. #### Runtime protection - Gain changes are smoothed with a one-pole filter with a time constant of about 300 ms. Filter coefficients are updated every 1 ms (48 samples), with no gain step larger than 0.05 dB per update. - A headroom pre-gain equal to the peak of the combined filter response (evaluated at 64 log-spaced frequencies) plus 0.5 dB keeps boosts from raising overall level. A look-ahead peak limiter enforces a −1 dBFS ceiling. - Silence detection (input below −60 dBFS) holds the current gains. - Non-finite, out-of-range, or stuck model outputs trigger a 500 ms ramp to bypass. A missed inference deadline keeps the previous gains, and filtering continues uninterrupted. Components: - Compact int8 temporal convolutional network, with weights in onboard flash - STM32Cube.AI / ST Edge AI Core deployment tools and CMSIS-DSP routines - Spectral feature extraction and five stereo-linked biquad EQ bands - Gain smoothing, headroom management, and look-ahead peak limiter - Offline tools: dataset preparation, oracle label generator, training, host simulator, and evaluation scripts ### Audio Output Subsystem The processor sends filtered stereo audio to a PCM5102A DAC over I2S in 32-bit frames. The PCM5102A generates its clocks from the bit clock, so no separate master clock line is required. Because the PCM5102A has no internal volume control, volume is applied digitally in the 32-bit domain before transmission. This preserves the 16-bit source resolution across the usable volume range. A TPA6132A2 ground-referenced headphone amplifier drives the 3.5 mm jack without output coupling capacitors. A resistive attenuator between the DAC's 2.1 Vrms full-scale output and the amplifier input, together with the amplifier gain setting, will be chosen so that a full-scale DAC signal cannot drive the amplifier into clipping. The design targets conventional 32 Ω headphones. To prevent pops, the DAC soft-mute (XSMT) pin and the amplifier enable pin are sequenced by firmware at power-up, power-down, and track changes. Both analog ICs run from a dedicated low-noise 3.3 V LDO rail. Analog traces are kept short, and digital return currents are routed away from the analog section. Components: - Texas Instruments PCM5102A stereo DAC - Texas Instruments TPA6132A2 headphone amplifier - 3.5 mm stereo headphone jack - Input attenuation, coupling, and output-filter components per the reference circuits - Local supply filtering and audio test points Requirements (measured at the headphone jack into 32 Ω, EQ bypassed): - Frequency response flat within ±1 dB from 20 Hz to 20 kHz - THD+N below 0.1% at 1 kHz, 0.2 Vrms output - Dynamic range of at least 90 dB (A-weighted), relative to maximum unclipped output - Maximum unclipped output of at least 0.5 Vrms - No audible pops at power-up, power-down, or track change, with transients below 10 mV peak at the jack Measurements will use a lab audio analyzer or a USB audio interface with Room EQ Wizard (REW), with the interface's own noise floor measured and reported. ### Music Storage and Playback Subsystem A removable microSD card stores the music library. Users copy songs onto the card with a computer and insert it into the player. The required format is stereo, 16-bit, 48 kHz PCM WAV, which keeps decoding overhead low. The card is accessed through the SDMMC peripheral in 4-bit mode with the FatFs file system (FAT32 and exFAT). The processor reads ahead into a buffer and supports track selection, play/pause, and previous/next. Files in unsupported formats are skipped, and a message is shown on the display. The same subsystem supports the offline evaluation mode, which writes processed WAV files back to the card. Components: - microSD card socket and removable card - SD interface pull-up resistors and local decoupling - FatFs file-system software, WAV header parser, and buffered playback Requirements: - Read-ahead buffer of at least 500 ms of audio - Library of at least 500 tracks, with file names up to 64 characters - Zero underruns caused by storage during the 60-minute playback test ### User Interface Subsystem A rotary wheel and physical buttons control the player without a phone. Depending on the selected menu, the wheel scrolls through tracks and listening goals, adjusts volume, or sets EQ strength. The OLED shows the track name, active goal, strength, battery status, and the current gain of each of the five EQ bands, so the adaptation is visible during use and during the demo. A bypass button switches between adaptive EQ and unprocessed playback with a 50 ms crossfade. Bypass output is level-matched to the EQ path so the comparison is not biased by loudness. Components: - Incremental rotary encoder with push switch and wheel - Play/pause, previous/next, and EQ bypass buttons - 128 × 64 OLED display with SSD1306 controller (SPI) - Button pull-ups, RC debounce where needed, and enclosure hardware Requirements: - Every control input is reflected on the display within 100 ms. - No missed or double-counted encoder steps at rotation speeds up to 3 detents per second. ### Power Subsystem A protected single-cell lithium-ion polymer battery powers the player. It charges from a 5 V USB-C input. A BQ24074 linear charger with power-path management handles charging and shares input power with the system. The USB-C port uses 5.1 kΩ CC pull-down resistors, and input current is limited to 500 mA, which any compliant source supports by default. Charge current is set to no more than 0.5C of the chosen cell. An NTC thermistor on the charger's TS pin blocks charging outside the cell's temperature window. A TPS63070 buck-boost regulator produces 3.6 V across the full battery range. Two LDOs derive the final rails: a TLV75733P for the digital 3.3 V rail and a TPS7A2033 low-noise LDO for the analog 3.3 V rail. The LDO stage keeps switching ripple off the audio supply. The regulator will be placed and filtered to minimize coupling into the headphone output. A battery-voltage divider to an ADC input provides a low-battery warning at 3.5 V and a controlled shutdown at 3.3 V. Controlled shutdown mutes audio, closes open files, and turns off the regulator. Our preliminary power estimates, which will be replaced with measurements from the first board, are: - STM32H743 running the audio pipeline and inference: 100 to 160 mA on the digital rail - microSD card, averaged during playback: 20 to 40 mA on the digital rail - SSD1306 OLED: 10 to 25 mA on the digital rail - PCM5102A DAC: 10 to 15 mA on the analog rail - TPA6132A2 amplifier with 32 Ω headphones: 5 to 15 mA on the analog rail The estimated total is 145 to 255 mA at 3.3 V, or about 0.5 to 0.85 W. At about 85% conversion efficiency, the battery supplies roughly 0.6 to 1.0 W. A cell of at least 1,200 mAh (about 4.4 Wh) therefore gives an estimated 4.4 to 7 hours of playback, which leaves margin above the 3-hour requirement. The final capacity will be chosen after measuring the first board. Components: - Protected 3.7 V nominal lithium-ion polymer cell (at least 1,200 mAh, final capacity after power measurements) - Texas Instruments BQ24074 charger with NTC temperature sensing - Texas Instruments TPS63070 buck-boost regulator - Texas Instruments TLV75733P (digital) and TPS7A2033 (analog) LDOs - USB-C connector, CC resistors, and input TVS protection - Power switch, battery connector, voltage-sensing divider, inductors, and capacitors ## Additional Features (if time allows) ### Typed Description Control Users can enter short descriptions such as "a little more bass" or "less sharp" with an on-screen character selector operated by the wheel. A small onboard intent classifier maps supported phrases to a listening goal and strength. Unrecognized requests prompt the user to pick a supported goal. This feature does not require a cloud language model. Components: - On-screen text-entry interface using the existing controls - Compact intent classifier and supported phrase vocabulary ### Additional Audio Formats If processing and memory allow, we will add FLAC playback and 44.1 kHz support. These additions will be tested with adaptive EQ enabled to confirm that decoding and sample-rate changes do not interrupt playback. ### Supplementary Blinded Listening Check As supporting evidence only (not a success criterion), we may run a blinded, loudness-matched A/B comparison between the adaptive controller and the best fixed preset with volunteer listeners who are not on the team. ## Criterion For Success ### Core player 1. **Reliable playback:** Plays stereo, 16-bit, 48 kHz WAV files from microSD for 60 continuous minutes on battery with AI EQ enabled. UART logs must show zero resets, zero buffer underruns, and zero inference deadline misses, with gains updating ten times per second and every inference finishing within 50 ms. 2. **Standalone control:** Track navigation, play/pause, volume, all three listening goals, EQ strength, and bypass all work through the wheel and buttons, with no phone or computer. Each input is reflected on the display within 100 ms. 3. **Output quality:** At the headphone jack into 32 Ω with EQ bypassed, the player measures a frequency response within ±1 dB from 20 Hz to 20 kHz, THD+N below 0.1% at 1 kHz and 0.2 Vrms, and at least 90 dB A-weighted dynamic range. 4. **Battery and thermal:** Plays for at least 3 hours with AI EQ enabled at a fixed volume setting that produces 0.2 Vrms for a −12 dBFS 1 kHz tone. Recharges from a 5 V USB-C source while drawing no more than 500 mA. All ICs stay within their rated temperatures, and the board surface stays below 45 °C during playback and charging. ### AI equalization 5. **Outperforms the best fixed preset (primary AI criterion):** For **each** of the three goals, on the 100-track held-out test subset processed on the device at full strength, the neural controller must: - achieve a mean tonal-balance error at least **20% lower** than the best fixed preset; - achieve lower error than the preset on at least **65 of the 100 tracks**; and - show a statistically significant improvement (one-sided Wilcoxon signed-rank test, **p < 0.01**). We will also report the oracle upper bound, the causal rule-based controller, and host-simulation results on the full 300-track test split. 6. **Content-dependent adaptation:** On spliced test clips that join two held-out passages whose band levels differ by at least 4 dB in the goal's primary band, the controller's gain in that band moves at least 1 dB toward its new steady-state value within 1 second of the splice, with continuous playback. Across the test subset, the primary-band gain must also vary with a standard deviation of at least 1 dB between segments, confirming that the output is not effectively constant. 7. **Safe, click-free transitions:** Across the evaluation playlist and 100 goal and bypass changes, processed peaks never exceed the −1 dBFS limiter ceiling. Logged gain trajectories show no step larger than 0.05 dB between 1 ms coefficient updates, and bypass crossfades last at least 50 ms. No playback interruption occurs. 8. **The evaluation represents the real device:** On-device quantized gains match the floating-point host model within 0.25 dB RMS on the validation split. Live-playback CRC-32 logs match offline evaluation mode exactly on 10 tracks. Analog recordings of those tracks reproduce the digital error reduction within 5 percentage points. ## Development Plan Work on the AI component starts in parallel with the hardware, and a go/no-go checkpoint is placed before board integration. - **Weeks 1–2:** On the hardware side, we will complete the schematic and part selection and bring up audio and power on a development board with a DAC breakout. On the AI side, we will download the dataset, create the artist-disjoint splits, and commit the frozen targets, split hashes, metric code, and thresholds. We will then compute the best fixed presets and the oracle labels. - **Weeks 3–4:** We will lay out the PCB and place the first-round order. In parallel, we will train the first model and run host simulation on the validation split. **Checkpoint:** the model must show at least a 30% error reduction versus the best fixed preset on validation for all three goals, which leaves margin above the 20% test requirement. - **Weeks 5–6:** We will assemble the board and measure power, noise, and audio output. In parallel, we will run quantization-aware training, port the model to the STM32, and check that the quantized model matches the floating-point model. - **Weeks 7–8:** We will make second-round PCB fixes and build the enclosure. In parallel, we will integrate real-time playback, the offline evaluation mode, and CRC equivalence logging. - **Weeks 9–10:** We will run battery runtime and thermal tests. In parallel, we will run the final on-device test-set evaluation (once), perform the analog confirmation, and work on stretch features. - **Weeks 11–12:** We will complete final measurements, prepare the demo, and write the final report with all baseline comparisons. |
||||||