Projets d'élèves

1. Introduction

La crise sanitaire, à montrer d'innombrables changements dans nos quotidiens. Parmi ceux-là, apparaissent très rapidement l'augmentation des commandes faites sur internet. En effet, les magasins ayant été fermés à maintes reprises, la possibilité de commander du matériel en ligne à su remplacer la plupart des achats fait normalement en magasin. Et avec cette augmentation, plusieurs technologies semblent intéressantes à étudiées. Serait-il possible d'automatiser la tâche de distribution de colis et de l'optimisé d'une certaine manière afin de pouvoir facilement la reproduire à grande échelle ? Je ne prétends évidemment pas pouvoir rivaliser avec les géants de la tech qui se tire les cheveux sur la problématique avec bien plus de moyen et de connaissance technique, mais me met plutôt au défi de m'intéresser à cette problématique et de développer à l'aide du Thymio une sorte de "proof of concept".

Mon objectif est de pouvoir créer un programme qui permettrait au Thymio de rejoindre une destination définie en évitant les possibles obstacles se trouvant sur sa route. Une fois sa destination atteinte, il trouverait un "dock" dans lequel il doit se parquer et ensuite actionner un moteur qui fait pivoter une plaque disposée sur le haut du robot permettant à un objet d'être libéré. L'objectif du "dock" est de pouvoir l'universalisé très aisément facilitant ensuite le travail des robots de distribution qui n'aurait pas à s'adapter et à adopter des comportements différents suivant les destinations qu'il livre. Ce dock serait au monde de la distribution ce qu'est le conteneur au monde du transport de marchandise.

2. Matériel et méthodes

2.1 Matériel

• Robot Thymio
• Raspberry pi
• Adafruit 16-Channel PWM/Servo HAT & Bonnet
• Un servomoteur
• Un support pour 4 piles AA
• Un ordinateur capable de faire tourner le logiciel Thymio suite

2.2 Méthode

Le projet se divise en 3 grandes étapes :

1. Développer le système de navigation du robot (rejoindre une destination)
2. Développer un moyen pour que le Thymio se parque dans le dock
3. Construire un plateau qui se positionne sur le Thymio et un boitier avec toute l'électronique

2.2.1 Système de navigation

