Home

General architecture

• Installation
• Main ROS message interactions (dégueulasse oui, j'accepte tout don de schéma venant d'une âme charitable ^^')
• Strategy launch procedure and game ending:

Technical documentation

Arduinos

• asserv : a dedicated arduino in the robot manages the wheels' trajectory and movement; also connected to the odometry system. Connected to ROS with the drivers_ard_asserv wrapper node.
• others : manages all movement requests for servos, PWM devices and motors, and publishes all arduino-connected sensors (e.g. belt sensors, color sensor) directly to a ROS topic using rosserial.
• hmi : used to display a selection interface on a mini-oled screen with selection buttons for selecting the robot strategy and team before the game starts. Also displays the estimated AI score.

ROS Nodes

• feedback
  • webclient : web server that provides an easy way to manually publish on topics or send service/action requests, diagnose topic data and visualize many of the important nodes' elements.
  • rviz : we regularly use RViz, a well-known ROS tool that lets us visualize and debug our system with a real-time or simulated 3D render of the map, robots and virtual elements (collisions zones, waypoints, trajectories...).
  • sensors_simulator : simulates sensor data when the system is executed in simulation mode. Can also provide fake laser scans for processing/particle_filter.
• ai
  • game_status : nœud responsable de donner l'état global du système aux autres noeuds. Diffuse un démarrage ou arrêt global du système suite à des événements dans les noeuds.
  • scheduler : nœud qui décide des ordres à effectuer. Possède un arbre des actions possibles avec des liens de dépendance et prend des décisions dynamiquement en fonction des résultats donnés par les nœuds d'actions.
  • scripts : nœud auxiliaire à ai/scheduler, permettant d'exécuter des enchainements d'actions qui ne seraient pas réalisables avec un simple arbre dans scheduler.
  • timer : nœud publiant le temps écoulé et restant du match. Publie un message d'avertissement à la fin du match pour enclencher un arrêt total.
• memory
  • map : sert de base de données des états et positions de tous les objets présents sur la carte (balles cubes, position des murs et obstacles fixes...), ainsi que les états des contenaires de la carte et du robot (combien de balles dans le réservoir à balles du robot, combien de cubes empilés sur la tour n°3...)
  • definitions : stockage de tous les fichiers de définition de tous les autres nœuds. Le nœud répond aux requêtes de demande de fichiers en donnant la version du fichier pour le bon robot (GR ou PR).
• navigation
  • navigator : nœud qui gère l'exécution d'une trajectoire du robot d'un point A à un point B, en l'adaptant dynamiquement si des collisions ou obstacles sont prévus pendant le mouvement. Commande drivers/ard_asserv pour exécuter la trajectoire.
  • pathfinder : grâce à une carte connue, donne une trajectoire possible d'un point A à B en prenant en compte les obstacles connus lorsque navigation/navigator le demande.
  • collisions : écoute les données de la ceinture, du lidar et d'autres capteurs pour déterminer s'il va y avoir collision entre le robot en mouvement et un obstacle. Notifie navigation/navigator quand il y a collision prévue.
• movement
  • actuators : sert de dispatcher de requêtes d'actions de mouvement (commande de moteurs, servos, glissières... autres que l'asservissement) vers le bon driver connecté au moteur en question à commander.
• recognition
  • localizer : écoute les données de tous les capteurs pour ensuite publier une estimation la plus précise possible de la position du robot.
  • enemy_tracker : écoute les données des capteurs pour identifier les positions des robots, en les trackant au cours du temps.
  • cp_recognizer : utilise la caméra RGB pour reconnaitre le plan de construction (spécifique 2018).
  • cube_finder : utilise les données filtrées de lidar_objects et données brutes pour trouver les positions des cubes (spécifique 2018).
• processing
  • lidar_objects : écoute les points bruts du lidar pour reconnaître et publier une listes de segments et cercles trackés au cours du temps.
  • belt_interpreter : écoute les données brutes de la ceinture et interprete si les distances trouvées visent un mur statique de la map ou un objet inconnu.
• drivers
  • lidar : se connecte au lidar et publie les points bruts.
  • imu : se connecte à la centrale inertielle et publie les données brutes.
  • displacement : se connecte que capteurs de recalage et publie les distances.
  • camera : publie au choix une photo sur demande ou un flux vidéo en continu venant d'une caméra RGB.
  • pico_flexx : se connecte à la caméra ToF et publie le nuage de points 3D brut.
  • ax12 : se connecte aux servos AX12 et éxecute les commandes de mouvement reçues depuis movement/actuators.
  • ard_asserv : se connecte à l'arduino gérant l'asservissement et envoie les requêtes d'action de navigation/navigator. Retourne le statut de l'asserv et les données d'odométrie.
  • ard_others : se connecte à l'arduino gérant les moteurs et servomoteurs et envoie les requêtes d'action de movement/actuators. Retourne les données des capteurs branchés à l'arduino (e.g. ceinture).
  • ard_hmi : se connecte à l'arduino gérant l'écran de sélection de stratégie/couleur d'équipe et remonte les informations sélectionnées à ai/scheduler.
• external nodes (existing packages around the internet used in our system)
  • obstacle_detector : listens to the lidar scands published by urg_node and simplifies the scan points to segments and circles. The circles are tracked in time and thus published with an instantaneous speed.