vinodtech
Case Studies

Hands-Free Door Access System

Hands-free, multi-modal accessible door activation for users who cannot press a physical button.

Hands-Free Door Access System

Hands-free door activation for accessibility users who cannot press traditional push buttons.

  • ESP32-based system triggers a relay wired in parallel with the existing door button.
  • Multi-modal sensing with safety logic (debounce, cooldown, confirmation window).
  • Local CSV logging plus optional Google Sheets export for monitoring and audits.

Metrics Targets
False activation rate target: TBD
Miss rate target: TBD
Median latency target: TBD
Uptime target: TBD

Problem & Accessibility Context

Users with limited mobility often cannot press physical accessibility buttons. The goal is a hands-free, multi-modal door activation system that safely assists users without compromising existing door functionality or safety compliance.

Key constraints:

  • Must not break or alter the existing button behavior.
  • Must avoid false activations and accidental openings.
  • Must provide traceable logs for monitoring and improvement.

Requirements

Hard constraints

  • ESP32 (PlatformIO).
  • Relay wired in parallel with existing accessible button.
  • Safety logic: debounce, cooldown, confirmation window.
  • Existing button must always work.
  • Local CSV logging; optional Google Sheets logging via Apps Script.

Measurable metrics

  • False activation rate: TBD
  • Miss rate: TBD
  • Median latency: TBD
  • Uptime target: TBD

System Architecture

flowchart LR
  User([User Presence]) --> Sensor[Multi-Modal Sensor<br/>(ToF/IR/Switch)]
  Sensor --> MCU[ESP32 Controller]
  MCU --> Logic[State Machine<br/>Debounce + Cooldown + Confirm]
  Logic --> Relay[Relay (Parallel to Button)]
  Relay --> Door[Door Operator]
  MCU --> Log[CSV Logger]
  Log --> Sheet[Optional Google Sheets]

Hardware

  • MCU: ESP32 (PlatformIO).
  • Sensors: ToF/IR and/or accessibility switch input (multi-modal).
  • Actuation: Relay wired in parallel with existing door button.
  • Power: Regulated 5V/3.3V supply with protection.
  • Enclosure: Secure, accessible mounting near door.

Firmware

  • PlatformIO structure: src/, include/, lib/, test/
  • State machine: idle → detect → confirm → trigger → cooldown
  • Debounce: filter noisy sensor readings.
  • Confirmation window: prevent accidental activation from transient events.
  • Fail-safe: relay default off, watchdog recovery on fault.

Safety & Risk Controls

  • False opens: confirmation window + multi-modal verification.
  • Missed opens: configurable sensitivity and timeout.
  • Stuck sensor: watchdog + error code + safe disable.
  • Power loss: relay off by default; button still functional.
  • Relay failure: detection via error logging and fallback.

Logging & Telemetry

  • Local CSV: stored on device or attached storage.
  • Optional Google Sheets: Apps Script endpoint for periodic uploads.

CSV schema (example)

timestamp, device_id, sensor_type, raw_value, filtered_value, decision, relay_state, latency_ms, cooldown_active, error_code

Test Plan

| Test ID | Scenario | Metric | Pass Criteria | |--------|----------|--------|---------------| | T01 | Normal activation | Latency | TBD ms | | T02 | No user present | False activation rate | TBD | | T03 | Sensor noise | Miss rate | TBD | | T04 | Cooldown enforcement | Double-activation prevention | 0 unintended triggers | | T05 | Power loss recovery | Uptime | TBD |

Results

  • Median latency: TBD
  • False activation rate: TBD
  • Miss rate: TBD
  • Uptime: TBD

Build Notes

  • Next iteration: refine sensor fusion to reduce false positives.
  • What I’d change: add adaptive thresholding based on environment.
  • Future upgrade: BLE diagnostics for mobile debugging.

Repo Links

  • Schematic: TBD
  • Firmware folder: TBD
  • Test logs: TBD

Appendix: CSV Schema + Label Definitions

  • timestamp: ISO-8601 timestamp (UTC)
  • device_id: unique device identifier
  • sensor_type: e.g., IR, ToF, switch
  • raw_value: unfiltered sensor reading
  • filtered_value: filtered sensor reading
  • decision: idle / confirm / trigger / cooldown
  • relay_state: on / off
  • latency_ms: time from detection to trigger
  • cooldown_active: true / false
  • error_code: 0 or specific fault code
ScheduleCall