Ori Cohen

Sébastien Druon

Sébastien Lengagne

Avi Mendelsohn

Rafael Malach

Abderrahmane Kheddar

Doron Friedman

fMRI-Based Robotic Embodiment: Controlling a Humanoid Robot by Thought Using Real-Time fMRI

We present a robotic embodiment experiment based on real-time functional magnetic resonance imaging (rt-fMRI). In this study, fMRI is used as an input device to identify a subject's intentions and convert them into actions performed by a humanoid robot. The process, based on motor imagery, has allowed four subjects located in Israel to control a HOAP3 humanoid robot in France, in a relatively natural manner, experiencing the whole experiment through the eyes of the robot. Motor imagery or movement of the left hand, the right hand, or the legs were used to control the robotic motions of left, right, or walk forward, respectively.

Introduction

This work aims at dissolving the boundary between the human body and surrogate representations in immersive virtual reality and physical reality. By dissolving the boundary, we mean that the subject is expected to have the illusion that his or her surrogate representation is his or her own body, and behave and think accordingly. This may help disabled humans to control an external device just by thinking, without any bodily movement being involved. As illustrated in Figure 1, our aim was to provide a subject the most intuitive thought-based control of a robotic body. The subject was located in Israel and the robot was located in France; this geographic split was made due to the availability of the facilities. In order to reach this goal, we decided to focus on motor control, using real-time functional magnetic resonance imaging (rt-fMRI) to detect the subjects' movement intentions and translate them into actions performed by a HOAP3 humanoid robot.

The majority of brain-computer interfaces (BCIs) with humans are based on electroencephalogram (EEG) technology. Although fMRI is expensive and less accessible, fMRI-based BCI is promising for several reasons. The superior spatial resolution, as compared with EEG, may allow exploring new modes of BCI, based on new types of mental patterns. If successful, attempts can be made to localize underlying brain patterns with the fMRI and detect the same patterns using more accessible devices such as EEG or functional near-infrared spectography (fNIRS). The latter is especially relevant, since it is based on the same hemodynamic responses as measured by fMRI. fMRI-based BCI can also *Correspondence to orioric@gmail.com. be used for training patients in BCI, for rehabilitation sessions, or for next generation neurofeedback-in all these cases very specific brain areas may be targeted. Finally, smaller and portable fMRI devices may become available. 1 1. http://www.news-medical.net/news/2008/07/08/39842.aspx

Previous Work

Telerobotics is the technology that allows a human operator to steer robots at a distance. Telerobotic control strategies have evolved from the classical masterslave control to advanced supervisory control [START_REF] Sheridan | Telerobotics: Automation and human supervisory control[END_REF]. Shared autonomy and the sophistication of the robotic control allows a telerobot to be steered by classical and modern input devices (such as keyboard, mouse, eye tracker, voice recognition system, etc.), or through a virtual reality functional intermediary [START_REF] Kheddar | Teleoperation based on the hidden robot concept[END_REF]. Recently, the possibility of using BCIs to control robots is gaining popularity. BCIs allow a human to control a computer or a mechatronic device just by thinking, without any body movement being involved. While contemporary BCI systems are far from the interfaces imagined by Hollywood in movies such as Avatar 2 or Surrogates, 3 there has been some progress made and a surge of interest in recent years [START_REF] Mak | Clinical applications of brain-computer interfaces: Current state and future prospects[END_REF].

Most BCI research is aimed at helping paralyzed patients, such as patients with amyotrophic lateral sclerosis (ALS) and severe nervous system damage including spinal cord injuries and stroke, and the goal is to provide such patients with some level of communication, control of external devices, and mobility.

