Tuteur: Stéphane BAZEILLE et Nicolas VERRIER

Groupe: Florian BRAUN, Noah BEAUPERE et Hugo TISSOT

Sommaire

Cahier des charges

1. Présentation générale du problème

1.1. Projet

1.2. Contexte

1.3. Énoncé du besoin

1.4. Environnement du produit

2. Expression fonctionnelle du besoin

Gestion et réalisation du projet

1. Simulation des capteurs

A) Générateur de fonctions arbitraires

              a) Analyse du système des valeurs recherchés

              b) Création de la fonction arbitraire

              c) Le générateur

B) Convertisseur Analogique Numérique

            a) Branchement

            b) Configuration

            c) Code

C) Avertissement visuel

            a) Branchement

            b) code

2. Programmation du RaspberryPI

A) Récupération des données

B) Communiquer entre les RaspberryPi

C) Analyse et utilisation des données

D) Envoie des données au serveurs

3. Stockage et Interprétation des Données

A) Récolte et Stockage

              a) Étude de marché

              b) Architecture

B) Accès à Distance et Interprétation

Cahier des charges

1.Présentation générale du produit

1.1. Projet

Le but du projet est de collecter les données de température sur chacun des fours à tabac d’une exploitation, les envoyer sur un serveur accessible depuis un smartphone ou autre pour permettre de visualiser et comparer facilement les données instantanées. Une alarme sera également créée, en cas de fort dépassement des valeurs attendues ou de problèmes matériels et l’utilisateur sera averti.

1.2. Contexte

Lors du processus de séchage du tabac, le séchage des feuilles doit passer par différents cycles avec différentes température et humidité afin d’extraire efficacement toute l’humidité. Ces cycles de séchage durent, au total, une semaine avec des fours continuellement allumés. Si un four vient à tomber en panne ou subi une anomalie durant le processus et qu’il n’y a pas de surveillance, (la nuit par exemple) les dégâts et la perte de la récolte peuvent se chiffrer en milliers d’euros.

1.3. Énonce du besoin

1.4. Environnement du produit

Le dispositif final doit pouvoir directement se connecter aux capteurs des fours et doit répondre à un minimum de contraintes environnementales:

• résister à une température minimum de 90°C
• résister à l’humidité ambiante

Liste du matériel:

• 2 Raspberry Pi
• Générateur de tension (fonction arbitraire)
• Oscilloscope
• CAN
• Afficheur 7-seg
• Relais wifi

On estime le coup total à 158€, étant donner que l’oscilloscope et le Générateur nous on été prêté.

2.Expression fonctionnelle du besoin

Tableau des Fonctions

Gestion et réalisation du projet

1. Simulation des capteurs

A) Générateur de fonctions arbitraires

(Tissot)

                a) Analyse du système des valeurs recherchés

On sait que les différents four à tabac possède déjà leurs propres capteurs de températures,n’ayant pas la références de ces capteur, on choisit comme référence un capteur qui correspond le plus nos besoins.

Ici on choisit donc comme référence un thermomètre à sortie analogique “THERMOSA”, avec les caractéristiques suivantes:

• Gamme de température : -20 à +120 °C
• Sortie analogique : Tension proportionnelle à la température -2,5 V (-20 °C) à +2,5 V (+120 °C)

On a donc 140°C sur une tension d’amplitude 5V, 1°C correspond à 0.035V.

Pour des raison pratique lié à la simulation, on affirme que 0°C correspond à une tension 0V.

On a pour but de créer une fonction capable de reproduire le cycle du séchage du tabac (voir courbe si-dessous).

La fonction devra donc obligatoirement passer par tous ces points.

On va donc avoir:

• 1°C correspond à 0.035V
• 20s dans la simulation correspond à 1h

On établit donc les points principaux de la fonction:

                  b) Création de la fonction arbitraire

Afin de créer cette fonction, on a besoin de générer un fichier de points (CSV File). Pour le générer il existe de nombreuses solutions, ici nous allons utiliser le logiciel gratuit EasyWawe.

Pour cela, après avoir installé ce logiciel, exécutez le.

Une fenêtre va s’ouvrir, cliquez sur “File” puis “New”.

