À propos des paramètres dans ROS 2
Table des matières
Aperçu
Les paramètres dans ROS sont associés à des nœuds individuels. Les paramètres sont utilisés pour configurer les nœuds au démarrage (et pendant l’exécution), sans changer le code. La durée de vie d’un paramètre est liée à la durée de vie du nœud (bien que le nœud puisse implémenter une sorte de persistance pour recharger les valeurs après le redémarrage).
Les paramètres sont adressés par nom de nœud, espace de noms de nœud, nom de paramètre et espace de noms de paramètre. La fourniture d’un espace de noms de paramètre est facultative.
Chaque paramètre se compose d’une clé, d’une valeur et d’un descripteur. La clé est une chaîne et la valeur est l’un des types suivants : bool, int64, float64, string, byte[], bool[], int64[], float64[] ou string[]. Par défaut, tous les descripteurs sont vides, mais peuvent contenir des descriptions de paramètres, des plages de valeurs, des informations de type et des contraintes supplémentaires.
Pour un tutoriel pratique avec les paramètres ROS, voir Comprendre les paramètres.
Contexte des paramètres
Déclaration des paramètres
Par défaut, un nœud doit déclarer tous les paramètres qu’il acceptera pendant sa durée de vie. Ainsi, le type et le nom du paramètre sont bien définis au démarrage du nœud, ce qui réduit les risques de mauvaise configuration par la suite. Voir Utiliser des paramètres dans une classe (C++) ou ../Tutorials/Beginner-Client-Libraries/Using-Parameters-In- A-Class-Python pour des tutoriels sur la déclaration et l’utilisation des paramètres d’un nœud.
Pour certains types de nœuds, tous les paramètres ne seront pas connus à l’avance. Dans ces cas, le nœud peut être instancié avec allow_undeclared_parameters défini sur true, ce qui permettra d’obtenir et de définir des paramètres sur le nœud même s’ils n’ont pas été déclarés.
Types de paramètres
Chaque paramètre d’un nœud ROS 2 possède l’un des types de paramètres prédéfinis, comme mentionné dans la Présentation. Par défaut, les tentatives de modification du type d’un paramètre déclaré lors de l’exécution échoueront. Cela évite les erreurs courantes, telles que l’insertion d’une valeur booléenne dans un paramètre entier.
Si un paramètre doit être de plusieurs types différents et que le code utilisant le paramètre peut le gérer, ce comportement par défaut peut être modifié. Lorsque le paramètre est déclaré, il doit être déclaré en utilisant un ParameterDescriptor avec la variable membre dynamic_typing définie sur true.
Rappels de paramètres
Un nœud ROS 2 peut enregistrer deux types de rappels différents pour être informé lorsque des modifications sont apportées aux paramètres. La raison pour laquelle il existe deux types de rappels est d’avoir une chance d’intervenir avant que le changement de paramètre ne se produise et d’avoir une chance de réagir après que le changement de paramètre se soit produit. Un nœud peut s’enregistrer pour les deux, l’un ou l’autre des types de rappel. Les deux types sont décrits ci-dessous.
Le premier type est connu sous le nom de callback « set parameters » et peut être installé en appelant add_on_set_parameters_callback. Le rappel doit accepter une liste d’objets Parameter et renvoyer un rcl_interfaces/msg/SetParametersResult. Ce rappel sera appelé avant qu’un paramètre ne soit déclaré ou modifié sur un nœud. L’objectif principal de ce rappel est de donner à l’utilisateur la possibilité d’inspecter la modification à venir du paramètre et de rejeter explicitement la modification.
Note
Il est important que les rappels « set parameters » n’aient pas d’effets secondaires. Étant donné que plusieurs rappels « set parameters » peuvent être chaînés, il n’y a aucun moyen pour un rappel individuel de savoir si un rappel ultérieur rejettera la mise à jour. Si le rappel individuel devait apporter des modifications à la classe dans laquelle il se trouve, par exemple, il peut se désynchroniser avec le paramètre réel. Pour obtenir un rappel * après * qu’un paramètre a été modifié avec succès, voir le type de rappel suivant ci-dessous.
Le deuxième type de rappel est connu sous le nom de rappel « événement sur paramètre » et peut être installé en appelant on_parameter_event. Le rappel doit accepter un objet rcl_interfaces/msg/ParameterEvent et ne rien renvoyer. Ce rappel sera appelé après que tous les paramètres auront été déclarés, modifiés ou supprimés. L’objectif principal de ce rappel est de donner à l’utilisateur la possibilité de réagir aux modifications des paramètres qui ont été acceptés avec succès.
Interagir avec les paramètres
Les nœuds ROS 2 peuvent effectuer des opérations sur les paramètres via les API de nœud comme décrit dans Utiliser des paramètres dans une classe (C++) ou ../Tutorials/ Beginner-Client-Libraries/Using-Parameters-In-A-Class-Python. Les processus externes peuvent effectuer des opérations sur les paramètres via des services de paramètres qui sont créés par défaut lorsqu’un nœud est instancié. Les services créés par défaut sont :
/node_name/describe_parameters : utilise un type de service de
rcl_interfaces/srv/DescribeParameters. À partir d’une liste de noms de paramètres, renvoie une liste de descripteurs associés aux paramètres./node_name/get_parameter_types : utilise un type de service de
rcl_interfaces/srv/GetParameterTypes. À partir d’une liste de noms de paramètres, renvoie une liste de types de paramètres associés aux paramètres./node_name/get_parameters : utilise un type de service de
rcl_interfaces/srv/GetParameters. À partir d’une liste de noms de paramètres, renvoie une liste de valeurs de paramètres associées aux paramètres./node_name/list_parameters : utilise un type de service de
rcl_interfaces/srv/ListParameters. Étant donné une liste facultative de préfixes de paramètres, renvoie une liste des paramètres disponibles avec ce préfixe. Si les préfixes sont vides, renvoie tous les paramètres./node_name/set_parameters : utilise un type de service de
rcl_interfaces/srv/SetParameters. À partir d’une liste de noms et de valeurs de paramètres, tente de définir les paramètres sur le nœud. Renvoie une liste des résultats de la tentative de définition de chaque paramètre ; certains d’entre eux ont peut-être réussi et d’autres ont échoué./node_name/set_parameters_atomically : utilise un type de service de
rcl_interfaces/srv/SetParametersAtomically. À partir d’une liste de noms et de valeurs de paramètres, tente de définir les paramètres sur le nœud. Renvoie un seul résultat en essayant de définir tous les paramètres, donc si l’un échoue, tous échouent.
Définition des valeurs initiales des paramètres lors de l’exécution d’un nœud
Les valeurs initiales des paramètres peuvent être définies lors de l’exécution du nœud via des arguments de ligne de commande individuels ou via des fichiers YAML. Voir Réglage des paramètres directement depuis la ligne de commande pour des exemples sur la façon de définir les valeurs initiales des paramètres.
Définition des valeurs initiales des paramètres lors du lancement des nœuds
Les valeurs initiales des paramètres peuvent également être définies lors de l’exécution du nœud via la fonction de lancement ROS 2. Voir ce document pour plus d’informations sur la façon de spécifier les paramètres via le lancement.
Manipulation des valeurs de paramètres lors de l’exécution
La commande ros2 param est le moyen général d’interagir avec les paramètres des nœuds déjà en cours d’exécution. ros2 param utilise l’API de service de paramètres comme décrit ci-dessus pour effectuer les différentes opérations. Voir the how-to guide pour plus de détails sur l’utilisation de ros2 param.
Migration depuis ROS 1
Le Guide de migration des fichiers de lancement explique comment migrer les balises de lancement param et rosparam de ROS 1 vers ROS 2.
Le guide de migration des fichiers de paramètres YAML explique comment migrer les fichiers de paramètres de ROS 1 vers ROS 2.
Dans ROS 1, le roscore agissait comme un tableau noir de paramètres globaux où tous les nœuds pouvaient obtenir et définir des paramètres. Puisqu’il n’y a pas de roscore central dans ROS 2, cette fonctionnalité n’existe plus. L’approche recommandée dans ROS 2 consiste à utiliser des paramètres par nœud étroitement liés aux nœuds qui les utilisent. Si un tableau noir global est encore nécessaire, il est possible de créer un nœud dédié à cet effet. ROS 2 est livré avec un dans le package ros-rolling-demo-nodes-cpp appelé parameter_blackboard ; il peut être exécuté avec :
ros2 run demo_nodes_cpp parameter_blackboard
Le code pour le parameter_blackboard est ici.