Naeem Khalid Janjua
email: n.janjua@adfa.edu.au

Omar Khadeer Hussain
email: o.hussain@adfa.edu.au

Elizabeth Chang
email: e.chang@adfa.edu.au

Interleaving collaborative planning and execution along with deliberation in logistics and supply chain

Automated planning is a rich technical filed in Artificial Intelligence (AI) and most of the existing research focused on path finding methods in a compact state-transition system where planning is decoupled from execution. The introduction of the Web has led to increasing emphasis in AI on the development of planning algorithms for real-world applications where planning is distributed and plan generation can happen concurrently with plan execution. An example of one such real-world application is logistics and supply chain. In this paper, we envisage a collaborative planning and execution framework for logistics and supply chain operations. The framework supports human planners for a collaborative plan construction. The planning is interleaved with execution where new information collected during execution is used to refine the plan if required. Additionally, planning is defeasible in nature. During planning either conflicting viewpoints may arise among planners and/or the new information collected during execution may result in conflicts among planned tasks (situations). Deliberation module in the proposed framework provides a platform to human planners where they can start an argumentative dialogue to resolve the conflicts by establishing preferences between conflicting tasks. We use situation calculus to model the framework and propose an algorithm to interleave collaborative planning with execution along with deliberation support.

Introduction

Planning and decision making processes have been a hot research area in AI for decades with applications in various domains. For example, it is a core activity to the design, organisation and control of logistics and supply chain activities such as procurement, transportation, inventory management, warehousing and materials handling, quality of services, information management and sharing, risk management etc. Collaborative planning is a process of decision making among interdependent parities that involves joint ownership of decisions and collective responsibility of outcomes, and work as coalitions to achieve common goals that otherwise would have been impossible or too expensive to achieve by an individual party. It is a method for solving shared problems by resolving conflicts.

Collaborative planning consists of two important phases, namely; planning and execution. Traditionally, these were separate apart. Most of the planning systems research focused on automated path finding methods in a compact, state-transition system and they ignored the human aspect in decision making process. These systems as categorised as an offline planning system. For example, in logistics and supply chain it is well-known that the strength of transactional enterprise resource planning (ERP) systems is not in the area of planning instead its execution. Hence, Advanced Planning Systems (APS) have been developed to fill this gap. APS are based on the principles of hierarchical planning and make extensive use of solution approaches known as mathematical programming and meta-heuristics. Multi-agent system planning systems are APS systems applied to independent or loosely-coupled problems to enhance the benefit of distributed planning between autonomous agents as solving this type of problem requires less coordination [START_REF] Torreño | An approach to multi-agent planning with incomplete information[END_REF]. Most of automated software agents who engage in collaboration with others, build a model of other agents' mental states and update their own beliefs and goals as the dialogue progresses. This process is known as dialogue understanding [START_REF] Gabaldon | Dialogue understanding in a logic of action and belief[END_REF]. To handle uncertainty, argumentation-driven frameworks have been proposed that allows different users to share their knowledge and resolve conflicts between them to reach the common goal have been proposed in the literature [START_REF] Torreño | An approach to multi-agent planning with incomplete information[END_REF]. However, in most MAP systems, planning provides the solution, and on execution part, it is executed as merely traversing the identified path. Such system work well in close world assumption where all of the possible effects of each action are know in advance. However, planning becomes very challenging if the environment is dynamically changing (open world assumptions) and is not pre-engineered to conform to software agent needs. Additionally, automated agents might not able to interpret human planner's intensions and could lack ability of planning and deliberation under uncertainty.

The introduction of WWW has led to increasing emphasis in AI on development of planning algorithms for real-world applications where planning is distributed and plan generation can happen concurrently with plan execution. When and how to interleave planning and execution is well defined complex problem in the literature [START_REF] Stone | User-guided interleaving of planning and execution[END_REF]. Additionally, the challenges for software tools supporting collaborative planning include master data integration, user-specific secure data access and the mutual decision-making process. Systems that enable collaborative planning must support partners during each step of the process [START_REF] Kilger | Collaborative planning[END_REF]. The introduction of Semantic Web technology tools for collaboration has addressed some of the issues of collaborative programming such as information has meaning attached to it that makes it understandable across organisational boundaries. The Collaborative planning and acting model [START_REF] Patel | Improving coalition planning by making plans alive[END_REF] is the first attempt that supports human planners in managing, planning information and facilitates the planning process with automated reasoning. However, currents Semantic Web based Collaborative planning models lack the means of representation incomplete, contradictory information and logical relations that define constraints and axioms of domain begin modeled [START_REF] Mott | Representing logic and rationale in semantic web technologies[END_REF].

In our previous work [START_REF] Janjua | A Defeasible Logic Programming-Based Framework to Support Argumentation in Semantic Web Applications[END_REF], we proposed a framework for incomplete and conflicting information representation and developed argumentation-based algorithms for reasoning over such information in Semantic Web applications. In this paper, we extend our previous work and apply it in the area of logistics and supply chain where planning for operational risk may need to be addressed at a spoke by considering the information from other multiple global and region specific locations. We propose a conceptual framework and develop algorithms that interleave planning and execution, thus allow in a timely manner enables the human planners to plan and execute the tasks . In case of conflicting viewpoints, planners start an argumentative dialogue to resolve the conflicts, integrate the changes in the plan and proceed with the execution. We use situation calculus to model the the framework and Defeasible Logic Programming (DeLP) for knowledge representation and reasoning in logistics operations.

Related work

This work lies at the intersection of Artificial intelligence, in particular classical and distributed planning, Multi agent systems, Argumentation based dialogue systems, Reasoning about actions and change, and the Semantic Web. Automated planning system is a kind of APS system that has been an endeavour of AI leading to numerous technologies, however, their application in real world applications has been unfortunately relatively low [START_REF] Ghallab | The actors view of automated planning and acting: A position paper[END_REF][START_REF] Patel | Improving coalition planning by making plans alive[END_REF].

Multi-agent planning system (MAP) involves several autonomous software agents in planning or plan execution activity, share their knowledge and capabilities to provide solutions to loosely-coupled problems with minimum coordination [START_REF] Durfee | Distributed problem solving and planning[END_REF]. Collaborative planning is a distributed planning which as been an active area of research in AI for decades and it is still an open challenge. The various existing work on MAP approaches can be classified according to the planning and coordination models they use.

