Third Eye Kit, Envisioned v2

A wearable that lets a blind person feel the world in real time, instead of waiting to be told.

Project Lead & Engineer: Said Mohaddes Sadeqi, Hillsboro, Oregon, USA Document type: Full technical + clinical design dossier (public) Status: v1 is a tested prototype. v2 (this document) is a design & reference specification, an engineering blueprint, not a finished or certified product.

Mission, "They deserve more." Blind and visually impaired people have been handed a pile of tools that don't work together and aren't safe on a real road. This project is built for the capable, long-overlooked person, not the low bar the world settled for.

North-star, "Feel, don't wait." The world must reach the person through the body, by feel, instantly, never through a slow voice that arrives after the moment has passed. Every design choice is judged against this.

⚠️ Status & Safety Disclaimer (read before publishing or building)

Third Eye Kit is an in-progress research and engineering project. v1 is a tested prototype; the v2 system described here is a design and reference specification that has NOT been clinically validated and is NOT a certified medical device. The powered exoskeleton, the hot-surface warning, and the health features are novel and unproven and MUST pass the staged safety validation in Section 11 before any person relies on them. Nothing here is medical advice. Any build or trial must happen under appropriate technical and clinical supervision. The mobility aid and the user's own hearing remain primary at all times, this system augments them, it does not replace them.

Table of contents

1. What this is
2. The problem & the market gap
3. Project history (v1 → v2)
4. Founding design rules
5. System overview
6. Architecture & the safety isolation boundary
7. Subsystems in detail (parts, wiring, code)
8. Electronics & wiring (master scheme + tables)
9. Software & code (languages, why, reference implementations, build steps)
10. The trainer game & city simulator
11. Health, safety & clinical validation
12. Regulatory pathway
13. Bill of materials
14. Build roadmap
15. For the team (repo, contribution, publishing)
16. Honest limits & open questions
17. Glossary
18. References
19. License

1. What this is

Third Eye Kit is a single, integrated, wearable mobility system for blind and low-vision people. It has three jobs:

1. Sense the world with direct physical measurement (lasers, radar, ultrasonic, hand and foot sensors), never guesswork.
2. Deliver that world into the body instantly through a full-body "buzz-language" of gentle vibration, plus a gently-steering exoskeleton, so the person feels and is guided in real time.
3. Assist with an AI that reads signs, names things, and helps with routes, but that never becomes "the eyes" and never steers.

Around that core sit the supporting parts: scanning gloves for indoor and manual exploration, a hot/cold-surface warning, a health & emergency bracelet, live city navigation, and a training game.

The one idea that makes this different from everything on the market: almost everyone invests in the "robot eyes" (camera + AI) and almost no one invests in the human input channel, how the information actually gets into the person fast enough to act on. That input channel is this project's invention.

2. The problem & the market gap

A blind or visually impaired person today juggles several single-purpose tools that don't talk to each other:

• Mobility aid, reliable ground contact, but misses everything above knee height, and gives only "something's there," not what it is.
• AI glasses (Envision, Meta Ray-Ban-based, OrCam, etc.), read text and describe scenes, but the research is blunt: they lack depth sensing and the sub-500 ms latency safe walking needs, miss glass, can mask traffic sounds, and must still be used with a mobility aid.
• Self-guiding robots (Glidance "Glide") and AI wearables (biped.ai "NOA"), the most advanced tier, but Glide is a wheeled robot you push beside you (not worn), and most of these remain prototypes.
• Apps (BlindSquare, Lazarillo, GoodMaps, Soundscape successors, Seeing AI, Oko) and human services (Aira, Be My Eyes), helpful, but can be wrong and must supplement the mobility aid.

The gap: not one of these is a road-safe, worn, all-in-one system, and none solves the input-channel problem, getting rich spatial information into the body faster than words. That is the space Third Eye Kit is built for.

3. Project history (v1 → v2)

v1, the first prototype (built & field-tested). A low-cost, decentralized obstacle-detection and family-location wearable:

• Four small microcontrollers, each owning a job in hard real time, so a slow task (like sending a text) could never freeze the fast task (ranging).
• Ultrasonic ranging at head/upper level and lower/shoe level; simple haptic and audible alerts; an LDR/LED light aid.
• A GPS + GSM node that could text a family member the wearer's location.
• Designed to fail silent and be repairable with basic parts.

