System Architecture Guide - Revision history

Dvernon: /* Inter-connectivity between the three components */

2014-09-01T14:04:02Z

‎Inter-connectivity between the three components

Dvernon: /* Inter-connectivity between the three components */

2014-09-01T14:03:30Z

‎Inter-connectivity between the three components

Dvernon: /* The sensoryInterpretation Component */

2014-09-01T14:02:53Z

‎The sensoryInterpretation Component

Dvernon: /* Primitives and Ports */

2014-09-01T14:00:40Z

‎Primitives and Ports

Dvernon at 06:32, 1 September 2014

2014-09-01T06:32:44Z

Dvernon at 06:30, 1 September 2014

2014-09-01T06:30:57Z

Show changes

Dvernon at 06:17, 1 September 2014

2014-09-01T06:17:23Z

Dvernon: Created page with "Introduction The DREAM software system comprises three main sub-systems, corresponding to work-packages WP4 (Sensing and Interpretation), WP5 (Child Behaviour Analysis) and W..."

2014-09-01T06:11:56Z

Created page with "Introduction The DREAM software system comprises three main sub-systems, corresponding to work-packages WP4 (Sensing and Interpretation), WP5 (Child Behaviour Analysis) and W..."

New page

Introduction

The DREAM software system comprises three main sub-systems, corresponding to work-packages WP4 (Sensing and Interpretation), WP5 (Child Behaviour Analysis) and WP6 (Robot Behaviour). Initially, these three sub-systems are implemented by three place-holder components, as follows.
1. sensoryInterpretation
2. childBehaviourClassification 3. cognitiveControl
The functionality of each sub-system will be developed incrementally as the project progresses and as new components that implement part of the functionality encapsulated in the place-holder components are developed and integrated into the system. During integration, white-box testing will be performed on a system-level by removing the driver and stub functions that simulate the output and input of data in the top-level system architecture, i.e. in one of the three components above, allowing that source and sink functionality to be provided instead by the component being integrated.
The functionality of sensoryInterpretation is specified completely by the 25 perception primitives defined in Section 2 of Deliverable D1.3 (Child Behaviour Specification).
The functionality of cognitiveControl is specified partially by the seven action primitives de- fined in Section 2 of Deliverable D1.2 (Robot Behaviour Specification). It is only a partial specifica- tion because the basis for invoking each of these action primitives has not yet been defined (whereas, in the case of sensoryInterpretation, all of the primitives are continually invoked to monitor the status of the robot’s environment).
The functionality of childBehaviourClassification is encapsulated by three primitives, as follows (the primitives are defined in Section 7).
1. getChildBehaviour(state)
2. getChildMotivation(degree_of_engagement)
3. getChildPerformance(degree_of_performance)

Primitives and Ports

The parameters of every primitive in the three sub-systems are explosed by two dedicated ports, one for input and one for output, with the arguments encapsulated in a YARP bottle, a simple but flexible way of sending and receiving messages in YARP (for an example, see the protoComponent port used by the respond() method in protoComponentConfiguration.cpp as described in the DREAM wiki).
Thegeneralnamingconventionforthetwoportsis/<primitive name>:iforinputand /<primitive name>:oforoutput.

The sensoryInterpretation Component
The following are the primitives and associated input and output ports in the sensoryInterpretation component. Note that not all primitives have input parameters. The components for those that do are stateful, i.e. once the associated argument values are set, they remain persistently in that state until reset by another input.
checkMutualGaze()
/sensoryInterpretation/checkMutualGaze:o
getArmAngle(left_azimuth, elevation, right_azimuth, elevation)
/sensoryInterpretation/getArmAngle:o
getBody(body_x, y, z)
/sensoryInterpretation/getArmAngle:o
getBodyPose(<joint_i>)
/sensoryInterpretation/getBodyPose:o
getEyeGaze(eye, x, y, z)
/sensoryInterpretation/getEyeGaze:i
/sensoryInterpretation/getEyeGaze:o
getEyes(eyeL_x, y, z, eyeR_x, y, z)
/sensoryInterpretation/getEyes:o
getFaces(<x, y, z>)
/sensoryInterpretation/getFaces:o
getGripLocation(object_x, y, z, grip_x, y, z)
/sensoryInterpretation/getGripLocation:i
/sensoryInterpretation/getGripLocation:o
getHands(<x, y, z>)
/sensoryInterpretation/getHands:o
getHead(head_x, y, z)
/sensoryInterpretation/getHead:o
getHeadGaze(<plane_x, y, z>, x, y, z)
/sensoryInterpretation/getHeadGaze:i
/sensoryInterpretation/getHeadGaze:o
getHeadGaze(x, y, z)
/sensoryInterpretation/getHeadGaze:o
getObjects(<x, y, z>)

