What is RapidKit?
A Python framework that turns Teslasuit into a programmable closed-loop haptic platform — you write a control algorithm, the framework handles everything else. Built for Functional Electrical Stimulation (FES), but equally suited to any application following the sensor input → processing → haptic output pipeline.
In one paragraph#
RapidKit is a modular Python library that provides a standardised
closed-loop control architecture for Teslasuit-based applications. The
canonical use case is Functional Electrical Stimulation (FES), but the same
pipeline — read sensors, process, drive haptic output — fits any third-party
application that needs deterministic real-time control of Teslasuit's haptic
and EMS subsystems. The framework abstracts hardware connection, sensor data
acquisition, muscle channel routing, calibration, inter-process communication,
and Lab Streaming Layer (LSL) integration behind a small set of clean,
anatomically-aware Python APIs. Application developers extend a single class —
ControlStrategyBase — and write process(), the per-cycle decision logic.
The framework runs that decision logic at hardware-paced ~100 Hz, in a
dedicated subprocess, with optional GUI, recording, and external-device fusion
already wired in.
What "closed-loop" means here#
Every cycle (~10 ms) the framework runs a strict three-stage pipeline:
┌────────────┐ ┌────────────────────┐ ┌──────────────┐
│ Sensors │ ──▶ │ Your algorithm │ ──▶ │ Stimulation │
│ (Teslasuit │ │ (ControlStrategy │ │ (EMS pulses, │
│ + LSL) │ │ .process()) │ │ haptic) │
└────────────┘ └────────────────────┘ └──────────────┘
▲ │
└──────── physical body in the loop ───────────┘The "loop" is closed by the body itself: the sensors observe how the user moves in response to the previous stimulation pulse, and your algorithm decides what to send next. The framework guarantees this happens deterministically, in order, at a predictable rate, with a global FES kill switch you cannot accidentally bypass.
What you provide#
One class. One method:
from fes_framework.control.strategy_base import ControlStrategyBase
from fes_framework.data.types import EMSParamData
class StanceQuadStrategy(ControlStrategyBase):
def process(self) -> None:
if self.contacts.right_foot_contact:
self.ems_output.quadriceps_right = EMSParamData(
IsMuted=False, Amplitude=40, PulseWidth=120, Period=20.0,
)That snippet, plus three lines to launch it, is a complete working FES application: when the right foot is on the ground, stimulate the right quadriceps at 40% amplitude.
What the framework provides#
| Concern | Handled by |
|---|---|
| Hardware connection | SuitHandler (auto-created) |
| Sensor data parsing | DataStreamer (29 joints, 20 bones, foot contacts, raw IMU, optional PPG) |
| Muscle channel routing | MuscleMap (anatomical name → SDK channel ID) |
| Stimulation output | Stimulator (translates EmsData to SDK haptic calls) |
| Calibration | CalibrationAPI (trigger + quality assessment) |
| External device fusion | ExternalInputManager (LSL inlets) |
| Recording / lab integration | LSLStreamer (7 outlets at 100 Hz) |
| Inter-process communication | SharedRingBuffer + multiprocessing.Queue |
| Real-time GUI scaffold | MainWindow template (PyQt5, optional) |
| Loop timing | Hardware-paced — Teslasuit SDK governs the clock |
| FES kill switch | UtilityMessage.FesIsActive enforced after every process() |
You touch any of these only when you want to. The defaults work.
Three-layer architecture#
The framework formalises every FES application as a three-layer pipeline:
INPUT → CONTROL → OUTPUT
DataStreamer ControlStrategy Stimulator
(your code)This mapping is reflected in the package layout (io/, control/, io/),
the data flow each cycle, and the place where developers focus their effort
(the middle layer). See Architecture.
What's in the box#
fes_framework/ ← the installable Python package
examples/
├── atomic/ ← 5 single-concept demos (~80 lines each)
├── elbow_flexion/ ← PID-controlled antagonist pair, GUI included
├── haptic_navigation/← directional cueing via haptic patterns
├── generic_gui/ ← reference PyQt5 operator interface
└── walking_fes/ ← full walking-FES research application
docs/ ← this documentationWhat it isn't#
- It is not a clinical medical device. There is no certification, no safety case, no regulatory pathway built in. Use only in research or supervised demonstration contexts.
- It is not a hardware abstraction over arbitrary FES devices. The only
supported hardware is Teslasuit v4.5+ (XR5 recommended; the active
configuration is selected via the
MuscleMapJSON). - It is not an algorithm library. It does not ship with controllers, filters, or detectors beyond the SDK's own step detector. The control logic is yours to write.
- It is not a GUI framework. It ships a working PyQt5 template, but the GUI is optional and entirely user-replaceable.
Where to go next#
| If you want to … | Read |
|---|---|
| Understand who this is for | Audience and use cases |
| Understand the design choices and architectural rationale | Design principles |
| Learn the FES + Teslasuit terminology used throughout | Glossary |
| Install and get a minimal app running in 10 minutes | Installation → Quick Start |
| See how a partner team would adopt the framework | The implementation guide |
