Département de Microtechnique Cours 'Conception de produits et systèmes' Projet de semestre, été 1999 Ass. Michel Lauria  Ass. Gilles Caprari

    1.1  Choix du sujet et motivations
    1.2  La méthode choisie

2    Conception

    2.1  Objectifs
        2.1.1  Project brief
        2.1.2  L’arbre des objectifs

    2.2  Le schéma bloc des fonctions

    2.3  Le cahier des charges

    2.4  Analyse de la concurrence
        2.4.1  fischertechnik®
        2.4.2  Lego®
        2.4.3  Autres concurrents
        2.4.4  Différenciation par rapport à la concurrence

    2.5  Catalogue des solutions
        2.5.1  Arbre des idées
        2.5.2  Le bras manipulateur
        2.5.3  Le robot mobile
        2.5.4  Avantages et désavantages de chaque solution

    2.6  Entretiens avec les clients
        2.6.1  Visite à Bussigny
        2.6.2  Visite au Cycle d'Orientation de Goubing, à Sierre (VS)

    2.7  Choix de la variante

3    Réalisation

    3.1  Le micro robot Alice
        3.1.1  Description du robot
        3.1.2  Communication infrarouge (unidirectionnelle)
        3.1.3  Communication par transmission radio (bidirectionnelle)

    3.2  Le langage de programmation
    3.3  L’interface utilisateur et le logiciel de développement
    3.4  Le simulateur
    3.5  Les exercices
    3.6  Evaluation et propositions d’optimisation
    3.7  Prix et contenu du kit

4    Conclusion

Annexes

    5.1  Documentation sur Alice
    5.2  Listing de l’interface




---

1    Introduction

1.1    Choix du sujet et motivations

Les extraits qui suivent sont tirés de Résonances, mensuel de l'école valaisanne. Les articles traitent des réformes en cours dans l'éducation publique…

Des activités porteuses de sens :

Pour répondre aux exigences actuelles de la formation en mathématiques, les activités retenues lors des cours seront centrées sur des problèmes "ouverts", des situations-problème, des jeux et stratégies, des casse-tête et autres recherches dans lesquelles les élèves devront développer une véritable démarche scientifique (poser des hypothèses, les vérifier, affirmer, justifier, se confronter à leurs camarades, … ).

Auto-évalutation des élèves…

L'évaluation de "demain" devrait être une évaluation globale. Dans ce but, les moyens 7-8-9 devraient contenir un maximum d'activités permettant l'auto-évaluation de la part de l'élève, …

…et formation continue des enseignants

L'évaluation de travaux de groupe, d'activités favorisant la différenciation, paraît, pour l'instant, quelque peu problématique, voire nouvelle pour une majorité d'enseignants. Pour l'introduction de tels moyens d'enseignement, la formation des enseignants, formation initiale et continue, est assurément l'élément primordial.

L’ordinateur est devenu un outil indispensable dans tous les domaines de la vie quotidienne et il est important de préparer les élèves déjà dans les écoles à ce qui les attend quand ils sortiront : un monde dans lequel il faut absolument être capable de travailler avec des moyens informatiques.

Mais l’informatique revêt aussi d’un aspect ludique et intéressant qui permet de motiver les élèves pour des matières plutôt " sèches " comme les maths, parce qu’il permet d’apprécier l’utilité et les applications pratiques de cette matière.

Dès lors, pourquoi les enseignants ne se servent-ils que très peu de ces moyens ? La raison est simple : presque tous les langages de programmation ne sont pas adaptés pour cette application, ils sont souvent trop compliqués et nécessitent trop de connaissances de base pour pouvoir être utilisés dans les écoles. De plus, les élèves souhaitent quelque chose de plus " visible " qu’un programme qui peut simplement additionner deux nombres, il leur faudrait quelque chose qui bouge.

Nous nous sommes inspirés par un article de M. Jürg Nievergelt, professeur à l’EPF Zurich, qui parle de comment on pourrait rendre plus aisée la programmation dans les écoles.

Une des achèvements les plus impressionnantes de la technique moderne est la simplicité dans l’utilisation d’une machine compliquée, or cette simplicité n’est souvent pas atteinte au premier coup, mais après beaucoup d’essais. C’était le langage de programmation LOGO qui était, dans les années 70, un des premiers essais de rendre la programmation accessible aux enfants. Le but de LOGO était d’offrir aux débutants une entrée aisée dans le monde de la programmation, mais aussi de posséder la puissance d’un langage professionnel.

Aujourd’hui, presque tous les programmes modernes appliquent le principe de LOGO : Il suffit par exemple d’appuyer sur quelques boutons pour afficher toute une partie d’un texte en gras. L’utilisateur n’a pas besoin de savoir ce qui se passe derrière la surface du programme, parce que c’est le logiciel qui permet d’effectuer une tâche compliquée a priori de façon très simple.

Mais pourquoi alors l’élève doit-il apprendre à programmer si en principe il n’en a pas besoin pour se débrouiller dans le monde informatique ? Pour expliquer cela on se sert d’une analogie entre l’informatique et la mathématique. Dans les maths il suffit souvent d’appliquer des théorèmes sans que l’utilisateur sache les prouver. Pourquoi donc apprend-t-on quand même à l’école comment prouver quelques théorèmes importants ? Parce que pour pouvoir appliquer correctement le théorème pour calculer quelque chose, il doit connaître la notion de la preuve mathématique. Et comme analogie on peut dire que l’utilisateur devrait connaître la notion du programme pour pouvoir appliquer correctement un logiciel. C’est pour ça que la programmation doit faire partie de l’éducation générale pour tout le monde.

Il faut donc offrir aux élèves la possibilité de se plonger dans la programmation pour qu’il apprenne les notions, mais seulement de façon très rudimentaire. Et c’est là le défaut de presque tous les langages de programmation. Ils sont conçus pour que l’expert puisse programmer n’importe quoi, mais par contre au début on doit lire un manuel pour pouvoir écrire " Hello world ". Il faut donc définir des mondes de programmation artificielles, qui n’offrent que des possibilités très restreintes, mais de manière très simple, le but n’étant pas de pouvoir faire tout, mais seulement ce qu’il faut.