/sensoryInterpretation/getObjects
getObjects(centre_x, y, z, radius, <x, y, z>)
/sensoryInterpretation/getObjects:i
/sensoryInterpretation/getObjects:o
getObjectTableDistance(object_x, y, z, vertical_distance)
/sensoryInterpretation/getObjectTableDistance:i
/sensoryInterpretation/getObjectTableDistance:o
getSoundDirection(threshold, azimuth, elevation)
/sensoryInterpretation/getSoundDirection:i
/sensoryInterpretation/getSoundDirection:o
identifyFace(x, y, z, face_id)
/sensoryInterpretation/identifyFace:i
/sensoryInterpretation/identifyFace:o
identifyFaceExpression(x, y, z, expression_id)
/sensoryInterpretation/identifyFaceExpression:i
/sensoryInterpretation/identifyFaceExpression:o
identifyObject(x, y, z, object_id)
/sensoryInterpretation/identifyObject:i
/sensoryInterpretation/identifyObject:o
identifyTrajectory(<x, y, z, t>, trajectory_descriptor)
/sensoryInterpretation/identifyTrajectory:i
/sensoryInterpretation/identifyTrajectory:o
identifyVoice(voice_descriptor)
/sensoryInterpretation/identifyVoice:o
recognizeSpeech(text)
/sensoryInterpretation/recognizeSpeech:o
trackFace(seed_x, y, z, time_interval, projected_x, y, z)
/sensoryInterpretation/trackFace:i
/sensoryInterpretation/trackFace:o
trackHand(seed_x, y, z, time_interval, projected_x, y, z)
/sensoryInterpretation/trackFace:i
/sensoryInterpretation/trackFace:o
trackObject(objectDescriptor, seed_x, y, z, time_interval, projected_x, y, z)
/sensoryInterpretation/trackObject:i
/sensoryInterpretation/trackObject:o

The childBehaviourClassification Component
The following are the primitives and associated input ports in the childBehaviourClassification com-
ponent.
getChildBehaviour(state)
/childBehaviourClassification/getChildBehaviour:o
getChildMotivation(degree_of_engagement)
/childBehaviourClassification/getChildMotivation:o
getChildPerformance(degree_of_performance)
/childBehaviourClassification/getChildPerformance:o
5 The cognitiveControl Component
The following are the primitives and associated input ports in the cognitiveControl component.
grip()
/cognitiveControl/grip:i
moveHand(handDescriptor, x, y, z, roll)
/cognitiveControl/moveHand:i
moveHead (x, y, z)
/cognitiveControl/moveHead:i
moveSequence(sequenceDescriptor)
/cognitiveControl/moveSequence:i
moveTorso (x, y, z)
/cognitiveControl/moveTorso:i
release()
/cognitiveControl/release:i
say(text, tone)
/cognitiveControl/say:i
6 Inter-connectivity between the three components
Any component that need to access the information exposed on the ports associated with a primitive has to have equivalent ports of its own so that the ports can be connected but reversing the input/output designation. Thus, for example, one would connect
/sensoryInterpretation/identifyObject:i to /cognitiveController/identifyObject:o and

/sensoryInterpretation/identifyObject:o to /cognitiveController/identifyObject:i. This would allow cognitiveController to send the x, y, and z location of the object to be identi- fied to sensoryInterpretation and then to receive the identification number of that object from sensoryInterpretation (see definition of identifyObject() in Deliverable D1.3).
7
Regarding the connectivity between the three components, the following principles apply.
• each sensoryInterpretation output port is connected to the counterpart input port in the
cognitiveController and childBehaviourClassification components;
• each sensoryInterpretation input port is connected to the counterpart output port in the cognitiveController component (but not the childBehaviourClassification com- ponent);
• each childBehaviourClassification output port is connected to the counterpart input port in the cognitiveController component;
• each cognitiveController input port is, typically, not connected to any counterpart output port in either the sensoryInterpretation or childBehaviourClassification com- ponents since these ports will be typically be used only internally within the components that will constitute the cognitiveController as it is developed.
Child Behaviour Analysis Primitives
getChildBehaviour(state)
This primitive classifies the childs behaviour on the basis of current percepts, producing an integer output representing the child’s state at that moment.
getChildMotivation(degree_of_engagement)
This primitive determines the degree of motivation and engagement on the basis of the temporal se- quence of child behaviour states, quantifying the extent the children are motivated to participate in the tasks with the robot and detect in particular when their attention is lost. The degree_of_engagement is a real number.
getChildPerformance(degree_of_performance)
This primitive determines the degree of performance of the child on the basis of a temporal sequence of child behaviour states, quantifubg the performance of the children in the therapeutic sessions. The degree_of_performance is a real number.

@@ Line 193: / Line 193: @@
 * each <code>childBehaviourClassification<code> output port is connected to the counterpart input port in the <code>cognitiveController</code> component;
-* each <code>cognitiveController</code> input port is, typically, not connected to any counterpart output port in either the <code>sensoryInterpretation</code> or <code>childBehaviourClassification</code> components since these ports will be typically be used only internally within the components that will constitute the <code>cognitiveController<code> as it is developed.
+* each <code>cognitiveController</code> input port is, typically, not connected to any counterpart output port in either the <code>sensoryInterpretation</code> or <code>childBehaviourClassification</code> components since these ports will be typically be used only internally within the components that will constitute the <code>cognitiveController</code> as it is developed.
 ==Child Behaviour Analysis Primitives==

