Urbi : un “operating system” de conception française

Comme un ordi­na­teur, un robot a besoin d’un ” OS “, ou Oper­at­ing Sys­tem, qui, à l’im­age de Lin­ux ou Win­dows, va ryth­mer le cœur du système.

Stim­uler la créa­tiv­ité 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­t­ique. C’est ce que pro­pose Gostai avec le sys­tème ” Urbi “. La moti­va­tion pre­mière a été de pro­pos­er un sys­tème unique pour con­trôler des robots très dif­férents, afin d’ap­porter un socle com­mun pour le développe­ment d’ap­pli­ca­tions robo­t­iques 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­pos­er un stan­dard pour le logi­ciel robo­t­ique. Microsoft a lancé une offre de mid­dle­ware robo­t­ique. Des ini­tia­tives académiques comme Player/Stage exis­tent de longue date. Des con­cur­rents appa­rais­sent régulière­ment aux États-Unis, au Japon et en Corée. Cette diver­sité témoigne de l’in­térêt porté par l’in­dus­trie pour les mid­dle­wares robo­t­iques, et de l’en­jeu impor­tant qui y est lié. Il n’y a tou­jours pas aujour­d’hui de stan­dard ” de fait ” pour les robots, mais des pro­grès très impor­tants ont été réalisés.

Cette capac­ité d’adap­ta­tion sup­pose une flex­i­bil­ité et une ouver­ture impor­tante, pour épouser les inter­faces et mor­pholo­gies extrême­ment divers­es que l’on peut retrou­ver dans les robots : robots à roues, robots humanoïdes, robots indus­triels, drones volants, etc.

Une jeune société
Urbi vient du monde de la recherche. Il a été dévelop­pé à par­tir de 2004 par Jean-Christophe Bail­lie (94) au lab­o­ra­toire de robo­t­ique cog­ni­tive de l’EN­S­TA Paris­Tech, avant d’être porté ensuite par la jeune pousse Gostai qu’il a fondée en 2006. La société compte aujour­d’hui une équipe de vingt per­son­nes. Elle a créé une pre­mière fil­iale à Palo Alto en Cal­i­fornie et entre­tient de nom­breux con­tacts au Japon et en Corée. Urbi est aujour­d’hui appliqué à des robots indus­triels, des robots grand pub­lic tels que le Nao ou le Spy­kee, et dans le cadre de recherch­es académiques et de pro­jets européens.

Simple et accessible

Une autre moti­va­tion était de con­stru­ire un out­il de pro­gram­ma­tion sim­ple et acces­si­ble. Ce souci de sim­plic­ité dans la con­cep­tion d’Ur­bi est resté au cours du temps, alors que le sys­tème se dotait de fonc­tion­nal­ités de plus en plus avancées, et reste aujour­d’hui encore une ligne direc­trice impor­tante. Le principe est qu’il doit être pos­si­ble de pren­dre en main un robot en moins de cinq min­utes sur la base de con­nais­sances élé­men­taires en infor­ma­tique. Le but est de per­me­t­tre le développe­ment d’une com­mu­nauté qui ne soit pas réservée à des experts mais ouverte à tous, pour stim­uler la créa­tiv­ité des très nom­breux pas­sion­nés qui s’in­téressent aujour­d’hui à la robo­t­ique dans les clubs, les écoles ou les uni­ver­sités. Nous avons pour cela ouvert un site, urbiforge.org, dédié aux échanges entre util­isa­teurs et per­me­t­tant de met­tre en avant les pro­jets les plus significatifs.

L’approche ” composants ”

Dans un robot, on peut seg­menter les fonc­tions fon­da­men­tales en unités, que l’on appelle ” com­posants “, ou par­fois aus­si ” ser­vices “. Le pre­mier tra­vail d’un OS robo­t­ique est de fournir une base pour décrire ces com­posants. Dans l’u­nivers Urbi, cet out­il s’ap­pelle ” UOb­ject ” et per­met d’écrire en lan­gage C++ ou Java une brique élé­men­taire de fonc­tion­nal­ité, comme, par exem­ple, la syn­thèse de la parole, le cal­cul de l’équili­bre, ou le con­trôle d’un moteur. Pour la plu­part des développeurs, le monde de la ” pro­gram­ma­tion ori­en­tée objet ” (POO) est un monde fam­i­li­er. ” UOb­ject ” s’en inspire pour per­me­t­tre très facile­ment d’in­té­gr­er un objet (au sens de la POO) dans Urbi et de le ren­dre immé­di­ate­ment disponible pour le robot. Cela per­met de réu­tilis­er des mil­liers de com­posants exis­tants très facile­ment et d’éviter de démar­rer sur une table rase. On regroupe habituelle­ment les com­posants en deux caté­gories : d’une part les com­posants bas niveau, ou dri­vers, et d’autre part les com­posants fonc­tion­nels, four­nissant une inter­face vers une fonc­tion­nal­ité par­ti­c­ulière, comme le traite­ment d’im­ages ou de la voix, ou un cal­cul com­plexe. Pour adapter Urbi à un robot par­ti­c­uli­er, il suf­fit de dévelop­per tout ou par­tie des com­posants bas niveau spé­ci­fiques à ce robot pour don­ner accès aux moteurs, caméra et autres cap­teurs. Un ensem­ble de con­ven­tions publiques per­met ensuite de définir la forme et les nom­mages à adopter de telle sorte que le résul­tat soit stan­dard. Il faut égale­ment définir et adapter des fonc­tions dites de haut niveau pour spé­ci­fi­er com­ment avancer, reculer, se posi­tion­ner, etc., pour que le pro­gramme final soit le moins dépen­dant pos­si­ble de la mor­pholo­gie du robot. 

