Urbi : un « operating system » de conception française

Les défis du logi­ciel sont encore plus grands que ceux du maté­riel, même s’ils sont moins spec­ta­cu­laires ou média­tiques. Les robots sont bien autre chose qu’un ordi­na­teur » auto-mobile « . Ils sont com­po­sites, assem­blages de com­po­sants maté­riels ou logi­ciels d’o­ri­gines diverses qu’il faut inter­con­nec­ter et asser­vir. Un monde com­plexe d’in­te­rac­tions et de dépen­dances dont la par­ti­tion est mul­tiple, mais dont l’en­semble, cor­rec­te­ment orches­tré, abou­tit au com­por­te­ment glo­bal du robot.

Comme un ordi­na­teur, un robot a besoin d’un » OS « , ou Ope­ra­ting Sys­tem, qui, à l’i­mage de Linux ou Win­dows, va ryth­mer le cœur du système.

Sti­mu­ler la créa­ti­vi­té des très nom­breux passionnés

Mais il a besoin d’un OS bien spé­cial, ouvert et adap­té aux besoins de la robo­tique. C’est ce que pro­pose Gos­tai avec le sys­tème » Urbi « . La moti­va­tion pre­mière a été de pro­po­ser un sys­tème unique pour contrô­ler des robots très dif­fé­rents, afin d’ap­por­ter un socle com­mun pour le déve­lop­pe­ment d’ap­pli­ca­tions robo­tiques géné­riques, un peu sur le modèle des PC dans l’informatique.

REPÈRES
Urbi n’est pas le seul pro­jet qui cherche à pro­po­ser un stan­dard pour le logi­ciel robo­tique. Micro­soft a lan­cé une offre de midd­le­ware robo­tique. Des ini­tia­tives aca­dé­miques comme Player/Stage existent de longue date. Des concur­rents appa­raissent régu­liè­re­ment aux États-Unis, au Japon et en Corée. Cette diver­si­té témoigne de l’in­té­rêt por­té par l’in­dus­trie pour les midd­le­wares robo­tiques, et de l’en­jeu impor­tant qui y est lié. Il n’y a tou­jours pas aujourd’­hui de stan­dard » de fait » pour les robots, mais des pro­grès très impor­tants ont été réalisés.

Cette capa­ci­té d’a­dap­ta­tion sup­pose une flexi­bi­li­té et une ouver­ture impor­tante, pour épou­ser les inter­faces et mor­pho­lo­gies extrê­me­ment diverses que l’on peut retrou­ver dans les robots : robots à roues, robots huma­noïdes, robots indus­triels, drones volants, etc.

Une jeune société
Urbi vient du monde de la recherche. Il a été déve­lop­pé à par­tir de 2004 par Jean-Chris­tophe Baillie (94) au labo­ra­toire de robo­tique cog­ni­tive de l’ENS­TA Paris­Tech, avant d’être por­té ensuite par la jeune pousse Gos­tai qu’il a fon­dée en 2006. La socié­té compte aujourd’­hui une équipe de vingt per­sonnes. Elle a créé une pre­mière filiale à Palo Alto en Cali­for­nie et entre­tient de nom­breux contacts au Japon et en Corée. Urbi est aujourd’­hui appli­qué à des robots indus­triels, des robots grand public tels que le Nao ou le Spy­kee, et dans le cadre de recherches aca­dé­miques et de pro­jets européens.

Simple et accessible

Une autre moti­va­tion était de construire un outil de pro­gram­ma­tion simple et acces­sible. Ce sou­ci de sim­pli­ci­té dans la concep­tion d’Ur­bi est res­té au cours du temps, alors que le sys­tème se dotait de fonc­tion­na­li­tés de plus en plus avan­cées, et reste aujourd’­hui encore une ligne direc­trice impor­tante. Le prin­cipe est qu’il doit être pos­sible de prendre en main un robot en moins de cinq minutes sur la base de connais­sances élé­men­taires en infor­ma­tique. Le but est de per­mettre le déve­lop­pe­ment d’une com­mu­nau­té qui ne soit pas réser­vée à des experts mais ouverte à tous, pour sti­mu­ler la créa­ti­vi­té des très nom­breux pas­sion­nés qui s’in­té­ressent aujourd’­hui à la robo­tique dans les clubs, les écoles ou les uni­ver­si­tés. Nous avons pour cela ouvert un site, urbiforge.org, dédié aux échanges entre uti­li­sa­teurs et per­met­tant de mettre en avant les pro­jets les plus significatifs.

