Robots suiveurs

Sujet

Nous proposons aux participants de créer et développer des robots connectés, sur le thème initial de robots suiveurs. Le scénario de départ fait intervenir un robot-maître, suivi de 2 robots en file indienne. Ce scénario est appelé à évoluer en complexité au fil de l'avancée du projet.

Les robots seront développés sur des bases Stinger et Traxer qui embarquent une carte microcontrôleur qui gère la puissance et l'asservissement. Le dialogue (envoi de commandes) avec cette carte se fait par liaison série TTL 5V. L'intelligence du robot et la communication sans fil sera gérée par Arduino Yùn.

Projet

Participants : Charlotte, Safae, Léa, Flora, Jimmy, Mehdi, Cyril, Yoann, Axel.

Objectif

• Avoir 3 robots qui se suivent.
• Obtenir la même distance entre les robots au départ et à l’arrivée.

1ère solution évoquée : Robot maitre avec détection les autres sans, le maitre transmet l’itinéraire à suivre aux autres robots.

Problème : si vitesse différente des robots ça ne marchera pas.

2ème solution : le premier détecte et dit aux autres le parcours à suivre. Les deux autres suiveurs suivront le même parcours, ils auront cependant juste a veiller que la distance avec le robot de devant soit correct (sinon ils s’adapteront -> Accélérer/freiner).

Problème : nécessité de communiquer entre les robots.

Communication entre les robots

• 1ère solution:
  • Wi-Fi comme vu en première séance
  • Ethernet
  • Bluetooth

-> Choix de Wi-Fi car fiable et vu en première séance de projet.

Solutions techniques apportées en « vrac » :

• Utilisation de timers pour savoir combien de temps le robot doit rouler avant de s’arrêter.
• Les roues du robot sont asservies. Le robot va faire en sorte d’atteindre la vitesse qu’on lui donnera.

Résumé de la méthode à aborder pour le moment

Le maître détecte l’obstacle et tourne sur place d’un côté, il communique ensuite aux autres robots la distance minimum à partir de laquelle les robots esclaves devront tourner si il détecte un obstacle.

Problèmes engendrés par cette méthode : Pendant que le robot maitre tournera il est possible que les esclaves détectent le robot maitre en pleine manœuvre comme un obstacle et qu’il commence à tourner, ce qui décalerai le parcours du robot esclave car il n’était pas censé tourner avant de détecter l’obstacle.

Solutions envisagées (à étudier plus tard dans le projet) : Pendant que le premier robot tourne les autres s’arrêtent/ralentissent et attendent un peu que le robot est terminé sa manœuvre de rotation. -> Cependant il faudra que les deux robots suiveurs rattrapent la distance perdue pendant qu’ils étaient à l’arrêt par la suite.

Répartition du travail :

• On se divise le travail en trois groupes pour éviter de tous travailler sur la même chose.
• Un groupe travaillera sur la communication entre deux cartes Arduino coté serveur
• Un autre groupe travaillera sur le robot maitre (mise en marche et détection d’obstacles)
• Un autre groupe travaillera sur la communication coté client
• Mise en commun des méthodes mises en place pour le calcul de la distance entre le capteur et l’objet pour arriver à une méthode la plus fiable possible de calcul de distance à l’aide des capteurs.

Idées de développements ultérieurs

• Faire un parcours sans obstacles ou les robots ferait une chorégraphie et se rejoindrait tous à un moment donné.
• Programmer les robots pour que le robot maitre, si jamais un robot est déplacé, puisse rappeler tout ses robots et qu’ils se remettent en place (PROBLÈME : il faudrait un GPS -> Matériellement peut possible à réaliser pour le moment).
• Commande à distance pour ordonner une séparation par exemple puis il faut qu’ils se remettent tous en place.

Idées à approfondir peut être et/ou à étudier pour pouvoir réaliser un projet intéressant.

Phasage

Jour 1

Qu'est-ce qu'on voulait faire ?

Prise en main de la carte Arduino Yun.

Dans un premier temps, notre objectif était de faire clignoter la LED N°13, tout d'abord, en passant par le port série de la carte Arduino Yun, à et en suite à partir d'une requête HTTP.

Qu'est-ce qu'on a fait ?

Pour atteindre notre objectif, dans un premier temps nous avons créé une méthode Blink , qui permet de faire clignoter la LED N°13 à partir du port série de la carte Arduino.