L’orchestration

Une par­ti­tion d’orchestre
D’autres approches priv­ilégient la sou­p­lesse et définis­sent l’orches­tra­tion à l’aide d’un lan­gage de script séparé des com­posants eux-mêmes. Un peu comme une par­ti­tion d’orchestre. On retrou­ve sou­vent pour cette tâche des lan­gages comme Python ou LUA, qui sont égale­ment util­isés dans ce cadre pour l’orches­tra­tion de jeux vidéo, domaine qui partage de nom­breux points com­muns avec la robotique.

Une fois tous ces com­posants défi­nis et inté­grés, il reste une étape impor­tante pour que le robot s’anime : il faut les inter­con­necter et définir leurs rela­tions, leurs liens et dépen­dances. C’est ce qu’on appelle l’orches­tra­tion. L’orches­tra­tion per­met de définir les flux de don­nées d’un com­posant à un autre, les pri­or­ités d’exé­cu­tion, les réac­tions du sys­tème à tel ou tel événe­ment, en un mot : le com­porte­ment du sys­tème. Bien sou­vent, l’orches­tra­tion est réal­isée ” en dur “, de manière figée et directe­ment liée aux com­posants : chaque com­posant con­naît les autres com­posants et s’adresse à eux directe­ment d’une manière décidée dès le départ.

L’ap­proche pro­posée dans Urbi, et qui con­stitue le coeur de son inno­va­tion, est d’u­tilis­er un lan­gage spé­cial­isé pour cette tâche d’orches­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 (ori­en­té objet, dynamique et réflexif, syn­taxe proche de C, etc.), mais il pro­pose deux nou­veautés cru­ciales pour faciliter son tra­vail de chef d’orchestre : le par­al­lélisme et la pro­gram­ma­tion événementielle. 

Un parallélisme omniprésent

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

Le par­al­lélisme est essen­tiel car un robot gère com­muné­ment des dizaines, voire des cen­taines d’ac­tiv­ités en même temps. Bien sûr, nos ordi­na­teurs actuels en sont déjà capa­bles, 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 gran­u­lar­ité du par­al­lélisme. Ce que pro­pose urbis­cript c’est une ges­tion du par­al­lélisme à un niveau plus fin, celui du code d’exé­cu­tion lui-même, ce qui n’est clas­sique­ment pos­si­ble que via des tech­niques telles que la pro­gram­ma­tion par threads. Or, l’ap­proche threads est notoire­ment com­plexe et pose de véri­ta­bles prob­lèmes de mon­tée en com­plex­ité, ce que pro­pose de résoudre urbis­cript en fusion­nant ces con­cepts directe­ment dans le langage.

Par exem­ple, en urbis­cript, pour exé­cuter A et B l’un après l’autre on écrira, comme dans beau­coup de lan­gages, ” A ; B ” et pour les exé­cuter en par­al­lèle, on écrira tout sim­ple­ment ” A & B “.

Le suivi de balle
ball­t­ag : when­ev­er (ball.visible)
{
headYaw.val += camera.xfov * ball.x
& headPitch.val += camera.yfov * ball.y
};
Ces quelques lignes com­pren­nent cer­tains des aspects les plus nota­bles de l’ar­chi­tec­ture Urbi et du lan­gage urbis­cript. Le mot-clé when­ev­er intro­duit une sorte de if con­tinu et événe­men­tiel : à chaque fois que la con­di­tion est véri­fiée, le corps est exé­cuté. Celui-ci est com­posé ici de deux instruc­tions mis­es en par­al­lèle par le con­necteur &. Cha­cune des deux instruc­tions asservit un axe de la tête du robot (en angle) à la posi­tion d’une balle dans l’im­age (en coor­don­nées cartési­ennes). L’UOb­ject cam­era est util­isé pour la con­ver­sion cartésien/angulaire, les UOb­jects headYaw, head­Pitch et cam­era sont des abstrac­tions du matériel. Ils sont util­isés en lec­ture pour l’ac­qui­si­tion (camera.xfov), en écri­t­ure 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 procé­dures telles que le cal­cul de sa posi­tion. Enfin, ball­t­ag 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 gel­er et repren­dre l’exé­cu­tion. Les tags for­ment un out­il puis­sant dans urbis­cript pour con­trôler le flux d’exé­cu­tion de cen­taines de por­tions de code qui fonc­tion­nent en parallèle.

