URBI Tutorial pour Urbi 1.5

Tout d'abord, téléchargez le memorystick correspondant à votre robot. Deux possibilités s'offrent à vous pour l'instant :

Instructions rapides :

Décompressez l'archive et copiez le contenu du dossier MS-xxx sur un memorystick vierge, puis mettez le fichier WLANCONF.TXT à jour en l'adaptant à la configuration de votre réseau.

Instructions détaillées :

Un des avantages de l'architecture client/serveur d'URBI est que vous pouvez immédiatement envoyer des commandes à votre robot via un simple client telnet. Bien entendu, il est envisageable d'interfacer URBI avec un programme écrit en C++ ou en Java, comme nous le verrons prochainement en parlant de liburbi (chapitre La liburbi en C++). Nous allons pour l'instant nous contenter d'une interface telnet.

Toutefois, telnet est quelque peu spartiate (et ne marche pas toujours bien sous Windows ^[3] ) et nous avons développé un logiciel multi-plateforme disposant d'une interface graphique que nous avons appelé URBI Remote et que nous vous encourageons à utiliser. URBI Remote est gratuit et mis à disposition sous license GNU-GPL. Vous pouvez le télécharger ici (disponible fin 2007) :

http://www.urbiforge.com/index.php?option=com_content&task=view&id=75&Itemid=136

D'autres applications graphiques tierces-parties comme Aibo-Telecommande peuvent être téléchargées dès maintenant sur urbiforge.com.

Nous allons utiliser les moteurs dans ce qui suit, donc, avant toute chose, nous les mettons en route :

motors on;

motors off est bien sûr également disponible, comme normalement n'importe quel device ou objet avec nom_du_device on/off. Commençons par déplacer le moteur HeadPan à 30 degrés:

headPan = 30;

Maintenant, demandons quelle est la valeur du device HeadPan:

headPan;
[00177648] 30.000000

Le serveur répond avec un message (écrit ici en italique pour le distinguer des commandes) précédé d'une marque temporelle (timestamp) et d'une étiquette (tag) entre crochets. Ici la commande n'a été associée à aucune étiquette, par conséquent le terme notag est utilisé par défaut. Il est très simple d'associer une étiquette à une commande en URBI. Il suffit de précéder la commande d'un mot suivi du symbole deux-points (:):

monetiquette << headPan;
[00300553:monetiquette] 30.000000

Le message possède maintenant l'étiquette monetiquette. Cela va s'avérer indispensable lorsqu'il s'agira de déterminer qui envoie quoi dans un contexte de commandes s'exécutant en parallèle, ou pour arrêter une commande en cours d'exécution en tâche de fond.

Vous pouvez essayer d'agir ainsi sur différents moteurs de l'Aibo tels legRF1 ou tailTilt, ou bien vous amuser avec les lumières (leds) telles ledF1 ou ledBMC, ou bien encore lire les valeurs de capteurs comme le détecteur de distance distanceNear ou l'accéléromètre avec accelX, accelY et accelZ. La syntaxe est toujours la même: device = value;.

En réalité device = value est compris par URBI comme device.val = value; qui affecte le paramètre val du device à value. Mais, afin de simplifier encore les choses pour les débutants, tous les devices d'Aibo ont un alias construit de la façon suivante:

alias headPan headPan.val

Du coup, vous n'avez pas à vous préoccupper d'ajouter le paramètre val pour les travaux basiques sur les moteurs. Il est toutefois possible de retirer ces alias (définis dans le fichier URBI.INI) avec la commande unalias.

Les exemples précédents affectent la valeur d'un device aussi rapidement que le matériel le peut. Bien entendu, vous souhaitez certainement faire quelquechose de plus élaboré comme atteindre une certaine valeur dans un temps donné (en millisecondes):

headPan = 30 time:3000;

qui va atteindre la valeur 30 (degrés) en 3000ms. Quand vous avez à exprimer une valeur temporelle avec URBI, vous pouvez toujours préciser explicitement l'unité que vous souhaitez employer:

headPan = 30 time:3s;
headPan = 30 time:3000ms;
headPan = 30 time:3m;
headPan = 30 time:3h26m15s;

Vous pouvez utiliser des jours (d), des heures (h), des minutes (m), des secondes (s) et des millisecondes (ms), avec des valeurs décimales. Par défaut, l'unité est la milliseconde si aucune unité n'est précisée ou lorsqu'une variable est utilisée.

D'autrepart, vous pouvez également régler la vitesse à la laquelle la valeur doit être atteinte, exprimée en unité/s:

headPan = 30 speed:1.4;

Ou l'accélération (exprimée en unité/s²):

headPan = 30 accel:0.4;

Une manière très utile d'affecter une variable avec un profil dynamique est d'employer l'oscillation sinusoïdale:

headPan = 30 sin:2s ampli:20,

Cela va faire osciller le device HeadPan autour de 30 degrés avec une amplitude de 20 degrés et une période de 2 secondes. Remarquez que la commande se conclue par une virgule et non un point-virgule. Nous expliquerons ceci en détail plus tard, mais, en deux mots, la raison est que l'oscillation ne termine jamais et la virgule signifie en quelque sorte "mais fais tourner ceci en tâche de fond" pour permettre aux commandes suivantes d'être exécutées. Autrement, avec un point-virgule, aucune autre commande ne pourrait ensuite être exécutée puisque l'oscillation ne termine jamais. Il s'agit d'une erreur courante de la part des débutants en URBI.

time, speed et sin sont appelés des modificateurs. Il en existe beaucoup d'autres comme phase, getphase ou smooth. Rendez-vous dans le document "URBI Language Specification" pour une liste exhaustive des modificateurs.

Un modificateur particulièrement puissant est une fonction qui affecte une fonction temporelle complexe en tant que variable de trajectoire. Tout ceci est décrit dans "URBI Language Specification" et ne sera disponible qu'à partir de la version 2.0 des serveurs.

Avec URBI, vous pouvez utiliser des variables. Affecter une valeur à x suffit à créer une variable nommée x qui sera locale à votre connexion:

x = 4;
x;
[00520072] 4.000000

monprefixe.x = "salut";

x = pi / 2;
calc << sqrt(1 + sin(x));
[00593076:calc] 1.414214

the_amplitude = 20 sin:10s ampli:5,
x = 0 sin:2s ampli:the_amplitude,

Avec URBI, vous pouvez stocker des éléments dans une liste, simplement en les encadrant par des crochets:

malist = [1, 2, 35.12, "hello"];
malist;
[00636417] [1.000000,2.000000,35.119999,"hello"]

Ajouter de nouveaux éléments ou des listes entre elles se réalise simplement:

malist = [1, 2] + "hello";
malist;
[00034647] [1.000000,2.000000,"hello"]
x = 1;
malist + [45, x];
[00101011] [1.000000,2.000000,"hello",45.000000,1.000000]

Pour accéder successivement à chaque élément d'une liste, utilisez la commande foreach:

list = [1, 2];
for n in list { echo (n) };
[00012407] *** 1.000000
[00012407] *** 2.000000

Pour des raisons purement techniques, le code exécuté dans une commande foreach doit être encadré par des accolades, même s'il n'est composé que d'une commande.

Vous pouvez accéder à n'importe quel élément en fournissant sa position dans la liste, comme avec les tableaux de la majorité des langages de programmation:

malist = [1, 2, "hello"];
malist[2];
[00013799] "hello"

Pour accéder aux éléments d'une liste contenue elle-même dans une autre liste, utilisez des index multiples comme maliste[3][4].

Enfin, vous pouvez demander le premier élément de la liste (ce que l'on nomme la tête ou head) et le reste (ce que l'on nomme la queue ou tail):

malist = [1, 2, "hello"];
head(malist);
[00014214] 1.000000
tail(malist);
[00019686] [2.000000,"hello"]

Une commande URBI peut durer un certain temps. C'est une nouveauté parmi la plupart des autres langages. Nous avons vu précédemment que l'on peut affecter des valeurs avec une certaine durée, une certaine vitesse, voire même avec une évolution sinusoïdale sans fin. Il existe de nombreuses façons de faire fonctionner ces commandes en parallèle. Nous avons déjà vu comment le faire en utilisant une virgule pour séparer les commandes au lieu d'un point-virgule.

Il y a une autre manière pour indiquer que les commandes doivent s'exécuter en parallèle: utiliser & :

x=4 time:1s & y=2 speed:0.1;

La différence avec le séparateur virgule est qu'ici on force les deux commandes à démarrer exactement au même moment. En particulier, cela signifie que la première commande ne peut démarrer tant que la seconde n'est pas complètement disponible. Ainsi, taper x=4 time:1s & dans la console ne produira rien car URBI attendra alors de savoir ce qui suit, après le & (c'est la raison pour laquelle le séparateur virgule existe, car ce dernier est moins contraignant et permet de lancer les commandes intéractivement).

Dans la même idée, les commandes peuvent être lancées en série, exactement l'une après l'autre, en utilisant un séparateur | (appelé pipe, tuyau en anglais):

x=4 time:1s | y=2 speed:0.1;

Il n'y aura aucun temps mort entre les deux commandes donc, là encore, URBI attend que la seconde commande soit disponible: la seconde commande doit démarrer exactement après la première, par conséquent elle doit être lue en avance.

Utiliser le point-virgule ou la virgule est plus permissif car ces deux séparateurs démarrent immédiatement la commande se trouvant juste avant eux. Mais si votre projet réclame des contraintes temporelles fortes, les séparateurs & et | sont là pour vous aider.

Il est possible de regrouper plusieurs commandes en les encadrant avec des accolades et ainsi élaborer des structures temporelles complexes:

{ { x = 4 time:1s | y = 2 speed:0.1 } & z = 0 sin:200ms ampli:4 } | t = 2,

Conseil: En général, pensez à terminer les commandes entrées dans une console (URBILab ou telnet) par une virgule, pour éviter de bloquer la connexion après avoir saisi une commande sans fin.

Comme il est possible d'exécuter des commandes en parallèle, il se peut que des conflits apparaissent. Par exemple, que se passerait-il si le code suivant était exécuté ?

x=1 & x=5;

x=5 est une affectation conflictuelle car elle accède à la variable x en même temps que la première affectation. Pour cela, URBI possède plusieurs modes de mélange (blend) pour prendre en charge les éventuels conflits et vous pouvez indiquer le mode souhaité grâce à la propriété blend de la variable. Par exemple:

x->blend = add;

Cela va demander à URBI d'additionner les valeurs numériques de toutes les affectations conflictuelles sur la variable x. Ainsi, le résultat de la commande précédente sera l'affectation de la valeur 6 à la variable x. Il existe également un mode mix qui réalise la moyenne des affectations conflictuelles (le résultat serait alors 3) ainsi qu'un mode queue qui écrase les affectations conflictuelles (le résultat serait alors 5). D'autres modes sont disponibles et décrits dans le document "URBI Language Specification".

Avec URBI, les variables possèdent des propriétés qui peuvent être accédées avec l'opérateur ->. Une propriété n'est pas l'attribut d'un objet. Les propriétés font partie intégrante de la sémantique du langage et par conséquent ne peuvent être redéfinies. Il existe de nombreuses propriétés disponibles comme rangemin, rangemax, speedmax, delta. Elle sont décrites dans le document "URBI Language specification."

Les modes de mélange s'appliquent également aux devices sonores, tels le haut-parleur de l'Aibo et passer alors de mix à queue passera d'une superposition sonore à une succession sonore (les sons, quoiqu'il arrive, sont joués les uns après les autres).

Les modes add et mix s'avèrent très utiles pour superposer des affectations sinusoïdales pour élaborer des mouvement périodiques complexes, en utilisant des transformations de Fourier du signal et en ne retenant que le coefficient le plus significatif.

Pour l'Aibo comme la plupart des robots, vous trouverez les variables de moteurs suivantes utiles (remplacez device par le nom du device):

Et voici des propriétés utiles, qui ne sont pas des variables au sens strict (les propriétés font partie de la sémantique du langage), mais vous pouvez les lire et les règler:

Ces propriétés sont en réalité celles de device.val, sachant que l'on considère que les alias sont opérationnels.

Voici une brève liste de commandes qui pourraient s'avérer utiles dans vos programmes:

Le branchement conditionnel et les boucles disponibles avec le C et le C++ sont présents dans URBI : if ... else, for et while. Les exemples suivants illustrent ces constructions (la commande echo que vous trouverez parmi les exemples affiche tout simplement l'expression en tant que message-système).

if (backSensorM > 0) {
       pressed = 1;
       echo "Back sensor pressed";
};

distance = 100;
if (distance < 10)
  echo ("Obstacle detected")
else
  echo ("No obstacle");
[00042854] *** No obstacle

i=0;
while (i <= 2) {
  i << echo (i);
  i++;
};
[00043477:i] *** 0.000000
[00043516:i] *** 1.000000
[00043536:i] *** 2.000000

for (i = 0; i <= 2; i++)
  i << echo (i);
[00022967:i] *** 0.000000
[00022991:i] *** 1.000000
[00023011:i] *** 2.000000

for i in [0, 1, 2]
{
  i << echo (i);
};
[00117921:i] *** 0.000000
[00117921:i] *** 1.000000
[00117921:i] *** 2.000000

loop { ... }

loopn (n) { ... }

Le système d'étiquetage décrit au début de ce tutoriel est en réalité plus qu'une simple identification de messages. Par exemple, vous pouvez arrêter n'importe quelle commande avec la commande stop, depuis n'importe quelle connexion:

maboucle << loop legRF2 = legLF2,
...
stop maboucle;

Vous pouvez aussi geler une commande avec la commande freeze et la dégeler (elle reprendra là où elle en était) avec la commande unfreeze. Il existe aussi la combinaison de commandes block/unblock qui permet d'empêcher de nouvelles exécutions de la commande possédant l'étiquette donnée. Une étiquette peut préfixer un ensemble de commandes entre accolades, comme { ... }, et ainsi être associée à une large portion de code et pas forcément une seule commande.

A la suite de l'étiquette, il est possible d'ajouter un ou plusieurs drapeaux (flags). Un drapeau est un mot-clé préfixé par le signe +. Les drapeaux les plus utiles sont +begin et +end qui envoient un message-système lorsque la commande démarre et lorsqu'elle s'arrête, ou +bg qui place la commande en tàche de fond. Voici quelques exemples illustrant tout ceci:

monetiquette+begin: loop legRF2 = legLF2,
[139464:monetiquette] *** begin

+begin+end: wait(1s);
[00564537] *** begin
[00565537] *** end

D'autres drapeaux sont présentés dans le document "URBI Language Specification".

Depuis URBI 1.0, vous pouvez utiliser des étiquettes hiérarchiques comme monetiquette.sousetiquette. L'avantage de ceci est que vous pouvez arrêter une famille entière basée uniquement sur l'étiquette-mère: l'étiquette précédente peut aussi bien être arrêtée avec un stop monetiquette.sousetiquette qu'avec un stop monetiquette, et vous pouvez ainsi regrouper facilement plusieurs commandes. Une prochaine version incluera également le multi-étiquetage pour accroître encore les possibilités.

Une possibilité importante offerte par URBI est de pouvoir regrouper les objets en hiérarchies. Cela se fait grâce à la commande group: group nomdugroupe { objet1, objet2, ...}, par exemple:

group patteavantgauche {legLF1, legLF2, legLF3};
group pattes {patteavantgauche, pattearrieregauche, patteavantdroite, pattearrieredroite};

Figure 4.1. Une hiérarchie typique de device moteurs

Cette fonction de regroupement est associée à la notion de broadcasting, qui est utilisée pour différentes choses. L'une d'entre-elles est l'affectation multi-objets : toute affectation est exécutée pour le groupe et, récursivement, passée aux sous-groupes-enfants. En d'autres termes, en utilisant l'exemple précédent, la commande legLF.val = 0 règlera la valeur de legLF1.val, legLF2.val et legLF3.val à zéro (notez que les alias fonctionnent également si vous le souhaitez).

group ab { a, b };
ab.n = 4;
a << a.n, b << b.n;
[00828842:a] 4.000000
[00828842:b] 4.000000

Pour tout robot supporté, il y aura une hiérarchie de regroupement d'objets disponible au départ. Les commandes établissant cette hiérarchie se trouve dans le fichier URBI.INI ou le fichier std.u.

Par exemple, pour aibo, il y a un groupe de l'ensemble des moteurs et un groupe de l'ensemble des lumières. Vous pouvez ainsi régler toutes les lumiéres à une valeur aléatoire avec la commande suivante:

leds = random(2); // l'allias est utilisé ici

Pour s'amuser, vous pouvez tenter: fun: loop leds = random(2), et admirer le résultat.

Il reste plusieurs choses à dire au sujet des groupes et du broadcasting, qui est une fonction trés puissante d'URBI. Nous reviendrons sur le sujet dans le chapitre Les Objets avec URBI.

Pour définir une fonction, vous devez utiliser le mot-clé function suivi du nom de votre fonction en notation préfixe.suffixe (ou simplement suffixe pour une fonction locale à la connexion), et les paramètres entre parenthèses (ou des parenthèses vides s'il n'y a aucun paramètre). Vous pouvez utiliser return pour retourner une valeur ou quitter la fonction, comme en C:

function ajouter(x,y) {
  z = x + y;
  return z;
};

function ecrire(x) 
{
  echo (x);
  if (x < 0)
    return
  else
    echo (sqrt(x));
};

Il faut obligatoirement un point-virgule ou un autre séparateur de commande à la fin de la définition de la fonction, puisque que définir une fonction est une commande comme tout autre commande URBI.

Les paramètres sont toujours locaux à l'appel de la fonction. Les variables non globales (i.e. sans préfixe) dans le corps de la fonction sont également locales à l'appel de la fonction. Etudions l'exemple suivant:

a = 4;
b = 5;
function afficher(b) {
  afficher_b << b; // b est local
  var a = b; // crée une variable locale a
  afficher_a << a;
};
display(10); a << a; b << b;
[139464:display_b] 10.000000
[139464:display_a] 10.000000
[139464:a] 4.000000
[139464:b] 5.000000

Une bonne habitude est d'isoler vos fonctions dans un fichier séparé comme mesfonctions.u, et de les charger avec la commande: load("mesfonctions.u"). Cela peut être fait dans le fichier URBI.INI par exemple, ou quand vous en avez réellement besoin.

Pour retirer la définition d'une function, utiliser simplement:

delete mafonction;

Lorsqu'une commande URBI échoue, cela envoie un message d'erreur, préfixé par trois points d'exclamation:

impossible << 1 / 0;
[00224686:impossible] !!! 5.15-19: Division par zero
[00224686:impossible] !!! 5.15-19: EXPR evaluation failed

Remarquez que l'étiquette de la commande est utilisée pour le message d'erreur, ce qui s'avère trés pratique pour savoir ce qui a coincé dans un programme complexe.

Les messages d'erreur sont différents des messages-système, préfixés eux par trois étoiles. Un exemple simple est la commande echo avec drapeau +begin et un drapeau +end:

monetiquette+begin+end << echo "salut tout le monde!";
[146711:monetiquette] *** début
[146711:monetiquette] *** salut tout le monde!
[146711:monetiquette] *** fin

Tout comme en C++, on définit une classe en URBI avec le mot-clé class:

class maclasse;

Vous pouvez naturellement définir ce qui se trouvera dans la classe, c'est à dire des variables, des fonctions et des événements:

class maclasse {
  var x;
  var y;
  function f(a,b);
  event signalemoi(s);
};

Il est important de remarquer que, contrairement aux classes C++, maclasse dans l'exemple précédent est également une instance ^[4] et vous pouvez donc tout à fait affecter des valeurs à maclasse.x et l'utiliser.

Une fonction importante que vous souhaitez certainement définir est init, qui est le constructeur de la classe (ceci est une autre différence avec le C++, le constructeur n'est pas nommé avec le nom de la classe). Cette fonction ne devrait rien retourner ou retourner zéro pour indiquer la réussite de la création de l'instance et tout autre valeur pour indiquer son échec.

Pour définir le corps d'une méthode de classe, faites-le en dehors de la définition de classe, de la manière suivante:

class maclasse {
  var x;
  function init(a);
};

function maclasse.init(a) {
  x = a;
};

Vous pouvez définir une sous-classe (ou une instance, souvenez-vous qu'il n'y a aucune différence), avec une commande new, comme en C++:

masousclasse = new maclasse(42);

Cela va créer une sous-classe et appeler masousclasse.init(42);.

masousclasse hérite de maclasse, par conséquent tous les attributs et les méthodes de maclasse sont aussi disponibles dans masousclasse. Nous allons voir par la suite la question de la définition par défaut et celle de la redéfinition ^[5].

masousclasse peut hériter de plusieurs classes en appelant new sur ces différentes classes:

masousclasse = new maclasse (42);
masousclasse = new monautreclasse ();

C'est une façon assez spéciale de traiter l'héritage multiple, comparé au C++.

En appelant new sans parenthèses, avec juste le nom de la classe, on exécute le constructeur init sans paramètre:

mysubclass = new myclass; // same as new
myclass();

Si init n'est pas défini, ou si init retourne une valeur synonyme d'erreur (non vide et non nulle), un message d'erreur sera produit et la création avortée.

Les classes peuvent être complétées pendant l'exécution simplement en créant des fonctions ou des attributs se référant à elles. Exemple:

class maclass {
  var x;
};
var maclass.newattribute;
maclass.s = "hello";
...
function maclass.f(a) {
  s = a;
};

En URBI, toutes les méthodes (fonctions de classe) et tous les attributs (variables de classe) sont virtuels, ce qui signifie que si votre classe le redéfinit, il devient sa propre définition, autrement la définition (ou la valeur) de la classe-mère sera utilisée.

Considérons l'exemple suivant:

class maclasse {
  var x;
  function f();
};
function maclasse.f() {
  echo "Je suis dans maclasse";
};

D'où:

sous = new maclasse;
sous.f();
[01130940] *** Je suis dans maclasse

La définition de f est récupérée depuis maclasse. Nous pouvons maintenant la redéfinir:

function sous.f() {
  echo "Je suis dans sous!";
};

Observons la différence:

sous.f();
[01173929] *** Je suis dans sous!

De la même façon, les attributs obtiennent leur valeur de la classe-mère, à moins qu'ils soient redéfinis dans la classe-fille. L'exemple suivant illustre ce cas avec la classe précédente maclasse et les prototypes de sous:

myclass.x = 1;
sub.x;
[01198648] 1.000000
sub.x = 4;
sub.x;
[01210231] 4.000000
myclass.x;
[01214327] 1.000000

Nous avons vu dans les chapitres précédents comment les groupes peuvent être utilisés pour affecter simultanément une valeur à plusieurs variables d'objets. En fait, le mécanisme est bien plus général et est associé au concept de diffusion qui sera défini précisément dans la prochaine section.

Tout d'abord, quelques mots sur les groupes. Nous avons déjà appris que nous pouvions définir des groupes avec la commande group. De la même façon, vous pouvez ajouter un membre à un groupe avec la commande addgroup et en retirer un avec delgroup, ce qui vous permet la gestion dynamique de vos groupes:

group a {a1,a2};
addgroup a {c,d};
delgroup a {a1,d};

Vous pouvez examiner le contenu d'un groupe en invoquant la commande group avec seulement le nom du groupe:

group a { u, v, b };
group a;
[01299618] ["u","v","b"]

Le regroupement de sous-groupes est possible. Dans ce cas, l'évaluation du contenu du groupe retourne la liste des membres terminaux seulement:

group a { u, v, b };
group b { x, y };
group a;
[01359471] ["u","v","x","y"]

L'utilisation typique de cela est l'énumération de devices, comme des moteurs, qui ont été regroupés dans le même groupe:

for m in group a
{
  echo (m);
};
[01426875] *** u
[01426875] *** v
[01426875] *** x
[01426875] *** y

Le constructeur $ retourne la variable dont le nom est la chaine de caractères donnée en paramètre. Dans l'exemple précédent, nous supposons qu'il y a un alias sur .val, autrement il faudrait écrire: $(m+".val")

Maintenant, nous allons voir comment utiliser en pratique les groupes avec la notion de diffusion.

Quand vous exécutez une commande à l'échelle d'un groupe, qui peut être un appel de fonction ou une affectation, la commande sera propagée en parallèle à chaque membre du groupe et à leurs sous-groupes. Cela s'appelle la diffusion (ou broadcast). Cela peut s'appliquer aussi aux classes, puisque vous pouvez définir un groupe contenant chaque instanciation de classe-fille. Une approche habituelle est de nommer le groupe associé à une classe avec le pluriel du nom de la classe, en ajoutant un simple "s".

Tout d'abord, observons comment une affectation est diffusée:

class a;
a1 = new a;
group as { a, a1 };
a1.x = 42;
as.x = 4;
a.x;
[00031479] 4.000000
a1.x;
[00036327] 4.000000

La diffusion fonctionne de manière similaire avec les fonctions:

class a {
  var x;
  function f();
};

function a.f() {
  echo (x);
};
a1 = new a;
group as { a, a1 };
a.x = 1;
a1.x = 2;
as.f();
[00049398] *** 2.000000
[00049398] *** 1.000000

La fonction précédente f est en réalité exécutée de la façon suivante:

a.f() & a1.f();

Diffuser revient donc à dupliquer les commandes en parallèle.

Les sous-groupes sont naturellement parcourus dans le processus.

Les fonctions diffusées peuvent s'avérer très utiles pour exécuter des tâches en parallèle dans un groupe d'objets, sans avoir à utiliser for& ou une construction similaire. La diffusion et l'héritage se complètent mutuellement, ainsi quand la diffusion est achevée, la définition de la fonction peut être recherchée en remontant dans la hiérarchie de classe, comme dans l'exemple suivant:

class a
{
  var x;
  function init(v);
  function f();
};
function a.init(v)
{
  x = v;
};
function a.f()
{
  echo (x);
};
a1 = new a(1);
a2 = new a(2);
a3 = new a(3);
function a1.f() { echo ("Je suis different!"); };
group oneandtwo { a1, a2 };
oneandtwo.f();
[00156447] *** 2.000000
[00156447] *** Je suis different!

La diffusion est clairement un concept nouveau dans les mains des programmeurs. Vous pouvez l'utiliser ou non, mais nous croyons que cela permettra d'obtenir des programmes plus concis, en regroupant les actions logiques en une ligne, au lieu d'utiliser des boucles for ou un concept itératif similaire. Cela renforce également l'idée que certaines actions doivent être exécutées en parallèle sur un groupe d'objets, ce qui peut rend votre code plus sensé.

Détecter une balle implique un traitement de l'image et ceci ne peut être écrit directement en URBI pour cause de performance. La meilleure façon de produire de tels composants algorithmiques (comme le traitement de l'image ou du son) est d'écrire un composant UObject en C++, Java ou Matlab et de le connecter à URBI. Nous n'allons pas nous attarder pour l'instant sur l'écriture d'un tel composant mais plutôt en utiliser un: l'objet ball.

L'objet ball est directement intégré dans l'Aibo URBI Engine et vous pouvez l'utiliser directement, comme n'importe quel device. Il n'y a pas de variable ball.val mais des variables ball.x et ball.y qui sont égales aux coordonnées de la balle dans l'image, comprises entre -1/2 et 1/2. Lorsqu'une balle est visible, ball.visible vaut 1, ou 0 dans le cas contraire. Il existe également une variable ball.ratio qui donne la proportion de pixels de la balle dans l'image, exprimée en pourcentage. Ces simples variables sont déjà intéressantes pour de nombreuses applications, tout comme nous allons le voir par la suite.

Le programme de détection de balle est donné en exemple dans le kit de développement de Sony (SDK OPEN-R) et réalise les actions suivantes: lorsqu'une balle se trouve en face du robot, ce dernier va la suivre en bougeant la tête. Autrement, il va la chercher en bougeant la tête en cercles.

Orienter la tête vers la balle peut être écrit très simplement en URBI avec les deux lignes suivantes:

headPan  = headPan  + camera.xfov * ball.x &
headTilt = headTilt + camera.yfov * ball.y;

Cela aura pour effet de bouger en même temps (c'est ce que veut dire le séparateur &) les deux moteurs de tête pan et tilt, d'une quantité proportionnelle aux positions x et y de la balle dans l'image de sa caméra. Les coefficients camera.xfov et camera.yfov viennent du device camera que nous découvrirons dans le chapitre suivant. Ils représentent l'angle x et l'angle y du champ de vision de la caméra de l'Aibo qui sont utilisés pour convertir l'intervalle normalisé [-1/2;1/2] de ball.x et ball.y en degrés.

Pour suivre la balle et non plus s'orienter une fois dans sa direction, nous allons utiliser la commande whenever:

whenever (ball.visible) {
  headPan  = headPan  + camera.xfov * ball.x &
  headTilt = headTilt + camera.yfov * ball.y;
};

Ce programme fait seulement trois lignes et réalise le comportement de suivi de balle que l'on souhaitait. Cependant, avec un Aibo, cela risque d'être trop réactif et conduira à de faibles oscillations de la tête autour de l'orientation de la balle. Pour éviter cela, une technique robotique simple est d'utiliser un coefficient d'atténuation, ball.a, pour limiter la réactivité du système. Par exemple:

ball.a = 0.8;
whenever (ball.visible) {
  headPan  = headPan + ball.a * camera.xfov * ball.x &
  headTilt = headTilt+ ball.a * camera.yfov * ball.y;
};

La prochaine étape est de basculer de ce comportement vers le comportement de recherche quand la balle n'est pas visible. Le comportement de recherche peut être exprimé avec un simple mouvement sinusoïdal sur à la fois headPan et headTilt. Nous utilisons dans l'exemple suivant l'extension de variable 'n ^[6] qui indique que l'on travaille avec une valeur normalisée de la variable, comprise entre 0 et 1, calculée à partir des propriétés rangemin (la limite inférieure) et rangemax (la limite supérieure). Cela s'avère très pratique d'éviter de contrôler la valeur actuelle d'un device et de le manipuler d'une façon générique:

periode = 10s;
headPan'n  = 0.5 sin:periode ampli:0.5 &
headTilt'n = 0.5 cos:periode ampli:0.5,

Le modificateur cos est identique à sin mais avec un décalage de phase de pi/2. Remarquez comme la valeur centrale 0.5 avec l'amplitude 0.5 permet de couvrir toute l'étendue du device: [0..1].

La commande précédente réalise le mouvement circulaire requis mais lorsque ce comportement est lancé, la position initiale sera atteinte brusquement depuis l'emplacement où se trouvant la tête avant le lancement de la commande. Pour éviter cela, nous pouvons précéder notre commande avec une transition douce d'une seconde vers la position initiale du cercle qui est headPan'n = 0.5 et headTilt'n = 1:

headPan'n  = 0.5 smooth:1s &
headTilt'n = 1   smooth:1s;

Le modificateur smooth est similaire à time, à la différence qu'il ajoute la douceur du tracé d'un "S", au lieu de faire un mouvement linéaire.

Désormais, nous pouvons tout connecter en un seul comportement, en utilisant la capteur d'évenement at comme ciment. Afin d'éviter de basculer du balayage circulaire au suivi de la balle trop souvent, nous ajoutons également un test coulé, et nous utilisons la fonction loadwav pour précharger deux fichiers sonores que l'on affecte au device speaker (le haut-parleur, nous décrirons ce device plus tard) pour jouer un son lorsque la balle est trouvée ou perdue:

// Parameters initialization
ball.a = 0.9;
period = 10s;
trouvee = loadwav("found.wav");
perdue  = loadwav("lost.wav");

// Comportement principal
whenever (ball.visible ~ 100ms) {
  headPan  = headPan  + ball.a * camera.xfov * ball.x &
  headTilt = headTilt + ball.a * camera.yfov * ball.y;
};

at (!ball.visible ~ 100ms)
recherche: {
          { headPan'n  = 0.5 smooth:1s &
            headTilt'n = 1   smooth:1s } |
          { headPan'n  = 0.5 sin:period ampli:0.5 &
            headTilt'n = 0.5 cos:period ampli:0.5 }
           };

at (ball.visible) stop recherche;

// Comportement sonore
at (ball.visible ~ 100ms) speaker = trouvée
onleave speaker = perdue;

Vous pouvez aussi utiliser la construction onleave pour regrouper les deux commandes at (ball.visible), mais vous devez alors employer la commande at&, pour placer la commande recherche en tâche de fond (car c'est une commande sans fin et donc at ne rendrait jamais la main).

Le programme précédent fonctionne, est facile à comprendre et à modifier. Pourtant, il est courant en robotique de concevoir les programmes en termes de comportements, exprimés sous forme de machines à états finis, qui sont des graphes d'états reliés entre-eux par des transitions. La figure 6.1 illustre le graphe de comportement du programme de détection de balle, qui est exemple très simple de comportement à deux états.

Figure 6.1. Le graphe de comportement de la détection de balle

Les ellipses représentent les états (dans lequels le robot boucle des actions ou une surveillance) et les flèches les transitions, étiquetées par des conditions. Les rectangles associés aux transitions indiquent certaines actions à exécuter lorsque la transition s'effectue.

La meilleure façon de programmer ce genre de graphe de comportement en URBI est d'utiliser une conjonction des fonctions avec les commandes at et stop pour relier le tout. Tout d'abord, définissons les deux fonctions associées aux deux états du programme de détection de balle:

// Etat de suivi
function suis() {
  whenever (ball.visible) {
    headPan  = headPan + ball.a * camera.xfov * ball.x &
    headTilt = headTilt+ ball.a * camera.yfov * ball.y;
  }
};

// Etat de recherche
function cherche() {
  period = 10s;
  {
    headPan'n  = 0.5 smooth:1s &
    headTilt'n = 1   smooth:1s
  } |
  {
    headPan'n  = 0.5 sin:period ampli:0.5 &
    headTilt'n = 0.5 cos:period ampli:0.5
  }
};

Maintenant, nous pouvons simplement relier les états entre-eux en établissant les transitions avec deux commandes at et en terminant l'état précédent avec des commandes stop:

// Transitions
at (ball.visible ~ 100ms) {
  stop recherche;
  speaker = trouvee;
  suivi: suis();
};

at (!ball.visible ~ 100ms) {
  stop suivi;
  speaker = perdue;
  recherche: cherche();
};

L'avantage de ré-écrire le programme de détection de balle en termes de machine à états finis peut ne pas vous apparaître évident pour l'instant car le programme est très simple. Mais, avec des comportements plus riches de dizaines d'états, chacun avec plusieurs transitions, il s'agit de la façon la plus sure de programmer. Cela rend le code modulaire, clair et facile à modifier.

Les machines à états finis sont une excellente façon de décrire les comportements des robots. Elles ne sont pas parfaites mais c'est pour l'instant la technique la plus employée en robotique. URBI est également capable de décrire des architectures subsumées, hiérarchisées ou réactives et bien d'autres paradigmes.

Les possibilités de geler, arrêter et bloquer les commandes avec URBI forment un outil très puissant pour contrôler l'exécution du comportement. Par exemple, si les transitions, exprimées avec une commande at sont préfixées par une étiquette, comme ceci:

transition_de_suivi:
     at (ball.visible ~ 100ms) {
        stop recherche;
        speaker = trouvee;
        suivi: suis();
     };

transition_de_recherche:
     at (!ball.visible ~ 100ms) {
        stop suivi;
        speaker = perdue;
        recherche: cherche();
     };

Il devient très facile de suspendre temporairement ou de ré-activer une transition de la manière suivante:

freeze transition_de_suivi;
...
unfreeze transition_de_suivi;

D'autrepart, il est possible de bloquer l'exécution d'un état, sans pour autant empêcher les transitions vers lui (attendant silencieusement une autre transition qui fera passer le robot à un autre état):

block recherche;
...
unblock recherche;

En utilisant freeze, block et stop, il est simple de modifier les comportements et ré-affecter les priorités en direct, ce qui est très pratique en robotique. Les possibilités sont innombrables car ces réglages peuvent être contrôlés par des évenements ou par d'autres programmes tournant en parallèle, ou même par un programme de contrôle à distance, ou encore une session telnet.

Vous avez certainement déjà tenté d'évaluer l'une de ces variables binaires:

camera;
[139464] BIN 5347 jpeg 208 160
.................5347 bytes.................

micro;
[139464] BIN 2048 wav 2 16000 16 1
.................2048 bytes.................

URBI préfixe chaque donnée binaire d'un en-tête binaire commençant par le mot-clé BIN, suivi de la taille de la donnée (en octets ou bytes) et un mot-clé indiquant le type de la donnée. Certains paramètres optionnels, comme la taille de l'image, la fréquence d'échantillonnage, le status mono ou stéréo d'un son peuvent suivre. Ensuite, après un retour à la ligne, la donnée binaire en elle-même est retournée (affichée ci-dessus comme une série de points ....), ce qui peut embrouiller un client telnet mais pas un client logiciel URBI ^[7] .

Ce que l'on appelle un client logiciel est un client ou un composant écrit en C++ ou Java, comme décrit dans le chapitre La liburbi en C++. C'est la manière habituelle de gérer les données binaires quand on souhaite traiter un signal avec URBI.

Vous vous en doutez sûrement, affecter une valeur binaire à un device speaker (le haut-parleur) par exemple n'est guère plus complexe que de le lire. Pour jouer un son sur un Aibo, vous pouvez envoyer au serveur une commande comme celle-ci:

speaker = bin 54112 wav 2 16000 16;
..............54112 bytes..............

L'en-tête doit se terminer par un point-virgule, et rien d'autre. Le contenu binaire commence immédiatement après le point-virgule donc nul besoin d'un retour à la ligne supplémentaire.

Bien sûr, une telle affectation binaire ne peut être faite depuis telnet ou URBIRemote, puisque vous souhaitez probablement que le programme envoie le contenu binaire, et que vous n'ayez pas à le saisir vous-même dans le terminal ! (bien qu'il soit possible de faire jouer un son depuis un client telnet).

Ce petit exemple montre une affectation binaire et une lecture binaire en URBI depuis un client telnet. Mais gardez à l'esprit que ceci n'est qu'une démonstration:

mybin = bin 3;ABC
mybin;
[146711] BIN 3
ABC

Vous pouvez ajouter d'autres paramètres après la taille de la donnée binaire, ils seront stockés avec le contenu binaire à l'intérieur de l'en-tête:

mybin = bin 3 hello world 33;ABC
mybin;
[146711] BIN 3 hello world 33
ABC

Ne confondez pas donnée binaire et donnée textuelle (chaîne de caractères). L'exemple précédent est différent de:

mystring = "ABC";
mystring;
[148991] "ABC"

Habituellement, un objet device binaire dispose de plusieurs attributs. Un exemple classique est le device camera d'un Aibo qui fournit les attributs suivants:

Pour le device speaker, en charge de la production sonore de l'Aibo, vous disposez de:

Avec l'objet speaker, il existe également une méthode qui peut être utilisée pour jouer un son directement à partir d'un fichier présent sur la memorystick:

speaker.play("monson.wav");

Autrement, pour éviter d'avoir un accès disque vous ralentissant dans le cas d'accès fréquent, vous pouvez opter pour le stockage en mémoire. Pour cela, utilisez la fonction loadwav:

monbinaire = loadwav("monson.wav");
speaker = monbinaire;

Avec URBI, vous pouvez ajouter des binaires, comme dans le cas de la concaténation de sons. Par exemple, considérons le programme suivant:

son = bin 0;
timeout(10s) loop son = son + micro;
speaker = son;

Ce code enregistrera dix secondes de son provenant du device micro et les stockera dans la variable son, et les jouera suite à l'affectation au device speaker. Ceci montre à quel point il peut être simple de manipuler les tampons binaires avec URBI pour de simples tâches comme la concaténation.

Utiliser URBI depuis un client telnet est trop limité. Vous avez besoin d'envoyer des commandes et de recevoir des messages en utilisant le langage de programmation de votre choix ou, de manière plus générale, vous avez besoin d'interfacer URBI avec d'autres langages.

C'est la raison pour laquelle URBI est un Interface Language: il est bien plus qu'un simple protocole car c'est un langage de script complet agissant comme un protocole. Dans la plupart des applications où intervient l'imagerie informatique ou le traitement sonore, URBI est utilisé conjointement avec C++ ou tout autre langage véloce afin d'effectuer la partie algorithmique. URBI est là pour orchestrer vos comportements, vos boucles action/perception et tout autre élement de haut niveau, avec comme source de décisions la sortie du code rapide de C++, Java ou Matlab.

Qu'est-ce que liburbi? Vous pourriez certes programmer une couche TCP/IP pour C++ ou pour votre langage favori mais c'est relativement trivial et serait fait une fois pour toutes. Voilà pourquoi nous avons créé liburbi. Voici les fonctionnalités que l'on est en droit d'attendre:

Le dernier point est très important et, même si cette approche est très différente de votre façon de programmer, il est essentiel de vous adapter à cette logique-ci de programmation (appelée programmation asynchrone) car elle est la plus adaptée à la robotique. Les robots sont fondamentalement des systèmes asynchrones. On attend des messages de la part du robot pour y réagir ensuite. (ceci est également appelé programmation évenementielle). C'est ce qu'un robot fait la plupart du temps: réagir à des évenements ^[8] .

Ce chapitre est une brève introduction à liburbi. Vous devriez lire la documentation officielle de liburbi sur http://www.gostai.com/docs.php si vous souhaitez une description plus étoffée. Si vous programmez en C++, nous vous conseillons d'utiliser l'architecture UObject décrite plus tard dans ce tutoriel, liburbi n'étant qu'un complément à la nouvelle et prometteuse technologie UObject.

Etendre URBI avec du code écrit en C++, Java ou Matlab qui sera accessible à vos scripts URBI peut être réalisé de deux façons. La première est d'exploiter la liburbi de votre langage préférée (C++/Java/Matlab) pour construire un client URBI. C'est ce que nous allons décrire dans ce chapitre.

La seconde, plus puissante, est de créer un composant UObject qui est associé à un objet C++. Ceci est expliqué au chapitre Créer des composants: l'architecture UObject. L'objet sera accessible comme tout autre objet URBI, partageant ses méthodes et ses attributs. Il s'agit de la manière la plus portable et la plus flexible d'incorporer des fonctionnalités inédites à URBI. Mais commençons par la traditionnelle liburbi. L'un des aspects séduisants de la liburbi est qu'elle est disponible pour de nombreux langages, bien que le jumelage-objet ne soit pas toujours possible et qu'il soit pour l'instant limité au C++. Aborder la programmation avec la liburbi permet déjà de mener à bien certains projets de programmation et, chose intéressante pour les débutants, de s'initier à l'aspect asynchrone de la robotique.

Il existe actuellement une version C++, une version Matlab, une version Java et une version Python de la liburbi si vous désirez contrôler votre robot dans l'un des langages. Il existe également une version OPEN-R, permettant de recompiler un programme pour le faire tourner uniquement sur l'Aibo. Cependant, nous vous déconseillons cette dernière approche au profit des UObject. La seule raison d'être de cette version OPEN-R est qu'elle offre une gestion implicite du multi-threading non bloquant, indisponible dans le système d'exploitation de base de l'Aibo, Aperios.

Nous ne décrirons pas ici la totalité des implémentations de liburbi mais seulement celle dédiée au C++, permettant cependant de s'introduire aux concepts généraux. Les autres versions sont similaires et possèdent chacune leur documentation. Nous supposons dans ce qui suit que vous disposez d'un minimum de connaissances sur le C++. Dans le cas contraire, consultez un rapide tutoriel C++ pour vous familiariser aux concepts de base de ce langage populaire.

Pour commencer, il vous faut pouvoir compiler un programme basé sur la liburbi. Il y a plusieurs façons de s'y prendre selon que vous soyez sous Linux ou Windows, avec un compilateur Borland ou Microsoft, etc. D'une manière générale, il suffit d'inclure liburbi.h et de lier votre code avec la liburbi (-lurbi par exemple pour le compilateur gcc). Consultez la documentation appropriée pour de plus amples détails.

Du côté du code, la première chose à faire est de créer un client qui se connectera à votre robot, disons à l'adresse monrobot.mondomaine.com. Pour cela, vous disposez d'une classe UClient:

UClient* client = new UClient("monrobot.mondomaine.com");

Si vous connaissez l'adresse IP, vous pouvez la mettre à la place.

Vous pouvez également appeler explicitement la classe UClient, en utilisant une fonction de l'espace de nommage urbi:

UClient* client = urbi::connect("monrobot.mondomaine.com");

Bien sûr, vous pouvez créer ainsi autant de clients que vous le désirez.

L'objet UClient possède une méthode send qui fonctionne comme printf:

client->send("motor on;");
for (float val=0; val<=1; val+=0.05)
  client->send("neck'n = %f;wait (%d);", val, 50);

Vous pouvez également utiliser votre objet-client comme un flux si vous préférez cette manière typiquement C++:

client << "headPan = " << 12 << ";";

Il existe également une manière très pratique d'envoyer des blocs entiers de code URBI depuis votre programme C++, grâce à la macro URBI((...)):

URBI((
      headPan = 12,
      echo "salut" | speaker.play("test.wav") & leds = 1
    ));

Le texte brut entre les doubles parenthèses sera envoyé directement au premier client créé par votre programme, par défaut. Cela peut se régler en appelant urbi::connect(...). La première possibilité que nous avons abordée, celle employant la méthode send, est plus appropriée dans la plupart des cas et la macro URBI ne devrait servir qu'à envoyer des scripts d'initialisation en début de programme ou pour prototyper.

Gardez à l'esprit que vous pouvez toujours faire repartir votre robot sur des bases neuves (reboot virtuel) en lui envoyant la commande reset. Cela vous évitera les définitions multiples à chaque nouvelle exécution de votre client. Voilà pourquoi de nombreux programmes principaux débutent par client->send("reset;");.

Pour envoyer une donnée binaire, vous utiliserez la méthode sendBin, au lieu de send:

client->sendBin(soundData, soundDataSize,
                       "speaker = BIN %d raw 2 16000 16 1;",
                       soundDataSize);

Les deux premiers paramètres sont le son lui-même et sa taille. Viens ensuite l'en-tête URBI et enfin les paramètres otpionnels, employant une syntaxe à la printf.

Pour envoyer un son, il existe une méthode spécialisée appelée sendSound, plus pratique et plus efficace:

client->sendSound(sound, "endsound");

Le premier paramètre est une structure USound, décrivant le son à jouer. Le second est une étiquette optionnelle qui sera utilisée par le serveur pour conclure la lecture du son par un l'émission d'un message-système.

Vous pouvez utiliser la fonction convert pour convertir un son vers différents formats.

Avec sendSound, il n'y a pas de limite quant à la taille du tampon sonore, puisqu'il sera découpé en petits morceaux par la bibliothèque. Les données étant copiées par liburbi, le paramètre USound et ses données associées peuvent ensuite être libérées dès que le fonction se termine.

Les étiquettes URBI vont s'avérer très utiles pour la réception des messages du serveur: chaque commande se voit associée à une étiquette (notag par défaut), et cette étiquette est transmise dans tout message originaire de cette commande. La classe UClient gère la réception de ces messages dans un thread indépendant créé par le constructeur, les analysent et remplit une structure UMessage. Les fonctions-callback, nom que l'on donne aux fonctions d'un client qui doivent réagir automatiquement à tout emploi d'une étiquette donnée de la part du serveur, peuvent être référencées avec la méthode setCallback: à chaque fois q'un message avec cette étiquette est envoyée par le serveur, la fonction-callback sera appelée avec la structure UMessage comme argument.

typedef UCallbackAction (*UCallback) (const UMessage &msg);

UCallbackID setCallback (UCallback cb, const char *tag)

Le premier paramètre cb est un pointeur sur la fonction à appeler. La fonction-callback doit retourner la valeur URBI_CONTINUE ou la valeur URBI_REMOVE. Dans ce dernier cas, la fonction sera déréférencée.

La meilleure façon d'apprendre à utiliser les callback est d'étuider les exemples de la documentation:

http://www.gostai.com/doc/en/liburbi-1.0/

Le type de donnée utilisé par la liburbi est décrite ci-dessous:

La classe dérivée USyncClient implémente des méthodes permettant d'obtenir les résultats des commandes URBI de manière synchrone. Vous devez savoir que ces fonctions sont moins efficaces et qu'elles ne fonctionnent pas encore avec la version OPEN-R de la liburbi. Par ailleurs, travailler avec un robot en mode synchrone est à éviter.

double ValeurNeck;
syncClient->syncGetDevice("neck", ValeurNeck);

client->send("camera.resolution = 0; camera.gain = 2;");
int width, height;
client->syncGetImage("camera", myBuffer, myBufferSize,
                            URBI_RGB, URBI_TRANSMIT_JPEG, width, height);

client->syncGetSound("micro", duree, son);

Nous fournissons également quelques fonctions de conversion entre différents formats d'image et de son. L'utilisation des fonctions de conversion d'image est assez directe:

 int convertRGBtoYCrCb (const byte* source, int longsource, byte* dest);
 int convertYCrCbtoRGB (const byte* source, int longsource, byte* dest);
 int convertJPEGtoYCrCb(const byte* source, int longsource, byte* dest, int &taille);
 int convertJPEGtoRGB  (const byte* source, int longsource, byte* dest, int &taille);

Le paramètre taille doit être réglé à la taille du tampon de destination. Au retour de l'appel de la fonction, il contiendra la taille de la donnée en sortie.

Pour convertir entre différents formats sonores, vous pouvez utiliser la fonction convert. Elle prend deux structures USound en paramètres. Les deux formats audio actuellement supportés sont SOUND_RAW et SOUND_WAV, mais le support de formats compressés tels l'Ogg Vorbis ou le MP3 sont prévus. Si l'un des champs est fixé à zéro, la valeur de la source sera utilisée.

URBIimage est un petit programme écrit en C++ avec la liburbi-C++ pour acquérir et afficher des images d'un serveur URBI. URBIimage fait deux choses: il place un callback sur l'étiquette uimg pour recevoir les images, et puis les affiche. Examinons le code. Commençons par l'interface de callback:

Monitor *mon;

/* Notre fonction-callback */
UCallbackAction showImage(const UMessage &msg)
{
  ...
}

Et maintenant, le programme principal :

int main(int argc, char *argv[])
{
  mon = NULL;
  client = new UClient(argv[2]);
  if (client->error() != 0)
    exit(0);

  client->setCallback(showImage, "uimg");

  // Some image initialization
  client->send("camera.resolution = 0;");
  client->send("camera.jpegfactor = 80;");

  // Start the loop
  client->send("loop uimg: camera,");
  urbi::execute();
}

Le code gérant l'image est stocké dans "showImage":

UCallbackAction showImage(const UMessage &msg)
{
  if (msg.type != MESSAGE_DATA || ((UImage)msg).imageFormat == IMAGE_UNKNOWN)
    return URBI_CONTINUE;

  UImage img = (UImage)msg;
  unsigned char buffer[500000];
  int sz = 500000;
  static int tme = 0;

  if (!mon)
    mon = new Monitor(msg.image.width, msg.image.height);

  convertJPEGtoRGB((const byte *) img.data,
                   img.size, (byte *) buffer, sz);

  mon->setImage((bits8 *) buffer, sz);
  return URBI_CONTINUE;
}

Il commence par tester le type du message, et retourne sans rien faire dans le cas où l'on ne se trouve pas face à un message de type BINARYMESSAGE_IMAGE (par exemple, si le callback est réveillé sur un message d'erreur).

Ensuite, la fonction de conversion convertJPEGtoRGB est utilisée pour transformer le tampon d'image en quelquechose d'exploitable par l'objet Monitor, qui reçoit ensuite l'image.

Enfin, URBI_CONTINUE est retourné pour prendre en charge d'éventuels futurs callbacks.

Ce petit programme illustre très bien l'organisation d'un programme basé sur la liburbi: on place des callbacks, on envoie des scripts URBI et on reçoit les callbacks dans des fonctions écrites pour l'occasion. Vous pouvez jeter un oeil au code source GPL d'URBILab, ce dernier étant construit avec la liburbi-C++. Il montre un usage plus poussé de cette méthodologie.