IMA4 2016/2017 P20 : Différence entre versions

Version du 29 mars 2017 à 12:21

Cahier des charges

Ce cahier des charges a pour objectif de définir le projet, ce qui est attendu ainsi que les contraintes de conception qui lui sont associées.

Présentation générale du projet

Le projet consiste à concevoir et développer un environnement virtuel de test pour l'Association de Robotique de Polytech Lille (ARPL). Ce simulateur doit reproduire les conditions de participation à la Logistic League de manière à pouvoir obtenir rapidement des données et tester le code ainsi que les stratégies de jeu utilisés par les robots.

Contexte

Ce simulateur est un outil développé dans le cadre de la RoboCup et plus particulièrement de la Logistic League. La RoboCup est une compétition internationale de robotique dans laquelle on voit beaucoup d'entreprises et de robots connus tel que NAO. Cette compétition a pour but de mettre en avant les évolutions en matière de robotique ainsi que les qualités des organismes participants.

La Logistic League est une des différentes épreuves proposées. L'objectif est de repérer le terrain puis de produire des objets avec différents éléments fournis par des machines et à livrer dans des plages de temps données. Une RefereeBox ou boîte arbitre sert à la coordination ainsi qu'à l'arbitrage. C'est cette boite qui va informer le robots des différents objets à construire avec la date de livraison demandée. Elle va également donner leur rôles aux machines présentes sur le terrain. L'arbitre va enregistrer les horaires de dépôt des objets et la position de chacune des machines lors de la compétition.

Celle-ci se déroule sur une piste de la taille d'une salle moyenne. Chaque équipe peut utiliser jusqu'à trois robots Robotino 3 pour réaliser les tâches demandées. Sur la piste, à part les robots, se trouvent seulement des machines dites de production ou de livraison. Elles vont servir soit à se procurer un élément nécessaire à la production de l'objet final soit à livrer celui-ci lorsqu'il est terminé.

Objectif du projet

Ce projet va permettre de fournir à l'équipe de l'ARPL un simulateur léger et complet, leur permettant de simuler en un court laps de temps un match entier ou partiel et de tester leur code et leur stratégie. Cela leur permettra de développer plus rapidement et efficacement.

Description du projet

Le simulateur devra répondre à un certain nombre de critères. Tout d'abord il lui faudra pouvoir simuler toutes les entités présentes sur la piste lors d'un match. Nous parlons des robots et des machines mais également des capteurs et des conditions de jeu.

Nous devrons faire en sorte que le simulateur puisse facilement intégrer le code de contrôle des robots afin de le tester. De plus il faut permettre à l'utilisateur de gérer les parties du code à tester ainsi que de changer les conditions et paramètres de simulation afin de ne tester que certaines partie du code (par exemple en excluant la gestion des collisions). Nous inclurons une gestion des phases de jeu (Découverte et Production) dans ce but. De ce point de vue l'idéal serait de générer un launchfile et de permettre à l'utilisateur de gérer l'utilisation des nœuds un par un.

En sus, le simulateur gérant les robots de l'équipe adverse, il aura une fonctionnalité de sauvegarde des configurations que ce soit pour le code ou les stratégies afin de comparer l'évolution des performances.

Le simulateur a certaines contraintes afin d'être utilisable et utile. Il doit opérer une compression du temps c'est à dire réaliser la simulation d'un match en moins de temps qu'une durée normale de match. Il s'agit d'obtenir des données représentant la réalité en un cours laps de temps. La communication avec la RefereeBox est indispensable. Celle-ci étant fourni par les organisateurs de la compétition nous n'avons pas à la simuler mais nous devons communiquer avec elle pour rendre la simulation plus réaliste.

Choix techniques : matériel et logiciel

Nous n'avons pas besoin de matériel hormis d'ordinateurs afin de programmer.

Dû à la compétition et aux choix de développement de l'équipe de l'ARPL, nous allons programmer en C++ avec les bibliothèques QT ainsi que le middleware ROS, une surcouche de programmation destinée à la programmation de robots.

Calendrier prévisionnel

Liste des tâches à effectuer

• Simuler les différentes entités
  • les Robotinos ;
  • les machines ;
  • l'environnement.

• Gérer l'interfaçage entre le simulateur et le code des Robots
  • lire et lancer le méta-paquet ;
  • identifier les différents parties du code ;
  • proposer l'activation/désactivation de ces parties et créer un launchfile en conséquence ;
  • créer un système de sauvegarde de tout code interfacé permettant sa réutilisation.

