Nikolena Christofi
email: nikolena.christofi@irt-saintexupery.com

Xavier Pucel
email: xavier.pucel@onera.fr

A Novel Methodology to Construct Digital Twin Models for Spacecraft Operations Using Fault and Behaviour Trees

Keywords: engineering → System modeling languages, Design languages, Architecture description languages, Fault tree analysis, Operational analysis MBSE, MBSA, fault trees (FTs), behaviour trees

Successful satellite data reception requires the nominal operation of the ground stations in charge of their health monitoring as much as the spacecrafts themselves. Although the concept of Model-Based Diagnosis (MBD) in the field of autonomous systems -such as satellites, has long been researched and developed, that is not the case for their ground systems. Both satellites and ground stations operate autonomously. The latter however, are not equipped with the advanced Fault Detection, Isolation and Recovery (FDIR) capabilities one finds today on-board all orbiting spacecrafts. The aim of the study presented in this paper is the improvement of ground stations' operational diagnostics by providing the operators with ad-hock, Operations-Dedicated Models (ODMs). The latter serve as a basis for the construction of the system's Digital Twin (DT) models. These models allow the operators react more quickly and more precisely to alarms raised by the station. By helping the operators identify the malfunction and correct it in the quickest delays, they can avoid loosing the next satellite telemetry (TM) data, thus saving precious time and costs. This would increase both the availability and maintainability of the system. In a larger framework, ODMs are ideally concurrently built and connected with the engineering and safety models of the system, in a sort of virtual continuous improvement loop. While the utter purpose of ODMs is their usage as the system's DTs during operations, they also contribute to the stations' architecture and robustness continuous improvement, through increasing its fault detection and mitigation capabilities.

INTRODUCTION

In the era of digital communications, models are becoming prevalent for the development of complex systems, especially when time and safety are critical. Nevertheless, the use of models is not extended to the field of operations. When operating a satellite system, operators need to detect and isolate -or even mitigate, any occurred fault in a very limited time-frame. However, satellite operators have no exhaustive knowledge of the system architecture, nor its underlying design. They are only expected to monitor the health state of the system and detect any deviations (called symptoms) of it components in the so-called housekeeping data.

Operators' troubleshooting tasks vary depending the health status of the system at each given moment, as indicated by the registered data. Per contra, if a symptom -or a combination of symptoms, is unknown i.e. system designers did not foresee its occurrence, operators are expected to diagnose the system, in order to eliminate the fault, and restore functions to their nominal state (or the least harmful possible). Thus, if the anomaly is not included inside the symptoms' database (no troubleshooting procedures associated), the operators must take individual action.

These actions are usually based on the operators' knowledge and experience. If this knowledge were to be combined with knowledge of the system itself (architectural and behavioural, as well as functional and dysfunctional), operational diagnosis could be improved significantly. For this reason the authors propose the creation of an Operations-Dedicated Model (ODM) [START_REF] Christofi | Towards an agile, model-based multidisciplinary process to improve operational diagnosis in complex systems[END_REF], representing a Digital Twin of the Operations and Maintenance system tasks, for Fault Detection and Diagnosis (FDD).

With the ODM's integration inside a monitoring tool, the operators will be provided a dedicated User Interface (UI) to help them identify anomalies more efficiently (in less time, and with less effort). This will allow them to restore the system more quickly -than currently, where no operations-model is available to them. The authors propose a methodology for the creation of ODMs using the formalism of Behaviour Trees (BTs), taking as input system design information, found inside Fault Trees (FTs). The system healthmonitoring data received at each satellite passage and lessons learnt from operating and maintaining the system i.e. Return of Experience (RoE), are used to feed the Digital Twin model. FTs are produced from system Reliability, Availability and Safety (RAMS) analyses, or Model-Based Safety Assessment (MBSA) models. They thus incorporate dysfunctional system information, but also, indirectly, functional information, since they use as input Systems Engineering (SE) data -including SE models. In the latter case we refer to Model-Based Systems Engineering (MBSE). For this reason FTs constitute a good source of information for the creation of a model dedicated to operational diagnosis. We use a Satellite Ground Station (GS) architecture to demonstrate our proposal.

The structure of the paper is as follows. Related work on current operational diagnosis approaches and BTs is provided in Section 2. Section 3 contemplates the usage of the ODM as the system's DT. Section 4 describes the proposed method; basic terms are formulated and methodological steps are provided in detail. The method is illustrated with a use case example. Finally, Section 5 discusses the proposed method's limitations and Section 6 draws conclusions.

LITERATURE REVIEW

Recently the practise of integrating experimental design in system modelling is being explored. Virtual design in combination with operational data consist the future of the SE practise [START_REF] Azad | Toward an Experiential Design Language: Augmenting Modelbased Systems Engineering with Technical Storytelling in Virtual Worlds[END_REF]. Originally introduced as a means to break information silos and reduce verification and validation (V&V) costs, by allowing design improvement cycles early on the system development -and not at the integration and testing phase, MBSE is being widely adopted by large agencies and organisations around the world, for a variety of aerospace applications. Notable examples are NASA's Europa Clipper [START_REF] Bayer | Model Based Systems Engineering on the Europa mission concept study[END_REF] and Mars 2020 [START_REF] Fosse | Inheriting Curiosity: Leveraging MBSE to Build Mars[END_REF] missions. The enabling of MBSE in combination with the development of Industry 4.0 inspired the development of the DT concept and technology. The past few years DTs are becoming an indispensable part of model-based systems development. An example being the largest aircraft constructors, Airbus and Boeing, who are both working towards developing DTs for their most recent aircraft [START_REF] Palit | Emergence of digital twins[END_REF].

A Digital Twin (DT) is a virtual representation of a physical product, asset, process, system, or service that allows us to understand, predict, and optimise their performance for better business outcomes [START_REF] Tsega | Digital Twin models in industrial operations: State-of-the-art and future research directions[END_REF]. It is essentially a digital version of a system which can also be used for V&V activities. A DT provides an accurate representation of a system's physical structure, logical behavior, physics analytics, its functionality e.g. data processing and communication interfaces [START_REF] Schluse | Experimentable digital twins for model-based systems engineering and simulation-based development[END_REF]. It is used throughout a system's life cycle for evaluating keymetrics and compliances [START_REF] Azad | Model-based systems engineering: Motivation, current status, and research opportunities[END_REF]. In the past few years, the use of DTs in a variety of industrial operations is being explored exhaustively. Nevertheless, and as stated [START_REF] Tsega | Digital Twin models in industrial operations: State-of-the-art and future research directions[END_REF], "there is still a need to identify its value in industrial operations mainly in production, predictive maintenance, and after-sales services".

