Les nouvelles technologies pour l’enseignement des mathématiques
Intégration des TICE dans l’enseignement des mathématiques

MathémaTICE, première revue en ligne destinée à promouvoir les TICE à travers l’enseignement des mathématiques.

Le projet « latence » de l’atelier scientifique du Lycée Parc de Vilgénis
Article mis en ligne le 31 décembre 2020
dernière modification le 6 janvier 2021

par Taillet Jacques

N.D.L.R Jacques TAILLET a déjà confié à MathémaTICE deux articles concernant l’Atelier scientifique du Lycée Parc de Vilgénis à Massy.

Il nous propose de découvrir ici le travail sur la latence d’un robot mené dans ce même atelier.
Deux élèves qui y participent, Baptiste DENIS et Gabriel RAMSSISS ont rédigé un compte rendu de leurs activités.

Ces deux parties sont présentées dans deux onglets différents.
Nous avons choisi de joindre à l’article le document pdf des élèves tel qu’ils nous l’ont envoyé, afin de souligner leurs capacités de communication, qualités que cherche à développer l’Atelier. Le fichier est téléchargeable en fin d’article (fichier associé à l’article)

Mise en perspective par Jacques Taillet

Nous avons travaillé pendant un an avec le Lab Innovation Ericsson sur le projet Pollubike (Pollubike est un objet connecté qui mesure la pollution atmosphérique en milieu urbain en temps réel), puis sur la notion de « latence ».
Pour mettre en évidence la notion de latence nous avons utilisé des robots Lego.
Nous avons placé deux robots sur une ligne formant un carré, le robot suiveur avait un temps de latence important, il perdait du temps en ligne droite pour bien suivre la ligne.
Nous avons eu d’autres projets :

  • Réaction d’un robot à des couleurs
  • Drone qui dépose des cubes
  • Étude du robot Flappy Bird



Pour des raisons de simplicité, nous sommes partis sur le projet Flappy Bird. Il s’agit à partir d’un tracé de faire apparaître l’importance de la latence.
Nous commencions nos travaux quand le premier confinement est arrivé en mars. Le matériel a été confié aux élèves et le travail a commencé à distance.
Pour communiquer, nous avons réalisé des vidéos (« nous », c’est l’atelier).
J’ai alors conseillé aux élèves de mettre par écrit leurs travaux. Ils ont réalisé une vidéo pour présenter leurs travaux, c’est bien mais, pour leur avenir il est important de savoir rédiger par écrit.
Nous allons donner un large écho à ces deux documents dans la suite de l’article.
Les objectifs donnés aux élèves étaient les suivants : émettre des hypothèses, les tester, conclure. Réaliser suffisamment d’essais pour que cela soit significatif.
Les élèves sont partis d’une hypothèse, ils ont réalisé des expériences. Nous avons eu des échanges par Discord.
Cela a permis de discuter en groupe des difficultés rencontrées :

  • Code trop limité car destiné aux enfants. Pas assez intuitif.
  • Robot peu précis, le contrôle des moteurs et des capteurs est très imprécis.
  • La batterie a une trop grande influence sur les performances.

Il y a aussi eu évidemment les problèmes d’échanges physique, de matériel.

Comment les élèves de l’Atelier sont-ils capables de travailler ainsi ? Une petite explication s’impose.

Les objectifs de l’atelier sont de faire des maths, des sciences, de rendre les élèves autonomes, les préparer à être des scientifiques aguerris. Mais aussi apprendre à échanger, rédiger, être rigoureux dans les expériences.
L’Atelier est composé de 30 élèves de Seconde, Première, Terminale, de l’enseignement général, technologique et professionnel.
Le principe général est le suivant : les Secondes apprennent à travailler, les Premières portent les projets et les Terminales les encadrent.
Rôle du professeur : j’encadre, je répartis le travail si besoin, je vérifie et rectifie pour que cela soit scientifiquement correct. Je valide en bout de course.

Travailler en groupe et de manière autonome.

Ces deux dernières années, les élèves arrivant à l’atelier ont choisi ce qu’ils voulaient faire parmi les activités que nous avions entamées :

  • Réaliser des soudures.
  • Apprendre à programmer avec des cartes Microbit afin de s’initier à la programmation et réaliser des tutoriels (chaîne youtube Atelier Scientifique-Vilgénis).
  • Apprendre à programmer en Python.
  • Apprendre à utiliser des cartes Arduino.
  • Traiter des données de Pollubike.
  • Traiter des données de la station météo.
  • Faire des schémas afin de modéliser des situations : plus court chemin entre deux points, lien entre pollution et données météo.
  • Rechercher du matériel afin de faire évoluer pollubike.
  • Apprendre à mieux communiquer au niveau du lycée sur nos travaux.