• Simuler un match
  • communiquer avec la RefereeBox et recevoir les différents ordres de celle-ci ;
  • gérer les machines et la communication avec la RefereeBox ;
  • gérer l'équipe de l'utilisateur et son interaction avec le reste de la simulation ;
  • gérer l'équipe adverse et son interaction avec le reste de la simulation.

• Paramétrage avancé de la simulation
  • proposer différents modes de simulations ;
  • activation/déssactivation des paramètres de la simulation ;
  • gestion des phases.

• Interface utilisateur
  • fournir des données utilisables et intéressantes sur la simulation ;
  • créer une GUI ergonomique ;
  • importer les données de la simulation sur la GUI pour une meilleure analyse de celle-ci.

Calendrier

Répartition du temps consacré au projet (120h/personne) :

Feuille d'heures

Planning des tâches

Avancement du Projet

Semaine 1

Nous avons commencé par installer ROS et tout ce dont nous avons besoin pour travailler correctement. Nous avons également suivi des tutoriels pour apprendre à utiliser ROS.

Pour pouvoir travailler en binôme sans problèmes et pour que nos encadrants puissent suivre notre avancement et tester le logiciel, nous avons utilisé le logiciel de gestion de versions Git, sur lequel on publie notre code au fur et à mesure.

Nous n'avions pas encore de dépôt sur celui-ci, donc nous avons commencé par réfléchir à la structure de notre projet. Nous commencerons par implémenter la phase d'exploration, ce qui comprend aussi le déplacement du robot, la détection de machines et de feux ainsi qu'une interface utilisateur basique.

En effet, le match oppose deux équipes ayant jusque trois robotinos qui s'affrontent lors de deux phases. La première est la phase d'exploration, durant laquelle les robots doivent trouver les machines de leur équipe en explorant le terrain. Ils doivent annoncer la position des machines et les signaux des feux de celles-ci : chaque machine, peu importe son type, possède un feu tricolore (rouge, jaune, vert) qui durant la phase d'exploration aura une combinaison de lumières allumées aléatoirement (au moins une doit l'être).

La création d'un simulateur passe par la réflexion sur les besoins en conception du simulateur (décris en partie ci-dessus). Nous avons donc passé un certain temps à schématiser la structure de notre simulateur et à en assimiler les besoins et l'ordre de création.

Semaine 2

Nous avons récupéré un dépôt Git (nommé logistic-sim) sur lequel travailler auprès de nos encadrants, nous pouvons donc commencer la programmation cette semaine.

Ceci étant notre premier projet mêlant ROS et Git, nous avons tenté de créer la structure du projet mais avons vite rencontré quelques difficultés. Nous avons ensuite compris qu'il était nécessaire de d'abord créer un environnement de travail ROS pour le projet, dans lequel on clône ensuite le dépôt Git localement.

Nous obtenons ainsi la structure de projet suivante :

• Workspace ROS
  • build
  • devel
  • src
    • CMakeLists.txt
    • logistic-sim

Les dossiers build, devel, src et CMakeList.txt sont des fichiers et dossiers générés par Catkin, un outil permettant de créer des paquets ROS facilement.

Nous avons ensuite décidé de séparer le code du projet en différents dossiers en fonction des tâches à effectuer :

• Entites pour simuler les différentes entités (Robotinos, machines, environnement...)
• Gestion_Code pour gérer l'interfaçage entre le simulateur et le code des robots
• Match pour simuler le déroulement d'un match
• GUI pour l'interface utilisateur avec le framework Qt

Dans chacun de ces dossiers, nous créerons des packages contenant les différentes fonctionnalités du projet.

Chaque package a la structure suivante :

• CMakeLists.txt
• include pour les fichiers .h
• package.xml
• README.md
• src pour les classes et nodes .cpp
• launch pour les launchfiles

Dans un premier temps, on commence par la gestion de la position du robot et la reconnaissance des feux.

Semaine 3

Nous avons avancé sur la programmation de la gestion de la position du robot et de la reconnaissance des feux.

Nous avons décrit nos classes par des schémas UML avec l'outil gratuit Modélio pour créer une documentation facilement accessible. Les commentaires des fonctions, classes et fichiers au format Doxygen nous permettront également de générer une documentation du projet sous format HTML notamment.