The field of Model-Based Diagnosis (MBD) is an auspicious candidate for combining with DTs. The greatest challenges still faced in the MBD world are related to system modelling i.e. how to better and more realistically represent the system in question. Within the context of Discrete Event Systems (DES), FDD has made significant advancements in the last decades [START_REF] Paola Cabasino | A comparison among tools for the diagnosability of discrete event systems[END_REF] [START_REF] Hashtrudi Zad | Fault diagnosis in discrete-event systems: framework and model reduction[END_REF]. The most popular solutions consist of Finite State Automata (FSA) [START_REF] Tripakis | Fault Diagnosis for Timed Automata[END_REF] [18] [START_REF] Settele | Plant Model-Based Fault Detection during Aircraft Takeoff Using Non-Deterministic Finite-State Automata[END_REF] or Petri Nets (PNs) [2] [11] variations. With PNs lately dominating the MBD world, they still present major drawbacks and unresolved issues regarding the representation of complex systems, hence their rare application in real-world problems.

More specifically, in petri-nets or automata-based methods (PNs transitions are similar to event firings in FSA), only the start and finish of each simulated event is considered in the modelling, resulting to neglecting the variable dynamics that take place in between [START_REF] Ekanayake | Model-based fault diagnosis and prognosis of dynamic systems: a review[END_REF]. For this and other reasons -explained below, the authors have investigated other possible solutions, resulting to the choice of Behaviour Trees (BTs).

BTs belong to the DES family. They were first invented as a tool to build modular Artificial Intelligence (AI) in computer games. A known alternative to Finite State Machines (FSMs), BTs are meant to provide better modularity, scalability, extendibility, adaptability and reuse of code [START_REF] Colledanchise | Behavior Trees in Robotics and AI: An Introduction[END_REF], and to be easier to understand for humans, thus allowing incremental functionality design and efficient testing.

The choice of BTs for the ODM construction was inspired by the fact that BTs can easily provide a detailed view of the system's current state -in different decomposition levels. This is an indispensable information for the system's operators. More specifically, BTs represent (and implement) a way to control the execution of a set of concurrent processes. Each concurrent process is represented by a leaf node (action; behaviour/function to be executed). Parent nodes (Sequence, Fallback/Selector, Parallel) specify which children nodes must be visited, and in which order. BTs define how the behaviour evolves when one (or all) of its children behaviour succeeds or fails.

More precisely, a Behaviour Tree (BT) is a tuple ⟨B, root, children⟩ where B is a set of behaviours, root ∈ B is the root behaviour, and children : B → B * is a function which associates each behaviour with an ordered (and possibly empty) list of children behaviours. In a BT, each behaviour has exactly one parent -except the root behaviour, which has no parent.

In the next section we further justify our choice of BTs as the language semantics for building the ODM. Moreover, we explain why BTs also meet the DTs requirements; where 𝐷𝑇 = 𝑂𝐷𝑀 𝑒𝑥𝑒𝑐𝑢𝑡𝑒𝑑 + (𝑅𝑜𝐸). More information is provided below.

ODM EXPLOITATION AS DIGITAL TWIN

Figure 1 portrays the interactions between the system architects and safety experts, the ODM design team and the operators, with the ODM and the ODM DT. The left side boxes represent presystem-deployment interactions. The right side boxes illustrate post-system-deployment activities.

As illustrated in Figure 1, ODMs serve a double purpose. On the one hand, since they are concurrently created with the SE & SA/RAMS models, they can provide feedback to the designers, specific to the system's health monitoring and FDIR aspects. This allows the improvement of the system's structural and behavioural design.

On the other hand, following the system deployment, the ODM can immediately be used as a prototype for the system's DT. That is because BTs are executable. The ODM can facilitate the design of test scenarios, distribute diagnosis objectives across the various activities, and ensure that operators are given realistic tasks. The DT model is then periodically updated with any new information supplied by the received system operational data. Eventually, the DT model will be used by operators for FDD purposes. For this an additional intuitive User Interface (UI) is needed, for the operators to be able to execute and exploit the models. This is possible by integrating the DT inside monitoring tools equipped with UI capabilities. BT libraries already provide similar tools, such as Groot for the BehaviourTree.CPP library [START_REF] Faconti | BehaviorTree.CPP[END_REF]. What is more, operational feedback can eventually contribute to the amelioration of the original system, by initiating modifications to the existing architecture while providing compelling information for future systems' design.

Regarding our BT implementation to construct the ODMs, we use the PyTrees (python implementation of BTs) library [START_REF]Pytrees Library Documentation[END_REF]. We found PyTrees relatively easy and intuitive to code with -in comparison to the C-based library alternative we tested, namely Be-haviourTree.CPP [START_REF] Faconti | BehaviorTree.CPP[END_REF]. This way any engineer/scientist can build a BT model, with no particular programming background or developer skills. In the subsection below follows a more elaborated description of BTs, including a definition of its basic constituting elements.

To establish ODM's operational diagnosis capabilities, its language semantics must enable the modelling of FDD related elements. That is, the system's fault detection, automatic diagnosis and recovery features, as well as its fault mitigation mechanisms. Moreover, these semantics must allow associating health indicators to system elements. To that end, we extended the PyTrees library with three entirely new types of nodes, so as to enhance ODMs' system monitoring features. Regarding health indicators, we have have so far enriched the status of each BT behaviour (other than the standard "Success", "Failure" and "Running") with associated alarms. A visual tool demonstrating the feasibility of our approach has also been implemented.

In the following section we present basic BT definitions, as well as our contribution as regards to the extension of the BT library to meet the ODM needs. For that we provide a detailed description of each newly defined node. We then outline the associated developed methodology for the ODM creation from system dysfunctional models.

METHODOLOGICAL DESCRIPTION FOR THE ODM CREATION

Throughout system development, ODMs must gather all system monitoring relevant information, for performing automatic diagnosis and hinting to a single failure candidate. During system operations, ODMs must be easily readable and usable by operators, so as to aid them in their troubleshooting tasks. BT semantics can fulfill both these causes, due to the facility in which one can model complex system behaviours, as well as the intuitiveness of their construction and format. Below we provide basic definitions on BTs as well as the definitions we have introduced within the language semantics, to better suit the requirements for the building and exploitation of ODMs.

ODM Semantics Description: BTs

Figure 2 illustrates a BT, in which the root behaviour is named "Operate system and mitigate faults". Its children are named "Operate system in nominal mode" and "Operate system in degraded mode". The former has children behaviours, while the latter is a leaf behaviour. Each behaviour is composed of its children.

Definition 4.1 (Behaviour status). The set of possible statuses for behaviours is the finite set S = {Idle, Running, Success, Failed}.

At each instant in the execution of a BT, the state of the BT is a function 𝑠𝑡𝑎𝑡𝑒 : B → S, which associates a status to each behaviour in the tree.

A behaviour whose status is not Running can be started by its parent, and its status then becomes Running. A Running behaviour can be interrupted by its parent; its status then becomes Idle. A Running behaviour can also autonomously change its status to Success or Failed.

Leaf behaviours are used to represent the actual activities implemented by the system, under the form of concurrent processes. Their execution is orchestrated by their parent behaviours, which are usually picked among a set of predefined composite behaviours.

We use four predefined types of composite behaviours: Seqence, Fallback and ParallelAll. Definition 4.2 (Sequence behaviour). When a Sequence behaviour starts, it starts its first child. When the currently running child succeeds, the Sequence behaviour starts its next child, or succeeds if it is the last child. If any child behaviour fails, the Sequence behaviour fails at the same instant. In this paper Sequence behaviours are drawn with gray signal shapes .