Firstly, pre-planning distribution of tasks where a software agent plans and distributes the tasks to other agents. For example, Multi-agent Planning by plan Reuse (MARP) agent allocates the task goals to the participating agents that consider both private and public information. MARP agent then calls each agent iteratively for a solution [START_REF] Borrajo | Multi-agent planning by plan reuse[END_REF]. In another work [START_REF] Crosby | Automated agent decomposition for classical planning[END_REF] agent automatically decomposes tasks into MAP problems, which are then locally solved through a centralized heuristic planner. Emphasis is pre-planning for task distribution and execution by individual agents.

Secondly, planning followed by merging plan through coordination where software agents construct independent plans for different subgoals and a centralized algorithm is used to merge those plans. The emphasis is on problem of controlling and coordinating a local plan of agents. For example [START_REF] Durfee | Partial global planning: A coordination framework for distributed hypothesis formation[END_REF] of the most well known approach for coordination of plans called as a partial global planning framework. Planning First is one of the first planners where agents individually synthesize plans through a state-based planner and the resulting local plans are then coordinated through a distributed Constraint Satisfaction Problem [START_REF] Nissim | Multi-agent a* for parallel and distributed systems[END_REF].

Thirdly, interleaving planning and coordination where software agents propose an iterative refinement of the base plan until a consistent joint plan is obtained that solves the problem. Several advantages of this approach have been discussed in the literature [START_REF] Torreño | An approach to multi-agent planning with incomplete information[END_REF].

Although APS systems discussed above provide promising solutions, however, they lack implementations in real world scenarios such as logistics and supply chain. The various reasons reported in literature that leads to low penetration of above mentioned APS systems in real world application areas are as follows [START_REF] Ghallab | The actors view of automated planning and acting: A position paper[END_REF][START_REF] Patel | Improving coalition planning by making plans alive[END_REF]:

1. Human planners want to use tool for better visibility of the planning process but want to control the decision making part of planning phase. 2. High level of automation results in reduced situation awareness, complex and skill degradation. 3. The huge amount time and manpower needed to enter all information. 4. Difficulty of converting human concepts into tool supported language.

Therefore, this research is an attempt to overcome the limitations of the APS system identified above. We propose a conceptual framework to support planning interleaving with execution along with deliberation to help the human planners in determining which actions are possible at current stage, helping them in making the best choice by building arguments in favour and against conflicting planning tasks, refine the plan and execute it.

Basic action theory

Our formalization model is based on situation calculus [START_REF] Mccarthy | Situations, actions, and causal laws[END_REF]. We describe and employ the extended version of Reiter [START_REF] Reiter | On knowledge-based programming with sensing in the situation calculus[END_REF] to formalization our model for argumentationbased collaborative planning and acting model.

In our model, each human planner maintains the representation of the domain as basic action theory and it has the following form:

D = Σ ∪ D ss ∪ D ap ∪ D una ∪ D S 0 (1)
Where is a set of fundamental domain-independent axioms providing the basic properties of the situation.

-D ss is a set of successor state axioms represent relational or functional fluents in the domain. Formally, P oss(a, s)

⊃ [T (do(a, s)) ≡ γ + T (a, s) ∨ (T (s) ∧ ¬γ - T (a, s))]
where γ + T and γ - T represent the add and delete conditions of fluent T.

-D ap is a set of precondition axioms under which action can be performed.

Formally, represented as Π A (s) ≡ P oss(A, S). -D una is a set of unique names axioms for actions.

-D S0 is a set of first order sentence that represents initial state of the world.

A basic action theory for logistics application specifies a plan and the tasks of the domain of concern and the contextual settings in which the dialogue operates. A plan in situation calculus is treated as an executable situation that satisfies a goal statement. We assume that the sets Fluents, NonFluents and Actions are shared among the planners. Additionally, they share a common goal, knowledge about the fundamental axioms, unique name axioms for actions and the names of object in the domain. We use the definition of plan and planning problem defined in [START_REF] Belesiotis | A generative dialogue system for arguing about plans in situation calculus[END_REF] as follows:

Definition 1. Given a basic action theory D and a Goal g with single free variable s, a plan π is a variable-free situation term s π iff D| = executable(s π ) ∧ g(s π ) where executable(s π ) def = (∀a, s * ).do(a, s * ) s Π ⊃ P oss(a, s * ).

It is important to note here is that the term s π represents the history for the execution of the actions of a plan in sequence. Definition 2. A planning problem P is a tuple < D, g > where D is a basic action theory denoting the planning domain and g is a fluent sentence specifying the goal.

As a result of above definition of plan and foundational axioms for situations we can identify that excutable(do(a, s)) ≡ executable(s) ∧ P oss(a, s). This enables the transformation of plan definition as follows:

Definition 3. A plan π = A 1 , A 2 ; .....; A n is a solution to a planning problem p iif D |= P oss(A 1 , S 0 ) ∧ do(A 1 , S 0 ) = S 1 ∧ P oss(A2, S 1 ) ∧ do(A 1 , S 1 ) = S 2 ∧ .... ∧ P oss(A n , S n-1 ) ∧ do(A n , S n-1 ) = S n ∧ G(S n ).
This definition asserts that the actions in the plan can be performed in sequence eventually performing the final action results in goal sentence G be true.

A basic action theory is necessary to define a domain for reasoning. However, in classical AI reasoning is performed under certain assumption such as follows:

1. The given problem can be fully addressed with available information (solution to the problem lies within the available situation tree). In order to elucidate it, let us consider an example. A planner wants to improve a decision making process and he believes that all the information he holds is sufficient to identify the issues and address them. 2. The domain knowledge is consistent. In other words, they assume that there will be no conflicting events and situation during the decision-making process. 3. New information is consistent with the already available information or specifications. 4. New information does not lead to retraction of previous conclusions.

Because of these limitations discussed above, AI failed to provide a solution to many real world scenarios where some of the information or actions in a plan may result in conflicting situations. To overcome this, we employ a model based on an extended version of action theory, D ext , that consider representation of conflicts and provide support for conflict resolution dialogue methodology. -Ω c is a set of axioms for representing conflicting information. For example argument(X,p), argument(Y,¬p), counterArgument(Y, X, do(a,s)), under-Cut(Z,C, do(a,l)) etc. -Ω p is an set of axioms used in deliberation module such as speech acts for communication and dialogue movies for establishing preference between conflicting situations. For example, propose(A), reject(A), Argue(A=>P), Why(P), Support(P) etc.

Definition 5. A situation p conflicts with situation ¬p in a plan iff ¬p executes action a after p has executed an internal action ¬a that conflict with a in the system.