La première question que je me suis posé est : en quel langage programmer le Thymio? Le robot lui-même a un langage propre à lui, l'aseba. Ce langage est assez simple et abordable ce qui aurait pu être parfait sachant que je n'avais presque aucune expérience dans le codage. Mais le seul souci, c'est que je savais qu'à un moment ou à un autre je devrais commander des modules électroniques externes tel que le servomoteur. Le langage Aseba étant grandement limité me paru donc un mauvais choix, de plus en me renseignant il se trouve qu'une librairie python avait été récemment développé pour commander le robot en python. Je me suis ainsi porté sur le choix de Python comme langage de programmation. Un détail important à mentionner par rapport à cette librairie est qu'elle nécessite d'avoir le logiciel Thymio Suite d'ouvert pour fonctionner. En effet, apparement c'est ce logiciel qui permet de communiquer avec le robot. Il n'est pas disponible sur Raspbian(l'os du raspberry) mais il est possible de faire tourner le logiciel sur un autre ordinateur et de spécifier dans le code une IP et un port auquel se connecter. Il me semble important de mentionner que tout les tests et travaux ci-dessous ont été effectués sur un ordinateur windows et non le raspberry pi. Toutefois j'ai fait des tests qui m'ont prouvés que l'utilisation de cette librairie était possible sur le raspberry

Maintenant le langage choisi, intéressons nous à la programmation. Le premier problème à considérer est comment le robot sait-il où il se trouve. En effet, il n'a aucune conscience d'où il est, ce qui est problématique lorsqu'il s'agit de le mener à un endroit précis. Afin de déterminer sa position, j'ai choisi de calculer le déplacement du robot. Il commence à une coordonnée (0, 0) et, en fonction de sa vitesse et du temps, il calcule son déplacement sur l'axe X et Y. Cette méthode montre des imprécisions lorsque le robot parcours de longues distances, car elle ne tient pas compte de l'accélération, et en plus, un des défauts de la librairie utilisée pour communiquer avec le robot est qu'elle montre une assez grande latence(~0.3 seconde pour envoyer ou recevoir une information du robot)ce qui fait que le robot met quelques centimètres en plus à s'arrêter. Mais malgré ça, sur l'ordre de grandeur que je vise (entre 1 et 2 m), l'imprécision que j'obtiens est peu importante. De plus, le dock faisant une certaine taille, s'il y a une dizaine de centimètres d'erreur ce n'est pas un problème.

Maintenant, le robot arrive à se situer. Il suffit donc seulement de lui dire sa destination et qu'il la rejoigne calculant l'angle optimal et allumant ses moteurs à toute berzingue... Eh non ! Si seulement c'était aussi simple... Comme mentionné précédemment il y a une grande latence lorsqu'il s'agit de communiquer avec le robot, ce qui n'est pas trop grave pour un déplacement, mais pour un angle, c'est tout autre. En effet, il était impossible d'obtenir des angles précis. Et cette imprécision posait un réel problème. Pour palier au souci, j'ai décidé de me déplacer que sur l'axe X et Y me facilitant la tâche, car n'ayant que des angles de 90° à effectuer, et pour les effectuer avec une plus grande précision, j'ai utilisé une fonction de la librairie qui permet de compiler du code aseba sur le robot qui est donc, lui, interpréter directement par le Thymio ce qui lui permet d'être plus précis (sinon, c'est la machine qui fait tourner le code python est qui se charge juste d'envoyer des requêtes telles que await node.set_variables(motors_straight(0, 0)), qui permet de définir la vitesse des deux moteurs à 0).

from tdmclient import ClientAsync(), aw
import time
with ClientAsync() as client:
    async def rotation():
        with await client.lock() as node:
            #compile du code aseba dans le robot, dans mon cas 
            #un programme qui fait tourner le robot se 90°
            await node.compile(aseba_code) 
            await node.run() #execute le programme aseba
            time.sleep(2) 
             aw(node.stop()) #ici j'ai remplacer une strucure conditionnel 
                     #par un time.sleep() avant de lancer cette fonction qui arrête 
                     #le programme aseba, mais en réalité il y a une variable du robot 
                     #qui est verifié en permance qui indique si la rotation à 
                     #été faite et donc si le Thymio doit lancer la fonction aw(node.stop()) 
    client.run_async_program(rotation)

Plus précisément, j'ai défini différents statuts dans lesquels mon robot pouvait être tel que x_displacement, rotating, y_displacement: Chaque état ordonne au robot différentes actions, que vous pouvez deviner par leur nom. Si le robot est dans le statut x_displacement il va parcourir la distance demandée sur l'axe X, s'il est sur le statut "rotating", il va effectuer une rotation et pour le y_displacement il fait la même chose que pour le x_displacement statut, mais sur l'axe y.

De manière plus détaillée, dans mon code, j'ai plusieurs fonctions dans une boucle while qui sont appelé. En tout premier dans cette boucle j'utilise la fonction time() du module time ce qui donne:

import time
While True:
    t = time.time()

de cette manière, je peux avoir un intervalle de temps ensuite que je peux calculer juste après avoir défini la vitesse des moteurs en faisant time_interval = time.time() - t de cette manière je peux passer comme argument l'intervalle de temps à ma fonction displacement_calculation() et l'obtenir (je vais mentionner beaucoup de fonctions, mais je ne vais pas toutes les mettre, car ce document sinon deviendrait juste une page remplie de code, je vous invite à ouvrir en parallèle le code que vous trouverez sur le git)

Dés à présent le robot est capable de connaître son déplacement. Il suffit donc juste de demander au robot de rouler tant que son déplacement est plus petit que sa destination. Pour cela rien de mieux qu'une bonne vieille structure conditionnelle telle que :

if destination[0] > displacement_calculation()[0] and 
    get_actual_direction() == X_POSITIVE and not check_if_robot_reach_X():
    wheel_speed = 100
    motor_on_protocole(t, wheel_speed) 

Vous remarquerez que la structure conditionnelle est un peu plus complexe qu'énoncé précédemment, cela est dû au fait qu'il est important de tenir compte du sens de la marche. En effet, si le robot reçoit une coordonnée négative telle que (-0.5, 1.3), et qu'il est à (0, 0), 0 > -0.5 et en conséquence il s'arrêterait alors qu'il n'a pas atteint sa destination. C'est pourquoi j'ai ici une fonction qui vérifie que le robot avance vers les x positifs et pour arriver à ce bloque, la destination est elle aussi uniquement un x positif(cela est vérifié plus tôt). Le même procédé est mis en place pour le déplacement sur l'axe Y.
Concernant la rotation. Pour qu'elle se lance le programme doit rentrer en robot_status = ROTATING, ce statut est probablement le plus simple et tient sur quelque ligne :

if robot_status == ROTATING:
    if robot_rotation_call == POSITIVE_90:
        client.run_async_program(turn_right)  
    elif robot_rotation_call == NEGATIVE_90:
        client.run_async_program(turn_left)  
    elif robot_rotation_call == TURN_180:
        client.run_async_program(turn_180)

quand le Thymio rentre dans ce statut, il connait déjà le robot_rotation_call(toujours défini en sortant, ou du déplacement sur X ou Y, ou du protocole d'évitement). Et pour chaque robot_rotation_call, une fonction "async" est lancée(les fonctions async dans python sont des fonctions qui "bloquent" le code en attendant des informations, ici, en communiquant avec le robot). Chaque fonction permet d'effectuer soit une rotation de 90° vers la droite, soit vers la gauche, soit un demi-tour de 180°.

Le dernier point à développer est le programme d'évitement d'obstacles. Cette tâche est loin d'avoir été la plus simple. Ce n'est pas encore parfait et ne le sera point malheureusement. Dans la situation actuelle, si le robot rencontre un objet, il va d'abord essayer d'interrompre son déplacement sur l'axe actuel et essayer de faire le déplacement sur l'autre axe. Je m'explique, si le robot doit atteindre le coordonné (1.5, 1.5), le robot parcours premièrement le chemin sur l'axe X, mais s'il rencontre un objet à mis chemin, imaginons à (0.75, 0) il va se tourner sur l'axe Y et essayer de parcourir les 1,5 m qu'il lui reste à faire sur cet axe et ensuite de finir les 75 cm demeurant sur l'axe X. Le robot peut facilement répéter ce schéma, mais il est loin de couvrir toutes les possibilités.

C'est pourquoi j'ai essayé ensuite de développer un système plus sophistiqué. Qui lui permettrait d'éviter des obstacles qui sont placés étrangement, qui bloqueraient le robot et où il devrait être capable de faire des demi-tours, etc. C'était beaucoup d'attentes qui m'ont aussi engagées dans beaucoup de travail, d'essais, d'échecs, mais aussi de réussites. Avant trop d’espérance, je dois reconnaître qu'il est encore loin d'être parfait, qu'il est encore possible parfois de voir le robot faire une crise de panique et tourner sur lui même, et même à de très rare occasion, le voir croire en ses rêves et foncé droit dans le mur (si j'ai correctement fait mon travail de débugage cela ne devrait plus arriver). Cependant malgré ces soucis, le programme que j'ai développé reste plutôt efficace et permet au Thymio dans la majorité des cas, de rejoindre sa destination.

Plus tôt, je vous ai parlé du cas classique d'évitement d'obstacles, maintenant, je vais vous parler des cas plus complexes. Le premier moment où mon programme présentait un souci c'est quand le robot avait complétement parcouru la distance souhaitée sur un axe et qu'il rencontrait un obstacle. en effet, si cela était le cas, le robot tournait initialement mais ayant déjà parcouru la distance souhaitée sur l'axe actuel, retournait de 90° pour être à nouveau face à l'objet et réitérer l'action étant bloqué dans cette boucle. Pour que le cas soit plus claire, voilà ci-dessous un schéma de la situation

Dans ce cas là, le robot, au lieu de retourner soit sur un statut x_displacement ou y_displacement, va rester dans le statut passage_obstructed et va tourner à droite ou à gauche et parcourir une quinzaine de centimètres s'il n'y a pas d'objet détecté à droite ou à gauche par les capteurs 0 ou 4 du robot (ceux qui ce trouve sur les côtés) ceci permettant d'éviter de tourner si un objet est déjà détecté.

Le dernier cas particulier que le robot gère sans beaucoup de soucis est lorsqu'il est bloqué dans un angle. Dans mon code j'ai une variable qui compte le nombre d'obstacles à la suite qui sont rencontrés, number_of_obstacle. Si ce nombre s’élève à 2 le robot va, au lieu d'essayer indéfiniment de rejoindre sa destination sur l'autre axe, retourner un moment en arrière jusqu'à ce qu'il n'y ait plus d'obstacle détecté par le capteur prox 0 ou 4.

Le schéma ci-dessus montre les différentes étapes que le robot va effectuer si il se retrouve "coincé" dans un coin. Il roule d'abord dans une direction jusqu'à observer un obstacle (1), ensuite il effectue donc une rotation de 90° car il y avait un obstacle en face (2). Cependant après cette rotation, il se retrouve encore en face d'un obstacle, il effectue donc encore une rotation de 90° (3) et va ensuite avancer de 15 centimètres lorsqu'il ne détecte plus rien sur son côté. Ensuite il rotate à nouveau de 90° (4) et, à partir de ce moment, il rejoint de nouveau un statut classique de déplacement ici le Y_DISPLACEMENT(5).

Voilà comment fonctionne mon système d'évitement d'une vision plutôt conceptuelle. D'une manière plus technique voilà son fonctionnement: premièrement, à l'aide d'une boucle for les valeurs des capteurs sont analysées et pour chaque capteurs au-dessus d'un certain niveau le capteur est compté comme "trigger":

 for i in range(5):
    if prox[i] > 2400:
        prox_triggered += 1 
    if prox_triggered >= 1 and not robot_status == ROTATING \\
          and not robot_status == PASSAGE_OBSTRUCTED: 
        object_avoided = True
        robot_status = PASSAGE_OBSTRUCTED
        next_status = PASSAGE_OBSTRUCTED
         break
     

Si plus de 1 prox est au dessus de 2400 (les capteurs peuvent avoir une valeur entre 0 et 4300, 0≈15 cm) alors il incrémente 1 à la variable prox_triggered et si cette variable est au-dessus de 1 alors il défini le robot_status = PASSAGE_OBSTRUCTED si ce n'est pas le cas il continue son chemin normalement

A présent le robot sait quand il est en face d'un obstacle. Dans le statut PASSAGE_OBSTRUCTED il rentre dans une première boucle qui s'occupe de gérer les cas simples d'évitement. Si il s'agit d'un cas d'évitement simple après être passé dans cette partie du code qui ne fait que conctrètement demander une rotation à droite ou à gauche au robot le code va juste passé dans un robot_status = resume_status() qui est une fonction qui renvoie le robot sur un statut soit X_DISPLACEMENT ou Y_DISPLACEMENT.

C'est dans les cas particuliers que les choses se corsent. Tout d'abord, le robot est capable de savoir combien de fois de suite il rencontre un obstacle. Ce nombre ce réinitialise automatiquement après avoir parcouru une quinzaine de centimètres. Si le robot rencontre donc 2 obstacles de suite il va, au lieu de retourner sur un statut classique avec la fonction resume_status() , entrer dans une boucle spécial qui lui permet de faire une autre rotation et ensuite qui le fait avancer jusqu'à ne plus capter d’obstacle à droite ou à gauche à l'aide des prox 0 et 4. Cette méthode permet de gérer les cas d'obstacle en forme de coin.
Si après avoir effectué cette procédure il rencontre encore un autre obstacle en forme de coin, certaines fois il va, soit rentrer dans une autre procédure similaire, soit essayé de rejoindre un statut classique avec la fonction resume_status().%% % Voilà dans les grande ligne comment fonctionne le programme qui permet d'éviter les obstacles. Comme je l'ai dis en amont, il est loin d'être parfait, je parlerai plus des limitations de mon projet dans la section discussion.

2.2.2 Le dock

La seconde partie de mon projet consiste en avoir un dock dans lequel le robot pourrait se parquer. Malheureusement, par manque de temps je n'ai pas pu pleinement finaliser la construction de ce dernier et le développement du programme permettant au Thymio de se parquer. Cependant, ce n'est pas pour autant que je ne me suis pas intéresser à cette partie et j'ai pu crée un système alternatif moins complet mais qui rejoint l'idée de "dock".
Pour pouvoir se parquer, le robot devais être capable de suivre une ligne et de la suivre jusqu'à être parquer. J'ai donc quand même développer le système qui permet au robot de suivre une ligne. Pour cela j'utilise les capteurs "prox.groud.reflected" 1 et 2 qui me permettent de détecter si le sol réfléchi bien ou non la lumière infrarouge émise par les capteurs. Le noir absorbant la lumière, il ne reflète pas bien la lumière est donc quand les valeurs captées sont faible cela signifie que le robot est sur du noir, ou qu'il n'y a pas de sol(qu'il est en l'air). Mon programme fonctionne donc de tel manière:

1. On récupère les valeurs des capteurs
2. On compile du code aseba et on l’exécute dans le robot
3. Lorsque le robot est parqué on arrête le code

En premier pour récupérer les valeurs des capteurs "prox.ground.reflected" 1 et 2, on utilise la fonction:

with ClientAsync() as client:
    async def get_thymio_variables():
        with await client.lock() as node:
            global prox_ground_refelcted
            #fonction de la librairie qui permet de demandé le valeurs 
            await node.wait_for_variables({"prox.ground.reflected"}) 
            #des variables internes du thymio
            prox_ground_refelcted = node.v.prox.ground.reflected[0:2]
    client.run_async_program(get_thymio_variables)

De cette manière, il est ensuite possible d'avoir accès à la valeur des capteurs stockée dans la variable prox_ground_reflected

Cela étant fait, lorsque le robot est assez proche de sa destination (dans un cercle de 20 cm autour de la destination), si le robot a des valeurs trop petites pour ses capteurs une fonction est lancée qui s'occupe de compiler du code aseba qui permet de gérer avec précision le guidage du robot en suivant la ligne. Une fois au bout de la ligne et respectant d'autres conditions, le robot s'arrête et le programme se termine

2.2.3 Le plateau

Normalement, mon projet devait aussi comprendre une dernière partie qui devait permettre au Thymio de transporter un objet et de le relâcher tel que dans le schéma suivant:
Malheureusement, par manque de temps je n'ai pas pu compléter cette partie du projet. D'un point de vue développement cette partie n'aurait pas du être très compliquée. Le moteur qui devait permettre au plateau disposé sur le robot de tourner devait être contrôlé par une carte d'acquisition "Adafruit 16-Channel PWM/Servo HAT & Bonnet" qui possède une librairie python qui permet très simplement de contrôler des servomoteurs. Sachant que mon objectif était uniquement de faire tourner la plaque de 90°, quelques simples lignes de code comme montré ci-dessous aurait du suffire, en ajoutant quelques conditions avant de déclencher ces lignes. Mais il faut d'abord s'assurer d'avoir quelques prérequis d'activer avant: d'abord il faut activer l'utilisation du protocole I2C sur le Raspberry pi:

sudo apt-get install python-smbus
sudo apt-get install i2c-tools

Ensuite, télécharger la librairie python adafruit-circuitpython-servokit:

sudo pip3 install adafruit-circuitpython-servokit

Dès à présent, il est possible d'utiliser la carte d'acquisition correctement, et avec les lignes suivante contrôler le moteur tel que prévu:

from adafruit_servokit import ServoKit
import time
#l’argument channels peut varier en fonction des pins 
#utilisés sur la carte pour brancher le servomoteur
kit = ServoKit(channels=16) 
kit.servo[0].angle = 90 #cette ligne effectue une rotation de 90° au servomoteur. 
time.sleep(2)
kit.servo[0].angle = 0 # permet de revenir à la position initiale

Voilà ci-dessus listé les 3 axes principaux de développement de mon projet. Je n'ai pas encore parlé des limitations de mon programmes dans ces différents domaine très précisément, mais vous en trouverez plus dans la section "discussion" de ce rapport.

3. Résultats

Dans cette section, vous trouverez différentes expériences faites et leurs résultats. Des vidéos du robot en action seront aussi disponible, cependant ce n'est pas utilse d'en faire pour chaques expérience que je souhaite faire. Une première expérience intéressante à effectuer est de regarder la précision du Thymio sur un déplacement de 2 mètres sur X et 2 mètres sur Y mètres sans obstacle et sans le système qui s'occupe de parque le Thymio. En faisant l'expérience on obtient ~5cm d'imprécision.

Une seconde expérience intéressante est maintenant de placer des obstacles sur le chemin du Thymio et voir à quel point la précision en est impactée. Il me semble important de donner quelques détails par rapport aux obstacles que le Thymio rencontre. Les capteurs utilisés par le Thymio pour détecter des obstacle étant des capteurs infrarouge, les surface mates et sombres peinent à être détectées. Pour obtenir les résultats les plus concluant il est mieux de favoriser des obstacles blancs et réfléchissants bien la lumière tel que la boite du Thymio. Ceci dit, voici la vidéo de l'expérience. Pour des raisons d'espaces la distance parcourue n'est que de (1.2, 0.8) mètre:

La dernière expérience qui me semble pertinent à effectuer est de tester le déplacement du robot rencontrant des obstacles et se parquant à la fin, une vidéo est aussi disponible ci-dessous dans les même conditions que l'expérience précédente:

4. Discussion

4.1 Discussion des résultats

Maintenant il est intéressant de pouvoir analyser et discuter les résultats obtenus. Pour la première et seconde expérience, il est visible que l'imprécision tend à s'agrandir avec le nombre d'obstacles rencontrés. Dans la deuxième expérience on voit bien sur la vidéo ce soucis, on voit surtout bien le souci de rotation que j'aborderai un peu plus bas. A la fin, le robot se trouvait à 7 cm de sa destination(point en bleu), cela reste une imprécision satisfaisante. Un autre point amusant est que comme vous l'aurez remarquer, le robot à réussi à passer l'obstacle en forme d'angle, cependant il l'a fait d'une manière tout à fait inattendu. Normalement il aurait dû descendre vers le bas sur Y et ensuite compléter la distance manquante sur X, mais là le robot décide de monter dans les Y et passer par l'autre côté de l'obstacle.

Revenons en au système de rotation qui manque de précision, cela est dû au matériel principalement. Ce fut tout au long du projet un soucis persistent, le problème étant difficilement améliorable de la manière dont j'ai fait les choses. Cependant certains autres élèves ayant aussi réalisés un projet sur le Thymio ont géré le problème différemment avec des résultats plus concluant. c'est notamment le cas du projet suivant ThymioSearch. Mais si on ne prend pas en compte ce problème le robot montre une précision satisfaisante.

La dernière expérience reprend essentiellement la première juste en ajoutant au robot la capacité de se "parquer". Ce système est loin d'être parfaitement abouti. On le voit bien sur la vidéo ou le robot a besoin de s'y reprendre une deuxième fois avant de se parquer correctement. Mais, si le temps le permettait, il paraît tout à fait envisageable d'intégrer ce système au projet. De plus il permet d' "effacer" une partie de l'imprécision sachant que la ligne trace un périmètre assez large autour de la destination qui compense une imprécision jusqu'à une hauteur d'une quinzaine de centimètres.

4.2 Autocritique du projet

En effet, le projet ne montre qu'une partielle réussite sur tout les aspects à peu près. Du système de navigation qui n'est pas encore parfait (même si sur ce point là, je pense que de manière très réaliste la perfection était compliquée à atteindre), par le dock qui n'est pas finalisé et le plateau qui n'est pas présent non plus il est légitime de se questionner sur les problèmes que le projet à rencontrés. Je vais m'attarder sur ces 3 points dans les 3 sections suivante pour parler des améliorations possible et des soucis rencontrés lors de l'élaboration de ces dernières.

4.2.1 Le système de navigation

C'est la partie sur laquelle j'ai passé le plus de temps, et c'est pourquoi c'est la plus abouti. En effet, malgré son imperfection ses résultats me satisfont. Mais si je devais venir à améliorer cette partie ce sont 2 points que je retravaillerait : les rotations et l'évitement d'obstacles. En effet les rotations imprécises sont un élément important qui agrandi l'imprécision du robot. Si le temps le permettait j’investiguerai différentes options alternatives à celle que j'utilise maintenant pour faire tourner le robot. Le deuxième point qui serait pertinent à améliorer serait le système d'évitement d'obstacle. Je pense que il pourrait être optimisé pour éviter de prendre d'énormes détour quand les obstacles sont particuliers. Un deuxième point qui pourrait être amélioré serait de régler les cas ou le robot se bloque indéfiniment.

4.2.2 Le dock

Comme vous avez pu le constater pour l'instant il n'y a pas de dock à proprement parler mais plutôt un point entouré de boites à sa place. Et le système qui s'occupe de parquer le robot est loin d'être abouti. Mais cette partie est plutôt là pour prouver qu'avec un peu plus de développement il serait possible d'obtenir des résultats plaisants. Un des principaux soucis est dû aux capteurs qui sont utilisés pour reconnaître la ligne. En effet ces capteurs fonctionnent avec la réflectivité du sol ce qui veut dire que plus une surface est clairs et brilliante plus elle réfléchie bien la lumière, leporgramme regarde alors quand ces valeurs sont plus basse que la normal. Mais cela ne veut pas dire qu'une ligne en particulier a été rencontrée mais simplement que le robot circule sur une surface peu réfléchissante. D'autres méthodes pourraient être privilégiées comme une caméra qui pourrait trouver la ligne et la suivre ou bien reconnaître le dock et se parquer dedans (même si cela est plutôt complexe à mettre en place).

4.2.3 Le plateau

C'est la partie du projet qui est malheureusement passée à la trappe. En effet, principalement par manque de temps, c'est la partie que je trouvais la moins problématique à louper, car ce qui importait vraiment c'était l'aspect déplacement plus que de pouvoir transporter un objet (même si ça aurait permis d'avoir un projet plus complet sachant que l'application de ce dernier est la distribution de colis).

4.2.4 Autres améliorations

Certaines autres améliorations serait aussi imaginable. Intégrer plus de protocoles de sécurités notamment pourrait être utile. Par exemple si le robot rencontre une falaise, l'arrêter ou encore arrêté les moteurs si l'accéléromètre rencontre des valeurs anormalement grandes, ce qui voudrait dire que le robot est en train d'être manipulé ou qu'il chute.
Ajouter une programme qui permettrait au Thymio de retourner à son point de départ après avoir livré le colis serait aussi une bonne piste pour emmener le projet plus loin.

5. Conclusion

Pour conclure, ce projet, malgré la partielle réussite, a été très intéressant et enrichissant à réaliser. En effet, d'un point du vue technique, au début j'avais proche de zéro connaissance sur le langage de programmation python, et j'ai pu voir une rapide évolution sur ce langage. Bien que je ne puisse prétendre être devenu un expert j'ai pu acquérir un niveau satisfaisant qui a, en tout cas été assez pour faire ce projet. Mais cela m'a aussi ouvert les yeux sur tout ce vaste monde de la programmation et dans lequel c'est avec plaisir que j'ai plongé (enfin pas tout le temps). Ce projet m'a aussi permis de voir ce que c'était de travailler avec de l'hardware et ses contraintes techniques, à toujours devoir trouver des alternatives et des moyens efficaces de contourner les défaillances du robot. Ce fut aussi une expérience intéressante concernant la gestion de projet, et qui m'a permis de, à l'avenir, savoir comment mieux structurer un projet, donnant les débuts d'outils importants pour le futur. Pour le mot de la fin j'ajouterai que, avant tout ce que je viens de dire, je me suis surtout beaucoup amusé et c'est aussi ça qui fait toute la différence.

Références

librairie python "tdmclient", édité par Yves Piguet
musique de la première vidéo : Fasion - No Cry
musique de la deuxième vidéo : SupahV - Something Behind Me