J Cotxet

F Gutty

G Baili

L Morvan

D Dolfi

S Guérandel

D Holleville

Ramsey CPT Signal Generation with a Miniature Clock Bench and a Dual-Frequency Optical Generator

Keywords: compact clock, cesium, CPT, Ramsey interrogation

We demonstrate, for the first time, Ramsey CPT spectroscopy with a miniature electro-optical bench associated to a dual-frequency generator based on combined optical injection locking and optical phase locking techniques Preliminary results show Ramsey CPT resonance with a contrast of 2% at the Cesium D2 line. Frequency difference locking loops lead to a contribution of Dick effect to fractional frequency stability lower than 1.7x10 -13 at 1 s, in line with targeted clock stability of 5×10 -13 at 1 s.

I. INTRODUCTION

During the last few decades, new concepts and technologies have emerged, particularly in developing precision frequency standards using atomic vapor cells [START_REF] Marlow | A review of commercial and emerging atomic frequency standards[END_REF]. The concerted effort in this development is to improve the clock characteristic to achieve high frequency stability, and precision along with reduced volume, weight and power consumption. Among these technologies, coherent population trapping (CPT) in atomic vapor cells shows impressive frequency stability at both short and long-time time scales [START_REF] Hafiz | Toward a High-Stability Coherent Population Trapping Cs Vapor-Cell Atomic Clock Using Autobalanced Ramsey Spectroscopy[END_REF]. In this context, we propose to implement a highly compact CPT clock based on a miniature electro-optical bench and a dual-frequency optical generator based on optical injection locking technique for Lin per Lin interrogation [START_REF] Zanon | High contrast Ramsey fringes with coherent population trapping pulses in a double lambda atomic system[END_REF]. The targeted relative frequency stability at 1 s of integration time is below 5×10 -13 . Extensive studies of the miniature optical bench has been already reported for both short and long time scales and interactions with a dual-frequency beam were previously described [START_REF] Cotxet | Laser Intensity and Frequency Stabilization Implemented on a Miniature CPT Clock Breadboard conference paper[END_REF]. Here we first present a dual-frequency optical generator based on the combination of two locking techniques: a passive optical injection-locking loop (OIL) and an optical phase-locking loop (OPLL). Then, based on the obtained dual-frequency generator, we present preliminary characterizations of continuous and pulsed CPT spectroscopy using the miniature clock bench.

II. Experimental set-up

The first building block is the dual-frequency optical generator (see Fig. 1). A low power DFB laser (master) is used to injection lock a low power DFB laser (slave) and generate the dual-frequency dual-polarization beams for our experiments. First, a part of the output from the master laser is sent into a fibred Mach-Zhender electro-optical intensity modulator (EOM) which is modulated at 9.2 GHz, i.e. the hyperfine frequency of cesium, delivered by a reference local oscillator (LO). The EOM is biased with a DC voltage set near to the carrier suppression DC bias. Then, the resulting optical field is fed back to the slave laser cavity with an injection ratio, r, defined as the ratio between the injected power and the slave laser emitted power. In order to take advantage of the optical injection loop (OIL) expected phase noise reduction, the optical delay between the master laser and the slave laser is compensated. To further stabilize the relative phase between the two lasers, an OPLL is implemented A photodiode (FPD) and an amplifier (RFA) are used to detect the beat note at a part of the output of the injection-locked diode laser system. The corresponding signal is compared with a microwave mixer to the 9.2 GHz signal coming from a reference local oscillator. The resulting error signal is filtered and fed back to slave laser, through its current supply. The resulting CPT beams are cross polarized and sent to the clock bench. The second building block is the miniature electro-optical bench (see Fig2). It provides all the functions needed for the CPT beam stabilization within a low volume of 10 L. The electro-optical bench functions description and validation are detailed in [START_REF] Cotxet | Laser Intensity and Frequency Stabilization Implemented on a Miniature CPT Clock Breadboard conference paper[END_REF]. The cross-polarized laser beams are superimposed and sent through the miniature electro-optical bench. At the last stage, the optical beam, with a mean power of 1mW per polarization, is extended and sent to a glass cell containing the cesium vapor and a buffer gas mixture. This cell is included in a physics package that ensures temperature and static magnetic environment stabilization. The transmitted light is detected with a photodiode, and the obtained CPT signal is processed. First, the dual-frequency generator is operating only with the OIL. As expected from this injection technique, we observe a drastic and a wideband reduction of the beat note phase noise, obtained for an injection ratio of -30 dB (See Fig. 3). From 100 Hz to 10 kHz, the phase noise (red line) reaches a low noise level, going from -60 dBc/Hz to -105 dBc/Hz. At 100 kHz, it represents an improvement of more than 70 dB compared with the free-running beat note phase noise (black line). When the OPLL is applied (blue line), the phase noise of the beat note reaches its lowest limit for frequencies going up to 200 kHz., i.e. the phase noise of the LO (grey line). Due to OPLL bandwidth limitation, 5 dB noise excess is measured around 400 kHz. The laser power stabilization loop is not applied, leading to the relative intensity noise (RIN) spectrum depicted by the insert of Fig. 3.

Zeeman split CPT resonances are first observed using continuous laser beams and after applying a DC axial magnetic field of 8 µT (see Fig. 4-left). The 0-0 CPT resonance is observed at the center with a linewidth of 2.4 kHz et and a contrast of 2.3%, 4 times lower than reported values with Cs D1 line [START_REF] Lutwak | The chip-scale atomic clock-recent development progress[END_REF]. Next, we used pulsed CPT beams to generate Ramsey fringes. A first pulse of length p (2ms) allows to pump the atoms into the CPT state. Atoms then evolve freely in the dark during a time TR. A second pulse is used for CPT signal detection. A delay R of 20 μs is taken before opening a detection window with a length D (25 µs). 3, their contribution to the clock fractional frequency stability at 1 s integration, respectively through Dick effect and light shift effects, respectively, are equal to 1.7x10 -13 and 3.7x10 -13 .

IV. CONCLUSIONS

Ramsey CPT spectroscopy is performed with a miniature electro-optical bench (volume < 10 L) associated to a dualfrequency generator based on combined optical injection locking and optical phase locking techniques of two DFB COTS lasers. Preliminary results show Ramsey CPT resonance with a contrast of 2% at the Cesium D2 line. Frequency difference locking loops lead to a contribution of Dick effect to fractional frequency stability lower than 1.7x10 -13 at 1 s, in line with targeted clock stability of 5×10 -13 at 1 s. Further investigations should include the simultaneous operation of stabilization servo loops and an optimization of Ramsey fringes contrast.

Fig. 1 .

 1 Fig. 1. General scheme of the combined loops OIL and OPLL.

Fig. 2 .

 2 Fig. 2. Miniature electro-optical breadboard. The dimensions are 9.5 × 25 × 43 cm3. (i) optical isolation, (ii) Power stabilization (iii) optical frequency locking, (iv) beat note detection (v) Optical pulses shaping III. RESULTS

Fig. 3 .

 3 Fig. 3. Phase noise of the beat note between the two CPT beams. Black line: free-running, Red line: with OIL and -30dB injection ration, Blue line with OIL and OPLL. Grey line: phase noise of the LO at 9.2 GHz Inset: RIN spectrum of the CPT beams in free running.

Fig. 4 .

 4 Fig. 4. Left: Zeeman split CPT resonances observed with CW optical beams. Right: Ramsey CPT resonances observed with pulsed optical beams Fig. 4-right shows preliminary Ramsey-CPT fringes for a free-evolution time TR of 4 ms. The central fringe linewidth is about 125 Hz. The CPT contrast is about 2%. Considering the OPLL phase noise and the laser free-running RIN depicted in Fig.3, their contribution to the clock fractional frequency stability at 1 s integration, respectively through Dick effect and light shift effects, respectively, are equal to 1.7x10 -13 and 3.7x10 -13 .

This work was partially supported by the Direction Générale de l'Armement and was performed in the framework of J. Cotxet thesis supported by ANRT.


Keywords: Soft Robotics, Sequential Decision Making, Inverse Model Control, Monte Carlo Tree Search, Closed Loop Control vi

This thesis focuses on automatic navigation of guidewires and catheters in the coronary arteries. We first introduce the context of interventional cardiology and percutaneous coronary interventions. We also justify the use of a robot for those procedures. We then link the guidewire navigation problem to the control of soft robots and review the existing literature.

Our study starts with building realistic, dynamic simulations of the arteries, heart and their interaction with the instruments. This required the gathering of patient data, understanding how the heart beat motion deforms the heart and how these deformations impact guidewire navigation. Percutaneous coronary interventions are also very contact dense which is a challenge for both simulation speed and accuracy.

We then used these simulations to frame the problem of navigating the coronaries as a sequential decision making problem. We determined the corresponding state and action spaces and devised a reward. We tested a variety of control schemes on the navigation problem, including inverse model based control and tree-search based control and proposed a novel combination of both which achieves good performance in navigating the coronaries.

Finally, we design a vision algorithm and registration scheme to transfer the algorithms to a physical robot. The closed loop control scheme was tested on two different silicone phantoms and achieves the same success rate as navigating by hand or by tele-operating the robot.

"Mundi placet et spiritus minima", ça n'a aucun sens mais on pourrait très bien imaginer une traduction du type : "Le roseau plie, mais ne cède... qu'en cas de pépin" ce qui ne veut rien dire non plus.

Loth d'Orcanie interprété par François Rollin, Kaamelott, Livre VI, Lacrimosa, écrit par Alexandre Astier.

Résumé

Cette thèse porte sur la navigation automatique de guides et cathéters dans les artères coronaires. Dans un premier temps, nous introduisons le contexte de la cardiologie interventionnelle et le cas particulier des interventions coronaires percutanées. Nous justifions aussi l'utilité de la robotisation de ces procédures. Nous faisons ensuite le pont entre le problème de la navigation de guides et le contrôle de robots déformables, puis examinons les travaux existants sur le même sujet.

Notre étude commence par la concéption de simulations dynamiques réalistes des artères, du coeur et de leur intéraction avec les instruments chirurgicaux. Cela a nécessité la collecte de données patient, la compréhension de l'influence du battement cardiaque sur la déformation des artères et comment cette déformation impacte la navigation de guides. Les interventions coronaires percutanées considérées reposent également fortement sur les contacts entre les instruments et les parois arterielles, ce qui est une difficulté supplémentaire au regard du temps de simulation ainsi que de leur précision.

