PASSIVE ARM COORDINATION TRAINER 3D (PACT3D)
BACKGROUND
Years of research of the Dewald Lab has concluded that the effective work area of a person who has suffered from an ischemic stroke could increase if they progressively increase the abduction load that they are lifting against and practice reaching with that load.
The Passive Arm Coordination Trainer 3D (PACT3D) is the embodiment of the translational component of the Dewald Lab's research goals as it was developed to improve upper limb rehabilitation, addressing the fact that no other standalone rehabilitation device exists in the market that had the capability of adjusting abduction load and allowing the trainee to reach while generating the counteracting abduction forces at the shoulder. The device has the ability to provide positive and negative loads, fully support the limb for beginning training sessions and generating up to -50 N of load for later stage training.
I managed a team of two engineers at the Dewald Lab, as well communications with our remote team in the Netherlands to see this device from conception to completion. Lastly, as this is a project for work, I am unfortunately unable to reveal detailed design elements.
DESIGN CONSIDERATIONS
We partnered with a team in the Netherlands to develop and improve our conceptual mechanical design. However, after they built the device, there were still some practical design considerations before the device could be in a state of active testing in our research environments:
What is the best microcontroller to use onboard the device?
How could we communicate with the motor controller in order to modify the abduction load between trials as needed?
Is it reasonable to communicate with the onboard microcontroller wirelessly and, if so, what is the best mode of communication?
How do we save and collect trial data? Is real-time data streaming to the GUI possible without introducing lag into a resulting visual feedback method?
What is a safe way to unload the device while the patient's arm is in it in case the system loses power?
MICROCONTROLLER SOFTWARE DEVELOPMENT
We selected the Teensy 3.6 Microcontroller as we thought it would be the optimal microcontroller in terms of memory, handling interrupts, and getting first iteration code up and running the fastest.
The microcontroller has a few major tasks:
Communicate constantly with the user's GUI to await an action command. These commands were:
Execute trial of x length
Send data to GUI
Adjust abduction load
Safety load release
Reading from the onboard encoders
Calculate end effector position based on joint angular measurements from encoders
Communicate with the onboard motor controller to set and get motor position
PCB DESIGN
One major requirement for the electronics was that they were constrained to a small 6" x 4" x 3" portion of the device. If necessary, we could house more electronics on the stand of the device but we did not envision that as an ideal case as we wanted everything other than the power supply of PACT3D and stand to be located at the base.
The PCB needed to have:
Teensy microcontroller
Backup battery system in the event of power loss
USB to TTL converter to communicate with Maxon controller
RS-485 Transceiver
USB to RS232 module for temporary communication with a PC while the Android GUI was in development, but next iteration will have a Bluetooth or Wi-Fi module
EXPERIMENTER GUI DEVELOPMENT
There are two GUIs that we would like to develop. The first is a GUI for the experimenter for when the device is used in a research setting and the second is a GUI to be used in the home or a clinical setting by Physical Therapists.
Our goal was to get the experimenter GUI developed first as that was easier, a good way for us to test the product, and what was needed first. The difference between the experimenter and at-home GUIs was primarily that the experimenter would be using Matlab on a Windows machine for data collection with EMGs vs. and Android tablet with simple task and feedback functions for the at-home or clinic user.
We accomplished this first goal relatively quickly, and I developed a simple proof-of-concept Android GUI for the second goal. We are currently working with a software developer to make a more robust version of the app.