Dans un deuxième temps ,nous avons configuré la carte en s'y connectant à partir d'un ordinateur en Wi-Fi pour pouvoir lui envoyer des requêtes HTTP. Nous avons ensuite utilisé un code ( fourni par Mr.Eric VERNEY ) , que nous avons modifié en important la méthode Blink utilisée précédemment accessible depuis l'adresse 192.168.240.1/arduino/blink et permettant de faire clignoter la LED.

Objectif pour la séance prochaine

Prendre en main un télémètre à infrarouge , le brancher à la carte Arduino Yun , et effectuer des mesures de distance précises.

Jour 2

Qu'est-ce qu'on voulait faire ?

Ce jour là nous avons eu le télémètre à mettre en place. Chaque groupe a travaillé de son côté pour prendre en main le télémètre à infrarouge et effectuer la tâche souhaitée.

Le but était d'arriver à mesurer une distance fiable et précise grâce au télémètre branché sur la Arduino Yùn.

Qu'est-ce qu'on a fait ?

1è partie

Chaque groupe a d'abord lu la datasheet du composant. Puis nous avons connecter la télémètre à la Arduino en programmant les ports au préalable.

Une fois le télémètre en place, nous avons procédé de manière suivante:

• écriture d'un code pour récupérer les valeurs lues en mV par le télémètre
• lecture des valeurs et amélioration de la précision des mesures via un code qui fait une moyenne de 200 valeurs.
• conversion des valeurs lues des mV en cm via une équation de linéarisation de la courbe théorique de la datasheet

2è partie: Brain Storming

A la fin de la séance nous nous sommes réunis afin de discuter sur le cahier des charges,le travail à réaliser et sa répartition.

Au cours de ce brain storming, plusieurs solutions étaient envisagées quand à la réalisation du projet:

• Les trois robot sont équipés de télémètres et chacun gère les obstacles qu'il a face à lui. Les deux robots qui suivent doivent juste garder la distance. Solution non retenue car demande un certains nombre de télémètre.
• Deux robots suiveurs reçoivent les ordres du premier qui transmet l'itinéraire mais non retenue car si la vitesse est différente entre les robots ça ne marchera pas.
• Le premier détecte et dit aux autres le parcours à suivre. Les deux autres suiveurs suivront le même parcours, ils auront cependant juste a veiller que la distance avec le robot de devant soit correct (sinon ils s’adapteront -> Accélérer/freiner). Cela nécessité de communiquer entre les robots.

La dernière solution est la solution retenue.

Qu'est-ce qu'il nous reste à faire ?

Le projet étant à son début, tout reste à faire!

Objectifs à court terme

• Etablir la communication entre deux cartes via WiFi (un serveur / un client)
• Fixer le télémètre sur un robot et diriger le robot par rapport aux obstacles.

Jour 3

Qu'est-ce qu'on voulait faire ?

Notre objectif de cette séance était d'avancer les deux grosses parties du projet en parallèle. Ce travail consistait à :

• Mettre en place la communication Client/Serveur sur deux cartes Arduino.
• Réfléchir a un système et commencer sa réalisation pour l'installation des capteurs sur le robot de tête (robot qui va détecter les obstacles/robot serveur).

Qu'est-ce qu'on a fait ?

Partie Communication

Tout d'abord il a fallu nous connecter à nouveau aux cartes Arduino Yùn afin de pouvoir les configurer.

Notre objectif étant de pouvoir ensuite travailler sur les cartes via un point d'accès commun, nous permettant de communiquer entre nos PC et nos cartes via notre réseau (et aussi tester la communication directement entre les cartes).

Toutes les informations passeront par notre point d'accès. Notre carte est branchée à l'ordinateur uniquement pour alimenter la carte (elle ne reçoit plus de données en USB).

Concernant la communication inter-cartes nous désirions simplement commencer par envoyer un message Hello World pour vérifier si l'échange de données se faisait de manière correcte.

Problèmes rencontrés

Aucuns point d'accès disponible et visible depuis notre salle de travail ne correspondait a nos attentes. Soit le réseau en question nécessitait l'utilisation de proxys ou bien notre carte se connectait au réseau, mais lorsque l'on connectait notre ordinateur a celui-ci la carte se déconnectait au bout de quelques secondes.

Pour notre message Hello World nous arrivions bel et bien à transmettre notre message cependant des séries de '-1' se glissaient au milieu de notre message. La solution à ce problème a été trouvée au début du jour 4.

Solution mise en place

