Project

# Title Team Members TA Documents Sponsor
10 OmniSense-Dual — Dual-Wearable 360° Blind-Spot Detection, Directional Haptic Hazard Alerts, and Belly-Based Navigation for Pedestrian Safety
Alex Jin
Jiateng Ma
Simon Xia
Team Members:
- Simon Xia (hx17)
- Jiateng Ma (jiateng4)
- Alex Jin (jin50)

**1. Problem Statement**
Pedestrians in urban and campus environments frequently share space with bicycles, e-scooters, cars, and other pedestrians approaching from all directions. Unlike drivers, who benefit from mirrors and active driver-assistance systems, pedestrians have:
- Unprotected blind spots
Fast-approaching objects from behind or from diagonal sectors are often perceived too late, especially on shared bike/pedestrian paths and narrow sidewalks.
- Reduced situational awareness
Headphones, smartphones, and other distractions degrade auditory and visual awareness, making it harder to detect hazards or notice subtle visual cues.
- Navigation burden
Outdoor and indoor navigation typically depend on visually checking a smartphone map or listening to voice guidance. Both approaches demand attention, occupy hands or ears, and can themselves be unsafe in traffic or crowded environments. For visually impaired users, relying solely on audio is also not ideal.

Existing systems (smartphone maps, voice navigation, cycling radars, blind canes) each address part of the problem but do not provide integrated 360° safety sensing plus hands-free navigation with clear separation of meaning.

**2. Solution Overview**
We propose OmniSense-Dual, a dual-wearable system consisting of:
- A waist/belly-mounted sensing, compute, and navigation haptic module, and
- A head-mounted sensing + haptic hazard alert module

Key design choice:
- Head channel = hazard alerts only
- Belly channel = navigation cues only

This cleanly separates “something is dangerous around you” from “where you should go.”

Core functions:

- 360° Blind-Spot Hazard Awareness
The belly module uses mmWave and ToF/ultrasonic sensors to detect approaching objects around the torso. The head module provides an additional sensing plane for head-level obstacles. When a hazard is detected, the headband vibrates on the corresponding side/direction, signaling an urgent warning.
Hands-Free Navigation
- A smartphone app provides waypoints (outdoor via GPS; optionally indoor via BLE/UWB). The belly module fuses waypoints with IMU heading and encodes navigation instructions as gentle vibration patterns on the belly module (e.g., left side of belt = turn left soon). Navigation never uses the head motors, so it cannot be confused with hazard alerts.

OmniSense-Dual is designed for campus walking, urban commuting, and accessibility support, with a strong emphasis on non-visual, non-auditory, and clearly distinguishable feedback.

**3. Solution Components**
**Component A: Waist/Belly Perception & Compute Module**
Placement:
Worn around waist or belly using elastic belt.
Sensors:
- Rear + Rear-Diagonal (L/R): mmWave radar (60 GHz)
- Left + Right: ToF (e.g., VL53 series) or ultrasonic
- Front-Lower: ToF/IR for low obstacles (curbs, poles, steps)

Functions:
- Provides 360° sensing at waist plane
- Detects moving vs static obstacles
- Includes 6-DoF IMU for heading + gait
- Includes battery + charger + regulators
- Belly haptics used only for navigation

**Component B: Head-Mounted Hazard Alert Module**
Placement:
Headband, cap insert, or lightweight strap.
Haptic Feedback:
8 directional motors placed at:
- Front (0°)
- Front-Left (45°)
- Left (90°)
- Rear-Left (135°)
- Rear (180°)
- Rear-Right (225°)
- Right (270°)
- Front-Right (315°)

Electronics:
- Small BLE SoC/MCU
- Optional short-range ToF for head-height obstacles
- Small battery or wired power from belt

Role:
- Only hazard alerts
- No navigation patterns

**Component C: Navigation & Belly Haptic Interface**
Input Source:
Phone provides route via GPS (outdoor) or BLE/UWB (indoor).
Processing on Belt Module:
- Receives desired bearing from phone
- Computes angle difference using IMU
- Triggers haptic cue on belt

**Component D: Safety Hazard Logic**
Inputs:
- mmWave + ToF/ultrasonic
- Optional head ToF
- IMU heading

Hazards Detected:
- Approaching fast objects (bike, scooter)
- Sudden close static obstacles
- Rear or diagonal intrusion
- Low objects in walking path

Head Feedback Patterns (Hazard Only):
- Default hazard → strong 0.5–1.0s pulse in correct motor direction
- High severity → repeated strong pulses
- Multiple hazards → priority by time-to-collision

**Component E: Electronics & PCB**
Belly PCB Includes:
- MCU (e.g., STM32H7 or ESP32-S3)
- Sensor interfaces (mmWave, ToF, IMU)
- BLE for phone + headband
- Haptic drivers for belt motors
- Li-ion charging + regulation

Head PCB Includes:
- BLE SoC (e.g., nRF52832/ESP32-C3-Mini)
- 8 motor drivers (directional)
- Optional ToF
- Small battery or connector

**4. Criterion for Success**
Safety
- Detect bikes/scooters ≥ 5 m away with ≥90% recall
- Head direction correctness ≥90%
- Alert latency ≤250 ms
- Dual-plane sensing reduces occlusion misses ≥30%

Navigation
- Turn accuracy using belly haptics ≥85%
- Heading deviation during “straight” ≤10°
- Navigation update latency ≤200 ms

Channel Separation
- Head = hazard, belly = navigation
- User classification accuracy (hazard vs nav) ≥90%

Usability
- Battery life ≥4 hours
- Total mass ≤350 g (head ≤150 g)

Control System and User Interface for Hydraulic Bike

Iain Brearton

Featured Project

Parker-Hannifin, a fluid power systems company, hosts an annual competition for the design of a chainless bicycle. A MechSE senior design team of mechanical engineers have created a hydraulic circuit with electromechanical valves, but need a control system, user interface, and electrical power for their system. The user would be able to choose between several operating modes (fluid paths), listed at the end.

My solution to this problem is a custom-designed control system and user interface. Based on sensor feedback and user inputs, the system would change operating modes (fluid paths). Additionally, the system could be improved to suggest the best operating mode by implementing a PI or PID controller. The system would not change modes without user interaction due to safety - previous years' bicycles have gone faster than 20mph.

Previous approaches to this problem have usually not included an electrical engineer. As a result, several teams have historically used commercially-available systems such as Parker's IQAN system (link below) or discrete logic due to a lack of technical knowledge (link below). Apart from these two examples, very little public documentation exists on the electrical control systems used by previous competitors, but I believe that designing a control system and user interface from scratch will be a unique and new approach to controlling the hydraulic system.

I am aiming for a 1-person team as there are 6 MechSE counterparts. I emailed Professor Carney on 10/3/14 and he thought the general concept was acceptable.

Operating modes, simplified:

Direct drive (rider's pedaling power goes directly to hydraulic motor)

Coasting (no power input, motor input and output "shorted")

Charge accumulators (store energy in expanding rubber balloons)

Discharge accumulators (use stored energy to supply power to motor)

Regenerative braking (use motor energy to charge accumulators)

Download Competition Specs: https://uofi.box.com/shared/static/gst4s78tcdmfnwpjmf9hkvuzlu8jf771.pdf

Team using IQAN system (top right corner): https://engineering.purdue.edu/ABE/InfoFor/CurrentStudents/SeniorProjects/2012/GeskeLamneckSparenbergEtAl

Team using discrete logic (page 19): http://deepblue.lib.umich.edu/bitstream/handle/2027.42/86206/ME450?sequence=1