PROJECT PERIODIC REPORT - srs-project.eu | Multi …srs-project.eu/sites/default/files/SRS 247772...

SRS Deliverable 8.3 - 1 Due date: 31 JULY 2010

FP7 ICT Contract No. 247772 1 February 2010 – 31 January 2013 Page 1 of 29

PROJECT PERIODIC REPORT

Grant Agreement number: 247772

Project acronym: SRS

Project title: Multi-Role Shadow Robotic System for Independent Living

Funding Scheme: Collaborative Project

Date of latest version of Annex I against which the assessment will be made: 2009-12-09

Periodic report: 1st 2nd □ 3rd □ 4th □ 5th □ 6th □

Period covered: from 1st Feb 2010 to 31st July 2010

Project co-ordinator name, title and organisation:

Dr. Renxi Qiu, Project Manager, Cardiff University

Tel: +44(0)29 20875915

Fax: +44(0)29 20874880

E-mail: [email protected]

Project website address: http://www.srs-project.eu/



DELIVERABLE D8.3 - 1

Progress reports (Month 1 to 6)

Contract number : 247772

Project acronym : SRS

Project title : Multi-Role Shadow Robotic System for Independent Living

Deliverable number : D8.3 - 1

Nature : R – Report

Dissemination level : RE – Restricted

Delivery date : 06-SEP-2010

Author(s) : Dr. Renxi Qiu

Partners contributed : All SRS Members

Contact : Dr Renxi Qiu, Cardiff School of Engineering, Cardiff University, Queen‟s

Buildings, Newport Road, Cardiff CF24 3AA, United Kingdom

Tel: +44(0)29 20875915; Fax: +44(0)29 20874880; Email: [email protected]

SRS

Multi-Role Shadow Robotic System for

Independent Living

Small or medium scale focused research project

(STREP)

The SRS project was funded by the European Commission

under the 7th Framework Programme (FP7) – Challenges 7:

Independent living, inclusion and Governance

Coordinator: Cardiff University

SRS

Multi-Role Shadow Robotic System for

Independent Living

Small or medium scale focused research project

(STREP)



Declaration by the project coordinator

I, as co-ordinator of this project and in line with my obligations as stated in Article II.2.3 of the Grant Agreement declare that: The attached periodic report represents an accurate description of the work carried out in

this project for this reporting period;

The project (tick as appropriate):

has fully achieved its objectives and technical goals for the period;

□ has achieved most of its objectives and technical goals for the period with relatively minor deviations1;

□ has failed to achieve critical objectives and/or is not at all on schedule. The public Website is up to date, if applicable.

To my best knowledge, the financial statements which are being submitted as part of this report are in line with the actual work carried out and are consistent with the report on the resources used for the project (section 3.6) and if applicable with the certificate on financial statement.

All beneficiaries, in particular non-profit public bodies, secondary and higher education establishments, research organisations and SMEs, have declared to have verified their legal status. Any changes have been reported under section 5 (Project Management) in accordance with Article II.3.f of the Grant Agreement.

Name of Coordinator: .............Renxi Qiu.......................................................

Date: ....01......../ ....09......../ .....2010.......

Signature of Coordinator: ................................................................

1 If either of these boxes is ticked, the report should reflect these and any remedial actions taken.



1. Publishable summary

Funding: European Commission (FP7-ICT-247772)

Partners: Cardiff University, UK; Central Laboratory of

Mechatronics and Instrumentation - Bulgarian Academy of Sciences, Bulgaria; Fondazione Don Carlo Gnocchi Onlus, Italy; Fraunhofer-Gesellschaft Zur Foerderung Der Angewandten Forschung E.V, Germany; Stuttgart Media University (Hochschule der Medien), Germany; Hewlett-Packard Italiana srl, Italy; Fundacion Instituto Gerontologico Matia – INGEMA, Spain; Profactor GMBH, Austria; Robotnik Automation SLL, Spain; University of Bedfordshire, UK Duration: 1 February 2010 – 31 January 2013.

URL: http://www.srs-project.eu

Description: The project focuses on the development and

prototyping of remotely-controlled, semi-autonomous robotic solutions in domestic environments to support elderly people. In particular, the SRS project will demonstrate an innovative, practical and efficient system called “SRS robot” for personalised home care. Most elderly people want to live in the familiar environment of their own residence for as long as possible. However, not many can live with their adult children and therefore, at some stage, often late in life, have to live alone. Studies show that some forms of home care are usually required as they advance in years. SRS solutions are designed to enable a robot to act as a shadow of its controller. For example, elderly parents can have a robot as a shadow of their children or carers. In this case, adult children or carers can help them remotely and physically with tasks such as getting up or going to bed, doing the laundry and setting up ICT equipment etc. as if

the children or carers were resident in the house. This objective will be realised by the following SRS innovations: A new intent-based remote control mechanism to enable the robots to be tele-operated over a real-world communication network robustly. An adaptive autonomy mechanism to enable a highly efficient task execution for remotely controlled service robots. A new robotic self-learning mechanism to enable the robots to learn from their experience. A safety-oriented framework derived through

extensive usability and user acceptance studies that enable service robots to be effectively deployed into home care applications. The SRS prototypes created with EU support in the SRS project will be tested at the “S.Maria Nascente” Centre in Milano and the IZA Care Center in San Sebastián.

Figure 1 SRS Project

Logo

Figure 2 SRS Prototype I, from Fraunhofer IPA

Figure 3 SRS Prototype II, from Robotnik

http://www.srs-project.eu/



2. Project objectives for the period

• To evaluate and assess various robotic and assistive technologies;

• To analyse user requirements and define project application scenarios;

• To select SRS framework architecture and specify basic components;

• To definition privacy policy, requirements, and usability study based on specific needs of

elderly;

• To develop robotic control techniques for required semi-autonomous operation;

• To disseminate widely information on the problems to be addressed, the existence of the

project and its results and achievements, through multimedia dissemination material;

• To promote and exploit the project results.

3. Work progress and achievements during the period

3.1 WORKPACKAGE 1: Requirements Study, Technology Assessment and System Specification

Participants: ALL

Leader: INGEMA

Objectives:

To analyse user needs and demands for the proposed technology

To define the environment and the application domain

To evaluate and assess various underpinning technologies and works that have been carried

out

To initialise the SRS knowledge-base and define the SRS specification

To provide ethical guidelines for the project

Deliverables in the report period:

D 1.1 Detailed user requirements, environment definition, general guidelines on ethical

concerns and SRS scenario report (report month 6)

D 1.2 Report on Technology assessments (report month 3)

D 1.3 SRS Initial Knowledge-base and SRS hardware, software communication, and

intelligence specification (report month 6)

Milestones in the report period:

M1a SRS user requirement specified and ethical national review approved for the project.