The pivot, what field testing taught us. The first prototype worked, and blind users were grateful. But testing with more advanced testers surfaced the real lesson: a voice telling you where to go is too slow and never precise enough for a real road. People don't want to wait to be told, they want to feel the world as it happens. That insight moved the project's center of gravity from the "robot eyes" to the human input channel, and is the reason for the full-body buzz-language and the exoskeleton.

v2, "Envisioned" (this document). The full redesign around "Feel, don't wait": a full-body haptic input channel, a warn-then-gently-steer exoskeleton, direct physics-based sensing, scanning gloves, a hot-surface warning, a health & emergency bracelet, live city navigation, an AI assistant kept strictly in an assisting role, and a training game, all integrated into one wearable system.

Changelog v1 → v2

4. Founding design rules

These are hard constraints. Every part of the design obeys them.

1. Life-critical = physics, not inference. "Is something in my path, how far, which side" is answered by direct measurement (ToF/LiDAR, radar, ultrasonic, sole/hand sensors, IMU), never by an AI guessing from a camera.
2. AI is an assistant only. It reads signs, names objects, describes scenes, helps with routes and context. It informs; it never has the wheel; it never steers.
3. Exoskeleton: warn → gently steer → never lock. A haptic warning first; then only a small, torque-capped, smooth nudge the wearer can always walk through; never a block or lock.
4. Fail transparent. On any fault, power loss, or the emergency stop, the motors drop to zero torque and freewheel. The failure mode is always "limp," never "trapped."
5. Real-time hardware isolation. The fast, safety-critical layers run on their own microcontrollers below an isolation boundary; the heavy best-effort layers (AI, maps, cloud) run above it and can never stall the safety layer.
6. Augment, not replace. Complements the mobility aid and the user's own hearing (ears-open, bone-conduction audio). Validated in stages before anyone relies on the powered guidance.
7. Not a health monitor. The health features are for emergency information and contact, not vitals monitoring or diagnosis.

5. System overview

Worn parts and what each does:

• Head unit, depth camera, multizone ToF, mmWave radar, IMU, bone-conduction audio.
• Haptic layer, a full-body web of small vibration motors ("buzzers"): the input channel.
• Compute + battery pack, the four control tiers and hot-swap batteries.
• Exoskeleton, partial powered hip + knee + ankle assist that gently steers.
• Shoes, downward ToF for drop-offs, curbs, and stairs.
• Gloves, hand-mounted scanner + palm haptics ("modern mobility aid") for indoor/manual exploration.
• Temperature guard, non-contact IR sensor that warns of hot/cold surfaces.
• Bracelet, emergency medical ID + family alert (with GPS).
• Radios, multi-mode cellular + GNSS for navigation and alerts.

6. Architecture & the safety isolation boundary

Four tiers. The rule: the more a layer is trusted with the person's life, the simpler and more deterministic it is.

                 FUSED SENSORS (depth cam, ToF, radar, IMU, sole, glove, temp)
                                        |
   ============================ BEST-EFFORT (above the line) ============================
   BRAIN  (NVIDIA Jetson Orin Nano Super, Linux)
     vision, object/scene AI, OCR, on-device assistant + speech, maps/routing
                                        |  (obstacle & terrain summaries, spoken prompts)
   SPINE  (STM32H7-class MCU, RTOS)
     arbitration, alert priority, haptic pattern sequencing, consent, telemetry
   ================== ISOLATION BOUNDARY, comms can never stall safety ==================
   REFLEX (STM32G4-class MCU, hard real-time <50 ms)      SAFETY-CRITICAL (below the line)
     close-range ranging, buzz-language drive, temp guard, watchdog, fault annunciation
                                        |  (CAN FD)
   EXO-MOTOR (STM32G4-class RT controller, >=1 kHz)
     gait-phase estimation, assist torque, gentle-steer torque (capped), fail-safe
                                        |
                 EXO ACTUATORS (hip / knee / ankle)   +   HAPTIC MOTORS + GLOVES

A stalled cloud call, a crashed AI model, or a hung map lookup above the line cannot freeze ranging, the buzz-language, or the motor loop below it. The powered actuators are themselves hard-real-time and therefore live below the boundary. Cross-boundary links are one-way command/telemetry (SPI/UART).

7. Subsystems in detail

Each subsystem below lists: what it does, the components (with example part numbers), how it wires in, and, for the critical ones, where the reference code lives (Section 9).

7.1 The full-body haptic input channel (the buzz-language)