Là, la programmation d’un robot jouet permet un rapport optimal entre une simplicité du langage et un comportement intéressant. Il faut donc spécifier les actions et les capteurs du robot et y adapter le mieux possible le langage de programmation, en définissant les capacités logiques du robot.

Si de cette façon on ne force pas la programmation d’être " utile " directement, mais plutôt ludique, déjà une courte introduction peut donner des expériences et d’idées importantes aux élèves. Et c’est l’expérience personnelle qui va aider l’élève de pouvoir juger lui-même, ce que des ordinateurs arrivent à faire ou non.

Suite à la lecture de cet article nous avons décidé de faire un produit qui permet aux élèves de programmer de façon très simple un robot, de faire des exercices qui les font travailler de manière autonome en équipe et avec lesquels ils peuvent contrôler eux-mêmes, s’ils ont fait juste ou non (auto-correction).

1.2    La méthode choisie

Le but de ce projet, dans le cadre du cours " Conception de produits et systèmes ", est de concevoir et de réaliser (au moins sur le papier) un nouveau produit en empruntant la démarche qu’il faut suivre dans la réalité. Cela veut dire qu’il faut analyser le marché en considérant la concurrence, établir un cahier des charges, optimiser le produit du point de vue de la qualité, de la production, etc.

Nous avons choisi de concevoir un " Kit de robotique pédagogique " qui doit permettre de façon simple et intéressante, mais aussi ludique, aux élèves de se rapprocher de l’informatique et des maths (voir " Project brief ").

Notre rapport se compose essentiellement de deux parties :
 

La conception :
c’est à dire la phase théorique que l’on a parcourue pendant le 1er semestre. Dans le rapport nous n’allons pas exactement suivre l’ordre proposé par les exercices distribués dans le cours, cependant, tous les aspects mentionnés seront traitées.

La réalisation :
Dans cette section nous allons présenter ce que nous avons fait en pratique : l’interface pour programmer le robot Alice et les exercices que nous avons élaborés et à l’intention des élèves. En faisant un effort supplémentaire nous avons donc investi beaucoup de temps dans la programmation de cette interface ce que nous a empêché de suivre exactement la démarche théorique. En plus, le fait que nous avons choisi de réaliser notre projet à partir d’un robot déjà existant nous a permit de sauter quelques étapes. C’est pour ça que notre rapport ne sera parfois pas complet du point de vue de la théorie, mais nous croyons que cette lacune est largement compensée par le résultat final, une interface pour la programmation simple qui marche.

2    Conception

2.1    Objectifs

2.1.1    Project brief

Le " Project brief " consiste à concentrer en une phrase l'objectif à atteindre avec notre produit :
 

'Proposer un kit de robotique pour l'enseignement en 7, 8, 9ème primaire qui permette d'expérimenter dans la pratique des programmes informatiques simples, d'appliquer des calculs mathématiques et de motiver les élèves (même inintéressés à priori) pour les domaines techniques comme la robotique ou la commande numérique.'

2.1.2    L’arbre des objectifs

Le schéma suivant montre les objectifs que nous aimerions atteindre avec notre produit. Le chiffres à côté de chaque élément signifie l’importance qu’on lui donne par rapport aux autres aspects.


 

On voit ici que nous mettons l'accent sur le développement de l’esprit d’équipe chez les élèves et sur le fait que le langage doit être simple.
 

2.2    Schéma bloc des fonctions



2.3    Le cahier des charges

Le cahier des charges sert à déterminer les attributs, les performances et les spécifications de chaque sous-système.

En général :
 

• Adapté à l’utilisation en classe
• Modularité quant au nombre de robots interagissants
• Prix pas trop élevé (pas plus que 10’000 francs suisses)


A. Interface logicielle :
 

• Facile à comprendre, à utiliser et à installer même pour les non-initiés
• Langage de programmation s’adressant à des élèves sans formation en informatique
• Langage de programmation dans la langue maternelle des élèves
• Prévue pour être installée sur des machines standards (PC, MAC)


B. Interface ordinateur - robot :
 

• Capable de gérer un ou plusieurs robots
• Capable de donner un feed-back en temps réel du robot géré
• Robuste : boîtier solide, câbles et connecteurs standards,
• Éventuellement communication par radio ou infrarouge ou …
• Peut être intégrée au robot lui-même ou non


C. Robot :
 

• Robuste afin d’assurer l’utilisation pendant environ dix ans dans plusieurs classes
• Aisé à mettre en œuvre
• Modularité restreinte (l’idée de base n’étant pas la construction)


D. Alimentation :
 

• Conforme aux normes européennes
• Sécurité accrue et adaptée à la manipulation par des élèves

2.4    Analyse de la concurrence

2.4.1    fischertechnik®

fischertechnik® dispose de deux lignes principales de produits robotiques :
 
• Mobile Robots
• Industry Robots


L’interface est la même pour les deux lignes et s’appelle " Intelligent Interface ". Elle consiste en une carte qu’il faut brancher sur le port série et elle dispose de 4 sorties digitales pour les moteurs ainsi que de 8 entrées digitales et 2 entrées analogiques pour les moteurs et les capteurs.

Le logiciel est une interface graphique très intuitive sous Windows95, dans laquelle on peut mettre des petits blocs qui représentent les commandes du programme complet.

Deux sortes de capteurs sont disponibles : des interrupteurs ou des capteurs de lumière (pour Mobile Robots).

Un système complet avec logiciel (DM100.-), interface (DM240.-) et boîte avec robot (DM260.- pour Industry Robots, DM500.- pour Mobile Robots, mais contient déjà logiciel et interface) coûte ainsi entre DM500.- et DM600.-, c’est à dire environ entre 400 et 500sFr.

Pour des informations supplémentaires, veuillez vous référer à l’annexe (2 articles, pages web imprimées et " Präsent mit Potential " par Dr.Thomas J. Schult) ou sur le site web www.fischerwerke.de .