(Month 3) (WP2, WP3 and WP6 will be started after the event)

M1b SRS Scenario & Specification has been precisely defined (Month 6) (WP1 completed

after the event)

Time Planed/Done (Feb 2010 – July 2010):

Task title Project Year 1

1-3 4-6 7-9 8-12

1.1 User Requirement assessment, elicitation and Planed



specification Done

1.2 Define the environment and the application domain

Planed

Done

1.3 Technology Assessments Planed

Done

1.4 Shadow Robotic System Specification Planed

Done

1.5 Ethical implications Planed

Done

Task implementation details:

Task 1.1: User Requirement assessment, elicitation and specification

Start date: Month 1

End date: Month 3

Description of work in this task:

Analysis of the expectations and demands of various potential users. User groups were defined in this

stage. Initial user samples recruited in 3 European countries (Germany, Italy, Spain) from primary users

(elderly people), secondary users (family members, formal caregivers) and health care professionals.

Systematic review and survey of selected users done in order to collect information about general

requirements, usability and acceptance possibility. Focus groups and individual questionnaires planned

and done according to this knowledge. User related knowledge gained in the study has been included in

D1.1.

Results:

Overview on age-related changes in elderly people, including changes on motor domain (movement

speed and accuracy decreases, joint functions reduces, lesser supportive functions of arm or leg),

sensation and perception (presbyopia, presbicusis) and cognition (declines in episodic and working

memory, generalized slowing, changes on language and communication). The review of the literature

in this field complements data collected in the user requirement study, mainly focused on functionality

and functional impairments.

Overview about needs of elderly people aging in place, including empirical evidence that elderly

people prefer to continue living in their homes. Their home is perceived as meaningful and useful apart

from limitations. The review of the literature in this field was especially relevant in the definition of

SRS application scenarios.

Overview on elderly people‟s perception of living with robotic systems in place. General acceptance of

robotic system is better in elderly people than expected. The review of the literature in this field was

relevant for the preparation of ad-hoc questionnaires included in the user requirement study.

Definition of user groups for the study (and reanalysis of the adequacy o user groups selected according

to data collected). Elderly people is the central user group, as final user and also because the

development of the system is directly associated with their environment, unmet needs and subjective

perceptions. Caregivers are also central because they are going to be remote operators of the system:

whereas family caregivers agree that they like the system but they do not want to spend much time

operating it, opinions of professional caregivers are more diverse. Finally, health professionals

provided very useful insights in this stage of the project, especially about privacy issues, but they do

not expect to use the system.

User recruitment. Criteria for user recruitment were: Elderly people, older adults above 65 years old

with difficulties in the Activities of Daily Living (ADL), i. e. due to mobility problems or

ostheomuscular problems; Family caregivers, family members who offer some kind of support to the

elderly without being paid for it; Professional caregivers, persons who are paid for offering support in

the ADL to the elderly person, mainly involved in direct care; Health professionals, professionals

involved in the health attention both directly (doctors, nurses, occupational therapists, physiotherapists,

etc) and/or indirectly (health service‟s administrators, advisors).



In Italy, elderly people attended a day care Centre at the geriatric Institute” Palazzolo” in Milan,

professional caregivers were working for the Nuovo Sole Social Cooperative, and health professionals

were working for the geriatric institute Institute “Palazzolo” in Milan. In Germany, elderly people,

family caregivers and professional caregivers were recruited in the community. In Spain, elderly people

were attending Ingema‟s educational activities, health professionals were working for Fundación Matia

and Fundación Ingema and family caregivers were relatives of elderly people attending to a cognitive

stimulation program.

Focus groups conducted. Focus groups are group discussions where a moderator leads participants

through questions about feelings, attitudes, and ideas in one topic of interest. 9 focus groups were

conducted.

FGs number

of

participants

Elderly

people

Family

caregivers

Professional

caregivers

Health

professionals

FDCGO/

HPIS 8 (4F+4M) 6 (5F+1M) 8 (5F+3M)

HdM 11 F 11

(10F+1M) 10 (9F+1M)

INGEMA 3 (2F+1M) 6 (5F+1M) 5 (3F+2M)

Focus group scripts included questions about activities of Daily Living and Instrumental ADLs

(difficulties in carrying out daily tasks), assistive Technology (technology currently in use; future

technology interviewed people wish to use), human-robot interaction (how the people interviewed

imagines robot features and uses) and privacy issues related to the Remote Control function.

Analysis and integration of focus groups results collected in Germany, Italy and Spain was conducted

by Ingema en included in D1.1. Concerning ADLs and IADLs, the activities that are the most difficult

to carry out for elderly people are housekeeping, transferring and mobility, and specific activities

related to shopping, (to carry heavy bags, to remember items to buy). Concerning human-robot

interaction, the robot could be of help in housekeeping activities, emergency situations and, in a minor

extent, in mobility problems. The robot should have a familiar voice and should not be too big.

Concerning acceptance of the remote control function, elderly people seem to put needs fulfilment

before any privacy concerns; caregivers and health professionals seem to worry more about potential

privacy problems than elderly users, but also agree with the system.

Review of instruments available to measure human-robot interaction acceptance and selection of the

the Survey of Technology Use (SoTU) scale as a general instrument that assess technology from an

user perspective. SoTU is included in the Matching Person & Technology (MPT) assessment process

[Institute For Matching Person & Technology: Matching Person & Technology: Model and assessment

process, 2003, revised version 2007].

Preparation of an ad-hoc questionnaire based on SRS specificities (RO possibilities, potential ROs,

privacy and psychological issues).

Data collected on SoTU and questionnaire.

Demographic data of Participants

Category Total Germany Italy Spain

Elderly number 64 28 19 17

Age 77,45 (min

65, max 92)

76,96 (min

65, max 92)

77,05 (min

66, max 87)

78,70 (min

66, max 88)

gender 47F, 17M 23F, 5M 11F, 8M 13F, 4M

Family

Caregivers number 19 10

9

Age 54,53 (min

28, max 69)

53,9 (min

28, max 66)

55,22 (min

44, max 69)

Professional

Caregivers number 22 10 12

age

46,68 (min

29, max 62)

48,1 (min

32, max 62)

45,5 (min

29, max 60)



Health

Professionals number 24

13 11

age 44,83 (min

27, max 57)

44,78 (min

27, max 57)

44.9 (min

30, max 55)

Results about needs of elderly people in daily life activities, differences between countries and target

groups. The main difficulties experienced by aging people at home as assessed through our interviews

are difficulties related to mobility activities - especially carrying heavy objects and reaching objects -

and housekeeping tasks - where cleaning the windows and cleaning the floor were rated with a very

high score in all the groups of participants. Cleaning the windows is not a task that will be considered

as a task SRS would carry out, mainly because this task only has to be done from time to time and

