Puissance 4 vs. Bras robot

7 Fév 2019 Nicolas Verrier

 

 

HEBINGER Pierre   –   ECKLER Louis

 

SOMMAIRE

 

I. Préparation

  • Contexte et principe
  • Matériel et logiciel
  • Bête à cornes
  • Diagramme Pieuvre

II. Programmation P4

  • Format du code
  • Création de la logique et structure du jeu
  • Mode PvP
  • Création d’une IA
  • Ajout d’intelligence pour l’IA
  • IA logique
  • IA prédictive
  • Interface utilisateur
  • Visuelle
  • Tactile
  • Assemblage du programme (Main)

III. Bras robotisé

  • Programme embarqué sur le robot
  • Communication
  • CAO

IV. Conclusion et remerciements

 

V. Notice et Code

 

I. Préparation

Contexte et principe

 

Le but de ce projet est de créer un programme permettant à une personne d’affronter soit une personne soit une intelligence artificielle via un écran connecté à une Raspberry Pi. L’intelligence artificielle aura plusieurs niveaux de difficultés. Par la suite, il a été convenu de faire en sorte que la partie se joue sur un vrai puissance 4, avec un bras robotisé qui effectue les mouvements pour le joueur et l’intelligence artificielle.

 

Le programme devra s’exécuter sur une Raspberry Pi, c’est pourquoi notre code sera en Python. L’interface devra être également tactile, ce qui nous amène à prendre du matériel spécifique.

 

Matériel et logiciel

 

Pour le matériel, il faudra:

  • une Raspberry Pi 3
  • un écran tactile LCD 7″ Raspberry Pi Officiel
  • un bras robotisé Staübli TX40 avec une pince

 

On utilisera également comme logiciel:

  • Python IDLE
  • Staübli Robotics Suite

 

Bête à cornes

Au niveau de la bête à cornes, on aura quelque chose de plutôt simple:

 

Bête à cornes

Traduction: Grâce au programme “Puissance 4”, on rend service au joueur en le divertissant.

 

Diagramme Pieuvre

 

Pour le diagramme pieuvre, on a deux fonctions principales et six fonctions contraintes:

Diagramme Pieuvre

Fonctions principales:

  • FP1: L’information venant du programme puissance 4 devra être accessible à l’utilisateur
  • FP2: L’information devra être livrée de façon ergonomique afin d’être comprise

 

Fonctions contraintes:

  • FC1: Le projet puissance 4 devra être utilisable par un utilisateur quelconque
  • FC2: Le projet devra fournir des informations de jeu
  • FC3: Le projet devra être ergonomique lors de son utilisation
  • FC4: Le projet sera exécuté sur une Raspberry Pi en continu
  • FC5: Le projet doit être adapté à son environnement, c’est-à-dire en dans une pièce
  • FC6: Le projet ne devra pas excéder un certain coût

 

Solutions face aux contraintes:

  • FC1: L’utilisateur pourra exécuter et utiliser le programme via l’écran
  • FC2: Les informations seront affichées sur l’écran via des images (jeu sur écran) ou via du texte (jeu avec le robot)
  • FC3: Le joueur pourra sélectionner avec l’écran tactile la colonne de son choix
  • FC4: La Raspberry Pi sera alimenté sur secteur
  • FC5: Aucune protection à l’environnement n’est nécessaire du fait que le projet est utilisé en intérieur
  • FC6: Le matériel étant déjà disponible, le coût du projet est nul

 

II. Programmation P4

Format du code

 

Nous avons choisi d’utiliser majoritairement de l’anglais afin d’éviter les accents qui ne font pas partie des caractères utilisables dans les noms de fonction.

Pour les noms de fonction nous avons utilisé le préfixe “is” ou “has” pour les fonctions retournant une valeur booléenne. Puis nous avons utilisé “get” et “set” pour les fonctions retournant ou modifiant l’état d’une variable.

 

exemples:

De plus nous avons essayé de respecter autant que possible la règle disant qu’une fonction ne doit pas effectuer plus d’une seule tâche afin de rendre le code plus simple à utiliser et débugger.

 

Finalement nous avons décidé d’utiliser uniquement Python 3 car elle était déjà présente sur la Raspberry Pi et que les différentes versions de python n’ont pas toujours le même comportement.

C’est pour cela que les programmes ne fonctionnent pas sur les PC de l’IUT qui eux sont sous Python 2.7 !

 

    Création de la logique et structure du jeu

 

Dans un premier temps nous avons créé la classe au cœur de notre programme : “Tableau”

