D2.1 Requirements and Specification - CORBYS

Recommendations

Info

D2.1 Requirements and Specification The g.SAHARA (Figure 41(a)) electrode system, a g.tec product, consists of an 8 pin electrode made of a special golden alloy. The golden alloy and the 8 pins reduce the electrode-skin impedance. EEG recordings are performed at frontal, central, parietal and occipital regions of the head (a mechanical system is required that holds the electrode to the skin with a constant pressure at every possible recording location) (g.tec Technologies, n.d). The g.SAHARA can be used in combination with the g.MOBIlab+ (Figure 41(b)), a portable biosignal acquisition and analysis system. Figure 41: Dry and portable recording EEG system provided from g.tech: dry electrodes (left) and a portable bioginal acquisition and analysis system (right) 15.3 Software for Noninvasive BrainComputer Interfaces Although the field of brain-computer interfaces is relatively young, significant research has been developed in the design of models and components to control interfaces and devices (see [Berger, 2008] for review). Despite this being a key point for the development and deployment of BCI-controlled devices, very little work has been devoted to design general, modular, and flexible software architectures for BCI (Mason et al, 2007). On one hand, the major existing BCI frameworks are very constrained in terms of usability and scalability. Some of these frameworks have been developed by private companies as small demonstrators of their technologies, being basically assessors of their provided hardware (g.tec Technologies, n.d; BioSig Project, n.d). Very specific open-source systems exist for biomedical signal processing and biosignal analysis, such as Matlab toolboxes (Delorme & Makeig, 2004) or software libraries (BioSig Project, n.d). The OpenEEG (OpenEEG, n.d) is an open-source project that promotes the creation of amateur software for neurofeedback using OpenEEG hardware designs. OpenEEG software is very specific and simple, but with a lack of a common architecture, incomplete documentation and that has not been extensively tested (OpenEEG, n.d). In addition, some other companies have developed proprietary software architectures for neurofeedback (BioEra, n.d.; BioExplorer, n.d.; Soft-dynamics, n.d.; Zengar Institute Inc., n.d.). Recently, other three software platforms have been proposed: BCI++ (Maggi et al, 2008), BF++ (Brainterface, n.d.) and OpenViBE (Renard, 2010). The first one is a C/C++ framework for designing a BCI system, it also includes some 2D/3D features for BCI feedback. The second one is another C++ framework originally oriented towards neurofeedback applications, although later versions can support any kind of BCI system. The latter has rapidly emerged in the last few years, it has a set of software modules that can be easily and efficiently integrated to design BCI for both real and virtual environments. It is highly modular and operates independently from the different software targets and hardware devices. Anyway its graphical interface is still not intuitive and usable for non-programmers users. On the other hand, BCI2000 (Schalk et al, 2004) is the result of a joint effort of several laboratories and is currently the most utilised worldwide software platform for BCI. 152
D2.1 Requirements and Specification High-level Tools: Usability is a crucial part for a BCI software platform and its acceptance and spread relies on how easy-to-use the platform is for both non-programmers and developers. As a result, such a platform should provide its users with high-level tools featured by flexibility to customise the software and build different applications, as well as usability for non-programmers. As illustrated in Table 4, some examples exist. However, many of them require programming skills (e.g. code skeleton generators, Matlab analysis tools), while those aimed at non-programmers are too complex and limited (e.g. scene editors). The innovation at this point would be to develop graphical tools in a user-centred approach and minimise third party dependencies. Facing the use cases of both programmers and non-programmers, the major requirements would be captured. Those requirements must lead the development of this kind of tools to obtain powerful as well as usable software applications that support flexible BCI designs. Technological Gaps in Merging Non-Invasive BCI and Robotics: A software analysis of BCI systems of standard requirements (Mason et al, 2007) applied to this platform reveals, however, some limitations when used as a general software architecture and in particular in the context of the robotic project CORBYS: 1. Recording software: only one recording technique can be used at a time for one application (e.g., EEG or MEG). This makes complex testing or validating a complementary approach to control devices. 2. Only one type of neural paradigm can be processed at a time: As a result, it is not possible to use multiple control channels simultaneously (e.g., simultaneous robot control and online robot error recognition). 3. It is a one-processing technique: a single signal-processing module can be processed simultaneously, which is a limitation in applications with redundant processing modules (for a given neural paradigm) or with parallel processing (of several paradigms as in the previous example). 4. It is single application software: only one device can be controlled at a time, which prevents the development of applications where humans control several devices simultaneously (e.g., two arms for manipulation). 5. It does not have interaction functionalities with other software architectures. This type of interface will open the possibility of interaction with other systems and re-using many existing algorithms already present in robotics architectures such as Stage/Player (Gerkey et al, 2003), OROCOS (Bruyninckx, 2011), CARMEN (Montemerlo et al, 2003), ROS (ROS.org, n.d.) or CoolBOT (CoolBOT Project, n.d.) . 6. Non portable and single-platform: it relies on third party component for compilation and execution (it can only be compiled in Borland under Windows operating system). 7. Lack of high-level tools: it does not provide graphical tools or software components aimed at nonprogramming users in order to facilitate construction and customisation of BCI applications. Table 4: Main platform comparison 153
Page 1 and 2:
CORBYS Cognitive Control Framework
Page 3 and 4:
D2.1 Requirements and Specification
Page 5 and 6:
Page 7 and 8:
Page 9 and 10:
Page 11 and 12:
Page 13 and 14:
Page 15 and 16:
Page 17 and 18:
Page 19 and 20:
Page 21 and 22:
Page 23 and 24:
Page 25 and 26:
Page 27 and 28:
Page 29 and 30:
Page 31 and 32:
Page 33 and 34:
Page 35 and 36:
Page 37 and 38:
Page 39 and 40:
Page 41 and 42:
Page 43 and 44:
Page 45 and 46:
Page 47 and 48:
Page 49 and 50:
Page 51 and 52:
Page 53 and 54:
Page 55 and 56:
Page 57 and 58:
Page 59 and 60:
Page 61 and 62:
Page 63 and 64:
Page 65 and 66:
Page 67 and 68:
Page 69 and 70:
Page 71 and 72:
Page 73 and 74:
Page 75 and 76:
Page 77 and 78:
Page 79 and 80:
Page 81 and 82:
Page 83 and 84:
Page 85 and 86:
Page 87 and 88:
Page 89 and 90:
Page 91 and 92:
Page 93 and 94:
Page 95 and 96:
Page 97 and 98:
Page 99 and 100:
Page 101 and 102:
Page 103 and 104:
Page 105 and 106:
Page 107 and 108:
Page 109 and 110:
Page 111 and 112: D2.1 Requirements and Specification
Page 161: D2.1 Requirements and Specification
Page 209: D2.1 Requirements and Specification
show all

D2.1 Requirements and Specification - CORBYS

Create successful ePaper yourself

Delete template?

Save as template?