0LAUK0 PRE2016 3 Groep18 DetailedScenarios

Process

In this page the process of the summing up scenario is given. Scenario 1 is the first one we made and 4 the final one.

Summing up scenario version 1

Description version 1

This version of the summing up scenario has the following significant elements:

• In the top beginning, there is a choice for which game the child wants to play (to improve interactivity with the child)
• There is a choice element whether the child should throw first or the NAO throws first (to improve interactivity with the child)
• The responses of the robot in this version are still somewhat "static" in the sense that they don't really really take into account the answers of the child (for instance at "Do you want to start?" and "What number did I throw?"

Finite state diagram

Summing up scenario version 2

Description version 2

This version of the summing up scenario has the following significant elements:

• There are less intermediate question 'diamonds' (for instance, we do not include the "maybe"option anymore with the question "Do you understand the game?". The reason is that we think that not all questions or answer cases are that relevant versus how overwhelming many questions could be for the child. Also, we think that the robot should be guiding/take the lead (as a teacher) in the game.
• We added an extra question right at the start of the game; "would you like to learn how the game is played?". This is done so that when the student has already played the game and remembers the rules, he/she does not have to hear the tutorial again.
• When guessing the numbers, the child does not get a 'hint' anymore as in version 1, but instead he/she can just try again once, and otherwise the number is revealed by NAO
• The conversation is made more interactive by actually replying to both the correct and incorrect answer respectively (positive "Well done", negative "This is not correct"). Also, in case of a wrong answer we actually mention the right number instead of giving a hint, so that the skill of student of adding two numbers can stilll be tested indepently of his/her ability to couple the right value to the symbolic representation of the number.
• When the summation of the two numbers is not done correctly. The child then has one more try. If this again is not right, we come up with an extra element in the scenario: the robot again asks for the number on the dice the child and the robot, in that specific order. If the child is giving (one of) the numbers in the wrong order this is also approved and leads to some positive feedback to encourage the child.

Finite state diagram

Summing up scenario version 3

Description version 3

This version of the summing up scenario has the following significant elements:

• In version 3 and 4, we incorporated a format that is used in TiViPe: more module based instead of state based (though we will still call this a 'state diagram').
• In version 3, we work with entries, where every entry represents some action, some line of code in the module in TiViPe.
• For the standard positive and negative feedback, we came up with varying responses for that and collected them in a dictionary. Now when needed, we can just pick one answer randomly out the positive or negative dictionary. Other speech synthesis, however, is still handled separately in a particular module.
• The rest of this state diagram is in further sense the same as version 2. the structure and flow are the same, meaning that no states are deleted or added when we converted to modules (structure), and the same arrows are still directing at the same representing modules (flow).

Finite state diagram

Summing up scenario version 4

Description version 4

In version 4, the technical details TiViPe require are implemented

• Since it is useful for identification and TiviPe requires it; every module is now identified by an unique number; counting from 1
• In TiViPe one has to priorly activate a module before one can actually execute it. Therefore, we have included lines like "-> state 3" to activate state 3.
• More about syntax: the syntax "[]" is used to handle boolean variables. For instance, suppose we have the line "[bool] -> state 3". Then if bool has value TRUE, state 3 gets activated. However, if bool has value FALSE, nothing happens.
• The syntax "%" is used to indicate a variable ("%var" is a variable with name var).
• The structure and flow are the same as in version 3.

Finite state diagram