robotique-ecam / cdfr Goto Github PK

Rendre possible la sélection de coté du robot

• Design / ROS 2 concepts to be used
• Implementation
  • Strategy (Strategix & Cetautomatix) 698b7b4
  • Assurancetourix & Vision
  • Navigation
  • Titan & Hyperion
• Testing

Il est possible de définir un callback sur une rclcpp::Node/rclpy.node.Node lors de la reception d'un rcp_interface::msg::ParameterEvent, émis lors d'un événement sur un/plusieurs paramètre de la node. Voir exemple

Features Hyperion, à contribuer

• Calcul du score de notre équipe
• Verification en mode [OK] / [WARN] / [FAIL] pour plusieurs critères :
  • Robots hyperstatique
  • status de Asterix / Obelix / Assurancetourix / Pharaon
  • Colisions
  • Actions executées avec succès / rejetées
  • ...

Sera intégré dans les tests automatiques

By using canTransform(...) i was hoping for something like a "wait for transform" behavior.

It did the trick, but while checking for the transform it spams a lot of warning messages like Warning: Invalid frame ID "odom" passed to canTransform argument target_frame - frame does not exist in the log.

I haven't found anything that will simply prevent this warning from appearing. So in order to avoid this garbage to appear, i decided to disable the log of drive node.

As discussed with @3wnbr1 in #31, this move is too rough, we need to work around to achieve a smoother solution and keep the log of drive.

@3wnbr1 comes with:

See example below to catch exceptions
https://github.com/ros2/geometry2/blob/ros2/tf2_ros/src/tf2_echo.cpp

When compiling with colcon build --cmake-args " -DSIMULATION=ON -DTIMER=ON", odometer doesn't update in realtime

This causes all NavigateToPose actions to be treated as SUCCESS and therefore, failed goals are never dropped by the robot

Could be nice to create a function is_simulation or even is_this_reality dans un package et l'utiliser partout pour detecter la simu. ARM64 will become more common in the future and this limits code duplication

Originally posted by @3wnbr1 in #31 (comment)

According to this article and by looking at what's going on in lifecycle_manager, at startup of titan node, map_server stays in an unconfigured state when bringing up the nav.

There is two map_server, one in the asterix namespace and another one in obelix.

Some cool tools might be useful to transition map_server to its active state in nav2_util package especially this function in lifecycle_utils.

#39 reverted a mitigation against this race condition

The ideal design would be prevent cetautomatix initialization completion as long as an odom message hasn't been received. We can't block the constructor's completion as this would result onto the odom callback handler not being called. We could instead use a boolean semaphore within the node to let know each subroutine if the node is ready and early return if it is not / report as not not ready yet.

Short term mitigation was to position with dummy values but this is impractical and can cause side effects.

Each package needs to be documented on the WIKI (Github Menubar).
Edit the ROS markdown and add a description of your package and how to use it.

DOC en Français les amis 😉

• Global ROS introduction & packages groups
• Assurancetourix @PhileasL
• Actuators @3wnbr1
• Sensors @HL-Boisvert
• Asterix @3wnbr1
• Cetautomatix @mAxYoLo01
• Drive @3wnbr1
• Map @Kazzor
• Obelix @3wnbr1
• Panoramix @jljonnard
• Pharaon @HL-Boisvert
• LCD Driver @3wnbr1
• Simulation @3wnbr1 @PhileasL @mAxYoLo01
• Strategix @mAxYoLo01
• Titan @3wnbr1
• URDF / Xacro @Kazzor

Les custom_behaviors de cetautomatix utilisent time.time() au lieu de robot.get_clock().now(). Du fait de la simulation, cetautomatix tourne en temps réel au lieu du temps simu ce qui donne des durées de matchs fausses. Il faudrait remplacer tout les time.* par get_clock().now() dans tout les packages.

https://github.com/3wnbr1/ros/blob/c09eb49dd8c0b6c708654f04679a4b6d887ee27c/src/modules/cetautomatix/cetautomatix/custom_behaviours.py#L61

Le contrôleur DWB présent dans la navigation de base ne réponds pas aux exigences de performance.

• Sur Raspberry Pi (4B), le contrôleur n'est pas capable de gérer des fréquences supérieures à 20Hz. Le pas d'integration n'est alors pas suffisant pour l'odomètrie ce qui augmente l'erreur. Le nouveau contrôleur devra tourner à 200Hz minimum.
• Le contrôleur DWB est trop complexe pour notre cas d'usage (toutefois, il reste inégalé pour le SLAM (Simultaneous Localization And Mapping)). L'erreur maximale de position tolérable par robot est fixée à 1 cm, l'erreur minimale du contrôleur DWB est 25 cm, il n'est de plus pas adapté aux robots non-holonomiques, ne favorisant pas les rotations sur lui même.
• Le planneur global (Pathfinder) ne répond pas non plus aux exigences de précision en finissant sur l'objectif en spirale. De plus, il ne tire pas pleinement parti du nav_msgs::msg::Path qui n'est pas une liste de geometry_msgs::msg::Point mais de geometry_msgs::msg::Pose contenant également une orientation interpretable par le contrôleur.
• Cependant du fait de l'architecture de ROS navigation2, ces composants existent sous forme de plugins et sont de ce fait remplaçables par d'autres plus adaptés

Il est donc entreprit de développer 2 plugins de navigation

• Le Planner à partir de nav2_core::GlobalPlanner et sur base de https://navigation.ros.org/tutorials/docs/writing_new_nav2planner_plugin.html
  Le planneur pourra combiner déplacements linéaires, rotations et courbes de bezier en fonction de la situation. Un planeur plus complexe tel que contenus dans OMPL n'est pas nécessaire pour l'instant mais pourrais à fortiori remplacer les courbes de bezier sur la trajectoire intermédiaire

• Le contrôleur à partir de DWB et TEB qui sont les 2 seuls contrôleurs supporté par navigation2.
  Design en cours...

See this run