Un petit bilan ci dessous de ce que nous avons pu identifier comme source potentielle de problèmes:
Les interférences dans la communication des robots en scratch via les dongles sont le premier problème. voilà les différentes pistes pour mitiger ceci:
-
Nos robot peuvent être répartis sur 3 canaux. A priori il vaut mieux répartir équitablement les robots entre ces 3 canaux en effectuant lesc pairages. Avec Scratch, dès qu’il y a plus de 6 robots par canal on constate facilement les interférences
-
A l’EPFL, il y a un réseau wifi d’un laboratoire de recherche qui fait du swarm (sycamore) qui overlappe avec notre premier canal. durant les formations, on a donc gardé les canaux 2 et 3.
-
certains adaptateurs USB C - USB créent des interférences dans nos fréquences, il faut les éviter.
Le plus petit ci-dessus est le meilleur, l’autre blanc marchait de manière acceptable
à éviter
- Les ordinateurs des profs « cherchaient » un wifi et créaient des interférences (plus que si ils sont bien définis, connectés à un wifi bien déterminé). en stoppant le wifi la situation s’est améliorée
- les programmes réalisés dans le cadre de ces exercices envoyaient beaucoup de messages (boucle infinie avec allumage d’une led par exemple)
Nous conseillons de fonctionner plus par événements, d’utiliser des instructions blocantes (i.e. qui ont une certaine durée) ou d’ajouter une temporisation de 0.1s
De notre coté nous avons aussi pris des notes pour la révision de l’extension scratch-thymio pour limiter les échanges de messages.
Les autres problèmes rencontrés
- un bug connu de Thymio Suite 2.3 sur les ordinateurs M1 avec Big Sur uniquement: problème d’affichage des polices dans la fenetre d’accueil de Thymio Suite. Pour le résoudre il faut mettre a jour vers Monterey, ou (sauf erreur, Michael tu me corriges si jamais) installer la police Roboto Google Fonts
Making the web more beautiful, fast, and open through great typography
- la précision des mouvements et la détection des distances: dessiner un carré précis sera toujours difficile a cause du fait que le stylo peut bouger, des frottements, du fait que le bloc « avancer de x cm / tourner de y° » sera toujours basé sur une vitesse pendant une certaine durée, qui n’est pas reproductible de robot en robot. C’est un exercice voué à créer la déception pour un prof de math; je suggérerais de mettre l’accent sur des comportements réactifs, ou, s’il faut faire une séquence, une séquence de couleur / bruit / mouvement (chorégraphie) dans laquelle la variation est mieux tolérée que lors du dessin géométrique. De même, la détection d’un objet a une certaine distance en cm n’est pas fiable car cela dépend de la réflectivité / couleur du matériau. On peut aussi imaginer des exercices centrés sur ces réalités physiques (par exemple l’exercice de Morgane en VPL3 dans « VPL education » pour comprendre les capteurs horizontaux)