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. 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 developers#
Researchers, clinicians, and engineers from external 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 | Antagonist-pair PID control for joint angle | examples/elbow_flexion/ |
| 2 | Haptic / tactile feedback (non-functional EMS as a navigation cue) | examples/haptic_navigation/ |
| 3 | Continuous direction and distance haptic cues (spatial awareness) | examples/haptic_proximity_radar/ |
| 4 | Balance biofeedback from postural sway (concept, not clinically validated) | examples/vestibular_training/ |
| 5 | Sensor-triggered stimulation from foot contact, joint angle thresholds, IMU patterns | examples/atomic/semantic_muscle_control.py |
| 6 | External-device-triggered stimulation (force plate, EEG, optical mocap via LSL) | Step 6 of the implementation guide |
| 7 | Multi-device lab recording with synchronised LSL outlets | Step 7 of the implementation guide |
| 8 | Calibration-gated control (refuse to start until quality is OK) | examples/atomic/calibration_gate.py |
| 9 | Any third-party closed-loop haptic application (gaming, VR, training, biofeedback) — same pipeline, your domain logic | Implementation Guide |
Constraints and assumptions#
- Hardware: Teslasuit 4.x or XR5 (the active configuration is selected
via the
MuscleMapJSON). No other haptic / FES hardware is supported. - OS: Windows 10 or 11 (64-bit) — Teslasuit Control Center constraint.
- Python: 3.10 or higher.
- Dependencies:
numpyandpylslare required (installed automatically);PyQt5,pyqtgraphandmatplotlibare optional (the[gui]extra, only for GUI applications). The Teslasuit Python SDK is installed separately. - Network: Teslasuit and host computer on the same WiFi network; Teslasuit Control Center and Teslasuit Studio running.
- Distribution: Open source (MIT). Get it from github.com/teslasuit/RapidKit. Not published on PyPI yet.
Related reading#
- What is RapidKit? — elevator pitch
- Design principles — the why behind the architecture
- Glossary — FES + Teslasuit terms