Sage Journals: Discover world-class research

Abstract

Several factors may prevent post-stroke subjects from participating in rehabilitation protocols, for example, geographical location of rehabilitation centres, socioeconomic status, economic burden and lack of logistics surrounding transportation. Early supported discharge from hospitals with continued rehabilitation at home represents a well-defined regimen of post-stroke treatment. Information-based technologies coupled with robotics have promoted the development of new technologies for telerehabilitation. In this article, the design and development of a modular architecture for delivering upper limb robotic telerehabilitation with the CBM-Motus, a planar unilateral robotic machine that allows performing state-of-the-art rehabilitation tasks, have been presented. The proposed architecture allows a therapist to set a therapy session on his or her side and send it to the patient’s side with a standardized communication protocol; the user interacts with the robot that provides an adaptive assistance during the rehabilitation tasks. Patient’s performance is evaluated by means of performance indicators, which are also used to update robot behaviour during assistance. The implementation of the architecture is described and a set of validation tests on seven healthy subjects are presented. Results show the reliability of the novel architecture and the capability to be easily tailored to the user’s needs with the chosen robotic device.

Keywords

Upper limb rehabilitation robotics stroke telemonitoring telecontrol

Introduction

Stroke is one of the main causes of disability in adults worldwide,¹ and its rapid growth² has revealed the need of new technologies for promoting effective, cost-efficient stroke rehabilitation. Early supported discharge (ESD) from hospitals with continued rehabilitation at home is known to be a well-validated regimen for post-stroke rehabilitation.³ It consists of services that aim to accelerate the discharge of patients after a stroke event and provide a comparable rehabilitation level at the patient’s home with conventional hospital care and discharge.⁴

The application of this regimen to post-stroke rehabilitation has fostered a growing interest in the development of new technologies for telerehabilitation, able to provide remote delivery and monitoring of rehabilitation services over telecommunication networks and Internet. Furthermore, telerehabilitation can also benefit from the recent advancements of robot-aided rehabilitation, thus providing interactive, repetitive and task-specific activities that can be tailored to the user’s needs, and promote motor learning, exploiting neuroplasticity, without the continuous oversight by a therapist.^5–7

Many studies have demonstrated the effective role of robots in upper limb robot-aided motor therapy;^8–12 conversely, a few studies have investigated the feasibility and the efficacy of remote robot-aided rehabilitation.^13–16 The concept of combining telerehabilitation and robot-assisted therapy represents a novel challenging approach in neurorehabilitation; such a concept shows the potential to provide cost-effective and consistently high-quality treatment to patients with limited access to rehabilitation clinics because of location or availability of treatment.¹⁷ In particular, task-specific neurorehabilitation using robotics coupled with ESD approach can significantly improve the field of rehabilitation and yields considerable benefits for patients with stroke impairments.^4,18

In the recent years, different telerehabilitation systems have been developed to improve patients’ activities of daily living in the attempt to increase their independent living at home.^19–22 The systems for robot-aided telerehabilitation can be grouped into two different classes: systems in unilateral configuration and systems in bilateral configuration.¹⁸

In unilateral configuration only the patient is connected to the robot, while the therapist can remotely communicate with the robot and the patient. The communication between patient and therapist is not required to be real time; after a predefined time-lapse, data are sent to the therapist interface in order to verify the therapy progress and, possibly, modify the treatment.

There are many examples of unilateral robotic systems; they are briefly reported in the following. TheraJoy and TheraDrive are a force reflecting joystick and force reflecting wheel, respectively, that are used together with UniTherapy, a customizable universal software platform for delivering upper limb robotic therapy.²³ The JavaTherapy system¹³ is a wrist trainer system based on a low-cost commercial force feedback; it is designed for home therapy and is remotely monitored and managed by therapist via a low-cost web camera and teleconference software. The assisted movement with enhanced sensation (AMES) robotic device²⁴ enables wrist or ankle exercises in home settings; it is able to provide vibratory sensations to the antagonist muscle-stretching tendon, while the agonist muscle is performing the desired action. The Rutgers Master II (RMII), developed by Popescu et al.,²⁵ is used to increase hand strength in stroke patients using teletherapy. The virtual driving environment²⁶ consists of an immersive virtual environment with which the patient can interact through various kinaesthetic interfaces, such as a commercial force feedback steering wheel used in gaming applications.

The Hand Mentor™ and Foot Mentor™ are unilateral configuration systems, developed by Kinetic Muscles Inc., that provide hand and foot in-home rehabilitation. The ReJoyce system, developed by Hometelemed Inc., represents an arm-hand workstation designed for clinic and home therapy. In addition, the Habilis platform developed within the Clinical Leading Environment for the Assessment and validation of Rehabilitation Protocols for home care (CLEAR) project²⁷ is a web-based interoperable platform allowing transmission of multimedia files to assign remotely telerehabilitation sessions to patients affected by stroke, spinal cord injury (SCI) and chronic diseases. Finally, the Hand Mentor Pro (HMP) has been validated through clinical studies;^17,28,29 no significant differences were found between home robotic telerehabilitation and standard home exercise programme.

