D2.1 Requirements and Specification - CORBYS

Recommendations

Info

D2.1 Requirements and Specification Figure 54: Autonomous vs. manual investigation of contamination area including sampling To meet the project objective, Reco Rob has to satisfy the following basic requirements: � the system must allow the user to guide the mobile unit for acquiring information concerning the air/water/soil relevant parameters (like contamination) and to gather samples for further investigations, � the sample gathering must be performed cross-contamination free, � the commands for guiding the unit as well as data acquired must be sent instantly to base using the wireless communication, � the transferred measurement data as well as information regarding stage of the task execution must be visualised on an ergonomic way, � the movement of the unit must be realised manually using a control joystick, or automatically, � a vision system is needed on the mobile to provide impression of tele-presence, � the mobile unit must report also the GPS data, for localisation and for data map generation, � in the case of an emergency, the mobile unit must be able to return to base executing a track-back of the route, � the construction of a mobile unit and/or components must allow decontamination in order to provide multiple usage of the system. To satisfy the functional requirements the system is endowed with various hardware devices as can be seen in Figure 55. For actuation the SCHUNK/degrees of freedom (DoF) lightweight robot arm is mounted on the mobile platform. The sensor system consists of a force-torque sensor in the manipulators wrist, a stereo camera system for 3D reconstruction, a camera for workspace observation and a camera for thermal inspection of the work area. (a) (b) Figure 55: (a) Hardware setup of the RecoRob reconnaissance robotic system, (b) Mapped Virtual Reality (MVR) used as simulation environment in the RecoRob system 17.2 Intelligent automated investigation of a hazardous environment To overcome the difficulties and limitations of teleoperation it is absolutely necessary to move beyond teleoperation and develop robot intelligence that can be interleaved with human intelligence. The Idaho National Engineering and Environmental Laboratory (INEEL) has developed a mixed-initiative robotic system which can shift modes of autonomy on the fly, relying on its own intrinsic intelligence to protect itself 176
D2.1 Requirements and Specification and the environment as it works with human(s) to accomplish critical tasks (Bruemmer et al. 2002). With this system communication dropouts no longer resulted in the robot stopping dead in its tracks or, worse, continuing rampant until it has recognised that communications have failed. Instead, the robot may simply shift into a fully autonomous mode. Also in a remote situation, the robot is usually in a much better position than the human to react to the local environment, and consequently the robot may take the leadership role regarding navigation. As leader, the robot can then “veto” dangerous human commands to avoid running into obstacles or tipping itself over. For this the robot has to provide the operator with the situational awareness required for controlling a robot (Valero et al., 2011). The CORBYS will build on state-of-the-art robotic systems for examination of hazardous environment endowing them with cognitive capabilities to support autonomous sampling in two experimental scenarios. One of the most fascinating areas of future work is the need for the robot to be imbued (to be filled) with an ability to understand and predict human behaviour. The robot’s theory of human behaviour may be a rule set at a very simple level, or it may be a learned expectation developed through practiced evolutions with its human counterpart. Interaction between the robot and human may be through direct communications (verbal, gesture, touch, radio communications link) or indirect observation (physically struggling, erratic behaviour, unexpected procedural deviation). Interaction may also be triggered by the observation of environmental factors (rising radiation levels, the approach of additional humans, etc.) 18 Conclusion In this document, the domain of robotic cognitive systems and their application in two demonstrators is introduced. Knowledge and requirements elicitation process, interaction with clinical and robotic experts (for gait rehabilitation systems and autonomous robotic systems respectively), and prioritised collection of requirements for CORBYS systems are presented in detail. The requirements engineering analysis base reports the requirements engineering methodology (UI-REF), followed by the procedure and findings of knowledge elicitation from clinical partners regarding the first demonstrator, entailing important discussions on end-user demographics, gait biomechanics in normal and pathological walking. Finalised requirements for the first and second demonstrator are then presented, followed state-of-the-market in light of CORBYS solutions. In total, 345 requirements have been gathered, out of which 309 are classed as mandatory, 22 as desirable, and 14 as optional requirements. All the requirements are detailed under the mechatronic control systems of CORBYS, human control system of CORBYS, and the Robohumatic systems. Requirements for system integration and functional testing for the CORBYS solutions as well as evaluation are also reported in this document. The requirements prioritisation process has used a number of prioritisation filters as reported in chapter 4, leading to a final sub set of 44 main requirements for the CORBYS project falling under three main categories: Cognitive systems, Demonstrator I specific, Demonstrator II specific. Lastly, detailed state-of-the-art reviews are presented in the various relevant areas as applicable to and in scope of the project. These include sensors and perception, situation assessment, anticipation and initiation, cognitive robot control architectures, smart integrated actuators, non-invasive BCI, gait rehabilitation systems and hazardous area examining robots. 177
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:
Page 113 and 114:
Page 115 and 116:
Page 117 and 118:
Page 119 and 120:
Page 121 and 122:
Page 123 and 124:
Page 125 and 126:
Page 127 and 128:
Page 129 and 130:
Page 131 and 132:
Page 133 and 134:
Page 135 and 136: D2.1 Requirements and Specification
Page 185: 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?