OpenGait — Open-Source FES Walking System

Role: Sole Architect & Lead Developer
Type: Open-Source Assistive Technology / Personal Use
Tech Stack: Python, TensorFlow Lite, Arduino (TinyML), Raspberry Pi 5, Unity3D, Federated Learning
Status: 🚧 Work in Progress — Research Complete, Design & Prototyping Pending

The One-Liner: An open-source closed-loop FES walking system for complete spinal cord injury, using distributed edge inference and predictive control to compensate for system latency. Target hardware cost: under $2,000.

The Problem Space

Functional Electrical Stimulation (FES) can enable people with paralysis to stand and walk by triggering muscle contractions through surface electrodes. I've used FES in rehabilitation settings (stationary cycling, leg exercises) and experienced firsthand how it can activate muscles that no longer respond to voluntary commands.

Commercial FES walking systems exist. They're also largely inaccessible.

The Challenge

The Parastep I is the only FDA-approved surface FES walking system¹. It costs approximately $13,000 (excluding training)² and uses open-loop control: pre-programmed stimulation sequences (24 Hz, 150 µsec) triggered by finger-touch buttons on a walker's handlebars. There's no sensor feedback, no adaptation to gait phase, no compensation for muscle fatigue. The user becomes the feedback loop.

Research labs have built closed-loop systems that achieve far better results. The Cleveland FES Center reports walking speeds ranging from 0.1 m/s to 0.5 m/s with implanted 16-channel systems, with one subject achieving repeatable day-to-day gait averaging 0.4 m/s³. But these remain locked behind proprietary hardware, academic access, and costs exceeding $50,000 for implanted systems⁴.

The gap between "technology that exists in labs" and "technology I can actually use" is what motivated this project.

The Constraints

Building a DIY FES walking system is not a weekend project. The constraints are severe:

Safety comes first. FES carries real risks: burns from improper electrode placement, falls from muscle fatigue, fractures from osteoporotic bones. Any system must include hardware-level safety interlocks that function independently of software. I'm not interested in building something that could hurt me worse than I already am.

Latency kills walking. The time from sensor reading to muscle force production can exceed 200ms when muscles fatigue. Gait phases at slow walking speeds last around 500-800ms. React too late and you've missed the window.

No proprioception below injury. I have no sensation or voluntary motor control below L4. The system must replace the entire sensorimotor feedback loop, not augment existing function.

Open-source means reproducible. If this only works with my exact body proportions and specific component tolerances, it's a personal project, not a contribution to the community.

These constraints shaped every architectural decision.

The Solution Architecture

High-Level Design

OpenGait uses a distributed architecture with edge inference to minimize latency while maintaining centralized coordination for safety and adaptive control:

1. Distributed Sensing Network
   Seven Arduino Nano 33 BLE Sense Rev2 units placed at shanks, thighs, pelvis, and trunk. Each runs TinyML gait phase classification locally, transmitting only state transitions (not raw IMU streams) to reduce BLE bandwidth and eliminate central processing as a latency bottleneck.

2. Force-Sensing Insoles
   Research is unambiguous: IMUs alone cannot reliably detect ground contact. FSR sensors at heel, first metatarsal, and fifth metatarsal provide binary ground contact confirmation that improves gait event detection accuracy.

3. Central Prediction & Coordination
   A Raspberry Pi 5 with Hailo-8L AI HAT (13 TOPS)⁵ handles multi-sensor fusion, LSTM-based trajectory prediction (200ms horizon), and adaptive parameter adjustment. The AI accelerator enables inference at the speed needed for real-time compensation.

4. Safety-First Stimulation
   Rather than building stimulators from scratch, OpenGait modulates FDA-cleared TENS units via relay control (following the openEMSstim approach)⁶. A dedicated RP2040 watchdog MCU monitors the main system and can kill stimulation even if the primary processor crashes.

5. Intent Input
   A Wii Nunchuck provides intuitive control: joystick for direction (always relative to user facing), buttons for sit/stand transitions and emergency stop.

Key Architectural Trade-Off
I optimized for latency compensation over raw accuracy. A gait phase classifier that's 99% accurate but takes 150ms is worse than one that's 95% accurate in 50ms. The system predicts ahead rather than reacts, using phase-advance triggering and LSTM trajectory prediction to compensate for electromechanical delay.

The Bill of Materials Target

The hardware BOM comes in at approximately $1,064, well under the $2,000 target:

*Battery costs are placeholders pending power system design validation. Actual costs may vary based on capacity requirements.

This excludes KAFOs (typically covered by insurance) and represents raw component costs only. It doesn't account for development time, iteration, or the regulatory compliance and training included in commercial systems like the Parastep ($13,000). The comparison isn't apples-to-apples, but it does suggest that the hardware itself isn't the primary cost barrier. The more interesting difference is the closed-loop control architecture, which doesn't exist in any commercial surface FES walking system.

Power System Requirements (To Be Designed)

Power management is a gap in the current architecture that I haven't solved yet. This section documents preliminary requirements and constraints; the actual power system design remains incomplete and will require iteration.

Estimated Power Budget

Based on component specifications, here's a rough power budget for active walking:

FES Stimulation Power Calculation:

FES power is complex because stimulation is pulsed, not continuous:

• Stimulation parameters: ~80V compliance, 10-30mA per channel, 150-300µs pulse width, 20-50Hz frequency
• Duty cycle at 50Hz with 300µs pulse: ~1.5%
• Per-channel average power at output: (80V × 20mA × 0.015) = ~24mW
• However, boost converter efficiency from battery (~50-70%) and idle consumption dominate
• With 4-6 channels active on average: ~2-4W from battery including converter losses

Caveat: These figures are estimates derived from component datasheets and published FES research. Actual consumption will vary based on stimulation intensity (which changes per user and with fatigue), duty cycles, and converter efficiencies. I won't know real numbers until I build and measure it.

Target Operating Duration

For practical use, the system should support:

For context: a typical smartphone battery holds ~15 Wh; a laptop battery holds ~50-100 Wh. The 30-minute training session target is achievable with reasonable battery weight, but full-day operation will require either battery swaps or significant weight.

Battery Options Under Consideration

Initial prototype approach: For early testing, I'll use a tethered power supply or oversized battery pack. Optimizing the power system comes after validating core functionality.

Load Management Considerations

The system has highly variable power demands:

• Startup surge: RPi 5 boot can draw 3A+ briefly
• Inference spikes: Hailo-8L peak draw during model execution
• Stimulation transients: FES pulse generation creates high-frequency current spikes
• BLE coordination: Periodic transmission bursts from 7 sensor nodes

Load management strategies to explore:

1. Staggered boot sequence — Don't power all subsystems simultaneously
2. Capacitor buffering — Bulk capacitance to handle transient loads without battery stress
3. Distributed power domains — Separate supplies for sensing, processing, and stimulation to isolate faults
4. Dynamic power scaling — Reduce RPi clock speed during low-demand phases; sleep sensor nodes between samples

Safety Constraints

Power system failures in an FES walking system can cause falls. Requirements I won't compromise on:

1. Graceful degradation — Loss of power must not cause uncontrolled stimulation. Fail-safe relays should default to open (stimulation off) on power loss.

2. Watchdog independence — The RP2040 safety watchdog must have isolated power (separate regulator or battery) so it can kill stimulation even if the main system fails.

3. Thermal protection — FES electrodes and boost converters can generate heat. Over-temperature cutoffs are mandatory.

4. Battery protection — Over-discharge, over-current, and over-temperature protection circuits are required for Li-ion cells. I'll use cells with integrated protection or add external BMS.

5. Charge safety — No charging while walking. Charging circuit should be physically isolated or interlocked to prevent operation during charge.

Known Unknowns

The following questions can't be answered without hardware testing:

• What is actual power consumption during realistic gait cycles?
• How does stimulation intensity (and thus power) scale with muscle fatigue over a session?
• What are the thermal limits of the enclosure, and how does heat affect battery capacity?
• Can commercial TENS units be reliably modulated without exceeding their duty cycle ratings?
• What is the actual efficiency of the boost converters under pulsed FES loads?

Status: Power system design is deferred until core functionality is validated. Initial prototyping will use bench power supplies or oversized batteries with the explicit understanding that a production-ready power system requires dedicated engineering effort.

Technical Deep Dive

Why Latency Compensation Dominates the Design

The fundamental challenge isn't "make muscles contract." Any TENS unit does that. The challenge is timing.

Walking involves precisely sequenced muscle activations across the gait cycle. Quadriceps fire during loading response to stabilize the knee. Tibialis anterior activates during swing to clear the foot. Gastrocnemius provides push-off propulsion. Miss the timing window by 100ms and you get a stumble, not a step.

The latency budget breaks down roughly as:

Research on delay compensation strategies shows that phase-advance triggering (initiating stimulation for the next phase based on predicted phase completion) can reduce timing errors. Zahradka et al. (2019) found that triggering at 50% of the current phase duration achieved timing errors of only 0.3 ± 4.1% of the gait cycle, while triggering at 75% phase completion produced timing errors of 3.9 ± 4.6%¹³. The LSTM on the AI HAT handles longer-horizon prediction to compensate for the variable electromechanical delay that increases with muscle fatigue.

Sensors Above AND Below Injury

My initial instinct was to focus sensing on the legs, where the action happens. Research corrected this assumption.

For complete SCI, there's no proprioceptive feedback from lower limbs. Balance relies entirely on visual feedback and trunk sensation. Studies on postural control in SCI show that trunk accelerometers correlate with clinical balance assessments and can detect compensatory movements that predict instability before it becomes unrecoverable.

The final sensor placement includes IMUs at pelvis, lower trunk (L5), and upper trunk (T4/sternum), not just the legs. This enables center-of-mass estimation, trunk sway detection for fall prediction, and understanding of how upper body compensation affects gait stability.

Unity3D Simulation for Cold-Start

A chicken-and-egg problem: you need a working system to collect training data, but you need training data to build a working system.

The solution is synthetic data generation via Unity3D simulation:

1. Create a musculoskeletal avatar scaled to my body proportions
2. Apply walking animations with realistic physics
3. Place virtual IMUs at sensor positions matching the physical hardware
4. Record synthetic accelerometer/gyroscope streams
5. Apply data augmentation (magnitude warping, time warping, noise injection)
6. Train TinyML models via Edge Impulse
7. Validate against real data (collected with safety harness)

Research by Sharifi Renani et al. (2021) demonstrates that synthetic IMU data generated from OpenSim musculoskeletal simulation can improve deep learning model accuracy for joint kinematic predictions. Their study found that training on synthetic data alone improved hip angle prediction by 38% compared to measured data, while combining synthetic and measured data achieved 54% improvement¹⁴. Whether these gains transfer to gait phase classification (a discrete state prediction task rather than continuous angle estimation) remains to be validated, but the underlying principle (that simulated sensor data can bootstrap model training) is promising.

Current Status & Outcomes

Where Things Stand

This project is in the research and preliminary design phase. No hardware has been assembled. No models have been trained. No walking has occurred.

✅ Completed: Initial Research

• Literature review of FES walking systems, gait phase detection, and latency compensation
• Component selection and feasibility assessment
• High-level system architecture concept
• Power budget estimates (pending validation)
• Research compilation available in the OpenGait Research Repository, an Obsidian notebook documenting sources, design rationale, and open questions

🚧 In Progress: Design & Documentation The following are drafts based on research, not validated designs:

• System architecture documentation (this document)
• Preliminary bill of materials
• Safety system concept (requires expert review)
• Technical reference for collaborators

📋 Remaining Before Hardware:

Only after completing the above can these be considered "complete":

• Architecture documentation (currently: hypothesis)
• Bill of materials (currently: estimate)
• Safety system design (currently: concept)
• Technical reference (currently: draft)

Why Document Before Building?

I've learned (the hard way, on other projects) that jumping straight to implementation often means building the wrong thing efficiently. The documentation-first approach forces architectural decisions to be explicit and reviewable before committing to hardware that's expensive to change.

That said, I want to be clear: this documentation represents research conclusions and design hypotheses, not validated engineering. The gap between "this should work based on the literature" and "this actually works on my body" is substantial. These documents will evolve as prototyping reveals what I've gotten wrong.

Retrospective

Rabbit Holes I've Been Down

The "Just Add More Channels" Trap
Early research suggested that more stimulation channels = better control. The Cleveland FES Center uses 16+ channels with implanted electrodes. I initially spec'd a 12-channel system before recognizing that surface FES has fundamental limitations that more channels don't solve. You can't selectively target deep muscles like the iliopsoas regardless of how many surface electrodes you apply.

The revised design focuses on 8 channels targeting muscles that surface stimulation can actually reach, plus using the peroneal nerve to trigger flexor withdrawal reflexes that produce coordinated hip/knee/ankle flexion.

The Inverse Kinematics Complexity Spiral
I spent weeks researching full biomechanical simulation: OpenSim integration, real-time inverse kinematics, musculotendon dynamics. The math is beautiful. It's also massive overkill for initial development.