L’approche » composants »

Dans un robot, on peut seg­men­ter les fonc­tions fon­da­men­tales en uni­tés, que l’on appelle » com­po­sants « , ou par­fois aus­si » ser­vices « . Le pre­mier tra­vail d’un OS robo­tique est de four­nir une base pour décrire ces com­po­sants. Dans l’u­ni­vers Urbi, cet outil s’ap­pelle » UOb­ject » et per­met d’é­crire en lan­gage C++ ou Java une brique élé­men­taire de fonc­tion­na­li­té, comme, par exemple, la syn­thèse de la parole, le cal­cul de l’é­qui­libre, ou le contrôle d’un moteur. Pour la plu­part des déve­lop­peurs, le monde de la » pro­gram­ma­tion orien­tée objet » (POO) est un monde fami­lier. » UOb­ject » s’en ins­pire pour per­mettre très faci­le­ment d’in­té­grer un objet (au sens de la POO) dans Urbi et de le rendre immé­dia­te­ment dis­po­nible pour le robot. Cela per­met de réuti­li­ser des mil­liers de com­po­sants exis­tants très faci­le­ment et d’é­vi­ter de démar­rer sur une table rase. On regroupe habi­tuel­le­ment les com­po­sants en deux caté­go­ries : d’une part les com­po­sants bas niveau, ou dri­vers, et d’autre part les com­po­sants fonc­tion­nels, four­nis­sant une inter­face vers une fonc­tion­na­li­té par­ti­cu­lière, comme le trai­te­ment d’i­mages ou de la voix, ou un cal­cul com­plexe. Pour adap­ter Urbi à un robot par­ti­cu­lier, il suf­fit de déve­lop­per tout ou par­tie des com­po­sants bas niveau spé­ci­fiques à ce robot pour don­ner accès aux moteurs, camé­ra et autres cap­teurs. Un ensemble de conven­tions publiques per­met ensuite de défi­nir la forme et les nom­mages à adop­ter de telle sorte que le résul­tat soit stan­dard. Il faut éga­le­ment défi­nir et adap­ter des fonc­tions dites de haut niveau pour spé­ci­fier com­ment avan­cer, recu­ler, se posi­tion­ner, etc., pour que le pro­gramme final soit le moins dépen­dant pos­sible de la mor­pho­lo­gie du robot.

L’orchestration

Une par­ti­tion d’orchestre
D’autres approches pri­vi­lé­gient la sou­plesse et défi­nissent l’or­ches­tra­tion à l’aide d’un lan­gage de script sépa­ré des com­po­sants eux-mêmes. Un peu comme une par­ti­tion d’or­chestre. On retrouve sou­vent pour cette tâche des lan­gages comme Python ou LUA, qui sont éga­le­ment uti­li­sés dans ce cadre pour l’or­ches­tra­tion de jeux vidéo, domaine qui par­tage de nom­breux points com­muns avec la robotique.

Une fois tous ces com­po­sants défi­nis et inté­grés, il reste une étape impor­tante pour que le robot s’a­nime : il faut les inter­con­nec­ter et défi­nir leurs rela­tions, leurs liens et dépen­dances. C’est ce qu’on appelle l’or­ches­tra­tion. L’or­ches­tra­tion per­met de défi­nir les flux de don­nées d’un com­po­sant à un autre, les prio­ri­tés d’exé­cu­tion, les réac­tions du sys­tème à tel ou tel évé­ne­ment, en un mot : le com­por­te­ment du sys­tème. Bien sou­vent, l’or­ches­tra­tion est réa­li­sée » en dur « , de manière figée et direc­te­ment liée aux com­po­sants : chaque com­po­sant connaît les autres com­po­sants et s’a­dresse à eux direc­te­ment d’une manière déci­dée dès le départ.