La fenêtre “Property setting” s’ouvre, dans la case “Sample” vous pouvez sélectionner le maximum de points pour avoir la meilleur précision.

Sélectionnez ensuite une période de 3280s, puis cliquez sur “Ok”.

La fenêtre “Wawe1” s’ouvre, cliquez sur “Draw” puis “Coordinate Draw”.

Indiquez le nombres de points nécessaire, ici “9”, et sélectionnez ensuite “Table”.

Rentrez ensuite les coordonnées des différents points. (ATTENTION Xpos est en kiloseconde et non en seconde).

Une fois tous les points entrés cliquez sur “Ok” et votre fonctions va être générer.

Il ne vous reste plus qu’à enregistrer en “.csv”, et vous avez votre fichier de points.

            c) Le générateur

Concernant le générateur, nous utilisons le générateur de fonctions arbitraire hameg hmf2525. Celui-ci est très pratique car il permet d’obtenir des période très longue et possède un port USB. On va donc utiliser ce port afin d’y transférer le fichier CSV précédemment créé (munissez vous de la notice de générateur si vous ne connaissez pas son fonctionnement).

Chargez le fichier

Réglez ensuite la période à 3280s, l’amplitude à 2.555V et l’offset à 1.25V afin que la tension de sortie corresponde à la tension souhaiter précédemment.

Il ne faut pas hésiter à utiliser un oscilloscope pour mieux visualiser la courbe.

B) Convertisseur Analogique Numérique

(Tissot)

Le CAN (Convertisseur Analogique Numérique) va nous servir à convertire la tension analogique du générateur, afin de pouvoir l’analyser sur le Raspberry PI. Le CAN possède deux entrées, on va donc y rajouter un potentiomètre pour simuler un second four.

Nous utilisons le CAN MCP 3002:

                a)Branchement

A l’aide d’une Breadboard, on va connecter la sortie du générateur et le potentiomètre au CAN, et le CAN au Raspberry PI comme ci dessous:

                    b) Configuration

Il faut configurer votre Raspberry PI pour utiliser le CAN.

Il faut tout d’abord vérifier que le SPI est activer.

Ouvrez un terminal et lancez la commande suivante :

sudo raspi-config

Sélectionnez « Advanced Options » puis validez :

Puis sélectionnez « SPI » puis validez :

Une fois cela fait, exécuter les commande suivante dans le terminal:

sudo apt-get install python2.7-dev

sudo apt-get install python3-dev

sudo apt-get libevent-dev

sudo pip install spidev

                      c) Code

#!/usr/bin/python

import time    

import spidev

DEBUG = 0

spi = spidev.SpiDev()

spi.open(0,0)

# read SPI data from MCP3002 chip

def get_adc(channel):

          # Only 2 channels 0 and 1 else return -1

          if ((channel > 1) or (channel < 0)):

                    return -1

           r = spi.xfer2([1,(2+channel)<<6,0])

           ret = ((r[1]&31) << 6) + (r[2] >> 2)

          return ret   

while 1:   

          print (get_adc(1))

         Tension = (get_adc(1)*2.7)/1024

         print (Tension)

        time.sleep(5)

Dans ce code on va créer une fonction “get_adc(channel)” qui va nous permettre de sélectionner l’entré du CAN et d’y lire la valeur. Si “channel” est différent de 0 ou 1 on retourne -1.

La valeur reçu est entre 0 et 1023, on procède alors à un calcul pour que cette valeur corresponde à une tension.

C) Avertissement visuel

(Tissot/Braun)

Le but est d’avertir visuellement l’utilisateur à l’aide d’un afficheur 7 segments.Il va alors pouvoir savoir sur quel four une alarme s’est déclenchée, cela peut être dû à un écart de température ou un problème matériel.

                 a) Branchement

Pour procéder correctement au branchement il nous faut un afficheur 7 segment et 7 résistances de 240 . Un segment va alors correspondre à un pin du Raspberry PI, il  suffit de suivre le schéma ci-dessous

Pour ma part, j’ai connecter:

• le segment A au PIN11
• le segment B au PIN12
• le segment C au PIN13
• le segment D au PIN22
• le segment E au PIN18
• le segment F au PIN16
• le segment G au PIN15

             b) code


#librairies à importer

import time

GPIO.setmode(GPIO.BOARD)

