Version actuelle datée du 15 juin 2018 à 21:35

Présentation générale

Généralités

• Titre du projet: Peach'IncBot (A défaut d'un meilleur nom)
• Description: Développer une interface sous la forme d'une brique simple (type puzzle) permettant de prévoir le déplacement d'un robot
• Membres de l'équipe: Maëva Delaporte, Simon Blas

Description

L'apprentissage de l'informatique très tôt dans la scolarité est un atout pour comprendre le monde numérique qui nous entoure.

Cependant, les interfaces traditionnelles d'accès à l'informatique ne sont pas adaptées aux jeunes enfants. En effet, ils ne sont généralement pas lecteurs et leur apprentissage passe essentiellement par le toucher. Notre projet consiste donc à créer un jeu pour enfant les introduisant à la programmation par blocs. L'enfant aurait à sa disposition un tapis de jeu, un ensemble de briques, un robot et un ordinateur. L'enfant devrait construire un chemin formé d'une succession de briques miniatures. Le chemin alors formé serait alors envoyé à l'ordinateur où il serait affiché. Le robot suivrait ensuite les instructions données et réaliserait le chemin correspondant sur le tapis. Les briques ne sont pas à l'échelle du robot, le robot ne pourra donc pas rouler dessus. Elles seront assemblées sous forme de pièces de puzzle.

Objectifs

Ce projet a pour objectif d'éduquer les enfants à la programmation dès leur plus jeune âge de manière ludique.

Pour cela, les différentes parties à réaliser seront:

• Développer une pièce de puzzle en bois que l'on puisse assembler avec d'autres afin de pouvoir construire des chemins;
• Ajouter un système permettant de relier électriquement entre eux les morceaux de puzzle et de transmettre le chemin à un PC;
• Guider le robot sur le chemin correspondant;
• Associer le déplacement à un code informatique pour amener les plus grands vers la programmation par bloc par exemple.

Analyse du projet

Positionnement par rapport à l'existant

Les robots qui ont déjà été créés dans ce secteur se présentent sous deux formes.

Soit, leur programmation est assurée par un assemblage de pièces à disposer sur un petit puzzle. Dans ce cas, la disposition des pièces ne reflète pas directement le chemin que va prendre le robot, mais simplement l'ordre dans lequel il va effectuer les instructions. C'est le cas notamment du robot Cubetto.

Soit, la programmation est faite à même le robot, à l'aide de touches, généralement disposées sur le "dos" du robot. L'ordre dans lequel on appuie sur les touches correspond alors à la séquence d'instructions que le robot va ensuite suivre lorsqu'on appuiera sur le bouton de démarrage. C'est le cas du Beebot par exemple.

Dans les deux cas, dans le but d'un apprentissage ludique, les robots sont fournis avec un tapis de jeu afin de fournir un support amusant et des objectifs aux enfants.

Notre robot se différenciera de ses concurrents de la façon suivante: la programmation de celui-ci sera assurée par l'assemblage de pièces de puzzle qui auront la forme du chemin que le robot va parcourir. L'enfant pourra donc directement visualiser le chemin qu'il programme, en dehors d'une échelle différente. Le positionnement des pièces se traduira en un programme qui sera alors téléversé vers le robot. SI l'enfant est plus âgé, il pourra également activer un mode plus avancé où le forme du circuit ne représentera plus les directions que prendra le robot mais la forme du programme. Par exemple, une boucle for sera représentée par une boucle de blocs, avec au début et à la fin de la boucle des blocs spéciaux pour l'indiquer. On peut également introduire la notion de choix avec un bloc if qui créera une divergence des chemins que le robot pourrait prendre.

Analyse du premier concurrent

Un jeu aboutit et similaire au sujet existe déjà et s'appelle Cubetto.

Fabriqué en bois robuste, Cubetto fera découvrir le monde de la programmation à votre enfant. Sans écran, intuitif et prêt à l’emploi. Un langage de programmation à toucher et à manipuler comme des LEGO®. À chaque bloc, une action. Combinez-les pour créer des programmes.

La programmation du Cubetto se fait au moyen de petites pièces de couleur, à insérer dans un certain ordre sur une plaque prévue à cet effet. L'ordre dans lequel est inséré les pièces correspond à l'ordre dans lequel seront effectuées les actions. Une fois les pièces disposées sur le plateau, il suffit d'appuyer sur un bouton pour que le robot suive le programme réalisé. Pour un jeu ludique, le Cubetto est fourni avec des tapis de jeu, qui représentent différents univers. L'enfant dispose ensuite de missions à réaliser sur les différentes cartes, avec pour objectif esquiver certains obstacles ou passer par certains points, objectifs qui lui raconteront une histoire et lui apprendront à se servir des pièces de programmation plus complexes. Il dispose notamment d'un cube bleu, qui permet d'exécuter une séquence d'actions programmées sur une planche à part, et dont l'utilisation devient nécessaire lors de la réalisation des chemins les plus complexes. En effet, sans cette brique, il n'y pas assez d'espace sur la planche-puzzle pour mettre tous les mouvements dont il a besoin.

Analyse du second concurrent

Le second concurrent est Beebot ou Mouse, Code & Go. Ces deux jouets fonctionnent de la même manière.

Leur programmation est assurée via les boutons situés sur leur dos. On appuie sur les boutons en séquence pour créer un programme puis on appuie sur un bouton pour lancer l'exécution. Le robot est donc relativement simpliste, et facile à comprendre pour les enfants.

Scénario d'usage du produit ou du concept envisagé

Billy est un jeune enfant qui s'ennuie. Dehors il pleut, et tous ses amis sont occupés. Ses parents sont partis faire des courses et l'ont laissé seul à la maison (il ne sont pas très responsables...). Heureusement, il a à sa disposition, un magnifique jeu: le Peach'IncBot! Grâce à lui, il va pouvoir passer son après midi sans déprimer.