Cette dernière nous permet de stocker l’état du jeu, de lui apporter des modifications simples ainsi que de vérifier divers éléments sur l’avancement de la partie.

 

Elle se présente de la façon suivante:

L’état du jeu est stocké dans un tableau en 2 dimensions de 7 colonnes et 6 lignes, chaque case de ce tableau représente une case du puissance 4 réel.

Une case vide prend la valeur de 0, une case avec un pièce du joueur 1 prend la valeur 1 et finalement une case avec une pièce du joueur 2 prend la valeur -1.

Descriptif des fonctions

 

_init_()

Constructeur de l’objet, elle permet d’initialiser les valeurs du tableau.

getTableau()

Renvoi le tableau de valeurs du jeu.

display()

Permet d’afficher le tableau de jeu de façon ergonomique dans la console python en ajoutant le numéro des colonnes et en remplaçant les valeurs par des symboles.

getSlot()

isSlotPlayable()

Permet de savoir si la case est jouable.

getRowSlot()

Cette fonction permet d’identifier la position “y” de la case jouable dans la colonne “x”.

Si cette colonne est pleine la fonction renvoie “-1”.

 

setPiece()

isFull()

Cette fonction permet de savoir si il ne reste plus aucune case de libre dans la grille du puissance 4.

hasPlayerWon()

Cette fonction nous permet de vérifier si un des joueurs a gagné la partie en alignant 4 pièces de sa couleur. Elle nous renvoie la position x, y de la case et la direction de cette ligne dans un tableau. Si le joueur n’as pas fait de ligne de 4 pièces la fonction renvoie “false” (0).

 

    Mode PvP

 

Tout d’abord, il faut savoir que chaque niveau est représenté par un chiffre dans le code:

  • Niveau 0 : mode PvP
  • Niveau 1 : mode IA aléatoire (baptisé “Timmy”)
  • Niveau 2 : mode IA logique (baptisé “Captain Obvious”)
  • Niveau 3 et supérieur : mode IA prédictive (baptisé “Hawking”)

Dans les variables globales, on choisira donc le niveau de l’adversaire dans la variable “level”, ici 4 soit le niveau IA prédictive.

Pour la création du mode PvP ou “level=0”, nous avons simplement fait en sorte de demander au joueur 2 quelle colonne il veut jouer comme le joueur 1. Pour cela nous avons réalisé la chose suivante:

Si c’est au tour de l’adversaire (soit turn différent de 1) et si le level = 0 (soit le mode PvP), alors on demande au joueur 2 quelle colonne il souhaite jouer ( x = askPlayer( ) ) . Dans le cas contraire soit (level différent de 0) il faudra demander à l’IA de jouer.

    Création d’une IA

Une fois le système d’alternance entre joueur mis en place nous avons ajouté au code pour le deuxième joueur, la fonction askIA(). Cette fonction fait appel à différents algorithmes qui vont être chargés de retourner la colonne jouée par l’ordinateur avec une difficulté variable.

 

Dans un premier temps nous avons créé une “IA” retournant simplement une colonne jouable aléatoirement afin de tester le bon fonctionnement du code.

Ajout d’intelligence pour l’IA

    IA logique

 

L’IA logique, nommée “CaptainObvious”, doit faire en sorte de bloquer le joueur, tout d’abord en lui empêchant d’aligner 4 pièces. Si le joueur ne peut pas en aligner 4, alors il lui empêchera d’en aligner 3. Si le joueur ne peut pas en aligner 3, alors “CaptainObvious” va chercher à en aligner 3. Si il ne peut pas en aligner 3, alors il va chercher à empêcher le joueur d’en aligner 2. Le code se présente de la façon suivante:

La fonction CheckFor() permet d’identifier toutes les cases vides qu’un joueur donné pourrait jouer afin de faire une ligne de n pièces de sa couleur. Elle va nous renvoyer le résultat sous forme de tableau de position.

Exemple:

Si on effectue une vérification de 4 pièces pour le joueur 1, la fonction nous renvoie  “[1,0] [4,1]”, ce sont les coordonnées de tous les cases vides que le joueur pourrait utiliser pour faire une ligne de 4 pièces en un seul coup.

Afin de vérifier si le joueur peut réellement faire le coup permettant de mettre une pièce à une de ces positions, on se sert de la fonction isSlotPlayable(). En effet dans l’exemple suivant le coup en “[4,1]” n’est pas possible car la case en dessous est vide.

    IA prédictive

 

