Closed loop development framework

The CLF was implemented using a graphical programming language (Simulink) that is part of the Matlab 2013a (MathWorks, Natick, US-MA) software package.

Additionally, Simulink 3D Animation, Simulink Coder, Signal Processing, and Real Time Windows Target toolboxes were used (RTWT). The framework is structured as a library of components that seamlessly integrate into the already existing Simulink Library Browser (Figure 2.5):

 The input interface library implements the generation, acquisition, and preprocessing (e.g., baseline removal, normalization, filtering) of the signals from different information sources (e.g., muscle activity, joystick, data file, predefined signal).

 The control method library implements the mapping from the input level to the system level commands. More precisely, it integrates a variety of control interfaces (e.g., proportional or state-machine control) that translate the input to corresponding system activation (e.g., DoF activation).

 The system library encapsulates a low-level interface to the real or simulated system that is controlled in the closed-loop system. The block defines intrinsic system parameters and the mapping between the control signals and the available system DoFs, defining which control input controls which system function (e.g., for prosthesis: Input1 controls hand opening/closing, Input2 wrist rotation, etc.).

 The experimental task library compares the current versus a desired system state, as defined by the system block and the goal of the experiment, respectively. It operates in two modes: pursuit and compensatory. Based on the operation mode it determines which signal should be fed back to the user (e.g., in pursuit mode the output will be the desired and the current system state;

whereas in the compensatory mode the output will be the error).

 The information-coding library translates the normalized feedback information signals into normalized stimulation parameters (i.e., frequency and intensity) for a generic multichannel feedback device. This library is one of the core CLF features since it allows for designing and reusing any custom-made coding scheme (e.g., intensity or spatial coding), independent of the underlying hardware interface.

 The feedback interface library encapsulates a low-level communication with a

device that is used to deliver the feedback (e.g., visual, tactile, sound). Each block inside of it sends device specific commands to adjust the stimulation parameters to the normalized frequency and intensity values supplied by the information-coding block.

 The signal-processing library implements the most common signal processing features such as signal filtering, normalization, artefact removal, etc.

 The model-configuration library integrates components that are designed to govern the overall model execution (e.g., simulation duration, sampling times, etc.) and data logging of simulation signals and model parameters.

Figure 2.5: a) The structure of the closed-loop development framework (CLF). The implemented components are divided into eight different libraries organized into separate folders. Each component follows the same structural organization consisting of a component-model (.slx) and dependencies folders. Custom-designed CLSs are saved in a separate folder tree (test bench models). b) CLF integrated in Simulink Library Browser. In order to use it, the user needs to navigate to the desired component and simply drag and drop it into his model.

The main features of the CLF (Figure 2.6) are:

 Execution in hardware real-time with sampling frequencies of up to 20 KHz [85], such that the system guarantees that a certain process will finish within the prescribed amount of time.

 High-level user customization, yet transparent system operation. Each block has its own GUI with appropriate customization options. The transparency of execution is achieved by associating the block functions with an intuitive icon.

Additionally, the most relevant component settings (e.g., execution frequency) are annotated in red text on the icon itself.

 Interoperability of system components, such that the blocks can be exchanged freely, without breaking the system functionality. This is achieved by utilizing normalized inputs and outputs (I/O signals are always between [-1, 1]).

 Centralized high-level system management. The CLF takes care of data logging (via DataLogging tags), execution flow, and model configuration (e.g., execution duration, sampling frequency, compiler settings, etc.).

Additionally, the CLF utilizes programming templates/style guidelines and has extensive documentation about the core system features as well as the specific component functionalities.

In an exemplary CLS setup given in Figure 2.6, the user employs a joystick to proportionally control the prosthesis’ opening or closing speed by regulating its inclination angle to the left or right, respectively. The experimental task is configured as compensatory tracking of a predefined profile with the generated prosthesis force as the input. This means that the user’s task is to match the prosthesis grip force according to the tracking profile. If he is successful, the resulting output of the experimental task block will be close to zero. The output of the experimental task is fed to the information-coding block that maps the sign of the error to one of the two available vibrotactile C2-tactors (residing on ulnar and radial part of the user’s lower arm) and the error’s amplitude to the intensity of the tactile stimulation. The user will thus feel the error as the intensity of vibration. This simple CLS setup can be used to understand the complex processes behind closed-loop prosthesis control. Namely, by simply exchanging a few blocks: e.g., the real prosthetic hand with the virtual one, the joystick with myoelectric interface, the vibro-tactile with an electro-tactile device or intensity with frequency coding, it would be possible to independently evaluate all contributing

factors (i.e., the control interface, the control system, the information coding and the feedback modality) on the overall closed-loop performance. Importantly, since they are interoperable and use normalized I/O, exchanging the blocks within the system is as easy as performing a drag and drop operation from the Simulink Library Browser.

Likewise, since the CLF logs the user-selected signals, the scripts used for data analysis can remain virtually unaltered as long as the experimental task does not change; also, the experimental-setup that was used for data acquisition can always be easily reconstructed because the model-specific parameters and settings are automatically saved.

Figure 2.6: An exemplary closed-loop system setup used for evaluating the human performance in steering the prosthesis’ force while utilizing tactile feedback. The flash symbols indicates that the additional, component-specific, settings open once the annotated component is double-clicked (customization). Each component has an intuitive icon and displays its most important parameters in red (transparency of operation). The overall CLS model execution is configured within a single block. The model will automatically compile and execute as soon as the START button is double clicked (centralized high-level system management). The data logging block logs the model settings automatically (e.g., component and model parameters) as well as the user-selected signals.