GPIO.setwarnings(False)# On supprime les avertissements inutiles

seg={« A » : 11, « B » : 12, « C » : 13, « D » : 22, « E » : 18, « F » : 16, « G » : 15} #on indique quel segment est sur quel PIN

#fonction d’affichage

def display(x) :

GPIO.output(seg[‘A’], x in [1,4])

GPIO.output(seg[‘B’], x in [5,6])

GPIO.output(seg[‘C’], x in [2])

GPIO.output(seg[‘D’], x in [1,4,7])

GPIO.output(seg[‘E’], x in [1,3,4,5,7,9])

GPIO.output(seg[‘F’], x in [1,2,3,7])

GPIO.output(seg[‘G’], x in [0,1,7])

La fonction display va permettre de choisir quelle pin il faut allumer en fonction du nombre x. L’afficheur 7 segment étant en logique inverse on indique les nombres pour lesquels chaque segment ne doit pas s’allumer.

On intègrera donc la fonction display dans le code final.

2. Programmation du Raspberry PI

(Braun)

A) Récupération des données

import cantest2 #cantest2 est le programme du Convertisseur Analogique-Numérique.
Il me permet de récupérer les données à l’aide d’une fonction


def RecupTfour(Nfour) :
Tfour[Nfour] = ((cantest2.get_adc(0)*3.35)/1024)/k

Cette fonction va récupérer la température du four (Tfour), d’un four précis choisi (Nfour), il converti également la tension que le programme cantest2 me donne en une température lisible.

B) Communiquer entre les RaspberryPI

La communication entre les Raspberry Pi est gérée par un serveur MySQL, celui-ci sera gérer sur le Raspberry maître et l’esclave lui enverra ses données. Il faut d’abord initialiser la connexion avec MySQL :


os.system ("sudo service mysql restart")
mydb = mysql.connector.connect(  host = '192.168.xxx.xxx',
user = 'FAT',
passwd = '****',
database = 'FAT')


Cette fonctionnalité est faite par une fonction qui enverra chaque valeur au serveur qu’il pourra par la suite gérer

C) Analyse et utilisation des données

L’analyse des données de se fait four par four, chaque seconde.
La première étape dans l’analyse d’un four est l’initialisation de celui-ci. Pour cela, on considère que le four s’allume quand on détecte une température entre 31 et 33 °C.


 def InitialisationFour(Nfour) :
              if (Tfour[Nfour]>=31) and (cycle_start[Nfour]==0) and (Tfour[Nfour]<=33) :
                           temps_depart[Nfour] = time.time()
                           cycle_start[Nfour] = 1


A partir de ce moment, on active un timer (temps_depart) pour savoir depuis quand ce four est allumé.
Une fois le four allumé, il faut calculer la température attendue : le tabac doit sécher pendant une semaine à des paliers de température différents.


def CourbeAttendu(Nfour) :

              if (time.time()-temps_depart[Nfour]<=16) :
                          Tatt[Nfour]=32+(time.time()-temps_depart[Nfour])*0.5

              if (time.time()-temps_depart[Nfour]>16) and (time.time()-temps_depart[Nfour]<=96) : #palier 40
                         Tatt[Nfour]=40

              if (time.time()-temps_depart[Nfour]>96) and (time.time()-temps_depart[Nfour]<=130) : #montée 40-57
                         Tatt[Nfour]=40+(time.time()-temps_depart[Nfour]-96)*0.5

              if (time.time()-temps_depart[Nfour]>130) and (time.time()-temps_depart[Nfour]<=240) : #palier 57
                         Tatt[Nfour]=57

              if (time.time()-temps_depart[Nfour]>240) and (time.time()-temps_depart[Nfour]<=272) : #montée 57-73
                         Tatt[Nfour]=57+(time.time()-temps_depart[Nfour]-240)*0.5

              if (time.time()-temps_depart[Nfour]>272) and (time.time()-temps_depart[Nfour]<=312) : #palier 73
                         Tatt[Nfour]=73

              if (time.time()-temps_depart[Nfour]>312) and (time.time()-temps_depart[Nfour]<=328) : #palier 40
                         Tatt[Nfour]=40

              if (time.time()-temps_depart[Nfour]>328) :
                         Tatt[Nfour]=0
                         cycle_start[Nfour]=0
                         temps_depart[Nfour]=0