BCI was successfully demonstrated with invasive methods such as electrocorticography (ECoG, e.g., [START_REF] Leuthardt | A brain-computer interface using electrocorticographic signals in humans[END_REF] and intracortical neural interfaces (e.g., [START_REF] Donoghue | Assistive technology and robotic control using motor cortex ensemble-based neural interface systems in humans with tetraplegia[END_REF][START_REF] Kim | A hybrid brain computer interface to control the direction and speed of a simulated or real wheelchair[END_REF]. Recently, a tetraplegic patient was able to use such electrodes to drink coffee by partially controlling a robotic arm [START_REF] Hochberg | Reach and grasp by people with tetraplegia using a neurally controlled robotic arm[END_REF]. Most BCI systems intended for humans rely on the measurement of an EEG recorded from the scalp. BCI-controlled robots have primarily been demonstrated using three major EEG-based BCI paradigms: the Steady-State Visually-Evoked Potential (SSVEP), the P300 wave, and motor imagery.

In SSVEP, a flickering visual stimulus is displayed to the subject. When the retina is excited by a signal ranging from 3.5 to 75 Hz, the brain generates electrical activity at the same frequency as the visual stimulus, which can be detected in the EEG signal. SSVEPs are highly interesting for robot control due to their simplicity, their superior signal-to-noise ratio, and their high decision rate. Previous studies have explored its use in the control of mobile robots (e.g., [START_REF] Prueckl | A brain-computer interface based on steady state visual evoked potentials for controlling a robot[END_REF][START_REF] Ortner | SSVEP based brain-computer interface for robot control[END_REF] 2. http://www.imdb.com/title/tt0499549/ 3. http://www.imdb.com/title/tt0986263/ & Edlinger, 2010), and recently, humanoid robots as well [START_REF] Gergondet | Using braincomputer interface to steer a humanoid robot[END_REF][START_REF] Gergondet | Multitask humanoid control with a brain-computer interface: User experiment with HRP-2[END_REF].

The P300 wave is an event-related potential (ERP) that appears 300 ms after an infrequent task-related event. This ERP is now commonly used in BCI systems due to its reliability: the waveform is easily and consistently detectable, with little variation in measurement techniques. Even though the bit rate (i.e., the amount of commands that are sent to the external object in a second) is typically lower than SSVEP, it is still a reliable BCI pattern, included in several robotic control systems (e.g., [START_REF] Bell | Control of a humanoid robot by a noninvasive brain computer interface in humans[END_REF][START_REF] Rebsamen | A brain-controlled wheelchair based on P300 and path guidance[END_REF][START_REF] Iturrate | A noninvasive brain-actuated wheelchair based on a P300 neurophysiological protocol and automated navigation[END_REF][START_REF] Rebsamen | A brain controlled wheelchair to navigate in familiar environments[END_REF][START_REF] Lenhardt | An augmented-reality based brain-computer interface for robot control[END_REF].

Because they rely on visual evoked responses, both SSVEP and P300 can be compared to eye-tracking systems in terms of input interface: they provide the same set of functionalities to the user and suffer from the same limitations. Mostly, the mapping between the user intentions and the functionality is arbitrary, in contrast to what we would expect from a thought-based interaction paradigm.

Motor imagery has also been used for EEG-based BCI. Motor imagery is a mental process by which an individual rehearses or simulates a given action. As explained in [START_REF] Neuper | Event-related dynamics of cortical rhythms: Frequency-specific features and functional correlates[END_REF], imagination of movement evokes brain networks that are similar to the networks evoked by real execution of the corresponding physical movement. A series of studies was carried out with motor-imagery-based navigation of highly-immersive virtual reality [START_REF] Friedman | Human-computer interface issues in controlling virtual reality with brain-computer interface[END_REF][START_REF] Pfurtscheller | Walking from thought[END_REF][START_REF] Leeb | Walking by thinking: The brainwaves are crucial, not the muscles! Presence[END_REF] including experiments with a tetraplegic patient [START_REF] Leeb | Self-paced (asynchronous) BCI control of a wheelchair in virtual environments: A case study with a tetraplegic[END_REF]. [START_REF] Royer | EEG control of a virtual helicopter in 3-dimensional space using intelligent control strategies[END_REF] demonstrated navigating a virtual helicopter using four classes: right hand to move right, left hand to move left, both hands to move up, and none to move down. Motor imagery requires more training and the bit rate is lower than P300 and SSVEP, but it is arguably based on a more intuitive mapping between the mental patterns and the resulting action taken by the system.

Since an EEG is recorded at the scalp, it suffers from high levels of noise and low spatial resolution as compared with other methods for recording brain activity. fMRI also has several drawbacks: it is expensive, less accessible, and has low temporal resolution and a builtin delay because it is based on metabolic changes rather than on direct recording of electrical activity in the brain. However, due to its superior spatial resolution covering the whole brain simultaneously, it holds much promise for completely new types of control paradigms.

Real-time fMRI has been suggested for various applications [START_REF] Decharms | Applications of real-time fMRI[END_REF]. Typically, rt-fMRI is used as a form of neurofeedback; that is, the raw signal values from a specific brain region are visualized on the screen, either as a bar or as a time-course plot, in order to provide immediate feedback [START_REF] Weiskopf | Physiological self-regulation of regional brain activity using real-time functional magnetic resonance imaging (fMRI): Methodology and exemplary data[END_REF] or delayed feedback [START_REF] Weiskopf | Principles of a brain-computer interface (BCI) based on real-time functional magnetic resonance imaging (fMRI)[END_REF]. The subject uses a mental strategy to increase or decrease the activity in the target brain region. Such neurofeedback sessions are different from BCI in various ways. First, the goal is different: in neurofeedback, the goal is to train the subject to modulate his or her brain activity, whereas in BCI, the goal is to allow a subject to control an external device by thought. Most notably, in neurofeedback, most of the effort is done by the subject, and the system is used only for visualizing the brain signals, whereas BCI systems include algorithms for processing the brain signals and mapping them into specific actions taken by the external device. fMRI was used as an input device for robotic hand control as publicized by Honda Research Institute and Advanced Telecommunications Research (ATR); this nonpublished result was reported by [START_REF] Honryak | Thinking of child's play[END_REF].

In traditional fMRI experiments, we collect data from a subject's brain and have abundant time after the experiment is complete to analyze the brain data. Additionally, algorithms do not need to be optimized for speed and for memory usage. Conversely, when dealing with real-time analysis and classification, we need to use fast algorithms that can manipulate large data sets in a fraction of a second. In our case, the time between repetition times (TRs), which is the time between our inputs, is 2 s. In the current real-time experiments, only three average raw values are calculated for the classification, so one of the advantages of the simplicity of our method is its computational efficiency.

fMRI-Based BCI

Our system is able to automatically identify a subject's intention based on motor imagery in real time, classify brain activation patterns, and convert them into robotic actions performed by a humanoid robot. The aim is to allow intuitive BCI control based on brain activity. This section describes the system and method used in the study.

The System

Imaging was performed on a 3T Trio Magnetom Siemens scanner, and all images were acquired using a 12-channel head matrix coil. Three-dimensional T1-weighted anatomical scans were acquired with high-resolution 1-mm-slice thickness (3D MP-RAGE sequence, TR 2,300 ms, TE 2.98 ms, 1 mm 3 voxels). For blood-oxygenation-level-dependent (BOLD) scanning, T2*-weighted images using echo planar imaging sequencing (EPI) were acquired using the following parameters: TR 2,000 ms, TE 30 ms, flip angle 80 • , 35 oblique slices without gap, 20 toward coronal plane from anterior commissure-posterior commissure (ACPC), 3 × 3 × 4 mm voxel size, and covering the whole cerebrum.

The data coming from the fMRI scanner is saved as Dicom files,4 and processed by Turbo BrainVoyager software (TBV; Turbo Brain Voyager, Netherlands, n.d.), which is a real-time processing, analysis, and visualization application that accepts input from an fMRI scanner. After processing the data, TBV saves the average raw data values for each region of interest (ROI) selected by the operator at each measured time point.

The fMRI scanner is located in Rehovot, Israel, and the robot in Béziers, France. The flow of high-level commands (forward, left, right) was sent to the robot through a User Datagram Protocol (UDP) connection and the video flow was received through another network flow. The round-trip time from transmission to reception of data (ping) between Israel and France was between 100 to 150 ms. Similar to many teleoperation systems, the vision flow is critical. While a dropped frame may not be perceived by the fMRI user, the latency must be as low as possible. We used the visionsystem framework 5 to acquire, transcode, and transmit the video flows.

The ROI-Based Paradigm

Each experiment is divided into three parts. The first part is intended for localization of brain areas: the subject sees an avatar standing in the center of a threedoor room, as seen in Figure 2. The subject is given pseudorandom instructions and is expected to follow them. After each action, the subject is instructed to rest, and during that time, the avatar executes a predetermined command that corresponds to the instruction. The "right" and "left" commands result in the avatar turning toward the right or left door correspondingly, and the "forward" command results in the avatar moving toward the top door. The total amount of instructions is divided equally between all instruction types. The entire session is recorded for the purpose of finding ROIs. An ROI is a selected group of voxels 5. https://github.com/LIRMM-Beziers/visionsystem in the brain; in our study, we select a group of voxels that were more active in one experimental condition compared to the other condition, as detected by a General Linear Model (GLM). The experimenter manually marks the ROIs inside the bright areas of the relevant anatomical regions where the event-related average signal for the current ROI is significantly higher than the other two ROIs. Figure 3 depicts an image from TBV's view screen. The three regions (from left to right) represent the three areas correspondingly: left hand, legs, and right hand, in the primary motor cortex, and are delineated by a left versus right hand contrast as well as a legs versus baseline contrast, using a GLM analysis. Figure 4 depicts the event-related average time-course of the contrast. We assume that there are intersubject differences in the specific ROIs; however, these ROIs are always expected to be found in the primary motor area and are easy to locate with the GLM contrast (this may be inconvenient to reproduce in other studies, but we are already improving our system to use an automated method).

In the second part, we instruct the subject to rest for 1 min; this serves as a baseline resting period in which we collect the mean and standard deviation for each ROI for the entire baseline period.

In the third and last part, the task stage, we instruct the subject to imagine moving his or her limbs and collect the average values from each ROI every 2 s. A classification is made using the z-score formula and is calculated for each measured value by using the mean and standard deviation from the baseline period:

z = x -μ σ , (1)
where

• x is the average raw value in an ROI in the current TR; • μ is the mean raw value of the ROI in the baseline period; and • σ is the standard deviation value of the ROI in the baseline period.

The selected class at each time step is the class corresponding to the ROI with the maximal z score value for that duration. The system then transmits the classification to the HOAP3 robot located in France. Each ROI is mapped to a different action performed by the subject, which in turn activates a precomputed robotic motion. Turning left, right, or walking forward corresponds to left-hand, right-hand, or legs imagery, respectively.

Generation of the Motion Database for the Robot

In order to control the robot through such highlevel instructions, we created a motion database for a follower task with the HOAP3 robot. Contrary to human-sized robots, small humanoid robots such as HOAP3 are very stable. Hence, we are free to execute those motions with a local joint control loop, without using a balance stabilizer. Moreover, the robot receives a new command every 2 s and has to walk on a flat floor without obstacles. Thus, there is no need for a reactive pattern generator, and the use of a motion database is fairly straightforward in our case for producing tasks such as tracking as presented in [START_REF] Lengagne | Planning and fast replanning safe motions for humanoid robots[END_REF]. In this paper, we use the method presented in [START_REF] Lengagne | Generation of whole-body optimal dynamic multi-contact motions[END_REF] to generate motions performing a sequence of contact stances and to ensure the balance and the physical limits of the robot.

Video feedback to the user is obtained directly from the HOAP-3 embedded cameras.

Motion Optimization

As presented in [START_REF] Lengagne | Generation of whole-body optimal dynamic multi-contact motions[END_REF], the goal is to compute the joint trajectories q(t ) that minimize a cost function C , perform the desired task, and ensure the integrity of the robot. min

q(t ) C (q(t )) subject to c eq (q(t )) = 0 c ineq (q(t )) ≤ 0 , ( 2
)
where c eq is the set of continuous equality constraints that allows for the definition of the foot position during a contact phase, and c ineq is the set of continuous inequality constraints relative to the balance and the limits of the robot. In order to deal with the constraints, classical optimization techniques revert to time discretization, even if they may produce unsafe motions, where some constraint violations between the instants of the time-grid may occur, as shown [START_REF] Lengagne | Planning and fast replanning safe motions for humanoid robots[END_REF]. In order to avoid any constraint violation, this method considers a time-interval discretization that decomposes the motion into several intervals and uses a polynomial approximation over each time interval of any state variables of the robot, in order to easily take into account continuous inequality and equality constraints.

Motion Properties

We created a database of motions in order for the robot to walk forward, turn to the left, or turn to the right. Each motion is decomposed into several contact phases, that is, a lapse of time when no contacts are created or released. To ensure continuity, every motion starts and ends with the same posture. The turning motions are composed of five phases that perform a rotation of 30 • , whereas the walking motions are composed of nine phases that produce steps of 5 cm each.

During the optimization processes, we considered the following cost function that produces a smooth and low-energy motion:

C (q) = a T 0 i Γ 2 i dt + b T 0 i ... q i 2 dt + cT , ( 3
)
where a = 1e -2, b = 1e -5, and c = 4 are the values we set heuristically to have human-like walking motion (from [START_REF] Lengagne | Generation of whole-body optimal dynamic multi-contact motions[END_REF].

Experimental Validation

Experimental Setup

In a parallel work [START_REF] Cohen | Controlling an avatar by thought using real-time fMRI[END_REF], we consider the same ROI paradigm applied to the control of a virtual avatar-while in this work, we deal with the control of a physical robot.

In the study reported here, we also used the avatar as a feedback in the first experimental stage, which was intended for defining three nonintersecting ROIs per subject. The subjects saw a virtual environment with an avatar standing in the bottom center of the space, and were instructed to imagine themselves as the avatar. The avatar would turn 90 • toward either the left or the right, or would walk 2 s when facing forward. In BCI, we would like to achieve the most intuitive mapping between thought patterns and the resulting interaction [START_REF] Friedman | Human-computer interface issues in controlling virtual reality with brain-computer interface[END_REF]. Imagining hands for motion direction and feet for forward motion is not identical to the way you control your body when walking, but it is clearly not arbitrary or intuitive.

In the next step, the subjects viewed a live video feed through a camera located at the eyes of the robot. The robot was located inside a 9.6 × 5.3 m room in France. The participants saw a technician who instructed them to move left, right, or forward using hand gestures. This method also allows the researchers to assess that the robot motion truly reflects the thought-based instructions initiated by the subject. The objective given to the subjects in this experiment was to walk around two obstacles in a figure-eight-shaped course, for an approximate length of 1.5 m. Each subject underwent between three and seven test sessions, each lasting 12 min (360 TRs), in which the BOLD signal from the entire brain was measured every 2 s. At the end of this period, we calculated two values: the mean signal and the standard deviation for the entire rest period.

The system sent a nominal value to the robot every 2 s (corresponding to the ROI with the maximal z score). The left or right commands initiated a 30 • turning sequence, and the forward command initiated a twostep forward walking sequence, both lasting between 8 and 14 s. The robot executed a new command only after completing the previous command; that is, many of the commands classified by the system were ignored by the robot, and in practice the robot performed between 25 and 45 commands per session. In practice, while each command was based on a 2-s time window, the subjects focused on the same command (left, right, or forward) for the time it took the robot to perform the action, which was longer. One alternative is to average the BOLD signal over the time it takes the robot to complete an action. However, due to the hemodynamic delay, we expect these latter values to be the "best" ones; we chose to allow the BOLD signal to reach its peak and stay at a relatively constant plateau during the time window of the robot action.

Subjects

The study included four right-handed participants: one man (age 26), referred to as S1, who performed 10 successful sessions of 12 min, using either exclusively motor imagery or motor movements, and three women (ages 25, 28, and 33) who performed the task using motor movements.

We tested the system with both motor imagery and motor movement; in the latter case, subjects were instructed to move their fingers and toes in order to move, rather than the corresponding imagery tasks. Because the commands are only extracted from brain signals, and because eventually such interfaces are intended for paralyzed patients, allowing the subjects to move their fingers and toes is still of interest. When using imagery alone, we occasionally fit the subject with electromyography (EMG) sensors on his or her hands and legs, and verify there is no electrical activity sent to the muscles. This test was done with S1 on other occasions when controlling the avatar by thought, but due to time constraints, this test was not done in the current study. S1 had participated in many motor imagery sessions previous to this study, had complete control of all three imagery commands, and therefore was the only subject selected to perform the task using motor imagery.

In the case of motor movement, the resulting brain signal and contrast are relatively strong; our experience indicates that any subject can perform the task without any difficulty and with literally no training. However, using motor imagery, the subjects need to be trained for several two-hour sessions. The training is necessary because it takes time for the subject to find the right imagery strategy to activate the motor regions. For example, participants imagine tapping with either right or left hand to turn, and imagine moving their feet back and forth to walk forward.

Results

Free-choice scenarios allow for an experience of performing a task in a relatively natural and continuous mode, as opposed to trigger-based BCI experiences. A limitation of free-choice scenarios is that it is difficult to accurately measure success rates. We have obtained accuracy measures from S1 of the same method with an avatar-based experiment; these were 100% for a two-class (50% chance-level) task (right hand vs. left hand) and 93% for the three-class (33% chance-level) task, across several runs, using the same ROI-based method as reported here [START_REF] Cohen | fMRI robotic embodiment: A pilot study[END_REF]. In our experiment, the subject was always successful in performing the task in the allocated time. However, different subjects had various degrees of control, and some completed the tasks faster than others. Most trials were constructed so that time allowed for errors. In the present scenario, the subject was able to surround both obstacles by following visual instructions made by the technician. We cannot quantify success rates, but it is clear that the probability of successfully completing the 12-min task with chance-level control is extremely small. We tested the same method by allowing subjects to guide a 3D avatar following a trajectory on a virtual path. Seven subjects were able to perform the task with a high level of success; the results will be published elsewhere.

The participants were asked to perform one of the following three missions.

• Free Navigation. The user is allowed to visit the room freely.

• Seek and Find. An operator shows an object to the robot, then hides it. The subject has to navigate the room to locate it. • Follower. An operator indicates (by gestures to the robot) the path that should be followed. This figure-eight-shaped path wound around two obstacles in order to use all of the three basic movements. In one of the runs, S1 successfully completed the figure-eight-shaped path, shown in Figure 5, by reaching the out point in exactly 12 min.

Figures 67891011show the mean activation values of the three ROIs over two sessions performed by subject S1 from two sessions: in one session the subject was allowed to move both fingers and toes, and in the other session the subject only used motor imagery. Figures 67show the raw values for the three conditions in both motor movement and motor imagery. In order to classify the subject's intentions, we normalized the raw BOLD values using the z score formula and choose the high-est signal as the classified action, as shown in Figures 8 and9.

During the baseline duration (30 TRs), all three regions fluctuated synchronously (Figures 10 and11). In contrast, the task phase (Figures 8 and9) is composed of sections such that in each section one of the ROIs has increased activity compared to the other two ROIs that typically remain in sync: this is the result of the subject activating one of the three motion types (by either imagery or motion) selectively in order to control the robot. The switch among regions (classes) is relatively slow. In this case, the robot itself was slow and took a few seconds to move forward or rotate. In future work, we will examine whether subjects can learn to switch among classes faster.

In the motor imagery session described in Figure 9, the subject was not able to properly rotate left. Inspecting Figure 11 explains why: during the baseline there was a large peak in the left-hand ROI, probably due to an artifact (such as hand motion instead of imagery). As a result, the baseline value for the left ROI was high. Since the current control paradigm is based on the percentage of signal change as compared to the baseline, it was difficult for the subject to exceed the high value of the baseline. In this particular session, the subject realized the limitation and was able to complete the task by turning almost 360 • to the right instead of rotating left.

We are also interested in the subjective experience of the subjects: what is it like to control a robot by thought, using fMRI? The subjects filled in a questionnaire and were interviewed after most sessions. All subjects received the same questionnaire, which included 13 questions about their experience and control, such as "Was there a delay between thought and the avatar's movement?" and "Did you feel that the avatar was an extension of your own body?" and "Did you feel that the avatar's right hand movement was an extension of your hand?" The small number of subjects does not allow for systematic analysis, but we can provide a few anecdotal comments. Subject S1 reported a strong sense of being in the robotic body and "in France." On one of the occasions, the technician picked the robot up in order to avoid hitting an obstacle, and S1 reported this as "hey, why is he lifting me up?" On another occasion we surprised S1 by introducing a mirror in the experiment room in France. The subject reported: "How cute, I have glowing eyes." Subject S2 reported that she felt "very small."

Conclusions and Future Work

The results of this study indicate that subjects can learn to control a robot using either motor imagery or movement, classified by our system, in better-thanchance levels with very little training. The system can also be used to train people for a BCI. Our aim is to allow subjects to perform diverse tasks in the virtual or real environment, using a natural mapping of mental patterns to functionality.

The ROI-based method we have presented here is simple and computationally efficient; we plan to extend it using machine learning techniques in order to iden- tify more specific multivoxel brain patterns that may lead to identifying more complex intentions. In the course of these studies, we also intend to explore how the sensation of agency and embodiment develop in the context of such BCI experiences. This study is the first step and proves feasibility and potential; and we hope more exciting results will follow.

Figure 1 .

 1 Figure 1. Robotic embodiment: General principle of data processing and experimental tasks.

Figure 2 .

 2 Figure 2. The subject sees an avatar in the center of a three-door room. The subject hears an auditory command and needs to use motor imagery or movement that corresponds to it.

Figure 3 .

 3 Figure 3. An example of right-hand versus left-hand contrast and legs versus baseline contrast, taken from one subject over the first stage of the experiment, intended for localization of ROIs.

Figure 4 .

 4 Figure 4. An example of event-related averaging plot for left-hand ROI, taken from one subject. This plot depicts the average hemodynamic response evoked by the stimulus for an ROI over the first phase of the experiment. X and Y axes represent the TR position corresponding to the beginning of the event and the percentage signal change, respectively.

Figure 5 .

 5 Figure 5. The lab room in France, in which the figure-eight-shaped path was drawn on the floor.

Figure 6 .

 6 Figure 6. Raw BOLD activation levels of subject S1 in the three ROIs used to control the robot with motion (fingers and toes).

Figure 7 .

 7 Figure 7. Raw BOLD activation levels of subject S1 in the three ROIs used to control the robot with motor imagery.

Figure 8 .

 8 Figure 8. Normalized activation levels of subject S1 in the three ROIs used to control the robot, during task, using motion.

Figure 9 .

 9 Figure 9. Normalized activation levels of subject S1 in the three ROIs used to control the robot, during the task, using motor imagery.

Figure 10 .

 10 Figure 10. Normalized activation levels of subject S1 in the three ROIs used to control the robot, during baseline, using motion.

Figure 11 .

 11 Figure 11. Normalized activation levels of subject S1 in the three ROIs used to control the robot, during baseline, using motor imagery.

http://medical.nema.org/

Acknowledgments

This research is supported by the European Union FP7 Integrated Project VERE (No. 657295), www.vereproject.eu. We would like to thank the subjects for helping us. We would also like to thank Dan Drai, and the Weizmann's Institute technicians, Edna Furman-Haran, Nachum Stern, and Fanny Attar, for helping in this experiment.


Christian Sicari

Alessio Catalfamo

Lorenzo Carnevale

Antonino Galletta

Daniel Balouek-Thomert

Manish Parashar

Massimo Villari

TEMA: Event Driven Serverless Workflows Platform for Natural Disaster Management

Keywords: faas, event-driven workflows, natural disaster management, ambient intelligence, ndm

TEMA project is a Horizon Europe funded project that aims at addressing Natural Disaster Management by the use of sophisticated Cloud-Edge Continuum infrastructures by means of data analysis algorithms wrapped in Serverless functions deployed on a distributed infrastructure according to a Federated Learning scheduler that constantly monitors the infrastructure in search of the best way to satisfy required QoS constraints. In this paper, we discuss the advantages of Serverless workflow and how they can be used and monitored to natively trigger complex algorithm pipelines in the continuum, dynamically placing and relocating them taking into account incoming IoT data, QoS constraints, and the current status of the continuum infrastructure. Therefore we presented the Urgent Function Enabler (UFE) platform, a fully distributed architecture able to define, spread, and manage FaaS functions, using local IOT data managed using the Fiware ecosystem and a computing infrastructure composed of mobile and stable nodes.

I. INTRODUCTION

In recent years we have assisted in the rise of the Internet Of Things (IoT) as one of the fastest-growing sources of data. The IoT has been applied in many different fields, like smart cities industries (Industry 4.0) and especially in environmental monitoring, with the purpose to keep under control different parameters, such as noise, air quality or in more sophisticated infrastructures, the rise of some kind of environmental disasters like fires, earthquakes or floods (Natural Disaster Management, NDM).

Independently by the application use case, IoT infrastructures are just data collectors, and they are not in charge of permanently storing, analyzing and reacting to the data. When those latter actions are critical or time-sensitive we fall in the area of Urgent Computing, which refers to the use of highperformance computing (HPC) resources to address critical and time-sensitive problems that require rapid response. These problems can include urgent scientific research, emergency

The paper is partially supported both by the Horizon Europe "Trusted Extremely Precise Mapping and Prediction for Emergency Management" project (Grant Agreement, project 101093003 -TEMA) and the Italian Ministry of Health Piano Operativo Salute (POS) trajectory 2 "eHealth, diagnostica avanzata, medical device e mini invasività" through the project "Rete eHealth: AI e strumenti ICT Innovativi orientati alla Diagnostica Digitale (RAIDD)"(CUP J43C22000380001) response planning, or real-time decision making in highpressure situations.

The way followed to build HPC systems changed over the years, moving from the adoption of high-performance cloud infrastructures, towards the use of distributed cloud edge cooperative infrastructures called Cloud-Edge Continuum or just Continuum.

The characteristics of a continuum infrastructure perfectly fit the needs of many time-critical scenarios, but, some challenging issues are still open, especially when applied to dynamic use cases like environment monitoring.

The TEMA project is a Horizon Europe (HE) project that addresses NDM needs by developing automated means for precise semantic area mapping and phenomenon evolution predictions for NDM in (near-)real-time. Potential end-users are mainly Civil Protection Agencies (CPAs), but also First Responders (FRs). To address this problem, TEMA proposes to design and develop an efficient continuum platform able to: (i) Increase responsiveness/speed of extreme data analysis algorithms; (ii) optimize the computation, dynamically migrating it accordingly with the just collected data, the historical information and the Quality of Service (QoS) needed; (iii) drive the computation considering the events that are measured by the IoT infrastructure.

In this position paper, we want to present the preliminary work carried on inside the TEMA project, proposing a continuum native, event-driven workflow architecture based on the Function as a Service (FaaS) paradigm. The goals of this architecture are the following:

• spreading functions at any continuum tier, letting the system use the best available infrastructure to run a NDM workflow; • monitoring and controlling the FaaS infrastructures in order to build an up-to-date dataset from which to learn where to compute based on the expected QoS and the forecast one; • dynamically connecting functions on the continuum to trigger complex distributed workflows able to analyze an incoming event properly. The rest of the paper is organized as follows: section II presents the current state of the art in the field of urgent computing, continuum computing, and event-driven processing; III discusses the infrastructure designed inside the TEMA project to achieve the described goals; IV summarizes work and discusses the next direction in the project.

II. STATE OF THE ART

Since IoT has risen, many different use cases appear with the aim of measuring and preventing some possible disasters [START_REF] Awasthi | Iot-a technological boon in natural disaster prediction[END_REF]. In some industries, IoT can be used for the extraction of oil and gas, which is a well-known system prone to incidents. [START_REF] Hussain | Federated edge computing for disaster management in remote smart oil fields[END_REF]; while in critical areas, IoT is used to detect possible flooding and earthquakes, eventually triggering local alarms [START_REF] Babu | Flood and earthquake detection and rescue using iot technology[END_REF], [START_REF] Balouek-Thomert | Mdsc: Modelling distributed stream processing across the edge-to-cloud continuum[END_REF]; or also to detect tsunamis [START_REF] Løvholt | Urgent tsunami computing[END_REF] in oceanic coast areas. The use of IoT is often associated with the implementation of Machine Learning algorithms used to analyze those data, extract knowledge, and then forecast something about the next possible events [START_REF] Mohammadi | Deep learning for iot big data and streaming analytics: A survey[END_REF]- [START_REF] Saleem | Deep learning for the internet of things: Potential benefits and use-cases[END_REF].

Unfortunately, working on time-sensitive use cases using machine learning algorithms can often be tricky due to algorithm heaviness, or distance from the data location [START_REF] Choda | A critical survey on real-time traffic sign recognition by using cnn machine learning algorithm[END_REF], [START_REF] Augenstein | Applying machine learning to big data streams : An overview of challenges[END_REF].

Urgent computing was born with the idea of providing the best resources possible as soon as they are needed to absolve time-critical events like environmental disasters or human health monitoring [START_REF] Leong | Towards a general definition of urgent computing[END_REF]. In literature, there exist many directions adopted to realize urgent computing. Cloud Computing, of course, thanks to its flexibility in providing any kind of resource has been immediately adopted to realize HPC system to accomplish a job sooner [START_REF] Posey | On-demand urgent high performance computing utilizing the google cloud platform[END_REF], [START_REF] Zhao | Developing and operating time critical applications in clouds: The state of the art and the switch approach[END_REF], but as often highlighted, even less powerful system, but closer to the data can better accomplish a time critical job [START_REF] Koulouzis | Time-critical data management in clouds: Challenges and a dynamic real-time infrastructure planner (drip) solution[END_REF]. The advantages of the use of Edge Computing in fact are mostly related to the proximity to the data [START_REF] Catalfamo | A platform for federated learning on the edge: a video analysis use case[END_REF] and the possibility to work even in the presence of partial network partitions [START_REF] Sicari | A distributed peer to peer identity and access management for the osmotic computing[END_REF], thanks to these advantages some authors proposed Edge as a valid infrastructure to run time-critical analysis [START_REF] Jain | An edge computing paradigm for time-sensitive applications[END_REF], [START_REF] Ovi | Aris: A real time edge computed accident risk inference system[END_REF].

More recently, Cloud Computing and Edge Computing, sometimes together with Fog computing, have no longer considered independent infrastructures, but cooperative ones [START_REF] Liu | Cooperative edge-cloud caching for real-time sensing big data search in vehicular networks[END_REF], which any application can take advantage of to satisfy different QoS levels; this cooperative infrastructure is now called continuum [START_REF] Moreschini | Cloud continuum: The definition[END_REF].

Unfortunately, native cloud or edge applications cannot be easily migrated to the continuous infrastructure, they need to be redesigned from scratch [START_REF] Dustdar | On distributed computing continuum systems[END_REF]. From this assumption, many authors proposed their own native continuum paradigm, frameworks, and applications to take advantage of all the tiers that make up the continuum.

Osmotic Computing [START_REF] Sicari | An osmotic computing enabled domain naming system (oce-dns) for distributed service relocation between cloud and edge[END_REF], was one of the first paradigms used to balance time-critical applications on cloud and edge, it does that by transforming application constraints to environment constraints using a bio-inspired approach. In [START_REF] Renart | An edge-based framework for enabling data-driven pipelines for iot systems[END_REF], the authors propose an edge framework, adapted for the continuum, to spread the computation across the continuum using user-defined dynamic rules that can be defined even taking into account the urgency of the computation.

In [START_REF] Mattia | Leveraging reinforcement learning for online scheduling of real-time tasks in the edge/fog-to-cloud computing continuum[END_REF] the authors collect a list of jobs to be scheduled, taking into account the emergency of each of them, then apply a federated learning algorithm to assign them to a specific node in the continuum federation, using the previous data sets (Qos Required, Qos reached, node, task) as a source of data from which learn. Using machine learning to optimize the QoS of a given task has been further used [START_REF] Jonathan | Awan: Locality-aware resource manager for geo-distributed data-intensive applications[END_REF], but as even the authors have highlighted, knowing the nature of the task and then forecasting its behavior is not easy, and prediction risks being wrong.

With the advent of containerization, researchers have seen in orchestrators, especially Kubernetes a great tool to federate heterogeneous environments like the continuum, and then customize it to deploy containerized applications on a node that can satisfy a time-based QoS constraint [START_REF] Hass | Workload deployment and configuration reconciliation at scale in kubernetes-based edge-cloud continuums[END_REF]; taking in example [START_REF] Rossi | Geo-distributed efficient deployment of containers with kubernetes[END_REF], authors use Kubernetes to federate the continuum, then they provide an internal opensource custom scheduler to deploy pods on a node that can satisfy network latency constraints, a factor that became crucial in real-time processing.

All the previous works have the assumption that any containerized application can be run anywhere and that it is possible to profile it, to forecast its behavior, and both considerations are not strictly true, until the introduction of Serverless Computing and FaaS.

FaaS, often used as synonymous with Serverless Computing, let spread functions using containers on most modern orchestrators, triggering them when explicitly invoked or in reaction to some external events. Most of the open-source Faas providers automatically support multiarchitecture distribution [START_REF] Sicari | Openwolf: A serverless workflow engine for native cloud-edge continuum[END_REF], and this lets the function be spread in the cloud as well in the edge [START_REF] Pfandzelter | tinyfaas: A lightweight faas platform for edge environments[END_REF], the authors in [START_REF] Morabito | Secure-by-design serverless workflows on the edge-cloud continuum through the osmotic computing paradigm[END_REF], built an Osmotic Computing based Serverless Workflow Engine able to spread and connect functions at any continuum tiers, Furthermore, functions belong to well-defined domain functions, which makes profiling functions possible and optimize their schedule on the continuum, taking into account QoS [START_REF] Lakshmi | Qos aware faas platform[END_REF] application parameters and the behavior of the function on any continuum's tier [START_REF] Rossi | Gofs: Geo-distributed scheduling in openfaas[END_REF].

III. ARCHITECTURE

In this section, we present the theoretical architecture we aim at including inside the TEMA project to enable Urgent Computing at the Continuum in the NDM context. This platform shorted by the name Urgent Function Enabler (UFE) is a distributed architecture composed of six main units: 1) the Infrastructure unit (IIA); 2) the IoT unit (IA); 3) the computation unit (CU); 4) the monitoring unit (MU); 5) the scheduler unit (SU); 6) the workflow unit (WU);

