Version du 12 février 2018 à 13:54

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.

• Recherches envoi par interruptions

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 multiports 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 oeuvre, à 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

Documents Rendus