cheaper solutions are available. Other upsetting difficulties in elderly life assessed in our interviews

derive from difficulties in remembering things and/or remembering to take medicine, while body care

activities didn‟t receive a high score in the quantitative evaluation.

Results about tasks in which help is needed, differences between countries and target groups.

Participants‟ perception of technology, assessed through the SoTU, is mainly positive. Participants‟

perception of usefulness of the robot was variable, but showed a big agree in emergency situations,

pointing the importance of safety issues in independent living. Mobility issues, such as carrying heavy

objects or shopping, obtained high scores. The only items that received clear low score were those from

body care, meaning elderly users still do not trust robot help for personal care.

Results about perception of the robot, differences between countries and target groups. Elderly and

family caregivers wishes show a high preference of a human like appearance, whereas professional

caregivers and health professional would prefer a machine-like system, showing influence of a better

knowledge of assistive technology. Professional caregivers and health professionals show more safety

concerns, while all the groups expressed their worries about the size of the robot.

Results about perception of the RO, differences between countries and target groups. Elderly people

show less concerns than the other groups interviewed, postponing privacy to benefit. A preliminary

authorization to remotely operate SRS was strongly supported by all the groups.

Task 1.2: Define the environment and the application domain

Start date: Month 1

End date: Month 6


Definition of the environment from the user (housing needs, aging in place, psychological motivations,

and physical limitations) and the technological side (Standards & Regulations for robots in home

environment, smart-home possibilities). Definition of the activities to be developed and development of

SRS application scenarios.

Results:

Detailed SRS application scenarios (Deadline: 31 July 2010).

Methodology of Scenario development has been as follows:

- Partners involved in Task 1.1 elaborated drafts of possible scenarios according to data collected in

user requirement studies.

- Drafts presented in the SRS Consortium Meeting hold in Stuttgart 19th and 20th May 2010.

- The whole consortium discussed the proposal of scenarios.

- Technological partners elaborated technical requirements and procedures according to Scenario

specifications.

- Scenario description finally elaborated by Ingema and FDCGO as participants involved in Task 1.2.

- List of actions based on scenario description under development.

Finally, scenarios included D1.1 were:

- For prototype 1,



Bring objects.

Setting table.

Heating and serving dinner.

Night monitoring (emergency situation).

- For prototype 2,

Day monitoring (social contact and communication).

Standing up assistance.

Reaching difficult objects.

Reminder function.

Shopping.

SRS application scenarios take a narrative approach, but also include description of the actions to be

done based on use case approach. Sketches have been also included.

Example of SRS Scenario sketch for shopping scenario

Task 1.3: Technology Assessments

Start date: Month 1

End date: Month 3


This task conducted the analysis of various robotic technologies and assisted living technology, including

relevant work already launched under FP6 and FP7. Technical related knowledge-base set-up and

guidelines to help the development in the following work packages. The results are being applied in task

1.4 to set-up the SRS specification.

Results:

Telerobotics Control Models assessment. Since telerobotics is one of the earliest fields of robotics, a lot

of research has taken place. The research focuses on recent activities and research projects.

Intelligent Home assessment. Information provided by intelligent homes can be used to enhance the

robot‟s capabilities. An environment that is self-aware about its state is very useful for the operation of

a robot. However, not every home can be converted into an intelligent one and the effort to build an

intelligent home is extensive. Because of that, a research about recent work in that field is provided in

D1.2.

Middlewares, Communication and Open Software Robotic Frameworks/Software Architectures

assessment is introduced. Especially in tele-robotics, operation of a robot without an appropriate

communication concept is to fail. Different software modules have to run on different machines and



nevertheless communicate over large distances.

Safety assessment. A robot that is not able to interact with the environment in a safe way cannot fulfil

its tasks in a satisfactory manner. Because of that, safety concepts and research activities for robots

have been researched and included in D1.2 (also safety requirements and recommendations in D2.1).

a --b

c

d

e

f

g

h

F1

C1

P1

Starting point

for risk reduction

estimationa, b, c, d, e, f, g, h represent the necessary minimum risk reduction. The link between the necessary minimum risk reduction and the safety integrity level is shown in the table.

W1W2

C = Consequence risk parameter

F = Frequency and exposure time risk

parameter

P = Possibility of avoiding hazard risk

parameter

W = Probability of the unwanted

occurrence

a, b, c ... h = Estimates of the required risk

reduction for the SRSs

a

b

c

d

e

f

g

-a

b

c

d

e

f

Necessary minimum risk

reduction Safety integrity level

- No safety requirements

a No special safety requirements

b, c 1

d 2

e, f 3

g 4

h An E/E/PE SRS is not sufficient

W3

F2

F1

F2P2

P2

P1

C4

C3

C2

Figure: risk graph according to ICE 61508-5 extracted from D1.2.

Interaction technology assessment has been done, including an overview of user interfaces and related

input devices. Complementarily, haptics assessment has also been done as an important technology for

intuitive user interaction.

Cognitive capabilities field has also been studied, including human motion analysis, environment

perception and mobile manipulation. Those technologies enable the robot to obtain knowledge about

itself and the environment it is operating in. Introduction to state of the art in machine learning as also

been included in D1.2. As conclusion, it has been pointed that the semi-autonomous property of the

SRS may also need to be implemented by following three stages of skill acquisition, namely cognitive

stage, associative stage and autonomous stage. It is important to enable the robot to identify its user‟s

intention; main-behaviours mappings and reasoning based on the mappings are essential to the

intention identification. Equally important are generalised skills the robot possesses; hybrid and

innovative approaches will be needed to develop.

Task title: Shadow Robotic System Specification

Start date: Month 4

End date: Month 6

This task defines characteristics of the SRS. It will be analysed and specified as follows:

• SRS software architecture requirement specification

• SRS communication framework specification

• SRS cognitive capability specification

• SRS usability and safety requirement specification

• SRS hardware requirement specification

Also the SRS knowledge-based will be initialised and the knowledge will be applied for the following

SRS implementation and further marketing.

Results:

The following requirements on the software architecture have been identified based on the user



requirement study and the technology assessment: Robotic Hardware Independence; Parallel Processing;

Modularity and Collaborative Development; Cross Platform Communication; Integration with other Code

Base. To meet the requirements, after careful consideration we have identified ROS as the best candidate

reference architecture for the SRS project. It satisfies all the requirement listed in the sections above. In

more detail, ROS supports parallel processing through message passing along a user-defined, task-specific

graph of connections between software modules. Modularity is enforced through the operating system

process model: each software module executes as a process on some CPU. The TCP protocol was chosen

for message passing, because it is supported on all modern operating systems and networking hardware. Its

operation is essentially lossless. It provides standard operating system services such as hardware

abstraction, low-level device control to ensure robot independent and has good support for sensors and

various development kits. The ROS peer-to-peer links communicate with each other by passing messages