Il commence par déplier son tapis de jeu le plus grand possible. Ensuite, il sort toutes ses briques de construction, et s'attelle à créer un chemin qui passerait par tous les dragons, afin que son robot chevalier puisse se charger de ce problème qui terrorise le royaume depuis plusieurs semaines. C'est un défi relativement simple, les dragons ne sont pas très dispersés et Billy parvient sans trop de peine à tous les atteindre avec les briques à sa disposition.

Ensuite se pose un défi plus intéressant. Billy doit faire en sorte que son chevalier réussisse à passer dans toutes les villes afin de déposer les princesses précédemment délivrées et leur annoncer la nouvelle de sa victoire. Il va cette fois-ci devoir réaliser un chemin aussi optimisé que possible, et ne faire aucun détour car il a juste assez de briques pour réaliser ce parcours.

Réponses aux questions difficiles

Quelle alimentation?

Notre puzzle comportera un bloc de base, comportant la batterie nécessaire à alimenter toutes les pièces qui y seront reliées. La transmission d'énergie et d'information se fera via des picots montés sur ressorts. Lorsque deux briques seront mises en contact, le picot entrera dans la cavité correspondante sur la deuxième brique. Chaque brique aura donc deux côtés, un mâle et un femelle.

Comment les briques vont-elles communiquer?

Les briques utiliseront la communication série. La brique principale utilisera la communication Bluetooth avec l'ordinateur.

Comment faire pour différencier les briques?

Chaque brique aura la forme correspondant à l'instruction qu'elle enverra au robot. Les briques seront de plus colorées pour correspondre au déplacement correspondant et rendre le tout plus visuel pour les enfants. La brique de départ sera unique. Chaque brique aura un identifiant unique qui pourra être transmis via la liaison série. L'identifiant permettra à la brique principale de savoir quelle est la forme de la brique correspondante pour la traduire en instructions.

Quelle sécurité vis-à-vis des enfants?

Les picots permettraient d'éviter aux enfants de se blesser. Si l'enfant appuie sur un picot, celui-ci se rétracte dans sa cavité car il est monté sur ressort, il ne peut donc pas vraiment se blesser avec. Le ressort permet de plaquer les picots l'un sur l'autre.

Préparation du projet

Cahier des charges

Choix techniques : matériel et logiciel

Partie matériel

On peut distinguer trois parties:

Partie briques

Brique principale

• Pile 9V [1] + Cordon d'alimentation [2]
• Arduino Uno [3]
• Module bluetooth pour Arduino [4]
• PCB (réalisé à Polytech par nous)
• 4*picots mâle [5]
• 4*ressorts [6]

(Briques de déplacement)*n

• Microcontrôleur Atmega 328p [7]
• PCB (réalisé à Polytech par nous)
• 8*picots mâle [8]
• 8*picots femelle [9]
• 8*ressorts [10]

Nous comptons réaliser au moins huit briques de base. Il nous faudra de plus ajouter des boutons poussoir [11] et des afficheurs 7-segments [12] pour les briques de boucle tant que, des leds [13] pour les boucle if, et des potentiomètres [14] pour les capteurs.

Brique de fins

• Microcontrôleur Atmega 328p [15]
• PCB (réalisé à Polytech par nous)
• 4*picots femelle [16]

Il faudra une brique de fin pour chaque chemin créé.

Partie robot mobile

• Pile 9V [17] + Cordon d'alimentation [18]
• Kit roue + moteur *2 [19]
• Roue folle [20]
• Contrôleur de moteur [21]
• Arduino uno [22]
• Arduino shield pour bluetooth [23]
• Capteur ultrason [24]

Piste de jeu

Nous verrons si nous pouvons la faire dans le temps imparti. Ce n'est pas une priorité.

Matériau

Bois [25]

Des câbles pour remplacer les pistes qui permettront la liaison série dans la version finale, mais qui seront peut pratiques en phase de test.

Partie logiciel

Arduino IDE, Cad Designer, Altium Designer, Programmateur Atmega 328p

Liste des tâches à effectuer

1. Partie briques :
   1. Programmer les Atmega328p, notamment pour la liaison série.
   2. Programmer l'arduino uno de la brique principale.
   3. Créer les boites pour les différentes briques, brique principale, de déplacement et de fin.
   4. Créer les PCB pour les différentes briques, brique principale, de déplacement et de fin.
2. Partie robot :
   1. Construire le robot.
   2. Programmer le robot.
3. Partie ordinateur :
   1. Réaliser le programme sur ordinateur.
4. Partie "tapis de jeu" :
   1. Réaliser le tapis.

Calendrier prévisionnel

• Découverte et analyse du projet (15 heures) dont 10H en cours.
• Programmation des liaisons séries des Atmega328p, d'abord sur arduino puis sur 328p
• Programmation de l'Arduino uno pour transformer les données reçues en un programme.
• Conception et réalisation des PCB.
• Conception et réalisation des boites des briques.
• Construction du robot.
• Programmation de l'Arduino uno du robot.
• Réalisation de la communication Bluetooth entre les briques et l'ordinateur et l'ordinateur et le robot.
• Réalisation du tapis de jeu.
• Réaliser une application sur ordinateur

Réalisation du Projet

Feuille d'heures

Prologue