2.4.2    Lego®

Un autre concurrent, peut-être plus dangereux est Lego®. Ils offre deux boîtes différentes:
 
• CyberMaster
• MindStorms


Comme la boîte CyberMaster n’offre que des possibilités beaucoup plus restreintes que MindStorms, nous n’allons traiter que ce dernier.

L’interface consiste en un émetteur infrarouge qu’on branche sur le port série du PC et une pièce appelée RCX qu’on implante directement dans le robot et qui gère tous les moteurs et capteurs. Il y a même une télécommande qui permet de contrôler directement les trois sorties et de démarrer des programmes qui ont été chargés précédemment sur RCX.

Ce RCX gère jusqu’à trois moteurs et trois capteurs simultanément. Il existent des boutons actionneurs, des capteurs de lumière, des capteurs de rotation et des capteurs de température.

Le logiciel tourne sous Windows et utilise aussi des blocs fonctionnels qui représentent les commandes. Ayant eu la possibilité de tester cette interface sur un PC avec un petit robot en Lego, nous avons fait l’expérience que tout le langage est très simple et intuitif, mais que ça devient rapidement très encombrant sur l’écran dès qu’on essaye de faire des programmes un peu complexes.

Le prix de la boîte MindStorms est d’environ $200. Ca vient de sortir en Suisse, nous connaissons donc pas encore les prix des magasins suisses.

Informations supplémentaires : www.legomindstorms.com ou l’article " Präsent mit Zukunft " qu’on a déjà mentionné.

2.4.3    Autres concurrents

Il est clair que nous ne sommes pas les premiers à avoir l’idée de vendre un outil pour les cours d’informatique à des écoles. Si l’on regarde sur le web, on trouve beaucoup de choses comme des robots de type bras manipulateur ou des petits robots qui peuvent saisir un objet, rouler ou même marcher puis le relâcher. Par contre ces kits sont souvent chers et mal adaptés à la programmation par des élèves qui ne connaissent pas encore les langages évolués comme le Pascal ou le C.

C’est pour cette raison que nous n’allons pas trop entrer en détail dans l'étude de ces produits qui se trouvent surtout sur le marché américain. Il est aussi très difficile de les acheter ici en Suisse, donc pour nous, ces robots ne représentent pas une concurrence sérieuse et adaptée à notre marché cible.

2.4.4    Différenciation par rapport à la concurrence

Avec des concurrents aussi puissants que Lego et fischertechnik, il faut que notre produit se différentie clairement :
 
• On s’adresse strictement à des écoles. On ne va donc pas vendre notre kit dans les magasins mais plutôt négocier directement avec les responsables des centres scolaires.
• Notre produit est peu modulaire. Le but chez nous n’est pas de construire un robot, mais seulement de le programmer. Cette non-modularité permet par contre d’augmenter nettement la robustesse, ce qui est un bon argument de vente dans des écoles.
• On vise à offrir un service de garantie. Si une panne intervient, la réparation sur site ou par courrier rapide doit être assurée.

2.5    Catalogue des solutions

2.5.1    Arbre des idées



Pour la réalisation pratique du robot, on a dû choisir entre trois variantes possibles :
 

• Le robot à bras manipulateur
• Le robot mobile
• Une combinaison des deux

2.5.2    Le bras manipulateur

Il s’agirait d’un robot stationnaire à deux degrés de liberté (monter et descendre, pivoter autour d’un axe vertical) capable de saisir une pièce soit avec une sorte de pince, soit avec un électroaimant, et de la poser ailleurs.

Ce type de robot est comparable à ce que fischertechnik offre avec ses " Industry robots ". On pourrait mettre plusieurs robots à la suite pour former une chaîne d’assemblage.

Si on avait choisi cette variante, on aurait vraisemblablement conçu notre propre robot au lieu de construire un sur la base des pièces de fischertechnik ou de produits équivalents.

2.5.3    Le robot mobile

Nous avons imaginé deux variantes : un robot qui ne peut que rouler et un autre qui peut en plus saisir une pièce avec une pince ou un aimant (du style Khepera avec pince).

Comme il existe déjà beaucoup de robots de se style, on s’est demandé si c’était vraiment nécessaire d’en concevoir un nouveau pour notre application au lieu de tout simplement prendre un robot existant comme le Khepera ou le micro-robot Alice ou ...

2.5.4    Avantages et désavantages de chaque solution

2.6    Entretiens avec les clients

2.6.1    Visite à Bussigny

Description du cadre:

Bussigny est une petite ville d‘environ 8'000 habitants à la périphérie de Lausanne.

Scolarité à Bussigny jusqu’en 9^ème ( fin de la scolarité officielle) pour les sections terminales à options et section supérieure. Les élèves en section prégymnasiale effectuent leur scolarité dans une commune voisine.

Description de l‘entretient:

Présentation du projet au directeur des écoles et au municipal responsable de l‘éducation.

Résultat de l‘entretient:

Existe-t-il déjà un système similaire ?

On a entendu parler d’expériences faites en combinant le programme éducatif Logo Writer et des sets de construction Lego (serre qui s’ouvre avec un capteur de température, passage à niveau avec barrières...).

Ces exercices sont vraiment destinés à des enfants en difficulté car ils exigent un investissement en temps qui ne peut être consacré qu‘à des élèves en classe de développement qui peuvent bénéficier d’un programme personnalisé et adaptatif.

Le municipal semblait obnubilé par ces expériences mais ne se rendait pas compte de leur marginalité et de l‘impossibilité d‘appliquer ces méthodes à une large échelle.

En quoi consistent les cours d‘informatique à Bussigny ?

Nous avons pu relever qu‘aucun cours d‘informatique, au sens où nous l‘entendons, n‘était actuellement dipensé. Les élèves n‘ont accès qu‘à des cours de fonctionnement général de l‘ordinateur, traitement de texte, programme de géométrie, ceci en option.

L‘idée est-elle intéressante et viable ?