In the bilateral configuration, both the patient and therapist interact with a robot and communicate over the Internet through a shared virtual environment (SVE), normally using a client/server approach. The communication is real time and enables the therapist to modify the current exercise or apply corrective actions during the tasks.

In the work by Basdogan et al.,³⁰ a cooperative ‘ring on a wire’ task over a local area network (LAN) using two PHANTOM™ haptic devices (SensAble Technologies Inc., Woburn, MA) has been performed. Similarly, a LAN-based system has been developed by Goncharenko et al.³¹ in order to simulate a dual-arm haptic interaction with a steering wheel. Alternatively, researchers at the MIT Touch Lab and University College London used a peer-to-peer architecture to perform a ‘transatlantic’ touch experiment in which a virtual box was lifted using PHANTOM™ haptic devices.³²

Independent of the type of configuration, studies on ESD have showed the need of in-home rehabilitation delivery system because, when therapy is maintained constant and intense, an increase in the functional recovery can be significant.³³ However, robots for telerehabilitation have to address specific requirements related to the application, such as portability and, consequently, lightness, compactness, easiness to set up and ready to use both for therapists and patients. Furthermore, communication architecture has to be reliable guaranteeing robust and safe communication between the patient and the therapist side. In addition, system modularity is also required since different signals and modules could be employed.

This article intends to propose an architecture for upper limb robotic telerehabilitation in unilateral configuration. The architecture is designed to be modular and is conceived to be as general as possible, in order to be independent on the specific robotic platform employed for delivering the therapy. Moreover, the architecture is designed to work in a realistic telerehabilitation scenario where the patient and the therapist interact over the Internet, without a dedicated or special data interconnection.

The case study of a planar end-effector machine for upper limb rehabilitation named CBM-Motus³⁴ is presented; it is able to provide the patient with assistance as needed, thanks to a patient-tailored control that can monitor the patient’s motor performance and, accordingly, tune the therapy. The aforementioned architecture has been tested on seven healthy subjects performing a typical motor exercise for upper limb robot-aided rehabilitation (namely, the clock-game) in two different conditions, that is, healthy behaviour and simulated post-stroke behaviour. The article is structured as follows:

The modular architecture for upper limb robot-aided telerehabilitation is first presented;

Afterwards, the case study of application of the proposed architecture to the CBM-Motus is described;

The experimental validation on healthy subjects and results are reported and discussed in section ‘Results and Discussion’;

Conclusions and future work are finally reported.

Materials and methods

The proposed architecture for telerehabilitation systems

The purpose of outlining a general architecture for telerehabilitation systems is to provide a flexible model usable in several rehabilitation scenarios. In particular, reference applications include remotely controlled robotic systems that deliver in-home rehabilitation treatments and continuously control rehabilitation outcomes. In Figure 1, our proposed model is presented. It is composed of four subsystems: the Patient, the Therapist, the Manager and the Communication HUB.

Figure 1.

The proposed general architecture for telerehabilitation robotic systems.

Each subsystem has a specific role and its own functionalities:

The Patient subsystem is the component that physically interacts with the patient. It includes the robotic system and implements control and communication functionalities.

The Therapist subsystem is the component that interacts directly with the therapist. It enables the remote monitoring and control of the patient.

The Manager subsystem is the component that interacts directly with one of the system managers. It enables the control and the configuration of other entities and the management of users.

The Communication HUB is a component that provides different services. In particular, it implements all the functionalities required for recognizing the users and allowing them to communicate.

The four subsystems interact to provide different services, as shown in Figure 2:

A.A.A.: Authentication, Authorization and Accounting services allow controlling the access to the system. In our model, the Communication HUB is in charge of maintaining information on users (Patients, Therapists and System Managers) and allowing them to log into the system. After logging in, users can interact with the system and, based on their authorization profile, access services. Historical information on services are recorded and associated with each user for clinical (Patients and Therapist) and system management (Patients, Therapist and Managers) reasons.

Communication: This service is required to enable the data transfer between subsystems. Our model assumes that communications are mediated by the Communication HUB. This choice is motivated by several advantages: (1) it simplifies the authorization of communications, (2) it disentangles the system from the Internet reachability problem (i.e. the behind network address translation (NAT) problem, when the system shares a public Internet protocol (IP) address with other devices and it is not directly accessible without an ad-hoc configuration of the router it connects to) and (3) it simplifies the monitoring of all the actions performed on the system. It is worth noting that drawbacks as Communication HUB overload can be easily solved, for instance, by means of system repetition and load balancing.

Exercise Execution: The execution of the rehabilitation exercise is performed by the patient and supported by the Patient subsystem. In our model this task can be performed under two execution models: (1) patient-alone and (2) patient-supervised. When executed alone, the patient is not required to access the A.A.A. and the Communication services. Conversely, when supervised, the patient has to identify himself or herself and communicate through the Communication HUB with the Therapist. Even though the patient-alone model does not require access to the A.A.A. and the Communication services for its execution, the dissemination of collected data through the Communication HUB needs them.