La première étape de notre projet a été de définir clairement ce qui était attendu de nous. Au départ, l'idée était relativement vague même si les bases étaient posées. Nous avons du définir quel type de robot nous allions construire, et notamment savoir si il devait rouler sur les briques de programmation ou, simplement suivre un chemin similaire à celui formé par celles-ci.
Le type de communication entre les briques et la façon de cartographier le réseau de briques a également du être trouvé. Nous étions à la base décidés à réaliser une cartographie linéaire de façon à suivre le chemin que notre robot allait parcourir, mais monsieur Boé a finalement établi qu'une cartographie complète en utilisant un algorithme de Parse Tree serait plus intéressante.
La question de l'alimentation a également été abordée, et on alimentera toutes les briques avec la brique principale.
Nous avons décidé d'utiliser la communication Bluetooth entre les Arduinos du robot et de la brique principale et l'ordinateur.
Etablir si le robot allait disposer de capteurs ou non. Finalement, notre robot aura un capteur de distance permettant de servir de condition au if qui sera l'une des briques de programmation.
Décider de la forme qu'aura nos briques. Chaque brique disposera de quatre côtés, qui pourront chacun être relié à une autre brique. La boucle while sera composée d'une brique de début de while et d'une brique de fin de while. Sur la brique de début sera deux boutons et un afficheur permettant d'indiquer combien de fois la boucle sera faite, et de reset la boucle. La boucle if pourra prendre une brique capteur sur un de ses côtés, et indiquera un choix entre aller dans deux directions parmi les trois possibles (Gauche, Droite, Tout droit). Elle disposera d'un potentiomètre pour régler la distance de choix.
Enfin, il a été nécessaire d'établir tous les types de briques que l'on désirait réaliser et les limites qui pouvaient éventuellement se présenter. Nous devons réaliser les briques suivantes:

• Avancer tout droit
• Tourner à gauche
• Tourner à droite
• Faire un if basé sur le capteur du robot
• Faire une boucle while, avec un bouton pour déterminer combien de fois réaliser la boucle
• Faire une brique de "fin" pour que l'enfant puisse indiquer à la brique principale que son chemin est achevé.

Semaine 1

