Open-Source Python Framework BRACE Brings Clinical Robotics Control Within Reach

Robotic devices are quietly transforming rehabilitation medicine, from powered exoskeletons that help children with cerebral palsy walk more upright to precision actuators that probe the nervous system’s sense of touch. Yet behind every one of these machines sits a daunting wall of software: sensor drivers, communication protocols, data acquisition pipelines, safety monitors, and user interfaces that all have to work together in perfect synchrony. For clinical research teams, which rarely employ dedicated software engineers, that wall has often been enough to stop promising devices before they ever reach a patient. A new open-source framework called BRACE, short for Biomedical Robotics Architecture for Clinical Experimentation, aims to tear it down.

Developed by Scott Shen, Noah Rubin, and Thomas C. Bulea at the National Institutes of Health Clinical Center and described in the journal SoftwareX, BRACE is a pure-Python software framework for real-time robotic control in clinical research settings. It is released under the GNU GPL-3.0 license, available through the Python Package Index and GitHub, and built entirely from widely used Python libraries including NumPy, PySide6, PyQtGraph, pandas, and h5py. The design goal is deceptively simple: let researchers focus on the science-specific control logic of their device while the framework handles everything else, from streaming data over Wi-Fi to enforcing safety limits on actuator commands.

The architecture rests on a hierarchical control strategy that is already the standard structure in rehabilitation robotics. Control flow is segmented into three layers. The supervisory layer manages high-level goals such as recognizing a user’s intent or determining which phase of a cyclic task like walking the patient is in. The action layer transforms state information into actuator commands that accomplish specific objectives, such as imposing a desired torque profile on a knee joint. The execution layer carries out those commands while maintaining precision and safety. In BRACE, these layers are implemented through a set of abstract base classes and interfaces, including RobotAssemblyABC, RobotABC, IInputCom, IOutputCom, IMeasurementLists, IControlLogic, and ISafetyCheck, which researchers subclass to describe their particular hardware and controllers.

This compartmentalization follows the well-known Strategy design pattern from software engineering, and its practical payoff is modularity. A standardized hardware configuration can share a common set of inputs, outputs, and safety mechanisms while accommodating interchangeable control logic modules that execute distinct behaviors. Custom remote procedure call functions can be defined and invoked at runtime, dynamically modifying attributes across any subsystem without interrupting execution. In other words, an experimenter can change how a robot behaves mid-experiment without stopping the program, recompiling code, or reflashing a device, a capability that matters enormously when trial time with patients or animal subjects is scarce.

The framework’s client-server design links a laptop graphical interface to an embedded controller, typically a Raspberry Pi 4B, through an MQTT message broker using the Mosquitto implementation. The GUI, built with PySide6, abstracts remote procedure calls into intuitive controls for parameter configuration and command execution. A key feature is supervised soft real-time control law switching: the experimenter can transition interactively between control modes within a single experimental session. Safety is built into the switching procedure, which disables actuator torque before the change, swaps in the new controller, and then re-enables torque. During streaming, the interface deliberately locks down most configuration options to prevent unintended changes mid-trial.

Data handling is equally considered. Streaming data travels over Wi-Fi through the AnimatedGraphManager class, which subscribes to MQTT topics, classifies incoming messages using registered picklable NamedTuple datatypes as a portable schema, and buffers them in memory for live soft real-time visualization. Saved datasets are written to client-side storage in the Apache Parquet format, with NamedTuple field names serving as column headers so that controller-specific data subclasses can coexist within one unified streaming session. Controller transitions are encoded with NaN values that register as time-series discontinuities, and all remote procedure calls made during a session are captured, enabling post-hoc analysis of event ordering and deterministic replay.

Perhaps the most clinically motivated feature is the integrated offline simulator. Because clinical participants often cannot complete a high volume of trials, iterative tuning under time pressure is a chronic bottleneck. The simulator replays previously collected data as a simulated stream, allowing researchers to apply updated controller parameters and evaluate alternative configurations without the participant present. In the team’s exoskeleton example, the simulator achieved a replay accuracy of 98.1 percent, with the residual error traced to the unknown initial state of a finite-state-machine walking controller, a problem the authors address by recommending a nominal streaming blanking period before online actions begin.

Two independent clinical use cases demonstrate the framework’s range. The first is a lower-limb exoskeleton designed to treat crouch gait, the excessive knee flexion seen in children with cerebral palsy and other neuromotor disorders. The system runs on a Raspberry Pi 4B with a two-channel CAN bus expansion board, interfaced with bilaterally mounted Agilik knee actuators on a knee-ankle-foot orthosis, powered by a 36-volt battery stepped down to 5 volts. In testing, the control loop achieved 199.97 hertz against a 200 hertz target with only 0.66 percent jitter per 5-millisecond cycle and mean CPU usage of 43 percent per core, and controller switching took just 1.88 milliseconds, below the threshold of human perception. Streaming reliability was verified for at least six minutes, the duration required for standard 6-Minute Walk tests, and the software supported soft real-time switching between a gait-phase finite state machine and a proportional knee-angle-to-torque controller for squatting.

The second example is strikingly different: a closed-loop mechanoreceptive device for basic science. Mechanosensation, the ability to sense mechanical force, underlies touch perception and proprioception through molecular channels such as PIEZO2. Traditional rodent studies rely on Von Frey monofilaments, which buckle at defined forces but suffer from discrete force scaling and the variability of manual stimulus application. The BRACE-based device pairs a Zaber linear actuator with a load cell, an Arduino for signal digitization, and a Raspberry Pi running the framework’s control loop, enabling programmable, closed-loop delivery of mechanical stimuli across a continuous force range. The result is faster, more precise, and less variable measurement of stimulus thresholds and tissue stiffness, with less unnecessary exposure for animal subjects. That two such disparate systems, a wearable pediatric exoskeleton and a benchtop neurobiology instrument, could share the same software foundation illustrates the framework’s central claim of modularity.

The authors are candid about limitations. Hard real-time performance depends on hardware, and the framework has so far been validated only on the Raspberry Pi 4B with a CAN HAT across two sensor and actuator configurations. Meaningful customization requires proficiency in Python and object-oriented programming, deployment requires installing an MQTT broker, and the pickle-based serialization used for data collection poses a security risk that the team says makes the software suitable only for controlled research environments with trusted parties, with JSON or Protobuf suggested as safer future alternatives. Unlike commercial microcontroller firmware, it lacks encryption and verification schemes against unauthorized installation, limiting commercial applicability. Still, by lowering the technological barrier for novice programmers, supporting rapid prototyping of novel controllers, and potentially reducing participant fatigue through offline tuning, BRACE fills a genuine complexity gap. For a field where software infrastructure too often dictates the pace of clinical translation, an accessible, portable, and extensible foundation may prove to be the accelerant clinical robotics has been waiting for.

Subject of Research: An open-source Python software framework for real-time control of robotic devices in clinical research

Article Title: Biomedical robotics architecture for clinical experimentation (BRACE): A software framework for clinical robotics research

Article References: Shen, S., Rubin, N., & Bulea, T. C. (2026). Biomedical robotics architecture for clinical experimentation (BRACE): A software framework for clinical robotics research. SoftwareX, 36, Article 103096. https://doi.org/10.1016/j.softx.2026.103096

Image Credits: AI Generated

DOI: 10.1016/j.softx.2026.103096

Keywords: BRACE, clinical robotics, open-source software, Python, exoskeleton, rehabilitation robotics, hierarchical control, MQTT, Raspberry Pi, cerebral palsy, mechanosensation, real-time control