also helps the Cross Platform Communication. Finally it has good support for code-reuse.

SRS basic software components diagram has been defined in the following diagram.

The interactions among SRS components have been specified to realise the intelligence, safety and

usability required by the SRS framework. The requirement of SRS interaction technology has been further

specified and analysed to derive optimal solution for the expected interaction tasks and requirements.

Task title: Ethical implications

Start date: Month 1

End date: Month 6

This task includes general guidelines on ethical concerns, checking user assessment procedures from the

point of view of ethics and privacy. European legislation and national legislation from European countries

with partners involved have been revised and implications for SRS have been extracted. Ethical issues in

different FP7 projects have been studied. According to this implications and specifications for each

partner, a Data Protection Plan has been written and included in D1.1.

Ethical national review approved for the user involvement of the project was obtained in both Spain and

Italy (M1a). Complementarily, ethical approval was obtained in Germany.



Results:

Ethical approval in Spain (INGEMA)

Ethical approval in Italy (FDCGO)

Ethical approval in Germany (HdM)

Assessment procedures, European legislation, national legislation and implications assessed (Deadline:

31 July 2010).

By ethical we mean issues that concern questions about life, about revealing personal data, revealing

diagnosis and about daily care or guidance. One important concern in this research is the balance

between the demand for independent living, the need of the system for information in order to ensure

context awareness, and rights of the participants. In this regard, SRS Data protection plan have to take

into account personal contact details, functional status, personal needs required and living environment,

mobility and user location information, and certain personal information appointments and daily

routines.

Data protection plan contains precise information about how to get written informed consent from the

participants (informed consent model included in D1.1), how to store data in a secure way avoiding

disclosures (electronic files encrypted and/or protected by strong password, removable storage media

holding and printouts in looked compartments/rooms), how to encode personal data in order to ensure

anonymization (using two separates database for contact information and research data including

functional and health information),

Ingema gave a presentation of the data-protection guidelines described below during the SRS

Consortium Meeting held in Stuttgart on May 19th, 2010. Main conclusion reached at the end of the

meeting was that:

- The Consortium agreed on the data protection plan presented

- Raw data will stay at local sites (Ingema, FDCGO, HdM), and other partners in the consortium will

have access for analysis of results and reports.

3.2 WORKPACKAGE 2: User Interaction Study of Remotely-Controlled Service Robots

Participants: CU, FDCGO, Fraunhofer, HdM, INGEMA, PROFACTOR

Leader: HdM

Objectives:

To design user interfaces for the remote operator and the elderly people;

Develop interaction patterns for human-robot interactions (HRI) including multimodal

interaction, augmented reality, and speech dialogues in order to support usability, safety and

situation awareness for elderly users and remote users;

Carry out an iterative process of interface prototype development and usability studies in

order to optimise the interface design;

To ensure high acceptance, adequate safety and attractiveness of SRS human robot

interaction.


D2.1 Definition of Privacy policy; requirements and usability study based on specific needs

of elderly (interim report - month 6 and final report - month 30)


None




task title Year 1

1-3 4-6 7-9 8-12

2.1 Requirements for shadow system related human-robot interaction

Planed

Done

2.2 Psychological dimensions (security, privacy, trust, pleasure and social implications) as well as ethical safeguards

Planed

Done

Task implementation details

Task 2.1:

Task 2.2:

Requirements for shadow system related human-robot interaction

Psychological dimensions (security, privacy, trust, pleasure and social

implications) as well as ethical safeguards

Start date: 1 May 2010

End date: 31 July 2010


Describe usability methodological framework based on user centred design approaches (HdM)

o Description of a user centred design process adapted to the requirements of human-robot

interaction and especially the SRS project (HdM)

o Definition of SRS relevant theories such as situation awareness and collaborative

interaction of human and robot (HdM)

Describe a short-term as well as long-term interaction design process based on a scenario-based design

process (ALL)

o Definition of basic SRS scenario for prototype 1 and 2 of SRS project (Ingema, FDCGO:

WP1)

o Development of detailed scenarios in order to envisage future interactions of local user

and robot as well as remote operator and robot

o Analyse and understand the robot capabilities

o Specification of interface requirements for interaction technology based on task analysis

o Decision on interaction technology

Development von human-robot interaction scenarios as a basis for task and requirement analysis (ALL)

o Development of detailed local user and remote operator scenarios

o Extracting relevant tasks from the scenarios

o Defining requirements based on tasks

Investigate SRS feasible hardware capabilities and cognitive capabilities (HdM)

o Analysis of relevant interaction technology hardware (8 configurations)

o Analysis of robot learning skills

Propose user group specification according to interaction analysis (ALL)

o Definition of main characteristics of target local user groups (ALL)

o Definition of main characteristics of target remote operator groups (ALL)

o Analysis of consequences for interaction design and evaluation procedure (HdM)

Requirements elicitation and analysis (ALL)

o Derive requirements from HRI literature (HdM)

o Derive requirements from an interaction analysis of SRS several simple interaction

prototypes (HdM)

o Compare possible interaction devices for suitability for SRS remote operation (HdM)

o Derive requirements from gerontology literature (INGEMA)



o Derive requirements from SRS user requirements study of WP1 (FDGCO)

o State privacy policy (INGEMA)

o State SRS relevant safety requirements (ACMIT).

o Derive requirements from an interaction analysis of SRS several simple interaction

prototypes (HdM)

o Compare possible interaction devices for suitability for SRS remote operation (HdM)

Results:

Usability methodological framework and short-term as well as long-term interaction design process

described (completed)

SRS interaction and user interface design is embedded in the user-centred design process - the most

successful approach for designing usable and easy to learn human-computer interaction (HCI). Human-

robot interaction (HRI) shows many analogies to HCI but also differences which have been outlined.

Steps of the interaction design process are scenario definition, scenario elaboration, understanding the

robot capabilities, specification of interface requirements and finally decision on interaction technology

(see D2.1).

Interaction device comparison for suitability for SRS remote operation (completed)

8 interaction technology configuration have been defined and evaluated against requirements and user

tasks. This analysis is completed and the final decision on interaction technology will be taken in task

2.3 of the DoW.

SRS feasible hardware capabilities and cognitive capabilities investigated and respected in interaction

analysis (completed)

User group specification proposed (completed)

A proposal for 3 user groups has been done and will be finally decided at the September meeting of

SRS:

o User Group 1: Elderly persons with a minimum age of 65 still living in their original

home and having some difficulties with the activities of daily living as a result of the

typical ageing process but no severe disabilities like complete loss of hearing, dementia,

or being bound to a wheelchair. They may already receive some assistance or care (e.g.

assistance with cleaning, meals-on-wheels, assistance with shopping, minor body care like

foot care, reminders for taking medicine, etc.).