A. Infrastructure unit

The infrastructure unit is strictly related to the CU, and is basically made up of all the nodes that are able to deal in any way with the data. In turn, we distinguish two main roles in the IIU which are the sensors and the workers nodes. The sensors are at the lowest level, and they are basically able just to measure environmental parameters and provide them as system data.

The workers do not measure data, but they are able to receive them and then apply some kind of computation like a transformation, or data analysis, eventually the result of that can be reintegrated into the system in order to be collected and analyzed by more workers.

The workers can belong to two main classes: 1) static workers; 2) mobile workers.

Static workers compose the most traditional computing infrastructure that basically is composed of cloud nodes deployed on remote data centers; edge nodes close to the data sources, realized using Raspberrys, Intel Nuc devices, or other micro computers and fog nodes, usually implemented with workstations or small servers racks distributed along the path from the edge to the cloud.

Mobile workers, it is a kind of novelty in this field. We consider mobile any device that can change physically change its position, we include in this group devices such as robots and drones.

Drones and robots have already been used in the field of NDM; some real examples are in [START_REF] Akhloufi | Unmanned aerial vehicles for wildland fires: Sensing, perception, cooperation and assistance[END_REF] where drones were used to monitor wildfires in California. The drones were able to fly over the fires and collect data on their size and intensity. This information was then used to help firefighters make decisions about how to fight the fires; and in [START_REF] Doull | An evaluation of the factors affecting 'poacher' detection with drones and the efficacy of Machine-Learning for detection[END_REF] drones were used to track poachers in Africa. The drones were able to fly over the camps of poachers and identify them. The information was then used by law enforcement to arrest the poachers.