Nous avons ensuite utilisé ces simulations pour formuler le problème de la navigation de guides dans les artères coronaires comme un problème de prise de décision séquentielle. Nous avons défini les espaces d'état et d'action correspondants et conçu une fonction de récompense adéquate. Nous avons testé plusieurs stratégies de contrôle, y compris des mèthodes de contrôle basées sur un modèle inverse et des méthodes de recherche arborescente. Nous avons également proposé une nouvelle combinaison de ces méthodes qui atteint de bonnes performances dans les cas de figure testés.

Finalement nous avons conçu un algorithme de vision et un schéma de recallage permettant de transférer les algorithmes de commande sur un robot physique. L'algorithme de contrôle en boucle fermée ainsi constitué a été testé sur deux fantômes en silicone différents sur lesquel l'algorithme atteint un taux de succès comparable à une navigation manuelle et à une navigation en télé-opérant le robot.

Keywords:

  Robotique Déformable, Prise de Décision Séquentielle, Controle par Modèle Inverse, Monte Carlo Tree Search, Contrôle en Boucle Fermée

Remerciements

I would like to start by thanking Professor Bello, Doctor Bergeles, Professor Berger, Doctor Carpentier, Professor Szewczyk and Professor Troccaz for agreeing to be part of the jury. Je veux ensuite remercier tout particulièrement mes directeur et co-directeurs Christian, Jérémie et Philippe. Merci pour votre patience, votre disponibilité, votre aide, votre confiance et votre soutien. Merci également à Bruno et Laurent, pour votre appui sur les problématiques industrielles. Merci finalement à Rémi pour son accueil dans son service et son expertise médicale. Je souhaite également remercier Etienne pour son aide précieuse en stage puis sur SofaGym ainsi que pour nos discussions, sur le RL ou non. Je remercie également Bruno M. et Damien pour leur appui inestimable quant à l'utilisation de SOFA. Je remercie finalement Wassim pour sa contribution à l'algorithme de vision. Merci également à Eulalie et Edouard pour leur aide dans ce projet. Je remercie mes collègues d'Inria pour les moments passés ensemble, tant au bureau qu'en dehors, à la salle d'escalade, sur un vélo ou a parler de permaculture et du monde d'après autour d'une frite. Merci en particulier à Bruno M., Damien et Félix, camarades de vélorution, de grimpe et potagistes aguérris, Olivier, cycliste et grimpeur imbattable, Yinoussa, coach sportif et d'applications mobiles ainsi que tous les collègues de DEFROST et de SCOOL, Anne, Alex K., Alex B., Camille, Christian, Etienne, Eulalie, Jérémie, Gang, Lingxiao, Mahsa, Mathieu, Maxime, Mei, Nathan, Omar, Paul, Quentin, Philippe, Stefan, Tanguy, Thor, Walid, Xuedong, Yannis, Zhongkai... Special thanks to Ke for being an amazing office mate. Je veux également remercier mes collègues de Robocath. Benoit, Franck, Ricardo, Sophie, Siham et tou•te•s les autres footeu•x•ses du vendredi, Arthur, Camille et Guillaume, les nageu•r•se•s du mardi, Amélie, Chloé, Gaëtan, Jules, Justine, Michaël, Pierre D., Siham, Simon, Wifried et tou•te•s les grimpeu•r•se•s, Alexis, camarade de bar et de dancefloor et tous les usagers de la cantine SDR117. Merci à mes parents et à ma famille pour leur soutien et leurs encouragements.

iii

Remerciements

A tous mes colocs au cours des années, Adéla, Antoine B., Antoine P., Antoine V., Arthur, Camille, Célia, Côme, Frédéric, Gaëtan, Janice, Léa, Marion F., Marion H., Maxime, Valérian, Ximena et Zoé, merci pour les bouffes, les soirées, le sport, les blagues et tout ce qu'on a partagé.

Un immense merci également à mes camarades d'ANV COP21 Lille, Alternatiba Rouen et la BASE Rouen pour votre amitié et tous nos beaux projets, passés et à venir.

Enfin, merci Louise pour ton soutien indéfectible, ton inébranlable et contagieuse bonne humeur et toutes tes trop bonnes idées.

Remerciements

Abstract


Mohammed Foughali
email: foughali@irif.fr

Some thoughts on teaching introductory programming and the first language dilemma

Keywords: Social and professional topics → Computer science education; Computer engineering education introductory programming, first programming language, CS1 & CS2

There is a consensus among computer education experts and practitioners that teaching introductory programming is intrinsically hard. In particular, the choice of the first programming language to support learning the fundamentals of problem solving and algorithmic reasoning is a hot issue that is driving a lot of attention within the last few decades. As a side effect, the computing education community has been long divided between supporters of industrial relevance and advocates of educational benefits as the prominent grounds on which a first programming language should be elected. While the former seem to have the wind in their sails, with popular-in-industry languages such as Java, C and C++ being still widely used to teach introductory programming, the case is far from being closed. In this paper, we propose to analyze the first language choice dilemma in the light of a number of rigorous studies carried out within and outside of the computing education community. We show that, in the light of these studies, we can efficiently question our choices as educators and stimulate objective discussions toward reconciling our views regarding the first language choice. Mainly, we devise a number of criteria, all backed up with scientific findings from different communities, according to which a first language should be evaluated. Our conclusions converge toward a justified concern vis-à-vis the use of languages such as Java and C to teach introductory programming, and the pressing need for a better compromise between industrial popularity and educational advantages. To meet that need, our position gravitates around two major opinions stemming from our cross-disciplinary analysis: (i) Java, C and C++ should not be used to teach introductory programming and should rather be saved for more advanced programming courses and (ii) while the recent trend of choosing Python is justified, it is still debatable and therefore other candidates, among which we propose a couple, should also be seriously considered. Besides arguing in favor of these opinions, the primary aim of our analysis is to trigger fruitful discussions on the subject fuelled by cross-disciplinary research findings rather than personal opinions.

INTRODUCTION

Computer science CS programs are proliferating across world's universities. For instance, the number of undergraduate CS programs in the US and Canada has grown by 74% in a seven-year interval [START_REF]Assessing and responding to the growth of computer science undergraduate enrollments[END_REF]. Unfortunately, this expansion is contrasted with persistent difficulties for students and educators alike. In particular, introductory programming is noticeably hard to teach and learn [START_REF] Gomes | Learning to program -difficulties and solutions[END_REF][START_REF] Jenkins | On the difficulty of learning to program[END_REF][START_REF] It | Issues and difficulties in teaching novice computer programming[END_REF][START_REF] Qian | Students' misconceptions and other difficulties in introductory programming: A literature review[END_REF][START_REF] Robins | Learning and teaching programming: A review and discussion[END_REF] with rather stable, relatively high dropout rates worldwide [START_REF] Bennedsen | Failure rates in introductory programming: 12 years later[END_REF][START_REF] Watson | Failure rates in introductory programming revisited[END_REF]. While the CS education literature is rich in debates on the "best" methodologies and languages for teaching introductory programming [START_REF] Böszörményi | Why Java is not my favorite first-course language[END_REF][START_REF] Neil | Ten quick tips for teaching programming[END_REF][START_REF] Suhana | A comparison of Java and C#[END_REF][START_REF] Leutenegger | A games first approach to teaching introductory programming[END_REF][START_REF] Rahul | An open source graphical robot programming environment in introductory programming curriculum for undergraduates[END_REF], their often divergent conclusions are hard to reconcile. As an example, Duke et al. praise Java's suitability for introductory programming [START_REF] Duke | Teaching programming to beginners -choosing the language is just the first step[END_REF], whereas Meyer mocks its "magic" main (string[]args) "which you do not understand" [START_REF] Meyer | The outside-in method of teaching introductory programming[END_REF].

The aim of this paper is to set the basis for fruitful discussions regarding the choice of the first language used as a "support" to teach introductory programming. To that end we argue as follows.

(1) Discussions on the first language choice should be made in accordance with a final objective (while a computer science graduate is expected to be an expert programmer [START_REF] Jenkins | The motivation of students of programming[END_REF][START_REF] Robins | Learning and teaching programming: A review and discussion[END_REF], a civil engineer is fine with basic programming skills). We focus on introductory programming where the objective is to form expert programmers, which we refer to simply as IP1 . (2) These discussions should feed on cross-disciplinary (CS education, educational psychology, cognitive science) existing rigorous research rather than personal and anecdotal opinions. Points (1) and ( 2) are intimately linked: as we show in the next paragraph, a preliminary analysis of the literature points to the fact that the first language choice may seriously impede the process of acquiring expert programmer skills.