o User Group 2: Persons providing care to an elderly person on a private basis (most

typically children but sometimes grandchildren, husband, wife, friends), in most cases not

receiving payment (but they may receive a small compensation). The important criterion

is that the care is provided in a personal, non-paid, informal way. The caregiver has a

personal relationship to the elderly person and usually has known the elderly person long

before the care situation.

o User Group 3: Professional remote operators (24-hour call centre): The required expertise

for teaching the robot advanced functions (e.g. complex procedures involving abstract

assembly of structured behavioural components) may likely be too high for the average

user. Another reason why this user group should be included is because the relatives may

not always be available to help (e.g. at work, not willing, or there are none). In this case,

there should be an optional path. There may be a priority order, e.g. (1) elderly person, (2)

relative, (3) call centre as the last alternative in the chain.

Requirements from HRI literature derived (completed)

Several design principles, requirements, and recommendations have been derived from the human-

robot interaction literature. Those relating to system usability can be considered preliminary and broad

usability goals. Specific and quantified usability goals will be developed when the system specification

is set. Most of the topics and design principles are related to robot interaction design specifically. In

addition, general design principles of user-centred design were added.

Examples of principles derived from of HRI literature are:

o Establish high situation awareness



o Establish common ground

o Design according to mental models

o Enhance awareness

o Lower cognitive load

o Increase efficiency

o Provide help in choosing robot modality

o Communicate intentions to local user

o Achieve high user experience

Requirements from interaction analysis of 13 SRS local user and remote operation simple prototypes

derived (completed)

The requirements analysis is based on a review of the SRS scenarios, literature review, the SRS

ongoing discussion and 13 additional scenarios demonstrated as simple prototypes. The scenarios were

based on various interaction device configurations for remote operation, 9 scenarios were developed

from the perspective of the remote operator and 4 from the perspective of the local user. The scenarios

were analysed concerning tasks of remote operator and local user related to different usage situations.

Further requirements were extracted from the scenario descriptions.

Requirements from gerontology literature stated (completed)

Taking into account age-related changes found in the revision reported in the Deliverable 1.1 Section

2.1, it is possible to conclude some specific requirements for interface design. Requirements elicited

from the Gerontology review are mainly about sensory and motor changes, especially those basic

requirements needed to allow usage in a basic level; nevertheless, some requirements taking into

account limitations in information processing and processing styles are also included.

Requirements from SRS user requirements study of WP1 stated (completed)

Based on the findings of the user requirements study of WP1 explained and discussed in detail in D1.1,

requirements have been elicited in order to provide technologists with information to start the

development of the system. Each functional requirement is presented with some practical examples

raised by the main needs that emerged during focus groups and interviews and in particular some of

these examples are drawn from scenarios presented in D1.1.

Privacy policy stated (completed)

SRS relevant safety requirements stated (completed)

About specific issues for SRS setup concerning user interaction and safety, in principle there are two

main groups of user interaction (a) control of robot system via remote control by remote operator and

(b) interaction between robot and the primary user at robot site. From safety aspect one major problem

– and also the main difference between SRS and most of the known robot setups for industrial and

service site – is that the primary user does not know what the next activities of the robot (remote

controlled or in automatic mode) are. On the other hand the remote operator needs sufficient

information about the environmental situation at the robot site in order to ensure safety of the

commands sent to the robot. Known problems with remote robot control (such as limited feedback

from use site to remote site, time delay between command and execution and/or between sensing of

environmental change and display of this information to the remote operator) increase complexity and

needs to be considered about their influence to system safety. This has been analysed and further

developed

3.3 WORKPACKAGE 3: Cognitive Capabilities of Remotely-Controlled Robots

Participants: CU, CLMI-BAS, Fraunhofer, HPIS, ROBOTNIK, BED

Leader: Fraunhofer



Objectives:

To develop methodologies and techniques to enable semi-autonomous operation of remotely-

controlled robots. This includes:

To develop perception capability of remotely controlled service robots

To develop learning capability of remotely controlled service robots

To develop integrated decision making capability of remotely controlled service robots


None


None


task title Project Year 1 Project Year 2

1-3 4-6 7-9 8-12 1-3 4-6 7-9 8-12

3.1 Environmental information interpretation Planed

Done

3.2 Human motion interpretation Planed

Done

3.3 Robotic motion interpretation Planed

Done

3.5 Imitation based learning Planed

Done

3.6 Cognitive inference capability Planed

Done

Task implementation details

Task 3.1: Environmental information interpretation




Evaluation and implementation of algorithms for point cloud registration with different sensor

systems

Definition of software component in the SRS framework

Definition of interfaces to other components

Expected results:

Point Cloud registration as a base for 3D environment maps ;

Software component ready to be used in SRS framework.

Task 3.2: Human motion interpretation




Point Tracking by EKF

This work aims to estimate the pose of a cube, which is a simplified representation of an arm. Thus, state x

is the pose of the cube centre, consisting of six positions and orientation variables as follows,



T[ , , , , , ]x y z x (1)

Estimation is proceeded in a recursive way. It means the state at time t is impacted by the preceding at time

(t1). Besides it, another input of the estimation algorithm is measurement z, that is, 2D coordinates of

projection points in monitor row-col frame. The output OUT includes state estimate x and accordingly 3D

coordinate estimates of eight vertices in camera frame and their 2D projection positions. See section 3.2

for more details. T{ } [ , ]di r cz (2)

where id indexes displayed points rather than all eight points. Usually, there are four to seven such points

shown in monitor within the eight vertices.

The EKF algorithm process has three parts, namely, prediction based on preceding estimates, correction

based on measurements, and output calculation as a post-processing step. Within them, the first two are

run separately with respect to each displayed 2D projection point. What will be discussed in detail in

section 3.1 is there are nd such points. They are processed in succession and the algebraic mean of the

results stands for the final belief.

Pseudo Markov chain

The current state of the filter depends on two preceding states. Strictly speaking, it violates the Markov

chain hypothesis, which is defined as „a discrete random process with the property that the nest state

depends only on the current state‟ [2]

. In order to follow this rule, if necessary, a solution is expanding the

state x to a 12 member vector to cover the 6 velocity variables. All corresponding entities above need to

accordingly modify.

Expected results:

Algorithm for Motion Detection and Motion Tracking

Task 3.3: Robotic motion interpretation




Evaluation of existing methods for robotic motion interpretation on Care-O-bot 3, definition of

requirements for SRS

Definition of software component in the SRS framework

Definition of interfaces to other components

Expected results:

Definition of requirements for SRS done;

Software component ready to be used in SRS framework.

Task title 3.5 Imitation based learning




Developing methodology for typical examples identification

Developing learning high-level abstract skills

Developing advanced imitation learning

Expected results:

Defined task classes in line with scenarios specified together with project partners

Collection of tasks within each task class and features identified for the tasks