What it does. A web of small vibration motors across the body. When something comes within ~1 meter, the motors nearest to it start a very gentle buzz that grows a little stronger, still gentle, as it gets closer. Direction = which zone buzzes; distance = intensity + rhythm; a distinct signature = a special warning (e.g., heat, or a drop-off).

Placement, grounded in how skin actually feels. Skin doesn't feel vibration equally everywhere. Two-point discrimination is ~1 to 5 mm on the fingertips but ~40 to 70 mm on the back and thighs, yet for vibration on the torso, people can distinguish buzzers spaced below ~13 mm. So: pack motors closer where the skin reads well (front torso, hands/wrists), space them out where it's coarse (back, thighs), the same "feel where things are" effect with far fewer motors, lighter and more comfortable. ~2-inch spacing on the torso is comfortably within what a person feels as separate points.

Body map (zones).

            [head/neck: overhead + forward high]
   [L shoulder]        [chest: dense]        [R shoulder]
   [L upper arm]       [belly: dense]        [R upper arm]
        [L forearm]     [lower back]     [R forearm]
              [L thigh]           [R thigh]
        (hands: see gloves)   (feet: sole warnings routed here)

Components. 16 to 28 linear resonant actuators (LRAs, crisper and more localizable than ERM motors); TI DRV2605L haptic drivers (one per group, addressed over I2C via a multiplexer); a soft, breathable garment carrier. Wiring. LRAs → DRV2605L drivers → I2C (through TCA9548A mux) → Reflex MCU. Driven by the Reflex tier so warnings survive even if everything above the boundary fails. Anti-habituation. Cues are sparse and meaningful; "funneling" (co-activating neighbors) raises perceived resolution above the physical motor count. Code. buzz_encode(), Section 9.

7.2 Direct sensing suite (the front door)

What it does. Physically measures the world reliably enough to stake safety on. No single sensor is trusted; they cover each other's blind spots.

Hazard coverage: drop-offs (sole ToF + depth), overhangs (head ToF + depth), glass (radar + ultrasonic, since cameras miss it), moving obstacles (radar + fast ToF). Code. nearest_mm() ranging loop, Section 9.

7.3 Scanning gloves, the "modern mobility aid" (NEW)

What it does. Turns the hand into a pointer/probe. A short-range, narrow-beam sensor on the back of the hand reads the distance to whatever the hand points at, and a small motor buzzes in the palm as the hand nears a surface or object, using the same buzz-language as the body. Ideal for indoor navigation and manual exploration: finding a doorway, a table edge, a handrail, a light switch, an empty seat.

Components (per glove). VL53L1X narrow-beam ToF (long, tight beam) or a small VL53L8CX; one LRA + DRV2605L in the palm; a small MCU (nRF52 / ESP32) with BLE to the main unit; coin battery or tether. Wiring. ToF → I2C → glove MCU → BLE → Spine (for logging/coordination); palm LRA driven locally so it works even standalone. Why it matters. Indoors, GPS and city data are useless; the gloves + sole sensors + body haptics carry the load. The glove is also the natural tool for reaching, the mobility aid can't tell you what your hand is about to touch. Code. glove_tick(), Section 9.

7.4 Temperature / hot-surface warning (NEW)

What it does. A non-contact infrared sensor checks the temperature of the surface the wearer (or their hand) is approaching, and warns, with its own distinct buzz signature so it's never confused with an obstacle, before touching a dangerously hot surface (stove, radiator, hot pavement, kettle) or a dangerously cold/icy one (frostbite, slip risk).

Components. MLX90614 (single-point IR thermometer) or MLX90640 (32×24 thermal array for a small heat "image"); mounted on the head unit and/or the glove. Wiring. MLX90614 → I2C → Reflex MCU (safety-critical, so it's on the fast tier). Thresholds (defaults, tunable): warn hot ≥ ~50 °C, warn cold ≤ ~-5 °C. Code. temp_check(), Section 9.

7.5 Health & emergency bracelet (NEW)

What it does. Two things, both about emergencies, not health monitoring:

1. Responder-readable medical ID. The bracelet carries an NFC tag and a printed QR that a first responder can tap/scan to read the wearer's stored conditions, medications, allergies, blood type, and emergency note, offline, with no app on their side.
2. Family alert. A dedicated SOS button texts allowlisted family members the wearer's condition summary and a live location link (extending v1's GPS + GSM alert). Works over cellular without internet.