D’anciens élèves de l’atelier ainsi que certains professeurs viennent ponctuellement répondre à leurs questions. Si les réponses peuvent être données à l’intérieur du groupe, les élèves ont un retour rapide. Elle permet au « sachant » d’apprendre à s’exprimer, à communiquer et à l’apprenant d’avoir un contact direct. Cela permet des échanges oraux, des schémas au tableau, des précisions de montage difficiles à avoir autrement qu’en direct.
A la fin de chaque séance des élèves prennent la parole afin d’expliquer ce qu’ils font. L’objectif est que tout le monde sache ce qui est fait et qu’ils apprennent à s’exprimer.
Les groupes de travail évoluent et les élèves trouvent leur place dans différentes activités.

Publier
L’atelier est fait de sciences, de rigueur, de recherches, de tests, d’erreurs et de rectifications. Tous les temps de la recherche et des sciences se retrouvent dans l’atelier.
Science sans communication n’est pas grand-chose dans le monde d’aujourd’hui : je leur apprends à communiquer.
Je laisse les élèves publier leurs travaux sur les réseaux sociaux ou sur notre site sous certaines conditions. A savoir, les élèves doivent vérifier que leurs travaux répondent aux points suivants :

  • Ce que j’écris est vrai et je l’ai fait relire.
  • Une expérience doit être refaite plusieurs fois.
  • Un calcul doit être vérifié par plusieurs personnes.
  • Ce que j’écris s’appuie sur des informations fiables (attention aux fakes)

Les écrits ne passent pas forcément par moi en première lecture. Mais ils m’arrivent toujours lors des discussions et des débats entre élèves.
Un comité informel décide de ce qui va être publié. Il faut trois personnes au minimum pour décider. Cela développe des qualités d’autonomie.
Je laisse publier des vidéos même si je trouve que le travail pourrait être de meilleure qualité. Pourquoi ? Car cela fait aussi partie de leur apprentissage. Si un élève parle pour la première fois avec un micro et qu’il a dû se faire violence pour y arriver, il n’est pas question de lui refuser le plaisir de la publication. Il verra ce qu’il pourra améliorer pour les prochaines fois mais cette publication lui aura permis de prendre confiance en lui et de faire un premier pas, qui sera suivi par d’autres.
De même, il y a quelques années, j’ai accepté que la vulgarisation de la relation proie-prédateurs soit publiée par un élève de ES qui n’a pas la perception scientifique d’un élève de S. En tant qu’enseignant en sciences, je n’étais pas satisfait du résultat, en tant que vulgarisateur, je l’étais. Cela a permis à cet élève de se sentir vraiment participant de l’atelier et de former par la suite des camarades aux montages vidéo. C’est ça aussi l’esprit de notre Atelier. Comme dit précédemment, chacun avance selon ses qualités, mais il aura toujours sa place, les sciences sont ouvertes à tous, chacun les aborde selon ses envies et ses moyens.

Le projet Latence, tel qu’il a été vécu par les élèves de l’Atelier

Voici maintenant la présentation par les élèves de l’Atelier Scientifique Vilgénis, de leur travail scientifique sur la latence du robot utilisé dans l’expérimentation.

Voici le compte-rendu écrit de l’Atelier. Il a été réalisé par Baptiste DENIS et Gabriel RAMSSISS, membres de l’Atelier.

Introduction

La latence qu’est-ce que c’est ?
Il s’agit du temps de différence qui sépare un ordre de l’action qui en résulte. Par exemple le temps qui s’écoule entre le moment où l’on ouvre le robinet et le moment où l’eau sort.

Pourquoi y a-t-il de la latence ?
Tout simplement parce que l’information ne circule pas instantanément. Plus l’information circule vite (à distance égale) moins il y aura de latence. Pour la réduire il faut donc faire appel à des réseaux plus performant, qui feront circuler l’information plus rapidement et contribueront donc à réduire la latence.
Dans ce projet nous allons chercher à montrer que la latence, même minime, peut occasionner à grande échelle des erreurs plus ou moins importantes. Notre robot Flappy Bird sera notre simulation d’une voiture autonome.

Le robot Flappy Bird

exemple de latence avec le robinet