Cette IA représente le niveau de difficulté le plus élevé de notre programme.

Elle va se baser sur la prédiction et l’analyse de tous les états futurs possibles du jeu.

 

Pour ce faire nous avons pris exemple sur l’algorithme surnommé “minimax“, celui-ci se base sur tous les états du dernier rang pour faire sa prédiction.

Cet algorithme se base sur le fait que le joueur lui aussi, fait à chaque fois le coup le plus avantageux pour lui. Les règles sont simples, un joueur tente d’arriver au nombre le plus faible et l’autre au nombre le plus élevé.

 

Il va donc partir du bas de “l’arbre” en sélectionnant à chaque fois l’option la plus avantageuse pour chaque joueur afin d’identifier le chemin que l’IA doit prendre pour avoir le plus de chances de gagner.

 

La clé de la réussite de cet algorithme est l’identification de la valeur de l’état actuel du jeu.

Il serait en effet simple de se contenter de vérifier si l’IA ou le joueur gagne dans une branche donnée mais la puissance de calcul de la Raspberry Pi étant limitée il nous est pas possible de calculer tous les coups possible avec beaucoup de coups d’avance.

 

Nous avons donc décidé de créer une fonction attribuant une valeur à un jeu. Elle va nous retourner une valeur positive si le joueur gagne et une valeur négative si l’IA gagne. Dans le cas ou aucun des deux gagne la fonction va nous retourner une valeur intermédiaire dépendant de l’avantage qu’a un joueur. En effet si le joueur possède plusieurs options pour aligner 3 pions alors que l’IA n’en a aucune la valeur du jeu va être en faveur du joueur.

 

Pour cela elle va s’appuyer sur la fonction countPossible() qui va retourner le nombre de coups possibles qu’un joueur va pouvoir faire pour aligner un certain nombre de pièces.

Il a fallu ensuite créer une fonction permettant de simuler tous les coups possibles et de renvoyer la valeur du coup à l’IA.

Finalement nous avons réalisé la fonction permettant de faire le choix de l’IA en fonction de toutes les possibilités qui lui sont proposées.

Elle va prendre le résultat de chaque branche pour trouver le coup avec la valeur la plus faible car c’est ce coup qui va lui donner le plus de chances de gagner.

 

Interface utilisateur

 

Pour l’interface utilisateur, nous avons utilisé PyGame qui permet de créer des interfaces via Python.

Tout d’abord on définit les dimensions de l’IHM (ici l’écran tactile), la taille d’un emplacement, le titre de la fenêtre et l’ouverture de la fenêtre:

Par la suite on charge les images et on les adapte au format que l’on souhaite:

les variables red_image et yellow_image sont utilisées uniquement pour l’interface avec le jeu sur écran.

On affiche ensuite l’écran puis le fond d’écran :

La suite du programme diffère en fonction de son utilisation avec le jeu sur écran ou avec le robot.

 

    Interface avec jeu sur écran uniquement

On va donc d’abord afficher le puissance 4. Pour cela on écrit une fonction qui colle des cases bleues (slot_image) en 6 lignes et 7 colonnes soit 42 cases. La fonction est donc la suivante:

Il faut ensuite afficher chaque pièce jouée. Pour cela on regarde d’abord si c’est la pièce du joueur ou de l’adversaire qui doit être ajoutée ( tableau[x][y] == 1 ou tableau[x][y] == -1) et on affiche la pièce de couleur rouge ou jaune en fonction de ça:

 

Joueur:

Adversaire:

Au final la fonction complète sera la suivante:

Pour savoir quelle colonne le joueur souhaite utiliser, on doit recueillir l’emplacement du curseur de la souris ou du doigt avec l’écran tactile.

 

position[0] correspond à la position en x du curseur.

position[1] correspond à la position en y du curseur.

 

On cherche d’abord à voir si le curseur est posé sur une case et non en dehors du puissance 4, on va donc vérifier de la façon suivante:

Si la position en x est inférieure à la position en x de la case la plus à gauche ou supérieure à la position en x de la case la plus à droite, alors on return -1 pour signifier que le curseur est en dehors du jeu.

 

De même, si la position en y est inférieure à la position en y de la case la plus en bas, on return -1 pour signifier que le le curseur n’est pas dans le jeu. Nous avons décidé de ne pas faire de même si le curseur est au dessus de la case la plus haute pour que le joueur puisse poser sa pièce au dessus du jeu, afin de paraître plus réel.

 

Si le curseur est dans le jeu, alors on return la position en x du curseur.

 