Conf lict(a, a) = counterArgument(p, ¬p, do(a, s)) = def p = ¬p∧P oss(¬p, a, s)∧ (∃¬a, s )[P oss(p, a , s) ∧ do(a , s ) ⊂ s ∧ P oss(a , a, >, s)]

A set of possible conflicts set

Ĉonf lict contains situations that can be used to generate counter-arguments. Note that no situation weights are used in both plan construction and conflict set. Therefore, the attack between arguments are symmetric i.e. they are equally acceptable. Therefore, planners need to perform meta-argumentation to establish a preference between conflicting arguments. Therefore, P ref erence(a , a)= def Assign(Conf lict(a , a))), where assign is a primitive action that triggers Deliberation Dialogue.

The deliberation dialogue is a meta-argumentation system consists of union of arguments that are constructed by the proponent and the opponents i.e. A = A pro ∪ A opps . As a result of the dialogue process, argumentation lines are constructed and acceptability of arguments is computed to establish priority between conflicting situations. Once the priority is established, the preference is included into the plan along with reasoning/argumentation line supporting it. We reuse the syntax and semantics for argumentation system defined in [START_REF] Janjua | Web@ idss-argumentation-enabled web-based idss for reasoning over incomplete and conflicting information[END_REF] and extend it for dialogue based system using semantics defined in [START_REF] Kok | A formal argumentation framework for deliberation dialogues[END_REF]. We explain the working of argumentation based dialogue system in section 4. The conceptual framework shown in figure 1 provides the infrastructure for collaborative planning to synthesis plan whose success is suggested by the evidence provided by the planners and evaluate the acceptability of the plan by comparing the evidence supporting them against possible objections (conflicts). The advantage of deliberation (argumentative dialogue) within the domain of decision making is its ability to manage conflicts in the knowledge, preferences and the rules by which a decision is made. Therefore, the notion of acceptability is embedded within the planning problem and the plans are supported with arguments. In following sub-sections we explain working of the framework in detail.

Planning module

A planner needs to reason about its actions. Therefore, they need models for choosing, organising, and revisiting their actions and plans [START_REF] Ghallab | The actors view of automated planning and acting: A position paper[END_REF]. During collaborative planning it might be possible that planner may need to retract from planning task defined earlier. Therefore, the knowledge representation model should be expressive enough to represent planning task that may be retracted later. Therefore the planning is defeasible in nature. DeLP is a general-purpose defeasible argumentation formalism based on logic programming, intended to model inconsistent and potentially contradictory knowledge (both strong and weak negation). A defeasible logic program has the form ψ= (Π, Δ), where Π and Δ stand for strict knowledge and defeasible knowledge, respectively. We extended DeLP for knowledge representation and reasoning in semantic web application [START_REF] Janjua | A Defeasible Logic Programming-Based Framework to Support Argumentation in Semantic Web Applications[END_REF]. We defined syntax and semantics for strict and defeasible rule representation. We reuse our work here for defining the planning tasks. In the rule base, a planning task (rule) takes the following form [rule identifier] [rule body] [type of rule] [head]. The rule body represents precondition and rule head represent the effects. Planners have objective and to achieve them, they define tasks using a web-based interface. A human planner who need to collaborate with other human planners to achieve some common goals, define their planning tasks in the form of strict and defeasible rules. Each planner defines its tasks and as a result the system produces a process map using forward chain reasoning as described in [START_REF] Janjua | Process map discovery from business policies: A knowledge representation approach with argumentative reasoning (kr@ pmd)[END_REF]. In such collaborative problem solving model, forward chain reasoning is used to digitize the plans and make them alive for the human planners. For more information about forward chain reasoning using rete algorithm, readers are referred to [START_REF] Janjua | Web@ idss-argumentation-enabled web-based idss for reasoning over incomplete and conflicting information[END_REF]. It is important to note is that the planning task are initiated with domain knowledge defined in descriptive model. We used ontologies to define domain knowledge and used rules defined in Table 1 to transform ontology implicit knowledge to become explicit for rule based reasoning.

Rule 1 type(X,C)→C(X) Class Rule 2 subClassof(Sc, C), Sc(X)→C(X) Subclass Rule 3 objectProperty(X), domain(X, Y), range(X,Z) →X (Y, Z) Object Property Rule 4 objectProperty(X), X(Z, V), subProperty(X, Y)→Y(Z, X) subProperty Rule 5 dataProperty(X), domain(X, Y), range(X, Z) →X(Y, Z) Data Property Rule 6 dataproperty(X), X(Z, V), subProperty(X, Y)→Y(Z, X) SubProperty Table 1. Translation rules for OWL/RDF predicates to DeLP facts

Deliberation module

Time pressure and the distributed nature of logistics and supply chain, force the planners to execute an action. In non-deterministic planning domain, execution of plan tasks is the best source of collecting real observations as an effect of the plan. In most of real world applications, planning is defeasible in nature and execution of plan tasks may result in conflicting tasks or retraction of previous planning results. We build deliberation module on the work done by [START_REF] Kok | A formal argumentation framework for deliberation dialogues[END_REF] and it helps planners firstly; to put forward their arguments that may be incomplete statements and offer them ways of advancing well-formed arguments as well as to reuse arguments that often appear in discussions, secondly; with the help of algorithms to compute the acceptability of arguments at any stage of the discussion. The deliberation module is defined by: -Topic Language: DeLP as a logical language.

-Argumentation Logic: as defined in [START_REF] Janjua | Web@ idss-argumentation-enabled web-based idss for reasoning over incomplete and conflicting information[END_REF]. The only difference is that in our previous work it was assumed that system has collated all the relevant information and hybrid reasoning engine reasoning over it. Here, we replace automated algorithm with human planners and conflict resolution process is a dialogue driven activity. We reuse the definition of argument, sub-argument, attack, static defeat , dynamic defeat. -Communication Language: Set of Locutions S and two binary relation Ra and Rs of attacking and surrendering reply on S. -Dialogue Moves and Termination: as defined in [START_REF] Kok | A formal argumentation framework for deliberation dialogues[END_REF].

It might be possible that task defined as defeasible tasks may get in conflict with other task. If both tasks are defined by a single planner, he can define a preference between conflicting tasks during planning phase, Otherwise, during execution, deliberation module is used to establish preference between conflicting tasks.

Inter-leaving planning, execution and deliberation

Various approaches in the literature [32, 33], including our previous work [START_REF] Kok | A formal argumentation framework for deliberation dialogues[END_REF], have developed argumentation-based algorithms for closed-loop systems, but no work has been done to identify and model the interaction steps of argumentation when various stakeholders are involved in the risk management of an open-loop system such as logistics and supply chain that needs interleaving planning and execution. The proposed framework address this drawback by by interleaving planning and execution.