On peut voir ici que l’on a des conditions pour savoir à quel palier le four devrait se trouver.
Suivant ce palier, on définit un Tatt qui est la température théorique que le four devrait avoir à cet instant précis. Puis à la fin, quand le four a fini son cycle, on remet l’état du four (Cycle_start) à 0 pour qu’il soit considéré comme éteint et on reset son timer.


def Alarme(Nfour) :

              if (abs(Tatt[Nfour]-Tfour[Nfour])<3) :
                         temps_ecart[Nfour] = time.time()-temps_depart[Nfour]
                         alarme_ecart[Nfour] = 0
                         display(10)
             if ((time.time()-temps_depart[Nfour])-temps_ecart[Nfour]>5) :
                        #print(« ecart de temperature de plus de 5s »);
                        alarme_ecart[Nfour] = 1
                        display(Nfour)

A coté de cela, il y a une fonction alarme qui compare l’écart entre la température théorique (Tatt) et la température actuelle du four (Tfour) et actionne une alarme si cet écart dure dans le temps (5 secondes).

D) Envoie des données au serveurs

Une fois l’analyse des données terminée, il faut envoyer celles-ci au serveur.


def Ecriture(Nfour) :
              if (temps_different[Nfour]!=int(time.time()-temps_depart[Nfour])) :
                        date = datetime.datetime.now()
                        sql = "INSERT INTO Four_" + str(Nfour) + " VALUE (null, %s, %s, %s, %s)"
                        cur.execute(sql, (str(date), str(Tfour[i]), str(defaut[i]), str(alarme_ecart[i])))
                        mydb.commit()
                        temps_different[Nfour]=int(time.time()-temps_depart[Nfour])
                        print("four ={}, time= {}, Tatt={}, Tfour= {}, Alarme ={}".format(Nfour, int(time.time()-temps_depart[Nfour]), int(Tatt[Nfour]), int(Tfour[Nfour]),alarme_ecart[Nfour]))


Cette fonction s’occupe d’envoyer chaque donnée de chaque four au serveur et cela chaque seconde.

3. Stockage et Interprétation des Données

A) Récolte et Stockage

(Beaupere)

              a) Étude de marché

Avant de commencer à coder, nous avons effectué une étude de marché pour connaitre la solution technique la plus fiable, simple et peu coûteuse sur le long-terme afin de ne pas compliquer la tâche de l’utilisateur avec des maintenances ou des actions pénibles ou excessives hors de son domaine de confort.

• Première idée : Tirer des câbles entre les capteurs et le serveur

Les câbles résistants à une utilisation extérieure sont chers et devraient être remplacés ou réparés au minimum annuellement si ce n’est plus. Un seul défaut dans le câble et toutes les données reçues jusqu’à la réparation seront inutilisables.

• Deuxième idée : Connecter les capteurs à un micro-ordinateur possédant une liaison GSM

Il existe des services tout prêt permettant ce genre de prouesse mais malheureusement ces services sont dimensionnés pour des cas ayant plusieurs machines à superviser (comme une industrie) et serait donc un coût beaucoup trop élevé pour notre cas particulier.

• Troisième idée : Étendre le réseau Wi-Fi jusqu’aux fours à tabac grâce à des répéteurs

Contrairement aux 2 autres solutions celle-ci n’implique qu’une simple vérification logicielle et physique des relais afin de s’assurer de leur bon fonctionnement, et dans le cas échéant le remplacement du matériel. Les facteurs d’erreurs potentielles seront les intempéries puissantes.

La solution finale a donc été le choix de la troisième idée : Étendre le réseau Wi-Fi et donc connecter 2 Raspberry Pi entre elles via le SGBD (Système de Gestion de Base de Données) MySQL.

              b) Architecture

Pour plus de clarté voici un schéma des différentes connexions :

Les 2 RaspBerry Pi sont reliées entre elles via le Wi-fi. L’un occupe la fonction de serveur MySQL et donc stockera les données ainsi que le site Web et l’autre sera la client MySQL.

Le tabaculteur accède aux données depuis son ordinateur (ou son smartphone) seulement si il est connecté en Wi-Fi.