La pro­gram­ma­tion événementielle
La pro­gram­ma­tion événe­men­tielle est égale­ment un fonde­ment de n’im­porte quel pro­gramme robo­t­ique. Un robot réag­it sans cesse à des événe­ments, extérieurs ou internes, et doit gér­er les inter­ac­tions entre toutes ces sol­lic­i­ta­tions… en par­al­lèle. Les deux aspects, événe­men­tiel et par­al­lélisme, se com­plè­tent naturelle­ment. Par exem­ple, en urbis­cript, pour faire une action A quand x est égal à 42, on écrira sim­ple­ment : ” at (x==42) A “.

Décrire des comportements robotiques

La robo­t­ique à bas coût
Déploy­er une appli­ca­tion robo­t­ique com­plexe pose des prob­lèmes pra­tiques : com­ment faire tenir dans un robot à la puis­sance lim­itée les algo­rithmes sophis­tiqués néces­saires pour traiter l’im­age, la voix, le son, la local­i­sa­tion, etc. ? La solu­tion que nous avons imag­inée est de déporter ces algo­rithmes, inté­grés dans UOb­ject, et de les faire fonc­tion­ner sur des serveurs puis­sants, à dis­tance. C’est ce qu’on appelle com­muné­ment le cloud com­put­ing, mais appliquée ici à la robotique.

Le rôle d’Ur­bi et d’ur­bis­cript est donc de fournir des abstrac­tions (com­posants, par­al­lélisme, événe­ments, con­trôle de flux) afin de sim­pli­fi­er la tâche de l’ingénieur ou du chercheur lorsqu’il écrit des pro­grammes pour des robots.

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

On peut aller encore plus loin et, au delà des abstrac­tions fonc­tion­nelles, pro­pos­er des abstrac­tions struc­turelles : com­ment décrire un com­porte­ment de robot ? Le sujet est très vaste et fait l’ob­jet de thèmes de recherch­es très var­iés depuis de nom­breuses années. Par­mi les nom­breuses approches exis­tantes, celle que l’on a retenue est celle des ” graphes d’é­tats finis hiérar­chiques “, une tech­nique clas­sique par ailleurs pour décrire le fonc­tion­nement d’un sys­tème com­plexe, et qui est sou­vent util­isée en robo­t­ique. Gostai Stu­dio est une appli­ca­tion conçue pour per­me­t­tre de créer et de manip­uler ces graphes. 

Demain l’open source

Urbi se veut donc une ten­ta­tive de fournir un ensem­ble com­plet pour les besoins logi­ciels de la robo­t­ique : une archi­tec­ture de com­posants, un sys­tème d’orches­tra­tion, des out­ils de développe­ment graphiques et une plate­forme d’exé­cu­tion type cloud com­put­ing pour les besoins hors embar­qué. Le pre­mier niveau de l’éd­i­fice, les com­posants et leur orches­tra­tion, cor­re­spond glob­ale­ment à un Oper­at­ing Sys­tem robo­t­ique. Or, aujour­d’hui, à l’heure d’An­droid et de Mae­mo, l’in­dus­trie exige de l’ou­ver­ture pour les com­posants clefs des sys­tèmes embar­qués, ce qui est com­préhen­si­ble, en par­ti­c­uli­er pour un OS, car il s’ag­it d’une par­tie cen­trale et vitale du système.

Un robot gère des cen­taines d’ac­tiv­ités en même temps

Dans cet esprit, nous avons annon­cé le pas­sage d’Ur­bi en open source (licence com­pat­i­ble GPL), ce qui va per­me­t­tre d’asseoir l’ensem­ble des solu­tions pro­posées par Gostai sur une base ouverte, pérenne et favor­able au développe­ment d’une com­mu­nauté. Alors que les États-Unis, le Japon et la Corée pré­par­ent cha­cun leur pro­pre OS open source pour les robots, Urbi se posi­tionne aujour­d’hui comme une alter­na­tive européenne sur un marché qui sera prob­a­ble­ment demain un enjeu clé pour l’industrie.

---

Articles similaires :

Alca­tel et le Viêt­nam, une stratégie payante de parte­nar­i­at durable en Asie Le dirigeant con­sulte, le con­sul­tant ne dirige pas La con­duite du sys­tème édu­catif : La LOLF et le pilotage académique Un étranger sur le toit Hypothèque Le droit d’auteur : l’idéologie et le système