The revised approach uses finite state machines for gait phase sequencing with adaptive parameter adjustment, reserving full IK modeling for potential future phases. Perfect is the enemy of walking.

Underestimating Electromechanical Delay
My initial latency budget focused on electronics: BLE timing, inference speed, stimulator response. I'd heard about electromechanical delay (EMD) but assumed it was a fixed offset I could compensate for statically.

Wrong. EMD varies within a single session. Research shows it can range from approximately 100ms to 300ms under dynamic FES cycling conditions, increasing as muscles fatigue¹². This is why the LSTM trajectory prediction exists: it needs to adapt to changing delay characteristics in real-time.

What I'd Do Differently

If starting over with current knowledge:

1. Start with the safety system. I designed control architecture first, safety second. Should be reversed. The safety watchdog, hardware current limiters, and emergency stop should be the first things built and tested.

2. Buy commercial insoles. I spec'd DIY FSR insoles to minimize cost. In retrospect, commercial smart insoles (~$200-300) would provide better sensor quality and save integration time. Optimize for learning speed, not initial BOM cost.

3. Find clinical collaborators earlier. The documentation is technically detailed but lacks clinical validation. A physical therapist with FES experience reviewing the approach early would have caught issues I'm probably still missing.

Why This Work Matters

I'm building this for myself. After two years in a wheelchair, I want to explore whether I can walk again using technology I can actually access and understand.

But the larger motivation is accessibility. The assistive technology market is characterized by high prices, proprietary systems, and slow innovation cycles. Open-source approaches have made inroads in other domains: 3D-printed prosthetics, open-source hearing aids, community-developed AAC systems. It's worth noting that FES walking systems involve real-time neuromuscular control and safety-critical timing that make them more complex than passive assistive devices.

If OpenGait works, it won't be because I'm a better engineer than the teams at research labs. The core challenges (muscle fatigue, variable electromechanical delay, lack of proprioception) are biological, not technological. What's changed is that:

• Edge ML hardware (TinyML, affordable AI accelerators) has only recently become cheap and capable enough to attempt distributed real-time inference
• Open-source development allows rapid iteration and community contribution, though academic labs with dedicated staff can also move quickly
• As a patient-developer, I have direct access to the feedback loop (my own body) and can make informed personal risk decisions. This is a double-edged sword, since institutional safety protocols exist for good reasons.

And if it doesn't work, if surface FES with KAFO bracing simply can't achieve stable closed-loop walking, that's also valuable information. The experiment is difficult to attempt outside of well-resourced settings, and documenting the approach openly may help others build on what works and avoid what doesn't.

Technical Resources

Project Repository

• OpenGait Research Repository — Obsidian notebook containing compiled research, paper summaries, design decisions, and open questions. This is the primary source for understanding the rationale behind architectural choices.

FES & Neuroprosthetics

• Cleveland FES Center — Leading research on implanted FES systems
• openEMSstim — Open hardware for EMS intensity modulation (note: designed for HCI/VR haptics, not rehabilitation)
• NeuroStimDuino — Arduino neurostimulation shield (research purposes only, not FDA-approved)

Gait Analysis & Control

• Zahradka et al. (2019) — Gait Phase Detection Delay Compensation Strategies — Research on timing compensation for FES walking systems
• Wearable Sensor-Based Real-Time Gait Detection: Systematic Review

Edge ML & Embedded Systems

• Edge Impulse — TinyML development platform
• Arduino Nano 33 BLE Sense Rev2 — 9-axis IMU (BMI270 + BMM150) with TensorFlow Lite for Microcontrollers support¹⁵
• Raspberry Pi AI HAT+ — Hailo-8L accelerator for edge inference

Open-Source Assistive Technology

• OATS Project — Open Assistive Technology Software
• Low-Cost Assistive Technologies Using Open-Source Hardware — IEEE systematic review

Get Involved

This project needs collaborators across multiple domains:

• Clinical: PTs with FES experience, rehab engineers, SCI clinicians
• Technical: Embedded systems, TinyML, Unity3D, PCB design
• Research: Biomechanics, control systems, federated learning
• Community: Documentation, other SCI individuals for feedback

How to follow or contribute:

• Browse the OpenGait Research Repository to understand current thinking and open questions
• Open issues for questions, suggestions, or to flag errors in the research
• Reach out via the contact information on this site for deeper collaboration

Project Status: Initial research complete. Model design, simulation, training, and component prototyping remain before architecture can be validated. No hardware built. No walking yet.

References