Components. Small MCU (nRF52) with BLE; NFC tag (NTAG213/216); a physical SOS button; optional tiny e-ink or vibration confirmation; the main unit's cellular modem (Quectel BG95) + GNSS provide the alert path. Wiring. Bracelet MCU → BLE → Spine; SOS event → Spine → cellular modem (SMS) + GNSS (location). NFC/QR are static and read directly by responders. Boundaries & privacy. Not a diagnostic or vitals device. Only allowlisted numbers can be alerted; the wearer controls the profile; there is no remote path for anyone to silently pull location. Code. on_sos_pressed(), Section 9.

7.6 The exoskeleton (warn → gently steer → never lock)

What it does. Reduces walking fatigue and gently steers the wearer away from confirmed hazards, always after a haptic warning, always as a small nudge the wearer can walk through, never a lock.

Form factor. A partial powered exoskeleton (hip + knee + ankle assist) with a soft-goods interface, lighter and safer than a full rigid suit. Actuators. Quasi-direct-drive (QDD) units (e.g., CubeMars AK-series). QDD = high-torque motor + low-ratio gear, which makes them backdrivable, easy to push, so they freewheel/go limp on any fault instead of locking. Reference hip units are ~3.4 kg, ~17.5 Nm nominal with only ~0.4 Nm backdrive resistance, and hip assist has cut walking effort ~15%. The "never lock" rule is thus built into the hardware, not just the software. Control. Gait-phase estimation (IMU + encoders) → impedance/admittance assist → a small, torque-capped steer term added only when the sensors confirm a hazard and the wearer keeps heading in. Torque limits are hard bounds enforced locally. Bus & power. CAN FD to the actuators; a separate high-voltage actuator rail broken by a hardwired emergency-stop relay. Code. steer_torque(), Section 9. State logic, Section 8.

7.7 AI assistant (ears-open, with a hard line)

What it does (allowed). Reads signs and text (OCR), describes scenes, identifies shops/objects/faces the user has saved, narrates route and context, answers questions, and talks the user through a junction. On-device model + speech for offline core; cloud for richer help when there's signal. Audio. Bone-conduction so the ear canals stay open, a blind or visually impaired person's hearing is a primary sense and must never be sealed. The hard line (forbidden). It is never the life-critical eyes, and it never steers. A confirmed obstacle or drop-off cue always preempts whatever it's saying. Components. Runs on the Brain (Jetson); models via ONNX/TensorRT; speech via a Whisper-class ASR + TTS.

7.8 Live city-data navigation

What it does. Uses live city data as a bonus layer on top of the always-on sensor core.

• Sidewalks & crossings, from OpenStreetMap / OpenSidewalks / AccessMap. Coverage is rich in well-mapped cities and thin elsewhere, so we build the flagship for a well-mapped city and step down in tiers to sensors-only where data is absent.
• Traffic lights, both ways. Where a city runs a connected-signal program (e.g., NYC, Tampa), use its live walk/don't-walk timing (SPaT). Everywhere else, read the walk signal with the device's own camera (proven today by the Oko app) and lean on the audible signals already installed at many intersections.
• Consent. Location sharing is user-held and revocable; only allowlisted contacts; no covert remote activation.
• Radios. Multi-mode cellular (LTE-M/NB-IoT + 2G fallback, e.g., Quectel BG95) + GNSS (u-blox NEO-M9N) + offline maps. Safety rule. If there's no signal or no data, the safety core (sensors → buzz + exo) is unaffected, the city layer can drop out without breaking anything.

7.9 Power & thermal

• Batteries: hot-swappable LFP (lithium iron phosphate) packs, thermally safe and heat-tolerant; swap to last all day.
• Rails: a high-voltage actuator rail (the dominant, swinging load) + a separate logic rail; the actuator rail is cut by the hardwired e-stop relay.
• Thermal: ventilated compute housing; actuator duty-cycle limits; temperature derating in firmware.
• Budget (order of magnitude): exo actuators 20 to 120 W (dominant, varies with terrain), Jetson 7 to 25 W, sensors 3 to 8 W, haptics 0.5 to 4 W, radios 0.5 to 3 W, MCUs 1 to 3 W. Runtime must be measured, not just calculated.

8. Electronics & wiring