Nous suivons aussi la normalisation du code donnée par l'ARPL pour avoir les mêmes conventions de nommage partout.

Nous avons décidé de créer un nouveau package match qui contiendra les nœuds correspondants aux différentes phases de jeu, et avons donc par conséquent commencé par créer un nœud pour la phase d'exploration.

Nous avons également commencé à réfléchir à la façon dont les informations sont communiquées dans le match : il y a un arbitre, la Referee Box qui permet de faire communiquer le simulateur et les robots jouant le match. En effet, l'arbitre prend les décisions importantes (placement des machines au début du jeu etc.) et c'est à lui que les robots s'adressent. Nous devons donc aussi communiquer avec lui pour recevoir certaines informations (par exemple les informations de base de la phase d'exploration) et les retransmettre dans le simulateur aux nœuds qui en auront besoin.

• 

  Schéma UML du package machine

• 

  Schéma UML du package formes

Semaine 4

Cette semaine, nous avons créé plusieurs nouveaux packages et modifié ceux qui avaient déjà été créés.

Nous avons créé la classe Cercle dans le package formes, nous pouvons donc maintenant utiliser deux formes différentes, le rectangle et le cercle. La classe Entite a elle aussi été rajoutée. En effet, certains attributs des machines sont communs avec ceux des robots; cette classe nous permet de les rassembler et les classes Machine et Robot hériteront ainsi de Entite.

Un nouveau package management a également fait son apparition. Il contiendra les classes Equipe et Manager. Le Manager sera chargé de créer les équipes et permettra d'y accéder partout dans le code, mais aussi de procéder aux différentes initialisations lors du démarrage d'une nouvelle phase.

Au package management s'ajoute le nouveau package robot dont le rôle est de simuler les robotinos lors du match.

• 

  Schéma UML du package machine

• 

  Schéma UML du package robot

• 

  Schéma UML du package formes

• 

  Schéma UML du package management

Nous avons également rendu visite à l'un de nos tuteurs de stage pendant la semaine dans le but d'obtenir un premier retour sur notre travail et l'avancement du projet.

Nous avons pu effectuer immédiatement quelques modifications nécessaires suite aux commentaires de notre tuteur. Nous avons dû, par exemple, clôner leur projet dans le même espace de travail que le notre pour pouvoir réutiliser certains paquets de messages déjà créés. Cela permettra une meilleure compatibilité. D'autres modifications concernaient entre autres les conventions de nommage de certaines classes et l'ajout d'un dossier supplémentaire dans le dossier include de chaque package portant le nom de celui-ci, pour ne pas avoir de conflits quant au nommage des fichiers.

Une réunion avec toute l'équipe des tuteurs a été prévue pour la semaine 5.

Semaine 5