La dernière fonction utilisée pour l’interface permet d’animer cette dernière. Lors de la pose d’une pièce, on souhaite la faire défiler du haut de l’écran jusqu’à son emplacement. Pour cela, on définit d’abord la hauteur de début (startheight = 0) et la hauteur finale qui dépendra de l’emplacement de la pièce jouée. On fait avancer la pièce et on réaffiche le fond d’écran, puis la pièce ajoutée, puis le puissance 4 et les autres pièces et on on affiche le tout.

La fonction est donc représentée de la manière suivante:

Le rendu visuel sera donc le suivant:

la zone avec le contour rouge représente la surface sur laquelle on peut cliquer pour mettre une pièce dans la colonne n°0.

 

Interface avec jeu via le robot

 

Pour l’interface avec le robot, on n’affichera pas autant d’éléments que pour une partie sur l’écran uniquement. On n’affichera qu’une ligne du puissance 4 et on n’affichera pas les pièces, étant donné que l’utilisateur les verra en vrai. On laissera donc l’utilisateur choisir uniquement la colonne de son choix.

Pour l’affichage des cases on aura donc ceci:

Étant donné qu’on n’aura qu’une ligne, la fonction qui prend la position en x du curseur change également:

Il ne reste donc plus qu’à utiliser ces fonctions dans le code principal (Main).

Voici une image montrant l’écran lorsque qu’on joue avec le robot:

 

 

    Assemblage du programme (Main)

Diagramme des classes

Tout d’abord, on importe les autres fichiers:

Afin de pouvoir faire plusieurs actions en même temps, on utilise le threading.

On initialise par la suite toutes les variables vues dans les programmes précédents:

On initialise le tableau, puis on définit que le premier à jouer sera le joueur. On met le level à 4, soit l’IA prédictive et on définit que la variable qui arrête l’affichage est a False.

 

On affiche le jeu:

On crée une fonction qui va demander au joueur quelle colonne il souhaite jouer.

 

On regarde d’abord si le joueur veut quitter le jeu ou si il a cliqué pour jouer:

Si le joueur veut quitter le jeu, on renvoie x = -2.

Si le joueur a cliqué, on vérifie qu’il a cliqué dans une colonne, sinon on envoie un message à l’utilisateur:

“le nombre choisi doit être entre 0 et 6, veuillez réessayer”.

Si le joueur a cliqué dans une colonne mais qu’elle est pleine , on envoie un message à l’utilisateur:

“la colonne est pleine, veuillez en choisir une autre”.

Si le joueur a cliqué dans une colonne est qu’elle n’est pas pleine, on renvoie la valeur de x.

La fonction complète est la suivante:

 

 

On crée également une fonction qui va demander à l’IA la colonne qu’elle souhaite jouer via AITread.

C’est à ce moment qu’on va utiliser le threading. En effet, pendant que l’IA va calculer la colonne qu’elle doit jouer, on doit continuer à rafraîchir l’écran pour éviter un “freeze” de l’application.

 

A nouveau, si le joueur cherche à quitter le jeu, on renvoie la valeur x = -2.

Si le joueur ne souhaite pas quitter le jeu, on arrête le threading et on récupère la réponse de l’IA.

 

Le code de la fonction est le suivant:

 

La fonction IATread va donc recueillir la réponse de l’IA. En fonction du niveau de l’IA, on va demander la réponse à l’IA correspondante:

On crée la boucle de jeu. On regarde d’abord à qui est le tour. Si c’est le tour du joueur, on va utiliser la fonction askPlayer(). Si c’est le tour de l’adversaire, on regarde si l’adversaire est un autre joueur (mode PvP avec level = 0), sinon on utilise la fonction AskIA().

 

Si la valeur de x est de -2, on met la variable quit_game à True, la partie s’arrête.

 

Sinon, on utilise slotAnimation pour afficher la pièce qui rentre dans le puissance 4.

Quand l’animation est finie, on définit la place de la nouvelle pièce.

On affiche le fond d’écran, les pièces et le puissance 4. On aura donc le code suivant:

On vérifie par la suite si quelqu’un a gagné: si c’est le joueur 1 qui gagne, on lui envoie “Le joueur 1 a gagné”. Sinon, on regarde si c’est le joueur 2 qui gagne et on envoie le message “Le joueur 2 a gagné”. On fait de même avec l’IA, avec un message personnalisé en fonction du niveau de l’IA. Enfin, on arrête le programme.

 

Si personne ne gagne, on vérifie si le puissance 4 est plein, dans ce cas là on envoie le message “Personne ne gagne, retente ta chance” et on arrête le programme.

