Determining delay created by multifunctional prosthesis controllers.

I am writing to express a concern that my colleagues from previous laboratories at Northwestern University/Rehabilitation Institute of Chicago (RIC) and I have shared for a number of years related to multifunctional prosthesis control. Previous investigations have used a variety of analysis window attributes for their multifunctional prosthesis controllers [1-8]. Researchers have varied the length of the analysis window, the amount of overlap between consecutive windows, and the number of majority votes used in the post-processing of the classifier decisions. However, we believe that many researchers have made decisions about these attributes with little regard for the overall delay created in the real-time system. (Note that the term classifier typically refers to an element of the controller that uses the inputs provided to it, e.g., electromyographic [EMG] signals, force sensor data, and position sensor data to decide which joint(s) of the prosthesis should be actuated.) For example, Peleg et al. performed classification decisions on data up to 1.4 seconds after the onset of the contraction [9]. This classifier would require its user to wait on the order of seconds for Peleg et al.'s prosthesis to respond, which would likely be quite frustrating for the user. We are not suggesting that new algorithms should not be explored simply because they may create substantial delays. However, we do believe that these delays should be considered and discussed in each article that is published on this topic. While a particular classifier may create a 1 percent increase in classification accuracy, if it cannot add this increase in accuracy in a reasonable amount of time, it may be a "nonstarter." Continuing in this vein, we would like to discuss some findings that we believe will allow prosthesis controller designers to better understand how their controllers will behave in real time. (For the purpose of this editorial, further use of "we" and "our" indicates my colleagues and me.) This editorial focuses on analysis window issues from the perspective of EMG-based multifunctional prosthesis control. However, the work described can be extended to other forms of window-based biosignal classifiers, such as brain machine interfaces that use neural spike-counting algorithms for intracortical data [10-12] or those that use electroencephalogram recordings [13-14]. BACKGROUND AND VARIABLE DEFINITION Many readers may be familiar with multifunctional prosthesis classifiers, but I would like to provide a brief introduction for those who are new to the area. Many multifunctional prosthesis controllers analyze EMG signals collected from the residual limb in an attempt to determine the intended movement of the user. These controllers use EMG data to decide which degree of freedom will be actuated and then produce motor-drive signals for the corresponding joint of the prosthesis. Classifiers typically make these decisions by comparing data collected in real time to data collected during a training session. Generally, the movement of the prosthesis whose training data best match the current real-time data sample is then selected as the output of the classifier. These class decisions can then be used for determining the "classification accuracy" of a classifier, which is defined as the percentage of the time that the output of the controller matches the intended movement of the user. Huang et al. provide a detailed description of the various steps of the classification process [15]. Some previous work has shown that classification accuracy increases when EMG feature extraction and pattern recognition are performed on larger data windows [1]. However, when more EMG data are collected for analysis, more time is required to collect and then process the larger data set. This collection and processing time increases the delay between the user producing a command and the controller responding appropriately. If this delay becomes excessive, it can make the prosthesis feel sluggish and unresponsive to the user. …