La grande remise en question (sur l'ensemble de la semaine):

Ceci est un résumé des questions que l'on s'est posés pendant la semaine 1. La majorité ont trouvé leur réponse cette même semaine, réponse qui sera écrite sur cette même page potentiellement plus tard. Il est également à noter que nous avons fait beaucoup d'avant-arrière lors de cette semaine, avec l'apparition de problèmes et d'idées au fur et à mesure que nous réfléchissions, et avec une confrontation de notre premier concept à nos tuteurs.

• Petites briques ou grosses briques.
• Lire le chemin de façon linéaire ou non.
• Combien de ports série sur les briques, quelle forme, quel lien entre les briques?
• Picots ou lamelles pour les contacts.
• Attiny85 puis atmega328p comme microcontrôleur (32 pins = plus que suffisant, 8 pins = pas du tout suffisant).
• Comment faire pour pouvoir lire tout le chemin de façon fiable
• Quelle sera la forme des briques?
• Dans quel ordre va-t-on réaliser le projet/ Quelles sont les priorités?
• Communication Bluetooth avec le robot et l'ordinateur?
• Piles 9V en guise de batterie (arduino alimenté en 9V puis sort du 5V suffisant à tout le reste)?
• Le robot devrait-il disposer de capteurs?
• Ajout des boucles tant que et des conditions basées sur les capteurs
• Quelle sera la forme des "tant que" et des "si"
• Générer le programme puis le transmettre, ou transmettre un code qui permettra au robot de générer son programme?
• Deux niveaux de jeu, un pour les jeunes enfants et un pour les un peu moins jeunes => Le chemin ressemble à celui que va parcourir le robot/ Le chemin créé est linéaire et représente la progression du programme
• Comment gérer les boucles?
• Inclure une brique de fin pour savoir quand l'enfant a fini son programme
• En quelle quantité va-t-on réaliser chaque brique pour le prototype?
• Quels boutons/leds/potars mettre sur les briques spéciales/ quelles briques spéciales?
• Le tapis de jeu sera-t-il créé un jour?

Semaine 2

Tests

Après de multiples tests, nous avons réussi à établir une connexion entre deux Arduinos, qui utilisent l'Atmega328p que l'on compte utiliser pour nos briques. Nous avons d'abord établi une connexion entre deux ports série physique, en apprenant qu'il était nécessaire de mette un délai entre chaque envoi de message afin d'éviter de surcharger la connexion, puis entre deux ports série "Virtuels/soft", à l'aide de la bibliothèque SoftSerial fournie par Arduino. Nous avons enfin réussi à établir une connexion entre deux ports série par Arduino, soit l'Atmega328p communiquait avec son homologue via non pas un mais deux ports série. Il est impossible d'utiliser plusieurs ports série en même temps, nous avons donc du ajouter des liaisons digitales afin de confirmer l'envoi entre les deux Arduinos. En effet, si il est impossible de scruter les quatre ports série en même temps, il est en revanche très simple de scruter 4 ports digitaux sur un Atmega, et de scruter le port série correspondant lorsque le port digital le demande. Une fois la demande reçue, l'Atmega receveur va répondre afin d'initier la communication. Pendant la communication, les Arduinos ne peuvent ni recevoir, ni émettre sur d'autres ports, il est donc impératif que le receveur puisse confirmer sa disponibilité avant que l'envoyeur n'entame la communication. Une fois l'envoi de messages sur quatre ports pleinement implémenté, nous commençerons à établir le protocole pour établir la forme du chemin à emprunter par le robot.

Poursuite des tests sur la liaison série. Nous avons réalisé quatre liaisons série soft entre deux Arduinos. Le premier test, avec d'un côté l'émission et de l'autre côté la réception, a bien fonctionné, on arrive à envoyer des messages successivement sur les quatre ports série du premier Arduino, pour les recevoir sur les quatre ports série du second Arduino. Nous avons également réussi à établir une communication entre les deux Arduinos, en recevant des messages sur un port série et en les renvoyant sur un autre. Cependant, nous n'avons pas réussi à recevoir des messages sur plus d'un port série pour les renvoyer. Ce sera donc le sujet principal de la séance suivante.

Le principal problème rencontré pour la liaison série est la synchronisation entre les deux blocs. Il arrive que l'un des deux blocs parvienne à envoyer un message sur le port série à l'autre, mais que celui n'arrive pas à le lire car il n'écoute pas assez longtemps. La majeure partie de ces deux heures à été allouée à trouver ce problème et à essayer de trouver des moyens de le résoudre. Nous avons commencer à programmer ce moyen, et nous espérons enfin réussir à la séance suivante.

Recherches

Cette semaine, nous nous sommes renseignés sur les différentes librairies disponibles pour établir des liaisons séries soft et nous avons découvert NeoSWSerial qui est réputée pour être plus fiable que Software Serial. Celle-ci permet d'envoyer et de recevoir en même temps et utilise les interruptions au lieu de la scrutation. Nous allons donc essayer de faire deux programmes, un qui fonctionne sans interruptions et un avec.

• Recherches simulateurs

Notre projet consiste à créer un chemin à partir de blocs et dans chacun de ces blocs, nous aurons un ATMega328p. Pour les tests du programme de liaison série nous utilisons donc des Arduino UNO qui comportent ce type de processeur. Or, nous n'avons pas 10 Arduino à notre disposition pour simuler un chemin et même si c'était le cas, ce serait encombrant. Nous avons alors eu l'idée de chercher des simulateurs d'Arduino pour réaliser la simulation de notre chemin. Il existe plusieurs simulateurs, certains en ligne et d'autres à télécharger, voici les plus connus:

• • 123D
  • Circuits.io
  • Virtual Breadbord
  • Node-RED
  • unoardusim

Malheureusement, aucun de ces simulateurs n'a fait notre bonheur, soit il était impossible de téléverser notre programme sur l'Arduino Virtuel soit celui-ci ne fonctionnait que pour des programmes basiques.

Semaines 3/4

Ces deux semaines ont été l'occasion de tester diverses façons de faire fonctionner la liaison série. Grâce aux suggestions de Monsieur Boé, nous allons utiliser la fonction millis() pour réaliser des timeouts lors de l'envoi série. De cette façon, si le programme n'a pas de réponse pendant plus d'une seconde par exemple il abandonne la tentative d'envoi. Ces timeouts sont principalement utilisés pour l'envoi par scrutation. Pendant ces deux semaines, nous nous sommes séparés le travail en deux parties pour tenter de réaliser l'envoi série multi ports de deux façons différentes: scrutation ou interruptions.

L'envoi par scrutation est plus simple à réaliser en théorie, mais moins fiable car il requiert l'utilisation de timeouts, et est relativement sensible aux erreurs de lecture sur les pins. Au bout de ces deux semaines, le fonctionnement par scrutation a fini par fonctionner pour la communication entre la brique principale et une brique esclave. La communication série s'est cependant avérée être difficile à mettre en œuvre, à cause de problèmes de synchronisation entre les blocs qui ne font que s'accroitre avec le nombre de briques impliquées. De plus, les pins des Arduinos ne sont pas par défaut à 0 et semblent au contraire prendre des valeurs aléatoires, ce qui complique encore la tâche puisqu'ils peuvent croire qu'une autre brique essaye d'initier une communication série alors que ce n'est pas le cas. Ces problèmes ont pour l'instant été résolus à l'aide de timeouts, en attendant de trouver une solution plus satisfaisante.

Après de multiples tentatives, nous avons réussi à faire fonctionner la communication entre l'arduino maitre et un arduino esclave de façon fiable, elle à fonctionné sur tous les tests réalisés jusqu'à présent. Cependant, lors de la mise en série de deux briques esclaves et d'une brique maitre, le message ne va pas plus loin que la première brique esclave. Les deux heures du lundi 12 février seront consacrées à résoudre ce problème. Si c'est une réussite, la liaison série par scrutation sera pleinement opérationnelle et nous pourrons enfin passer à l'étape suivante du projet.

• Tests envoi par interruptions

Pour ce qui est du programme par interruption il n'est malheureusement pas fonctionnel, nous allons donc utiliser le programme par scrutation pour rentrer dans le vif du sujet dans perdre plus de temps.

Le problème du programme par interruption est que les librairies de communication série utilise aussi les interruptions ou plutôt elles donnent une valeur aux ports de l'arduino qui complique l'utilisation des interruptions. De plus, après plusieurs tests, je ne suis pas en mesure d'expliquer pourquoi je ne parviens pas à faire fonctionner plusieurs liaisons séries soft grâce à NeoSWSerial, j'ai beau faire ce qui est indiqué dans le Readme et dans la librairie elle même, le plus simple des programmes refuse de tourner à partir de 3 liaisons séries. Mais comme dit précédemment, le programme par scrutation commence à prendre réellement forme alors nous n'allons pas perdre plus de temps là dessus aussi intéressant que je trouve cela.

On peut voir ici le protocole pour l'envoi sur la liaison une d'une donnée.

Semaine 5

Suite à l'échec de la première tentative de réparation du programme, nous avons du trouver de nouvelles façons de faire fonctionner le programme. Après quelques heures de réflexion en dehors du projet, nous avons enfin eu une idée qui aurait probablement du arriver longtemps auparavant: les valeurs aléatoires que l'on obtenait sur les pins non connectés sont inévitables. Il faut donc brancher sur tous les pins des résistances pull down, qui mettrons par défaut les pins à zéro et qui permettront quand même de brancher un pin extérieur. De cette façon, les valeurs sur les pins ne fluctueront pas.

Nous nous sommes rendus compte que la cause d'une partie des dysfonctionnements est un jumper qui semble ne pas transmettre de valeur et ne fonctionne pas.

Après une série de tests sur les valeurs envoyées et lues par les analogWrite et Read (je pensais que l'on écrivait et lisait des valeurs entre 0 et 255, mais il s'avère qu'il peut y avoir des valeurs de 0 à 1023, et que la valeur moyenne quand aucun signal n'est envoyé commence à 700 et diminue lentement tant que rien n'est envoyé, tandis que la valeur moyenne quand un signal 1023 est envoyé semble se situer entre 930 et 1001), et une correction de l'attribution des pins dans le programme (j'avais mit 1 et 2 au lieu de A1 et A2) le programme d'échange de données série à fonctionné sur trois Arduinos consécutifs! L'Arduino maitre a envoyé un signal au premier esclave, qui a ensuite répondu sur ses deux ports série connectés, à reçu une réponse du deuxième Arduino esclave et l'a transmise au Maitre. Ce programme a donc permis au maitre de cartographier un réseau de deux briques, mais ce avec quatre liaisons séries théoriques. Le programme est capable de reconnaitre un port non connecté grâce aux timeouts, et de renvoyer tous les messages reçus après le premier au maitre.

La prochaine étape consistera a programmer des blocs de différents types (droit, gauche, droite, if, début while, fin while, condition, fin parcours), qui auront chacun un identifiant propre. Grâce à la commande de matériel qui a été faite, nous pourrons passer de la programmation sur Arduino (qui disposent d'un microprocesseur Atméga328p), à la programmation en direct sur des 328P, afin de pouvoir constituer des réseaux plus grands et ainsi augmenter l'échelle de nos tests. Chaque bloc sera caractérisé par son identifiant, unique, codé sur 4 bits?, son type, codé sur 4 bits?, ainsi que des caractèristique particulières, codées sur un deuxième octet, avec par exemple le nombre de fois qu'une boucle while doit être executée, ou la valeur a atteindre pour une condition sur un if.

Le code ci-dessous permet de lire un port série sur réception d'un un sur le pin de hanshake.

Semaine 6

L'essentiel des quatre heures du mercredi ont donc été occupées à comprendre comment programmer l'Atmega328p en passant par l'Arduino IDE, et en utilisant un autre 328p sur un arduino comme programmateur. Ma première tentative de programmer le 328p en utilisant l'oscillateur interne 8MHz de celui-ci s'est soldée par un échec, cet oscillateur n'est pas suffisamment fiable pour qu'on puisse l'utiliser. Cet échec est malheureux car il va complexifier légèrement le design du PCB, qui est réalisé en parallèle. En effet, l'utilisation de l'oscillateur ne demande aucun composant externe, alors que l'utilisation d'une clock extérieure demande elle, un quartz de 16 MHz, deux condensateurs de 22pF et une résistance pull-down supplémentaire pour le pin de reset. Il m'a de plus nécessité un certain temps avant de réaliser que la programmation via l'oscillateur interne ne fonctionnerait pas. Cependant, après quelque échec, j'ai réussi à téléverser mon programme directement sur un 328p, la prochaine étape consista donc à vérifier que tout était toujours fonctionnel en utilisant un 328p en lieu et place d'un arduino.

L'objectif des autres heures de cette semaine a été de passer d'un programme de test qui fonctionne sans erreurs de façon théorique à un programme qui rempli de façon satisfaisante les conditions de notre projet. En effet, la complication jusque là a été l'utilisation de multiples ports séries, qui ne peuvent être activés simultanément alors que les demandes de communication, elles, peuvent arriver simultanément. Un mélange de plusieurs solutions à été appliqué pour résoudre ce problème, solutions détaillées plus haut, et le programme de communication obtenu est relativement complexe par rapport à l'apparente simplicité de l'objectif de base, ce qui justifie la nécessité de 5 semaines de travail pour obtenir ce résultat.

Le problème avec ce programme est cependant qu'au lieu de former un mot grâce à la succession de blocs parcourus, il se contente de transmettre un mot depuis le bloc maitre jusqu'au bloc de fin, puis de voir ce mot revenir. La première étape de la semaine a donc été pour moi de construire un mot a chaque bloc passé, pour au final récupérer sur le maitre un mot représentant correctement la chaine de blocs finale. Heureusement, cette conversion a été simple a réaliser grâce à la forme du programme utilisé. L'étape logique suivante est donc d'agrandir la chaine afin de prouver la fiabilité du programme sur un plus grand nombre de blocs, nous avons jusque là été limités à trois blocs, un maitre et deux esclaves. Afin d'augmenter la taille du réseau, il faudra donc commencer à programmer les Atmega328p directement, sans plus passer par les Arduinos, en espérant que les 328p commandés arrivent relativement vite.

C'est pourquoi nous avons commencé la confection d'un premier PCB, un prototype qui sera modifié et amélioré par la suite. Je ne vais pas expliquer réellement comment faire un PCB dans ce wiki, de très bons tutoriels peuvent être trouvés sur internet selon le logiciel utilisés. Par contre, en débutant le design du schématique du circuit, nous avons réalisés qu'il nous fallait ajouter d'autres composants qui n'étaient pas prévus dans la liste initiale. De plus, il a fallu créer des composants comme le quartz que je n'ai malheureusement pas trouvé directement dans la librairie des composants. Même si faire un PCB n'est pas très compliqué, cela prend quand même beaucoup de temps.

En parallèle au développement de la carte et à celui du PCB, nous devons également en permanence nous remettre en question sur le fonctionnement exact de notre projet fini. En effet, de nombreux doutes subsistent, que nous résolvons petit à petit. La question de la forme finale qu'aura notre circuit, ainsi que la forme finale des briques est relativement complexe et mérite une grande attention. La forme et le fonctionnement que prendront les briques particulières, à savoir le while, le if, et la brique de condition, sont également en questionnement. La quantité de composants qui seront à prendre en compte sur le PCB a également énormément évolué, en passant de simplement un 328P, à celui-ci plus 5 résistances pull-down, un quartz et deux condensateurs. La question de la nécessité d'un composant pour maintenir la puissance à 5 volts tout au long du chemin s'est également présentée, mais ça n'est en fin de compte pas nécessaire. Enfin, nous avons trouvé une nouvelle façon de connecter les blocs d'une façon non dangereuse pour les enfants, en n'utilisant non plus des ressorts pour assurer les connections, mais en faisant ressortir les connecteurs femelle plutôt que les connecteurs mâle. De cette façon, les enfants ne pourront pas se blesser sur les connecteurs mâles qui sont rentrés, et se blesser avec un connecteur femelle semble être très compliqué. Toutes ces questions, qui ne nous apparaissent que maintenant, donc assez tardivement, doivent être résolues et le sont au fur et à mesure.

Malheureusement, par un manque d'organisation de notre part, ou de recherche, le PCB peine à avancer puisque nous changeons constamment ce qui doit se trouver sur la carte et connecté à quel pin.

La photo ci-dessous indique quel montage effectuer pour reprogrammer un Atmega328p. Au préalable, il faut avoir gravé la séquence d'initialisation sur l'Atmega328p.

Semaine 7

Lors de cette séance, l'objectif a été de faire fonctionner les modules bluetooth pour Arduino, ainsi que rendre le programme de communication série fonctionnel en digital et non plus en analogique. En effet, avec notre alimentation actuelle, nous risquons de perdre en tension dans les briques esclaves à mesure que les piles se déchargent, ce qui risque de fausser les seuils de tension que l'on a passé dans le programme, notamment pour le handshake entre deux arduinos. Afin d'éviter ce problème, nous avons donc utilisé les pins uniquement en mode digital, ce que l'on aurait pu faire dès le départ au demeurant. Après quelques modifications, le programme s'est avèré tout aussi fonctionnel en mode digital qu'en mode analogue.

Ensuite, il a fallu réussir à établir une communication entre l'ordinateur et le module HC-06 branché sur un arduino. En effet, dans le sujet qui nous a été donné, un ordinateur doit servir de relai entre les briques d'un côté et le robot de l'autre. Cependant, pour des raisons de simplicité, nous avons décidé de d'abord essayer de transmettre directement le chemin des briques au robot, et de faire en sorte que l'ordinateur puisse ensuite prendre la place des briques si l'on a le temps de réaliser la partie "pour aller plus loin" de notre projet. Dans cette optique, nous allons devoir un installer un module non pas HC-06 mais HC-05 sur notre brique principale, car le module HC-06 ne peut fonctionner qu'en tant qu'esclave, tandis que le HC-05 est configurable en maitre ou esclave. Et nous avons besoin d'un maitre et d'un esclave ici.

Cependant, nous savons désormais communiquer avec le module bluetooth, le configurer et le connecter à l'ordinateur. Dès que possible, nous établirons une communication entre les deux modules bluetooth, et le message pourra alors être transmis directement entre robot et brique. La dernière étape sera alors de réaliser le programme de décodage du chemin pour le robot, et la partie informatique du projet, en dehors du "aller plus loin", sera complétée.

Le protocole de reconnaissance de briques que nous allons utiliser sera sur un ou deux octets, en fonction de la brique et utilisera le format suivant:

(4 bits type de brique) (4 bits identifiant de la brique) (8 bits de donnee(optionnels))

Les 8 bits de donnée optionnels sont utilisés uniquement par les briques while et if. Les codes seront les suivants:

• Tout droit: 0001
• Virage à gauche: 0010
• Virage à droite: 0011
• Début while: 0100
• Fin while: 0101
• If: 0110
• Fin parcours: 0111

Les Id des briques seront attribuées au préalable à chaque brique de façon à ne pas avoir de doublon.

En parallèle à cela, nous avons commencé le design des boîtes sur OnShape, le logiciel 3D pourrait nous donner des idées sur comment assembler le tout. AU début nous pensions faire deux liaisons séries uniquement et les briques devaient s'emboîter en se posant l'une sur l'autre. Cependant en passant à quatre liaisons séries, nous avons trouvé ce design inutilement complexe et nous avons décidé de changer pour une forme simple de cubes comme ci-dessous. Cette fois, les fentes sont sur les côtés.

Le PCB est quasiment terminé, maintenant que nous sommes sûr de ne plus ajouter de composants sur la carte, nous avons tout de même pris des précautions dans le cas où il faudrait réellement en ajouter un en dernière minute et nous comptons relier tous les pins à des header même ceux qui ne sont pas utiles pour le moment car ils le seront peut être plus tard.

Semaine 8

Lors de cette semaine, je me suis concentré sur la création d'un message à envoyer à partir des données reçues par la brique principale du chemin, puis le décodage de ce message en un chemin par le robot.

La première étape a été de décider d'une forme de message à envoyer. Le plus simple consiste à ne garder parmi les chemins reçus que les chemin qui soient finis, cet à dire qui comportent une brique de fin. Si la dernière brique d'un message est une brique de fin, celui-ci est ajouté au message à envoyer. Au bout d'une quantité de temps donnée, la brique principale estime que le chemin a été entièrement cartographié et enverra son message, constitué de plusieurs chemins mis bout à bout au robot. Le robot va ensuite lire ce message et exécuter les instructions une par une.

Pour ce qui est des instructions "tout droit", "à gauche" et "à droite", c'est relativement simple, il reste juste à déterminer l'amplitude de son mouvement. Les instructions "if" et "while" ont d'un autre côté nécessité plus d'attention, puisque l’algorithmique associée à ces deux briques varie en fonction des informations qui leur sont liées. Nous avons décidé de tronquer un des bits de l'Id du if pour le remplacer par la valeur d'un interrupteur, qui permettra de déterminer si le if est un inférieur ou supérieur strict lors de la comparaison. Le nombre de boucles que va effectuer le while est quand à lui stocké dans le caractère de donnée qui la suit. Après quelques tests, la fonction de décryptage fonctionne. Notamment, les cas de plusieurs if sur un même chemin ou de while imbriqués les uns dans les autres est géré.

La prochaine étape consistait donc a rendre le robot mobile, afin de pouvoir le faire rouler avec un message prédéfini en entrée, et de pouvoir calibrer ses fonctions de déplacement, notamment au niveau de la vitesse. Cela s'est fait assez simplement, car nous avons utilisé le même contrôleur de moteurs et les mêmes moteurs que lors de notre projet d'IMA en Peip. Après la réalisation des soudures sur le contrôleur de moteur, le système à fonctionné sans soucis particuliers. Il est maintenant temps de tester le transfert d'information via les modules bluetooth, et si cela fonctionne, faire se mouvoir le robot avec quelques chemins afin de démontrer la faisabilité et l'aboutissement de notre projet.

Après cela, il faudra terminer le design des boites. En effet, celles-ci seront en bois et nous les ferons via la découpeuse laser, nous devons donc réaliser .svg qui sera une vue des découpes. Pour l'instant, l'important est surtout de faire un prototype et voir la taille des encoches nécessaires pour passer les barrettes.

Le PCB a été terminé et gravé, nous avons profité des heures du mercredi pour le souder et nous espérons pouvoir le tester à la prochaine séance.

Si celui là est fonctionnel, quelques changements seront néanmoins à faire comme la taille de la carte. En effet beaucoup d'espace est gâché et non utilisé, le placement des composants peut être largement optimisé. De plus, sur ce PCB, un fil croise les autres alors je vais tester différentes combinaisons de pins pour tenter de faire en sorte que ce ne soit plus le cas. Ce sera seulement après avoir un PCB correct pour les briques que nous en ferons un autre pour le robot.

Semaine 9/10/11

Lors de de ces trois semaines, j'ai principalement essayé puis réussi à configurer les modules bluetooth HC-05. Même si cela peut sembler être une perte de temps, le bon fonctionnement de ces modules est important pour la démonstration, sans cela le robot devra être relié à la brique maitre par un câble, ce qui ne semble pas très intéressant. De plus, les modules étaient en théorie relativement simples à utiliser, cette étape n'aurait donc pas du prendre trop de temps. Cependant, il s'est avéré que passer en mode commande afin de configurer les modules était très difficile. La méthode indiquée pour ces modules, à savoir alimenter le module avec le pin Enable sur High n'a pas fonctionné. Après recherches, il s'est avéré que le pin Enable n'était pas toujours connecté et qu'il fallait mettre directement un jumper sur le pin correspondant de la plaque, à savoir le 34ème pin. De plus, il ne fallait pas utiliser de port soft pour communiquer avec le module mais plutôt se servir de l'arduino pour transmettre directement les messages au module, donc en branchant le module sur les pins 0 et 1 de l'arduino. Enfin, contrairement aux modules HC-06 (qui ne fonctionnent qu'en mode esclave et ne sont donc pas appropriés pour le projet), les modules HC-05 fonctionnent à un baud rate de 38400, et nécessitent les caractères \n et \r pour prendre en compte les commandes envoyées. La combinaison de ces trois facteurs, qu'il m'a fallu du temps pour découvrir, à fait que la configuration de ces modules fut plus complexe que prévu. Cependant, ils sont maintenant configurés correctement, et il ne me reste plus qu'a les tester au début de la semaine 12 pour le confirmer.

En parallèle, j'ai également debuggé mon programme de communication entre briques, qui était de fait moins opérationnel que prévu. Ce problème est normalement réglé, les transmissions entres briques devraient maintenant fonctionner jusqu'à la fin du projet sans que nous ayons besoin de modifier le programme.

Enfin, j'ai pu tester le premier prototype de PCB réalisé par Maëva en utilisant un 328p sur lequel j'ai téléversé un programme correspondant à une brique de fin, et pu confirmer le fait qu'il fonctionnait correctement, tout le chemin est reçu par la brique maitre. Nous pouvons donc nous permettre d'être optimistes pour ce projet, si la communication bluetooth fonctionne comme prévu, nous pourrons faire rouler le robot cette semaine en fonction du chemin que l'on compose avec les briques. La seule étape alors restante sera de polir le projet en y ajoutant les boites pour contenir les PCB, en rendant le robot présentable, et en réalisant plus de boites et PCB pour disposer d'un nombre correct de briques.

Pour la vidéo, nous devrions donc disposer d'un robot et de briques au moins opérationnels, et au mieux disposants tous de PCB et de boites pour l'apparence.

Lors de ces trois semaines, nous avons également créé une version 2.0 du PCB qui est beaucoup plus optimale. Et ensuite une version 3.0 qui sera la finale. Nous avons d'ailleurs fait graver 8 PCB 3.0 pour en avoir dans les briques et faire une démonstration à la fin du projet.

10 boîtes ont été découpées également. Lors de nos premières découpe de boîtes, nous avons rencontré quelques soucis. En effet, les plaques de contreplaquées sont souvent gondolées, donc lorsque l'imprimante fait ses découpe, la distance focale du laser n'est pas la même sur toute la planche ce qui fait parfois qu'elle ne transperce pas tout le matériau. Pour régler le problème c'est assez simple, il suffit de passer doucement derrière les découpes faites par le laser avec un cutter et ainsi couper à la main ce qui restait à faire. C'est assez embêtant car cela prend du temps mais c'est la meilleure solution que j'ai pu trouver.

De plus le gondolement du bois pose un autre soucis, lorsque la découpeuse trace au laser le contour de la boite, celle-ci tombe légèrement, hors quand il reste des découpe à faire à l'intérieur de la boîte ce n'est pas pratique car elle n'est plus droite et à plat, donc les dimensions de découpe ne sont pas correcte. Mais grâce à l'aide et la patience des fabmanager, j'ai découvert qu'il existait un ordre de découpe. Je m'explique la découpeuse va faire attention à plusieurs types de couleurs dans le .svg. Par exemple la première couche est celle que l'on fait en premier et elle est noire, elle correspond à la gravure. Ensuite, la deuxième est rouge et correspond à une découpe tout comme la bleue qui vient en troisième. Donc pour régler mon problème, c'est à dire le fait qu'elle découpe le contour de la boîte avant son intérieur, il suffit de mettre ce que je veux découper en priorité en rouge et le contour en bleu.

Ceci est un module buetoothhc-05, identique à ceux utilisé lors de la réalisation de ce projet.

Semaine 12

Après tests, le bluetooth fonctionne, le robot peut donc se déplacer en fonction du chemin envoyé par la brique maitre via bluetooth. Pour cela, un chemin formé de trois arduinos et d'un 328p sur Pcb a été formé, et le tout fonctionne parfaitement. Il ne reste donc plus qu'a imprimer, souder et tester les pcb en plus grande série pour obtenir des chemins plus long. Dans le même temps, le prototype de boite est terminé, il ne reste également plus qu'a la découper, puis trouver comment tout fixer à l'intérieur d'une boite.

Il reste à designer les pcb spécifiques de la brique maitre et du robot, deux blocs qui utilisent un arduino et ne demandent donc pas le même type de pcb. Il reste également à faire une boite de la bonne taille pour le robot.

Le code couleur des briques sera le suivant:

- Tout droit: vert

- A gauche: rouge

- A droite: bleu

- If: jaune

- While: violet pastel

- Fin while: rose pastel

- End: Noir

- Maitre: Quadrillage noir et blanc

Le robot ne sera probablement pas coloré, mais ses yeux seront le capteur ultrason, et nous penserons peut-être à lui dessiner une bouche ou des parties de corps pour le faire ressembler à un animal ou une personne. Nous en avons dessiné un semblable à celui de Cubetto c'est à dire :

Suite à une erreur bête de ma part, nous allons devoir redécouper toutes les boîtes. En effet, les PCB mesurent 5.2x3.5cm et mes boîtes 6x6cm je pensais avoir pris 8mm de marges et pouvoir tout assembler tranquillement. Seulement, je n'avais pas pensé aux encoches qui permettent de fermer la boîtes. En effet, des encoches sont dessinées et découpées sur tous les côtés de la boîtes pour maintenir les faces entre elles et celles ci ont une profondeur de 5mm. Donc pour m'exprimer plus clairement, la boîte fait 6cm à l'extérieur par contre à l'intérieur c'est un cube de 5x5cm et le PCB est trop grand pour rentrer. Je vais donc faire des briques de 7x7cm.

Une fois les boîtes découpées, nous avons pu percer les trous qui vont permettre aux vis d'entrer et de fixer le PCB. Nous avons d'ailleurs fraisé pour que la boîte ne soit pas bancale à cause de la tête de la vis. Grâce à cela la tête de la vis est à ras du bois et nous n'avons aucun soucis de stabilité.

Ensuite, nous avons fixé les PCB et collé grâce à la superglue les barrettes femelles. C'était le moyen le plus simple et rapide auquel nous avons pensé. De plus la résistance mécanique de la super glue est largement suffisante pour résister à la force des enfants.

Pour fixer les barrettes mâles, nous avons confectionné une pièce en 3D. L'impression étant plutôt longue, nous en avons profité pour peindre les boites avec le code couleur ci-dessus.

Nous pensions que la pièce 3D imprimée fonctionnait plutôt bien seulement une fois une brique assemblé, nous avons remarqué que les deux barrettes ne s'emboitaient pas réellement et nous avons du tout démonter. Par manque de temps, nous n'avons pas réimprimé de pièce 3D et nous avons décider de ne pas fixer la barrette mâle mais de la maintenir nous même quand nous testerons le jeu assemblé.

D'ailleurs, pour assembler les boîtes il a fallu énormément d'heures de soudure. Nous avions réellement beaucoup trop sous estimé le temps que cela nous prendrait. C'est pour cela que bien qu'ayant conçu un shield arduino pour le robot, nous n'avons pas souhaité le faire graver. Nous savions que nous avions déjà beaucoup à faire avec les briques alors nous avons préféré nous concentrer là dessus.

Exemple de parcours possible

Voici un exemple du rendu final de notre projet, comme prévu à la base, les boîtes s'assemblent entre elles pour former un chemin et le robot connecté à elles via bluetooth va réaliser ce même chemin.

Pour aller plus loin, nous avons réaliser une boîte pour que l'apparence du robot soit plus esthétique ainsi qu'une pour la boîte maître et les briques de fin. Elles sont toutes dans les documents rendus. De plus un ami m'a passé une pièce pour maintenir le capteur ultrason que j'ai modifié et adapté à notre projet, voici le résultat :

Documents Rendus

Lien vers le git contenant les trois programmes de brique principale, brique esclave et du robot.

https://archives.plil.fr/sblas/IMA4P7/tree/master

Rapport:

Media:Rapport_de_projet_IMA4.pdf

Pour les briques, voici les fichiers de découpe laser :

Media:Boite_maitre.svg

Media:Boite_fin.svg

Media:Box 70x70x70 5mm.svg

Voici un dossier zip contenant les pièces 3D pour maintenir la barrette mâle : Media:Male header holder.zip

Pour le robot, nous avons également le contour :

Media:Petit_robot.svg

Et un shield :

Media:Robot shield.zip

Enfin, voici une pièce pour maintenir le capteur ultrason sur le robot : Media:Ultrasound holder.zip