Frameworks

Audience and Use Cases

Who this framework is for and what it lets them do.

Primary audiences#

1. Internal Teslasuit developers#

Teslasuit team members building FES applications, demos, and integrations for partners. They know the hardware deeply but face friction every time they start a new application from the raw SDK — re-implementing the same data plumbing, channel maps, and process orchestration.

For this audience the framework is: a shared substrate that removes boilerplate, standardises how applications look across the team, and serves as the canonical reference implementation for new patterns (semantic muscle maps, calibration gating, LSL integration).

2. External partner developers#

Researchers, clinicians, and engineers from partner organisations (healthcare institutions, neuro-rehab labs, motion-science research groups) who build FES applications on Teslasuit hardware as part of their own research programmes.

Assumed background:

Working knowledge of Python (functions, classes, dataclasses, virtual environments, pip install).
Familiarity with FES, biomechanics, or rehabilitation engineering as a research domain.
No prior knowledge of Teslasuit SDK internals (skeleton structures, haptic node indices, channel mappings).

For this audience the framework is: the productive entry point. They should be able to write class MyStrategy(ControlStrategyBase): ..., hit run, and see a stimulation pulse delivered in response to a sensor event — without ever touching the underlying SDK.

The framework targets Python-proficient developers initially. Future work may bring less technical users into reach via the optional GUI scaffold and parameter-tuning utilities.

Concrete use cases the framework supports#

The canonical use case is FES, but the framework is suitable for any third-party application that follows the sensor input → processing → haptic output pipeline on Teslasuit hardware — gaming feedback, VR immersion, training cues, sensorimotor research, biofeedback, and so on. If your application reads from the suit's sensors, runs an algorithm, and produces haptic or EMS output, you're in scope.

#	Use case	Anchored example
1	Gait-phase-adaptive walking assistance (foot-drop, post-stroke gait)	`examples/walking_fes/`
2	Antagonist-pair PID control for joint angle	`examples/elbow_flexion/`
3	Haptic / tactile feedback (non-functional EMS as a navigation cue)	`examples/haptic_navigation/`
4	Sensor-triggered stimulation from foot contact, joint angle thresholds, IMU patterns	`examples/atomic/semantic_muscle_control.py`
5	External-device-triggered stimulation (force plate, EEG, optical mocap via LSL)	Step 6 of the implementation guide
6	Multi-device lab recording with synchronised LSL outlets	Step 7 of the implementation guide
7	Calibration-gated control (refuse to start until quality is OK)	`examples/atomic/calibration_gate.py`
8	Any third-party closed-loop haptic application (gaming, VR, training, biofeedback) — same pipeline, your domain logic	Implementation Guide

Constraints and assumptions#

Hardware: Teslasuit v4.5+ (XR5 recommended; the active configuration is selected via the MuscleMap JSON). No other haptic / FES hardware is supported.
OS: Windows 10 or 11 (64-bit) — Teslasuit Control Center constraint.
Python: 3.10 or higher.
Dependencies: numpy and pylsl are required; PyQt5 and pyqtgraph are optional (only for GUI applications).
Network: Teslasuit and host computer on the same WiFi network; Teslasuit Control Center running.
Distribution: Available to Teslasuit partners; contact support@teslasuit.io for access.

What is RapidKit? — elevator pitch
Design principles — the why behind the architecture
Glossary — FES + Teslasuit terms

Overview