À propos des interfaces ROS 2

1. Origines

Les applications ROS communiquent généralement via des interfaces de l’un des trois types suivants : messages, services et actions. ROS 2 utilise un langage de description simplifié, le langage de définition d’interface (IDL), pour décrire ces interfaces. Cette description permet aux outils ROS de générer automatiquement le code source pour le type d’interface dans plusieurs langages cibles.

Dans ce document, nous décrirons les types pris en charge.

• msg : les fichiers .msg sont de simples fichiers texte qui décrivent les champs d’un message ROS. Ils sont utilisés pour générer le code source des messages dans différentes langues.

• srv : les fichiers .srv décrivent un service. Ils sont composés de deux parties : une requête et une réponse. La requête et la réponse sont des déclarations de message.

• action : les fichiers .action décrivent les actions. Ils sont composés de trois parties : un objectif, un résultat et des commentaires. Chaque partie est une déclaration de message elle-même.

2. Spécification de la description des messages

Les messages sont décrits et définis dans des fichiers .msg dans le répertoire msg/ d’un package ROS. Les fichiers .msg sont composés de deux parties : des champs et des constantes.

2.1 Champs

Chaque champ est composé d’un type et d’un nom, séparés par un espace, c’est-à-dire :

fieldtype1 fieldname1
fieldtype2 fieldname2
fieldtype3 fieldname3

Par example:

int32 my_int
string my_string

2.1.1 Types de champs

Les types de champs peuvent être :

• un type intégré

• noms des descriptions de message définis par eux-mêmes, tels que « geometry_msgs/PoseStamped »

Types intégrés actuellement pris en charge :

Tapez le nom	C++	Python	Type DDS
bourdonner	bourdonner	builtins.bool	booléen
octet	uint8_t	builtins.octets*	octuor
carboniser	carboniser	builtins.str*	carboniser
float32	flotter	builtins.float*	flotter
float64	double	builtins.float*	double
vous8	int8_t	builtins.int*	octuor
win8	uint8_t	builtins.int*	octuor
int16	int16_t	builtins.int*	court
uint16	uint16_t	builtins.int*	court non signé
Se remettre	int32_t	builtins.int*	longue
se remettre	uint32_t	builtins.int*	long non signé
int64	int64_t	builtins.int*	longtemps longtemps
gagner t64	uint64_t	builtins.int*	non signé long long
chaîne	std ::chaîne	builtins.str	chaîne
ficelle	std :: chaîne u16	builtins.str	ficelle

Chaque type intégré peut être utilisé pour définir des tableaux :

Tapez le nom	C++	Python	Type DDS
tableau statique	std::array<T, N>	builtins.list*	T[N]
tableau dynamique illimité	std :: vecteur	builtins.list	séquence
tableau dynamique borné	classe_personnalisée<T, N>	builtins.list*	séquence<T, N>
chaîne délimitée	std ::chaîne	builtins.str*	chaîne

Tous les types qui sont plus permissifs que leur définition ROS appliquent les contraintes ROS de plage et de longueur par logiciel

Exemple de définition de message utilisant des tableaux et des types bornés :

int32[] unbounded_integer_array
int32[5] five_integers_array
int32[<=5] up_to_five_integers_array

string string_of_unbounded_size
string<=10 up_to_ten_characters_string

string[<=5] up_to_five_unbounded_strings
string<=10[] unbounded_array_of_string_up_to_ten_characters_each
string<=10[<=5] up_to_five_strings_up_to_ten_characters_each

2.1.2 Noms de champs

Les noms de champ doivent être des caractères alphanumériques minuscules avec des traits de soulignement pour séparer les mots. Ils doivent commencer par un caractère alphabétique, ils ne doivent pas se terminer par un trait de soulignement et ne doivent jamais avoir deux traits de soulignement consécutifs.

2.1.3 Valeur par défaut du champ

Les valeurs par défaut peuvent être définies sur n’importe quel champ du type de message. Actuellement, les valeurs par défaut ne sont pas prises en charge pour les tableaux de chaînes et les types complexes (c’est-à-dire les types non présents dans le tableau des types intégrés ci-dessus, qui s’applique à tous les messages imbriqués)

La définition d’une valeur par défaut se fait en ajoutant un troisième élément à la ligne de définition du champ, à savoir :

fieldtype fieldname fielddefaultvalue

Par example:

uint8 x 42
int16 y -2000
string full_name "John Doe"
int32[] samples [-200, -100, 0, 100, 200]

Note:

• les valeurs de chaîne doivent être définies entre des ' simples ou des guillemets doubles "

• actuellement les valeurs de chaîne ne sont pas échappées

2.2 Constantes

Chaque définition de constante est comme une description de champ avec une valeur par défaut, sauf que cette valeur ne peut jamais être modifiée par programmation. Cette affectation de valeur est indiquée par l’utilisation d’un signe égal “=”, par ex.

constanttype CONSTANTNAME=constantvalue

Par example:

int32 X=123
int32 Y=-123
string FOO="foo"
string EXAMPLE='bar'

Note

Les noms des constantes doivent être en MAJUSCULES

3. Spécification de description de service

Les services sont décrits et définis dans les fichiers .srv du répertoire srv/ d’un package ROS.

Un fichier de description de service se compose d’une demande et d’un type de message de réponse, séparés par “—”. Deux fichiers .msg concaténés avec un “—” sont une description de service légale.

Voici un exemple très simple d’un service qui prend une chaîne et renvoie une chaîne :

string str
---
string str

On peut bien sûr faire beaucoup plus compliqué (si vous voulez faire référence à un message du même paquet vous ne devez pas mentionner le nom du paquet) :

#request constants
int8 FOO=1
int8 BAR=2
#request fields
int8 foobar
another_pkg/AnotherMessage msg
---
#response constants
uint32 SECRET=123456
#response fields
another_pkg/YetAnotherMessage val
CustomMessageDefinedInThisPackage value
uint32 an_integer

Vous ne pouvez pas intégrer un autre service à l’intérieur d’un service.

4. Nouvelles fonctionnalités dans les interfaces ROS 2

Le ROS 2 IDL est étroitement lié au ROS 1 IDL. La plupart des fichiers .msg et .srv de ROS 1 existants devraient être utilisables tels quels avec ROS 2. Au-dessus de l’ensemble de fonctionnalités existant de ROS 1, le ROS 2 IDL introduit de nouvelles fonctionnalités, à savoir :

• tableaux délimités : alors que l’IDL ROS 1 autorise les tableaux illimités (par exemple, int32[] foo) et les tableaux de taille fixe (par exemple, int32[5] bar), l’IDL ROS 2 autorise en outre les tableaux délimités (par exemple, int32[<=5] bat). Il existe des cas d’utilisation dans lesquels il est important de pouvoir placer une limite supérieure sur la taille d’un tableau sans s’engager à toujours utiliser autant d’espace (par exemple, dans un système en temps réel dans lequel vous devez préallouer toute la mémoire qui sera utilisé lors de l’exécution).

• chaînes délimitées : alors que l’IDL ROS 1 autorise les chaînes illimitées (par exemple, string foo), l’IDL ROS 2 autorise également les chaînes délimitées (par exemple, string<=5 bar).

• valeurs par défaut : alors que l’IDL ROS 1 autorise des champs constants (par exemple, int32 X=123), l’IDL ROS 2 permet en outre de spécifier des valeurs par défaut (par exemple, int32 X 123) . La valeur par défaut est utilisée lors de la construction d’un objet message/service et peut être remplacée par la suite en l’attribuant au champ. Vous pouvez également spécifier des valeurs par défaut pour les parties d’action.