RoboCup 2015

Polytech RoboCup Team

Cahier des charges

Présentation générale du projet

Lors de la compétition de l'Open German, prélude de la Robocup, il faudra mettre en place un système d'autonomisation de production à l'aide de Robotinos (robots mobiles de Festo ayant un système d'exploitation Linux). Comme dans toutes compétitions, le but est de gagner, par conséquent, il faudra faire en sorte de gagner un maximum de points. C'est pourquoi il faut créer un manager à l'aide de ROS, c'est-à-dire un nœud ou ensemble de nœuds permettant de pouvoir recevoir les informations envoyées par les autres nœuds, de les traiter, tout cela afin de donner les ordres que doivent exécuter chaque Robotino. Ce manager devra également être capable d'optimiser le nombre de points à obtenir.

Contexte

La compétition de l'Open German se déroule en quatre phases spécifiques : phase de début-de-jeu, phase d'exploration, phase de production, phase de fin-de-jeu. Le manager aura des tâches spécifiques à remplir suivant les différentes phases. La RefereeBox est un système d'arbitrage auquel il est nécessaire d'envoyer périodiquement des données à tout moment du jeu et qui donne à chaque instant l'état du jeu ainsi que les produits demandés en priorité durant la phase de production.

Objectif du projet

• Assurer un maximum de points suivant les aléas du jeu (panne de machine, produits demandées, rupture de stock d'une matière première, …)
• Assurer la pérennité du projet (chaque année des candidats de Polytech Lille y participent)

Description du projet

Pour le projet, outre le fait de gagner le plus de points possibles, il faudra valider les trois contraintes suivantes :

• Communication avec le nœud de la RefereeBox à tout moment du jeu
• Contrainte de robustesse (il ne faut qu'à un moment ou à un autre il n'y ait un blocage de tous les robots)
• Coopération entre les trois robots

Interactions des nœuds avec le manager

Le manager devra interagir avec les différents nœuds suivants ayant chacun leurs rôles spécifiques :

• RefereeBox Comm : recevoir les données envoyées par la RefereeBox et envoyer des données suivant l'état du jeu à la RefereeBox
• Robots Comm : communiquer aux autres robots les informations concernant ce que chacun font
• Traitement des TAGs : lire les TAG
• Traitement des feux : lire l'état des colonnes de feu
• Pince de préhension : ouvrir et fermer la pince et renvoyer l'état de la pince
• Approche finale : s'adapter au banc de charge ou de décharge de produits
• Génération trajectoire : détermine une trajectoire pour aller au lieu (X,Y)
• Réalisation trajectoire : parcourir la trajectoire
• Localisation : savoir périodiquement (faible période) où se situe le robot
• Détection d'obstacle : détecter les obstacles fixes et mobiles

Choix techniques : matériel et logiciel

• Utilisation de trois robotinos
• Utilisation de ROS (Robot Operating System), c'est un ensemble d'outils informatiques open source permettant de développer des logiciels pour la robotique. Il est disponible sous environnement Linux en version stable. Ce système travaille en utilisant des nœuds qui communiquent entre eux à l'aide de services (requête-réponse) et de topics (fichiers).
• Utilisation de différents langages : C++ ou Python (nœuds)
• Travail sous Linux Ubuntu 12.04 car utilisation de la version HYDRO de ROS

Etapes du projet

• Prise en main de ROS et du C++
• Élaboration de l'algorithme du manager pour la phase d'exploration
• Élaboration de l'algorithme du manager pour la phase de production
  • Coopération entre robots
  • Répartition des tâches
• Codage du manager
• Tests et corrections

Avancement du Projet

Semaine 1

• Prise en main de ROS
• Réalisation des tutoriels ROS disponibles au lien http://wiki.ros.org/fr/ROS/Tutorials
• Réalisation de différents tutoriels C++
• Connaissance plus aiguë du sujet de l'Open German 2015

Semaine 2

• Réflexions autour de la structure du manager : deux nœuds
  • Un nœud exécuteur de tâches
  • Un nœud générateur de tâches
• Réflexions sur l'algorithme général du manager concernant la phase d'exploration
  • Fonctionnement par zoning pour la répartition des tâches des trois robots
  • Réflexion autour d'une alternative de répartition par distances les plus courtes entre machines
• Recherche de solutions pour la phase de production
  • Documentation autour de la planification de tâches et la génération de tâche pour une équipe
  • Recherche autour de la coopération et de l'allocation de rôles à des robots multi-tâches
• Organisation générale
  • Structuration d'un échéancier numérique sous Asana
  • Demande d'autorisation pour l'ouverture de la salle C002 auprès de M. Scrive

Semaine 3

Voilà un lien permettant d'accéder au sujet provisoire de la Robocup 2015 : Sujet

• Réflexions au sujet des infos à communiquer au nœud AutresRobotsComm :
  • Ce que le robotino fait
  • Quelle machine le robotino est en train d'utiliser

• Réflexions au niveau de l'algorithme de la phase de production
  • Proposition de le faire sous le principe de "Diviser pour mieux régner" (validé par M. Vincent Coelen)
    • Diviser la tâche principale en sous-tâches, les sous-tâches en sous-sous-tâches et les sous-sous-tâches en sous-sous-sous-tâches élémentaires.
  • Détermination des tâches à réaliser pour un exemple particulier

On souhaite produire, pendant une durée déterminée par la refBox, le produit suivant :

Le produit est composé d’une base bleue, d’un ring rouge, d’un ring vert et d’un cap noir.

Obtenir Base Bleue

->Aller à la Base Station
  générateur trajectoire
  exécuteur trajectoire
->Vérifier si machine OK
  approche finale
  traitement feux
->Prendre produit
  RefBoxComm (dire à la Base Station quelle base est souhaitée et à quelle banc le robotino est) 
  approche finale 
  pince (prendre)

Obtenir ring rouge

->Aller à une Ring Station
  Laquelle ? laquelle est inoccupée ? la plus proche ? (RobotsComm)
  générateur de trajectoire
  exécuteur de trajectoire
->Vérifier si machine OK
  approche finale
  traitement feux
->Prendre produit 
  RefBoxComm (pour dire quel produit et quel banc de livraison)
  approche finale
  pince (déposer)
  pince (prendre)

Obtenir ring vert

->Aller à une Ring Station
   Laquelle ? laquelle est inoccupée ? la plus proche ? (RobotsComm)
   (Du coup la plus proche sera celle où on vient de faire le ring précédent)
   générateur de trajectoire
   exécuteur de trajectoire
->Vérifier si machine OK
   dire à la Ring Station quelle base est souhaitée ( ici, la verte )
   approche finale
   traitement feux
->Prendre produit 
   RefBoxComm (pour dire quel produit et quel banc de livraison)
   approche finale
   pince (déposer)
   pince (prendre)

Finaliser produit

->Aller à une Cap Station
   Laquelle ? laquelle est inoccupée ? la plus proche ? (RobotsComm)
   générateur de trajectoire
   exécuteur de trajectoire
->Vérifier si machine OK
   dire à la Cap Station quelle cap est souhaité ( ici, le noir )
   approche finale
   traitement feux
->Prendre produit 
   RefBoxComm (pour dire quel banc de livraison)
   approche finale
   pince (prendre)
->Déposer à la Delivery Station
   générateur de trajectoire (vers la Delivery Station)
   exécuteur de trajectoire
   approche finale
   pince (déposer)

• Organisation générale :
  • Création de la page Facebook de l'équipe PYRO Team

Semaine 4

• Écriture des sous-tâches à réaliser
  • Pseudo-codes de certaines sous-tâches réalisées
• Recherche d'ordonnancement optimisé pour la fabrication du produit
  • Recherche d'algorithmes
  • Visualisation du problème d'ordonnancement concernant l'exemple précédent (base bleue, ring vert, ring rouge, cap noir)

Ici, on a pris en plus en hypothèse le fait que la Ring Station (RS1) est capable de mettre des rings rouges ou verts et que la RS2 est capable de de mettre des rings bleus et rouges. Afin de mieux appréhender le problème, nous nous sommes attachés à effectuer un tableau récapitulant les tâches à effectuer pour le produit exemple et à réaliser un graphe mettant en avant les contraintes de précédence de chaque tâche.

	Tâches	Ressources utilisées	Contraintes de précédence
T0	Ramener à CS base avec cap	Robot 1, 2 ou 3	Aucune
T1	Décapsuler	Cap Station 1 ou 2	T0
T2	Ramener base supplémentaires à RS	Robot 1, 2 ou 3	Aucune
T3	Chercher base bleue	Robot 1, 2 ou 3	Aucune
T4	Ramener à RS pour ring vert	Robot 1, 2 ou 3	T7
T5	Ramener à RS pour ring rouge	Robot 1, 2 ou 3	T8
T6	Ramener à CS pour cap	Robot 1, 2 ou 3	T9
T7	Ramener Base	Base Station	T3
T8	Ajouter ring vert	Ring Station 1	T4
T9	Ajouter ring rouge	Ring Station 1 ou 2	T5 et T2
T10	Ajouter cap	Cap Station 1 ou 2	T6 et T1
T11	Traiter le produit fini	Delivery Station	T12
T12	Ramener à DS	Robot 1, 2 ou 3	T10

Graphe montrant l'ordre des tâches à réaliser

Semaine 5

Durant cette semaine, nous avons réfléchi sur le choix de structures pour nos données :

• Une liste principale de tous les produits demandés par la RefBox à un instant t. Cette liste principale a les caractéristiques suivantes :
  • Une Priorité sera calculée pour chaque produit avec les paramètres suivants :
    • Nombre de points que peut apporter la production d'un produit de A à Z.
    • Une estimation du temps de production d'un produit.
    • La date limite de livraison du produit demandé
  • Une tâche est élue si sa priorité est supérieure ou égale à celle des autres tâches.
  • Quand la RefBox demande un produit, une cellule sera ajoutée dans cette liste. Et de même, quand un produit sera terminé, on le supprimera de cette liste.
• Chaque produit de la liste principale va contenir une liste de tâches correspondantes à la production de ce produit. Cette liste de tâches a les caractéristiques suivantes :
  • Chaque cellule correspond à une tâche de la production d'un produit. Une tâche contient différents champs :
    • Intitulé de la tâche (par exemple ajouter une base)
    • Produit concernée (par exemple P3)
    • Priorité de la tâche (par exemple 20)
    • Temps restant estimé de production (par exemple 180s)
  • A chaque fois qu'une tâche est réalisée, elle sera supprimée de la liste de tâches. Ce qui veut dire, qu'on va devoir calculé à nouveau la priorité de chaque tâche de la liste principale.
  • Afin de respecter les contraintes de précédence, on considérera que la tâche en tête de la liste de tâches peut être élue. Par exemple, on ne peut pas ajouter un Ring si on n'a pas de base.

L'exemple suivant simule le cas où la RefBox a demandé deux fois le produit P3 et deux fois le produit P2.

• Le produit P3 est réalisable en cinq tâches.Ce produit mettra plus de temps à être fabriqué mais rapportera plus de points.
• Le produit P2 est réalisable en quatre tâches.

Structure utilisée pour ranger les tâches à réaliser

Différentes remarques utiles :

• Avant de commencer à réaliser n'importe quel produit, il faudra au préalable vérifier si on a libérer un espace de stockage pour plusieurs raisons :
  • Les Cap Stations ayant initialement aucun cap en stock, il faut les ramener de l'étagère qui en contient initialement car un produit est dit fini lorsqu'il a à son sommet un cap.
  • L'étagère ayant été débarrassée d'un cap, cela permet d'avoir un espace de stockage afin de déposer des produits finis en attente de livraison ou des produits non finis dont on voudrait mettre en pause la production.
• Il sera peut être des fois plus avantageux d'abandonner temporairement la production d'un produit :
  • Il vaut mieux faire en sorte de terminer un seul produit sur deux dans les temps plutôt qu'aucun car du fait de la parallélisation de la fabrication des produits, on peut être surchargé de travail.
  • Un produit livré durant le laps de temps demandé rapportera plus de points non négligeables.
• Un tableau sera nécessaire afin de savoir ce qu'il y a les espaces de stockage avec les champs suivants :
  • Type de produit
  • Liste de tâches restantes pour la fabrication du produit (pour un produit fini cette liste est donc nulle)
  • Date de début de livraison
  • Date de fin de livraison
  • Emplacement de l'espace de stockage

Semaine 6

• Différentes fonctions et actions en pseudo code pour le générateur de tâches
  • Fonction qui retourne un booléen suivant si un produit est en stock ou non
  • Fonction qui retourne un booléen suivant si on doit livrer le produit à présent ou non
  • Fonction qui retourne un booléen suivant si on a déjà ou non mis le travail à faire dans la structure contenant les tâches à réaliser
  • Fonction qui retourne le nombre de points que rapporte un produit passé en paramètre
  • Action qui rajoute les nouveaux ordres de production dans la liste de listes de tâches
  • Action qui calcule le ratio pour chaque tâche
  • Action qui supprime les tâches vides (ie celles qui sont terminées)
• Début de l'écriture en pseudo code de la fonction principale

• Discussion avec M. Vincent Coelen concernant l'avancement du projet :
  • Validation par M. Coelen Vincent des portions de pseudo code déjà écrites
  • Discussion autour de la mise en place d'un arrêt immédiat des robots à tout moment du jeu
  • Amélioration concernant la robustesse de l'algorithme si un robot n'est plus en état de fonctionnement

• Différentes remarques utiles :
  • Branche concernant le manager créée sur le git de l'équipe
  • Discussion avec d'autres membres de l'équipe sur les services et les topics à envoyer et à recevoir aux nœuds du manager

Semaine 7

Générateur de tâches

Début du codage C++ :

• Création de différentes classes :
  • La classe Tache (tache.h et tache.cpp)
  • La classe Stockage (stockage.h et stockage.cpp)
  • La classe RefBoxComm (refboxcomm.h)
• Création de différentes fonctions :
  • Dans tache.h et tache.cpp :
    • point_par_produit : retourne le nombre de points que vaut un produit
    • dans_les_temps : retourne un booléen indiquant s'il est temps de ramener le produit
  • Dans listetaches.h et listetaches.cpp :
    • creation_liste_taches_prod : retourne une liste de taches à partir d'un produit passé en paramètre
    • creation_liste_taches_act  : retourne une liste de taches à partir d'un produit et d'une action passés en paramètres
  • Dans tableaustockage.h :
    • produit_en_stock : retourne un booléen indiquant si au moins un produit est en stock
  • Dans travail.h et travail.cpp :
    • deja_dans_travail : retourne un booléen indiquant si un ordre de la RefBox a déjà été pris en compte dans la structure contenant les tâches à réaliser
    • max_ratio : retourne l'objet Tache qui a le plus grand ratio dans la structure contenant les tâches à réaliser
    • rajout_dans_travail : rajoute un nouvel ordre de la RefBox dans la structure contenant les tâches à réaliser

Les codes sont disponibles sur le git
Des tests ont été réalisés afin de valider les fonctions crées en particulier les fonctions contenues dans travail.h et travail.cpp
Voici un petit aperçu de la console :

Ainsi, les trois fonctions fonctionnent parfaitement :

• deja_dans_travail et max_ratio retournent bien ce qui est attendu
• rajout_dans_travail rajoute en fin de liste la liste de tâches pour la première création d'un produit P0 car un cap est disponible , puis il concatène une liste contenant en tête la tâche "Decapsuler" avec la liste de tâches pour la seconde création d'un produit P0. En effet, la RefBox a demandé deux fois le produit P0 et on ne peut créer un produit tant qu'un cap n'est pas disponible.