Home

Welcome to coupe18's wiki! Here you'll find all the documentation you need to understand how the current system works. If you start developing things and contributing to the project, don't forget to update and/or add to this wiki.

You'll first find general articles on how the system is organized. Below are also a summary of all the wiki pages related to all the system's nodes. Happy reading! 📚

NOTE: The 2018 edition ended ! See notable conclusions and a comprehensive list of what needs to be improved on the Conclusions page. Solutions will appear in this repo's GitHub Projects tab.

General architecture

Here are some general articles that will introduce you to the system: what's the main philosophy that drives its architecture, how the nodes are organized, etc. Here is your homework, which is best to read with the set order:

1. Installation troubleshooting : the general installation process is explained in the README file located in the project's root folder. If you encounter problems, see this section to solve them.
2. General architecture and philosophy : how the system adapts to the different robots, namespaces organization, nodes launch conventions...
3. Nodes interactions : main explanation with a map of all the system nodes, with explanations on who talks to who.
4. Startup process and game ending : how the system starts all the nodes, how everything goes from initialized to in game internally and how the system stops after 100 seconds in game.

Technical documentation

Note: wanna create a new wiki page for a node or system component ? Please follow the Wiki Guidelines when doing so!

Note 2: external nodes (existing packages around the internet used in our system) are marked in italics.

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 Wiki duidelineswrapper 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

2019 Edition Refactoring:

• feedback
  • webclient : web app 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 : node that stores the main system statuses. Can be contacted by a node to start the game or halt the entire system (timer ended, critical failure).
  • scheduler : this is the robot's AI. Selects which actions to perform, and adapts the next ones in case of problems or errors (enemy blocking the navigation path, node not responding, servo blocked...) by exploing a possibilities tree defined by the user.
  • timer : node that keeps track of how much time is left during the game. Publishes a HALT message ai ai/game_status to stop all node actions.
• memory
  • map : a database manager that holds all map walls, elements, waypoints, objects and robot characteristics. Also holds the main robot's containers' state (how many balls in the robot's main container, how many cubes in the tower #3...). Can generate occupancy images with the walls and dangerous objects (used in navigation/pathfinder).
  • definitions : node that holds all public definition files of all the nodes in the system. Replies to file retrieval requests with the path to the right file version according to which robot the system is on (GR or PR in our case).
• navigation
  • navigator : Node that manages a robot trajectory from point A to B. Dynamically adapts to events (enemy blocking the way, imminent collision...) and automatically tries different routes to the destination before giving up.
  • pathfinder : takes the map bmp file generated by memory/map containing the walls and dangerous objects positions and replies to navigation/navigator's requests with a valid navigation path that avoids all map and dynamic obstacles.
  • collisions : listens to all sensors data and gets the current robot's speed and path to predict a collision with any dangerous obstacle while navigating. Notifies navigation/navigator when a collision is seen.
• movement
  • actuators : serves as an action dispatcher for servos, motors, AX12s and all other actuators to the right driver that handles the specified actuator's movement.
• recognition
  • objects_classifier : collects all sensor measurements and gives a label to them based on their location; outside of the map, inside static walls or inside the map.
  • localizer : listens to all pose estimations coming from the sensors and estimation nodes and applies a Kalmann Filter to estimate the real robot's position. Publishes the main robot's tf frame.
  • enemy_tracker : listens to sensor data to recognize the enemies' positions. Useful to memory/map which invalidates certain actions scheduler actions if an enemy already used map objects.
  • cp_recognizer : uses the RBG camera to recognize the construction plan (1028 specific).
  • cube_finder : uses the lidar information fo find and estimate the cubes' positions and states arouns the table (2018 specific).
• processing
  • lidar_objects (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.
  • belt_interpreter : listens to the raw belt sensors data and publishes ROS tf frames and associated rectangles (representing the measured value and uncertainty tolerances).
• drivers
  • camera : connects to a RGB camera and publishes the raw feed.
  • ax12 : connects to the AX12 Dynamixel SDK framework and acts as a wrapper with an action server and dynamic parameter configurator.
  • ard_asserv : connects to the asserv arduino and acts as a wrapper to the home-made protocol through ROS. Lets navigation/navigator request goto, gotoa and other types of actions. Also reports the odometry estimates to ROS.
  • ard_others : empty package that simply holds the message definitions used by rosserial in arduino/others.
  • ard_hmi : empty package that simply holds the message definitions used by rosserial in arduino/hmi.
  • pico_flexx : acts as a wrapper to the Pico Flexx 3D camera SDK framework.
  • urg_node : Hokuyo LiDAR driver. Connects to the Hokuyo (automatically finds the port) and published the raw scans on topic /scan.