@@ Line 179: / Line 179: @@
 and
-<code>/sensoryInterpretation/identifyObject:o</code> to <code>/cognitiveController/identifyObject:i<code>.
+<code>/sensoryInterpretation/identifyObject:o</code> to <code>/cognitiveController/identifyObject:i</code>.
 This would allow <code>cognitiveController</code> to send the x, y, and z location of the object to be identified to <code>sensoryInterpretation</code> and then to receive the identification number of that object from <code>sensoryInterpretation</code> (see definition of <code>identifyObject()</code> in Deliverable D1.3).

← Older revision		Revision as of 14:00, 1 September 2014
Line 35:		Line 35:
	== Primitives and Ports ==		== Primitives and Ports ==

−	The parameters of every primitive in the three sub-systems are explosed by two dedicated ports, one for input and one for output, with the arguments encapsulated in a YARP bottle, a simple but flexible way of sending and receiving messages in YARP (for an example, see the <code>protoComponent</code> port used by the <code>respond()</code> method in <code>protoComponentConfiguration.cpp<code> as described in the DREAM wiki).	+	The parameters of every primitive in the three sub-systems are explosed by two dedicated ports, one for input and one for output, with the arguments encapsulated in a YARP bottle, a simple but flexible way of sending and receiving messages in YARP (for an example, see the <code>protoComponent</code> port used by the <code>respond()</code> method in <code>protoComponentConfiguration.cpp</code> as described in the DREAM wiki).

@@ Line 14: / Line 14: @@
 The functionality of each sub-system will be developed incrementally as the project progresses and as new components that implement part of the functionality encapsulated in the place-holder components are developed and integrated into the system.
 During integration, white-box testing will be performed on a system-level by removing the driver and stub functions that simulate the output and input of data in the top-level system architecture, i.e. in one of the three components above, allowing that source and sink functionality to be provided instead by the component being integrated.
@@ Line 73: / Line 74: @@
   getHands(<x, y, z>)
     /sensoryInterpretation/getHands:o
   getHead(head_x, y, z)
     /sensoryInterpretation/getHead:o
@@ Line 195: / Line 197: @@
 ==Child Behaviour Analysis Primitives==
-===<code>getChildBehaviour(state)</code>===
+===getChildBehaviour(state)===
 This primitive classifies the child's behaviour on the basis of current percepts, producing an integer output representing the child’s state at that moment.
-===<code>getChildMotivation(degree_of_engagement)</code>===
+===getChildMotivation(degree_of_engagement)===
 This primitive determines the degree of motivation and engagement on the basis of the temporal sequence of child behaviour states, quantifying the extent the children are motivated to participate in the tasks with the robot and detect in particular when their attention is lost. The degree_of_engagement is a real number.
-===<code>getChildPerformance(degree_of_performance)</code>===
+===getChildPerformance(degree_of_performance)===
-This primitive determines the degree of performance of the child on the basis of a temporal sequence of child behaviour states, quantifing the performance of the children in the therapeutic sessions. The degree_of_performance is a real number.
+This primitive determines the degree of performance of the child on the basis of a temporal sequence of child behaviour states, quantifying the performance of the children in the therapeutic sessions. The degree_of_performance is a real number.

@@ Line 1: / Line 1: @@
-Introduction
+== Overview ==
 The DREAM software system comprises three main sub-systems, corresponding to work-packages WP4 (Sensing and Interpretation), WP5 (Child Behaviour Analysis) and WP6 (Robot Behaviour). Initially, these three sub-systems are implemented by three place-holder components, as follows.
-. sensoryInterpretation
-. childBehaviourClassification 3. cognitiveControl
+* <code>sensoryInterpretation</code>
 The functionality of each sub-system will be developed incrementally as the project progresses and as new components that implement part of the functionality encapsulated in the place-holder components are developed and integrated into the system. During integration, white-box testing will be performed on a system-level by removing the driver and stub functions that simulate the output and input of data in the top-level system architecture, i.e. in one of the three components above, allowing that source and sink functionality to be provided instead by the component being integrated.
-The functionality of sensoryInterpretation is specified completely by the 25 perception primitives defined in Section 2 of Deliverable D1.3 (Child Behaviour Specification).
+* <code>childBehaviourClassification</code>
-The functionality of cognitiveControl is specified partially by the seven action primitives de- fined in Section 2 of Deliverable D1.2 (Robot Behaviour Specification). It is only a partial specifica- tion because the basis for invoking each of these action primitives has not yet been defined (whereas, in the case of sensoryInterpretation, all of the primitives are continually invoked to monitor the status of the robot’s environment).
-The functionality of childBehaviourClassification is encapsulated by three primitives, as follows (the primitives are defined in Section 7).
+*<code>cognitiveControl</code>
-. getChildBehaviour(state)
-. getChildMotivation(degree_of_engagement)
+The functionality of each sub-system will be developed incrementally as the project progresses and as new components that implement part of the functionality encapsulated in the place-holder components are developed and integrated into the system.
-. getChildPerformance(degree_of_performance)
 Primitives and Ports