Nous avons suscité un intérêt de politesse lors de notre visite. Nos interlocuteurs redoutaient beaucoup le désintérêt rapide des enfants après quelques expériences. Nous avons appris que l‘école avait déjà fait l‘acquisition d‘une „boîte Logo", mais que celle-ci collectait la poussière sur une armoire…

Matériel utilisé et nombre de périodes d’enseignement ?

L‘école utilise des Macs et propose des cours à option de 6 heures par semaines pendant un semestre

Prix de vente ?

Un prix de „quelques milliers de francs" a été articulé. Ce chiffre n’a néanmoins que peu de signification car nos interlocuteurs ne savaient pas précisément ce qu’ils achetaient et ont plus essayé de mettre un prix sur une idée que sur un produit. Nous avons malgré tout pu juger qu’une somme de deux à trois milles francs pour un produit qui peut être utilisable pour travailler avec une dizaine d’élèves serait acceptée sans trop de réticences.

Conclusion

Nous avons été quelque peu déçu par la réaction de nos interlocuteurs vis à vis de notre projet. En prenant cet entretien avec recul et en confrontant notre expérience de Bussigny avec celle de Goubing, nous pouvons néanmoins interpréter et analyser ces réactions.

Premièrement, nous avons immédiatement saisi l‘importance vitale d‘avoir un responsable informatique et des professeurs motivés par le concept. De toute évidence ce n‘est pas le cas à Bussigny. Il est aussi à relever que cet entretient c‘est fait dans la phase de naissance de notre projet, nos idées n‘étaient sûrement pas assez claire et une démonstration pratique aurait presque assurément pu faire comprendre à ces personnes toutes les possibilités et le potentiel de notre projet.

La comparaison entre les écoles de Bussigny et de Goubing nous montre bien que les élèves et le corps enseignant font preuve d’une motivation et d’un intérêt sans réserve pour un projet de ce genre s’ils peuvent toucher et sentir rapidement une réalisation concrète.

Deuxièmement il faut savoir que si une progression informatique faisant appel aux outils que nous proposons ne semblait pas leur convenir, c’est parce qu’ils estimaient (de façon biaisée - nous l’avons constaté à Goubing) que la motivation, la créativité et la capacité de leurs élèves à utiliser un tel kit n’étaient pas suffisante.

Malgré tout, notre projet semblait suffisamment intéressant pour que l’on nous propose d’effectuer des tests dans une classe comme nous l’avons ensuite fait à Goubing. Comme nous pensions y obtenir des informations plus intéressantes et utiles qu’à Bussigny, c’est vers Goubing que nous nous sommes tourné.

2.6.2    Visite au Cycle d'Orientation de Goubing, à Sierre (VS)

Objectifs de notre visite

L'idée initiale de cette visite était de profiter de l'expérience d'un enseignant qui utilise un bras manipulateur fischertechnik et l'interface LogoMR (développée par Jean-Christophe Zufferey durant l'été 98) pour se faire une idée très proche de la réalité de la robotique appliquée à l'enseignement.

Il est important de souligner ici que les élèves de cet âge-là (13-15 ans) découvrent l'informatique à l'école. Ils ont donc aucune notion de programmation. Tout au plus ont-ils travaillé quelques heures avec Logo Writer.

Ces élèves ont commencé par nous montrer quelques exercices et applications qu'ils avaient déjà réalisées. Ensuite, on a pu proposer des exercices que nous avions imaginés afin de se faire une idée précise des difficultés que pouvait rencontrer l'enseignant. Enfin, une discussion avec les profs, nous permit de mieux cerner les attentes, les envies, les angoisses et les possibilités à l'égard de notre projet.

Les objectifs furent énoncés comme suit :

• Observer des élèves et des enseignants travaillant avec un robot ("LogoMR")
• Obtenir l'avis de ces personnes sur ce moyen pédagogique
• Tester des idées d'exercices avec des élèves
• Présenter notre projet et discuter avec des enseignants de sa faisabilité
• Et finalement, profiter de l'occasion pour présenter le projet "robots footballeurs" pour l'expo.01 et sonder l'opinion des enseignants

 

Organisation

13h00 Déplacement à Goubing

13h10 Préparation des cours, essai du robot "LogoMR"

13h45 1^er cours (mathématiques appliquées – 9^ème) : démonstration d'exercices sur le robot "LogoMR" réalisés par trois ou quatre élèves expérimentés (dernière année avant un apprentissage)

14h35 2^ème cours (histoire – 9^ème) : possibilité pour nous de poursuivre avec un ou deux élèves du cours précédant => exercice présenté par Patrick

15h25 3^ème cours (informatique – 9^ème) : introduction à "LogoMR" et exercices simples par Jean-Christophe (~4 élèves)

16h20 Présentation de notre projet "Kit de robotique pédagogique" aux enseignants intéressés. Discussion avec ces enseignants.

17h00 Démonstration du robot "Zéphyr" et du robot "Alice" aux élèves intéressés.

Notre exercice

L'idée fut de proposer un exercice plus complexe, faisant intervenir plus de notions que les petits exercices de simples déplacement de pièces et permettant l'expérience du travail en groupe.

Deux équipes de 3 personnes furent définies. Et le jeu commença. Un des groupes était sensé travailler dans un centre spatial, sur Terre, pendant que l'autre serait constitué d'astronautes. Sur la Terre, il y avait l'ordinateur de commande (avec l'interface LogoMR) et sur la Lune, le bras manipulateur. Les deux groupes ne devaient communiquer que verbalement et sans contact visuel.

Dans une première phase, ils devaient trouver un moyen de se communiquer des missions de type : "déplacer une pièce d'un point A à un point B". Pour se faire, il s'agissait de définir une règle de trois entre unités du robot et unités métriques et angulaires en testant différents mouvements du bras (vertical et horizontal en rotation).

Ensuite, une mission fut délivrée à l'équipe des astronautes qui durent la décrire à la Terre afin qu'ils puissent la programmer.

Dans la phase finale, l'équipe sur la Terre put exécuter le code préparé, tout en assistant au résultat.