Mobile workers, as well as static ones, can be used by the other units to run algorithms based on the data they can easily reach; to do that, the computation unit has to be used.

B. IoT Unit

The IA is the lowest infrastructure in UFE, it consists of all sensors used to monitor the environment, and it is managed by a Fiware infrastructure that allows the device to be authenticated and authorized, but also provides API to send data and receive commands from and to the upper level [START_REF] Carnevale | Designing a fiware cloud solution for making your travel smoother: The fliware experience[END_REF]. The main components of this architecture are the Orion Context Broker, the IoT Agent (IOTA), the P2P-IDM [START_REF] Sicari | A distributed peer to peer identity and access management for the osmotic computing[END_REF], and the PEP Proxy.

• The P2P IDM is a distributed eventually consistent unit that stores all service accounts used by IOT devices; it provides the API to obtain and verify Oauth2 tokens. The advantage of using a P2P IDM with respect to a centralized IDM is the possibility to keep the service up in the presence of network partitions or disconnections, and this is crucial when the infrastructure is composed of edge and mobile nodes. • The IOTA is a middleware that receives raw data from the IoT, transforms it in NGSI format, and then sends them to the Orion Context Broker. • The PEP proxy is an authorization proxy, placed in front of the IOTA, that verifies the device authorization according to the Keyrock policies and then forwards or denies the request to the IOTA. • The Orion Context Broker is the core of the IOT Unit.