Definition 4.3 (Fallback behaviour). When a Fallback behaviour starts, it starts its first child. When the currently running child fails, the Fallback behaviour starts its next child, or fails if it is the last child. If any child behaviour succeeds, the Fallback behaviour succeeds at the same instant. In this paper Fallback behaviours are drawn with gray octagon shapes .

Sequence and Fallback behaviours have at most one running child at each instant.

Definition 4.4 (Inverter behaviour

). An Inverter behaviour has exactly one child. It starts its child when it starts, and is running when its child is running; succeeds when its child fails, and fails when its child succeeds. We represent Inverters by triangle arrow decorations . We chose to modify its standard name for distinction reasons with the supplementary parallel behaviour we introduced, as defined shortly below. In this paper, ParallelAll behaviours are represented by gray ∧-shaped trapezia .

In addition to the standard composite behaviours presented above, we introduced three new BT behaviours, related to semantic translations from FTs and to fault diagnosis. They are respectively called ParallelAny and Fault Detection and Fault Avoidance behaviours.

Definition 4.6 (ParallelAny behaviour). When a ParallelAny behaviour starts, it starts all its children in parallel. It fails once all its children have failed. If one child succeeds, ParallelAny behaviour succeeds and interrupts the rest of the children. We represent Par-allelAny behaviours by ∨-shaped gray trapezia . Definition 4.7 (Fault detection behaviour). A Detect behaviour is an atomic behaviour dedicated to detecting a fault. In this behaviour, Success means that it has detected the fault. Otherwise, it stays in the running mode and never fails. Fault detection behaviours are represented by diamonds .

Finally, our methodology uses a type of behaviour that can be either atomic or composite, but their semantic is defined with respect to a specific fault event.

Definition 4.8 (Fault avoidance behaviour). A Fault avoidance behaviour is a behaviour that should fail when the fault event occurs, and never succeed. It can be atomic or composite. In this paper, all behaviours whose names start with "Avoid" are Fault avoidance behaviours.

Fault avoidance behaviours are always associated with a fault event from a FT. They do not always make sense from an operational point of view, and are mostly an artifact used as a temporary translation between the FT and the ODM. Note that in a composite Fault avoidance behaviour, its children must be compatible with the Fault avoidance specification, otherwise the BT is invalid, and its semantic hence undefined.

In Figure 2, the semantics of the BT are as follows. The topmost behaviour is a Fallback, i.e. it tries to run its first child, and in case of failure, falls back to its next child. In this instance, the first behaviour executed is "Operate system in nominal mode". The nominal mode is implemented by a ParallelAll behaviour, that runs the inverted "Detect fault" and "Control system" behaviours in parallel.

When a fault is detected, the "Detect fault" succeeds, so its inverter fails, and thus the whole nominal mode behaviour fails, which interrupts the "Control system" behaviour. Similarly, if the "Control system" fails for some internal reason, the nominal mode fails and interrupts the "Detect fault" behaviour as a result. When the nominal mode fails, the root Fallback behaviour starts the "Operate system in degraded mode" behaviour.

ODM creation

As mentioned earlier, we use FTs as an input source for ODM construction. FTs are the produced result of Fault Tree Analysis (FTA). FTA performs a top-down (deductive) analysis, expressed by the FT, which proceeds through successively more detailed (i.e. lower) levels of the system design, until the probability of occurrence of undesirable event -viz. Feared Event (FE), can be predicted in the context of its environment and operation [START_REF] Kritzinger | Fault Tree Analysis[END_REF] [START_REF] Bai | Subsea Risk and Reliability[END_REF]. The undesired event constitutes the top event -or Feared event (FE), of a Fault Tree (FT) diagram, and represents a complete failure of a product or process. FEs are characterised by their importance of impact to the system itself and its environment (e.g. nature, operators, passengers). The FT segments leading to a FE define all of the things that could go wrong (faults) to cause the FE e.g. loss of telemetry (TM) image data.

Our methodology for obtaining an ODM from a FT is composed of two steps:

1. Translate each FT into a BT (BT-v.1). This step is automated; the purpose is to provide a first draft which accounts for all the faults that can affect the system. 2. Elicit all BTs into a single BT (BT-v.2), in which each behaviour represents an actual activity in operations. This step is done manually by a person with modelling skills, but more importantly operational experience. During the first step, the FT is transformed into a BT as follows.

Definition 4.9 (Fault tree transform FT2BT ). The transform of a FT into a BT is implemented by the function FT2BT defined on FT nodes as follows.

I. If 𝐹𝑇 𝑁 is a basic event named "Fault event 𝑋 ", then: FT2BT (FTN ) is an atomic fault avoidance behaviour named "Avoid fault event 𝑋 ". II. If 𝐹𝑇 𝑁 is an AND gate labelled "Fault event 𝑋 " with children nodes 𝐹𝑇 𝑁 1 , 𝐹𝑇 𝑁 2 , . . . , then FT2BT (FTN ) is a ParallelAny behaviour named "Avoid fault event 𝑋 ", with children behaviours FT2BT (FT 1 ), FT2BT (FT 2 ), . . . . III. If 𝐹𝑇 𝑁 is an OR gate labelled "Fault event 𝑋 " with children nodes 𝐹𝑇 1 , 𝐹𝑇 2 , . . . , then FT2BT (FTN ) is a ParallelAll behaviour named "Avoid fault event 𝑋 ", with children behaviours FT2BT (FT 1 ), FT2BT (FT 2 ), . . . .

During the second step, firstly, Fault avoidance behaviours are elicited to "Operate"-type behaviours. That is because BT-v.2 represents an executable system model. Then, critical Fault avoidance behaviours are elicited to a parent Sequence "Operate without critical faults" behaviour, with children an Inverted Fault detection i.e. "Detect critical faults" behaviour, and an "Operate with degraded faults" behaviour.

Example

In this subsection we illustrate our methodological approach proposal with the help of a simplified Ground Station (GS) use case. For the needs of the paper, we only demonstrate a small part of the dysfunctional analysis that took place in order to produce the FT shown in Figure 3. The Radio-frequency (RF) subsystem of the GS system was chosen for the methodology application demonstration.

The case study contemplates the FE of loss of satellite TM data due to a malfunction of the RF subsystem. Here we consider the RF subsystem as isolated from the rest of the GS system. The faults consisting the FT of Figure 3 represent only critical single faults. That is because the information source for the analysis was solely the Return of Experience (RoE) from GS operators. Hence only OR gates are included in the FT: the represented fault events are single (single event occurrence leads to the higher level fault expression), and not combinatory (a combination of faults leads to the higher level fault). The latter would need an AND gate for their expression. Only critical faults were of interest for the specific study.

In Figure 3 we can see that the loss of data due to the RF subsystem malfunction could be caused by a critical (i) RF chain, (ii) Eb/N0 gain, or (iii) Antenna failure. Human error is out of context for this study. Failure (i) could be caused by a critical (i.a) cabling, (i.b) Antenna reception, or (i.c) frequency converter failure. Critical failure of the RF subsystem cables could be caused by a mechanical failure due to overloaded stress on the cables, or by physical degradation of the cables due to unforeseen environmental conditions and animals.