A key trait of expert programmers EP is that they "organise their knowledge according to functional characteristics such as the nature of the underlying algorithm rather than superficial details such as language syntax" [START_REF] Robins | Learning and teaching programming: A review and discussion[END_REF], which implies the valuable benign side effect of high adaptability to new programming languages. Jenkins emphasizes this adaptability suggesting that EP simply "bring [their] knowledge to some new situation (in this case the new language)" [22, p. 45]. Unfortunately, in the last two decades, the trends in teaching IP seem to go against the EP objective. Gomes and Mendes pointed out this issue: "teachers are more concentrated on teaching a programming language and its syntactic details, instead of promoting problem solving using a programming language" [START_REF] Gomes | Learning to program -difficulties and solutions[END_REF]. More recent studies show further that the observations of Gomes and Mendes are particularly present in settings where the language used to teach IP is chosen primarily for its industrial popularity [START_REF] Koulouri | Teaching introductory programming: A quantitative evaluation of different approaches[END_REF][START_REF] Stefik | An empirical investigation into programming language syntax[END_REF]. In particular, Koulouri et al. show in an elegant study that teaching "some [popular-in-industry] programming languages [with a focus on Java]" may drown beginners into syntax issues and "distract them from learning basic programming concepts, which may, in turn, have a lasting impact on students' confidence" [START_REF] Koulouri | Teaching introductory programming: A quantitative evaluation of different approaches[END_REF]. There appears therefore to be a discrepancy between the choice of languages such as Java and C (mainly for their industrial merit) in IP courses, still popular as of today, and the consensus that teaching IP (the objective of which is, we recall, forming EP) must focus more on algorithmic reasoning than on programming languages technical details [START_REF] Gomes | Learning to program -difficulties and solutions[END_REF][START_REF] Jenkins | The motivation of students of programming[END_REF][START_REF] Koulouri | Teaching introductory programming: A quantitative evaluation of different approaches[END_REF]. This situation is, to say the least, worrying, given that several studies confirm that educators are clearly shifting from the classical debate of industrial relevance vs. educational benefits toward settling for the former as the most important -even the only -ground for selecting the first language (Sect. 4). There is therefore an urgent need to reconcile our views on the first language dilemma somewhere between educational fitness and industrial relevance. Even with the recent trend of switching to Python, this urgent need is far from being met, as reflected by the persistence of Java/C/C++ in IP courses today (Sect. 4) and the educational pitfalls of Python (Sect. [START_REF] Altadmri | 37 million compilations: Investigating novice programming mistakes in large-scale student data[END_REF][START_REF] Muñoz Arancón | ESROCOS: Development and Validation of a Space Robotics Framework[END_REF]. Therefore, in order to question our choices as educators, we need to establish clear, evidence-based criteria on which electing a language for teaching IP should be based.

This paper identifies some of these criteria and discusses whether the current choices w.r.t. the first language should be reconsidered. While we (i) make a clear case against the use of Java, C and C++ to teach IP and suggest saving them for later years (when students are no longer novices) and (ii) put forward three alternative language candidates (including Python), our main objective is to trigger constructive discussions on the first-language choice dilemma based on cross-disciplinary scientific findings. Note that the conclusions of this paper rely on a procedural-first approach, without any attempt to minimize the debate on the first-paradigm dilemma [START_REF] Susan | The first programming paradigm and language dilemma[END_REF][START_REF] Pears | A survey of literature on the teaching of introductory programming[END_REF] (more in Sect. 4).

Following the importance and the dependency between points (1) and (2) above, the paper is organized as follows. First, we provide a context of a typical IP course for which a programming language should be chosen to serve as a "support" (i.e. to implement the algorithms). In particular, we discuss the educational choices made in the course, in light of various research findings, in order to be in line with the EP objective, regardless of the support language (Sect.2). Second, we devise some criteria, also backed up with existing research, to elect a first language to support the course presented previously (Sect. 3). We show that languages such as C, C++ and Java, still as of today belonging to mainstream languages used in IP courses 2 , score poorly when confronted with these criteria. We then conclude with Sect. 4 as we propose, besides Python, already considered by many educators, two other candidates, namely Ada and Kotlin, to possibly replace Java/C/C++. We show that (i) Python is not necessarily the ideal undebatable replacement and (ii) languages like Ada, and perhaps Kotlin, should not be discarded a priori, and conclude with open questions regarding the possible directions of future discussions where further candidates may also be considered.

IP COURSE 2.1 Targeted public

The course we present is applicable to any IP (i.e. any introductory programming, first-year university course where the final objective is to form EP, Sect. 1). It

Content

The course frames programming as a communication problem. We have, at one end, a human speaking natural language (e.g. English or French) and, at the other end, the computer "speaking" binary. The problem of programming then consists in finding a way for the human to communicate with the computer and get it do what he/she wants i.e. execute the solution to the problem at hand. Since the gap between the languages spoken at each end is huge, programming languages serve as an interface (in the sense of a "compromise") between the human and the computer. Still, a programming language is drastically different than natural language, so we need another "intermediary interface": high-level solutions.

Fig. 1, taken from our teaching slides, illustrates the programming problem as introduced in the course. Connecting the two ends of the communication and the interfaces forms a chain of programming "phases": (i) specifying solutions (the specification phase), (ii) implementing them as programs using a programming language (the implementation phase) and (iii) compiling such programs into binaries (the compilation phase) 4 .

The course explains afterwards that compilers are ready-to-use generators: the compilation phase does not need any intervention from the students (besides interpreting its results). It summarizes accordingly that programming is a two-phase activity: at the specification phase, what we want the computer to do transforms from natural language to abstract mathematical solutions, whereas the latter become programs at the implementation phase. The course emphasizes the importance of the specification phase as mastering it will make it easier for students to succeed in the different programming languages courses in the upcoming years. It is important to note that the organization in Fig. 1 is paradigm independent . While this course follows a procedural-first approach, where, in later slides, the green box content is replaced with "algorithms", the same organization can be used within an object-first approach (by simply replacing "high-level solutions" with e.g. "diagrams & algorithms" in later slides).

The course then focuses on the specification problem: how do I specify an abstract solution to a problem described in naturallanguage? In a procedural setting, the specification phase is equivalent to writing algorithms. Based on Fig. 1, to program is to communicate with the computer, thus solutions should be written for the computer. Therefore, an algorithm should provide a solution that a high-level fictive computer would be able to execute. This fictive computer has different levels of "tolerance" toward what humans write. The tolerance-zero level is conceptual: this involves e.g. a sequence of instructions that are both elementary (adding two numbers is elementary, factorial is not) and unambiguous ("do this" is clear, "do this or that" is not). The maximum-tolerance level is syntactical, e.g. ending an instruction with either a line-break or a semicolon is okay as long as it is consistent throughout the algorithm. Thus, the course encourages the students to separate more important aspects, that is problem solving (how to solve a problem thinking like the fictive computer, e.g. in terms of a sequence of elementary unambiguous instructions) from the less important ones, that is syntactical details (e.g. what symbol should I use to end my instruction?)

On this basis, the remaining course sessions (lectures and assignments) cover various aspects of algorithms (e.g. types, variables, instructions, loops and subroutines) and data structures (e.g. records and arrays). IP is limited to static variables (dynamic variables and pointers are covered in the second year). Implementation is introduced gradually as the students encode their algorithms using a support language. Since algorithms and data structures are classic in IP, we do not go into their details. Rather, we emphasize some choices made in the course and explain their motivations.

Algorithmic notations.

McIver and Conway referred to seminal works from educational psychology and cognitive science to argue that learning programming can be negatively affected by unlearning existing parts of the students cognitive structures [START_REF] Mciver | Seven deadly sins of introductory programming language design[END_REF] (for instance, unlearning that = means equal to, a knowledge that first-year students hold for over 15 years). Teaching algorithms to a beginner should connect to his/her existing cognitive structures and involve as little unlearning as possible, preferably no unlearning at all (see more on the effects of unlearning in Sect. 3.2.1). Thus, = remains the notation for equality, whereas we use ← for assignment (read "transfer what is on the right into what is on the left" [START_REF] Mciver | Seven deadly sins of introductory programming language design[END_REF]). Similarly, we use either universal symbols or their English meanings for boolean operators, e.g. ∧ and ∨ (or simply and and or) . Besides being "anti-unlearning" and promoting simplicity (more on the importance of syntax simplicity at the implementation level is given in Sect. 3.2.2), these choices serve the purpose of building a "universal" specification basis, independent as much as possible from programming languages. Students will thus always find their "pivot" when moving to a new programming language, as they implement their abstract solutions in the language (mapping the universal symbols to their language-specific counterpart).

Variables.

Variable-related misconceptions are a major source of students difficulties in programming [START_REF] Milne | Difficulties in learning and teaching programming[END_REF]. These misconceptions can form as early as the abstract introduction of variables in IP. Clancy, for instance, shows that using a box to represent a variable (a metaphor still commonly employed by teachers [START_REF] Qian | Students' misconceptions and other difficulties in introductory programming: A literature review[END_REF]) messes with the mental model of students as it makes them, for instance, think that a variable may hold a number of things [START_REF] Clancy | Misconceptions and attitudes that interfere with learning to program[END_REF]. We suggest using the labelized erasable slates metaphor: a variable is an erasable slate with a label indicating its name and type. Thus, declaring e.g. an integer variable 𝑥 creates a slate, labelized with the variable name 𝑥 and type integer, with an arbitrary integer on it, which students may erase to write a different value instead (assignments, including initialization). The label allows to find the variable (the name) and prevents writing anything but integers (the type).

Loops.

Another widespread misconception is viewing the while and the for loops as identical, therefore preferring one over the other instead of comprehending that each is destined to solve a different problem [START_REF] Qian | Students' misconceptions and other difficulties in introductory programming: A literature review[END_REF]. While Qian et al. link this misconception to factors such as "which loop construct the student learned first" [START_REF] Qian | Students' misconceptions and other difficulties in introductory programming: A literature review[END_REF], we show in Sect. 3.2.3 that the programming language chosen for IP is another important factor. In the course we present, comprehending these loop constructs regardless of the language is important. Finding an integer in an array is a while problem (browse the array as long as the value is not found or there are more cells to browse) whereas finding the smallest integer in an array is a for problem (browse the whole array in any case, i.e. for each index in the array range). Understanding the differences at this stage minimizes the chances of students to confuse both constructs (Sect. 3.2.3).

Subroutines.

Though distinguishing subroutines with and without a return value may sound trivial, giving it little attention at the specification phase has serious consequences at the implementation phase (Sect. 3.2.4). The course uses the terminology procedure and function to denote a subroutine without and with a return value, respectively. In addition, the course advocates the "good practices" of writing subroutines as early as the specification phase. These practices include the well-known "friends" of reusability (e.g. simple, hardcoding-free subroutines), but also other guidelines such as "a return values must not be discarded" to help prevent common, hard-to-catch code bugs (Sect. 3.2.4).

Analysis.

Algorithms must be correct, in order to implement correct code. Many students make mistakes (e.g. infinite while loops) due to violating the underlying logical properties of different algorithmic concepts. Therefore, the course promotes logical reasoning as it guides students toward deriving formal rules that help them write correct algorithms. For example, let 𝑉 (resp. 𝐼 ) be the set of variables tested in the condition (resp. the set of instructions within the body) of a while loop, and SI : I ↦ → P (V ) (where P (V ) is the powerset of 𝑉 ) the function returning the subset of 𝑉 modified by an instruction i ∈ I . The course drives students' attention to the fact that if ∀i ∈ I : SI (i) = ∅ then the while loop is either never executed or infinite (and is thus, in the general case, misconceived). Moreover, the course familiarizes students with program verification. In particular, students learn how to use preconditions, postconditions and invariants to verify their algorithms. At the implementation phase, students should be able to concretize their acquired knowledge on program verification in lab sessions (Sect. 3.2.5).

FIRST LANGUAGE CHOICE

In this section, we reflect on the first language choice dilemma in the context of the IP generic course introduced in Sect. 2. Like it was the case for the choices made in the course, we evaluate the support language according to several criteria in the light of rigorous, cross-disciplinary research findings. The criteria belong to the two traditional categories considered by computing education experts when electing a language to support teaching IP: industrial relevance (Sect. 3.1) and educational benefits (Sect. 3.2). In particular, we derive five important aspects under the educational benefits category based on previous research.

We analyse, under all criteria, six programming languages: Java, C, C++, Python, Ada and Kotlin. These candidates are chosen in compliance with our observations, backed up with the literature, introduced in Sect. 1. Indeed, we evaluate Java, C and C++ to underpin the concerns raised in [START_REF] Gomes | Learning to program -difficulties and solutions[END_REF][START_REF] Koulouri | Teaching introductory programming: A quantitative evaluation of different approaches[END_REF][START_REF] Stefik | An empirical investigation into programming language syntax[END_REF] pertaining to the fact that using these languages in IP, based on their sole industrial merit, threatens attaining its EP final objective. Python is analyzed as it has been, in the last decade, the de facto choice of educators that wish to reconsider using Java/C/C++ (more in Sect. 4). Ada and Kotlin are also scrutinized in order to discuss whether they could be viable candidates to replace Java/C/C++ in IP so the latter may be taught in later years in the curriculum, when the students are no longer total beginners.

Industrial relevance

In this category, the weak candidates are, without a doubt, Ada and, to a lesser extent, Kotlin. Indeed, Java, C and C++ are known for being traditionally used in industry throughout the last decades, while Python is galloping when it comes to industrial popularity. For instance, the most recent survey of the Indeed job-application platform places these four languages among the top-five most demanded languages in industry 5 . (Another abundantly detailed survey with similar findings is available from StackOverflow 6 ). However, to be fair with the weak cadidates, Ada's and Kotlin's lack of popularity should not be mistaken for a total absence in industry as it is the case for languages specifically tailored for education such 5 https://uk.indeed.com/career-advice/career-development/coding-languages 6 https://survey.stackoverflow.co/2023/#most-popular-technologies-language as Eiffel and Pascal. Industrial relevance of both Ada and Kotlin is discussed next.

Ada has a long-term ongoing history with industrial critical domains worldwide 7 . For instance, the Ariane 4/5/6 rockets software was written in Ada, and the Systerel company 8 , a major actor of critical computing in France, regularly hires Ada experts. Moreover, the recent ESROCOS and ADE projects [START_REF] Muñoz Arancón | ESROCOS: Development and Validation of a Space Robotics Framework[END_REF][START_REF] Ocón | ADE: Autonomous DEcision making in very long traverses[END_REF], funded by the European Space Agency, heavily relied on Ada (within the TASTE toolbox [START_REF] Perrotin | TASTE: A real-time software engineering tool-chain overview, status, and future[END_REF]).

As for Kotlin, and since being announced as the preferred language for developing Android applications by Google in 2017, it gained significant popularity as other major companies such as Uber and Pinterest adopted it for purposes that go sometimes beyond mobile applications development [START_REF] Oliveira | On the adoption of kotlin on android development: A triangulation study[END_REF].

Educational benefits

We compare the six languages within five non-exhaustive criteria backed up with relatively recent scientific findings.

Anti-unlearning syntax.

As explained in Sect. 2.2.1, unlearning existing parts of cognitive structures has negative effects on beginners. The equal/assignment confusion is a famous unlearning side effect where a beginner would write e.g. if (x = 5){. . . } (instead of if (x == 5){. . . }) in C, C++, Java, Python or Kotlin thinking that the body of if will be executed only if x is equal to 5 (while, in reality, 5 is assigned to 𝑥 silently as the condition of if becomes a tautology). This issue seems to receive much less attention than it should, as Stefik and Siebert showed in a rigorous study [START_REF] Stefik | An empirical investigation into programming language syntax[END_REF]. In particular, the authors noticed that the double-equal sign was used correctly by beginners as little as any random sign such as the Bang (!) which the authors invented for their experiments (less than 2% used either sign as they should have). Stefik and Siebert concluded that "We understand all too well why many language designers historically made the choice of ==, but the impact on novices is clear". Moreover, in a more recent thorough study (data collected over more than 37 million compilations), Altadmri and Brown showed that the equal/assignment confusion ranked high in terms of both frequency (4 th ) and difficulty to fix (6 th ) among the 18 most common errors committed by beginners [START_REF] Altadmri | 37 million compilations: Investigating novice programming mistakes in large-scale student data[END_REF]. Another example of unlearning side effects is the 0 index in C, C++, Java, Python and Kotlin, frequently at the origin of the famous off-by-one error: students need to unlearn first being simply 1 st and replace it with first being 0 th . In general, the chosen language for IP must involve as little unlearning as possible, a criterion amply met by Ada. Contrary to the other languages under scrutiny, Ada has an anti-unlearning syntax: equal is =, whereas := (inherited from the educational language Pascal) is used for assignments, and the keywords ′ First and ′ Last are provided for arrays boundaries.

In sum, only Ada meets this criterion.

Simple syntax.

The chosen support language should have simple syntax, avoiding cryptic symbols [START_REF] Mannila | An objective comparison of languages for teaching introductory programming[END_REF] and "magic formulae" [START_REF] Meyer | The outside-in method of teaching introductory programming[END_REF]. C, C++ and Java use cryptic syntax (e.g. && for ∧ and || for ∨), that does not intuitively connect to universal mathematical notations (Sect. 2.2.1). Moreover, writing the first program in any of these languages requires beginners to use a "magic formula" which they will likely not understand before the next year, such as main (string [] args) in Java. Besides, these languages use semicolons the forgetting and misplacement of which are very common errors among beginners (in the top fifteen of most frequent errors according to Altadmri and and Brown's study [START_REF] Altadmri | 37 million compilations: Investigating novice programming mistakes in large-scale student data[END_REF]). Both Ada and Python enjoy simple and intuitive syntax: for instance, the English keywords and and or are used for the obvious corresponding logical operators, and writing the first program is magic formula free (e.g. in Ada the main program is simply a parameterless procedure). However, contrary to Python and Kotlin, Ada uses semicolons in a similar fashion as Java, C and C++. As for Kotlin, though it shares cryptic syntax with Java/C/C++, a program can be written easily in a magic-formula-free manner, and the language shares the easy use of line-breaks to end instructions with Python, with the extra simplicity of insensitivity to indentations.

In brief, Ada, Python and, to a lesser extent, Kotlin partially meet this. Java, C and C++ are the weak candidates.

Clear concepts of loop constructs.

The support programming language should concretize the understanding of the conceptual differences between a while and a for loop, acquired at the specification phase (Sect. 2.2.1). This is the case of Ada, providing a clear, unambiguous syntax for both loop constructs. The syntax of while is similar to that of C, but the for loop construct is different: for x in r do ... where 𝑥 is a variable and 𝑟 is a range, thus the instructions within the body of for are repeated for the whole range . In C/C++, the for loop simply does not exist, although a for construct is provided. Actually, the latter is a while construct written in a more compact way: for (inst1; cond; inst2) is a while loop preceded with instruction inst1, conditioned with the Boolean expression cond and incorporating inst2 as the last instruction in its body. This is surprising, and remarkably poor from a conceptual point of view: it promotes the misconception of both loops being similar, thus pushing the students to compare them [START_REF] Qian | Students' misconceptions and other difficulties in introductory programming: A literature review[END_REF]. Eventually, beginners that will deem for better than while will end up writing a for loop with a break (or even worse, a return) statement to solve a typical while-loop problem. In Java, things are even worse: the for loop (which is actually a while loop) is kept from C, and a foreach loop construct is introduced to implement a true for loop, but it is called also for (one can only imagine the confusion this creates in a novice student's mind). Python and Kotlin, on the other hand, share with Ada a clear and nice separation between both loop constructs.

To conclude, Ada, Python and Kotlin are excellent candidates w.r.t. this criterion, which neither Java, C or C++ meet.

Clear and rigorous concepts of subroutines.

The support language should concretize the distinction between subroutines with and without return values (learned at the specification phase, Sect. 2.2.4) in a rigorous manner. In Ada, the syntactical distinction is explicit: procedure (no return value) and function (one return value). In C, C++, Java, Python and Kotlin, it is the return type of the subroutine that makes the difference (though less intuitive in Python, where types are implicit). Syntactically, this is not a real plus of Ada. However, Ada's rigorous separation between procedures and functions becomes clearly advantageous at compile-time.

Let us illustrate with an example. Listing 1 shows the same erroneous student code in Ada (right, where 𝑥 has been declared integer earlier in the program) and Python (left). The student is trying to display 𝑥, update it with its factorial fact (x), then display 𝑥 again. However, he/she forgot to assign the return value of fact (x) to 𝑥 (line 3). The Python code compiles (as its equivalent in C, C++, Java or Kotlin would), while it does not in Ada with the compiler displaying "cannot use function fact in a procedure call" pointing to line 3. This is a rather dummy example, but it highlights a remarkably serious mistake (known as discarding/ignoring return values of non-void functions), ranked 1 st in terms of average time to fix (≥ 1000 seconds) in Altadmri and Brown's study [START_REF] Altadmri | 37 million compilations: Investigating novice programming mistakes in large-scale student data[END_REF] (referenced earlier in Sect. 3.2.1, 3.2.2). Such high average would be drastically reduced with Ada, as the error is caught by the compiler. While discarding return values in the remaining language candidates looks like a trivial matter (easily fixable at the compiler level), the historical choices made in these languages makes it tricky in practice. For instance, C++17 introduced the "no discard" attribute to explicitly denote that a method may not see its return value discarded. Evidently, this is an additional burden for a beginner student.

To summarize, Ada is the only candidate that satisfies this criterion.

3.2.5 Verification support. Finally, a good language for IP is also a language that promotes writing correct code [START_REF] Mannila | An objective comparison of languages for teaching introductory programming[END_REF] (which connects to specifying correct algorithms, Sect. 2.2.5). Ada is known for its strong typing and strict compiler, both promoting writing correct programs. One example on strict compiler benefits is the discarding/ignoring return values error, which only Ada catches at compiletime (Sect. 3.2.4). Let us now give an example on how strong typing can help catch errors at runtime. Consider the Kaprekar routine, where students store, in an array 𝐴, the digits of a number 𝑁 , then use them to perform some computations. A hard-to-catch mistake is when e.g. a two-digit number is put in one of 𝐴's cells. Ada's strong range subtyping can help. It suffices to write subtype Digit is Natural range 0..9; then define 𝐴 as an array of Digit, then, at runtime, if any instruction attempts to put a value outside of 0..9 in a cell of 𝐴, the execution stops with the message "constraint check failed", pointing to the culprit instruction. In contrast, range subtyping does not exist per se in C, C++, Java or Kotlin (despite some online projects that claim to implement it), which would entail, for e.g. the Kaprekar example, longer classic debugging through inserting print/printf statements. In Python, things are more complicated as the language uses a sort of implicit typing. Let us consider another example where a student is supposed to implement a function that computes the factorial fact (n) of a number 𝑛. Here, the fact function should implement its classical mathematical counterpart fact : N ↦ → N, that is fact is only defined for positive integers, and always returns a positive integer. In Ada, this is easily feasible through defining both the only parameter of the function and its return value as naturals:

function fact (n : Natural) return Natural A direct advantage of strong subtyping here is avoiding, by design, ill-typed instructions (for instance calling the function above with a negative integer) and return values outside of the function's range. But strong subtyping benefits go beyond this direct advantage. In this example, it allows for a rigorous mapping of a function, as a mathematical object at the specification phase, to a function, as a programming concept. To explain this, let us see how the C/C++ header of the same "function" would look like:

int fact (int n) But, strictly speaking, fact above is not a function to begin with (simply because it is not left total), contrary to the Ada implementation. For a novice programmer, using a language that allows precise mapping of high-level solutions (algorithms) and their mathematical foundations (e.g. functions) to programs promotes writing correct code. This is not the case in the other candidate languages, especially in Python because of the absence of explicit typing.

Strong (sub)typing put aside, Ada has solid foundations in program verification: its SPARK subset/toolset [START_REF] Gilbert | High integrity software: the SPARK approach to safety and security[END_REF]. C, C++, Java, and Kotlin verification support is more or less comparable to SPARK (e.g. the state-of-the-art KeY theorem prover for JavaCard [START_REF] Ahrendt | The key tool[END_REF]). As for Python, Nagini has been recently proposed [START_REF] Eilers | Nagini: a static verifier for Python[END_REF]. However, it requires a strictly typed version of Python, which clashes with the "simplicity" induced by the implicit typing philosophy of Python.

In fewer words, Ada is an ideal candidate under this criterion. C, C++, Java and Kotlin are more difficult to use to write correct code (due to typing/subtyping limitations), but they may be still fit thanks to their verification support. Python is the weak candidate due to the absence of explicit typing.

DISCUSSION & CONCLUSION

When it comes to choosing a programming language for IP, the CS education community has been long polarized with advocates of industry relevance opposed to those of educational benefits, and the former seem to have the wind in their sails. Many studies show that teachers first criterion to choose a language for IP is industry relevance, even before pedagogical suitability [START_REF] Davies | A snapshot of current practices in teaching the introductory programming sequence[END_REF][START_REF] Michael De Raadt | Language tug-ofwar: industry demand and academic choice[END_REF][START_REF] Mannila | An objective comparison of languages for teaching introductory programming[END_REF]. As a consequence, languages such as Java, C and C++ are still very popular in IP courses today, despite the recent ascension of Python. For example, and according to the most recent rigorous surveys that we could find on the most popular languages used to teach IP, Java and C appear among the top-three of such languages in the UK and Australia [START_REF] Mason | Language choice in introductory programming courses at Australasian and UK universities[END_REF] and Ireland [START_REF] Brett | A survey of introductory programming courses in Ireland[END_REF], and C is overwhelmingly dominant in IP courses in Portugal (according to a 2019-2020 data shared by public Portuguese universities and reported in [START_REF] Sónia | The old question: which programming language should we choose to teach to program?[END_REF]) and in Greece [START_REF] Avouris | Introduction to computing: a survey of courses in Greek higher education institutions[END_REF]. This is a sad state of affairs, as such choices are more dangerous than one may think (Sect. 1, Sect. 3). It is thus perhaps about time to revisit the "industry-relevance-first" choice, and reserve these languages for teaching programming at more advanced levels (second-year students and above). With the rise of Python, it is now clearer than ever that to avoid a never-ending war (in which "the loudest professors always win" [START_REF] Jenkins | The first language -a case for Python?[END_REF]), the right posture to adopt must be more flexible: both educational and industry relevance are important [START_REF] Michael De Raadt | Language tug-ofwar: industry demand and academic choice[END_REF]. Perhaps, Python is slowly conciliating the two extremes as it is both gaining popularity in industry and regarded as education friendly [START_REF] Mason | Trends in introductory programming courses in Australian universities: languages, environments and pedagogy[END_REF], but the case is not yet closed. First, besides its advantages that our analysis confirms to some extent, Python is still far from being the ideal, undebatable replacement as we have shown through the same analysis. Second, the fact that Java/C/C++ are still widely used in IP courses, as detailed above, attests to the lack of unanimity regarding the trend of switching to Python.

Our category-based analysis on educational fitness (Sect. 3.2) shows a clear advantage of Ada, followed by Python, and to a lesser extent Kotlin, with C, C++ and Java lagging behind. The analysis is not exhaustive, but still covers fundamental criteria of educational fitness, long-established by educational psychologists (e.g. categories one, Sect. 3.2.1 and two, Sect. 3.2.2) and/or crucial to avoid the underlying misconceptions of the most tenacious mistakes of first-graders reported in rigorous research (e.g. category four, Sect. 3.2.4). Ada's educational superiority over Python and Kotlin, mainly stemming from its anti-unlearning syntax, strong typing and strict compiler, is contrasted with an industrial relevance that seems to be tied to critical applications (Sect. 3.1), making it the less desirable language form an industry-relevance angle especially with the exploding popularity of Python (and the rising one of Kotlin). While our positive observations on Python are corroborated by Koulouri et al.'s rigorous analysis [START_REF] Koulouri | Teaching introductory programming: A quantitative evaluation of different approaches[END_REF], we did not find any work that includes Ada as a first language candidate (except for a couple of over 30-year-old publications [START_REF] Thomas | Ada as a CS1-CS2 language[END_REF][START_REF] Leon | Ada in CS1[END_REF]), although the language is used, at least in a number of French universities, to support IP courses. As for Kotlin, its timid to non-existent appearance as an IP candidate in previous research is probably due to it being the youngest among our candidates. Yet, according to our criteria, it is still noticeably behind Ada (educational-fitness-wise) and Python (industry-relevance-wise). Perhaps, we could sum up accordingly the takeaway of our analysis in the three following conclusions:

(1) Java/C/C++ should be avoided in IP courses, (2) the trend of using Python, while somewhat justified, is clearly debatable and (3) Ada, and perhaps Kotlin, should receive more attention as potential candidates (the former might have been discarded too quickly, and it might be about time to start considering the latter).

At this stage, we would also like to (re)emphasize the context in which our analysis remains valid. As explained in Sect. 1, the objectives of the IP course are a crucial parameter toward electing a first language. In other words, the way we, educators, "split" learning objectives between IP and higher-level programming courses is a determining factor for choosing the first language. Our analysis is carried out with, in mind, a broadly brushed final objective of forming expert programmers (Sect. 1, Sect. 2), with the hope that its results remain in line with the smaller objectives resulting from the decomposition of the eventual one. Similarly, and in a closely connexe scope, the choice of the first paradigm is equally important and may greatly influence the usefulness of our analysis. This is, however, out of the scope of this paper where we assume a procedural-first approach, without any intention, nevertheless, to minimize the importance of the first-paradigm dilemma.

As explained in the introduction, this paper is not about personal opinions, it rather seeks triggering discussions based on scientific evidence. The three overall conclusions above are thus meant to set some flexible bases for such discussions. We wrap up therefore with the following questions to serve as stimulating headlines:

• Are we ready, as educators, to keep taking the risk of thinking in terms of "industrial relevance first" and thus using languages such as Java, C and C++ to teach IP knowing their serious educational drawbacks? • If no, how do we define a balance between industrial popularity and educational advantages? • Does Python realize this balance despite its implicit typing, porous compiler and unlearning-friendly syntax? • Is Ada a viable candidate even with a rather poor industrial relevance? • Could Kotlin be envisaged as a serious candidate regardless of its unfriendly syntax and yet-to-be-proven industrial prosperity? What about other modern languages like Rust?

Figure 1 :

 1 Figure 1: The programming problem.

1 x = 5 2

 5 print("the factorial of", x) 3 fact(x) 4 print("is", x) 1 x:= 5; 2 Put("the factorial of" & Integer'Image(x)); 3 fact(x); 4 Put("is" & Integer'Image(x)); Listing 1: Discarding/ignoring return values of non-void functions in Python (left) and Ada (right)

IP can be viewed as CS1 + CS2, but we prefer to clearly define what it is in order to avoid the possible confusion the latter acronyms may entail[START_REF] Hertz | What do "CS1" and "CS2" mean? Investigating differences in the early courses[END_REF].

References on the popularity of these languages in IP courses are further detailed in Sect.[START_REF] Muñoz Arancón | ESROCOS: Development and Validation of a Space Robotics Framework[END_REF]

https://www.insa-toulouse.fr (in French).

It is perhaps noteworthy to mention that, in a purely historical context, Friedman presented an organization structurally similar to Fig.1using a ladder[START_REF] Weiser Friedman | From Babbage to Babel and beyond: A brief history of programming languages[END_REF] (yet different in content, as it had nothing to do with teaching).

See e.g.[START_REF] Magel | Revisiting the Impact of the Ada Programming Language[END_REF] and https://www2.seas.gwu.edu/~mfeldman/ada-project-summary.html

https://www.systerel.fr/en/

ACKNOWLEDGMENTS

Special thanks to Didier Le Botlan (INSA Toulouse) who, thanks to his substantial efforts, both on the pedagogical and technical fronts, as well as the constructive role he played in our passionate debates (mostly ending in agreements), greatly inspired this paper. We also thank Aldric Degorre (Université Paris Cité/IRIF) for his valuable insights on Kotlin.


Pol Hamon

Loic Michel

Franck Plestan

Damien Chablat

Model-free based control of a gripper actuated by pneumatic muscles 1

Keywords: Grasping system, pneumatic muscle, model-free control

In this article, a model-free based control strategy is applied to a gripper activated by Mckibben's pneumatic muscles. The gripper is composed of three fingers and is based on an original mechanical design to grip a large range of objects (by a weight, size, form, ... point-of-view). A model-free based control strategy is proposed to manage the force control phases. An experimental setup is introduced to experimentally test and validate the proposed control strategy using a very simple setup composed of a single force sensor, an embedded electronic board, and a single pressure proportional solenoid valve.

Introduction

One of the great challenges of industrial robotics is to manipulate safely a large number of objects with varied and complex shapes and di↵erent masses. For this reason, a new underactuated hand has been developed [START_REF] Hamon | A new robotic hand based on the design of fingers with spatial motions[END_REF], each finger being mechanically designed to be adaptable to a large range of objects. Nowadays, no other under-actuated finger uses a spherical parallel joint at the base of the finger to provide abduction movement [START_REF] Birglen | Underactuated robotic hands[END_REF]. This allows to switch easily between cylindrical and spherical grasping. The original design of the fingers is unique to the authors; actually, no other author uses a spherical parallel joint at the base of the finger to provide abduction movement. To actuate this new mechanical architecture, pneumatic muscles have been chosen since the coupling between pressure, contraction, and e↵ort can be advantageous to achieve under-actuated gripping [START_REF] Birglen | Underactuated Robotic Hands[END_REF]. Furthermore, the high e↵ort-mass ratio of pneumatic muscles is an interesting feature when an object is grabbed. Notice that motion-pressure nonlinearities are advantageous to ensure the stability of the e↵orts between the fingers applied on the object [START_REF] Kalita | A review on the development of pneumatic artificial muscle actuators: Force model and application[END_REF].

The transition from free fingers motion to holding the object is intuitive. There are two very di↵erent situations, which use two kinds of feedback: proprioception and touch. In the human case, the vision allows anticipating the transition between these two situations. In the current work, it is stated that there is no visual information; an intuitive blind grasp has to be recreated. Sensors based solutions have been proposed in [START_REF] Sgarbi | Grab system actuated by a servo motor[END_REF][START_REF] Xu | Design and smooth position/force switching control of a miniature gripper for automated microhandling[END_REF], switching between the motion phase and the grasping phase. However, these solutions introduce the problem of reliable and responsive contact detection; as an example, in [START_REF] Birglen | Kinetostatic analysis of underactuated fingers[END_REF], fuzzy logic is used for a smooth transition between the two sensors.

The solution introduced in the current paper introduces an alternative to this problem by using a well-matched reference trajectory. Indeed, a solution for a gripper including force control without contact detection is proposed.

As previously mentioned, the gripper under interest is actuated by a Mckibben pneumatic muscle. Few contributions have been made about the control of pneumatic artificial muscles (PAM) used as actuators [START_REF] Takosoglu | Determining the static characteristics of pneumatic muscles[END_REF][START_REF] Tondu | Modelling of the mckibben artificial muscle: A review[END_REF] for a finger. Standard Ziegler-Nichols method has been proposed in [START_REF] Takosoglu | Angular position control system of pneumatic artificial muscles[END_REF] to tune a PID position controller. Similarly, a PID controller tuned by the Simulated Annealing method has been considered in [START_REF] Sca↵ | Pneumatic artificial muscle optimal control with simulated annealing[END_REF] regarding a positioning system. In [START_REF] Godage | Dynamic control of pneumatic muscle actuators[END_REF], an experimental PID control based on a specific hysteresis model has been proposed. Such strategies require the identification of a model: thus, self-identification-based control using neural networks has been proposed in [START_REF] Thanh | Nonlinear pid control to improve the control performance of 2 axes pneumatic artificial muscle manipulator using neural network[END_REF][START_REF] Huy | Online tuning gain scheduling mimo neural pid control of the 2-axes pneumatic artificial muscle (pam) robot arm[END_REF][START_REF] Zhao | Position control of a pneumatic muscle actuator using rbf neural network tuned pid controller[END_REF][START_REF] Zhong | A new approach to modeling and controlling a pneumatic muscle actuator-driven setup using back propagation neural networks[END_REF]. A recent contribution to illustrate the feasibility of a positioning system using a grey-box-based identification modeling using neural networks and sliding mode control in real-time applications has been proposed in [START_REF] Ba | An integrated intelligent nonlinear control method for a pneumatic artificial muscle[END_REF].

In this paper, the objective is to design a control strategy for the gripper requiring a very reduced e↵ort for the identification process. Furthermore, it is necessary to get a su cient robustness versus the mass and shape of the objects. So, a model-free based e↵ort control is selected. Based on authors' previous work [START_REF] Hamon | Control of a gripper finger actuated by a pneumatic muscle: new schemes based on a model-free approach[END_REF], a model-free control strategy [START_REF] Fliess | Model-free control[END_REF] is proposed to solve the problem of controlling the motion of a gripper actuated by pneumatic muscles, for grasping a wide variety of di↵erent objects, while limiting the identification process. The model-free control approach [START_REF] Fliess | An alternative to proportional-integral and proportional-integral-derivative regulators: Intelligent proportional-derivative regulators[END_REF] can be considered as an alternative to the standard PI and PID controls; it does not require any prior knowledge of the plant, and it is straightforward to tune. Its usefulness has been demonstrated in many situations through successful applications (for details, see [START_REF] Bara | Toward a model-free feedback control synthesis for treating acute inflammation[END_REF][START_REF] Fliess | Model-free control[END_REF][START_REF] Hamiche | Bullwhip e↵ect attenuation in supply chain management via control-theoretic tools and short-term forecasts: A preliminary study with an application to perishable inventories[END_REF]). In particular, some applications to mechanical systems have been dedicated to the control of quadrotor position [START_REF] Bekcheva | Cascaded model-free control for trajectory tracking of quadrotors[END_REF][START_REF] Younes | Model-free control of a quadrotor vehicle[END_REF], control of machine tool positioning systems [START_REF] Villagra | Model-free control for machine tools[END_REF], position control of a cable-driven parallel robot [START_REF] Sancak | Position control of a fully constrained planar cable-driven parallel robot with unknown or partially known dynamics[END_REF], or control of electro-active polymer actuators [START_REF] Sancak | Force control of electro-active polymer actuators using model-free intelligent control[END_REF]. Notice that this kind of control approach is computationally e cient, easily deployed even on small embedded devices, and can be implemented in real-time since it requires very light computations. One additional novelty of the present study lies in the utilization of a non-hybrid control law, which eliminates the need for contact sensors or position sensors on every joint. Instead, it relies on a single e↵ort feedback measurement. This approach capitalizes on the significant nonlinear characteristics exhibited by the e↵ort and displacement dynamics of the pneumatic muscle. As a result, it enables the gripper to reach a stable position without requiring prior knowledge of the object's shape. In summary, the main contributions and novelties of this work can be summarized as follows.

• The mechanical characteristics of the gripper, specifically the spatial displacements of the fingers (flexion and abduction), as well as its actuation through the utilization of pneumatic muscles.

• The adoption of a non-hybrid control structure that eliminates the need for contact detection.

• The implementation of a model-free based control approach that necessitates only a minimal amount of modeling knowledge, thereby reducing the requirement for an extensive identification process.

The novelty of this mechanical gripper design primarily lies in its finger spatial displacements, which are accomplished using a single actuator powered by a pneumatic muscle [START_REF] Hamon | A new robotic hand based on the design of fingers with spatial motions[END_REF]. This single actuator is capable of controlling both the flexion and abduction movements of the fingers. Another notable innovation is the utilization of a single valve to regulate the pressure injected into the three muscles. This design assumes that the gripper naturally reaches a mechanical equilibrium point that enables it to securely grasp and hold objects. The paper is structured as follows. Section 2 states the control problem during grasping tasks, especially the design of a unique reference trajectory without formal contact detection. In Section 3, principles of model-free control are recalled. Section 4 presents the experimental setup, which is composed of a hand with three fingers actuated by three pneumatic muscles, as well as experimental results and discussion.

2. Description of the system and control problem statement 2.1. Mock-up of three-fingers hand Figure 1-left presents a mock-up of the under-actuated 12 degrees of freedom robotics hand with three under-actuated fingers [START_REF] Hamon | Conception et contrôle d'un préhenseur sous-actionné pour la saisie d'objets complexes[END_REF]. The proximal phalange is formed by the two opposite bars of the spherical parallel mechanism represented in yellow, and the middle and distal phalanges are represented in orange and red, respectively. Two 4-bar mechanisms represented in blue and green allow the transmission of the movement produced by the pneumatic muscle on the phalanges. Each finger performs spatial motions to achieve more complex and varied grasping than the existing planar-movement fingers and is actuated by one pneumatic muscle. The purpose of this hand is to grasp a wide range of complex-shaped objects at the exit of machining centers, the objects being of di↵erent sizes, shapes, and weights. Its kinematics allows these properties (for details, the reader can refer to [START_REF] Hamon | Conception et contrôle d'un préhenseur sous-actionné pour la saisie d'objets complexes[END_REF]).

The main industrial objective guiding the design of this hand is linked to ensured and safe grasping. The industrial application does not require fast grasping to preserve the quality of the surface. Furthermore, the industrial context requires constraints on sensors (low price, reduced number, ...). Notice that the wide range of objects induces the design of a robust control strategy in order to have no tuning procedure for each part. Furthermore, given the di culty to get a control-oriented modeling of the system, a so-called model-free controller is designed in the sequel.

The paper is a first step to validate the gripper model free based control; thus, the control design is made under some hypotheses:

• Assumption 1. A similar control is applied to the three muscles (and then, to the three fingers). As a consequence, the velocity of the motion of each finger is consequently the same during the approach phase with the object;

• Assumption 2. Only one finger is equipped by a force sensor, this latter sending the single measurement to the controller;

• Assumption 3. The contact with the object is made at the same time for the three fingers.

Closing and opening phases

The description of the di↵erent phases of a gripping cycle with the gripper displayed in Figure 1-left is presented in the sequel (see Figure 1-right); these phases allow first to grasp the object, then to release it.

Closing control phase

Close and lifting

Opening « open loop » phase

Lifting phase

Figure 1: Left. Kinematics of the under-actuated gripper architecture with a spherical parallel mechanism [START_REF] Hamon | Conception et contrôle d'un préhenseur sous-actionné pour la saisie d'objets complexes[END_REF].

Right Phases for grasping/releasing an object.

• Phase 1. There is no contact. The objective is to generate a motion of the three fingers to obtain contact with the object; the goal is to achieve a given force when contact between the fingers and the object appears. However, during this phase during which there is no contact, it is not possible to act on the force. The challenge is to define a reference trajectory allowing to reach a given force, at a contact time unknown a priori and with a constant zero force during all the phases. This reference trajectory which is a key point of the control strategy will be detailed in the sequel.

• Phase 2. The contact is established. The objective is then to control the contact force in order to maintain the object in the hand2 .

• Phase 3. The support of the object is removed; the grasping has to keep the object maintained by opposing the gravity force. In this phase, the force control must be robust given the variation of gravity force.

• Phase 4. The gripper is opened. As a consequence, the contact is broken. A specific strategy is applied to limit the velocity of the fingers, the aim being to reduce the risk of collision with other objects.

A unique reference trajectory for phases 1, 2 and 3

The objective is the design of a reference trajectory allowing, without formal contact detection, to track a unique trajectory over Phases 1, 2, and 3. The interest of a single reference trajectory without contact detection is the continuity of the trajectory; furthermore, contact detection can be tricky due to the presence of noise on low-cost sensors and could induce a back-and-forth between Phases 1 and 2. In fact, the reference trajectory definition and the control problem must take into account several constraints:

• the trajectory is unique for pre-contact (Phase 1) and contact phases (Phases 1 and 2) and no formal detection is made;

• the velocity of the fingers tips must be limited in order to limit the overshoot when the desired force is obtained. The overshoot limitation is important to ensure a safe grasping of the object;

• during the pre-contact phase (Phase 1), the system is not controllable given that there is no contact, hence the force keeps zero during the motion.

Denote y ⇤ the desired force and y r the reference trajectory that are defined through a precompensator (see Figure 2) and reads as

y r = (1 K (t))y ⇤ + Ky (1)
with y the measured force applied to a single fingertip. The function (t) is a monotonically increasing continuous one defined such that (0) 0 is small and (t ! 1) = 1. The parameter K is such that 0 < K < 1. Denoting e = y r y the tracking error and recalling that y (the measured force applied to a fingertip) keeps 0 between the initial and contact times, one has • for t = 0, (0) = 0, y = 0, then e = y ⇤ ;

• for 0 < t < t c with t c being the first contact instant, then

e = (1 K (t))y ⇤ (2)
In this case, the tracking error is naturally decreasing as (t) is increasing. Notice that the control still has no action on the tracking error given that there is no contact, i.e. y = 0 for all t 2 [0, t c ), but this strategy reduces the error. It will allow a lower magnitude of the control at the contact time, a lower contact velocity between the fingertips and the object, hence a reduced force overshoot.

• for t t c , the tracking error reads as

e = (1 K (t))y ⇤ (1 K)y (3)
Given that (t) converges to 1, it yields e = (1 K) • (y ⇤ y). So, the control forces e towards 0, inducing y ! y ⇤ .

Figure 2 summarizes the closed-loop scheme with the desired trajectory y ⇤ as input. The reference trajectory y r is computed by the precompensator (1). The force y, defined as the output of the system, is measured and controlled via the control board system. A single proportional pressure valve (see details in Section 4) allows injecting a controlled pressure, driven by the control board, inside the three pneumatic muscles.

About the controllability of the force

As shown in Figure 2, the proposed control system of the fingers is based on a closed-loop for which the purpose is to control the contact force with the object. A particularity of this system is that the measured force y equals zero during Phase 1 since the fingers move to hang the object. From the control point of view, it highlights the fact that the system is not controllable during Phase 1, since the control input has no e↵ect on the output y.

Furthermore, the definition of reference trajectory y r consists in imposing progressively a pressure to the muscle in order to create a smooth contact with the object and allows "switching" the control law between Phases 1 and 2.

Control design based on model-free approach

As previously introduced, the objective is to propose a new control scheme that requires a very reduced e↵ort for the identification/modeling while keeping high performances in terms of accuracy and robustness. A solution is the so-called "model-free control" approach that is detailed in [START_REF] Fliess | Model-free control[END_REF]. The corresponding "intelligent" controllers are much easier to implement and tune than PID controllers, which are now the main tools in industrial control engineering (for example, see [START_REF] Åström | Feedback Systems[END_REF]).

The ultra-local model

The main ideas of model-free control are explained in the sequel. This approach is based on an ultra-local model in the sense that it is well-adapted during a very short time. From this ultramodel, a linear controller is designed. A key point is the capability of the controller to be adapted to the evolution of this ultra-local model given that very reduced information on the system is required.

Consider that the dynamic modeling of the plant3 is made by a following first order ultra-local model which reads as ẏ = F + ↵u

where

• y and u are respectively the control and output of the system;

• the term F includes all the nonlinearities, disturbances, uncertainties, ...;

• ↵ 2 R is a constant chosen by the practitioner such that ẏ and ↵u are of the same magnitude. Therefore, ↵ does not need to be precisely estimated.

As previously mentioned, equation ( 4) is only valid during a short time-lapse, hence the ultra-local term that must be continuously updated.

Control design

As a trivial introduction, supposing that F is perfectly known and considering the following

controller u = F ẏr ↵ K p e (5)
where y r is the output reference trajectory (assumed to be well-known), e = y y r is the tracking error, and K p > 0 is a tuning gain4 , then the closed-loop system behavior is governed by the following equation ẏ = ẏr ↵K p e

that gives ė = ↵K P e. However, F is unavailable; considering another control strategy is then required. A solution called "intelligent" digital P -controller [START_REF] Fliess | Model-free control[END_REF] can be derived. To make an accurate analysis and given that the control law will be implemented in discrete time, a discrete version of the control input is considered in the sequel. Defining the sampling time h and t k = k • h being the k th sampling time at which the control and output are updated, the discrete version of (5) reads as

u k = F k 1 ↵ + 1 ↵ y r | k h K p e| k (7)
with y r | k = y r k y r k 1 and e| k = y k y r k the tracking error between the measurement y k and its reference trajectory y r k at t = t k . The unknown term F k 1 is estimated as described in the sequel from the previous measurement y k 1 and the control output u k 1 . Indeed, an approximation of the ultra-local model (4) at t = t k 1 reads as (with

y| k 1 = y k 1 y k 2 ) 1 h y| k 1 = F k 1 + ↵u k 1 (8)
and gives

F k 1 = 1 h y| k 1 ↵u k 1 (9)
Substituting ( 8) into ( 7) leads in the direct transposition of ( 5) into the discrete time domain that reads

u k = 1 ↵ ✓ 1 h y| k 1 ↵u k 1 ◆ + 1 ↵ y r | k h K p e| k (10)
that gives

u k = u k 1 1 ↵ ✓ y h k 1 y r h k ◆ K p ( y| k y r | k ) (11)
Regarding the implementation purpose, equation ( 11) is rewritten as

u k = u k 1 1 ↵h y| k 1 y r | k K p ( y| k y r | k ) ( 12
)
where 1 ↵h adjusts the weight of the derivative / anticipation part while K p adjusts the weight of the proportional part. This proportional part acts as the main "amplification" that forces the asymptotic error reduction; both parameters are involved in the transient dynamic behavior which can be slightly accelerated using a higher anticipation, while keeping lower gain K p prevents from entering into saturation or unstable behavior. The convergence behavior of the closed-loop system can be established as described in the sequel. Considering the ultra-local model [START_REF] Takosoglu | Determining the static characteristics of pneumatic muscles[END_REF]

at t = t k y h k 1 = F k 1 + ↵u k 1 (13)
One gets

u k 1 = 1 ↵ ✓ y h k 1 F k 1 ◆ (14)
Replacing ( 14) in [START_REF] Sca↵ | Pneumatic artificial muscle optimal control with simulated annealing[END_REF], one gets

u k = 1 ↵ ✓ y h k 1 F k 1 ◆ 1 ↵ ✓ y h k 1 y r h k ◆ K p (y| k y r | k ) (15)
Multiplying ( 15) by ↵ gives

↵u k = F k 1 + y r h k ↵K p (y| k y r | k ) (16)
Since (from ( 8)) one has

↵u k = y h k F k , (17)
one gets

y h k F k = F k 1 + y r h k ↵K p (y| k y r | k ) ( 18
)
that gives

y h k y r h k = (F k F k 1 ) ↵K p (y| k y r | k ) ( 19
)
Assumption 4. The ultra-local model is valid only over a very short time during which the perturbation is such that

F k ⇡ F k 1 .
From this latter assumption and ( 19), it implies that the error e converges towards 0. Notice that,

• as previously discussed, both ↵ and K p are associated to the dynamic rate of the convergence;

• the previous assumption requires a relatively small sampling period.

Remarks.

• The presence of u k 1 in the definition of u k allows, by an indirect way, to take into account the unknown term F k 1 .

• The control law (12) requires a numerical time derivation of y. Its estimation is made using a di↵erentiator based on the Euler methodology. Consider the following assumption Assumption 5. The output y (that is, in this work, the force applied to the tip of one finger) is di↵erentiable.

• To manage both phases, the reference trajectory should be chosen smoothly given the presence of the derivative of y r (t) in [START_REF] Godage | Dynamic control of pneumatic muscle actuators[END_REF].

Experimental setup for a prototype three-finger gripper

This section is devoted to the application of a model-free based control strategy to spatial kinematics of under-actuated fingers developed for spherical and cylindrical grasps. This kinematics is characterized by the integration of a spherical parallel mechanism in the proximal phalanx [START_REF] Hamon | A new robotic hand based on the design of fingers with spatial motions[END_REF] and generalizes the work on the under-actuated fingers [START_REF] Birglen | Underactuated robotic hands[END_REF]. This solution (see Figure 1) provides non-planar behavior in relation to the abduction movements of the human hand and thus a change in the type of grasping. Some features have to be mentioned (for details, see [START_REF] Hamon | Conception et contrôle d'un préhenseur sous-actionné pour la saisie d'objets complexes[END_REF])

• each finger has four degrees of freedom which are not directly controlled by the actuator, whose behavior depends on the contact between the fingers and the object;

• all joints are passive without angular position sensors, except for the prismatic joint that operates with a Mckibben pneumatic muscle. Small torsional springs are placed on the passive joints in order to return to the home position.

• to decrease the number of elements, the smallest number of fingers is used to take spherical and prismatic objects. So, the robotic hand is composed of three under-actuated fingers whose placement is defined to reach the two types of handles: prismatic and spherical.

Model-free control strategies apply very well to this type of mechanism because it is a hard task to model the dynamic behavior of the under-actuated fingers as well as the interactions between the fingers and the object (the contact points between the object and the phalanges are not known). Furthermore, the actuation choice based on pneumatic muscles increases the modeling challenge, as these actuators are highly nonlinear and uncertain. The experimental setup is displayed in Figure 3, and its main elements begin detailed in the sequel.

Pressure proportional valve

The control signal (see Figure 2) is sent to a FESTO VPPE5 pressure proportional solenoid valve that transmits pressure to the three Mckibbens muscles of the hand (DMSP AM-CM 10 130N6 ). The valve is controlled by a 4 20 mA signal with 2700 resolution points. The use of this type of valve makes it possible not to use PWM in the control and thus not to stress the muscle in frequency.

Contact forces measurement

In this paper, the measurement system has been integrated into the distal phalange (see Figure 4) of a single finger. The force relationship applied by the three fingers on the object depends on the shape of the object. Given that, in the case study, the shape is unknown, a single control is applied to the three fingers and a single contact information is available, it is necessary to consider only symmetrical objects. Future works will study the case of asymmetrical objects that will have consequence on the control scheme.

Recall that the force measurement is not operating during Phase 1 given that there is no contact between the fingertip and the object. Concerning the measurement system, for the mechanical stability of the contact surface, two FSR force sensors (IE FSR X 402) are used between the polymer/aluminum contact surface and the finger (Figure 4). These two sensors return 0-5V analog signals that are summed to obtain the contact force signal. The latter is filtered using a standard Butterworth filter 20 Hz-fourth order.

Experimental results and discussion

The ability to forcefully control the gripper is tested in various grip configurations, as presented in the literature with an egg [START_REF] Birglen | Underactuated robotic hands[END_REF]; thereafter, only Phases 1-3 are considered. Notice that the object is placed on a support that is removed once the grip is over. The coe cient ↵ has been tuned as 2.5.10 7 , which allows a reasonable dynamics for the pressure and the force. The coe cient K p = 8.10 3 has been chosen in order to avoid control saturation while keeping good static/dynamic performances. The coe cient K may slow down the closing of the hand in order to avoid a strong overshoot of the force that increases at the contact instant between the finger with the object (see Section 4.5 for a more detailed study of the precompensator characteristics). Concerning the reference trajectory (1), the arbitrary choice K = 0.83 has been made mainly to limit the overshoot while keeping good performances in terms of accuracy and response time. Finally, the function (t) reads as

(t) = 1 1 + e (t t 0 ) (20)
with = 1 and t 0 = 0.15 sec. Remark that the definition (20) of (t) fulfills (0) 0 and small, (t) monotonically increasing continuous and (1) = 1.

• Scenario 1 (Figure 5) : The object is entered with a spherical grip. To allow a full grip, the e↵ort is set to 15N and the object support is removed around 27 sec.

• Scenario 2 (Figure 6) : The object is captured with a prismatic grip; as with the previous case, the e↵ort is set at 15N and the coin support is removed around 32 sec.

• Scenario 3 (Figure 7) : An egg is grasped by the three fingers with a force of 8N and the coin support is removed at 19 sec.

Taking into account the friction coe cient between the finger and the object, the value of 15 N is considered su cient to hold any objects less than 500 g, within the range of available pressures. For a fragile object like egg, that force is reduced to 8 N . This value is set by the user as the control reference thanks to the knowledge of the object properties. In Figures 5, 6 and7, the contact is indicated by a red dotted vertical line whereas the removal of the object support7 is indicated by a black dotted vertical line. Each scenario shows that

• during Phase 1, the fingers are moving until contact with the object is made. Indeed, the pressure injected in the muscles is linearly increasing according to the time whereas the tracking error is decreasing and y keeps 0; • once the contact with the object is established (Phase 2), the pressure still increases to ensure accurate tracking between the force and its reference. During this phase, the underactuated fingers reach a position of stability [START_REF] Hamon | A new robotic hand based on the design of fingers with spatial motions[END_REF] and create a grip of the object (shown by the next item, i.e. with the removal of the object support).

• grasping the object is illustrated with Phase 3 during which the object is maintained in the fingers while the support is removed. Figures 5-6-7 show that the force can either increase or decrease depending on the reactions applied to the object according to its geometry, which illustrates, in these cases, the benefits in using a model-free based control law.

In all three cases, the disturbance created by the removal of the support is rejected. The control shows good tracking of the reference when the object is in a free grip (without support). Notice that the low rigidity of the prototype limits a finer analysis of the results because the contact between the finger and the object is dampened and it is not possible to transmit significant forces. These first tests highlight the feasibility of the proposed approach and the relevance of the control architecture.

Repeatability and experimental asymptotic stability

The long-term stability of the grasping phase is experimentally studied, as well as the repeatability of the experiments. Figure 8-left illustrates the long-term stability of the measured force when the object is not moving. Due to the sensor drift, the hysteresis e↵ect in the muscles, and the resulting force on the "measuring finger" (as a combination of the other forces applied to the object whose shape is unknown), the pressure injected into the muscles may vary to track the constant desired force, despite all nonlinear e↵ects. To complete the experiments, Figure 8-right illustrates some tests that have been carried out (10 similar tests over 200 sec) to highlight some properties of repeatability of the force tracking e ciency despite di↵erent initial conditions/calibration of the force sensor.

About the performances of the precompensator

To highlight some properties of the precompensator, a study of the step response according to a set of values of the precompensator gain K (see equation 1) has been carried out, based on Scenario 1. The objective is to estimate the influence of K on the closed-loop system performance by the evaluation of certain standard parameters such as the overshoot, the static error, and the response time. Table 1 presents the results for K = {0, 0.5, 0.9}. The evaluation of the static error has been made on the time interval t 2 [100, 200] sec.

The precompensator is acting during the closing phase of the hand, the objective being to mitigate the contact force when the contact occurs, as detailed in Section 2.3. The main advantage of the precompensator is to slow down the approaching phase and the gain K allows adjusting the corresponding speed. The results presented in Table 1 show that the overshoot of the contact force is significantly damped if the gain K is large (K = 0.9). From (3), it can be explained by the fact that, the larger the gain K, the smaller the error e, and the less aggressive the controller is. However, it can be noticed that the closed-loop system allows better accuracy and a smaller response time when K is small (ideally K = 0, but with a huge overshoot). As previously, it can be explained from (3) that the tracking error e is larger when K is larger, inducing a more aggressive controller.

Conclusions and future work

In this paper, a model-free control has been applied to a control scheme of a gripper composed of three fingers, each of them being actuated by a pneumatic muscle. The control scheme is based on a model-free approach and is using a reference continuous trajectory allowing to have no formal contact detection. Furthermore, no sophisticated model of the system, no knowledge of the object (except for the fact that it is symmetrical), and no trajectory planning are required. The experimental results demonstrate the feasibility and e↵ectiveness of the proposed approach. The main work to come concerns the design of a multivariable control scheme to separately control the three fingers in order to guarantee the mechanical stability even for asymmetrical objects. This class of control could allow for more e cient capture of a larger class of objects. Another future work is the use of robust control strategies that do not require models (for example, adaptive sliding mode control) in order to improve the tracking performances. Other gripping systems considering other shapes of objects as well as the installation of the gripper on a robotic arm will be investigated in further works.

Figure 2 :

 2 Figure 2: Closed-loop scheme including a pre-compensation of the desired trajectory: y is the measured force, y ⇤ is the desired reference trajectory, and yr is the reference trajectory defined by (1).

Figure 3 :

 3 Figure 3: Photo of the whole experimental setup with an STM32 Nucleo board, a pressure proportional valve, and the gripper.

Figure 4 :

 4 Figure 4: Integration of force sensors on the distal phalange.

Figure 5 :

 5 Figure 5: Scenario 1. Left top. Desired (yellow) and real (black) forces (N ) versus time (sec). Left bottom. Pressure (bar) versus time (sec). Right. Photo of the experimental set-up with a spherical grip.

Figure 6 :

 6 Figure 6: Scenario 2. Left top. Desired (yellow) and real (black) forces (N ) versus time (sec). Left bottom. Pressure (bar) versus time (sec). Right. Photo of the experimental set-up with a prismatic grip.

Figure 7 :

 7 Figure 7: Scenario 3. Left top. Desired (yellow) and real (black) forces (N ) versus time (sec). Left bottom. Pressure (bar) versus time (sec). Right. Photo of the experimental set-up grasping an egg.

Figure 8 :

 8 Figure 8: Left. Long-term experiment to verify the asymptotic stabilization of the grasping -Force (N ) versus time (sec). Right. 10-time experiments to highlight the e ciency and the repeatability of the grasping -Force (N ) versus time (sec).

Table 1 :

 1 Gain K Overshoot (%) Static error e(1) (N) t r5% (sec) Control performances according to the gain K.

	0	25.67	0.0020	8.09
	0.5	8.09	0.0410	13.02
	0.9	7.48	0.1386	36.47

A preliminary version has been published in the proceedings of 9 th IFAC Symposium on Mechatronic Systems, Los Angeles, California, USA,

Recall here the assumption of the above section: the contact of each finger with the object is supposed to be active at the same instant. Hence, the force measured by the dedicated finger is related to the velocity of the approaching phase as well as the equilibrium point of the resulting forces that are distributed among the fingers during the phase of contact.

For sake of simplicity and clarity, the system is supposed to be a SISO (single-input single-output) one.

Practically, ↵ and Kp can be tuned following e.g. the proposed procedure described in[START_REF] Novel | A mathematical explanation via "intelligent" pid controllers of the strange ubiquity of pids[END_REF].

Data-sheet: https://www.festo.com/tw/en/a/8114536/

Data-sheet: https://www.festo.com/media/pim/555/D15000100140555.PDF

During Phase 3, it is recalled that the object does not move and only the control changes to compensate for the lack of support.

Acknowledgment

The work has been supported by the French National Association for Research in Technology (ANRT) through the CIFRE 2019/27 and Armor Meca Developpement. This research was supported by the project New smart and adaptive robotics solutions for personalized minimally invasive surgery in cancer treatment -ATHENA, funded by European Union -NextGenerationEU and Romanian Government, under National Recovery and Resilience Plan for Romania, contract no. 760072/23.05.2023, code CF 16/15.11.2022, through the Romanian Ministry of Research, Innovation and Digitalization, within Component 9, investment I8.