Skills format and levels

Learning algorithm evaluation

Learning algorithms of high-level skills

Imitation learning algorithms evaluation

Advanced imitation learning algorithms for SRS

Achievements:

Methodology for typical examples identification

Methods for identifying typical examples are closely related to the design of UI. In the case where the UI

is able to accept linguistic commands from users and to convey to an SRS robot, typical examples can be

characterised using verbs. When a linguistic command is received, the robot can calculate the verb

appears in the command with those that are used to characterise typical example. Verbs‟ feature vectors

are defined to allow the characteristics to be measurable. A verb‟s feature vector f shows how strong the

verb is associated with a set pre-selected of nouns such as:

where is the association between the verb and the ith noun of the set. It takes values in [0, 1] where 0

means that there is no association between the verb and the noun and 1 means the strongest association

between them. The values can be obtained using statistic methods.

Learning high-level abstract skills

Association among task, goal and skill

When a user gives a command to an SRS robot, he/she assigns a task to the robot. A task contains an

ultimate goal for the robot to achieve.

Tasks are arranged in a two-level structure with generalised ones on the top and specific ones, called

typical cases, at the bottom. This way of organising tasks has the following advantages:

Easier for an SRS to distinguish and handle given tasks which are either the same as or similar to

the tasks that the robot knows how to fulfil and those that are new to the robot

Scalable if typical tasks within a category of a generalised task are to be further divided into finer

classes.

A task, at both levels, can be decomposed into sub-tasks each of which has a sub-goal. The decomposition

can carry further until “atomic” sub-tasks reached. A skill is needed to complete an atomic sub-task. To

Cooking

Cook p

izza

Bak

e

potato

Serving drink

Serv

e tea

Serv

e juice

Generalised level

Specific

level



complete a task, all skills that are needed to complete all atomic sub-tasks will be required and arranged in

such a way that the task can be completed step by step.

Skill classification

Skills can be classified into two categories, tactical skills that are used to complete a specific atomic sub-

task and organisational skills that are used to arrange tactical skills for completing a task step by step.

Tactical skills models

Corresponding to the detailed task level, tactical skills, called specific skills, can be modelled as the

following format:

Skill: If final goal is G

Then set as sub-goals {g1, g2, …, gn} as a tuple, and

Set as actions {ai1, ai2, …, aim} as a tuple for the ith sub-goal, i = 1, …, n, and

An action aij is represented as a trajectory with pre- and post- conditions.

The pre- and post- conditions of an action show the conditions under which the action can be performed

and the consequences of the action, respectively. They can be 2D mental images. An action sequence can

also be represented in a flowchart with testing conditions and branches.

Corresponding to the generalised task level, tactical skills, known as abstract skills, can be modelled such

as:

Skill: If final goal is G

Then set as sub-goals {g1, g2, …, gn} as a tuple,

Set as actions {ai1, ai2, …, aim} as a tuple for the ith sub-goal, i = 1, …, n.

An action sequence can also be represented in a flowchart with testing and branches. The abstract skills

are associated with tasks at the generalised level of the two-level structure.

Tactical skills are stored in human brain in the way that they are associated with tasks. That is, all actions

that are needed for complementing a task are encapsulated in a skill. The abstract skills and specific skills

in SRS will also be stored in the same way, as shown in the following diagram.

Tactical skill learning procedure

1. Task classification – to identify the ultimate goal associated with a given task 2. Task segmentation – to decompose the task into sub-tasks so that is can be completed step by

step and to identify sub-goals associated with each sub-task

Cooking skill

Action c.1.1

(abs) Action c.1.2

(abs) Action c.2.1

(abs) Action c.2.2

(abs) Action c.2.3

(abs) Action c.3.1

(abs)

Cooking pizza

skill Action c.1.1

(imp) Action c.1.2

(imp) Action c.2.1

(imp) Action c.2.2

(imp) Action c.2.3

(imp) Action c.3.1

(imp)

Baking potato

skill Action c.1.1

(imp) Action c.1.2

(imp) Action c.2.1

(imp) Action c.2.2

(imp) Action c.2.3

(imp) Action c.3.1

(imp)

Abstract skill Specific skill



3. Tactical skill learning – to acquire skills that are used to achieve the sub-goals at both abstract level and specific level

4. Organisational skill learning – to acquire skills about how sub-goals are set given a task. (See the following diagram.)

Feature capture

Similarity calculation

CommandsCommands

Task/GoalTask/Goal

Segmentation

Perception

Sub-tasks/goalsSub-tasks/goals

New sub-goal ID

New action ID

Pre-/post-condition identification

Action and pre-/post-condition

association

Action sequence formating

Sub-goal and action sequence

association

Actions

Pre-/post-conditionsPre-/post-conditions

Formalised actionsFormalised actions

Sub-goal sequence

If … then rules generation

Generalisation

Tactical skillsTactical skills

Organisational skillsOrganisational skills

Task learning inputs

The following information will be needed for learning:



Context information, including (from ROS) geometry_maga/PoseStamped, trajectory-msgs/PoseStamped, geometry_msga/TwistStamped, std_msgs/String, cob_msgs/Tigger

Commands (from Local User Interface)

Remote operators’ intention (optional).

Task 3.6: Cognitive inference capability




Developing a case-based mechanism/algorithm for an SRS robot to what skills will be needed to

complete a given task

Defining a way in which remote user‟s intervene introduced

Expected results:

Typical case identified

Similarity measures between cases evaluated and defined for SRS

Case-based reasoning mechanism/algorithm

Way of human intervene

Achievement:

In order to develop cognitive inference capability for SRS robots, the following scopes are defined:

Consciousness

An SRS robot will be able to recognise

Local users who are in different postures

Different types of furniture such as table, cupboard and door, and

Objects such as bottles, cups and door handle, when approaching to them.

Note: The postures, furniture and objects should be further defined according to testing scenarios used in

the project.

User intention recognition

While being manipulated by a remote user, an SRS robot will be able to

Segment actions it is controlled to perform into sub-tasks

Identify sub-goals that are associated with the sub-tasks, and

Recognise the operator‟s intention through the process of being controlled in completion of a

serious of sub-tasks.

3.4 WORKPACKAGE 7: Dissemination and Exploitation

Participants: ALL

Leader: PROFACTOR

Objectives:

To disseminate widely information on the problems to be addressed, the existence of the project and

its results and achievements, through effective multimedia dissemination material;

To raise awareness about the possibilities offered by SRS by direct contact with potential user groups,

care organisations, and others;

To promote and exploit the project results.




None


None


task title Project Year 1 Project Year 2 Project Year 3

1-3 4-6 7-9 8-12 1-3 4-6 7-9 8-12

7.1 Exploitation of commercial potential of the developed technology

Planed

Done

7.3 Dissemination towards the robotic and home care industry