The collaborative planning algorithm interleaving execution, integrated with argumentation-driven dialogue system works as follows:

1. Terminate the collaborative planning activity if the objective statement is satisfied in current planning phase. Return a list of tasks (situations) indicating which have been executed. 2. Check if there is an executable plan task i.e., a step which has been planned but not yet executed. if there is none, go to step 4 3. For every executable plan task, executed the task -Incorporate new found information from execution into planning stage.

-if conflict arise, initiate call to deliberation module for establishment of preference over conflicting situations.

-Go to step 2 4. Plan:

-Either --identify a objective that needs to be achieved.

--Add a new tasks to the existing plan step to achieve the objective.

-Or --Apply (simulate execution of) tasks previously selected to be in the plan.

-Go to step 1

Conclusion

In this paper, we propose a collaborative planning and execution framework. MAP based approaches discussed in literature takes planning and execution as separate steps and as a result, most of their implementations lack real-world applications. Our work is first of its kind that provides a collaborating environment to human planners where planning interleave with the execution along with deliberation support in an open loop system like logistics and supply chain. We plan to develop a prototype system and extend the system's functionality with conflict blocking and conflict propagation based reasoning models.

Definition 4 .

 4 Extended action theory is defined as follows:D ext = D ∪ Ω c ∪ Ω p where-D is a basic action theory.

Definition 6 .

 6 Given extended action theory D ext , a collaborative plan Π for a common Goal G is a variable-free situation term s Π iff D ext |= executable(s Π ) ∧ G(s π ) where executable(s Π ) def = (∀a, s * ).do(a, s * ) s Π ⊃ P oss(a, s * ) and if conflict exists, there exists a preference relationship, such that P ref erence(a , a) ≡ Support(a , a) |= do(a , s) Definition 7. A collaborative planning solution CP s is a tuple < D ext , G, p > where D ext is extended action theory for representing the sequence of actions and G is a fluent sentence specifying the goal and p represents the priority relationships over conflicting situations.

Fig. 1 .

 1 Fig. 1. Interleaving collaborative planning and execution framework along with deliberation in logistics and supply chain


Leonardo Angelini

Jürgen Baumgartner

Francesco Carrino

Stefano Carrino

Maurizio Caon

Omar Abou Khaled

Jürgen Sauer

Denis Lalanne

Elena Mugellini

Andreas Sonderegger

Omar Abou Khaled

Comparing Gesture, Speech and Touch Interaction Modalities for In-Vehicle Infotainment Systems

Keywords: Gestures, touch, speech, HUD, IVIS comparison. ACM Classification H.5.m. Information interfaces and presentation (e.g., HCI): Miscellaneous

published or not. The documents may come

INTRODUCTION

Increasing the driver experience while maintaining a high safety level is one of the hardest challenges for modern car designers. Many companies are moving through a semi-autonomous driving approach, where the driver has the possibility to distract from the primary task that is taken in charge by the autonomous driving system of the car. Nevertheless, taking back the driver in the loop in emergency situations could imply much slower reaction times than a driver that is focused on the primary task [START_REF] Flemisch | Automation spectrum, inner/outer compatibility and other potentially useful human factors concepts for assistance and automation[END_REF]. An alternative approach for increasing the driving experience and safety is leaving the driver engaged in the primary task and optimize the interface for the secondary task in terms of driver distraction and user experience. Several researchers and In-Vehicle Infotainment System (IVIS) designers [START_REF] Angelini | Opportunistic synergy: a classifier fusion engine for micro-gesture recognition[END_REF][START_REF] Iván | Eyes on the road, hands on the wheel: thumb-based interaction techniques for input on steering wheels[END_REF][START_REF] Koyama | Multi-touch steering wheel for in-car tertiary applications using infrared sensors[END_REF] embraced the "eyes on the road, hands on the steering wheel" approach [START_REF] Iván | Eyes on the road, hands on the wheel: thumb-based interaction techniques for input on steering wheels[END_REF], in order to decrease driver distraction and, hopefully, increase safety. Speech and gesture are often used as interaction modalities that can support this approach, especially if combined to a Head-Up Display (HUD) [START_REF] Angelini | Gesturing on the Steering Wheel: a User-elicited taxonomy[END_REF][START_REF] Koyama | Multi-touch steering wheel for in-car tertiary applications using infrared sensors[END_REF].

In order to understand the impact of the different interaction modalities on driving performances and on the user experience, we compared three different interfaces for the IVIS, each based on a different interaction modality: speech, gesture and touch. The speech interface was designed to comply with the eyes on the road, hand on the steering wheel approach, combined with a HUD. The gestural interface adopted the same approach and investigated a novel trend, i.e., gesturing on the steering wheel. Nevertheless, in order to increase the user experience, we chose to adopt user-elicited gestures [START_REF] Morris | Understanding users' preferences for surface gestures[END_REF], which required leaving one hand from the steering wheel, thus, losing partially the "hands on the steering wheel" safety constraint. The third interface used a popular interaction modality in modern cars, i.e., a touch interface on the dashboard, which does not comply at all with the "eyes on the road, hands on the steering wheel approach". Following these considerations, we could expect a negative impact of the touch interface on driving performance. Obviously, besides driving performances (e.g., number of accidents and infractions), we are interested in investigating the user experience of the driver; therefore, subjective evaluations on the usability, emotional response and perceived workload were conducted.

In the next section, we present previous studies assessing and comparing the three different interaction modalities for the IVIS, with a particular focus on gestural interfaces on the steering wheel. Then, we describe the three interfaces designed for this experiment and the test methodology. Finally, we present and discuss the results.