Et voici également un schéma du trafic de données :

Chaque RaspBerry Pi possède un identifiant pour se connecter à la base de données, ainsi que le Site Web qui utilise un autre identifiant afin d’éviter des modifications non voulues.

Toutes les secondes, les données sont transmises à la base de données, 1 table pour chaque four. Une fois en situation réel, on pourra espacer la transmission des données (jusqu’à 15 minutes) vu que le processus complet dure une semaine et qu’une erreur de température n’est fatale qu’après 1 ou 2 heures.

B) Accès à Distance et Interprétation

(Beaupere)

Sur le RaspBerry Pi Serveur, nous avons codé une page a l’aide des langages de programmation Html5, CSS et PHP. Il a été pensé comme une application Web pour simplifier sa compréhension et son utilisation par le tabaculteur. Le résultat est le suivant :

Page d’accueil pour accéder aux dernières mise à jour des fours, ainsi qu’une ‘‘Led’’ de couleur verte ou rouge pour les alarmes de température ou de défaut matériel.

Page détaillé d’un four pour suivre l’avancement sur le cycle hebdomadaire. En bleu, le cycle idéal et en noir, qui apparaîtra au fur et à mesure du cycle, nous verrons le cycle actuel.

Vidéo de présentation

Remerciements

Merci à nos professeurs référents M. BAZEILLE et M. VERRIER et l’IUT.Lab pour le matériel.

Table Interactive

 Giudilli – Merimeche – Vessot – Binder

SOMMAIRE

1. Phase d’étude
   1. Présentation du projet
   2. Matériel en possession
   3. Répartition des tâches
   4. Recherche de matériel
   5. Conception du prototype
   6. Conception de la table
2. Phase prototypage
   1. Réalisation du prototype
   2. Polissage du polycarbonate
   3. Connections des LEDs avec des fils
   4. Connections des LEDs avec des PCB
   5. Fabrication de la surface de couplage
   6. Assemblage
3. Phase réalisation
   1. Réalisation de la table
   2. Soudure des LEDs
   3. Programmation
   4. Jeux
   5. Démonstration
   6. Améliorations possibles

Introduction

Lors de notre deuxième année de DUT GEII, nous avons proposé nous-même un projet à nos professeurs. C’est ainsi que nous avons choisi de travailler sur la conception et la création d’une table interactive. Il s’agit d’une table dotée d’un écran tactile et qui peut être utilisée de différentes situations, comme lors de réunions ou simplement pour se divertir, dessiner ou jouer.

Nous tenons à remercier Messieurs Verrier et Bazeille, nos professeurs, qui nous ont encadré lors de ce projet et sans qui il n’aurait pas été possible.

1. Phase d’étude

   1. Présentation du projet

Notre table tactile est basée sur une technologie nommée “FTIR” (Frustrated Internal Reflection).  Pour mettre en place un tel écran, il faut d’abord une plaque translucide entourée de leds infrarouges.  Cette plaque servira de support aux rayonnements infrarouges des leds qui se dispersent de manière uniforme dans ce support.

Lorsqu’un doigt est posé sur la surface, nous modifions le comportement de la lumière infrarouge dans la plaque. Une partie de cette lumière est alors déviée vers le sol et grâce à une caméra infrarouge, nous pouvons repérer cette modification sous la forme de “blobs”.

En traitant les images reçues de la caméra, nous pouvons déterminer à quel endroit simuler un clic de souris sur l’ordinateur.

Le choix de cette méthode dite “FTIR” est intéressant car nous pouvons utiliser un vidéoprojecteur pour afficher l’écran de l’ordinateur. En effet le vidéoprojecteur émet de la lumière visible et ne perturbe donc pas notre système infrarouge.

Cependant afin de pouvoir projeter sur l’écran (qui est entièrement transparent), il faut rajouter une surface de couplage légèrement opaque. Cette surface de projection, comme visible sur le schéma, permet aussi d’améliorer la réflection de la lumière infrarouge lorsque nous touchons l’écran.

   2. Matériel en possession

Pour réaliser notre projet l’IUT nous a prêté un vidéo projecteur et un Raspberry Pi 3 pour réaliser le traitement d’image et la programmation de la détection de blob et le tracking.

   3. Répartition des tâches