Planed

Done

Task 7.1: Exploitation of commercial potential of the developed technology


End date: 31 Jan 2013


The objective of this task is to define and implement SRS exploitation plan. The marketing analysis survey

will be initiated through the realisation and circulation of a relevant template for collecting structured data

on each aspect of the project. The task leader will carry on an analysis of the project results at month12

and update it every 6 months.

The initial market survey has been carried out;

DELILA poster has been produced;

Literature and web search have been carried out;

Expected results:

As planned

Task 7.2: Dissemination towards the robotic and home care industry


End date: 31 Jan 2013


The objective of this task is to define and implement SRS exploitation plan. The marketing analysis survey

will be initiated through the realisation and circulation of a relevant template for collecting structured data

on each aspect of the project. The task leader will carry on an analysis of the project results at month12

and update it every 6 months. The project information has been disseminated through:

Project Website

Project Partners‟ Websites

EURON

ETFA 2010

Workshop on Biomathematics 26-27 May, Sofia, Bulgaria, was presented a lecture about SRS project

development, entitled – “Service Robots for Supporting Elderly Peoples”.

Expected results:

As planned



4. Deliverables and milestones tables

Deliverables (excluding the periodic and final reports)

TABLE 1. DELIVERABLES

2

Del. no.

Deliverable name WP no. Lead participant

Nature

Dissemination level

Due delivery date from Annex I

Delivered Yes/No

Actual / Forecast delivery date

Comments

D1.2 Report on

Technology

assessments (task

1.3)

WP1 FRAUNHOFE

R

R PU 30th

April

2010

YES 27th

May 2010

D8.1 Project presentation;

web first version

available to all

partners

WP8 CU R PU 30th

April

2010

YES 27th

May 2010

D8.2 Quality plan &

evaluation/success

criteria

WP8 CU R RE 30th

April

2010

YES 27th

May 2010

D1.1 Detailed user

requirements,

environment

definition, general

guidelines on ethical

concerns and SRS

scenario report

WP1 INGEMA R PU 31st July

2010

NO 6th

Sep 2010

D1.3 SRS Initial

Knowledge-base and

WP1 CU R PU 31st July

2010

NO 6th

Sep 2010

2 For Security Projects the template for the deliverables list in Annex A1 has to be used.



SRS hardware,

software

communication, and

intelligence

specification

D2.1

a

Definition of Privacy

policy; requirements

and usability study

based on specific

needs of elderly

WP2 INGEMA R PU 31st July

2010

NO 6th

Sep 2010

Milestones

TABLE 2. MILESTONES

Milestone

no. Milestone name Due achievement

date from Annex I Achieved Yes/No

Actual / Forecast achievement date

Comments

M1a SRS user requirement

specified and ethical

national review approved

for the project

30th

April 2010 YES 30th

April 2010 User requirement presented in project Stuttgart

Meeting.

Ethical approval letters received for relevant

partners .

M1b SRS Scenario &

Specification has been

precisely defined

31st July 2010 YES 31

st July 2010 Reported in D1.1 and D1.3

M14 Project Quality Plan ready

for use 31

st July 2010 YES 31

st July 2010 Reported in D8.2



5. Project management

5.1 Objectives:

• To coordinate and manage the project activities in administrative, technical and financial terms;

• To provide a communication medium between the project partners and the Commission;

• To assure the quality of the project outcomes;

• To maintain the consortium agreement.

5.2 Work performed:

• Project co-ordination and financial management;

• Management of RTD, dissemination and exploitation activities;

• Management of intellectual assets;

• Quality assurance / review & assessment.

5.3 Results achieved:

• Monthly/quarterly/six-monthly progress reports have been done by all partners;

• The EC funding has been allocated to all the consortium members;

• Project deliverables (D1.2, D8.1, D8.2, D1.1, D1.3, D2.1a, D8.3-1 and D8.4-1) have been / are

being delivered to the Commission as scheduled.