De notre côté, on se rendit vite compte que 45 minutes était un temps un peu sous-évalué pour un tel programme. Cependant, les élèves (même pas trop intéressés, a priori, par la science ou la technique) se laissent prendre au jeu et sont motivés par le résultat final : "faire bouger quelque chose, si possible sans erreur".

Cet exercice fait appel à des notions de mathématique (trigonométrie, applications linéaires, etc.), de logique, de programmation informatique et de travail de groupe.

Discussion avec les enseignants

La discussion avec les enseignants fut orientée comme suit :
 
• La formation des enseignants
• La complexité de l'interface
• Le niveau de programmation
• La robustesse nécessaire
• Style d'exercices & définition des objectifs
• Moyens financiers

Et il en ressort essentiellement les points suivants :

Premières réactions :
 

• nos propositions se révèlent être "en plein dans la ligne" des réformes actuelles de l'éducation publique
• il faut absolument faire dans la simplicité, tant au niveau de la mise en œuvre, qu'au niveau de l'interface

• stimuler la créativité
• favoriser les travaux de groupe, le sens pour la logique et l‘auto-correction
• compréhension et manipulation de la structure d’un système
• notion de précision des mouvements et des positions
• faire des expériences de manière interactive et ludique
• aider la compréhension mathématique en proposant des exercices appropriés lors d'ateliers
• exercer une certaine rigueur (par exemple dans la syntaxe de programmation)

• le constructeur du kit devrait proposer des exercices types, tout en laissant la possibilité aux enseignants créatifs d'inventer d'autres problèmes
• matières: mathématiques, informatique, logique, transposition de problèmes pratiques
• favoriser les travaux de groupe

• possibilité de programmer à différents niveaux ("qui peut le plus peut le moins")
• "expressions conditionnelles" bien, mais limite
• éventuellement style Logo Writer
• de préférence dans la langue maternelle


Interface :
 

• le plus simple possible
• rapidement compréhensible sans cours préalable

• pas de formation absolument nécessaire
• éventuellement petit mode d'emploi simple et rapidement compréhensible

• quelques milliers de francs pour équiper une classe ou développer un atelier

• il est difficile d'occuper toute une classe avec des robots : problème de contrôle
• l'infrastructure au niveau des ordinateurs est parfois insuffisante (evt. livrer un petit ordinateur adapté et bon marché avec le robot)

• a priori, un robot mobile offre plus de possibilités qu'un bras manipulateur (LogoMR) dans la diversité des exercices, il est donc plus intéressant
• est-il possible de tracer sur du papier la trajectoire d'Alice ?
• les enseignants sont sceptiques quant à la robustesse de ce robot
• problème du vol : "pour les enfants, il est facile et tentant de mettre un de ces petits robots dans la poche"

• premières réactions très positives
• attention de proposer un langage de programmation très simple
• traiter comme option de cours d’informatique
• pas de cours supplémentaire

Nos conclusions

Il existe une réelle attente de la part du milieu de l'éducation publique pour ce genre de moyen pédagogique. Cependant, certains problèmes sont à prendre très au sérieux. Nous retiendrons ici les problèmes liés au matériel informatique, à la robustesse, au vol et à l'utilisation en groupe.

Pour la suite, nous retenons que la variante "robot mobile" paraît plus intéressante que la variante "bras manipulateur" car plus variée et peut-être plus proche de choses déjà connues (cf. Logo Writer).

Il est aussi à noter que le chiffre articulé (quelques millier de francs) nous donne une première idée pour l'évaluation du prix de notre kit.

Enfin et surtout, nous avons retiré de cette expérience très enrichissante une notion assez précise de ce que pouvaient être les exercices avec un robot dans une classe de ce niveau.

2.7    Choix de la variante

Fort de l'expérience de la visite à Goubing et suite à une discussion avec Gilles Caprari (responsable du développement du robot Alice, à l'ISR), nous avons décidé d'opter pour une solution avec un robot autonome.

Plus précisément, le robot Alice (déjà réalisé) nous permet de nous concentrer sur l'aspect interface, langage de programmation, exercices et conception global du kit.

L'idée est donc de sous-traiter la construction du robot et de développer et produire "seulement" le logiciel, le support matériel et les exercices.

Afin de limiter les coups et de diminuer les besoins de surveillance, un simulateur (existant lui aussi) sera utilisé. Plus précisément, notre logiciel devra être capable de se connecter indifféremment à un robot Alice réel ou virtuel. Ainsi, le nombre de robots par classe peut être très réduit, les élèves ne testant leurs programmes que lorsqu'ils tournent déjà sur le simulateur.

Cette variante nous paraît moins utopique et moins coûteuse que si l'on avait dû créer de toute pièce le robot (par exemple bras manipulateur) et le simulateur. Remarquons cependant que tout va être entrepris, lors du choix du langage de programmation, afin que celui-ci puisse être facilement applicable à d'autres types de robot. En effet, une extension de notre projet, en cas de succès, pourrait être de proposer d'autres éléments robotiques.

Dans la suite, nous avons non seulement étudié la réalisation technique de notre projet, mais nous avons aussi eu l'occasion de réaliser une version préliminaire du logiciel et un programme de démonstration afin de mieux se rendre compte de la faisabilité d'un tel ensemble.

3    Réalisation

3.1    Le micro robot Alice

3.1.1    Description du robot

Le micro robot Alice est un robot autonome de très petites dimensions (21 mm x 21 mm x 14 mm). Il est géré par un microcontrôleur PIC16C84 programmable à l’aide d’une EEPROM. Les deux roues sont entraînées par des moteurs d’horloge (Lavet). Il est également muni de 4 capteurs de distance. Ceux-ci permettent de détecter des obstacles et de communiquer localement entre deux robots. Les obstacles sont détectés jusqu’à une distance de 2 cm et la communication infrarouge entre robots est possible jusqu’à 4 cm.

L’alimentation de tout le système est assurée par deux batteries d’horloge. Grâce à une très faible consommation de puissance, le robot reste autonome pour environ 10 heures.

