Project

# Title Team Members TA Documents Sponsor
68 Insole Pressure Sensing System for Running
Aarush Sivanesan
Joseph Casino
Matthew Weng
Xiaodong Ye design_document1.pdf
proposal1.pdf
Members:
Joseph Casino (jcasino2)
Aarush Sivanesan (aarush2)
Matthew Weng (mw87)

# Problem
Runners often develop injuries or inefficient running form due to high impact forces, poor foot-strike mechanics (heel vs midfoot), asymmetrical loading, or inconsistent cadence. Most runners do not have an easy way to measure how their foot actually loads the ground over time, since gait labs and force-sensing soles are expensive and geared towards physical therapy, research, or professional athletics. Existing consumer wearables estimate cadence using wrist/hip motion, but do not directly measure foot-ground pressure/impact. There is a need for a low-profile, shoe-integrated system that can quantify foot impact and pressure distribution during real runs while remaining comfortable, lightweight, and accessible to everyday runners.

# Solution
We propose a thin-film pressure sensor insole system for running shoes that measures the force applied by the foot to the ground throughout each stride. A flexible sensor array embedded on top of the shoe foam (or placed under the insole) will capture pressure through the foot’s main contact points (forefoot, heel, and midfoot). A small electronics module will attach to the shoe heel or tongue and contain MCU, battery, and Bluetooth modules. The MCU will sample the pressure sensors, detect foot-strike events, and compute basic metrics such as step count, cadence, contact time, and estimated distance (using cadence/stride-length calibration and optional IMU/GPS data). Data will be streamed over Bluetooth Low Energy (BLE) to a phone for visualization, logging, and further analysis.

# Solution Components

**Subsystem 1: Thin-Film Pressure Sensor Insole Array**

This subsystem senses foot pressure at key regions of the shoe to capture impact patterns and pressure distribution during stance. The sensor insole would fit either on top or bottom of the foam insole of the shoe.

Components:
- Thin-film force sensors (multiple locations): Interlink Electronics FSR 402
- Flexible interconnect/cabling: FFC/FPC cable (0.5 mm pitch) (generic)
- Connector (board-side): Molex 503480-0490 (4-pos FFC/FPC connector) (size can be adjusted based on channel count)

**Subsystem 2: Analog Front-End + ADC Data Acquisition**

This subsystem converts each sensor data to data that can be read to the MCU. To sample all the sensors on the foot, we sample between all the sensors with a MUX. We then properly filter and amplify the data from the sensor through the op-amp. This data then gets digitized through an ADC.

Components:
- 16-bit ADC: MCP3425A0T-E/CH
- Analog multiplexer: CD74HC4067SM96
- Op-amp: TLV9062IDR

**Subsystem 3: Microcontroller + BLE Wireless Telemetry**

This subsystem houses our MCU which will control sampling,collect data, timestamp data, and transmit results via BLE.

Components:
- MCU module: ESP32-C3-WROOM-02
- Programming/debug interface: Tag-Connect TC2030-IDC

**Subsystem 4: Optional Motion Sensing (IMU)**

This extra subsystem provides accelerometer/gyro data to gather speed data, estimate and improve stride data and length, and improve cadence robustness when the pressure signals are noisy.

Components:
- 6-axis IMU: ST LSM6DSOXTR or equivalent

**Subsystem 5: Power Management + Charging**

This subsystem powers the in-shoe electronics safely and supports rechargeable operation if applicable. The design regulates battery voltage to stable rails for the MCU and sensors. We have a wide range of batteries that we would like to work with initially to weigh out the pros and cons of each.

Components:

Battery options:
- 3.7V Li-Po (300–500 mAh)
- 3V Coin Battery
- AAA Alkaline Battery
- BMS IC for Li-Po : MCP73831T-2ACI/OT
- 3.3V regulator : MCP1700T-3302E/TT

**Subsystem 6: Phone Interface / Data Visualization**

This subsystem provides the wireless interface between the device and a smartphone or website which displays metrics to the runner and logs sessions. Initial versions can use a simple BLE GATT service viewed in a standard BLE app; a custom website or phone UI can be added if time permits.

Components:
- BLE GATT profile (firmware-defined)
- Prototype viewer: nRF Connect app or alternative

# Criterion For Success

Efficiency: The system shall sample plantar pressure sensor data at a minimum rate of 100 Hz and transmit the data over Bluetooth Low Energy with no more than 5% packet loss during continuous operation.

Accuracy: The system shall detect foot-strike events and report running cadence with an accuracy of ±3 BPM compared to a stopwatch or smartwatch reference over a controlled running trial.

Continuity/Longevity: The device shall operate continuously for at least 1 hour on battery power while performing active sensing and BLE data streaming.