It receives the IoT data from the IOTA NGSI format, and then offers them to third clients using an advanced Pub/Sub model; the subscription will be used to trigger faas workflows on the continuum;

C. The Computation Unit

The CU is responsible for executing the algorithms designed to compute the data collected from the IoT unit. All algorithms are encapsulated in functions since this unit is strictly based on the FaaS paradigm. In brief, FaaS is able to encapsulate a stateless function inside the container, letting external clients invoke this function using typically HTTP or pub/sub-patterns.

In UFE, the CU is not a unique infrastructure, rather it is the logical union of all the CU installed in all the nodes that compose the continuum infrastructure.

Finally, the main component of the CU is OpenFaas. Open-Faas is the most stared opensource engine on GitHub1 , it is composed of a gateway that lets us invoke any function using HTTP; a NATS server associated with a Queue-Worker, which lets us invoke the function using pub/sub model, sending back the result using webhooks, and a faas-cli, which is used to interact with OpenFaas, building multiarchitecture function natively, and of course, deploying them. OpenFaas is a centralized Function Registry to store the functions available in all the CU; this registry is even cached locally to avoid the cold start problem, typical in any containerized infrastructure.

As anticipated previously, the CU works integrated with the IIU; in particular, the FaaS stack is supposed to run in the workers' nodes, in fact, the massive use of lowlevel containerization together with a light system such as OpenFaaS, makes it possible to run functions in most of the traditional mobile units as well as a static unit we want to integrate. At the end then, we will be able to run algorithms on a drone, a robot as well as in a cloud virtual machine.