Sinon, on passe le tour à l’autre: turn = turn * (-1).

On a le code suivant:

On crée une autre boucle qui vérifie si le joueur souhaite quitter le jeu:

 

Main version robot

 

Dans cette version nous avons simplement repris le code déjà écrit pour le main précédent et nous y avons ajouté les éléments permettant d’interagir avec le robot.

Diagramme des classes version Robot

 

La classe “DisplayRobot” est une version simplifiée de la classe “Display”. en effet il n’est plus nécessaire d’afficher l’état du jeu sur l’écran vu que nous pouvons le voir en réel. Son but est simplement de proposer à l’utilisateur une grille simplifiée pour qu’il puisse choisir ou le robot doit jouer.

 

On ajoute aussi la nouvelle classe “SocketCom” qui permet, à l’aide de la fonction “sendSocketToRobot()”, d’envoyer les coups joués au robot, on reviendra plus en détail sur cette classe dans la troisième partie.

Il a fallu ici encore faire appel à des threads pour pouvoir envoyer les données au robot car une fois de plus le programme ne peut pas se permettre d’attendre le robot. Cette technique permet au programme de continuer à exécuter sa boucle principale tout en attendant que le robot confirme la réception des données.

On va utiliser une variable “SocketComState” afin de resynchroniser le programme une fois le message envoyé.

Voici une vidéo de présentation du projet puissance 4 avec le jeu sur écran:

III. Bras robotisé

Étant donné que nous n’avions pas utilisé tout le temps consacré au projet après avoir finalisé le programme, nous avons eu pour nouvel objectif de prendre notre programme et de faire jouer un robot sur un vrai puissance 4.

    Programme embarqué sur le robot

 

En premier nous avons écrit le code qui va être exécuté sur le robot.

Celui-ci va stocker la position des piles de pièces ainsi que l’emplacement du plateau de puissance 4. Il va pouvoir recevoir la colonne et la couleur de la pièce jouée par le joueur ou l’IA.

 

Le programme est initialisé par la fonction start qui va se charger de placer le robot à sa position de départ et d’initialiser la hauteurs des piles de pièces.

C’est elle aussi qui va configurer le port du serveur Socket en “timeout” (temps d’attente) limité car on ne connaît pas le temps que va prendre le programme pour envoyer les données au robot (le joueur humain pouvant attendre des heures avant de faire un coup si il le veut). Finalement elle va appeler la fonction “p4” qui  s’occupe de la réception des données et du calcul des mouvements du robot.

La fonction p4

Cette fonction contient la boucle principale du programme.

Elle va attendre les données de la Raspberry Pi avec la fonction “sioGet” qui prend comme argument le serveur Socket configuré au préalable dans les configurations du robot et une variable de sortie “nCom” qui va stocker les données reçues. La fonction “clearBuffer()” permet de supprimer les données après leur lecture afin que le serveur puisse recevoir les données du prochain coup.

 

Après avoir calculé les positions de déplacement du robot on va faire appel à la fonction “mouvement()”  qui elle, va ajouter les vitesses et les points d’approche des mouvements du robot ainsi que la gestion de l’ouverture et de la fermeture de la pince.

On a par la suite ajouté un delay avant que le robot lâche les pièces car les pièces qui restaient légèrement collées à la pince se voient projetées en arrière.

 

Il ne reste donc plus qu’à transmettre les coups du programme au robot afin qu’il puisse les réaliser sur le plateau du puissance 4.

Communication

A la place d’afficher les différents coups des joueurs sur l’écran nous devons désormais envoyer ces derniers au robot. Pour cela nous avons créé une nouvelle librairie du nom de “SocketCom”  (pour la communication par socket).

 

Dans un premier temps nous avons mis en place une convention d’envoi des données aussi utilisée lors de la réception du coté robot.

Les données sont envoyées en paquet de 3 char (nombre de 8 bits). Le premier donne la colonne jouée, le deuxième la couleur jouée et le troisième est utilisé pour envoyer des commandes au robot. Si ce dernier est à 1 par exemple, le robot va automatiquement arrêter le programme et ainsi ne pas être dangereux. Comme le robot ne contient aucune intelligence cela est le seul moyen pour lui de savoir quand la partie est terminée.

La fonction “moveRobot” se charge de la création du message à transmettre et de la boucle d’envoi du message qui s’assure que le robot a bien reçu le message avant de continuer.

