D2.1 Requirements and Specification - CORBYS

Recommendations

Info

D2.1 Requirements and Specification 7.5.2.3 Other Requirement No.: RRS39 Name: Requirements for size/shape/dimensions/weight of the FPGA board Description: It is important to know if there are any restrictions to these parameters. Reason / Comments: Indicative priority Mandatory Requirement No.: RRS40 Name: Requirements for the placement of the FPGA board Description: Where, what location in the demonstrator the FPGA sub-system board should be placed Reason / Comments: Indicative priority Mandatory Requirement No.: RRS41 Name: Cost requirements of the FPGA sub-system Description: Cost requirements of the FPGA sub-system while purchasing components and boards Reason / Comments: Indicative priority Mandatory Requirement No.: RRS42 Name: Certification Description: To get the sub-system certified for safety and usability Reason / Comments: Indicative priority Desirable 7.5.3 Assumptions and Dependencies Internal � Depends on SAWBB � Depends on all modules 7.6 SOIAA: SelfOrganizing Informational Anticipatory Architecture (Tasks 4.4, 5.1, 5.2, 5.3, 5.4; UH) Relevant tasks: � Expectation as a specification of an anticipated outcome (TASK 4.4, UH) � Development of self-motivated movement and goal generator for the cognitive architecture (TASK 5.1, UH) � Models and algorithms for the identification and anticipation of human purposeful behaviour (TASK 5.2, UH) � Algorithms for measurement of anticipatory information flow between robot and human and vice versa (TASK 5.3, UH) � Development of framework for transitional dynamics between robot-initiated and human-initiated behaviours (TASK 5.4, UH) 74
D2.1 Requirements and Specification 7.6.1 Preamble: Interface with the project 7.6.1.1 Research Scenario Considerations From the perspective of the SOIAA component whose development is in the responsibility of UH, and in the understanding of UH of the documents provided by IRSZR there appear to be at least two main “axes” spanning the space of modes of operation to which SOIAA needs to be exposed. The first is a “follow me” mode, where the controller strives to ensure safe interaction between the human and the robot. The robot would then practically “walk along” with the human, and should neither hinder nor assist its behaviour. This could then be used as a zero-hypothesis “status quo” from which the human’s task could start to be influenced. In general, the second mode of operation in either demonstrator involves outlining how the robot will interact and anticipate the needs of the human. For example, with regards to the first demonstrator, the second mode of operation would strive to fully impose a desirable (e.g. from the perspective of therapy) walking pattern on the patient. The needed movement would in this case be estimated from the current torque supplied by the sensors in the exoskeleton’s motors. This would basically force the human subject to move in the specified way, where the applied force would be steadily reduced (under the supervision of a therapist) as the human starts to walk normally on his own. From the perspective of the development of the SOIAA component, one of the main scientific challenges is the formalisation of the different modes of operation (such as the “follow me” mode, or the “human-robot interaction” - mode) in terms of the universal approach of the SOIAA component described in the next section. The various modes of operation should ideally also allow inclusion of established human movement models, such as for instance the minimum jerk principle or the 2/3 power law (Viviani and Flash 1995) in a form accessible to the SOIAA framework to be smoothly integrated into the cognitive process. With respect to the cognitive requirements in regard to the second demonstrator, the exploration scenario, it is important to establish the extent to which the CORBYS architecture should be generalisable to that scenario. This includes clarification of the range to which the CORBYS algorithms and techniques will work without change for both robots, and possibly for other cognitive robots, and to which extent the development will be specifically aimed to work for a particular demonstrator. In this context, a discussion of specific cognitive requirements for each demonstrator inside the CORBYS framework is particularly vital. 7.6.1.2 Issues for SOIAA Interface To clarify the interface of the cognitive UH SOIAA component inside the CORBYS architecture, it is important to determine the level at which the cognitive component provided by UH will interface with the overall project. With regards to the first demonstrator, this can be summarised in the following key question: “How much cognition is involved in walking?” From the perspective relevant to the SOIAA architecture, the cognitive process of walking is not high-level as would be if every action taken and every muscle moved involved processing complex semantic representations. In particular, human movement typically does not involve a conscious process of contemplation such as e.g. characterised by the following: “To get 10 centimetres ahead I am going to lift my leg and move it slightly forward so as a result my body will then tilt slightly forward and gain some forward momentum” or some other kind of precise rule-based system. Rather, the approach espoused by SOIAA is based on optimisation principles which express the balances of cognitive load in terms of informational quantities. In this view, the control of a quasi-automatic behaviour (such as straight walking) would be reflected in limited cognitive processing load which, could be furthermore treated as largely detached from higher cognitive levels and would only be modulated by them to a limited degree. The key insight is that, according to these principles, we expect that the cognitive information processing can be modelled on these 75
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: D2.1 Requirements and Specification
Page 83: D2.1 Requirements and Specification
Page 135 and 136:
Page 137 and 138:
Page 139 and 140:
Page 141 and 142:
Page 143 and 144:
Page 145 and 146:
Page 147 and 148:
Page 149 and 150:
Page 151 and 152:
Page 153 and 154:
Page 155 and 156:
Page 157 and 158:
Page 159 and 160:
Page 161 and 162:
Page 163 and 164:
Page 165 and 166:
Page 167 and 168:
Page 169 and 170:
Page 171 and 172:
Page 173 and 174:
Page 175 and 176:
Page 177 and 178:
Page 179 and 180:
Page 181 and 182:
Page 183 and 184:
Page 185 and 186:
Page 187 and 188:
Page 189 and 190:
Page 191 and 192:
Page 193 and 194:
Page 195 and 196:
Page 197 and 198:
Page 199 and 200:
Page 201 and 202:
Page 203 and 204:
Page 205 and 206:
Page 207 and 208:
Page 209:
show all

D2.1 Requirements and Specification - CORBYS

Create successful ePaper yourself

Delete template?

Save as template?