Nous nous sommes réparti les tâches afin que tout le monde puisse contribuer au projet. Nous avons tous réalisé de la surface de couplage. M. Merimeche a fait la conception et la réalisation de la table, il a fait la recherche des caméras que nous pouvons modifier afin de lui enlever son filtre infrarouge. M. Vessot s’est occupé de la recherche des composants pour l’écran, a réalisé le schéma électrique et le soudage des LED.  M. Giudilli s’est occupé surtout de la programmation et du polissage du polycarbonate du prototype. M. Binder s’est occupé de l’organisation du projet et du polissage du polycarbonate de la table. Quand une personne avait fini sa tâche, il en aidait une autre afin d’aller plus vite.

   4. Recherche de matériel

Il nous a fallu rechercher un écran transparent, nous pensions à une plaque de plastique. Après de nombreuses recherches, nous avons opté pour un écran en polycarbonate.

Nous avons dû ensuite chercher une webcam sur laquelle le filtre infrarouge est facile à enlever, nous avons retenu quelques modèles :

• Sony Playstation Eye Camera
• Philips SPC900NC
• Logitech QuickCam Express
• Microsoft LifeCam VX-1000

Nous avons finalement choisi la Sony Playstation Eye Camera car elle était plus facile à obtenir et dans un délai rapide. Cependant après certains tests, nous avons tout de même changer l’objectif de cette caméra pour mieux détecter les infrarouges et supprimer le visible.

   5. Conception du prototype

Il nous a fallu d’abord concevoir un prototype avant de commencer la table tactile. Ce prototype a d’abord été modélisé en 3D sur le logiciel Fusion 360. De dimension raisonnable (40*20*20 cm), il permettait d’être transporté facilement et de simuler correctement le comportement d’une table tactile grandeur nature.

   Le prototype modélisé sur Fusion360

La fente supérieure permet d’accueillir une plaque de polycarbonate de 10x20cm avec sa surface de couplage ainsi que les leds infrarouges qui l’entourent. Ce prototype intègre une partie amovible à l’avant (en rouge) pour faciliter l’installation de la caméra sous l’écran.

Nous avons choisi de maintenir les leds autours de l’écran en utilisant des profilés en aluminium

   6. Conception de la table

Après des essais concluant sur le prototype, nous avons modélisé notre table tactile en 3D. Ce modèle nous a permis de quantifier le matériel nécessaire (bois et visserie). Nous nous sommes inspirés de différents modèles de tables et d’établis pour concevoir une table solide et non bancale.

2. Phase prototypage

   1. Réalisation du prototype

Le prototype a été réalisé à la découpe laser selon le modèle vu précédemment. Voici son apparence une fois les différentes pièces montées.

   2. Polissage du polycarbonate

La lumière ne passait pas bien dans la plaque de polycarbonate. De ce fait, nous avons dû la polir à l’aide du papier à poncer, du fil de fer et une dremel.

   3. Connection des LEDs avec des fils

Nous avons choisi d’utiliser une alimentation d’ordinateur pour alimenter nos leds. Cette alimentation à une tension de 3.3 V à ses bornes et est capable de délivrer jusqu’à 33A. Ainsi, nous avons dimensionné nos résistances sur 18 Ω pour que nos leds puissent bénéficier d’un courant optimal. Toutes les leds étaient placées en parallèle.

Voici le schéma électrique :

Dans un premier temps, nous avons voulu connecter les LEDs avec des fils sur le prototype, cependant il s’est avéré que cette connection n’était pas adaptée pour ce prototype.

Ils y auraient eu trop de fils, l’isolation aurait été très compliqué à réaliser sur l’ensemble du prototype qui comportait déjà 15 LEDs. Nous avion donc un problème au niveau de l’espace que nous avions pour les fils et aussi de l’isolation du système. Nous avons donc cherché une autre méthode qui résolvait ces deux problèmes.

   4. Connection des LEDs avec des PCB

Afin de pallier aux problèmes de dimension et d’isolation du schéma électronique, nous avons opté pour une méthode de connections avec PCB. Cette méthode nous permet en effet de gagner beaucoup de place dans le prototype car la soudure des LEDs est faite sur le PCB à des petits fils. Cela a donc permis un gain de place important, pour résoudre le problème de l’isolation, le PCB en lui-même était déjà bien adapté pour isoler le système électronique, mais nous avon rajouté par-dessus de la colle qui permettait d’isoler les parties un peu plus vulnérable que le PCB ne pouvait pas protéger.

