TP 3 — Services et paramètres

Objectifs

offrir un service : une requête, une réponse ;
régler les limites de la bibliothèque micro-ROS, et la reconstruire ;
exposer des paramètres, modifiables depuis ROS 2 sans recompiler, et les valider.

Durée indicative : une séance de 3 h. Prérequis : TP 2 — Recevoir des ordres, dont on reprend le projet.

Ce qu’il faut savoir

Topic, service ou paramètre ?

Mécanisme	Principe	Exemple
topic	flux de messages, sans réponse, à n’importe quel nombre d’abonnés	une mesure, une consigne de vitesse
service	une requête, une réponse, à un seul serveur	remettre l’odométrie à zéro, déclencher un bip
paramètre	une valeur nommée, lue et modifiée par `ros2 param`	un réglage : un rayon de roue, un seuil

Un service est fait pour une action ponctuelle, dont on veut savoir si elle a réussi. Un paramètre, pour un réglage, qu’on change rarement.

Le robot en offre de chaque sorte : base/reset_odom est un service ; les rayons de roue et l’entraxe sont des paramètres de sa carte.

Les limites de micro-ROS

micro-ROS n’alloue pas de mémoire au fil de l’eau : le nombre de nœuds, d’éditeurs, d’abonnés, de services est fixé à la compilation de la bibliothèque, dans le fichier colcon.meta. Par défaut :

RMW_UXRCE_MAX_PUBLISHERS     = 10
RMW_UXRCE_MAX_SUBSCRIPTIONS  =  5
RMW_UXRCE_MAX_SERVICES       =  1
RMW_UXRCE_MAX_CLIENTS        =  1

Au-delà, la création échoue — et rien d’autre ne l’indique que le code de retour.

Étape 1 — Un service : le buzzer

Configurez PC13 en sortie (le buzzer actif, TP 3 de la partie 1).

Créez un service buzzer de type std_srvs/srv/SetBool : data: true met le buzzer en marche, false l’arrête. La réponse indique success et un court message.

rclc_service_init_default(&srv_buzzer, &node,
    ROSIDL_GET_SRV_TYPE_SUPPORT(std_srvs, srv, SetBool), "buzzer");
rclc_executor_add_service(&executor, &srv_buzzer, &req_buzzer,
                          &res_buzzer, buzzer_cb);

Le champ message de la réponse est une chaîne : comme au TP 2, c’est à vous de fournir sa mémoire.
Un élément de plus pour l’exécuteur.

Depuis le PC :

ros2 service list
ros2 service call /tp/buzzer std_srvs/srv/SetBool "{data: true}"

Questions

Que renvoie l’appel ? Que se passe-t-il si la carte est débranchée ?
Pourquoi un service plutôt qu’un topic std_msgs/msg/Bool ?

Étape 2 — Un second service, et la limite

Ajoutez un service reset_counter de type std_srvs/srv/Trigger, qui remet à zéro le compteur du TP 1 (réintégrez-le s’il a disparu).
Vérifiez le code de retour de sa création : que se passe-t-il ?
Ouvrez micro_ros_stm32cubemx_utils/microros_static_library_ide/ library_generation/colcon.meta, et portez RMW_UXRCE_MAX_SERVICES à 8.
Supprimez le dossier micro_ros_stm32cubemx_utils/microros_static_library_ide/libmicroros, pour forcer la reconstruction de la bibliothèque, et recompilez.

Question

Pourquoi ces limites sont-elles fixées à la compilation, et pas choisies par le programme ?

Étape 3 — Des paramètres

Trois réglages de la carte deviennent des paramètres :

Nom	Type	Rôle
`blink_period_ms`	entier	période de clignotement de LED_2, de 50 à 5 000 ms
`temp_alarm`	réel	seuil d’alarme de température, en °C : LED_3 allumée au-delà
`buzzer_enabled`	booléen	autorise ou non le service `buzzer`

Créez le serveur de paramètres, avec une option pour en accepter plusieurs (par défaut : quatre au plus) :

rclc_parameter_options_t o = {
    .notify_changed_over_dds     = true,
    .max_params                  = 4,
    .allow_undeclared_parameters = false,
    .low_mem_mode                = false,
};
rclc_parameter_server_init_with_option(&params, &node, &o);
rclc_executor_add_parameter_server(&executor, &params, on_param_changed);

Le serveur utilise cinq services et un éditeur : comptez-les dans les limites de l’étape 2, et ajoutez RCLC_EXECUTOR_PARAMETER_SERVER_HANDLES (5) au nombre d’éléments de l’exécuteur.

Déclarez chaque paramètre, puis donnez-lui sa valeur de départ :

rclc_add_parameter(&params, "blink_period_ms", RCLC_PARAMETER_INT);
rclc_parameter_set_int(&params, "blink_period_ms", 500);