La vitesse du robot n’est pas variable et elle est de 20 mm/s.

La communication avec le robot peut être établie de deux manières différentes, qui seront expliquée par la suite. Dans notre cas on parle toujours de la communication entre l’ordinateur de base (PC) et le robot.

Pour plus d’information sur le robot Alice veuillez vous référer à la documentation qui se trouve dans l’annexe.

3.1.2    Communication infrarouge (unidirectionnelle)

La communication infrarouge est unidirectionnelle. Avec cette communication il n’est donc pas possible d’inclure des commandes conditionnelles dans notre langage de programmation, puisqu’il n’est pas possible de connaître les valeurs des capteurs sur le robot. Cette méthode n’est alors pas adaptée à notre application.

3.1.2    Communication par transmission radio (bidirectionnelle)

Il est également possible de communiquer avec le robot par transmission radio. Cette communication est bidirectionnelle ; c’est-à-dire qu’on peut envoyer des commandes au robot d’une part, et recevoir des informations du robot d’autre part (par exemple sur l’état des moteurs ou des capteurs). Ce type de transmission est absolument indispensable pour pouvoir écrire des programmes qui agissent de manière dynamique. La transmission dans les deux sens est possible jusqu’à une distance de 10 m.

Le module de transmission radio est encore en cours de développement. Nous utilisons donc actuellement des câbles, mais avec le même protocole de transmission radio. Le module radio sera prêt vers la fin de l’année. Après on pourra utiliser ce module de manière " plug and play " ; c’est-à-dire il suffira d’enlever les câbles et de brancher le module de transmission radio et tout fonctionnera exactement de la même manière qu’actuellement.

La vitesse de transmission n’est pas très élevée. La réception de la valeur d’un seul capteur sur le robot dure par exemple 40 ms (20 ms pour la demande, 20 ms pour la réception). Si l’on fait beaucoup de guidage du robot à partir de l’ordinateur de base (ce qui implique beaucoup de lectures des capteurs et beaucoup d’envois de commandes) on rencontre deux problèmes : Premièrement on observe des temps d’attente remarquables en regardant les mouvements du robot, et deuxièmement ceci implique une baisse inadmissible de la précision des mouvements. La solution est d’effectuer toutes ces opérations le plus possible sur le processeur PIC du robot. Ceci veut dire qu’on envoie au robot seulement la commande de départ et puis il s’occupe lui-même de la gestion pour effectuer cette commande. Nous avons donc essayé de procéder de cette manière dans la mesure où c’était possible avec le temps qui était à disposition. Il est clair qu’il y a encore des améliorations à faire pour diminuer encore le taux de communication avec le robot.

Dans la configuration actuelle il est très facile de commander 2 robots à la fois avec la communication radio. Mais on peut bien sûr augmenter ce nombre en faisant un simple adressage des robots. La limite est fixée par la vitesse de transmission. A partir d’un certain nombre de robots, on arriverait plus à lire les capteurs sur tous les robots dans les intervalles nécessaires pour le bon fonctionnement du guidage. Mentionnons ici qu’à l’avis des enseignants il n’est pas possible d’occuper toute une classe avec des robots. Deux robots commandés à la fois sont donc déjà suffisants.

Le module de transmission radio coûte relativement cher, et la transmission n’est pas très rapide. Nous proposons donc comme option une communications par câbles. Le robot sera donc toujours lié à l’ordinateur par ces câbles. L’avantage de cette méthode est une baisse de prix du robot de presque la moitié. De plus la vitesse du protocole de communication peut être augmenté. Le fait que le robot sera physiquement lié avec l’ordinateur diminue aussi le risque de vol par des élèves.

3.2    Le langage de programmation

Le choix du langage de programmation est un problème important dans ce genre de projet. Il est capital de bien répondre aux attentes des enseignants :
 
• langage très simple style (Logo Writer), avec possibilité d'introduire des boucles "répète" ou des contrôles de flux conditionnels
• si possible dans la langue maternelle
• demandant tout de même un peu de rigueur au niveau de la syntaxe


Le langage Logo a été évalué car il correspond assez bien aux attentes des enseignants. Cependant, il est assez complexe de réaliser un interpréteur de Logo. Et il nous parut gênant et frustrant pour des utilisateurs habitués de limiter ce langage à une forme encore plus simplifiée.

Pour notre première version de démonstration, nous avons opté pour un langage très limité, ressemblant un peu au C (avec des accolades pour déterminer les blocs), avec des "IF" et des "REPEAT", ces blocs pouvant être imbriqués à l'infini. Nous avons laissé de côté l'idée des déclarations de constantes et de variables. Nous n'avons pas non plus implémenté une reconnaissance de procédures et de fonctions. Ces derniers points nous semblent cependant assez importants pour la version finale.

Le tout est compilé avec un "header" contenant les mots clés dans la langue voulue. Dans un premier temps, seule la version française a été réalisée mais cette méthode permet de vendre le produite dans différentes régions linguistiques très facilement.

Voici un exemple de programme :

Programme DEMO :

DEBUT

avance.jusque (obstacle.devant)
gauche (90)
suis (droite)
gauche (45)
si (obstacle.gauche) ; test la présence d'un obstacle à gauche
{
    repete (10)
    {
        avance (10)
        droite (30)
    }
}

Commandes utilisables :
 

• avance ( )
• avance.jusque ( )
• recule ( )
• recule.jusque ( )
• droite ( )
• gauche ( )
• suis ( )


Opérateurs :
 

• repete ( ) { }
• si ( ) { }


Conditions booléennes (vrai ou faux) :
 

• obstacle.gauche
• obstacle.droite
• obstacle.devant
• obstacle.derrière


Constantes :
 

• droite
• gauche


Explication des commandes :
 

obstacle.droite : même principe.

obstacle.devant : même principe.

obstacle.derrière : même principe.
 

Elles ne sont utilisées que par la commande suis ( ). Elles permettent l’exécution par Alice d’une procédure définie au niveau du PIC qui est soit le suivit à gauche ou à droite, d’un obstacle comme un mur, par exemple.