L’ap­proche pro­po­sée dans Urbi, et qui consti­tue le coeur de son inno­va­tion, est d’u­ti­li­ser un lan­gage spé­cia­li­sé pour cette tâche d’or­ches­tra­tion : le lan­gage urbis­cript. Ce lan­gage est sem­blable à ses véné­rables col­lègues sur de nom­breux points (orien­té objet, dyna­mique et réflexif, syn­taxe proche de C, etc.), mais il pro­pose deux nou­veau­tés cru­ciales pour faci­li­ter son tra­vail de chef d’or­chestre : le paral­lé­lisme et la pro­gram­ma­tion événementielle.

Un parallélisme omniprésent

L’or­ches­tra­tion est néces­saire pour que le robot s’anime

Le paral­lé­lisme est essen­tiel car un robot gère com­mu­né­ment des dizaines, voire des cen­taines d’ac­ti­vi­tés en même temps. Bien sûr, nos ordi­na­teurs actuels en sont déjà capables, mais ils le font en géné­ral au niveau des appli­ca­tions elles-mêmes. La dis­tinc­tion est liée ici à la finesse dans le niveau de gra­nu­la­ri­té du paral­lé­lisme. Ce que pro­pose urbis­cript c’est une ges­tion du paral­lé­lisme à un niveau plus fin, celui du code d’exé­cu­tion lui-même, ce qui n’est clas­si­que­ment pos­sible que via des tech­niques telles que la pro­gram­ma­tion par threads. Or, l’ap­proche threads est notoi­re­ment com­plexe et pose de véri­tables pro­blèmes de mon­tée en com­plexi­té, ce que pro­pose de résoudre urbis­cript en fusion­nant ces concepts direc­te­ment dans le langage.

Par exemple, en urbis­cript, pour exé­cu­ter A et B l’un après l’autre on écri­ra, comme dans beau­coup de lan­gages, » A ; B » et pour les exé­cu­ter en paral­lèle, on écri­ra tout sim­ple­ment » A & B « .

Le sui­vi de balle
ball­tag : whe­ne­ver (ball.visible)
{
headYaw.val += camera.xfov * ball.x
& headPitch.val += camera.yfov * ball.y
};
Ces quelques lignes com­prennent cer­tains des aspects les plus notables de l’ar­chi­tec­ture Urbi et du lan­gage urbis­cript. Le mot-clé whe­ne­ver intro­duit une sorte de if conti­nu et évé­ne­men­tiel : à chaque fois que la condi­tion est véri­fiée, le corps est exé­cu­té. Celui-ci est com­po­sé ici de deux ins­truc­tions mises en paral­lèle par le connec­teur &. Cha­cune des deux ins­truc­tions asser­vit un axe de la tête du robot (en angle) à la posi­tion d’une balle dans l’i­mage (en coor­don­nées car­té­siennes). L’UOb­ject came­ra est uti­li­sé pour la conver­sion cartésien/angulaire, les UOb­jects hea­dYaw, head­Pitch et came­ra sont des abs­trac­tions du maté­riel. Ils sont uti­li­sés en lec­ture pour l’ac­qui­si­tion (camera.xfov), en écri­ture pour le mou­ve­ment (headYaw.val). L’UOb­ject ball est algo­rith­mique ; il four­nit des évé­ne­ments (tels que la détec­tion de la balle) et des pro­cé­dures telles que le cal­cul de sa posi­tion. Enfin, ball­tag est ici un tag qui per­met à tout moment d’in­ter­rompre l’exé­cu­tion du code qui le suit par un appel du type : » balltag.stop » ou » balltag.freeze/ unfreeze » pour geler et reprendre l’exé­cu­tion. Les tags forment un outil puis­sant dans urbis­cript pour contrô­ler le flux d’exé­cu­tion de cen­taines de por­tions de code qui fonc­tionnent en parallèle.

La pro­gram­ma­tion événementielle
La pro­gram­ma­tion évé­ne­men­tielle est éga­le­ment un fon­de­ment de n’im­porte quel pro­gramme robo­tique. Un robot réagit sans cesse à des évé­ne­ments, exté­rieurs ou internes, et doit gérer les inter­ac­tions entre toutes ces sol­li­ci­ta­tions… en paral­lèle. Les deux aspects, évé­ne­men­tiel et paral­lé­lisme, se com­plètent natu­rel­le­ment. Par exemple, en urbis­cript, pour faire une action A quand x est égal à 42, on écri­ra sim­ple­ment : » at (x==42) A « .