Microcontroller-based Occupancy Monitoring (MOM)

Vish Gopal Sekar, John Li, Franklin Moy

Microcontroller-based Occupancy Monitoring (MOM)

Featured Project

# Microcontroller-based Occupancy Monitoring (MOM)

Team Members:

- Franklin Moy (fmoy3)

- Vish Gopal Sekar (vg12)

- John Li (johnwl2)

# Problem

With the campus returning to normalcy from the pandemic, most, if not all, students have returned to campus for the school year. This means that more and more students will be going to the libraries to study, which in turn means that the limited space at the libraries will be filled up with the many students who are now back on campus. Even in the semesters during the pandemic, many students have entered libraries such as Grainger to find study space, only to leave 5 minutes later because all of the seats are taken. This is definitely a loss not only to someone's study time, but maybe also their motivation to study at that point in time.

# Solution

We plan on utilizing a fleet of microcontrollers that will scan for nearby Wi-Fi and Bluetooth network signals in different areas of a building. Since students nowadays will be using phones and/or laptops that emit Wi-Fi and Bluetooth signals, scanning for Wi-Fi and Bluetooth signals is a good way to estimate the fullness of a building. Our microcontrollers, which will be deployed in numerous dedicated areas of a building (called sectors), will be able to detect these connections. The microcontrollers will then conduct some light processing to compile the fullness data for its sector. We will then feed this data into an IoT core in the cloud which will process and interpret the data and send it to a web app that will display this information in a user-friendly format.

# Solution Components

## Microcontrollers with Radio Antenna Suite

Each microcontroller will scan for Wi-Fi and Bluetooth packets in its vicinity, then it will compile this data for a set timeframe and send its findings to the IoT Core in the Cloud subsystem. Each microcontroller will be programmed with custom software that will interface with its different radio antennas, compile the data of detected signals, and send this data to the IoT Core in the Cloud subsystem.

The microcontroller that would suit the job would be the ESP32. It can be programmed to run a suite of real-time operating systems, which are perfect for IoT applications such as this one. This enables straightforward software development and easy connectivity with our IoT Core in the Cloud. The ESP32 also comes equipped with a 2.4 GHz Wi-Fi transceiver, which will be used to connect to the IoT Core, and a Bluetooth Low Energy transceiver, which will be part of the radio antenna suite.

Most UIUC Wi-Fi access points are dual-band, meaning that they communicate using both the 2.4 GHz and 5 GHz frequencies. Because of this, we will need to connect a separate dual-band antenna to the ESP32. The simplest solution is to get a USB dual-band Wi-Fi transceiver, such as the TP-Link Nano AC600, and plug it into a USB Type-A breakout board that we will connect to each ESP32's GPIO pins. Our custom software will interface with the USB Wi-Fi transceiver to scan for Wi-Fi activity, while it will use the ESP32's own Bluetooth Low Energy transceiver to scan for Bluetooth activity.

## Battery Backup

It is possible that the power supply to a microcontroller could fail, either due to a faulty power supply or by human interference, such as pulling the plug. To mitigate the effects that this would have on the system, we plan on including a battery backup subsystem to each microcontroller. The battery backup subsystem will be able to not only power the microcontroller when it is unplugged, but it will also be able to charge the battery when it is plugged in.

Most ESP32 development boards, like the Adafruit HUZZAH32, have this subsystem built in. Should we decide to build this subsystem ourselves, we would use the following parts. Most, if not all, ESP32 microcontrollers use 3.3 volts as its operating voltage, so utilizing a 3.7 volt battery (in either an 18650 or LiPo form factor) with a voltage regulator would supply the necessary voltage for the microcontroller to operate. A battery charging circuit consisting of a charge management controller would also be needed to maintain battery safety and health.

## IoT Core in the Cloud

The IoT Core in the Cloud will handle the main processing of the data sent by the microcontrollers. Each microcontroller is connected to the IoT Core, which will likely be hosted on AWS, through the ESP32's included 2.4GHz Wi-Fi transceiver. We will also host on AWS the web app that interfaces with the IoT Core to display the fullness of the different sectors. This web app will initially be very simple and display only the estimated fullness. The web app will likely be built using a Python web framework such as Flask or Django.

# Criterion For Success

- Identify Wi-Fi and Bluetooth packets from a device and distinguish them from packets sent by different devices.

- Be able to estimate the occupancy of a sector within a reasonable margin of error (15%), as well as being able to compute its fullness relative to that sector's size.

- Display sector capacity information on the web app that is accurate within 5 minutes of a user accessing the page.

- Battery backup system keeps the microcontroller powered for at least 3 hours when the wall outlet is unplugged.

Project Videos