These gestures are performed either while firmly holding the steering wheel [START_REF] Angelini | Gesturing on the Steering Wheel: a User-elicited taxonomy[END_REF][START_REF] Döring | Gestural interaction on the steering wheel: reducing the visual demand[END_REF][START_REF] Endres | Geremin": 2D microgestures for drivers based on electric field sensing[END_REF][START_REF] Iván | Eyes on the road, hands on the wheel: thumb-based interaction techniques for input on steering wheels[END_REF][START_REF] Koyama | Multi-touch steering wheel for in-car tertiary applications using infrared sensors[END_REF], or after shifting the hand position [START_REF] Angelini | Gesturing on the Steering Wheel: a User-elicited taxonomy[END_REF][START_REF] Koyama | Multi-touch steering wheel for in-car tertiary applications using infrared sensors[END_REF][START_REF] Ei-Wen | Development and evaluation of automotive speech interfaces: useful information from the human factors and the related literature[END_REF]. Döring et al. used a user elicitation approach for the design of a gestural interface on a touchscreen integrated in the steering wheel, but they restricted the possible interaction areas to two input fields close to left and right edges of the steering wheel [START_REF] Döring | Gestural interaction on the steering wheel: reducing the visual demand[END_REF]. As a result, the most common gestures elicited by participants were always performed with their thumbs without leaving the hands from the steering wheel. Recently, Angelini et al. presented a user-elicited taxonomy of gestures performed on the entire surface of a standard steering wheel [START_REF] Angelini | Gesturing on the Steering Wheel: a User-elicited taxonomy[END_REF]. A larger variety of different gestures were proposed by the users and two different trends were evidenced: some people suggested gestures to be performed without taking the hands off the steering wheel, while others suggested gestures that required taking at least one hand off the steering wheel. We decided to use the results of this user elicitation to design a gestural interface that could be perceived as intuitive by the users, as suggested by Morris et al. [START_REF] Morris | Understanding users' preferences for surface gestures[END_REF].

Although several researchers presented an interface with gestures performed on the steering wheel [START_REF] Angelini | Opportunistic synergy: a classifier fusion engine for micro-gesture recognition[END_REF][START_REF] Döring | Gestural interaction on the steering wheel: reducing the visual demand[END_REF][START_REF] Endres | Geremin": 2D microgestures for drivers based on electric field sensing[END_REF][START_REF] Koyama | Multi-touch steering wheel for in-car tertiary applications using infrared sensors[END_REF][START_REF] Ei-Wen | Development and evaluation of automotive speech interfaces: useful information from the human factors and the related literature[END_REF], among them, only Döring et al. compared gestures to different interaction modalities [START_REF] Döring | Gestural interaction on the steering wheel: reducing the visual demand[END_REF]. Indeed, the authors compared their interface to two traditional interfaces, a radio with buttons in the central dashboard for the music control task and a conventional car navigation system for the navigation task. While they did not find significant differences on the driving performances, they found a significant decrease on the amount of glances and the time spent looking away from the road when using the gestural interfaces compared to the traditional ones. Generally, users rated the gestural interface higher compared to the traditional interfaces in terms of general preference, distraction, and easiness of use. Bach et al. compared gestures on a touchscreen to a touch interface with graphical buttons and a traditional car radio with tangible buttons noticing a decreased lateral deviation for the gestural interface compared to the central dashboard with buttons [START_REF] Bach | You can touch, but you can't look: interacting with in-vehicle systems[END_REF]. In terms of interaction time, users were faster using the touch interface compared to gestures and buttons. Also in this study the gestural interface was largely preferred to traditional interfaces. In our study, we compared the gestural interaction modality to two state of the art interaction modalities: speech interaction (combined to a HUD) and touch interaction on a large Android touchscreen.

Several studies investigated the implications and risks of using speech-based interfaces in the car [START_REF] He | Texting while driving: is speechbased texting less risky than handheld texting?[END_REF][START_REF] Ei-Wen | Development and evaluation of automotive speech interfaces: useful information from the human factors and the related literature[END_REF][START_REF] Maciej | Comparison of manual vs. speech-based interaction with in-vehicle information systems[END_REF]. Maciej and Vollrath compared a touchscreen interface in the dashboard and a speech based interface during the execution of four IVIS tasks (audio, phone number selection, navigation system with address entry and pointof-interest selection), obtaining better driving performances with the speech based interface for all the tasks except the point of interest selection, which required higher visual attention on the lateral screen [START_REF] Maciej | Comparison of manual vs. speech-based interaction with in-vehicle information systems[END_REF]. Nevertheless, the authors stressed that the driving performances while using the speech interface were significantly worse than the baseline (i.e., without interacting with any interface), especially with a more demanding primary task (in their case, the "Lane Change Task"). Similar conclusions were drawn by He et al. for speech-based text entry compared to a handheld touch device [START_REF] He | Texting while driving: is speechbased texting less risky than handheld texting?[END_REF]. In our experiment we focused the comparison only on menu-based tasks, avoiding more complex tasks such as text entry or navigation to an address, with the aim of comparing the three different interaction modalities on a same structured menu interface.

SYSTEM DESIGN

This section describes the three interfaces that we designed to compare three different interaction modalities (gesture, speech and touch):

• Gestural interface on the steering wheel and visual feedback on the HUD • Speech-based interface and visual feedback on the HUD • Touch interface on the dashboard (with inherent feedback)

Since the aim of this study is comparing the interaction modalities, not whole interfaces (which includes also information presentation, feedback, etc.), we designed the rationale behind the interface to be exactly the same. We adopted a hierarchical menu interface where the elements shown within the HUD for the first two modalities and the elements shown within screen of the tablet were the same, even if displayed in a slightly different manner to adapt to the requirements and possibilities of the two interfaces. In particular, the goal of the interaction scenario was to navigate the menu in order to accomplish some predetermined tasks. The structure of the menu was the same for all the interaction modalities and the number of interactions required to complete the proposed tasks was exactly the same in the three cases. The first level of the menu contains three items (Music, Contacts and Reminders), which correspond to the three functions implemented in the IVIS (Music Player, Phone Calls and Vocal Assistant). The second level displays the content of each menu. Each content list has a circular structure (the last item is linked with the first one).

In the HUD system, we implemented a menu layout similar to the Cover Wheel Layout (but with no 3D effect) [START_REF] Mitsopoulos-Rubens | Effects on driving performance of interacting with an in-vehicle music player: A comparison of three interface layout concepts for information presentation[END_REF], as shown in Figure 1. As shown by Mitsopoulos-Rubens et al. [START_REF] Mitsopoulos-Rubens | Effects on driving performance of interacting with an in-vehicle music player: A comparison of three interface layout concepts for information presentation[END_REF], this layout structure should not have an impact on performance compared to a list layout, often used in other HUD interfaces. The items of the list are displayed horizontally, with the selected item in the center, highlighted. The HUD was implemented only for the gesture and speech modalities; for the touch modality, the user relied only on the touchscreen visual feedback, which is the typical configuration available in commercial vehicles. We provided the same audio feedback (music, traffic alerts or simulated phone calls) for the three interfaces through stereo speakers.