Décrire des comportements robotiques

La robo­tique à bas coût
Déployer une appli­ca­tion robo­tique com­plexe pose des pro­blèmes pra­tiques : com­ment faire tenir dans un robot à la puis­sance limi­tée les algo­rithmes sophis­ti­qués néces­saires pour trai­ter l’i­mage, la voix, le son, la loca­li­sa­tion, etc. ? La solu­tion que nous avons ima­gi­née est de dépor­ter ces algo­rithmes, inté­grés dans UOb­ject, et de les faire fonc­tion­ner sur des ser­veurs puis­sants, à dis­tance. C’est ce qu’on appelle com­mu­né­ment le cloud com­pu­ting, mais appli­quée ici à la robotique.

Le rôle d’Ur­bi et d’ur­bis­cript est donc de four­nir des abs­trac­tions (com­po­sants, paral­lé­lisme, évé­ne­ments, contrôle de flux) afin de sim­pli­fier la tâche de l’in­gé­nieur ou du cher­cheur lors­qu’il écrit des pro­grammes pour des robots.

Un robot réagit sans cesse à des évé­ne­ments, exté­rieurs ou internes

On peut aller encore plus loin et, au delà des abs­trac­tions fonc­tion­nelles, pro­po­ser des abs­trac­tions struc­tu­relles : com­ment décrire un com­por­te­ment de robot ? Le sujet est très vaste et fait l’ob­jet de thèmes de recherches très variés depuis de nom­breuses années. Par­mi les nom­breuses approches exis­tantes, celle que l’on a rete­nue est celle des » graphes d’é­tats finis hié­rar­chiques « , une tech­nique clas­sique par ailleurs pour décrire le fonc­tion­ne­ment d’un sys­tème com­plexe, et qui est sou­vent uti­li­sée en robo­tique. Gos­tai Stu­dio est une appli­ca­tion conçue pour per­mettre de créer et de mani­pu­ler ces graphes.

Demain l’open source

Urbi se veut donc une ten­ta­tive de four­nir un ensemble com­plet pour les besoins logi­ciels de la robo­tique : une archi­tec­ture de com­po­sants, un sys­tème d’or­ches­tra­tion, des outils de déve­lop­pe­ment gra­phiques et une pla­te­forme d’exé­cu­tion type cloud com­pu­ting pour les besoins hors embar­qué. Le pre­mier niveau de l’é­di­fice, les com­po­sants et leur orches­tra­tion, cor­res­pond glo­ba­le­ment à un Ope­ra­ting Sys­tem robo­tique. Or, aujourd’­hui, à l’heure d’An­droid et de Mae­mo, l’in­dus­trie exige de l’ou­ver­ture pour les com­po­sants clefs des sys­tèmes embar­qués, ce qui est com­pré­hen­sible, en par­ti­cu­lier pour un OS, car il s’a­git d’une par­tie cen­trale et vitale du système.

Un robot gère des cen­taines d’ac­ti­vi­tés en même temps

Dans cet esprit, nous avons annon­cé le pas­sage d’Ur­bi en open source (licence com­pa­tible GPL), ce qui va per­mettre d’as­seoir l’en­semble des solu­tions pro­po­sées par Gos­tai sur une base ouverte, pérenne et favo­rable au déve­lop­pe­ment d’une com­mu­nau­té. Alors que les États-Unis, le Japon et la Corée pré­parent cha­cun leur propre OS open source pour les robots, Urbi se posi­tionne aujourd’­hui comme une alter­na­tive euro­péenne sur un mar­ché qui sera pro­ba­ble­ment demain un enjeu clé pour l’industrie.

---

Articles similaires :

Apprendre avec les robots : futile ou indispensable ? Robots aériens : auto­no­mie et sécu­ri­té des drones Les robots compagnons,une double oppor­tu­ni­té à saisir Nao : un robot huma­noïde à la française La robo­tique va-t-elle chan­ger le monde ?