Exercise Execution, Monitoring and Control: In the supervised execution model, our system allows the therapist to interact with the patient. This interaction can be limited to the online visualization of the exercise during its execution or it may extend further, including the online adaptation and control of rehabilitation parameters. This service requires that both the patient and the therapist use their local subsystem, and pass through the A.A.A. and the Communication services.

Exercise Execution, Logging and Log Analysis: Data generated during exercises need to be collected and made available for offline patient performance assessment. In our model, the data are collected by the Communication HUB, which implements both a database for data collection and an interface and/or a set of application programming interfaces (APIs) for data retrieval. Using the Logging and Log Analysis service, it is possible to track the evolution of patient’s performance and to make global studies on the impact of rehabilitation therapies.

Figure 2.

Telerehabilitation systems’ main services.

It is worth noting that the services presented above do not include maintenance services that involve a Manager, the Communication HUB and the Patient and/or the Therapist subsystems. These services enable a system manager to interact with the subsystems and, for instance, to change the configuration parameters of the local control in the Patient subsystem. These services will not be discussed in the following. Conversely, in the following, first we focus on the implementation of the proposed architecture combined with the CBM-Motus rehabilitation robot, including the Communication, the Exercise Execution and the Exercise Execution, Monitoring and Control services.

Implementation of subsystems