Les objets et obstacles peuvent être détecté lorsqu’ils se situent au maximum à un cm et demi.

3.3    L’interface utilisateur et le logiciel de développement

Le programme étant développé sous Borland C++ Builder, il est très simple de créer une interface standard, avec une page blanche pour y inscrire le code et les menus courants sous Windows. Quelques boutons permettent d'établir la communication avec le robot, de choisir la valeur de certains réglages ou de connaître la valeur des capteurs. D'autres fonctionnalités seront ajoutées afin de communiquer avec le simulateur. Un système de fenêtre (où l'on verra un ou plusieurs Alice virtuels) intégrée au logiciel de programmation sera étudié.

Screenshot de l’interface de programmation
 
Tout le développement, pour la version de test, côté PC, à été réalisée par nos soins sous Borland C++ Builder 4. Vous trouverez le code source en annexe. Il est composé, pour commencer, des fonctions d'interprétation du code entré par les élèves. Viennent ensuite les procédures de communication RS232 avec le robot. Le fichier "keywords.h" contient les mots clés en français.

3.4    Le simulateur

Afin de pouvoir travailler sur les notions de base de notre langage de programmation, sans forcément avoir à disposition un robot Alice réel, nous proposons en plus un simulateur très bon marché. Ceci permettra de faire tourner des programmes aussi bien sur le simulateur qu’en réalité sans aucun changement au niveau du programme. On peut donc préparer et tester un programme sur le simulateur et par la suite passer sur un robot réel pour admirer le résultat. Cette possibilité de simuler le comportement des robots permet de faire travailler toute une classe sur la programmation de nos robots sans travailler avec les robots réels. Rappelons qu’à l’avis des enseignants il n’est pas possible d’occuper toute une classe avec des robots à cause de problèmes de contrôle.

Ce simulateur à été développé pour le robot Khepera, et il a été adapté pour le robot Alice. Actuellement il n’existe qu’une version compatible avec le système d’exploitation LINUX, mais une version WINDOWS sera à disposition vers le mois d’octobre.

L’interface entre l’interpréteur et le simulateur n’est pas encore développée.

3.5    Les exercices

Ces quelques exercices ont pour buts de satisfaire les objectifs qui nous ont été fixés lors de nos différentes visites d‘établissements scolaires.

Leur simplicité permet une rapide „prise en main" de la part des élèves et de l‘enseignant. Comme souhaité, la difficulté des problèmes est évolutive: l‘enseignant (ou élève) motivé et créatif est libre de combiner et de s‘inspirer de cette base pour composer des exercices personnalisés.

Une boîte de jeu est livrée avec le kit, elle permet de tester les exercices codés sur l’interface.

Cette boîte est en carton épais, de format A4. Le rebord, d’une hauteur d’environ deux centimètres, empêche la sortie du robot du terrain de jeu. La surface sur laquelle évolue Alice est recouverte d’un quadrillage (unité : 1cm) qui permet aux élèves de résoudre les problèmes trigonométriques proposés ainsi que d’avoir une bonne appréciation des distances parcourues (ou restant à parcourir).

Cette boîte de jeu comprend en outre une dizaine d’obstacles de section carrée (2 cm) de différentes longueurs, ceci afin d’assurer la modularité des exercices.

Concepts étudiés:

Multitude de solutions existantes pour résoudre un problème. Comment en apprécier la qualité?
 

• Rapidité d‘exécution, style de programmation, robustesse de l‘implémentation par rapport à l‘environnement.


Favoriser les travaux de groupe et la communication entre élèves :
 

• Coopération du style „terre-lune" entre celui qui voit et peut décrire et celui qui est aveugle mais peut agir.


Joutes informatiques :
 

• Les élèves peuvent résoudre certains exercices sous la forme de concours, „combats" de robots. Stimulation garantie…


La perfection n’est pas de ce monde :
 

• Les élèves s‘en rendront vite compte, Alice adopte en effet des comportements qu‘il faut pouvoir „sentir", ceci afin de modifier la programmation du code et de réussir l‘exercice.


Exercice mathématique.
 

• Eviter un obstacle en utilisant la trigonométrie de base.
• Concours entre des équipes : Qui arrive à parcourir une course prédéfinie le plus vite ?

3.6    Evaluation et propositions d’optimisation

Du fait que nous avons pu réaliser une première version de notre kit, nous pouvons évaluer concrètement les caractéristiques du système. Nous proposons par la suite quelques améliorations qui nous semblent indispensables pour garantir la fiabilité du kit.
 
• Lorsqu’on fait tourner le robot d’un certain angle, en comptant le nombre de pas des moteurs au niveau du processeur, on rencontre deux problèmes qui sont dû au fait que nous travaillons en boucle ouverte :

• La précision de ces rotations n’est pas toujours assurée. Ceci dépend encore du type d’alimentation du robot. Plus l’alimentation est faible (piles embarquées), plus le robot perd des pas moteur (c'est pour cette raison que nous avons introduit des sliders dans l’interface qui permettent d’ajuster les coefficients d'angles). Dans tous les cas, la précision d'angles n'est pas satisfaisante lorsque le robot n'est pas alimenté par l'extérieur (par exemple avec module radio).

• Il suffit qu’il y ait une petite perturbation qui déplace légèrement le robot pour que la suite du programme ne soit pas exécutée correctement, à cause d'un mauvais alignement par rapport à la trajectoire prévue. Pour résoudre ce problème, il faut améliorer les routines en assembleur qui doivent permettre, à l’aide des capteurs de distance, d’aligner le robot par rapport à un obstacle dans des situations où ceci semble utile.

• Le taux de communication entre l’ordinateur et le robot doit être réduit au stricte minimum puisque ceci utilise beaucoup de puissance et crée des temps d’attentes inutile. Par exemple, la commande "avance.jusque (obstacle.devant)" et contrôlée actuellement par l’ordinateur. C’est-à-dire que l’ordinateur demande au robot, à intervalles réguliers, si le capteur détecte un obstacle. C’est une tâche qui peut être gérée par le processeur PIC sur le robot. Puis, on doit savoir au niveau de l’ordinateur, quand un tel processus et terminé. Là aussi, il serait plus judicieux que le robot envoie automatiquement un avertissement lorsqu'il a terminé, en lieu et place du polling à partir du PC.

 
• S’il y a eu faute de manipulation ou de programmation, on doit avoir la possibilité d’arrêter un programme à tout instant. De plus il peut se révéler utile de pouvoir exécuter certaines commandes isolées (sans écrire un programme) à l’aide de boutons. L'idée de rendre possible l'exécution d'une ligne de code a déjà été prévue.

 
• Le micro robot Alice n’a pas encore la robustesse voulue pour pouvoir être utilisé dans des classes sans trop se soucier des risques d’endommagement. Les éléments faibles sont les moteurs et les roues. L'objectif est une durée de vie d'environ 10 ans pour une utilisation de 10 heures par semaine. Le robot doit pouvoir tomber de la hauteur d'une table sans casse. Ces spécifications figureront dans le cahier des charges du fournisseur.

 
• Les câbles que nous utilisons actuellement pour la communication entre l’ordinateur et le robot sont trop fragiles. Il faut surtout prévoir une bonne isolation et garantir des bonnes connections, les câbles ne devant pas s'emmêler trop facilement.

 
• Le terrain de jeu dans lequel se balade le robot doit présenter une surface très plate pour ne pas perturber les mouvements du robot. Le carton n’est donc pas un matériau approprié. Il faudrait utiliser du bois ou du plastique. Pour les obstacles, le bois naturel s’est révélé très pratique pour garantir une bonne visibilité au niveau des capteurs.

 
• La sensibilité au taux de lumière ambiante peut être très perturbatrice et devrait être amoindrie. Cependant, donner aux élèves la possibilité de régler ce paramètre est une façon de le sensibiliser aux problèmes robotiques et techniques, tout comme la gestion de l'incertitude sur les angles et les distances.

 
• Notre interface et le simulateur doivent être disponibles sur plusieurs plate-forme, en particulier Windows et Macintosh qui sont les plus usitées dans les centres pédagogiques.

3.7    Prix et contenu du kit

Un kit se compose de deux robots (avec ou sans module radio), d’un terrain de jeu avec exercices et d’une trentaine de licences pour le logiciel avec le simulateur.

Le coût pour le robot avec les capteurs et la télécommande pour la communication se montera à environ Fr. 350.-. L’option avec le module de transmission radio coûtera Fr. 650.-. La boîte avec le terrain de jeu et les obstacles coûtera Fr. 50.-. Les coûts pour le matériel d’un seul kit seront donc Fr. 750.-, respectivement Fr. 1200.- (il faut seulement un module de réception en plus puisque l’émission à partir du PC se fait à travers le même module pour les deux robots). Nous comptons 2 ingénieurs pour le développement du logiciel pendant une année et les coûts de vente et de représentation dans le milieu pédagogique.

Dans un premier temps, le marché se restreindra à la Suisse. L’objectif est de vendre 1 à 2 kits par école en moyenne dans environs 15 écoles par canton suisse. Ceci fait une première série de 500 kits dont 250 sans et 250 avec module radio.

Voici le calcul du prix d’un seul kit :

L’ordre de grandeur de ces prix approximatifs est tout à fait raisonnable, vu que quelques milliers de francs sont à disposition pour réaliser un tel projet dans une école.

4    Conclusion

"D'une idée jusqu'au début de la construction détaillée"
Le cours "conception de produits et systèmes" nous a permis, dans un premier temps, de partir d'une idée pour définir un projet. Notre idée fut l'interaction entre pédagogie et robotique, idée abstraite qui, soumise aux méthodes d'analyse du CPS1, nous délivra ses possibilités, ses secrets.

Le potentiel de notre projet ainsi révélé, nous avons voulu le confronter à la réalité de notre marché cible. Nous nous sommes laisser prendre au jeu. Des visites furent effectuées et il en ressortit beaucoup d'enthousiasme de la part des enseignants et quelques problèmes importants. Cette confrontation à la réalité du marché engendra tout naturellement un cahier des charges plus précis et à l'écoute du client.

Puis, le CPS2, nous emmena, grâce aux propositions de l'ISR, de Gilles Caprari et de son micro robot, à l'élaboration d'une première version pratique de notre système. Et grâce à cette version, nous sommes arrivés au début de la construction détaillée, objectif ultime de ce projet de conception.

Choix de la solution finale
Il faut remarquer honnêtement que le choix de la solution finale fut très fortement influencé par l'arrière fond de nos visites in situ et par la possibilité de s'appuyer sur des outils existants qui nous permirent de tester nos idées.

Cependant, la solution "Alice" a été confrontée, comme il se doit, aux solutions de départ, plus abstraites, mais représentant des options tout à fait valables. Nous nous sommes donc attelé à démontrer que cette solution représentait l'idée la plus proche d'une réalisation réelle, dans le cas d'une entreprise débutante.

L'analyse de la faisabilité et de la fiabilité
Il va sans dire, que l'analyse de la faisabilité et de la fiabilité a été menée dans le meilleur contexte qui soit, grâce à notre banc d'essai réalisé par nos soins, à l'ISR. Nos conclusions à ce sujet sont visibles sous le point 3.6.

La demande existe
Notre visite du Cycle d'Orientation de Goubing, à Sierre (VS), a montré que la demande existait. Cependant, d'autres investigations, notamment au niveau des directeurs du matériel informatique des cantons seraient indispensables, par la suite, afin de préciser cette analyse.

Un projet viable pour une toute petite entreprise
Finalement, nous avons le sentiment que ce projet est bien "ficelé" et qu'il serait certainement viable pour une petite entreprise débutante qui commencerait avec deux ingénieurs et un représentant. Les robots et le simulateurs seraient sous-traités et le marché cible limité à la Suisse, dans un premier temps.