La semaine a commencé par une réunion avec l'équipe de l'ARPL se chargeant d'encadrer notre projet, c'est-à-dire Vincent et Thomas. Nous avons discuté ensemble de l'avancement du simulateur et de l'ordre dans lequel effectuer les tâches. Ils nous également demandé de créer un planning de nos tâches avec la date prévue pour chacune; ils auront en effet besoin de modifier leur code à certains endroits pour pouvoir utiliser le simulateur (nous n'aurons pas besoin de tous les nœuds, certains comme la détection Laser nous étant inutiles) et souhaiteraient savoir lorsque nous seront prêt à tester de nouvelles fonctionnalités.

Nous nous sommes lancés dans l'affichage des formes avec l'outil rviz, qui permet de visualiser en 3D les messages de type visualisation_msgs qui lui sont envoyés sur le topic associé. Ces messages sont disponibles en différents types. Pour afficher les formes nous utiliseront le format Marker qui permet d'afficher un objet en 3D (cubes, sphères, flèches, cylindres) ou en 2D en lui donnant un z de 0.

Nous avons donc commencé par faire les tutoriels sur l'utilisation de rviz puis par ajouter le code nécessaire à l'affichage des formes. Nous avons ainsi décidé d'ajouter la variable du message de type Marker dans la classe Forme; celle-ci sera accessible par toutes les classes filles de Forme, notamment Cercle et Rectangle. Nous avons également créé une méthode display qui sera chargée de mettre à jour la position de la forme et de publier le message. Les différents setters des classes filles modifieront également le message pour qu'il soit à jour lors de l'envoi.

• 

  Affichage de la forme Rectangle dans Rviz

• 

  Affichage de la forme Cercle dans Rviz

Semaine 6

Cette semaine, nous continuons d'améliorer l'affichage en programmant cette fois-ci la classe Robot (qui possède une forme, étant une Entité) pour pouvoir visualiser le robot avec rviz. Nous avons donc ajouté une fonction display à Entite, faisant elle-même appel à la fonction display de sa forme; ce qui permettra un affichage plus facile de l'objet.

Nous avons également ajouté une forme Texte pour afficher du texte informatif sur les formes (par exemple, une lettre et un id pour une entité, "R1" dans le cas du premier robot de chaque équipe). Ce texte est affiché en cyan ou en magenta, en fonction de la couleur de l'équipe. Les noms des markers de la forme et du texte eux aussi dépendent du type de l'entité.

Enfin, nous avons permis au entités de type Machine de gérer leur affichage. Pour cela, nous avons dû créer une classe fille de cette entité pour pouvoir tester son affichage. Le choix s'est porté sur les machines de type BS (Base Station).

En cours de route, nous avons été confrontés à un problème au niveau de l'affichage en 2D. Il semblait logique que la hauteur des objets (en z) soit égale à 0 pour un affichage 2D, mais il s'est avéré que la couleur de l'objet était alors imprévisible (plus souvent noir que de la bonne couleur). Il en fait fallu laisser une légère épaisseur (0.001 mètres dans notre cas) pour que la couleur s'affiche correctement.

Un de nos objectifs était aussi de gérer l'affichage de l'orientation de nos entités. En effet, cela semble essentiel pour les robots par exemple, représentés par des ronds et pouvant se déplacer. Nous avons ainsi créé un nouveau marker Fleche; il était également possible de changer le type de marker en interactive marker ce qui aurait permis l'affichage de flèches de direction, mais celles-ci permettaient de modifier la position de l'objet et n'étaient disponibles qu'en multiple de 2 (déplacement sur un axe). Le choix s'est donc porté sur l'utilisation d'un marker classique dont on change l'orientation en même temps que celle de l'entité. Nous avons rencontré quelques soucis quant à la gestion de l'orientation du marker, celle-ci étant un quaternion (x, y, z, w) alors que nous souhaitons donner l'angle en degrés (ou en radians éventuellement); la documentation n'est pas forcément facile à trouver pour ROS.

• 

  Affichage de l'entité Robot dans Rviz

• 

  Affichage de l'entité BaseStation dans Rviz

• 

  Affichage de l'entité Robot avec une forme Fleche dans Rviz

Nous avons dû corriger nos constructeurs pour être le plus efficace possible et remplir au maximum les besoins des futurs fonctions.

La problématique rendant nécessaire une gestion du temps vient du besoin de l'ARPL de pouvoir contrôler la vitesse de simulation et donc de pouvoir jouer un match très rapidement afin d'observer le comportement de leur code. Nous avons commencé et fini la gestion du temps. ROS intègre une interface de temps qui se cale sur la machine qui lance ROS. Pour que plusieurs machines suivent le même temps il faut opérer une synchronisation des temps. Cependant lors de la simulation tous les robots auront leur référentiel temporel sur la même machine ce qui rend une synchronisation inutile.

Il existe un topic clock qui sert pour les simulations. En forçant nos nœuds à utiliser le temps de simulation, nous avons une échelle temporelle utilisable et synchronisée. Nous avons donc un nœud qui va publier sur ce topic le temps qui sera initialisé à 0 en début de match.

Un paramètre d'environnement ROS sert à régler le facteur d'accélération de la simulation par rapport au temps réel. Il est modifiable à tout instant et est initialisé en premier dans le launchfile.

Semaine 7

Nous nous sommes attaqués à l'affichage du terrain dans rviz.

Pour cela, nous pouvions nous inspirer de code écrit par l'ARPL permettant de charger une carte depuis un fichier .yaml. Certains de leurs packages nous ont été utiles, mais d'autres se sont avérés inutilisables tels quels à cause d'erreurs tantôt de "référence indéfinie" à un fichier, tantôt de "redéfinition" du même fichier (la cause de ces erreurs reste pour le moment toujours un mystère). Nous avons donc opté, pour pouvoir avancer rapidement sur le projet, d'utiliser tel quel ce qu'il était possible d'utiliser, et sinon de recopier les fonctions nécessaires dans notre package. Certaines fonctions nécessitaient d'ailleurs de toute façon des modifications, car dans notre simulateur nous gérons aussi l'affichage de la carte alors qu'eux ne faisaient que la charger.

Un fichier .yaml a la syntaxe suivante :

field:
   name: robocup_simulator
   size: [14, 9, 0.0]
   gradient:
       distance: 0.35
       minValue: 0
   walls:
       bottom1:
           start: [-6, 0, 0.0]
           end: [-4, 0, 0.0]

Nous avons donc commencé par charger le fichier en mémoire en le passant en paramètre à un launchfile lançant le nœud chargé de lire et d'afficher la carte. Ensuite, en faisant appel à des param (paramètres) du nœud actuel et en leur donnant le nom du champs (name par exemple), on peut récupérer les valeurs du fichiers voulues.

Nous avons ainsi créé une classe Carte pour gérer le chargement des données depuis le fichier et toutes les fonctions utilitaires associées, mais permettant aussi d'afficher la carte grâce à une fonction display de même fonctionnement que celles créées précédemment pour les entités.

Pour l'affichage sur rviz, nous nous sommes servis du type d'objet Map pour visualiser le sol du terrain (en blanc ci-dessous). Nous avons également créé un vecteur de Rectangles pour afficher les murs (en bleu foncé ci-dessous) et un vecteur de Rectangles pour les zones interdites au robot (en noir).

Nous aurions aimé mettre à jour la taille de la grille affichée en fonction de la taille de la carte, mais il s'avère que c'est impossible, la grille ne provenant pas d'un message publié.

• 

  Affichage du terrain de jeu dans Rviz

Semaine 8

Nous avons complété la fonction de gestion de la vitesse. Il n'y a plus de nœud pour gérer les déplacements au profit d'un nœud gérant chaque robot. Les robots envoient un vecteur "twist" pour donner leur commande vitesse, soit deux vecteurs vitesse 3D, l'un pour la vitesse linéaire et l'autre pour la vitesse angulaire. Cependant ce vecteur vitesse est paramétré dans le repère du robot, c'est-à-dire avec le vecteur x dirigé dans la direction de l'orientation du robot. Pour nos calculs nous nous servons du repère originel, que ce soit pour placer les entités ou les déplacer. Cela facilite les calculs dans la simulation. Ainsi nous devons transposer les vecteurs vitesse reçus pour les appliquer à notre repère.

La simulation fonctionnant en 2D nous simplifions les données en utilisant un seul vecteur 3D (x et y pour le déplacement linéaire et z pour le changement d'orientation soit la vitesse angulaire autour de l'axe z). La transposition n'est nécessaire que pour les déplacements linéaires, donc nous utilisons de la trigonométrie simple et nous ajoutons le déplacement ainsi obtenu à la position actuelle, ce qui donne :

v_x = v_x1*cos(orientation_radian) - v_y1*sin(orientation_radian)
 
v_y = v_x1*sin(orientation_radian) + v_y1*sin(orientation_radian)

x_new = v_x *delta_t + x

y_new = v_y *delta_t + y

orientation_new = (v_angulaire*delta_t + orientation) [360]

Nous avons également apporté des modifications aux flèches et textes; en effet, maintenant que le déplacement des robots est possible, nous pouvons effectuer des tests. Il s'avère que nous ne modifions pas la position des flèches et textes, le robot s'éloignait alors d'eux lorsqu'il se déplaçait. Nous avons donc ajouté les quelques modifications nécessaires pour que ces formes suivent l'entité en déplacement.

Nous avons aussi commencé à compléter le package machine pour lui ajouter les sous-classes de Machine représentant les différentes machines (MPS) du jeu (BaseStation, CapStation, RingStation, DeliveryStation). La BaseStation permettra au robot de récupérer un objet de type base, la RingStation d'y empiler des anneaux de couleurs différentes en fonction des commandes reçues, la CapStation de déposer un chapeau au sommet de l'objet et enfin on l'apporte à la DeliveryStation.

Nous avons complété ci-dessous les schémas UML du projet dans son état actuel :

• 

  Schéma UML du package formes

• 

  Schéma UML du package machine

• 

  Schéma UML du package management

• 

  Schéma UML du package robot

Semaine 9

Semaine 10

Fichiers Rendus