D. The Monitoring Unit

The MU is fundamental for planning a time-critical computation. The MU is installed along with the computation unit and collects all the useful metrics of all the functions that are executed in the CU. The Monitoring Unit is made up of a high-performance proxy (HPC), a Prometheus instance, and a centralized shared data lake. The HPC is posed in front of the OpenFaas gateway, then it intercepts all the function invocations, forwarding the result to the client, but before doing that it retrieves from the OpenFaas response the request id that is used asynchronously to fetch all the information from Prometheus and OpenFaas' logger. Prometheus is a popular open-source monitoring and alerting system that is used to collect and analyze metrics from various sources in realtime, but at this moment the information that the MU fetches are the following: 1) function executed; 2) continuum's node where the function is run; 3) start time and duration of the computation; 4) start and end time of the request; 5) CPU cycles and memory used to run that function and conclude the request. All these metrics are collected together and then sent to the Data Lake component, which will permanently store them, to be used later to apply scheduler choices.

E. The Scheduler Unit

A key component in the described architecture is related to the scheduling of created workflows among the components that belong to the Cloud-Continuum Infrastructure. In particular, the SU exploits context data to estimate the more efficient and convenient node in which the function should be deployed. A key role is played by MU that collects the monitored data that will actually be used to guide the scheduler in the offloading of workflow processes. The scheduling is dynamic, and it exploits Machine Learning inference to establish more appropriate nodes in which workflow can be deployed. The inference of a Machine Learning model could be considered a complex operation that can compromise a time-constrained application. For this reason, the scheduler will figure out an inference with a pre-trained model in an asynchronous fashion when a new workflow is not yet created or deployed. The model consists of a Deep Neural Network in which the inputs are all metrics collected through MU and the QoS score brought by the specific workflow. The model output consists of a score that ranks each node in the architecture on the basis of different parameters: time-response respect to the scheduler, used memory, used CPU, and other possible parameters collected by Prometheus instance present in MU. In particular, it performs, exploiting a classical Soft Max Activation Function, a classification of more appropriate nodes according to computed scores. It classifies the most efficient node candidates for deploying the next workflow processes. The decision of the nodes for each process is decided following the probabilities computed by the model. Moreover, the model will be updated by exploiting historical data collected through a continuous learning mechanism that takes advantage of the Federated Learning approach [START_REF]Communication-efficient learning of deep networks from decentralized data[END_REF]. Indeed, each node, periodically, trains a local model that will be aggregated in the central cloud server and exploited by the scheduler's central component. The scheduler will become more precise thanks to historical data collected by MU.