The commands that allowed the navigation through the menu items were the following: VOLUME UP, VOLUME DOWN, NEXT, PREVIOUS, SELECT and BACK. The first two commands allowed to set the desired volume (in ten steps), the NEXT and PREVIOUS commands allowed going to next and previous elements in the list, while SELECT and BACK were used respectively to select or play an item and go back to the parent item. Each interface implemented the commands exploiting the corresponding interaction modality, as described in the following subsections. Since the main purpose of the design phase was to obtain similar interfaces for the different interaction modalities, each interface offered a sub-optimal user experience, compared to what could have been achieved following the best practices for each interface.

Gestural Interface (WheelSense)

In a precedent study conducted by Angelini et al. [START_REF] Angelini | Gesturing on the Steering Wheel: a User-elicited taxonomy[END_REF], 20 users were asked to elicit pairs of gestures to operate a HUD with the six aforementioned commands (Volume UP/DOWN, NEXT/PREVIOUS, SELECT/BACK). Users were allowed to suggest any type of gesture that implied a contact with any part of the steering wheel.

The gestures preferred (i.e., elicited more often) by the participants were adopted for designing the interface of this study. The selected gestures were the followings: All the six gestures required to temporarily remove one hand from the steering wheel. The gestures on the left/right side of the steering wheel were performed with the corresponding hand. For the gestures on the top and the bottom, the users could use their preferred hand according to the situation and personal preferences.

•
Figure 2 shows the six gestures performed on the related steering wheel region.

In order to recognize gestures, we implemented a system, called WheelSense, based on capacitive sensors integrated in a Logitech G27 steering wheel (depicted in Figure 2). The system is based on a Freescale MPR121 capacitive sensor connected to an Arduino Uno board. We built electrodes sticking strips of copper tape on the steering wheel. To avoid encumbering cables, the sensor data were sent through a Bluetooth connection to the PC where a C# application recognized gestures through a simple threshold-based algorithm. This algorithm did not require to be trained with each user and allowed lowlatency responses of the system to users' gestures (<200ms). Moreover, the system did not require manual gesture segmentation. To avoid undesirable false positives, the gesture recognizer was disabled while steering right or left and while no task was assigned to the experiment participants. For the vocal interface, we chose to simplify as much as possible the corresponding vocal commands. The following list reports the six vocal commands:

• Volume UP: "Up"

• Volume DOWN: "Down"

• PREVIOUS: "Left"

• NEXT: "Right"

• SELECT: "Select"

• BACK: "Back"

During the experiment, the vocal commands were recognized through a Wizard of Oz approach [START_REF] Kelley | An iterative design methodology for user-friendly natural language office information applications[END_REF]. This method allowed creating the sense of a natural interface where the time between the user's command and the system execution was similar to the dialog between humans. To keep the interface as natural as possible, we considered that the speech interface did not require any manual (e.g., pressing a button) or spoken keyword segmentation for the vocal commands.

Touch Interface

The touch interface was designed for an Android Tablet with a screen size of 10.1 inches, positioned in portrait mode, to simulate a central vertical touch dashboard.

We exploited the size of this screen to make the items of the menu as big as possible, in order to facilitate the touch interaction and the readability of the information. Each button represented a command. We used simple icons that were easy to interpret for the participants. Although the menu content was the same as in the two HUD interfaces used in the previous interactions, we exploited the whole surface of the screen to make some information more noticeable. Figure 4 shows the placement of tablet and provides a hint of the user interface. Figure 3 details

TEST METHODOLOGY

Participants

The sample of this study consists of 60 participants (50 female). All of them were in possession of a valid driving license, and aged between 18 and 40 years (M = 23.22, SD = 4.43).

Self-reports showed that the participants rated themselves as average drivers (M = 4.37 on a seven-point Likert scale from "beginner" to "expert", SD = 1.10). With regard to simulator experience, they rather rated themselves as beginners (M = 2.30, SD = 1.38).

When asked about the frequency of usage of different interaction modalities in the car in a 7 point Likert scale, buttons were by far the most used interface (M=4.6, SD=1.9) followed by touchscreen (M=2.0, SD =1.6) and speech interaction (M=1.2, SD=0.7). Concerning the interaction modality that users considered as easier to use to interact with an IVIS, 5 participants answered the speech interaction, 1 the touch interaction and 54 an interface with buttons. Since there are no commercial cars equipped with a gestural interface, it was not included as an option in the questionnaire.

Experimental Design

In this study we decided to use a driving simulation scenario that could be as close as possible to a real driving scenario. The driving scenario was in a city center with average traffic and pedestrian crossing. This choice was made to ensure obtaining a measurement of perceived cognitive workload and of the emotional response as close as possible to a real driving simulation.

For this reason, we did not use the standard measurement tools for assessing driving performances, such as the Line Change Task [START_REF] Mattes | The lane-change-task as a tool for driver distraction evaluation[END_REF] or for assessing the cognitive workload, such as the Detection Response Task (ISO/CD 17488).

In a one-factorial design, IVIS interface was used as a between-subjects variable, being varied on three levels: participants used either a touch interface, or a speechbased interface or a gestural interface (20 participants per interface).

Participants had to complete different tasks in a driving simulation. The dual task paradigm was applied. The primary task was to drive a defined route in the driving simulation. Participants were asked to respect traffic rules and to drive as safe as possible without stopping on the route. To follow the right itinerary participants were guided via verbal instructions by the investigator. The secondary tasks consisted of different interactions with the IVIS that had to be executed while driving. They were inspired by real tasks typical in IVIS usage. On defined positions of the itinerary, pre-recorded verbal instructions were presented to the participants, describing what they had to do. The following tasks had to be completed during the drive:

• Lower the volume of an incoming traffic alert

• Search for a specific person in the contacts list and start a phone call • Five tasks asked the participants to do some changes in a media player, such as playing a specific song or adjusting the volume

The participants were free to execute the secondary tasks whenever they felt comfortable, postponing the interaction whenever the primary task was too demanding.

Before the experiment, each participant spent 10 minutes to get acquainted with the driving simulator and with the IVIS interface.

Measures

Performance

For primary task performance, three measures were recorded: (1) driving time: the time participants needed to drive the route, (2) violations: the number of infractions of the traffic rules, (3) accidents: number of collisions while driving the route.

In particular, the driving simulator automatically detected and logged the following violations:

• Crossing the lane markings into the opposite lane Regarding secondary task performance, the number of interactions and the completion time for each task was recorded.

•

Subjective workload