Master electronics / bus scheme

  SENSING (head)                                   BRAIN
  Stereo depth cam ---- MIPI CSI-2 -------------->  Jetson Orin Nano Super
  mmWave IWR6843 ------ USB ---------------------->   vision, AI, OCR, assistant,
  Head IMU ICM-42688 -- I2C ---------------------->   maps/routing
                                                        | UART (objects, prompts)
  RADIOS                                     SPINE       v
  Cellular BG95 ------- USB ------------------>  STM32H7 coordinator
  GNSS NEO-M9N -------- UART ----------------->    arbitration, consent, patterns
  Bracelet (nRF52) ---- BLE ----------------->     telemetry, SOS routing
  Gloves (nRF52 x2) --- BLE ----------------->
                                                        | SPI/UART (one-way)
  ===================== ISOLATION BOUNDARY =========================
                                                        v
  Body ToF (VL53L8CX) - I2C -->  REFLEX  --- I2C(mux) --> DRV2605L xN -> LRA motors (body)
  Sole ToF (VL53L7CX) - I2C -->  STM32G4        \
  Ultrasonic --------- I2C -->  safety MCU       `--> Temp guard MLX90614 (I2C)
  Glove ToF (VL53L1X)  (via BLE/Spine)  watchdog, <50 ms fault annunciation
                                                        | CAN FD (isolated)
                                                        v
  Joint encoders/IMU - CAN --> EXO-MOTOR --- CAN FD --> QDD actuators (hip/knee/ankle)
                                STM32G4 RT
                                     ^ hardwired enable line
  E-STOP (NC button) ==============>  Actuator-rail cutoff relay  (open = zero torque)
  LFP hot-swap pack ------------->  PDU: 48 V actuator rail + 5 V logic rail

Per-module connection tables

Haptic driver group

Multizone ToF (body / sole)

Exo actuator (per joint)

Temperature guard

Bracelet

Exoskeleton state logic (warn → steer → fail-safe)

  WALKING (assist on, no steering)
     | obstacle detected (sensors)
     v
  STAGE 1, HAPTIC WARNING (buzz the zone; NO physical push)
     | wearer keeps heading in
     v
  STAGE 2, GENTLE STEER (small, torque-capped nudge; wearer can walk through)
     | path clears  --> back to WALKING

  FAIL-SAFE FLOOR (reachable from ANY state):
     any fault / power loss / e-stop  -->  ZERO TORQUE, freewheel (never lock)

9. Software & code

Languages, and why

Note on "all the code." The complete, line-by-line codebase is a living repository grown module by module at build time, no single document can (or should) hold it all. What follows is real reference code for the critical modules, enough for the team to build outward from. Everything below reuses the same buzz-language, so what the gloves teach, the body confirms, and the trainer matches the real device.

The buzz-language encoder (Reflex MCU, C)

// buzz_encode.c, maps a zone distance to a haptic drive command.
// Life-critical layer: deterministic, no dynamic allocation.
#include <stdint.h>
#define WARN_START_MM 1000u   // begin gentle buzz at ~1.0 m
#define CONTACT_MM     150u   // treat as "at" the obstacle
#define PWM_MIN         40u   // gentlest perceptible amplitude (0-255)
#define PWM_MAX        200u   // firm but never alarming

typedef struct { uint8_t amplitude; uint8_t pulse_hz; } haptic_cmd_t;

haptic_cmd_t buzz_encode(uint16_t distance_mm) {
    haptic_cmd_t cmd = {0, 0};
    if (distance_mm >= WARN_START_MM) return cmd;          // silent beyond 1 m
    uint16_t d   = distance_mm < CONTACT_MM ? CONTACT_MM : distance_mm;
    uint32_t span = WARN_START_MM - CONTACT_MM;
    uint32_t near = WARN_START_MM - d;                     // 0 (far) .. span (near)
    cmd.amplitude = (uint8_t)(PWM_MIN + (near * (PWM_MAX - PWM_MIN)) / span);
    cmd.pulse_hz  = (uint8_t)(2 + (near * 6) / span);      // 2 Hz far -> 8 Hz near
    return cmd;
}

The ranging loop (Reflex MCU, C, ST ULD API)

// ranging_loop.c, read one multizone ToF sensor, return nearest valid distance (mm).
VL53L8CX_Configuration dev;
VL53L8CX_ResultsData   res;

void ranging_init(void) {
    vl53l8cx_init(&dev);
    vl53l8cx_set_resolution(&dev, VL53L8CX_RESOLUTION_8X8);
    vl53l8cx_set_ranging_frequency_hz(&dev, 15);
    vl53l8cx_start_ranging(&dev);
}

uint16_t nearest_mm(void) {
    uint8_t ready = 0;
    vl53l8cx_check_data_ready(&dev, &ready);
    if (!ready) return UINT16_MAX;
    vl53l8cx_get_ranging_data(&dev, &res);
    uint16_t best = UINT16_MAX;
    for (int z = 0; z < 64; z++)
        if (res.target_status[z] == 5 && res.distance_mm[z] < best) // 5 = valid
            best = res.distance_mm[z];
    return best;
}

The gentle-steer control (Exo-motor MCU, C)

// steer_control.c, assist + gentle steer with a HARD torque cap and fail-safe.
// Runs >=1 kHz. Never locks; freewheels on any fault.
#define TAU_CAP_NM  6.0f    // hard steer ceiling (well below destabilizing)
#define ASSIST_GAIN 0.15f   // fatigue-assist scale

extern bool  estop_pressed(void);   // hardwired line
extern bool  fault_present(void);   // watchdog / sensor / power
extern float hazard_bias(void);     // -1..+1 from Reflex; 0 = no hazard

float steer_torque(float assist_ref) {
    if (estop_pressed() || fault_present())
        return 0.0f;                          // FAIL TRANSPARENT: zero torque, freewheel
    float tau = ASSIST_GAIN * assist_ref + TAU_CAP_NM * hazard_bias();
    if (tau >  TAU_CAP_NM) tau =  TAU_CAP_NM; // clamp, the human always wins
    if (tau < -TAU_CAP_NM) tau = -TAU_CAP_NM;
    return tau;
}

The hot-surface guard (Reflex MCU, C)

// temp_guard.c, non-contact hot/cold surface warning (burn/frostbite prevention).
#define HOT_C   50.0f
#define COLD_C  -5.0f
float mlx90614_object_c(void);                 // IR object temp over I2C
typedef enum { TEMP_OK, TEMP_HOT, TEMP_COLD } temp_state_t;

temp_state_t temp_check(void) {
    float t = mlx90614_object_c();
    if (t >= HOT_C)  return TEMP_HOT;          // -> distinct heat buzz signature
    if (t <= COLD_C) return TEMP_COLD;
    return TEMP_OK;
}

The scanning glove (Glove MCU, C)

// glove_scan.c, hand-mounted ToF turns the hand into a probe; palm buzzes.
uint16_t glove_tof_mm(void);                   // hand VL53L1X (narrow beam), I2C
void     glove_lra(uint8_t amp, uint8_t hz);   // palm LRA via DRV2605L

void glove_tick(void) {
    haptic_cmd_t c = buzz_encode(glove_tof_mm()); // SAME language as the body
    glove_lra(c.amplitude, c.pulse_hz);
}

The emergency alert (paired module, Python)

# emergency_alert.py, SOS -> notify family + share location; responder-readable ID card.
def on_sos_pressed(profile, contacts, gps):
    # profile = {name, conditions, meds, allergies, blood_type, note}
    msg = (f"SOS from {profile['name']}. Conditions: {profile['conditions']}. "
           f"Allergies: {profile['allergies']}. Location: {gps.maps_link()}")
    for c in contacts:                 # allowlisted family only
        send_sms(c.number, msg)        # via cellular SIM, works without internet
    # First responders tap the NFC tag / scan the QR to read `profile` offline.

A trainer level (browser, TypeScript)

// level1.ts, "which side?" teaches the buzz-language with the REAL haptic pad.
async function playObstacle(pad: HapticPad, zone: Zone, distanceMm: number) {
  const { amplitude, pulseHz } = buzzEncode(distanceMm); // shared encoder
  await pad.buzz(zone, amplitude, pulseHz);              // Web Bluetooth
  speak(distanceMm < 300 ? "very close" : "approaching"); // audio, ears-open
}
// Player indicates the side -> score -> increase difficulty.

Build steps (developer quick-start)

1. Reflex/Exo/Spine firmware: install the ARM GNU toolchain + STM32Cube (or Zephyr); flash the reflex ranging+buzz firmware to an STM32G4 dev board with a VL53L8CX breakout; verify nearest_mm() and buzz_encode() drive an LRA.
2. Brain: flash the Jetson Orin Nano Super (JetPack); run the perception + assistant stack (Python venv, PyTorch → TensorRT, OpenCV).
3. Gloves/bracelet: build with ESP-IDF / nRF Connect SDK; pair over BLE to the Spine.
4. Trainer: npm install && npm run dev; connect the haptic pad via Web Bluetooth.
5. Simulator: install CARLA; run the bridge that feeds simulated sensor frames into the same buzz encoder.
6. Integration: bring up tiers bottom-up (Reflex → Exo → Spine → Brain); test the e-stop and fail-safe before any powered walking.

10. The trainer game & city simulator

Why. A game teaches the buzz-language safely and keeps people practicing, and research shows audio + haptic O&M games work and the skills transfer to real-world walking. It also doubles as the test tool.

For the user, an audio + touch training game. Graded levels on a phone/laptop with the real haptic pad, no eyes needed:

1. Which side?, identify the direction of a buzz.
2. How close?, judge distance from intensity/rhythm.
3. Find the gap, steer toward the safe opening.
4. Cross the street, a full simulated crossing.

For the engineers, a city test-simulator. A virtual Boston/NYC sidewalk (built on CARLA, the self-driving simulator) feeds simulated sensor data into the same real buzz encoder, so cues and street logic can be tuned safely, without hardware or going outdoors.

Rule. The game/sim reuses the same encoding as the device, but stays separate from the safety-critical firmware.

11. Health, safety & clinical validation

The exoskeleton, hot-surface warning, and health features are novel and must clear the staged milestone below before any person relies on them. Nobody has safely robot-steered a blind person's gait before; this is unproven.

Safety philosophy. Warn → gently steer → never lock. Fail transparent. Augment, not replace. The human always wins (the torque cap guarantees it). Nothing fails silently.

Hazard analysis (design-stage FMEA, excerpt).

Emergency systems. Hardwired normally-closed e-stop that cuts actuator power independent of firmware; watchdog → freewheel; undervoltage/over-temperature → zero torque. Agency & consent. The machine only ever biases, never compels; it warns before it acts (never a surprise); the wearer controls the whole capability, including location sharing, revocably. Training protocol (staged). (1) familiarization, seated, learn the buzz-language and assistant, no walking; (2) supervised assist walking with fall protection, no steer; (3) supervised gentle steer, controlled course; (4) independent graduation, mobility aid retained throughout. Led by an orientation-and-mobility (O&M) professional. Contraindications. Individualized clinical assessment required for certain balance, orthopedic, cardiovascular, cognitive, or skin conditions. Not validated for dense crowds or fast traffic.

Staged validation milestone, cleared in order before any blind user relies on the powered steer.

12. Regulatory pathway (orientation, not legal advice)

A powered wearable that physically assists and steers a person is very likely regulated as a medical device and a physical assistant robot; classification is jurisdiction-specific and must be confirmed with regulatory professionals. Design against, from day one: ISO 13482 (personal care / physical assistant robots), ISO 14971 (medical-device risk management), IEC 60601 (medical electrical equipment), IEC 62304 (medical-device software), ISO/TS 15066 (power-and-force-limiting concepts). Comparable powered exoskeletons (ReWalk, Ekso) reached market via medical-device clearance, a multi-year, evidence-intensive path. There is real product-liability and insurance exposure for a device that acts on a vulnerable user. The health/temperature features must avoid medical claims and carry disclaimers.

13. Bill of materials (advanced prototype)

This is the recommended path to a real, testable device fastest.

14. Build roadmap

1. Essentials bench build, body buzz-language + one ToF + temp guard on a laptop/dev board; prove nearest_mm → buzz_encode → LRA.
2. Wearable Essentials, full-body haptic garment + sole sensors + gloves + bracelet; field-test with users (no exoskeleton yet).
3. Trainer + simulator, ship the training game; stand up the CARLA test-sim.
4. Exoskeleton bench (G0), actuators, e-stop, fail-safe, torque caps on the bench only.
5. Staged human validation (G1 → G4), per Section 11, mobility aid retained throughout.
6. Iterate & cost-reduce, toward a producible, affordable version.

15. For the team

Suggested repository structure

third-eye-kit/
  README.md                 <- short version of this doc + the disclaimer, up top
  docs/
    Third-Eye-Kit_Envisioned-v2.md   <- this document
    history-v1.md            <- the v1 prototype writeup
    safety-and-validation.md
  firmware/
    reflex/  exo-motor/  spine/       (C / C++ / Rust)
    glove/   bracelet/                (C / MicroPython)
  brain/                     (Python + C++: perception, assistant, maps)
  trainer/                   (TypeScript: audio+touch game)
  simulator/                 (Python: CARLA bridge)
  hardware/
    schematics/  wiring-tables/  bom.csv
  LICENSE
  SAFETY.md                  <- the disclaimer, contraindications, "not a medical device"
  CONTRIBUTING.md

Contribution guide (essentials). Keep safety-critical firmware (reflex, exo-motor) in its own reviewed area, changes there need a second reviewer and a bench re-test of the e-stop + fail-safe. Never let AI/cloud code reach across the isolation boundary. Every new sensor reuses the shared buzz_encode. Log real measured latency and runtime, not calculated.

Publishing checklist (GitHub / website / LinkedIn).

• The status & safety disclaimer is at the top of the README, not buried.
• It's clearly framed as a research/design project and prototype, not a product for sale or clinical use.
• No medical claims for the health/temperature features; disclaimers present.
• A license is chosen (e.g., MIT/Apache-2.0 for code, CC-BY-4.0 for docs), your call.
• Credits list the team; the lead is Said Mohaddes Sadeqi, Hillsboro, Oregon.
• The LinkedIn post links the repo and leads with the mission ("They deserve more") and the insight ("Feel, don't wait"), and says it's an in-progress project.
• Alt text on images; the page itself is screen-reader accessible (it's for this community).

16. Honest limits & open questions

• Nobody has safely robot-steered a blind person's gait, the exoskeleton is the novel, unproven, expensive piece.
• The effective-yet-safe steer torque is unknown until G1, G2 measure it.
• Real false-positive rates in the field are unknown.
• Live traffic-signal data exists only in a few cities; the camera-read fallback carries most of the load.
• Full-day runtime under real actuator loads must be measured, not assumed.
• Long-term retention (do people keep wearing it?) is the ultimate test, and the reason for the trainer.
• The regulatory classification and clearance path are unconfirmed and will be slow.

17. Glossary

• Buzz-language, the scheme mapping direction/distance/urgency to body vibration.
• ToF (time-of-flight), a sensor that measures distance by timing a laser pulse's return.
• mmWave radar, radar that senses motion and works through dust/glare and detects glass.
• LRA, linear resonant actuator; a crisp, localizable vibration motor.
• QDD actuator, quasi-direct-drive motor; strong yet backdrivable (freewheels on fault).
• Backdrivable / fail-transparent, easy to push, so it goes limp instead of locking.
• Isolation boundary, the hardware split keeping the safety layer immune to the AI/cloud layer.
• SPaT, Signal Phase and Timing; live traffic-signal state, where a city publishes it.
• O&M, orientation and mobility; the profession that teaches blind travel skills.
• FMEA, failure mode and effects analysis; the hazard table method.
• G0, G4, the staged safety validation milestones before human reliance.

18. References (selected)

• Efficacy of electronic travel aids for blind wayfinding; the reality that AI glasses must still be used with a mobility aid and that newer AI guides (biped NOA, Glide, .lumen) are mostly prototypes, assistive-tech literature (2025 to 2026).
• a smart mobility aid handle Smart Mobility aid 2 specs and pricing; guide-dog and ETA cost figures, vendor and press sources.
• Two-point discrimination and vibrotactile spatial acuity across body sites, sensory-neuroscience literature.
• ST VL53L8CX / VL53L7CX multizone ToF datasheets (8×8, ~400 cm, cliff detection, eye-safe).
• Quasi-direct-drive backdrivable hip-exoskeleton research (~3.4 kg, ~17.5 Nm, ~0.4 Nm backdrive, ~15% metabolic reduction).
• OpenStreetMap / OpenSidewalks / AccessMap sidewalk-coverage studies; connected-signal (SPaT) pilots (NYC, Tampa); the Oko app reading walk signals by camera.
• Audio + haptic O&M training games (Audiopolis, AbES) and evidence of skill transfer to real-world navigation.
• Standards: ISO 13482, ISO 14971, IEC 60601, IEC 62304, ISO/TS 15066; exoskeleton clearances (ReWalk, Ekso).

(Full source URLs are compiled in the conversation research log and should be pasted here by the team before publishing.)

19. License

To be selected by the project lead before publishing. Suggested: MIT or Apache-2.0 for code; CC-BY-4.0 for documentation. Include the SAFETY.md disclaimer alongside the license.

Third Eye Kit, Envisioned v2, Said Mohaddes Sadeqi, Hillsboro, Oregon. Built on the principle that blind and visually impaired people deserve to feel the world in real time, not wait to be told about it. This is a research and design project; it is not a validated medical device, and its powered and health features must pass staged safety validation before anyone relies on them.