Écrivez on_param_changed : elle reçoit l’ancienne et la nouvelle valeur, et renvoie true pour accepter la modification, false pour la refuser. Refusez une période hors de 50–5 000 ms.

Important

old_param vaut NULL à la création d’un paramètre (premier rclc_parameter_set_*) : ce n’est pas une erreur, il faut accepter. Sinon, tous les paramètres restent à zéro.
Dans la boucle, lisez les paramètres (rclc_parameter_get_int…) et appliquez-les.

Depuis le PC :

ros2 param list /tp/ratbot_lab
ros2 param get /tp/ratbot_lab blink_period_ms
ros2 param set /tp/ratbot_lab blink_period_ms 100
ros2 param set /tp/ratbot_lab blink_period_ms 10

Questions

Que répond ros2 param set pour la valeur 10 ? Où ce refus a-t-il été décidé ?
Redémarrez la carte : que valent les paramètres ? Comment le firmware du robot garde-t-il les siens d’un démarrage à l’autre ?
Pourquoi le serveur de paramètres demande-t-il cinq services ? Lesquels (ros2 service list) ?

Solution de l’étape 3

#include <rclc_parameter/rclc_parameter.h>

static rclc_parameter_server_t params;

/* old_param NULL : création ; new_param NULL : suppression. */
static bool on_param_changed(const Parameter *old_param, const Parameter *new_param,
                             void *context)
{
    (void)context;
    if (old_param == NULL) { return true; }      /* création : on accepte */
    if (new_param == NULL) { return false; }     /* suppression : on refuse */

    if (strcmp(new_param->name.data, "blink_period_ms") == 0)
    {
        int64_t v = new_param->value.integer_value;
        return (v >= 50) && (v <= 5000);
    }
    if (strcmp(new_param->name.data, "temp_alarm") == 0)
    {
        double v = new_param->value.double_value;
        return (v > 0.0) && (v < 100.0);
    }
    return true;                                 /* buzzer_enabled : tout booléen */
}

la création (l’exécuteur compte maintenant 2 + 5 éléments) :

rclc_parameter_options_t o = {
    .notify_changed_over_dds     = true,
    .max_params                  = 4,
    .allow_undeclared_parameters = false,
    .low_mem_mode                = false,
};

rclc_parameter_server_init_with_option(&params, &node, &o);
rclc_executor_init(&executor, &support.context,
                   2u + RCLC_EXECUTOR_PARAMETER_SERVER_HANDLES, &allocator);
/* … les deux services … */
rclc_executor_add_parameter_server(&executor, &params, on_param_changed);

rclc_add_parameter(&params, "blink_period_ms", RCLC_PARAMETER_INT);
rclc_parameter_set_int(&params, "blink_period_ms", 500);
rclc_add_parameter(&params, "temp_alarm", RCLC_PARAMETER_DOUBLE);
rclc_parameter_set_double(&params, "temp_alarm", 35.0);
rclc_add_parameter(&params, "buzzer_enabled", RCLC_PARAMETER_BOOL);
rclc_parameter_set_bool(&params, "buzzer_enabled", true);

et dans la boucle :

int64_t period = 500;
double  alarm  = 35.0;

(void)rclc_parameter_get_int(&params, "blink_period_ms", &period);
(void)rclc_parameter_get_double(&params, "temp_alarm", &alarm);
/* … LED_2 clignote à « period », LED_3 s'allume au-delà de « alarm » … */

Le service buzzer consulte buzzer_enabled avec rclc_parameter_get_bool avant d’agir, et répond success = false s’il est désactivé.

Pourquoi l’ordre déclarer, puis valeur. rclc_add_parameter crée le paramètre, sans valeur ; le premier rclc_parameter_set_* la lui donne, et passe par le rappel de validation avec old_param à NULL. Un rappel qui refuse ce cas laisserait tous les paramètres à zéro, sans aucun message : c’est un piège rencontré sur le firmware du robot.

max_params : par défaut, le serveur n’accepte que quatre paramètres ; au-delà, rclc_add_parameter échoue en silence si l’on ne teste pas son retour. Le robot en déclare treize, d’où l’option.

La validation sur la carte. C’est la carte qui sait quelles valeurs sont dangereuses pour elle. Valider côté PC serait insuffisant : n’importe quel outil ROS 2 peut appeler le service set_parameters.

Exercices supplémentaires

Ces exercices n’ont pas de correction.

Mémoriser les réglages : un service save écrit les paramètres dans un registre de sauvegarde de la RTC (TP 9 de la partie 1) ; au démarrage, ils y sont relus.
Un fichier de paramètres : ros2 param dump écrit les paramètres dans un fichier YAML, ros2 param load les recharge. Essayez.
Les contraintes déclarées : utilisez rclc_add_parameter_constraint_integer pour déclarer la plage de blink_period_ms, et observez ros2 param describe.

Après le TP

La flash externe contient votre programme : réinstallez celui du robot, voir Remettre la carte en état RatBot.