To assess the subjective workload while driving, the Driving Activity Load Index (DALI) was applied [START_REF] Pauzié | A Method to Assess the Driver Mental Workload: The Driving Activity Load Index (DALI)[END_REF]. The DALI is a modified version of the National Aeronautics and Space Administration-Task Load Index (NASA-TLX), which has been especially adapted to the driving context [START_REF] Hart | Development of NASA-TLX (Task Load Index): Results of Empirical and Theoretical Research[END_REF]. On a seven-point Likert scale (1 = low; 7 = high) participants rated their perceived workload on seven factors (visual demand, auditory demand, tactile demand, temporal demand, interference, attention and situational stress).

Perceived usability and learnability

As a measure of the perceived usability, the System Usability Scale (SUS) [START_REF] Brooke | SUS -A Quick and Dirty Usability Scale[END_REF] was applied after product usage. The SUS consists of 10 items and is well suited for a quick comparison between systems in regard of usability. Items were rated on a seven-point Likert scale (1 = strongly agree; 7 = strongly disagree), which results in a score between 0 and 100. The overall internal consistency of the questionnaire (Cronbach's α > .91) is high. The learnability and usability factors have been measured using two and eight items of the SUS questionnaire as explained by Lewis and Sauro in [START_REF] Lewis | The factor structure of the system usability scale[END_REF].

Emotions

To measure different aspects of emotion, the PANAVA-KS (short scale for the assessment of positive affect, negative affect and valence) [START_REF] Schallenberger | Kurzskalen zur Erfassung der Positiven Aktivierung, Negativen Aktivierung und Valenz in Experience Sampling Studien[END_REF] was applied. It consists of 10 bipolar adjectives that describe different affective states. Items were rated on a seven-point Likert scale with the two extreme points (e.g. happy: very happy, very unhappy). The psychometric properties of the questionnaire are sufficient (Cronbach's α =.83 for positive affect, .76 for negative affect and .74 for Valence).

Material

The driving simulator was running on an Intel Core i7 Windows PC and displayed on three 19" 1280x1024 LCD screens. Car and IVIS audio feedback was provided through a pair of stereo speakers positioned in front of the user. A Logitech G27 set, including the steering wheel, pedals and the gear stick, was used to control the vehicle in driving simulator. We used a Samsung Nexus 10 Tablet positioned on a reclined portrait stand for the touch interface. We placed the tablet in a position where it was easy to read and easy to reach. However, in order to interact with the system, the participants had to glance at the screen, remove one hand from the steering wheel and touch the desired button. The HUD was implemented through a software overlay on top of the driving simulator. The experimental setup is shown in Figure 4. All the interactions with the IVIS were logged by the system.

Statistical Analysis

For measures of user performance and subjective user ratings, a one-factorial analysis of variance (ANOVA) was carried out, followed by explorative post-hoc comparisons, for which a Bonferroni correction was applied. For most variables, distribution of the data meets normality assumption (e.g., DALI, driving time, measures of affect, SUS usability), there are however several measures that do not (i.e., SUS learnability, no. of accidents). Since our sample is not too small, the sample size is equal in each experimental group (N = 20) and kurtosis is most often rather small, we applied an ANOVA because this method tends to be robust if sample sizes are equal in the different experimental conditions. For the analysis of the data on participants' affective states, a one-factorial analysis of covariance (ANCOVA) was carried out, with the initial baseline measure (taken prior to task completion) used as covariate.

RESULTS

Driving performance

The data of the driving performance are presented in Table 1. Data analysis indicated no significant difference between the different interaction modalities for driving time, driving errors and accidents (all Fs < 1). Task completion time. The analysis of the data of task completion time (see Table 2) revealed a significant effect between the different interaction modalities (F = 5.3; df = 2, 57; p < .01), with post-hoc analysis indicating that task completion time in the touch modality was lower (i.e., higher performance) compared to the WheelSense modality. The other post-hoc comparisons did not reach significance level.

Interaction efficiency. The data about the number of user interactions are also presented in Table 2. Statistical analysis (F = 16.8; df = 2, 57; p < .001) revealed a lower number of user interactions (i.e., higher performance) for the speech control condition compared to the other two conditions (large effects with r between .63 and .68). Since the menu structure for the three IVIS was the same, those findings indicate that participants committed fewer errors in the speech condition.

Subjective evaluation of the IVIS systems

The data of mental workload, perceived usability and learnability are presented in Table 3. Mental workload is reported as the average of the seven items of the DALI questionnaire. As expected, the perceived workload is above average for all the three interfaces. The SUS scores for the touch and voice modality are slightly above average (68 is the average for a SUS score) while the Wheel Sense interface scored slightly below the average. However, the calculated ANOVAs showed no significant effect of interaction modality on the different subjective evaluations of the IVIS systems (all three Fs < 1).

DISCUSSION

The main goal of the present study was to evaluate three different interaction modalities of in-vehicle information systems in the context of a driving simulation study. Measures of driving performance, interaction performance, workload, perceived usability and user affect were recorded. The main results showed some advantages of the speech control (with regard to interaction efficiency) and touch control (regarding task completion time) for performance on the secondary task. This could be explained because user could rapidly execute the same command on a touch interface, especially if they have to press the same button. Since the interaction with the touchscreen is visually demanding, users were sometimes imprecise, making mistakes, for example going too far in the item list in respect to the desired item. The same considerations could not be done for the gestural interface on the steering wheel, probably because the users were not acquainted with this interaction modality.

The interaction modality of the IVIS had no effect on all the other measures assessed in this study (e.g. driving performance, subjective evaluation of the IVIS system as well as on the users' affective state). This result is rather surprising since it was expected that the use of interaction modalities allowing the driver to keep her eyes on the road (i.e., speech and gestures) would result in increased driving performance (e.g., decreasing driving errors and accidents) compared to the use of the touch modality, for which the driver needs to shift her attention from the road towards the central dashboard.

Gestures and speech are uncommon interaction modalities. Users did not have previous experience with similar systems; therefore, it is surprising and satisfactory that ratings of their usability did not differ from the ratings of the better known touch system. Indeed, there was a remarkable difference between the learnability score of the touch and gesture systems, although not statistically significant (p=0.084).

Concerning the absence of difference in driving performance and subjective workload, it can be argued that the novelty of speech control and gestural control might have had some negative influence on performance and perceived workload. Since the interaction with these new systems was uncommon and novel, this might have been the reason for a decrease in driving performance and an increase in subjective workload. The advantages of those systems in comparison with the touch system due to the eyes on the road-principle might hence have been compensated by their disadvantages due their novelty.

LIMITATION

This study focused on the comparison between interactions modalities. For this reason, we used the same hierarchical organization of the menu for the three modalities and we adopted the same commands (i.e., UP, DOWN, RIGHT, LEFT, SELECT, and BACK).

Obviously, each interaction modality could offer several advantages that were not exploited in the designed interface for the sake of a "fair" comparison. For example, considering a speech interface, it could be possible to directly issue an order (e.g., "System, call Home" or "System, play The Man Who Sold The World"). This will reduce the time in which the driver's focus switches from the primary to the secondary task, and will reduce the overall time spent interacting with the IVIS. Nevertheless, a segmentation approach is generally required for most speech recognizers: the current commercial systems require the user to press a button or to use a keyword to activate the vocal interface (such as the word "System" in our example or "Ok, Google" and "Hey Siri" in other systems based on speech recognition).

In our study, we overlook this aspect, using a "Wizard of the Oz" approach, considering the system as able of automatically segment the vocal commands. Finally, the design of interaction-specific solutions can be extremely varied. It means that we risked designing a system too dependent on the design of the interaction, biasing the modality comparison.

Concerning the gestural interaction, the chosen gesture vocabulary could have an impact on the perceived usability and emotional response of the users, although the gesture elicitation approach should have optimized this aspect. We did not count the number of interaction errors made by the users. Since in our setup, it was difficult to discriminate user errors from errors of the recognition system.

Finally, concerning the driving simulator, we tried to set up a real case scenario, in which participants would have experienced a workload typical of a city center driving scenario. Nevertheless, simulated driving cannot be compared with a real driving experiment, also because participants did not have time to get completely acquainted with the driving simulator (participants rated themselves as beginner and have only ten minutes to learn the driving simulator and the IVIS interface). For this reason, the number of driving accidents and violations were sensibly higher than what could be expected in a naturalistic driving scenario.

CONCLUSION

We compared a novel interaction modality for the IVIS, gesturing on the steering wheel, with two classic modalities in modern cars: touch and speech. A between subjects experience involving 20 participants per modality assessed that the gesture-based modality is comparable with the other two in terms of perceived usability, subjective workload and emotional response.

These results are particularly significant since they mean that the novel approach is perceived by the user as a novel realistic opportunity to perform secondary tasks in driving conditions even while compared with approaches that they already have the habit of using.

In future works it will be interesting to evaluate if a multimodal approach could help to overcome the wellknown practical limitation related to each modality (e.g., speech interaction is not suitable in shared space, the touch interaction requires to remove the eyes from the road, and gesture interaction, as novel modality, has a fee to pay in terms of learnability). A comparison between optimal interfaces, designed exploiting all the advantages offered by each interaction modality is also particularly interesting.

Finally, because of the between-subject approach, an extension of the comparison to other interaction modalities, for example buttons on the steering wheel, is also possible.

  Volume UP: hand swipe (toward the top) on the external part of the right side of the steering wheel; • Volume DOWN: hand swipe (toward the bottom) on the external part of the right side of the steering wheel; • PREVIOUS: hand tap on the external part of the left side of the steering wheel; • NEXT: hand tap on the external part of the right side of the steering wheel; • SELECT: hand tap on the frontal part of the top of the steering wheel; • BACK: hand tap on the frontal part of the bottom of the steering wheel;

Figure 1 .

 1 Figure 1. Head-Up Display Interface in a music player item.

Figure 2 .

 2 Figure 2. Logitech G27 Steering Wheel equipped with capacitive sensors, also called WheelSense. Red arrows depict hand-taps and blue arrow the hand-swipe.

Figure 3 .

 3 Figure 3. Four views of the touch interface.

  Pulling over the roadway • Driving in the forbidden direction • Turn Signal not used • Right turn signal not used when changing the lanes • Left turn signal not used when changing the lanes • Driving into the traffic lane without turning the left turn signal • Driving into the traffic lane without turning the right turn signal • Right-of-way at the intersection violated • Not yielding to a pedestrian • Driving more than 10 km/h over the speed limit • Driving more than 20 km/h over the speed limit • Driving more than 30 km/h over the speed limit • Driving on a red light • Hindrance to the vehicle moving in the same direction Similarly, the simulator automatically detected collisions with other cars, environmental objects or pedestrians.

Figure 4 .

 4 Figure 4. Experimental setup

Table 2 :

 2 Performance values on the secondary tasks (lower is better) and results of post-hoc tests (Bonferroni corrected)as a function of interaction modality.

Table 1 : Performance values (lower is better) on the driving task as a function of the interaction modality Secondary task performance (IVIS interaction)

 1

		Touch	Voice	WheelSense
		control	control
		M (SD)	M (SD)	M (SD)
	Time (s)	917 (124) 935 (154) 902 (101)
	Driving	34 (10)	34 (13)	36 (11)
	errors (#)
	Accidents(#) 2.8 (2.3)	3.6 (3.1)	3.0 (2.7)

Table 3 : Subjective evaluation of the IVIS systems (higher is better) as a function of the interaction modality. Affective state of the user

 3

Table 4

 4

	presents the summative results of the questions
	relative to valence, positive affect (PA) and negative
	affect (NA) in the PANAVA-KS questionnaire (two, four
	and four questions, respectively). For the three interfaces,
	both valence and positive affect are slightly above
	average, while negative affect is around average.
	Statistical analysis revealed no significant influence of
	interaction modality on any measure of user affect
	(F Valence = 2.3; df = 2, 54; p > .05; F PA < 1; F NA = 2.8; df =
	2, 54; p = .07). The covariates initial PA showed a
	significant effect on users' PA ratings after task
	completion (F = 8.0; df = 1, 54; p < .01) as well as the
	covariate initial NA was linked with participants' NA
	ratings (F = 15.3; df = 1, 54; p < .001). No other effect of
	a covariate reached significance level.
		Touch	Voice	Wheel
		control	control	Sense
		M (SD)	M (SD)	M (SD)
	Valence (2-14)	10.4 (2.2)	9.1 (1.8)	10.1 (2.0)
	Positive Affect	19.2 (3.0)	18.8 (2.5)	18.7 (3.6)
	(4-28)
	Negative Affect	17.0 (3.4)	17.2 (2.8)	15.3 (3.4)
	(4-28)

Table 4 : Ratings of users' affective states after task completion as a function of the interaction modality.

 4

IHM'16: Contextes et domaines applicatifs 25-28 oct. 2016, Fribourg, Suisse

IHM'16: Contextes et domaines applicatifs 25-28 oct. 2016, Fribourg, Suisse

ACKNOWLEDGMENTS

This work has been supported by Hasler Foundation in the framework of "Living in Smart Environments" project.