GPU-resident human-exoskeleton learning

GPU-Parallel Exoskeleton Policy Learning with Embedded Deployment

ExoSwift trains a reusable assistance policy in minutes by keeping musculoskeletal human-exoskeleton interaction and policy learning on the GPU, then distills the policy for 100 Hz microcontroller control.

  • 2,048parallel environments
  • 10,961environment steps/s
  • 2.03 msbilateral inference
Hundreds of muscle-actuated human and hip-exoskeleton simulations running in parallel 12 fps preview
GPU-parallel rollout. 256 environments are visualized; training scales to 2,048 environments on one GPU.

Overview

One pipeline, from muscle-level interaction to embedded assistance

Musculoskeletal simulation can reduce physical experimentation in exoskeleton controller development, but human-exoskeleton physics and real-time inference remain computationally demanding. ExoSwift separates reusable human-controller preparation from downstream exoskeleton policy learning and deployment.

A frozen muscle-actuated human policy supports GPU-parallel optimization of one assistance policy across four walking speeds. Offline distillation then compresses the learned torque mapping for execution on a Teensy 4.1 microcontroller.

13×

Higher peak throughput

Measured against the evaluated CPU-resident training baselines.

6.0–13.5 min

Mean convergence time

Across four parallelism settings and three random seeds.

15.2×

Fewer policy parameters

265,985 parameters in the teacher, 17,537 in the student.

0.91–0.94

Torque-command CCC

Mean participant-level concordance across four speeds (n = 6).

Why GPU-resident?

Remove the split between simulation and learning

Conventional pipelines step complex human-exoskeleton dynamics on the CPU while learning policies on the GPU. ExoSwift keeps the full training loop on-device.

CPU–GPU split training pipeline compared with the GPU-resident ExoSwift training pipeline
CPU-based simulation requires observation and action transfer at every step. The GPU-resident pipeline keeps batched musculoskeletal dynamics, environment stepping, observations, rewards, and policy learning on the same device.

Method

A staged route to a deployable exoskeleton policy

The method preserves muscle-level human-exoskeleton interaction during training, while the final policy uses only deployable bilateral hip kinematics.

01

Prepare the human controller

Continue training a pretrained muscle-actuated human policy under random bilateral hip torques, then freeze it for downstream assistance learning.

  • 83 joints and 354 active muscle-tendon units
  • Four reference speeds from 0.6 to 1.2 m/s
  • Perturbation curriculum up to ±15 N·m
03

Distill and deploy

Compress the teacher’s torque mapping offline into a compact student without additional simulation rollouts, then execute it at 100 Hz on-device.

  • Teacher: 256–512–256 hidden units
  • Student: 128–128 hidden units
  • Direct Teensy 4.1 flash deployment
Musculoskeletal human model wearing a bilateral hip exoskeleton
Human-exoskeleton model Device mass and inertia are attached to the pelvis and thighs; bilateral torques act about the human hip joints.
Teacher-to-student policy distillation followed by microcontroller deployment
Policy compression and hardware deployment The compact policy reads bilateral hip IMUs, predicts torque commands, and sends them to the QDD motors through CAN.

Robust human policy

Perturbation training stabilizes early exoskeleton exploration

A randomly initialized assistance policy can apply disruptive hip torques. Training the human controller under randomized bilateral perturbations improves tracking resilience before the exoskeleton policy begins learning.

Frozen during exoskeleton training Reusable across assistance objectives
Comparison of human motion tracking without and with perturbation training
Tracking under random hip torques, shown at 12 fps.

Training results

Large batches turn downstream policy learning into a minutes-scale task

The GPU-resident trainer continues to scale beyond the point where both evaluated CPU implementations saturate.

Training throughput and GPU memory use versus number of parallel environments
A

Throughput scales to 10,961 steps/s

At 2,048 environments, the trainer reaches 13× the peak measured CPU-baseline throughput while occupying 72% of the 16 GB GPU.

Total training time and convergence time across four environment counts
B

Fastest mean convergence: 6.0 min

The 1,024-environment setting converges fastest; all settings converge within a 6.0–13.5 min mean range across three seeds.

Joint kinematics, biological hip mechanics, and exoskeleton assistance across four walking speeds
C

One policy covers four walking speeds

The policy increases assistance with speed while preserving a consistent gait-cycle pattern, without receiving an explicit speed command.

Simulated biological and exoskeleton positive power across four walking speeds
D

22–28% lower simulated biological hip power

In simulation, the exoskeleton delivers 9.5–18.9 W of positive mechanical power per leg. These values are simulation outcomes, not physiological measurements.

Simulation demonstrations

Assistance adapts across the target speed range

The same policy generates stance-phase extension assistance and swing-phase flexion assistance from 0.6 to 1.2 m/s.

Four synchronized simulations showing exoskeleton assistance from 0.6 to 1.2 meters per second
Multi-speed assistance Muscle-actuated human and hip-exoskeleton simulation, with torque and power traces.

Embedded deployment

A distilled policy runs inside the 10 ms control period

The student policy requires 2.03 ms for bilateral inference on the Teensy 4.1—about 20% of the 100 Hz control period.

Participant walking on a treadmill while wearing the bilateral hip exoskeleton
Zero-shot treadmill deployment, shown at 12 fps.
265,985teacher parameters
17,537student parameters
  • 15.2× fewer parameters
  • 15.5× faster measured bilateral inference
  • Same deployable kinematic inputs as the teacher
  • Torque filtering and limiting before CAN transmission
Comparison of simulated and experimentally measured torque commands across four walking speeds
Simulation and deployment torque-command profiles across 0.6–1.2 m/s.

Treadmill study · n = 6

Torque commands remain consistent from simulation to hardware

Mean participant-level torque-command CCC ranges from 0.91 to 0.94 across four walking speeds, with standard deviations of 0.03–0.04.

RMS torque
7.54–8.29 N·m
Mean positive power
9.32–14.53 W
Positive share of absolute power
>98%

Manuscript

Read the paper

Full method details, experimental protocols, ablations, and references are available in the manuscript.

Download PDF