La fonction chargée de l’envoi du message est “sendMoveToRobot”. Elle crée la connection avec le robot, encode le message et le transmet au robot.

    CAO

(Conception Assistée par Ordinateur)

 

L’utilisation du bras robotisé entraîne des contraintes que nous avons dû gérer. En effet, les vibrations causées par le déplacement du bras font bouger le puissance 4, ce qui provoque une imprécision notable. Il est donc nécessaire de faire en sorte que le puissance 4 reste stable. Pour cela nous avons eu l’idée de créer un support permettant de caler le jeu sur la table, qui soit en plus installé de manière non définitive. Le support a donc été créé avec le logiciel Corel Draw et une découpeuse laser.

Le support est en bois et est muni de deux encoches pour insérer les pieds du puissance 4 ainsi que deux emplacements gravés afin de savoir ou poser précisément les piles de pièces rouges et jaunes.

Étant donné que le puissance 4 sera utilisé dans la salle où se trouve le Staübli, la table utilisée est munie d’encoches comme vous pouvez le voir ci-dessus. Nous avons donc créé une encoche dans chaque coin du support afin de le fixer à la table, comme ci-dessous:

Suite à cela, malgré le fait que le puissance 4 soit stable, nous avons remarqué que le nombre de pièces tombant en dehors du puissance 4 reste conséquent (environ 7% des pièces tombent en dehors lors d’une partie).

 

Après plusieurs observations, nous avons conclu que cette imprécision peut provenir de différents éléments:

 

  • Les pièces collent parfois à la pince
  • Le robot peut avoir une erreur de 2mm sur un mouvement
  • Le robot n’est pas bien calibré à la table

 

Une des solutions possible est d’ajouter une mousse sur la pince pour que les pièces ne collent plus. Cependant cela n’aurait pas suffit car même lorsque les pièces ne collent pas il arrive que la pièce tombe en dehors du puissance 4.

 

C’est pourquoi nous avons décidé de créer une goulotte afin d’agrandir la “zone de chute” de la pièce. Nous avons donc à nouveau utilisé Corel Draw afin de créer la goulotte. Cette fois-ci nous avons utilisé du plastique bleu, afin d’avoir la même couleur que le puissance 4.

La forme du puissance 4 nous a permis de réaliser une goulotte amovible. Le puissance 4 n’a donc pas été modifié directement, il peut être utilisé sans goulotte.

Après plusieurs essais avec la goulotte, nous avons observé une erreur de 0%. La solution est donc validée.

Voici une vidéo de présentation du programme en action, joué avec le Staübli:

IV. Conclusion et remerciements

 

Nous tenons à remercier avant tout M.VERRIER Nicolas ainsi que M.BAZEILLE Stéphane pour nous avoir aidé pendant le projet. Nous tenons également à remercier M.DE SABBATA qui nous a été d’une grande aide pour la réalisation de la CAO.

 

En conclusion, nous pouvons affirmer que ce projet nous a offert une expérience non négligeable dans le domaine de l’informatique, la robotique et  la CAO. Ce projet nous a également appris à nous partager les tâches en fonction des nos compétences et surtout à travailler durablement en groupe. Nous sommes d’autant plus heureux de savoir que ce projet sera utilisé lors des portes ouvertes de l’IUT de Mulhouse.

 

Quant aux améliorations éventuelles à réaliser sur ce projet, il serait possible de rajouter un deuxième bras robotisé qui puisse jouer contre le premier. Cela servirait donc à faire une démonstration du programme devant les spectateurs. Nous avons également pensé à rajouter une caméra visant le puissance 4 afin de pouvoir faire jouer directement l’utilisateur sur le puissance 4, cependant le robot Staübli n’étant pas fait pour une utilisation ludique, la sécurité ne serait pas assurée. Pour ajouter des fonctionnalités au robots, on pourrait néanmoins faire en sorte qu’il ouvre la grille en fin de partie et qu’il empile les pièces sur deux piles. Il faudrait alors rajouter une caméra en plus.

 

V. Notice et code

 

Vous trouverez ci-dessous les liens utiles:

  • La notice d’utilisation du projet:

https://drive.google.com/file/d/1QyNU8MFcEi8Y3eGVnGr0a0IhyVS3yis5/view?usp=sharing

  • Le code:

https://drive.google.com/drive/folders/1iRYLxJR4iJaN3XV4ZD_5T1SGecX8y07u?usp=sharing

 

Vous pouvez nous contacter aux adresses mails suivantes:

hebinger.68(at)gmail.com

louis.eckler(at)gmail.com