The general scheme for robot-aided telerehabilitation, previously presented in Figures 1 and 2, has been tailored to use the CBM-Motus robotic device. In particular, we used the Qt (https://www.qt.io) library to implement user interfaces (UIs), standard C libraries to manage transmission control protocol (TCP)/IP communications among subsystems and Aerotech libraries for the control of CBM-Motus motors. The libraries and the software have been tailored to run on cheap hardware settings and, indeed, all the systems developed in this work run seamlessly on Pentium 4 workstation equipped with less than 1 GB main memory.

Each subsystem presented in the previous subsection has been implemented as a software component. Hence, our telerehabilitation system based on the CBM-Motus robot is composed of Patient, Therapist, Manager and Communication HUB software components. The architecture of each software component is outlined hereafter.

Patient software component

The architecture of the patient software component is presented in Figure 3. Such a component implements the following functionalities:

It controls the robotic system;

It implements the UI for the patient;

It implements the data communication logic for patient/therapist interaction.

Figure 3.

Patient component architecture.

The architecture of the software component is composed of two tiers: (1) the Local Control Tier (LCT) that controls the robotic rehabilitation end-point and (2) the Patient Control Tier (PCT) that manages the UI, the interaction with the first tier and the remote exchange of data.

The LCT is a multilayer software component for the direct control of the robotic system. The lowest layer abstracts the hardware and implements a general software interface (HAL – hardware abstraction layer); the second layer implements local and time-critical control functionalities for the robot management (Control logic), and the highest layer (Local comm.) provides a communication interface based on standard inter-process communication (IPC), to exchange messages (commands and data) with the other tier.

The PCT is a multilayer software component that implements rehabilitation exercises (Local control), the User Interface for the patient (UI Patient) and communication functionalities (Communication Logic and Local Communication). Local communication functionalities are based on standard IPC, whereas the interaction with other rehabilitation systems, mediated by the Communication HUB, is based on the TCP/IP network protocol.

Therapist software component

The Therapist software component architecture is shown in Figure 4. It implements the following functionalities:

It allows the therapist to monitor the execution of the patient’s exercises;

It allows the therapist to change exercise parameters online.

Figure 4.

Therapist component architecture.

The architecture of the software component is composed of multiple layers. From bottom to top, the Network layer provides communication functionalities and, in particular, it is based on the TCP/IP protocol. The Communication Logic manages uplink (data) and downlink (control messages) flows, whereas the Remote Control layer maps therapist actions to commands for the patient software components. Eventually, the UI Therapist implements the graphical interface that the therapist uses to monitor and issue commands. Data messages to the therapist UI are sent by means of TCP packets at the same rate they are generated for the patient UI.

Manager software component

In the current implementation, the Manager software component allows monitoring the execution of exercises concurrently with the therapist. The architecture of the Manager software component, shown in Figure 5, is hence the same presented for the Therapist. Contrary to the Therapist, the Manager cannot issue control operation during exercises, but it is enabled to monitor exercises and command flows. Moreover, the manager manages hardware settings that are out of the scope of therapist’s actions.

Figure 5.

Manager component architecture.

Communication HUB software component

The architecture of the Communication HUB software component is shown in Figure 6. Such a component provides the following functionalities:

It manages the authentication of users;

It manages communications among other software components;

It implements a local debug console for system monitoring.

Figure 6.

Communication HUB architecture.

To implement these functionalities, the Communication HUB relies on a three-layer architecture. The Network and the Communication Logic layers implement a TCP/IP service to which all the other software components (Patient, Therapist and Manager) can connect. The Auth Logic sublayer controls if a given software component is allowed to connect and which role it has. The Hub Logic sublayer dispatches messages (data and commands) among the connected subsystems.

The CBM-Motus

The CBM-Motus is a planar end-effector machine for upper limb rehabilitation (Figure 7) conceived to address the following main requirements: low and isotropic inertia, simplicity in the mechanical structure, lightness and compactness in order to enable portability and low cost to favour home usage.³⁴ It has a Cartesian kinematic structure consisting of two modules connected by a double prismatic joint each corresponding to an actuated axis (i.e. x and y axes). Each module includes six pulleys with the same radius (25 mm) and two belts.^35,36 The double prismatic joint ensures that only stretching (tensile) forces are transmitted to the belts. In this fashion, only the component of the force that is orthogonal to the same bar can be transmitted to each bar; consequently, the bar stretches the belts but it does not bend them.³⁵ The total mass of the robot (frame and motors included) is less than 30 kg. Further details on robot design and functionalities can be found in the work by Zollo et al.³⁴

Figure 7.

Overview of CBM-Motus.

The robot control belongs to the category of assist-as-needed control paradigm;^37,38 hence, it aims at providing the patient with the minimum level of assistance needed to accomplish the task, by monitoring the patient’s status by means of performance indicators. Therefore, an impedance control with adjustable parameters has been implemented. It can be written as follows

τ = B (q) y + F_{v} \overset{\cdot}{q} + F_{s} sign (\overset{\cdot}{q})

(1)

with

y = M_{d}^{- 1} (M_{d} {\overset{\cdot\cdot}{q}}_{d} + K_{P} \tilde{q} + K_{D} \overset{\cdot}{\tilde{q}})

(2)

In equation (1), $τ$ is the torque command, B is the inertia matrix (independent of robot configuration), $F_{v} \overset{\cdot}{q}$ and $F_{s} sign (\overset{\cdot}{q})$ are dynamic and static friction torques, respectively, which are non negligible in the CBM-Motus dynamics.³⁴ However, y represents the stabilizing action that makes the robot behave as a generalized mechanical impedance regulated by mass matrix $M_{d}$ , stiffness matrix $K_{P}$ and damping matrix $K_{D}$ .

The control is tailored to the subject’s motion abilities by updating stiffness matrix $K_{P}$ during the therapy and time allotted for task execution t.³⁹ To this purpose, a set of performance indicators has been selected for a quantitative evaluation of the subject’s biomechanical behaviour⁴⁰ and employed to adjust control parameters. Position and velocity sensors embedded into the robot are employed to record hand position and velocity in the planar space and, later, compute performance indicators.

The two control parameters (i.e. $K_{P}$ and t) are progressively updated, based on the values acquired by modulation functions $C_{K}$ and $C_{t}$ , expressed as

C_{K} = \frac{3}{5} α + \frac{1}{4} AREA + \frac{1}{4} nMD

(3)

C_{t} = \frac{3}{10} MAPR + \frac{1}{4} SpeedMetric + \frac{1}{6} MD

(4)

They are weighted sums of a few of the aforementioned performance indicators where $(α)$ is the Aiming angle, AREA is the area between the desired and the actual trajectory performed by the subject, nMD is the normalized mean deviation from desired path, MAPR (Mean Arrest Period Ratio) represents the proportion of time (i.e. the percentage of samples) that movement speed exceeds 10% of the peak speed, SpeedMetric expresses the ratio between mean speed and peak speed and MD is movement duration. The weights have been chosen through a trial and error approach; the Aiming angle and the MAPR have greater weights than the others as they are more indicative of a pathological behaviour versus a healthy behaviour in terms of required assistance (through $C_{K}$ ) and movement velocity (through $C_{t}$ ).

A threshold strategy is then applied to set the value of control parameters. This takes into account that equations (3) and (4) continuously vary in the interval $[0; 1]$ . Therefore, the discrete levels $(L_{i})$ of patient performance for updating $K_{P}$ and t are defined as

L_{i} = {\begin{matrix} 1 if C_{i} \in [0, 0.25) \\ 2 if C_{i} \in [0.25, 0.5) \\ 3 if C_{i} \in [0.5, 0.75) \\ 4 if C_{i} \in [0.75, 1] \end{matrix}

where $i = K, t$ . Values of $L_{k}$ and $L_{t}$ are automatically associated with predetermined values of stiffness and task duration. Depending on $L_{i}$ , $K_{P}$ can assume one of the following four values: 1, 25, 75 or 120 N/m, while task duration t can be equal to 1000, 2000, 2500 or 3000 ms. All these values were empirically derived, in a way similar to previous studies on a similar topic.³⁹

The global system is shown in Figure 8. The scheme shows the main blocks involved in the integration of the CBM-Motus and the proposed architecture. Low latency controls are implemented in the LCT, while exercise-wide parameters (e.g. the activation of the feedback forces) are managed by the PCT. The PCT performs the update of exercise parameters directly or under the control of the Therapist. The exchange of data is mediated by the Communication HUB. The granularity of viable control depends on the latency and the bandwidth exhibited by the Patient-to-Therapist and Therapist-to-Patient communication channels.

Figure 8.

The modular architecture for telerehabilitation applied to the CBM-Motus rehabilitation robot. The patient side includes the robot and the patient–robot interaction modules; the therapist side includes evaluation and therapy modules, allowing therapy definition based on the evaluation of the patient, thanks to quantitative performance indicators and clinical scales.

Experimental trials

The patient-alone configuration of the Patient subsystem has been thoroughly evaluated. Seven healthy subjects have been asked to perform typical upper limb robotic exercises, for example, clock-game.^8,10 Each session consists of 160 point-to-point movements in 8 different directions rotated at 45°. They are grouped into 80 trials performed without assistance, in order to measure subject performance and update control parameters, and 80 trials performed with a level of assistance tailored to the patient status (described through the computed performance indicators).^39,40 The session of 160 point-to-point movements has been repeated under two different conditions, that are, (1) healthy behaviour and (2) simulated post-stroke behaviour.

In order to make the results comparable among the subjects and ensure repeatability of the performed trials, the simulated post-stroke behaviour was implemented by applying a constraint on the healthy subjects. It consists of an elastic sling applied on the subject’s arm between the forearm (12 cm below the elbow joint) of the ipsilateral arm and the axilla of the contralateral arm.

The resulting elastic force was not exactly quantified due to the unknown elastic constant of the sling. However, it is assumed to be in the range [15, 30] N. The proposed constraint intends to increase the difficulty of elbow flexion/extension movements, which are the most affected movements after a stroke event.

Moreover, elastic force of the band strictly depends on its length and the length of user arm. No adjustments regarding arm-length or subject-based strength have been performed; such an aspect might have introduced an appropriate amount of uncertainty.

Hence, subjects were asked to perform 80 point-to-point movements without robot assistance ( $K_{P} = 1 N / m$ and $t = 3000 ms$ ). Position and velocity acquired by robot sensors were sent from the patient side to the therapist side for computing performance indicators.

The performance indicators have a twofold purpose: (1) evaluation of the therapy progress; (2) adaptation of the level of assistance to the patient condition, by updating control parameters through equations (3) and (4). Afterwards, control parameters $K_{P}$ and t were sent to the patient side and the block of 80 assisted point-to-point movements was performed again. It has been decided to carry out calculations at the therapist side in order to give the therapist a complete overview of the therapy process and not to overload the PCT with computational efforts which can be easily carried out on therapist side. Such solution is implemented in this modular way since the application is thought to be employed for in-home rehabilitation sessions where the patient and therapist are not in the same place.

Limits of the proposed architecture in Internet scenarios were investigated by means of modelling. Real data obtained from tests were used to fill the model and characterize the system. In particular, we focused on the assessment of the Patient-Therapist-Patient control loop. The aim was to quantify the level of control that can be applied under realistic communication constraints. We measured the computation time required to calculate performance indicators in the following three different conditions:

For the single point-to-point movement;

For a block of 16 movements (i.e. one repetition of the whole clock-game);

For a block of 80 movements (i.e. five repetitions of the clock-game).

Furthermore, we extracted the time required for transmitting data and commands between the Patient and Therapist. These times can be used to compute closed-loop communication delays and characterize applicable control strategies. In particular, a single control loop requires the following:

The generation of patient’s data: $T_{P}$ ;

The full transmission of such data to the Communication HUB: $T_{P \to H}$ ;

Reception and decoding of the patient’s data: $T_{H}$ (the Communication HUB identifies the sender and the receiver and dispatches the received packet to its transmission queue);

The full forwarding of data to the therapist: $T_{H \to T}$ ;

The computation of performance indicators and updated parameters: $T_{T}$ ;

The full transmission of updated parameters to the Communication HUB: $T_{T \to H}$ ;

Reception and decoding of the therapist’s data: $T_{H}$ ;

The full forwarding of data to the patient: $T_{H \to P}$ ;

The application of new parameters: $T_{A}$ .

Assuming that (1) $T_{P} \approx 0$ , that is, the generation of data is done while the exercise is executed; (2) $T_{H} \approx 0$ , that is, Communication HUB packet forwarding times negligible (the required time is that required to make very few memory accesses and can be easily controlled and maintained negligible with respect to other times); and (3) $T_{A} \approx 0$ , that is, the update of available parameters has negligible time, we can write that as

T_{LOOP} = T_{P \to H} + T_{H \to T} + T_{T} + T_{T \to H} + T_{H \to P}

(5)

This time has to be lower than the maximum waiting time that the patient can accept during exercise phases involved in parameters update.

Results and discussion

In this section, results obtained from the experimental validation of the proposed telerehabilitation architecture are reported. First, the results of the assist-as-needed exercises performed with the CBM-Motus are shown and then the results of the communication tests between patient and therapy sides are reported.

As regards the experimental trials carried out with the CBM-Motus, hand trajectories and velocities in the Cartesian space of one subject are shown for unassisted healthy, unassisted simulated post-stroke condition and assisted simulated post-stroke behaviour (Figures 9 –11). As expected, after adaptation of control parameters, simulated post-stroke behaviour tends to the healthy one in terms of trajectories as well as of velocity and smoothness. Moreover, since post-stroke subjects typically have higher motion difficulty in directions requiring elbow extension, it has been chosen to show NW (NorthWest) hand velocity trajectories to highlight performance improvement after control parameters update.

Figure 9.

Subject 1 performing 80 repetitions of the clock-game in healthy condition: Cartesian position (upper left side), Cartesian velocity (right upper side), x component of hand velocity over time during NW forward/backward movement (lower left side) and y component of hand velocity over time during NW forward/backward movement (lower right side).

Figure 10.

Subject 1 performing 80 repetitions of the clock-game in unassisted simulated post-stroke condition: Cartesian position (upper left side), Cartesian velocity (right upper side), x component of hand velocity over time during NW forward/backward movement (lower left side) and y component of hand velocity over time during NW forward/backward movement (lower right side).

Figure 11.

Subject 1 performing 80 repetitions of the clock-game in assisted simulated post-stroke condition: Cartesian position (upper left side), Cartesian velocity (right upper side), x component of hand velocity over time during NW forward/backward movement (lower left side) and y component of hand velocity over time during NW forward/backward movement (lower right side).

In Figure 12, a bar plot of the selected performance indicators is shown for both unassisted and assisted movements taking into account mean values and standard deviation. Even though no clinical considerations can be extracted from these data, the indicator trend confirms the expected improvements between unassisted and assisted tasks, especially observing the simulated post-stroke behaviour. Moreover, it shows the efficacy of the control modulated by the therapist side and the functioning of the proposed telerehabilitation architecture.

Figure 12.

Mean values and standard deviations of performance indicators for all the subjects before and after updating control parameters. They are reported both for healthy (left) and simulated post-stroke condition (right).

The characterization of the Patient-Communication HUB-Therapist control loop is based on data reported in Table 1. The table presents mean and standard deviations of computation times required to update control parameters, and the size of data transferred between the patient and the therapist in order to perform this computation and to apply results back into the Patient subsystem. In particular, we extracted these data considering an update operating between the following three groups of elementary actions: (1) the single movement scenario, (2) the 16 movements scenario and (3) 80 movements scenario. Based on these data, we can compute an upper bound of the closed-loop time for parameters update as

T_{LOOP} = 2 \times T_{ping} + 2 \times T_{P \to T}^{tx} + 2 \times T_{T \to P}^{tx} + T_{T}

where we used equation (5) assuming that each direct data exchange is composed of two components: $T_{ping} / 2$ , the time required to send a short packet from two generic entities of the system (it can be estimated by means of the standard ping command) and $T_{Source \to Destination}^{tx} = Message size / Communication rate$ . Being interested in an upper bound, we assume that the aforementioned parameters are all equal to those of the worst direct interconnection among subsystems.

Table 1.

Architecture validation: computational time for updating control parameters (mean and standard deviation (SD)) and file size of the information exchanged throughout the architecture blocks.

Trial	Time (mean), s	SD, s	File size P → T	File size from T → P
Single movement	0.23	0.01	8 B	K_P = 3 B, t = 5 B
16 movements	1.48	0.04	118 kB	K_P = 3 B, t = 5 B
80 movements	6.52	0.23	622 kB	K_P = 3 B, t = 5 B

SD: standard deviation.

Tables 2 –4 present values of the time required for the closed-loop update of parameters in the case of the configurations of Table 1 and considering different values of $T_{ping}$ (columns) and $communication rate$ (rows). The results show that, in the case of updates between single movements, the most critical parameter is the communication delay between systems and, indeed, if we assume that the maximum waiting time acceptable between single movement is 500 ms, all the communication rates provide acceptable results, given that T_ping = 50 or 100 ms (i.e. given that the communication latency is low enough).

Table 2.

Closed-loop parameters update times (single movement).

	50 ms	100 ms	250 ms	450 ms
256 kbps	331 ms	431 ms	731 ms	1131 ms
1 Mbps	330 ms	430 ms	730 ms	1130 ms
10 Mbps	330 ms	430 ms	730 ms	1130 ms

Table 3.

Closed-loop parameters update times (16 movements).

	50 ms	100 ms	250 ms	450 ms
256 kbps	7.7 s	7.8 s	8.1 s	8.5 s
1 Mbps	2.2 s	2.3 s	2.6 s	3.0 s
10 Mbps	0.52 s	0.62 s	0.9 s	1.1 s

Table 4.

Closed-loop parameters update times (80 movements).

	50 ms	100 ms	250 ms	450 ms
256 kbps	39.2 s	39.3 s	39.6 s	40 s
1 Mbps	10.3 s	10.4 s	10.7 s	11.1 s
10 Mbps	1.33 s	1.42 s	1.72 s	2.13 s

When the amount of data communicated between systems increases, the results change and the most critical parameter is the transmission rate. If we assume that the maximum waiting time acceptable between 16 movements (80 movements) is 2 s (20 s), all the configurations having a communication rate equal to 10 Mbps (1 or 10 Mbps) are valid, independent of the $T_{ping}$ value.

Results demonstrate the feasibility and limits of the proposed architecture for upper limb robotic telerehabilitation. The implemented system is able to send data and compute performance indicators in a safe and reliable way. In this condition, the subject who is performing the robot-aided exercise has enough time to accomplish the required task being involved also by means of visual feedback.

Being a preliminary phase, the computation of performance indicators has been executed in an offline modality and therefore communication stability has been proved by the aforementioned tests. Obvious extension of the proposed architecture will be the computation of the performance indicators and the update of control parameters in a real-time environment. This will allow the therapist to monitor and evaluate the therapy in a simultaneous way by setting the type of exercise, the level of difficulty and the needed robot assistance depending on the specific patient’s condition.

Conclusion

This article has presented a novel modular architecture for telerehabilitation. The architecture has been conceived to be as general as possible in order to be adapted to different telerehabilitation scenarios, including or not including the robot. The modular architecture has been applied to the CBM-Motus, a planar robot for upper limb rehabilitation previously developed by the authors, controlled through an assist-as-needed control. The experimental validation on healthy subjects simulating a post-stroke behaviour has demonstrated the functioning and reliability of the novel architecture, as well as the modularity of the proposed system able to be tailored to different unilateral robot systems. Tests performed with the CBM-Motus encourage the potential use of the implemented system in a clinical scenario. To this purpose, future studies on post-stroke subjects’ in-home telerehabilitation programmes will be taken into account in order to enhance patients’ independence and encourage faster recovery from stroke.

Footnotes

Academic Editor: Nicolas Garcia-Aracil

Declaration of conflicting interests

The author(s) declared no potential conflicts of interest with respect to the research, authorship, and/or publication of this article.

Funding

The author(s) disclosed receipt of the following financial support for the research, authorship, and/or publication of this article: This work was supported by the National Project Industria 2015 – DAHMS (Distributed Architecture Home Modular Multifunctional Systems), CUP B85E10003020008 and by European Project H2020/AIDE: Multimodal and Natural Computer Interaction Adaptive Multimodal Interfaces to Assist Disabled People in Daily Activities, CUP J42I15000030006.

References

Mozaffarian

Roger

. Heart disease and stroke statistics–2014 update: a report from the American Heart Association. Circulation 2014; 129: e28–e292.

Ovbiagele

Goldstein

Higashida

. Forecasting the future of stroke in the United States a policy statement from the American Heart Association and American Stroke Association. Stroke 2013; 44: 2361–2375.

Thorsen

Holmqvist

Von Koch

Early supported discharge and continued rehabilitation at home after stroke: 5-year follow-up of resource use. J Stroke Cerebrovasc Dis 2006; 15: 139–143.

Langhorne

Widen-Holmqvist

Early supported discharge after stroke. J Rehabil Med 2007; 39: 103–108.

Basteris

Nijenhuis

Stienen

. Training modalities in robot-mediated upper limb rehabilitation in stroke: a framework for classification based on a systematic review. J Neuroeng Rehabil 2014; 11: 111.

Maciejasz

Eschweiler

Gerlach-Hahn

. A survey on robotic devices for upper limb rehabilitation. J Neuroeng Rehabil 2014; 11: 3.

Accoto

Carpino

Sergi

. Design and characterization of a novel high-power series elastic actuator for a lower limb robotic orthosis. Int J Adv Robot Syst 2013; 10: 359.

Krebs

Hogan

Aisen

. Robot-aided neurorehabilitation. IEEE Trans Rehabil Eng 1998; 6: 75–87.

Kwakkel

Kollen

Krebs

HI.

Effects of robot-assisted therapy on upper limb recovery after stroke: a systematic review. Neurorehabil Neural Repair 2007; 22: 111–121.

10.

Guarino

Richards

. Robot-assisted therapy for long-term upper-limb impairment after stroke. New Engl J Med 2010; 362: 1772–1783.

11.

Hesse

Waldner

Mehrholz

. Combined transcranial direct current stimulation and robot-assisted arm training in subacute stroke patients an exploratory, randomized multicenter trial. Neurorehabil Neural Repair 2011; 25: 838–846.

12.

Klamroth-Marganska

Blanco

Campen

. Three-dimensional, task-specific robot therapy of the arm after stroke: a multicentre, parallel-group randomised trial. Lancet Neurol 2014; 13: 159–166.

13.

Reinkensmeyer

Pang

Nessler

. Web-based telerehabilitation for the upper extremity after stroke. IEEE Trans Neural Syst Rehabil Eng 2002; 10: 102–108.

14.

Carey

Durfee

Bhatt

. Comparison of finger tracking versus simple movement training via telerehabilitation to alter hand function and cortical reorganization after stroke. Neurorehabil Neural Repair 2007; 21: 216–232.

15.

Zhang

Austin

Buchanan

. Feasibility studies of robot-assisted stroke rehabilitation at clinic and home settings using RUPERT. In: Proceedings of the IEEE international conference on rehabilitation robotics (ICORR), Zurich, 29 June–1 July 2011, pp.1–6. New York: IEEE.

16.

Fluet

Deutsch

JE.

Virtual reality for sensorimotor rehabilitation post-stroke: the promise and current state of the field. Curr Phys Med Rehabil Reports 2013; 1: 9–20.

17.

Butler

Bay

. Expanding tele-rehabilitation of stroke through in-home robot-assisted therapy. Int J Phys Med Rehabil 2014; 2:1–11.

18.

Carignan

Krebs

HI.

Telerehabilitation robotics: bright lights, big future?

J Rehabil Res Dev 2006; 43: 695–710.

19.

Lai

Woo

Hui

. Telerehabilitation: a new model for community-based stroke rehabilitation. J Telemed Telecare 2004; 10: 199–205.

20.

Brennan

Mawson

Brownsell

Telerehabilitation: enabling the remote delivery of healthcare, rehabilitation, and self management. Stud Health Technol Inform 2009; 145: 231–248.

21.

Sivan

Gallagher

Makower

. Home-based Computer Assisted Arm Rehabilitation (hCAAR) robotic device for upper limb exercise after stroke: results of a feasibility study in home setting. J Neuroeng Rehabil 2014; 11: 163.

22.

Chen

Jin

Zhang

. Telerehabilitation approaches for stroke patients: systematic review and meta-analysis of randomized controlled trials. J Stroke Cerebrovasc Dis 2015; 24: 2660–2668.

23.

Johnson

MJ.

Recent trends in robot-assisted therapy environments to improve real-life functional performance after stroke. J Neuroengineering Rehabil 2006; 3: 29.

24.

Cordo

Lutsep

Cordo

. Assisted movement with enhanced sensation (AMES): coupling motor and sensory to remediate motor deficits in chronic stroke patients. Neurorehabil Neural Repair 2008; 23: 67–77.

25.

Popescu

Burdea

Bouzit

. A virtual-reality-based telerehabilitation system with force feedback. IEEE Trans Inf Technol Biomed 2000; 4: 45–51.

26.

Jadhav

Krovi

A low-cost framework for individualized interactive telerehabilitation. Conf Proc IEEE Eng Med Biol Soc 2004; 2: 3297–3300.

27.

Scattareggia

Macellari

Hermens

. ICT solutions for the management of chronic diseases: the Habilis concept and the CLEAR project. In: Cunningham

Cunningham

(eds) Proceedings of the eChallenges transactions conference, International Information Management Corporation Ltd (IIMC), Warsaw, Poland, 27–29 October 2010. ISBN: 978-1-905824-20-5.

28.

Wolf

Sahu

Bay

. The HAAPI (Home Arm Assistance Progression Initiative) trial a novel robotics delivery approach in stroke rehabilitation. Neurorehabil Neural Repair 2015; 29: 958–968.

29.

Linder

Rosenfeldt

Bay

. Improving quality of life and depression after stroke through telerehabilitation. Am J Occup Ther 2015; 69: 6902290020p1–6902290020p10.

30.

Basdogan

Srinivasan

. An experimental study on the role of touch in shared virtual environments. ACM T Comput: Hum Int 2000; 7: 443–460.

31.

Goncharenko

Svinin

Matsumoto

. Cooperative control with haptic visualization in shared virtual environments. In: Proceedings of the 8th international conference on information visualisation, London, 14–16 July 2004, pp.533–538. New York: IEEE.

32.

Kim

Tay

. Transatlantic touch: a study of haptic collaboration over long distance. Presence 2004; 13: 328–337.

33.

Langhorne

Taylor

Murray

. Early supported discharge services for stroke patients: a meta-analysis of individual patients’ data. Lancet 2005; 365: 501–506.

34.

Zollo

Salerno

Vespignani

. Dynamic characterization and interaction control of the CBM-Motus robot for upper-limb rehabilitation. Int J Adv Robot Syst 2013; 10: 374.

35.

Zollo

Accoto

Torchiani

. Design of a planar robotic machine for neuro-rehabilitation. In: Proceedings of the IEEE international conference on robotics and automation, Pasadena, California, 19–23 May 2008, pp.2031–2036. New York: IEEE.

36.

Accoto

Torchiani

Guglielmelli

. Dispositivo per la terapia motoria robot-mediata dell?arto superiore. Patent RM2008A000242, Italy, 2008.

37.

Hogan

Krebs

HI.

Interactive robots for neuro-rehabilitation. Restor Neurol Neurosci 2003; 22: 349–358.

38.

Zollo

De Luca

Siciliano

. Regulation with on-line gravity compensation for robots with elastic joints. In: Proceedings of the IEEE international conference on robotics and automation, New Orleans, LA, 26 April–1 May 2004, pp.2687–2692. New York: IEEE.

39.

Papaleo

Zollo

Spedaliere

. Patient-tailored adaptive robotic system for upper-limb rehabilitation. In: Proceedings of the IEEE international conference on robotics and automation, Karlsruhe, Germany, 6–10 May 2013, pp.3860–3865. New York: IEEE.

40.

Zollo

Gallotta

Guglielmelli

. Robotic technologies and rehabilitation: new tools for upper-limb therapy and assessment in chronic stroke. Eur J Phys Rehabil Med 2011; 47: 223–236.

A modular telerehabilitation architecture for upper limb robotic therapy

Abstract

Keywords

Introduction

Materials and methods

The proposed architecture for telerehabilitation systems

Implementation of subsystems

Patient software component

Therapist software component

Manager software component

Communication HUB software component

The CBM-Motus

Experimental trials

Results and discussion

Conclusion

Footnotes

Declaration of conflicting interests

Funding

References