Nous avons donc décidé d'utilisé un des routeurs fournis par l'école (modèle D-Link DWL 2100 AP) et de le configurer nous même afin que nous puissions agir sur tout les paramètres de notre réseau (notamment configurer le DHCP, le Lease time...). Après configuration de celui-ci nous avons finalement réussi à nous connecter a notre point d'accès (nos ordinateurs ainsi que nos cartes, ces dernières ce connectent maintenant par défaut à notre routeur).

Présentation du support de suivi

Il nous a été présenté le support sur lequel nous devions faire le suivi journalier du projet, il s'agit donc de ce site.

Partie Capteurs Robots

Pour cette partie nous avons commencer par réfléchir a comment notre robot de tête (robot serveur) allait pouvoir détecter nos obstacles. Nous devons être sûrs que notre robot pourra détecter un obstacle sur toute sa largeur (c'est a dire même au niveau des roues).

Ceci à permis de guider notre premier objectif de travail, qui a alors consisté a déterminer quel était expérimentalement le champ de vision de notre capteur (Est-il Large ou mince?). Nous avons réalisé un programme rapide grâce auquel nous faisions tourner les roues du robot lorsqu'il détecte un objet a moins de 30cm (au delà de cette distance notre capteur n'est plus très fiable). Notre conclusion est que le capteur détecte l'objet seulement si il se trouve dans l'axe (couloir d'environ 1cm) de l'émetteur de notre capteur (il y a un émetteur ainsi qu'un récepteur sur notre télémètre).

Cette étape d'expérimentation nous a permis de nous poser la question suivante : De combien de capteurs allons nous avoir besoin?

Nous sommes partis sur une base de trois capteurs pour pouvoir couvrir une largeur maximum de notre champ de course. La question suivante que nous avons du nous poser était de savoir comment allions nous les positionner sur notre robot pour pouvoir détecter les obstacles de la meilleur façon possible.

Voici ci-dessous les deux premières configuration auxquelles nous avons tout d'abord pensé :

1er choix de configuration étudié pendant le Jour3

Choix de configuration adopté pendant le Jour3

La première n'a pas été approfondie car trop imprécise. La deuxième quand à elle est celle qui a été utilisée pour notre étude tout le reste de la journée. En effet, grâce à cette méthode nous pensons pouvoir détecter un objet sur toute la largeur du robot quelle que soit sa taille.

Pour installer ces télémètres de manière stable sur notre robot nous avons utiliser des socles fournis par l'école nous permettant de visser les capteurs au robot de manière stable (voir photo ci-dessous).

Socle utilisé pour placer nos capteurs

Problème rencontré

Nous avons constaté un problème lorsque le capteur n'a aucun objet placé devant lui (distance infinie). En effet nous lisons une valeur numérique en sortie du capteur identique à la valeur que l'on devrait recevoir lorsque notre objet se trouve a 10cm de distance environ. Ceci est problématique car il n'y a pas de différence au niveau du capteur entre un chemin libre d'accès ou un objet situé à 10cm.

Solution apportée

Nous avons pensé à régler la distance seuil de notre programme (distance à partir de laquelle notre robot va avertir d'une collision et vouloir changer de direction) juste en dessous de la distance qui nous pose problème au niveau du capteur (10cm dans notre paragraphe précédent). Comme cela si notre objet est a 10cm ou qu'il n'y a pas d'objet notre robot avancera. Mais si l'objet est detecté a 9cm alors une manoeuvre sera effectuée. Nous devons encore approfondir cette méthode de travail car nous ne sommes pas sûrs de sa fiabilité.

Objectifs pour la prochaine fois

Communication

La communication entre les deux cartes est à poursuivre. En effet, on arrive à envoyer une donnée par le serveur et qu'elle soit récupéré par le client, mais il y a encore des problèmes. La donnée réceptionnée comporte plus de données que l'original (les -1).

Il faudra donc régler ce problème afin que la communication entre les robots soit faite sans interférence ni perte de données.

Robot et télémètre

Il nous faut approfondir notre méthode de détection d'obstacles car pour le moment certains problèmes sont encore présents et notre objectif final serait d'obtenir une détection fiable.

Il nous faudrait vérifier les caractéristiques de nos trois télémètres et effectuer une série de test pour pouvoir utiliser les résultats obtenus afin d'arriver à une solution fiable de détection.

Wiki

• Rédaction du wiki
• Suivi du wiki

Jour 4

Qu'est ce qu'on voulait faire ?

Comme dit dans le Paragraphe Jour 3: Objectifs pour la prochaine fois nous devons améliorer la partie robot en mettant au point un système le plus fiable possible. Concernant la partie communication nous voulons pouvoir communiquer les informations que nous souhaitons entre les deux cartes en passant par notre routeur. Nous aimerions aussi déterminer une méthode de communication entre le maître et les esclaves. Nous mettre d'accords tous ensemble sur cette méthode et essayer de la fiabiliser pour échanger nos données de la façon la plus fiable possible.

Qu'est ce qu'on a fait?

Partie communication entre les deux cartes

Travail réalisé

On arrive a récupérer le message hello world sur la deuxième carte et à l'afficher pleinement sans -1, en modifiant le code de telle sorte à ce qu'il n'y ait envoi que sur demande du client. Par la suite , nous avons allumé la LED 13 de la première carte , à partir de la deuxième carte . Nous avons mis en place un télémètre afin de détecter si l'obstacle est proche de celui-ci, et si c'est le cas , allumer la LED.

La LED s'allume quand la main est proche du capteur.

La LED s'éteint quand il n'y a pas d'objet.

Affichage sur l'interface Arduino de l'état de la LED

Pistes de travail

Deux stratégies d'approche sont possibles:

• Le robot principal (Maître: M) envoie ses données sur le serveur lorsqu’on le lui demande et les deux autres (esclaves :E1 & E2) lisent les données et adaptent leurs trajectoires en fonction de celles-ci.

• Le robot maître donne aux robots esclaves l’ordre de faire le mouvement, ces derniers lui renvoient l'information qu'ils ont bien reçu l'ordre.

Pour la suite du projet , Nous avons choisi d'utiliser la deuxième stratégie, car celle-ci présente une étape en moins, ce qui est pratique, et elle évite une surcharge du serveur du robot maître.

Tâches réalisées

• Tout d'abord nous avons testé et approuvé une nouvelle méthode de positionnement des capteurs sur le robot maître. En effet comme vu dans le paragraphe concernant la disposition des capteurs sur le robot, nous avions réfléchi et testé deux méthodes différentes cependant nous avons au début de cette 4ème journée réfléchi à une troisième méthode plus appropriée.

En effet, cette nouvelle méthode (voir schéma ci-dessous) nous permet de balayer toute la largeur de notre champ de course tout en restant très précis au niveau des capteurs (on a pas besoin de détecter les objets de très loin, donc on s’affranchit des problèmes de détection a de grandes distances).

Choix de configuration adopté pendant le Jour4

• Changement de format de la valeur utilisée pour notre détection. Nous convertissions la valeur récupérée en sortie du capteur puis nous effectuions des calculs pour convertir cette donnée en cm. Cependant nous avons rencontré de nombreux problèmes à cause de cette conversion donc nous avons décidé de ne pas convertir la valeur en cm mais de la laisser telle qu'elle. Afin que celle-ci soit plus facilement utilisable.

• Nous avons crée et utilisé un programme permettant à notre robot de tête de détecter les obstacles ainsi que de savoir de quel coté se trouve l'objet (plus à droite, à gauche, ou complètement devant). Grâce à cette information le robot peut ensuite effectuer la manœuvre nécessaire qui va lui permettre d'éviter l'obstacle (tourner droite/gauche , marche arrière).

Vous pouvez voir une démonstration de ceci dans la vidéo suivante prise à la fin du jour 3 de notre projet.

Objectifs à réaliser pour la prochaine fois

Mettre en commun les deux parties sur lesquels nous avons travaillé. Ceci consiste à faire avancer ou arrêter un robot et que celui ci communique cette information à une seconde carte Arduino Yùn.

Dans un second temps nous aimerions avoir un second robot qui fonctionne (nous ne sommes pas sûrs à 100% que les autres robots soient opérationnels).

Jour 5

Qu'est ce qu'on voulait faire ?

• Faire avancer ou arrêter un robot tout en communiquant cette information à une deuxième carte Arduino. Celle-ci sera implanté sur un deuxième robot par la suite.
• Vérifier le bon fonctionnement d'un deuxième robot pour pouvoir l'utiliser par la suite.

Qu'est ce qu'on a fait?

Tests des nouveaux robots

Plusieurs autres robots sont disponibles dans les placards de notre école. Trois sont relativement identiques (même forme, deux roues motrices à l'avant et une roue pour stabiliser à l'arrière). Seul la carte motrice gérant notamment l'asservissement des roues du robot diffère selon le robot, cependant ceci ne devrait pas nous poser de problème pour faire fonctionner les robots. Un quatrième robot est mis à notre disposition, il est un petit peu différent de part sa conception cependant celui-ci est déjà monté et ne nécessite pas autant de travail que les autres robots. Une partie de notre groupe a donc commencé les tests sur un des deux "nouveaux" robots. Une fois ce robot effectif, nous avons commencé les tests sur le deuxième robot.

Problèmes rencontrés

Le programme que nous voulions tester était simple, nous voulions juste faire avancer et arrêter le robot afin de vérifier son bon fonctionnement. A ce stade ci un problème s'est posé car les deux roues ne tournaient pas à la même allure. Ce qui empêchait alors notre robot d'avancer de manière rectiligne. Après avoir essayer de trouver la source du problème, nous avons enfin compris d'où pouvais venir le problème. En effet lorsque le robot était alimenté avec la batterie portable, nous ne pouvions pas le faire avancer droit. Mais si nous l'alimentions à l'aide d'une alimentation fixe les roues tournaient enfin à la même vitesse (un très léger décalage minime entre les deux roues).

Communication entre un robot et une autre carte Arduino

Dans cette partie l'objectif était le suivant. Nous voulions réussir à faire avancer notre robot et pouvoir communiquer en Wi-fi l'état actuel du robot à une autre carte. C'est à dire que lorsque que l'on avance on envoi une requête HTML à notre carte serveur et celle-ci par exemple pourrait exécuter une action telle qu'allumer une de ses Leds pour vérifier la bonne transmission de l'information.

Comme nous l'avions déjà fait à la séance précédente nous avons pu communiquer des informations entre la carte du robot et l'autre carte Arduino. Ensuite l'étape suivante était d'envoyer depuis la deuxième carte (celle qui n'est pas implémentée sur un robot) un ordre d'avancer via Wi-fi à notre robot. Cette étape ci a été fonctionnelle pendant la première moitié de notre journée de travail cependant un problème de taille allait se poser par la suite.

Problèmes rencontrés

Lorsque nous avons voulu effectuer l'étape de la communication dans l'autre sens un problème est survenu. Il nous était alors impossible de faire avancer notre robot ET ensuite de communiquer via Wi-fi l'état de notre robot. Ces deux étapes qui marchaient parfaitement séparément ne pouvaient pas être combinées.

Après de nombreux essais et recherches sur des forums nous avons pu identifier la source du problème. En effet la communication Wi-fi (utilisant un bridge reliant le microcontrôleur et le microprocesseur) doit utiliser une ressource qui est la même que celle utilisée par la liaison Serial reliant la carte Arduino à la carte motrice de notre robot. C'est à dire que l'action d'avancer, et celle d'envoyer des données nécessitent toutes deux l'accès à une ressource qui ne peut pas être partagée. Nous avons alors pensé à allouer du temps pour que chaque partie du programme puisse utiliser la ressource mais nous ne savions pas comment forcer le bridge à perdre l'utilisation de la ressource en question.

Nous avons pensé essayer de contourner ce problème en utilisant un câble différent pour faire passer les ordres entre la carte Arduino et la carte motrice de notre robot. Nous voulions utiliser un câble micro-usb - RS232 (5V). Cependant aucun câble de ce type n'était présent dans l'école.

Objectifs à réaliser pour la prochaine fois

Nous aimerions régler ce problème de transmission entre la carte motrice et notre carte Arduino pour pouvoir ensuite effectuer nos tests entre notre robot et notre carte, puis entre nos différents robots vu que ceux-ci semblent opérationnels.

Jour 6

Qu'est ce qu'on voulait faire ?

Notre objectif principal est de trouver une solution au problème de communication entre les cartes ALORS QUE notre carte Arduino communique déjà avec notre carte motrice via une liaison TX/RX.

Qu'est ce qu'on a fait?

Comment résoudre notre problème?

Le problème de câble ne semble pas réalisable dans l'immédiat à cause d'un problème de matériel. Cependant après une discussion avec deux spécialistes Mr Bru et Mr Minot plusieurs solutions possibles ont été évoquées (qui ne nécessite pas de câble particulier). L'une d'entre elle, sur laquelle nous avons concentré nos efforts consiste à déplacer (au niveau logiciel) les pins sur lesquels la communication TX/RX s'effectue (pour nous permettre de libérer le bridge). Voici le bout de code qui nous permet d'affecter notre TX/RX aux pins que nous voulons (il suffit d'ajouter ces deux lignes de code):

#include <SoftwareSerial.h>

SoftwareSerial mySerial(10, 11); // Le premier paramètre correspond a la pin du TX, le deuxième au RX

Après utilisation et test de cette méthode nous avons effectivement pu à la fois avancer et envoyer l'état de notre robot sur l'autre carte arduino.

Communication entre deux robots

Maintenant que nous pouvons communiquer entre un robot et une carte, nous aimerions communiquer entre deux robots. C'est à dire de pouvoir faire avancer un robot, qu'il envoit son état à l'autre robot ("j'avance"), et que l'autre robot avance à son tour.

Voici une vidéo présentant cette étape de développement de notre projet. Nous voyons bien notre robot suiveur s'arrêter juste après que notre robot maître se stoppe (un petit temps de latence du à la transmission et au traitement est visible sur la vidéo).

Cependant nous avons remarqué un problème matériel relativement important. Nos robots ne roulaient pas droit alors que nous ne leur disions pas de tourner.

Réparation des roues du robot

Nous devions nous pencher sur ce problème de robots. Les roues arrières de nos deux robots semblaient être la source de ce problème. Après un changement de roues et un graissage de ces dernières les résultats obtenues furent bien meilleurs. Cependant la trajectoire de notre robot n'est pas totalement rectiligne ce qui ne nous permettrait pas de maitriser parfaitement notre trajectoire. Ceci est du au fait que les moteurs des roues ne tournent pas à la même vitesse.

Nous avons essayé de régler ceci en programmant deux vitesses différentes pour les deux roues de notre robot. Cette méthode fonctionne mais nous ne pensons pas qu'elle soit très viable pour la suite de notre projet.

Communication : Contenu des données à envoyer

Après avoir réussi à faire communiquer nos deux robots une question très délicate s'est posée.

Ce que l'on veut :

• Le maître détecte les obstacles, les évite et transmet les informations (ou ordres).
• L'esclave reçoit, traite et exécute l'instruction envoyée.

Ce que l'on sait :

• légère latence entre le moment ou l'on exécute une action sur le premier robot et celui ou elle sera exécutée sur le deuxième robot.
• Vitesse des robots constante (peut être différente entre les deux robot mais reste la même pour un robot durant l'exécution du programme).

Quel est le contenu (et non la forme) des informations à envoyer? Liste des actions que notre robot effectuera :

• Avancer/reculer.
• droite/gauche.
• Stop.

Après avoir réfléchi à plusieurs méthodes différentes nous avons envisagé une possibilité qui pourrait fonctionner. Nous aimerions en fait envoyer les informations à l'esclave en décalé. C'est à dire qu'on attendrai un certains temps avant que le maître dise à l'esclave de tourner par exemple. Comme ceci nous pourrions avoir l'esclave qui suit parfaitement le robot maître (il tournerai au même moment). Seul le moment ou le robot maître s’arrêtera définitivement pourrait être problématique car nous ne voudrions pas que l'esclave percute le robot maître. Cependant si nous connaissons le moment ou nous allons stopper notre application nous pouvons faire en sorte que l'esclave s’arrête a la bonne distance du maitre.

Une autre méthode a été étudiée pendant cette séance. En effet jusqu'à présent nous utilisons la méthode MOGO pour faire tourner les roues du robot. Mais il se trouve qu'il existe une méthode DIGO qui elle fait la même chose mais à laquelle nous pouvons dire roule sur telle ou telle distance. Donc nous pouvons fixer la distance sur laquelle nous voulons rouler (et non pas influer sur le temps pendant lequel nous voulons rouler). Ceci peut être un avantage et nous avons essayé de voir s'il était possible de récupérer la distance sur laquelle le robot a roulé (nous ne fixerions aucune distance mais nous aimerions la connaître).

Au final nous avons réussi à récupérer le nombre de Tics de chacun des moteurs du robot, c'est à dire que si nous connaissons le nombre de Tics par tour nous pouvons ensuite (en récupérant le nombre de Tics compté pendant le trajet d'un robot) en déduire la distance qu'il a parcouru.

Objectifs à réaliser pour la prochaine fois

Examiner la commande vel, qui permet de récupérer la vitesse de rotation d'un moteur, ceci pourrait permettre de contrôler la linéarité de la trajectoire en corrigeant le paramètre de commande en temps réel.