Le robot avance et doit se déplacer pour éviter les obstacles, comme dans le jeu « flappy bird​ ».
Tout le long du parcours sont disposées des bandes de couleurs au sol. Celles-ci ont trois couleurs : bleu, rouge ou vert (on aurait pu en choisir d’autres). Ces bandes permettent au robot d’effectuer des actions en fonctions de leur couleur :

  • ROUGE : droite
  • BLEU : gauche
  • VERT : fin

Ces indications sont donc vitales pour le robot mais peuvent être remplacées, si on veut une application plus concrète, par différents capteurs qui détectent la présence d’obstacles et permettrait au robot de visualiser l’environnement dans lequel il évolue (comme un capteur ultrason, un sonar, ...).

L’expérience

1. Les conséquences vérifiables
Nous nous attendons à ce que le temps mis par le robot augmente de manière proportionnelle par rapport au temps de latence programmé.
En effet, on a :
$v = \dfrac{d}{t} \Leftrightarrow t=\dfrac{d}{v}$

Or la vitesse du robot est constante. On a donc :
$t=\dfrac{1}{v} \times d \Leftrightarrow$ t = k \times dc’est à dire que t est proportionnel à d.

Ainsi on suppose que le temps mis par le robot et la distance qu’il parcourt (qui augmente avec la latence) sont liés par une relation de proportionnalité.

2. Protocole
Le robot est placé sur une ligne de départ marquée, qui reste fixe entre chaque passage.
On lance le programme (développé plus loin). Puis on réitère avec tous les temps de latence que l’on veut tester, en changeant la variable. Avec un grand nombre de virages, le robot sort parfois du circuit. Nous sommes donc obligés de déplacer les marques aux sols.

3. Circuit
On a d’abord opté pour un circuit à 6 virages. Mais le robot en sortait trop souvent et cela devenait trop fastidieux, nous avons donc simplifié le problème avec un circuit à seulement 2 virages.

Circuit à 6 virages

Circuit à 2 virages

Légende

Les obstacles factices que doit éviter le robot. Ils sont uniquement à but représentatif car le but n’est pas de savoir si le robot réussira le parcours mais de voir combien de temps il met pour le faire.


Un marquage au sol de couleur qui indique au robot quoi faire. (ici de couleur rouge, qui donnera l’ordre de tourner à droite)


Le trajet du robot. Ici il tourne à gauche après une bande couleur bleue.


Fin du circuit marqué par une bande verte.

4. Programme


On commence par démarrer le chronomètre. Ensuite dans la boucle infinie on intègre trois sous-boucles if, une pour chaque couleur. Si le capteur détecte du vert, il s’arrête et affiche le temps du chronomètre pendant 30 sec. Lorsqu’il détecte du rouge, il avance pendant un certain temps, qui représente la latence. Ce temps est défini par une variable. Ensuite il tourne la roue gauche afin de tourner à droite . De même lorsqu’il y a du bleu sous le capteur, il avance tout droit pendant un temps défini par une variable, puis fait tourner sa roue droite . Enfin, s’il ne détecte rien, le robot roule tout droit en faisant tourner les deux roues en même temps. Voici, ci-dessous, l’organigramme du programme du Robot.

Résultats

1. Premiers tests, avec 6 changements

Ce tableau
Sans latence Avec 100ms Avec 200ms Avec 300ms Avec 400ms Avec 500ms Avec 600ms
16,2s 16,42s 16,62s 16,73s 16,82s 17,01s 17,1s

Le robot navigue dans un circuit avec 6 bandes de couleurs (3 rouges et 3 bleues). Les données préconisent un système avec une croissance proportionnelle. Cependant ce test est très fastidieux car il y faut souvent changer les emplacements des couleurs. De plus les mesures sont approximatives étant donné que le chronomètre n’est pas encore intégré au programme.​ On va donc basculer dans un système à seulement deux changements et avec moins de temps de latence différents.

2. Deuxième tests, avec 2 changements

(Version 1)
Première et brève série de tests sur ce nouveau « circuit » et avec le nouveau code.

Ce tableau
0ms 250ms 500ms 750ms 1000ms 6,034s 6,13s 6,292s 6,459s 6,65s

graphique des données du premier test avec 2 virages

Il confirme les hypothèses réalisées avec le test précédent, mais il manque un nombre conséquent de données. ​ Toutefois, par observations nous avons l’impression que la batterie joue un rôle important. ​ Nous allons donc réaliser une nouvelle série de tests, avec plus de données et avec une légère différence.

(Version 2)
Cette fois ci, les tests, au lieu d’être faits dans l’ordre croissants (0ms puis 250 puis 500...) les tests sont faits dans le désordre.