Failure (iii) could be caused by a critical failure of the Antenna (iii.a) positioner (rotator of the Antenna parabola), (iii.b) cables, (iii.c) cylinder (Antenna base body), or due to (iii.d) natural degradation of the Antenna (environmental phenomena and wildlife).

The first step in our methodology is to transform the FT into a BT, based on 4.9 -I, II & II. The result is shown in Figure 4.

Based on rule no.I, the FE "Loss of data cause RF at entry" becomes an Avoid type of behaviour. This results to the Root Paralle-lAll behaviour "Avoid data loss due to critical RF failure". Similarly, the rest FT nodes -still based on rule no.I, are translated into respective "Avoid" behaviours. Since all the gates present in the FT of Figure 3 are OR gates, following rule no.III, the respective parent BT nodes are represented by ParallelAll behaviours.

According to the second step of the method, BT-v.1 is elicited to BT-v.2, as illustrated in Figure 5. Thus all "Avoid", behaviours become "Operate" behaviours. The Root behaviour is represented by the Fallback node "Operate RF Subsystem (SS)". Its children consist of the ParallelAll behaviour "Operate RF SS without critical faults" and the leaf behaviours "Operate RF SS in degraded mode" and "Terminate RF SS's Functions". If the subsystem fails to operate nominally, it tries to enter a degraded mode. There the subsystem is still in operation but with degraded functions. If operating the subsystem in degraded mode fails too, the subsystem executes a fail-safe action and terminates all subsystem's functions.

As instructed by the second step of the method, each ParallelAll "Avoid critical faults" behaviour becomes an "Operate without critical faults" Sequence behaviour with an Inverted "Detect critical faults" and an "Operate system in degraded mode" behaviours as children. That is because, if the system fails to detect critical faults, a "Success" status will be sent to the parent node -because of the Inverter. This will make the Sequence parent node tick the second child, where the system will attempt to operate under non-nominal conditions. We can call this a fail-safe design.

DISCUSSION

The first BT version was automatically created from the provided FT. BT-v.1 did not include any supplementary system information, as for example on how to avoid certain faults. In the second BT version we can see that certain elements, which were included neither in the FT nor BT-v.1, are useful for system operation and specifically, fault mitigation.

BT-v.2 shows that by being able to detect a specific behaviour, we can manage to operate the system even under non-nominal conditions. For example, by adding additional sensors, redundant components or further surveillance on the Antenna body, the risk for its associated fault occurrence can be greatly reduced. The latter contributes to increasing the GS's Availability and Maintainability features.

Surely, the method implementation on a real-life complex system is necessary, to order to evaluate its scalability and facility of application. In addition to that, it is imperative that operators provide feedback on the methodology and the intuitiveness of ODM exploitation.

CONCLUSION

In this paper the authors propose a novel methodological approach on how to construct Operations-Dedicated Models from Fault Trees, using the Behaviour Tree formalism. The method is illustrated with a Ground Station use case example. The limitations of the proposal are discussed, as well as future work opportunities. Finally, the authors contemplate the methodology validation by planned interactions with system operators and modellers, and extended dissemination to DevOps experts, through conference presentations.

Figure 1 :

 1 Figure1: Overview of the proposed methodology for the construction and usage of an operations-dedicated model, used as the base to construct a digital twin monitoring model of the system, with the integration of operational data feedback © N. Christofi.

Figure 2 :

 2 Figure 2: The BT for system operation with fault detection and mitigation; children are ordered from left to right © N. Christofi.

Definition 4 . 5 (

 45 ParallelAll behaviour). When a ParallelAll behaviour starts, it starts all its children in parallel. It succeeds if and only if all its children have succeeded. If one child fails, Par-allelAll behaviour fails and interrupts the rest of the children. In current literature ParallelAll behaviours are simply called Parallel.

Figure 3 :

 3 Figure 3: Extracted Fault Tree for a Ground Station (GS) System regarding data loss of satellite telemetry (TM) data. Focus on the RF Subsystem. Feared Event: Loss of TM data due to wrong RF at the GS TM receptor.

Figure 4 :

 4 Figure 4: First version of the BT, derived automatically from the FT depicted in Figure 3.

Figure 5 :

 5 Figure 5: Second version of the BT, derived from eliciting the first BT version (Figure 4); follows format of Figure 2.

ACKNOWLEDGMENTS

The authors would like to thank all individuals, companies and research institutes involved in the S2C project led by the IRT Saint Exupéry and in particular Airbus Defence & Space for proposing and funding the research topic. The work presented in this paper results from the PhD thesis undertaken by N. Christofi and is equally supported by the French National Research Agency (ANR). Special thanks to Claude Baron, Marc Pantel, Sebastien Guilmeau and Christophe Ducamp for co-supervising the thesis work, as well as to Jerome Golenzer and Paul Albessard for their contribution on Ground Segment Operations. Most importantly, we thank David Canu, for providing us the Ground Station Use Case.


Timothée Duron

Laurent Gallon

Philippe Aniorte

Detection and classification of dropout behavior

Keywords: code.org, block programming, dropout, perseverance, MHI, HCI, Flow theory

come

Introduction

Our work aims to characterize school perseverance when students work on a computer, and more precisely, to detect when they drop out. The main idea is to detect these dropouts as soon as possible (weak signals) in order to be able to act and re-engage the student as quickly as possible. Therefore, we are not looking for school perseverance in the academic sense, which is over a long period of time (semester, year, ...), but rather we are looking to qualify perseverance behavior (or dropout) over a very short period of time (one or several minutes). Several works [START_REF] Deci | Intrinsic motivation and self-determination in human behavior[END_REF][2][3] [START_REF] Barbeau | Pour mieux comprendre la réussite et les échecs scolaires[END_REF] show that emotional and psychological state of the learner have a strong impact on its behavior. So the change of emotional and psychological state can be observed, and measured through the analysis of the use, for example, of the mouse and the keyboard of the computer [START_REF] Kołakowska | A review of emotion recognition methods based on keystroke dynamics and mouse movements[END_REF][6] [START_REF] Lim | Detecting cognitive stress from keyboard and mouse dynamics during mental arithmetic[END_REF] [START_REF] Khan | Measuring personality from keyboard and mouse use[END_REF], and more recently [START_REF] Aranha | Engagement and discrete emotions in game scenario: Is there a relation among them?[END_REF][10] [START_REF] Happy | Automated alertness and emotion detection for empathic feedback during e-learning[END_REF].

We make the assumption that the student's behaviors during a computer-assisted educational activity can be can be classified into several categories : working, risk of a dropout, and dropping out. This asumption is based on numerous works in the psychology of motivation, educational sciences, . . . as shown in the figure 2 [START_REF] Duron | Modelling learner's perseverance in education software[END_REF]. Most of them allow us to understand the mechanisms linked to motivation, before, after and during a pedagogical situation. But the most important one's for us is the FLOW theory [START_REF] Csikszentmihalyi | Flow and education, Applications of Flow in Human Development and Education : The Collected Works of Mihaly Csikszentmihalyi[END_REF], which links the emotional/psychological state of the learner to the challenge/skills balance of the activity. As the emotional state (and so the behavior of the learner) is induced by this balance, and reflects it, we seek to detect and classify these different behaviors during an activity. to charcaterize the level of dropout of the learner.

