Version du 21 février 2018 à 22:57

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

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.

Partie robot
5. Construire le robot
6. Programmer le robot

Partie ordinateur
7. Réaliser le programme sur ordinateur

Partie "tapis de jeu"
8. 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.
• Programmation de l'Arduino uno pour recevoir les données par la liaison série.
• 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

Deux heures le lundi 22/01/2018:

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.

Quatre heures le mercredi 24/01/2018:

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.

Deux heures le jeudi 25/01/2018:

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.

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

Deux heures le lundi 29/01, 4 heures le mercredi 31/01, 2 heures le jeudi 01/02 , deux heures le lundi 05/02, 6 heures le mercredi 07/02, 2 heures le jeudi 08/02

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

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.

Semaine 6

L'objectif des 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.

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.

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. Toutes ces questions, qui ne nous apparaissent que maintenant, donc assez tardivement, doivent être résolues et le sont au fur et à mesure.

Documents Rendus