On se rend compte ainsi que les temps de ceux réalisés en premiers (sans latence, 750ms et 500ms) sont anormalement bas alors que ceux réalisés en derniers sont anormalement élevés.​ Voici ci-dessous une superposition des courbes Version1 (en rouge) et Version2 (en bleu).

Par conséquent le niveau de batterie influence le temps mis par le robot.​ Donc le niveau de batterie devra rester constant pour les tests suivants.

(Version 3)
Pour cette série de ​ tests nous avons accumulé 25 mesures pour chaque latence.​ Grâce à la magie des piles rechargeables, nous avons également réalisé les tests avec uniquement un niveau de batterie maximale. La case rouge correspond à une recharge. Les tests ont été réalisés dans l’ordre croissant.



Notre conséquence vérifiable semble être fausse (“ Nous nous attendons à ce que le temps mis par le robot augmente de manière proportionnelle par rapport au temps de latence programmé. ”). Cela ne ressemble pas à une fonction affine, mais plus à une fonction logarithmique...​ Alors, appliquons une courbe de tendance logarithmique :


On se rend compte qu’elle est beaucoup plus proche que si on applique une courbe de tendance affine. On se rend compte en effet que le R2 est plus élevé, c’est à dire que le taux d’erreur est plus faible​.

(Version 4)

Il s’agit des derniers tests effectués pour l’instant. On place le robot au centre d’un cercle d’1m50 de rayon et on cherche à savoir si la position de la bande verte sur ce cercle modifiera le temps du robots et surtout comment elle le fera. Ainsi on veut placer la fin du circuit à 45°, 90° et 0° du robot, à droite et à gauche. Dans un souci pratique, on modifie un peu le code du robot. En effet, au lieu qu’une seule roue du robot lui serve à tourner, on lui fait actionner ses deux roues dans le sens contraire. Il va donc rester sur place lorsqu’il va tourner, ce qui permettra de prédire plus facilement et précisément où il arrivera. Toutefois, les résultats étaient incohérents : on a obtenu des temps plus courts pour des temps de latence plus élevés. C’est pour cela que nous nous sommes arrêtés à 2 mesures pour 0ms.

Conclusion

Finalement, notre hypothèse de départ, c’est à dire que le temps mis par le robot pour faire le circuit augmente proportionnellement avec la distance, était fausse. Il y a plusieurs raison à cela :

  • La vitesse que nous croyions constante ne l’est pas (à cause de la batterie notamment).
  • La latence n’augmente pas proportionnellement avec la distance. Les virages ne se font effectivement pas à 90° donc lorsque le robot continue tout droit à cause de la latence il continue à se rapprocher de la ligne finale.

Puisque le temps du robot augmente en fonction de la latence selon une fonction logarithmique, un petit temps de latence entraîne rapidement une grande conséquence. On peut parler d’effet « boule de neige​ ».

Les problèmes rencontrés

Nous avons rencontrés une grande multitude de problèmes :

  • Comme dit précédemment lorsque le robot subit de la latence il se rapproche de l’arrivée, sa latence lui est « utile ». Ainsi la position de l’arrivée joue beaucoup dans les mesures et peut être mauvaise.
  • Le matériel lego en général a certaines limites :
    • Le détecteur de couleur n’est pas précis à 100% . Ainsi il arrive qu’il parvient à finaliser le circuit mais qu’à la fin il détecte du bleu à la place du vert et ne s’arrête pas.
    • Les moteurs ne peuvent pas être programmés pour faire tourner le robot à 90°, ainsi on perd forcément en précision et les trajectoires des robots peuvent être faussées.
    • Les robots sont très énergivores et nécessitent d’être chargés au maximum pour la précision des tests. Il fallait donc les recharger très souvent.
    • Le logiciel de programmation en bloc est peu clair et a nécessité du temps d’apprentissage.
    • On ne pouvait uniquement que téléverser et non récupérer le programme dans le robot ce qui est peu pratique pour les déplacements.

L’avenir du projet

Nous avons encore plein d’idées, autres que le flappy bird pour le projet latence mais nous préférons pour l’instant travailler sur celui-ci.
Nous allons dorénavant nous concentrer sur des situations où deux robots, un avec latence et l’autre sans, feront le même circuit en même temps. Il s’agira d’un circuit simple, tel que des allers retours. De cette manière, le robot avec latence mettra beaucoup plus de temps. Ce format nous permettra de pouvoir aller le présenter et ainsi faire découvrir le projet latence.