In the rest of this paper, we present the methodology we used to build the tools (detection rules) for detecting the dropout level of the learner, and the validation process of these tools. Then we give the results of the first experiments we made, and identify trends regarding the effectiveness of our approach.

Methodology

The objective of the proposed methodology is to build the rules allowing to classify the learner's dropout behaviors, then to measure the efficiency of these rules in order to modify them if necessary. This methodology is inspired from the De Vicente one [START_REF] Vicente | Towards Tutoring Systems That Detect Students' Motivation: An Investigation[END_REF].

The methodology is decomposed into four major steps, as seen in figure 1 : capture the data, construct the rules, pre-validate rules and finaly validate rules. The fisrt step is crucial, and concerns data capture. At this stage, we identify the sensors of the hardware and software platform used, thanks to which we will obtain the meaningfull informations on the activity of the learner. These sensors can be varied. In our case, we are using a keylogger, which allows us to capture the learner's mouse and keyboard activity. We also use a screen recording, to see the evolution of the learner in the software interface. We differentiate the captured datas into two groups: functional datas, i.e. the data which will be used to build the detection rules (datas from keylogger and screenshot recording), and control datas, which will be used to validate these rules (video recording of the student + screen recording). Basing on the functional datas, different informations can be build (we call them metrics). They are classified into three categories : intensity metrics (quantitative metrics), efficiency metrics (which assess the quality and the efficiency of the actions made by the learner), and semantic metrics (capture the meaning of the actions). Table 1 gives a list of metrics that we can build in our context. In step 2, we create a first version of the detection rules; basing on the metrics build in step 1. This construction is done in a completely empirical manner. We ask then some experts, who can be psychologists, experienced teachers, cognitive researchers, etc., to analyze, identify and describe significant behaviors with the recorded control data. A significant behavior could be, for example, a student who is seen to huff and get impatient, and at the same time make a large number of button clicks, and continue to huff because the program does not respond quickly enough. Once these behaviors are identified, we try to characterize them using logical combinations of metrics from the captured functional data (detection rules). For example, in the case of the impatient student, we can extract from the "mouse" data the metric "number of clicks in a reduced time interval", and consider that we will detect an impatient behavior when this metric exceeds a certain threshold. After the construction of the first version of the detection rules, we can pass to a pre-validation phase (step 3) which aims to check if the detection rules define in step 2 detect at the right time the behaviors identified by the experts. To do this, we apply the detection rules on the functional datas captured, and compare the the results (list of dates corresponding to points of interest) with the points of interest identified by the experts in step 2. If some detection rules are not satisfying (i.e. their result does not match that of the experts), they are modified until the pre-validation test is positive (loop with step 2 on figure 1). In our case, the 11 defined rules correctly identified the points of interest initially put forward by the experts. Then, we give this list of points of interest to a new group of experts, without specifying the type of detection carried out by the rules. We ask them to characterize the type and level of dropout on these points of interest, but also to let us know if in the control data, they identify dropout situations not listed in the list we provided them. The main idea of this part is to quantify the performance of the detection rules.

The results of step 3 of our firsts experiments are detailed in the following of the article. It should be noted that we were largely disturbed by the Covid period, and that consequently a limited number of experiments could be carried out, as well as a mobilization of a limited number of experts. This explains why we are currently only in phase 3 of our methodology. However, the results obtained seem sufficiently interesting to us to be presented to the scientific community for opinion.

Third step : pre-validation

The result are only in the prevalidate step, due to a lack of new data set. For that we applied our 11 rules our are commons by them constructions with the 6 students. We take all the moment, our rules detect something and give the list of this moment to expert without which rules is activated, and which states the prototype detect.

The expert have to give only one state to each moment in the list (around 15 moments by seance of 45 min by student). We allow them to give a second states, in case of doubt, but to give the states they thinks the more probable first.

In this paper, talk about raw result, when we only take into account only the first answer they give (we take into account like they have no expert doubt to any points).

Pre-validation result

In this paper, we talk about raw result, when we only take into account only the first answer they give (we take into account like they have no expert doubt to any points).

These results presenting only come from the first iteration of the process1, at the pre-validation step (step 3). We applied the 11 rules on 4 pupils included in the 6 pupil used to created the rules. For the 4 pupils, the prototype had detect respectively (16, 25, 12, and 18 points), so 71 points of detection in total.

Only two more point had been suggested by the expert, that mean, that prototype seems to detect properly the important moments.

We begin to evaluate to each point the difference of the 3 opinions in the same time (prototype, expert1 and expert2). We can see, the result in the figure 3. The green part with 37% is when the two expert give the same state that prototype detect. 31% in blue, the prototype concording with only one expert, and in conclict with the second one. In grey, is the case where nobody is agreed, they is any matching between prototype and one of the expert, and also between experts. These case need to be study further to understand them. And the red represent the case that opinion of expert concording together, but not with the expert, so this case represent the false detection from prototype.

The cases in green, are validated cases regarding to our purpose. In blue, these cases could be validated because one the two expert has agreed with us. It means that 68% in total of the cases are validated. The non validated cases (in red) need to be improved through the adaptation of the required rules. The other cases (in grey) cannot be validated, or invalidated because nobody is agreed. In 60% of grey case we are between the two experts opinions with "risk of dropout", the other 40% of grey case, prototype said working, instead of expert saying "risk of dropout" and "dropout". This represent respectively 9% and 6% to the total of cases. So 6% seems to be invalidate, because the two experts are more of a begining or a complete dropout, while the prototype detect a working state. The other 9% seems more on our side, and could be validated, because we are the mean of the two experts opinions. Which would bring the total number of validated cases to 77%.

To go further in the evaluation of the prototype, we also look for confrontation between each expert to the prototype, and between experts themselve (table 3).

The raw results for detecting a dropout (or the risk of dropout) are good, with 52-54% of cases where each expert is agreed with the prototype results (see table 3). In 43-44% of case each expert have a sligthy difference of opinion (for example prototype said risk of dropout and one expert said work). This kind of case, 1/3 of this case are hesitation between "drop out" and "risk of dropout", the 2/3 are hesitation between "risk of dropout" and "work". It is normal to have this kind of case, because the border between this different states can be defined clearly, the border is more like a blurred zone. However for the moment, they are too high to be only the blurred zone, specialy between "work" and "risk of dropout", and the next iteration will permit to improve the rules and decrease these kind of case.

And in 2-6% there is a very large disagreement between an expert and the detection of the prototype, that mean one said "dropout", while the other says "work".

But more interestingly, we can see that the results of the confrontation of expert opinions are surprising. In spite of an equivalent or slightly better percentage on the number of cases where they agree, the number of cases of contradictory opinion is at least twice as high, reaching up to 13%.