5.4 Project website: Official SRS website (http://www.srs-project.eu) and a project wiki (http://wiki.srs-project.eu)

have been set up by the end of month 3 for both consortium members‟ and public access. The

websites are maintained daily during to report project activities, progress and achievements. The

wiki will be used for internal collaboration. It contains project draft documents, presentations

and records of internal discussions.

5.5 Tele conference

Although the project still holds its meetings as planned in order resolve an issue quickly, to save

time and to minimise cost of travel when appropriate the project partners make maximal use of

teleconferencing. After careful cost/benefit analysis which included several possible

teleconference solutions the project partners selected to use the hosted teleconferences provided

by FreeConferenceCall International where a low cost dial-in number is given for most of the

countries where SRS partners reside. Major factor in selection of this teleconference solution

was the fact that the sound quality does not deteriorate significantly compared with free solutions

like Skype when a number of participants take part in the call. Two major teleconferences have

been organised across SRS members (8th

of April 2010, and 19th

of July 2010)

5.6 MEETINGS

5.6.1 The first project meeting

Venue:

C/1.10B, Queen‟s Building, Cardiff University

09 (Tue) to 10 (Wed), February 2010

Agenda:

http://www.srs-project.eu/

http://wiki.srs-project.eu/



Day 1

10:30 Tea & coffee

11:00 Start of meeting, agenda and welcome (Professor D T Pham)

11:10 Presentations of partner institutions (CU, CLMI-BAS, FDCGO, Fraunhofer, HdM, HPIS

INGEMA, PROFACTOR, ROBOTNIK, BED)

14:00 Visit to MEC‟s facilities

14:30 Project presentation and management set up (Dr Renxi Qiu)

15:00 Presentation and discussion of the work plans for WP1 (WP Leader INGEMA) *

16:00 Tea & coffee

16:15 Presentation and discussion of the work plans for WP1 continued

17:00 Place and date of next meeting

Day 2

8:45 Tea & coffee

9:00 Presentation and discussion of the work plans for WP2 for the first six months (WP Leader

HdM) *

10:00 Presentation and discussion of the work plans for WP3 for the first six months (WP

leaders: Fraunhofer) *

11:00 Tea & coffee

11:15 Advanced work plan or relevant preparation work for the tasks after six months

12:00 A.O.B.

WP presentation includes the following details:

• Relevant state of the art/background, recent update/progress;

• Objectives of WP;

• Methodology;

• Time scale;

• Deliverables;

• Actions (Who does what by when).

5.6.2 Technique meeting in Stuttgart

Venue:

Day 1:

Hochschule der Medien (Stuttgart Media University), Campus Stuttgart Central,

Wolframstrasse 32, 70191 Stuttgart, room 411 (4th floor, left door after elevator)

Day 2:

Location: Fraunhofer IPA (Institut für Produktionstechnik und Automatisierung), Nobelstrasse

12, 70569 Stuttgart-Vaihingen, room E1.04 in Turm III (obtain a site map at the gate and ask

the porter for directions)

19 – 20 May 2010

Agenda:

Day 1:(Participating partners: all)

11:00 Start of meeting, welcome by Prof. Michael Burmester, introduction round due to new

persons in the consortium

11:10 Profactor company presentation by Martijn Rooker

11:30 Presentation of results from user requirement study by Ingema, FDG, HP, HdM

11:30 Introduction and overall methodology (Ingema)



11:40 Focus group results from Italy (FDG & HP)

11:55 Focus group results from Germany (HdM)

12:10 Focus group results from Spain (Ingema)

12:25 Results of questionnaire study, all countries (Ingema)

12:50 Questions and comments

13:00 Demonstration of HdM Design Center

14:10 Demonstration of HdM Usability Lab

14:30 SRS scenario definition (part 1)

14:30 Introduction (HdM)

14:35 Presentation of cooking scenario + 5 min discussion (HdM)

14:45 Presentation of exemplary detailed task analysis for cooking scenario (HdM)

14:55 Presentation of laundry scenario + 5 min discussion (HdM)

15:05 Presentation of night monitoring and falling scenario + 5 min discussion (HP)

15:15 Presentation of fetch-and-bring scenario + 5 min discussion (FDG)

15:25 Presentation of forgetfulness scenario + 5 min discussion (Ingema)

15:35 Presentation of shopping assistance + 5 min discussion (Ingema)

15:45 Voting on scenarios (HdM-moderated)

1. recapitulate all possible scenarios

2. recall requirements for a suitable scenario, discuss additional requirements

3. discussion of inclusions and exclusions

4. scenario voting on flipchart

17:10 SRS scenario definition (part 2)

17:10 Presentation of top-voted scenarios (HdM)

17:20 Decision-making: How many scenarios will we implement? Which scenarios?

17:45 Presentation of SRS data protection plan (Ingema)

18:05 Announcements for day 2 (IPA)

18:10 End of day 1 (taxis to hotel and restaurant)

Day 2:

There will be two parallel tracks on this day.

Track A: WP3 software meeting

Participating partners: all except HdM, FDG, Ingema, HP

10:00 Presentation of existing software components, interfaces and development tools from

all partners

11:30 Discussion about mandatory components in the SRS software framework, definition of

interfaces and communication of components

13:30 Demonstration of Care-O-bot and Fraunhofer facilities (together with track B)

14:30 Discussion and decision about action plan for WP3

16:00 End of track A

Track B: WP2 and WP6 discussion

Participating partners: HdM, FDG, HP, Ingema, Profactor (1 person), CLMI (1 person),

CU (1 person)

10:00 WP2 and WP6 discussion

10:00 WP2 action plan till July (HdM, Marcus)

10:15 WP2 long-term design process (HdM, Michael)

10:45 WP6 plan / FDG facilities and methods (FDG)

11:00 Discussion of inconsistencies in DoW (HdM-moderated)

11:45 Discussion of publication of WP1 user studies results

12:15 Other topics, miscellaneous



13:30 Demonstration of Care-O-bot and Fraunhofer facilites (together with track A)

14:30 End of track B. The track B partners will have the chance to participate in the afternoon

discussion of track A (not mandatory). Alternatively, the afternoon can be used for individual

partner conversations according to demand.

5.6.3 6 monthly progress review teleconference

Venue:

Host by Free conference call and SRS Wiki

19-July-2010

Agenda

10:30 Start of meeting, agenda and welcome

10:40 Presentations of work being and to be carried out

(5 ~ 10 minutes per partner)

CU

CLMI-BAS

FDCGO

Fraunhofer

HdM

HPIS

INGEMA

PROFACTOR

ROBOTNIK

BED

12:20 Expected Results & Milestones for WP1 (WP Leader INGEMA)

Status of deliverables

SRS scenarios update

13:30 Break

14:00 Expected Results & Milestones for WP2 (WP Leader HdM)

Presentation of interface requirements

User definition

16:00 Expected Results & Milestones for WP7 (WP Leader PROFACTOR)

Dissemination & Exploitation

17:00 Q&A about WP1, WP2 and WP7

18:15 All other business and list of actions

19:00 End

5.6.4 Technique meeting in Valencia

Venue:

C/Berni i Catalá, 53 .Valencia (Spain)

22 (Thu) to 23 (Fri), July 2010

Agenda:

Day 1

09:30 Start of meeting, agenda and welcome (Rafa López)

09:45 Visit Robotnik facilities (Rafa López)

Part 1 Presentation of technical progress

10:00 IPA State of Work (for technical development)



10:15 ROB state of Work (for technical development)

10:30 CU state of work (for technical development)

10:45 BED state of work (for technical development)

11:00 CLMI-BAS state of work (for technical development)

Part 2 SRS Components and ROS Workshop

11:45 Demonstration on SRS components interaction

12:15 Discussion about software, hardware and components required by the scenarios

12:45 Demonstration on existing environment perception process for testing case with ROS

13:10 Discussion about SRS enhancement for environment perception

14:30 Demonstration on existing navigation and localisation process for testing case with ROS

15:00 Discussion about SRS enhancement for navigation and localisation

15:30 Demonstration on existing manipulation process for testing case with ROS

16:00 Discussion about SRS enhancement for manipulation

16:30 Coffee break

17:00 Discussion about SRS knowledgebase, user interface and learning capability

Day 2

Part 3 SRS technique specification

09:30 Discussion about software architecture and communication specification

10:00 Discussion about knowledgebase and cognitive capability specification

10:30 Discussion about hardware requirement specification

11:00 Summary of decisions

11:10 Coffee break

11:40 Revision of the Work Plan (technical side) for the next months

12:45 Feedback by all attendants, conclusion and all other business

14:30 End of the meeting

5.7 Change in project beneficiaries

Possible new beneficiary originally from SRS consortium member PROFACTOR

Dr. Gernot KRONREIF and his team who was originally from ASR unit of PROFACTOR has

been moved to a new company called “Integrated Microsystems Austria GmbH” (IMA; this is

the legal body behind the aforementioned competence centre "Austrian Center for Medical

Technology and Innovation - ACMIT"). PROFACTOR is proposing to transfer the working

parts which have been previously assigned to PROFACTOR business unit ASR (i.e. safety,

HMI/HRI) to the IMA. Dr. Gernot KRONREIF and his team are still working under the SRS

project but under new company IMA. PROFACTOR still will be partner in SRS and will

perform the tasks which have been assigned to the PROFACTOR business unit RAS during

proposal stage.

Date post:	30-Aug-2018
Category:	Documents
Upload:	vantram
View:	230 times
Download:	0 times

PROJECT PERIODIC REPORT - srs-project.eu | Multi …srs-project.eu/sites/default/files/SRS 247772...

Documents