F. The Workflow Unit

One of the most highlighted downsides of FaaS is the inability to deploy complex and distributed workflows that connect functions to serve a bigger and composed computation. To overcome this, most of the FaaS-based architectures propose to use a centralized microservice that invokes and synchronizes the right function when needed. This small trick might be not the best choice for any distributed time-critical environments; therefore, we integrated the WU. The WU let us define serverless workflows using a light version of OpenWolf [START_REF] Sicari | Openwolf: A serverless workflow engine for native cloud-edge continuum[END_REF]. OpenWolf is a small distributed broker that can be instantiated on Kubernetes or with just Docker for the lightest environments in this use case, we have an OpenWolf agent for each computing tier. OpenWolf2 uses a customized version of the Serverless Workflow DSL3 to describe how the input and output functions are connected, allowing one to define asynchronous faas DAGs. Using the DSL, we can submit a Manifest file to the OpenWolf agent, the manifest file will be used to declare a workflow and then it will be used to trigger the function defined inside it when a specific event occurs. Through the Manifest is even possible to decide where to deploy a function to use inside the workflow, but in this case, we modified the function allocation, in order to migrate a function location according with the QoS of an event and the suggestion coming from the SU. Manifests are even more shared with all the OpenWolf agents, in this way, any instance can run the same workflow.