Fourth step : validation

Once the pre-validation test is satisfaying, we can then move on to a more general validation (step 4), with new experiments and new sets of data captured, in order to see if the detection rules applies to others sessions of the same student or group of students.

Conclusions and perspectives

In this paper, we relate the first experimentation, of the first iteration of our methodology. The result are really encouraging, to continue and improve the prototype. We are also working of improving the expert review, by working on our protocole and description of the differents states. Because, we can see it clearly, in table 3, that the prototype are more closer to each expert, than the two expert themselve. It could also permit to reduce the "blurred line" between state.

We also working now of increasing the number of expert, to have particularely for the cases in blue in figure 3, a majority of expert agreeds with prototype (and not a 50/50), but the disparity between expert could bring a lot of noise, with to much experts.

We will also continue the methodology to improve the rule with the iterations planned is the process (figure 1).

We also plan to go further and detect more than just severity of the dropout, by including the two major reason of dropout according to flow theory [START_REF] Csikszentmihalyi | Flow and education, Applications of Flow in Human Development and Education : The Collected Works of Mihaly Csikszentmihalyi[END_REF]: difficulty and boredorm. Some of the rules already take into account the reason. The prototype would then go from 3 possibles states to 5 states (difficulty dropout, risk of difficulty dropout, work, risk of boredom dropout, boredom dropout).

Figure 1 :

 1 Figure 1: Methodology steps

Figure 2 :

 2 Figure 2: Federative view centered on the pedagogical situation

Figure 3 :

 3 Figure 3: Confrontration 3 together of Raw result to 3-states summary (working, risk of dropout, dropout)

Table 1 :

 1 Metrics from mouse, keyboard and screen sensors 2.2 Second step : rules construction

	Category Sensor Metrics
	Intensity Mouse #pauses per minutee
	pointer speed variation
	#clics per minute
	Dist. run through by the pointer per minute
	#drag-drop per minute
	Keyboard #keystrokes per minute
	Screen #blocks moved per minute
	Efficiency Mouse Mean pointer speed
	Drag-drop duration
	Pause duration
	Ratio activity/inactivity
	Sinuosity of the movements of the pointer
	Ratio drag/empty
	Keyboard Mean time while pressing a key
	Semantic Mouse Pointer position in areas of interest
	Time spent by area of interest
	Clics in the void
	Clics on "start" button
	Screen #blocs created
	#blocs deleted
	#blocs currently isolated

  In our case, we build 11 different detection rules using datas issued from 4 experiments (4 students of the same classroom following individually code.org 2 courses). We give a short description of the rules in the table 2. High number of clicks without load. This rule represents impatient, stressful behaviors, where pup R2 Risk of dropout Long load time and strong sinuosity. This rule represents hesitation behaviors, where during the cr R3 Risk of dropout or Dropout Reset between two pauses. Here, the student between two long pauses, resets and reruns the simula R4 Risk of dropout Deletion of the program. When a student deletes his complete program to start again from scratch, R5 Work Low acceleration over a long time. This rule describes a behavior that we observed, where the stud R6 Work Rapid change in the number of connected blocks. This rule describes a reorganization of the progr R7 Dropout Several times the R4 rule, i.e. several deletions of its complete program, on the same exercise. This R8 Risk of dropout or Dropout A few movements of the pointer without clicking between two long pauses, reflects either the com R9 Work Rapid back and forth between the loading (reserve of block) area and the working area (canvas). H R10 Dropout Several tests in a row without modifying the program. Behavior representing a perception of diffic R11 Dropout Long time without activity. This rule reflects a dropout, whether due to disinterest or great difficult

	M[1]¿m1
	Rules State(s)	Description
	R1 Risk of dropout

Table 2 :

 2 Rules descriptions

Table 3 :

 3 Confrontation two by two, 3 states versionAt this stage, if some issues are identified, we can move back to step 2 to modified some of the rules if necessary. A rule is considered valid if at least it allows to have a good detection rate on other data sets then the one used in step 2.

http://perseverons.inspe-bordeaux.fr/

https://code.org/


L Gallon

T Duron

M Rigal

E Péré

V Mengelatte

A telepresence robot for a better orientation at university

Keywords:

This article presents the first results of the use of telepresence robots to allow high school students absent from our University, to discover our courses in telepresence, and assist them in their academic pathway. After presenting the project, we detail the process built to use the robot. Then we give the results of a survey conducted among the first pilots regarding the immersive activity itself, and the impact of the use of the telepresence robot

Introduction

In recent years, telepresence robots have appeared in the French educational environment. A major project of the French Ministry of National Education, Youth and Sports, called TED-i, is currently underway to deploy 4000 of these robots in French schools [START_REF] Ministry | Official launch of the TED-I program for sick children[END_REF]. They are used to enable students, unable to attend classes for health reasons for a long period of time, to maintain social ties with their classmates and the teaching staff, and to participate in real time to the educational activities of their class. The robot is positioned in the classroom with the rest of the group and the student who is unable to attend can connect to the device during lesson times. The absent student is thus totally immersed in the educational session, at the same time as his/her classmates. The mobility of the robot allows the student to multiply the activities to be carried out: choose the positioning of the robot in the classroom, participate to group work, visualize manipulations in practical works, discuss with his/her peers, . . . The student can also follow classmates during interactions, lunch breaks, . . . and thus recover the generational social tie essential, especially for adolescents.