Nous avons donc vu que ce système est très pratique pour un schéma électronique de petite taille et avec un courant peu élevé (jusqu’à 1,5A). Cependant pour un schéma électronique plus grand, le choix des PCB aurait été trop coûteux, nous avons donc dû chercher une autre méthode pour la table.

   5. Fabrication de la surface de couplage

La surface de couplage à deux fonctions : elle sert à afficher l’écran via le vidéoprojecteur et à mieux détecter les doigts. Elle a été créée à partir d’une feuille de papier calque (ayant les mêmes dimensions que la plaque de polycarbonate) qui a été enduit d’un mélange de silicone et de diluant.

   6. Assemblage

Nous avons installé les différentes composantes du prototype vues dans les parties précédentes sur la maquette.

3. Phase réalisation

   1. Réalisation de la table

Une fois la commande de bois reçue, nous avons découpé les planches et les chevrons en se basant sur la modélisation 3D pour les dimensions. Nous les avons ensuite assemblés.

Une fois la table montée nous avons installé la plaque de polycarbonate par-dessus. Ensuite, nous avons rajouté autour de l’écran les profilés U avec les leds et la surface de couplage a été posée par-dessus.

   2. Soudure des LEDs

La solution que nous avons choisie pour connecter les leds entre elles sur la table est de modéliser nos propres PCB en bois et de les fabriquer avec la découpe laser.

    PCB en bois modélisé en 3D

   Soudure des leds

   3. Programmation

Traitement flux d’entrée : Pour repérer uniquement les changements effectué sur l’image d’entrée nous soustrayons l’image acquise par une première image prise lorsqu’il n’y a aucun doigt de posé. Ensuite nous appliquons différents filtres pour supprimer le bruit de fond dû à la caméra.

Détection des blobs : Comme nous l’avons vu précédemment, notre système infrarouge permet de repérer les doigts posés sur l’écran sous la forme de “blobs”.

Tracking : La détection de blob nous permet d’avoir un tableau de coordonnées représentant les différentes positions de chaque blob. Pour identifier ces derniers et les différencier un algorithme de proche en proche programmé par nos soins est utilisé ainsi chaque blob se voit donner un ID unique nous permettant de le différencier.

Calibrage : La webcam étant en train de filmer avec un grand angle, il fallait donc lui donner à travers le programme les dimensions de l’écran. Aussi, cette caméra n’étant pas totalement droite par rapport à l’écran, l’image reçue n’était pas 100% rectangulaire. Pour cela notre programme intègre une partie de calibrage. Il faut lui donner 4 positions sous la forme de blobs (en posant nos doigts) aux 4 coins de l’écran. Ainsi le programme en traitant ces données récupère les dimensions de l’écran et est capable de le redresser sous la forme d’un rectangle.

Interface et application : Les différentes parties du programme ont été regroupées sous une même interface.

   4. Jeux

Nous avons aussi programmé quelques applications qui ont été optimisées pour la table. Elles ont été programmées en C++ et à l’aide de la librairie SFML.

“Paint” : Notre Paint reprend les bases du Paint sur ordinateur et on peut être plusieurs à l’utiliser en même temps.

“Hanoï” : Notre jeu des tours de Hanoï reprend les règles classiques du jeu pour 3 disques, il faudra donc utiliser le tactile afin de les déplacer.

“Pong” : Ce jeu n’a pas encore été implémenté sur la table et nécessite 2 joueurs. Son amélioration et installation pourrait faire l’objet d’un projet futur.

   5. Démonstration

   6.Améliorations possibles

Des améliorations peuvent encore être réalisées sur notre table tactile. En voici certaines :

• Adapter les jeux Hanoï et Pong sur la table
• Soigner son esthétique (ponçage, peinture ..)
• Investir dans une caméra de meilleure qualité (avec un plus grand nombre d’image par seconde notamment)
• Porter les programmes sur un ordinateur plus puissant et l’intégrer dans la table
• Réaliser l’alimentation des leds

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:

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:

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