G. Units Integration

The integration of the UFE unit is quite straightforward. The overall architecture is presented in figure 1, from the bottom we distinguished three different zones provided with the IoT sensors. Each device can use any of D-IDM to get an Oauth2 token, that is used to access to the IOT Agent in the IA. In the same unit, the IoT Agent, sends the data to the Context Broker, where the data live. In parallel, as soon as a Workflow manifest is sent to OpenWolf, the functions included in that file are deployed on the Computing Infrastructure according to the scheduler's choices. When all the functions are ready, the workflow endpoint is subscribed to the Context Broker which contains the data needed to trigger the workflow. When the subscription arrives at the Context Broker, data will be sent to the first function on the workflow, and in turn, the result will be forwarded to the other functions until all the functions in the workflow are not consumed. While the functions are run, the monitor system installed alongside the serverless platform records all the information related to the executions. This information will travel to the Data Lake, which the scheduler will continuously read to adapt the function position in the infrastructure dynamically.

IV. CONCLUSION AND FUTURE WORKS

The work proposes a solution for Natural Disaster Management in the Horizon TEMA project exploiting Cloud-Continuum workflows, and applying them considering QoS parameters. TEMA is a Horizon Europe-funded project that wants to manage Natural disaster Management exploiting a Cloud-Edge Continuum infrastructure. For this reason, the architecture depicted in this work must be able to manage Urgent Computation applications. The solution described here is a concrete workflow system use case that can satisfy the QoS and realize a complex algorithm pipeline exploiting IoT-collected data in a Cloud-Continuum infrastructure. Moreover, the architecture described is capable of performing dynamic scheduling of workflow components, exploiting the monitored data by each node of infrastructure, and a sophisticated machine learning model capable of retrieving the optimal nodes. The fixed steps to perform are the practical application of the solution in a concrete use case provided by the TEMA project and the practical performance evaluation of implemented architecture. As naturally expected in future works, we need to validate the architecture we proposed, in order to understand the limits and strengths of the works.

Fig. 1 .

 1 Fig. 1. TEMA Platform Architecture

https://github.com/openfaas/faas

https://github.com/christiansicari/OpenWolf

https://serverlessworkflow.io/