TeslasuitDocumentation
Frameworks

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.

↺ the physical body closes the loopSensors
Teslasuit IMUs · joint angles · foot contacts · LSL inlets
process()
Your ControlStrategy reads self, writes ems_output
Stimulation
Anatomical muscle names → EMS channels
cycle 0142·~10 ms· hardware-paced 100 Hz

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#

ConcernHandled by
Hardware connectionSuitHandler (auto-created)
Sensor data parsingDataStreamer (29 joints, 20 bones, foot contacts, raw IMU, optional PPG)
Muscle channel routingMuscleMap (anatomical name → SDK channel ID)
Stimulation outputStimulator (translates EmsData to SDK haptic calls)
CalibrationCalibrationAPI (trigger + quality assessment)
External device fusionExternalInputManager (LSL inlets)
Recording / lab integrationLSLStreamer (7 outlets at 100 Hz)
Inter-process communicationSharedRingBuffer + multiprocessing.Queue
Real-time GUI scaffoldMainWindow template (PyQt5, optional)
Loop timingHardware-paced — Teslasuit SDK governs the clock
FES kill switchUtilityMessage.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 documentation

What 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 MuscleMap JSON).
  • 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 forAudience and use cases
Understand the design choices and architectural rationaleDesign principles
Learn the FES + Teslasuit terminology used throughoutGlossary
Install and get a minimal app running in 10 minutesInstallationQuick Start
See how a partner team would adopt the frameworkThe implementation guide