The student, homebound for medical reasons, is not the only application context for telepresence in education. The French PIA 3 ACCES [START_REF] Pau | French PIA 3 acces project[END_REF] project, which brings together the Universities of Bordeaux (Pau and Pays de l'Adour, Bordeaux, Bordeaux Montaigne), aims to improve the orientation of high school students (especially during their final year) in education. One of the actions implemented to achieve this objective is the use of telepresence robots. Students use it to be present in a university course, without leaving their high school. They can then discover these courses and the University environment without being physically present at the university. This article is a feedback of the first telepresence immersive sessions carried out at the University of Pau and Pays de l'Adour.

Section 2 gives a short state of the art of the use of telepresence robots in education. Section 3 succinctly presents the ACCES project and its objectives. Section 4 details the organizational set up to use the robot in the immersive sessions. Section 5 is devoted to the analysis of a post-activity questionnaire conducted among high school users. Finally, section 6 concludes and gives perspectives to this work.

Related works

The use of telepresence robots in the classroom dates back to more than 10 years. Tanaka and al. [START_REF] Tanaka | Child-operated telepresence robot: A field trial connecting classrooms between australia and japan[END_REF] experiment how to link children across the world through telerobotics. They demonstrate that, even if the students do not speak the same language, interactions are more important when using a telepresence robot than using a visioconference system. Bell and al. [START_REF] Bell | Frm 2d to kubi to doubles : designs for student telepresence in synchronous hybrid classrooms[END_REF] experiment several kind of telepresence solutions in class: visioconference (called 2D telepresence), "table" telepresence robots (called 2,5D telepresence) and mobile telepresence robots (called 3D telepresence). They conclude that 3D telepresence gives a higher feeling of immersion to distant students. Coureau-Falquerho and al. [START_REF] Coureau-Falquerho | Experimentation "robot lycéen" in the french "auvergne rhône-alpes" area : usage report on "robot lycéen[END_REF] make a very comprehensive study of the use of 60 telepresence robots in France for students absent from their school for medical reasons. They conclude that the main benefits are: not dropping out, maintain social ties with peers, more solidarity between students, and play a part in an innovative project. On the other hand, the main negative points are essentially technological issues: hearing and vision problems, difficulty to move within the classroom, bad connections . . . They also point out the that a human assistance is necessary to troubleshoot when technical issues occur Newhart and al. [START_REF] Ahumada-Newhart | My student is a robot: How schools manage telepresence experiences for students[END_REF] study the reasons why teachers and administrators adopt or reject the robot, and propose some elements to improve the robot acceptance. In [START_REF]Going to school on a robot: Robot and user interface design features that matter[END_REF], they explore potential design improvements of the robots to better fit childrens' needs. Gleason and al. [8] study the potential of teaching and learning with robot-mediated communication. They conclude that it "offers advantages over traditionally used video-conferencing, including affordances for fostering students' embodiment in the classroom, their feelings of belonging and trust, and their ability to contribute ideas in authentic ways". In [START_REF] Gallon | Using a telepresence robot in an educational context[END_REF] , the authors explore the motivation of students in using the robot in time (persistence). They also analyse the impact of using additional educational connected environments to increase the feeling of presence, and then the engagement in pedagogical activities. All these works confirm that the use of the robot gives a strong feeling of presence to the pilot. But that it is also necessary to support its use to solve technical problems, and reassure the pilot and remote people. Under these conditions, the use of the robot can be optimal. This is what we experienced in the context of remote immersion of high school students in higher education, without being physically present at the university. We evaluate both the interest of the immersive sessions, and the impact of the robot on the quality of this immersion. These experimentations are supported by the French PIA 3 ACCES project.

Presentation of the ACCES project

In France, the last year of high school ends with a national exam, called baccalaureate. Students must pass it to continue their studies in higher education (universities, engineering schools, . . . ). While on the territory of the French South-West area (Bordeaux Academy), the baccalaureate success rates are higher than the national average, the rate of perpetration of new baccalaureate holders to higher education is lower, regardless of the type of baccalaureate (scientific, literary, technological, . . . ). Social and geographical origins of high school students weigh on their choice of orientation and can also constitute obstacles to the pursuit of studies. The objective of the ACCES project is to reduce these inequalities to allow everyone's ambition and the construction of a chosen and thoughtful orientation.

During the project, several tools were tested and assessed to improve the orientation of high school students towards higher education. One of these tools is the use of telepresence robots. These robots allow geographically distant high school students from University to participate in telepresence immersive sessions in some courses, in order to better understand what University is. We chose to only offer these sessions during school time. The students stand from the high school to which they belong (and not from their homes), and are supervised during the activity by a referent teacher and a University referent. This latter serves as technical support, collects the results of the post-activity questionnaire (see section 5.1) and does a quick debrief with the students at the end of the immersions.

Setting up experimentations

For the preliminary phase (testing phase) of the project, which is the subject of this article, we selected 3 high schools in the Bordeaux Academy, and identified 9 final year students potentially interested in this approach. For efficiency and time reasons, we chose to allow a group of students (4 at most) to participate to each immersion session rather than only one student per session. This permitted to organize only three immersive sessions per high school: one lecture session, one practical exercise session and Fig. 1: Activities assessment results one practical work session. Unfortunately, sometimes, one or more students were absent because of the COVID-19 pandemic, so the number of participants to each session was variable. Table 1 gives details of these sessions.

It is highly recommended to have a preliminary encounter with the robot before the first immersive session, in order to solve handling problems, but also to mitigate potential fears. There was always a preliminary session for at least a week before the first immersive session. The robot was located in a neutral place, for example in desk spaces. The university referent would be present in the high school to help students with connections, to present them the cockpit, give a demonstration, and answer their questions. They use a pre-configured computer (the robot cockpit is a dedicated application) connected to the wired network of the high school. On a voluntary basis, students could drive the robot to familiarize themselves with it and its cockpit. We did not force them to drive it, to avoid any rejection phenomenon. The sessions lasted a maximum of 40 minutes.

During the immersive sessions, we did not give any guidelines to the teachers for the reception and integration of telepresence students. Surprisingly, we observed that the level of interaction in each course typology was different, which was particularly interesting for us, giving us the opportunity to analyze the impact of this dimension on the quality of the immersion. More precisely:

-During lecture sessions, there was no interaction between the high school students and the students or the teacher of the University (no hello, no explanation, no goodbye); -During practical exercise sessions, the amount of interaction was low: the teacher welcomed the high school students at the beginning of the session, quickly explained to them what a practical exercise session was, and the high school students remained passive during the rest of the session; -During practical work sessions, the amount of interaction was high: the teacher welcomed the high school students at the beginning of the session, quickly explained to them what a practical work session was, and encouraged them to interact with the students, move among the different pairs to watch and discuss about the different manipulations student were doing. High school students also discussed with students about courses, student life and their future orientation.

At the end of each session, each student completed a questionnaire. The university referent was present to answer any questions from students, but also to ensure that the questionnaire was completed correctly to then collect the answers. Thus, out of the students who were present in the immersive sessions, we collected 23 answers.

After having been immersed in the three different typologies of courses (lecture, practical exercise and practical work), 8 out of 9 students were individually interrogated to have a better understanding of some points. More precisely, the questionnaire was more deeply explored for which we obtained a high variety of answers. We also explored the question of the positioning of the robot in the classroom during the immersion. Finally, some other points were detailed, depending on the students' prerogatives.

Analysis of the robot usage 5.1 Post-activity assessment questionnaire

The analysis of the robot usage is based on the results of a post-activity questionnaire. This questionnaire is divided into two categories : assessment of the immersive activities, and assessment of the impact of the use of the telepresence robot. At least two questions composed each item Q*. The list of these items is given below:

1. Activity assessment Q1 Sufficient activity duration Q2 Need to interact with distant people Q3 Sufficient amount of interactions Q4 Understanding of the course typology Q5 Activity representative of the University ? Q6 Impact on the future orientation of the student Q7 Overall satisfaction of the activity 2. Telepresence assessment Q8 Representation of remote space Q9 Orientation in remote space Q10 Pilot's sense of presence Q11 Pilot thinks he is considered like a human by others Q12 Mobility usability Q13 Ease to communicate via the robot Q14 Sound quality Q15 Image quality

Immersive activities assessment

Figure 1 shows the answers given to the seven questions concerning the immersive activities (Q1 to Q7). Each column combines the answers to the same question, without taking into account the course typology (lecture, practical work and practical exercise). For Q5, Q6 and Q7, the opinions are clearly positive (resp. 56%, 63% and 69% positive answers, less than 10% negative answers). Thus, we can say that the students judged the immersive activities convincing and enabled them to make a better choice in their orientation. In general, they were definitely satisfied.

Results of Q1 to Q4 are different depending on the typology of the course. Figure 2 gives the answers to these questions per course typology.

Concerning Q1 (activity duration), notice that during the experimentation, the duration of immersive session was the same independently of the typology (approximately 40 minutes). The results show that the students consider the duration of the practical exercise sessions adequate (14% of negative opinions for Q1 PE). They are less convinced by the length of the practical work sessions (36% of negative opinions for Q1 PW), and clearly consider those of lecture sessions not adapted to all (62% of negative opinions for Q1 L, they got bored). However, during the interview, half of the students said that if the sound was clearer (without any echo) and the video-projection vision better, they may have considered time shorter. So, the lack of quality in terms of listening and watching induced a loss of interest. Finally, the duration of practical work sessions, according to the interview, is a little short. The majority of high school students were willing to extend its duration. The fact that they had to explore the practical work room (move the robot), talk and interact with the students and the teacher, strongly engaged them in the activity and make them eager to prolong their participation.

Q2 focuses on the need of interaction with the distant space and people. Globally, students considered that interactions were needed, but the answer is quite different depending on the typology of the course. In lecture courses, a minority of students consider interactions useless (26%) and 13% do not have an opinion. In practical exercise Fig. 3: Telepresence assessment results courses, 72% of the students' interactions are useful, and 29% stay neutral. There is no negative opinion. Finally, in practical work courses, for 100% of the students' interactions are useful.

The results of Q3 are logical: the students estimate that there is no sufficient interaction during lectures (no exchange with any distant people : only 23% of positive answers), idem for practical exercises (the teacher welcomed the students, but no interaction after this preliminary phase : 28% of positive answers), on the other hand, they are sufficient during practical work (frequent exchanges with distant people : 58% of positive answers, 14% of negative answers).

Finally, Q4 indicates that practical work and practical exercise sessions are well understood by students, while lecture sessions are not convincing (34% positive answers, 39% negative answers).

As a conclusion, it can be said that students appreciate these immersive sessions. The three kind of course typologies had their interest. Even if some technical issues degraded the quality on the interactions, they assess this experimentation as being positive. Lecture sessions are the less convincing, mainly because of lack of interaction. This point needs to be improved in the future, maybe by asking the teacher to welcome the distant students, and proposing a feedback time at the end of the sessions, whenever possible.

Assessment of the telepresence robot usage

Figure 3 shows the answers to the eight questions concerning the use of the telepresence robot. Figure 4 gives details of questions Q10, Q11, Q14 and Q15.

We can see that Q8 and Q9 (representation and orientation in remote space) have relatively good results. Clearly, sensors and actuators of the robot seem to be sufficient for a good appropriation of the remote space. This is confirmed by question Q12, which focuses on mobility usability, and for which only 15% of the answers are negative. Note that, without any surprise, students found it more difficult to drive the robot in practical exercise sessions, than in the other typology sessions. The reason is that in practical exercise courses, the room is generally narrow (space between tables, school bags, chairs, . . . ). In practical work courses, the room is more spacious. And in lecture courses, it is not necessary to move. By consequence, the feeling of difficulty in driving the robot is more important in a practical exercise room, especially if the conductor uses the robot for the first time.

Q13 (easy to communicate via the robot) is slightly more mixed than Q12. Communication quality between people is dependent on the image quality, the sound quality and the network quality of service. So the results of Q13 are strongly linked to the results of Q14 and Q15 (sound and image qualities).

Q15 answers are really different depending on the typology of the course. For lecture and practical exercise courses, student in general considered the video quality to be poor. This was due to a too large distance between the robot and the whiteboard, or reflection on the whiteboard (sun, video-projector lamp, lighting, . . . ). Conversely, in their opinion the image quality acceptable in practical work sessions is better (64% of positive answers). In fact, high school students observe and imitate the university student behavior: in lecture and practical exercise sessions, university students are seated without moving. Consequently, high school students dare not "move" (the robot) to be closer to the blackboard, and thus better see what is written. This is particularly true in practical exercise sessions, in which students cannot understand the exercise corrections if the robot is not well located compared to the whiteboard. Note that it is not the case in practical work courses, in which students have the ability to move and interact with other students. So the robot can move and relocate to the right place without disturbing the course.

Q14 deals with the sound quality. Results are not excellent, especially in practical works and lectures (with respectively 50% and 44% of completely disagree answers). The post-interview allows us to have a better understanding of these results. The fact that the network connection was not good enough during two practical works prevented high school students from fully interacting with the distant students and the teacher. They considered this frustrating. During lecture courses, the teacher voice was amplified in the amphitheater, and this caused a kind of echo that disturbs and makes difficult to listen through the robot. Once again, technological issues had a bad impact on the quality of the relationship between humans.

Concerning questions Q10 and Q11, which deal with the feeling of presence in the distant space, several points must be highlighted. In Q11, we can see that the feeling of having been seen like a human by the teacher and university students, and not a robot, is low, whatever the typology course is. Q10 shows that the pilot's feeling of presence in the distant place is also low, between 22% and 50% of satisfaction. as for questions Q2 and Q3, numerous bad issues with the connection (lot of shutdown, video frozen or degraded, very chopped sound) during these immersions could have ruined these feelings. The lack of interaction initiated by the teacher could also be an explanation: there were not asked for anything, and it made them feel "invisible".

Conclusion

In this paper, we relate the first experimentations of the use of telepresence robots to improve high school students' orientation in higher education. After giving some elements on the planning of immersive activities, we detailed the results of a post-activity questionnaire filled by the robot pilots after each session.

Results show that high school students are globally satisfied with the immersive activities proposed. Concerning the use of the robot, some results are disappointing. First, several technical issues occurred and strongly degraded the quality of the immersion. Video and sound quality were strongly dependent on the network quality of service. Moreover the robots are not really conceived especially for educational purposes, and some issues are not considered : reflection of the sun on the whiteboard, video-projection, unreadable handwriting.

Second, the integration of the robot into the course of the session was not always well done, and has induced a feeling of isolation (no interaction), which is not very positive for a discovery session possible future orientation.

In a close future, we will continue to experiment the use of telepresence robots in immersive activities, in order to increase the number of experiments, and consolidate these firsts results. We will also better prepare these sessions, in particular by talking with teachers to have more interactions with students in telepresence. Some additional components need to be added to the robot in order to improve the quality of stimulus coming from the distant space : Bluetooth microphone for the teacher, dedicated additional camera for the whiteboard, . . .

Fig. 2 :

 2 Fig. 2: Details of questions Q1 to Q4

Fig. 4 :

 4 Fig. 4: Details of questions Q10, Q11, Q14 and Q15

Table 1 :

 1 Details of telepresence sessions

	H. School Session Course typo. Taught subject #students
		1.1 pract. work Chemistry	3
	1	1.2 pract. exerc. Chemistry	2
		1.3	lecture	Law	4
		2.1 pract. work Chemistry	2
	2	2.2 pract. exerc. Chemistry	4
		2.3	lecture	Law	3
		3.1 pract. work Chemistry	2
	3	3.2 pract. exerc. Chemistry	1
		3.3	lecture	Law	2