Skip to content

Home

Jump to bottom
Clément de La Bourdonnaye edited this page Jul 30, 2019 · 5 revisions

Ceci est le wiki du code haut niveau du gros robot de l'association de robotique de l'UTT en 2019. Vous trouverez ici différentes ressources pour mieux comprendre et utiliser le code de ce dépôt.

Introduction

Le comportement du gros robot est développé à l'aide de ROS (Robot Operating System), son code est donc séparé en différents programmes ou packages qui gèrent chacun une partie du fonctionnement du robot.

Chaque package est développé en C++ ou en python, mais d'autres langages peuvent être utilisés si besoin (voir http://wiki.ros.org/Client%20Libraries).

Structure

Le code est structuré ainsi dans le dossier src/:

  • ai : dossier contenant les packages gérant le fonctionnement haut niveau du robot (gestion de l'automatisme)
    • scheduler : c'est lui qui est en charge de lire les fichiers d'action et de gérer l'ordre d’exécution des action, il est démarré et mis en pause par le controller
    • controller : en charge d'initialiser le robot et de lancer le scheduler
    • node_watcher : au coeur du fonctionnement du robot, ce package se charge d'enregistrer les états des autres nœuds et fournit les librairies nécessaires en python et C++ pour s'enregistrer ou récupérer les états des nœuds facilement
    • action_manager : il s'agit d'une librairie contenant les classes d'actions ainsi que celles permettant de créer facilement un exécuteur d'action
    • pathfinder : gestion du pathfinding volé à l'UTC (avec leur consentement) et adapté pour ce projet, l'algorithme utilisé n'est pas optimal (flooding) mais permet de chercher un chemin au plus court ou de vérifier qu'il n'en existe pas
  • interface : dossier content les packages utiles à la communication entre le haut niveau (packages du dossier ai) et les différentes entrées/sorties possible (can, simulation, gpios...)
    • can_interface : package faisant le lien entre les messages de l'interface et les _frames _envoyées via la librairie CAN, chaque type de _frame _peut être décrit dans le package interface_description
    • serial_interface : package similaire à can_interface, excepté qu'il communique en série. Permet éventuellement d'étendre la connexion lors de connectivité difficile d'un composant avec le bus CAN.
    • gpio_handler : package gérant la communication par GPIO de la carte BeagleBoneBlack, il s'occupe principalement d'allumer des leds et de récupérer le signal de départ ainsi que le coté duquel le robot commence
    • interface_description : package externe (https://github.com/RobotikUTT/Info-2019_Interface qui contient les différentes trames envoyées entre chaque élément sur le bus CAN (beagle bone, arduinos, stm...)
  • procedures : dossier contenant toutes les actions atomiques du robot qui ne peuvent pas être générées autrement, chaque package contient un exécuteur d'action (ActionPerformer) qui gère l'action
    • idle : mise en pause du robot
    • reach : déplacement du robot vers un point, un angle, ou les deux d'un coup
  • simulation : en cours d'élaboration, ce dossier est destiné à simuler les entrées/sorties du robot lors d'une éxecution sur une autre machine par exemple
  • lib : contient quelques utilitaires utilisés par tout le programme (voir page sur les libs)

On trouve également dans les dossier ai et interface des packages *_description ou *_msgs, qui contiennent respectivement des fichiers de données utiles au package (définition de la carte ou des frames CAN par exemple) et les messages utilisés lors de la communication dans ce package (les messages d'interface sont par exemple utilisés par les packages d'ai pour communiquer et recevoir depuis l'extérieur).

Processus de fonctionnement

Le fonctionnement haut niveau du robot s'effectue à l'aide des étapes suivantes :

  1. Les différents packages utilisés sont lancé par le fichier .launch adapté (robot, ou simulation)
  2. Les différents packages s'enregistrent auprès du node_watcher :
    • Les actions s'enregistrent généralement directement sans attendre d'autres services
    • Le scheduler charge les fichiers d'action en un arbre d'actions et extrait la liste d'actions atomiques nécessaires, il attend auprès du node_watcher que ces actions s'enregistrent avant de s'enregistrer lui même comme prêt
    • Le controller attend que le scheduler soit prêt et que le signal de départ soit donné, une fois ces deux conditions réunies, il indique au scheduler de démarrer les actions
  3. Le scheduler lance l'action atomique dans l'arbre des actions qui n'est pas terminée ni en pause et rapporte le plus de point pour le minimum de distance
    • Si l'action est réussie, on passe à la suivante (étape 3)
    • Sinon (arrêt par le controller ou pause déterminée par l'exécuteur, l'action est mise en pause et on passe à la suivante (on recommence l'étape 3)
  4. Une fois toutes les actions en attente en pause ou en terminées
    • Si certaines actions sont en pause, on les remet en attente, et on revient à l'étape 3
    • Sinon le fonctionnement du robot est achevé
Clone this wiki locally