Programació i simulació del robot mòbil Guardian mitjançant ROS i Gazebo

Projecte Final de Carrera Programació i simulació del robot mòbil Guardian mitjançant ROS i Gazebo Marc Benetó Juan 20 de Setembre del 2011 Universitat Politècnica de València Escola Tècnica Superior d’Enginyeria Informàtica Codirector a l'empresa: Roberto Guzmán Diana Codirector a l'ETSINF: Ángel Rodas Jordà Índex 1 Introducció. Motivació. Objectius. 1 2 El robot mòbil Guardian 3 2.1 Vistageneral ............................... 3 2.2 Característiques tècniques . . . . . . . . . . . . . . . . . . . . . . . . 4 2.3 Partsprincipals.............................. 5 2.4 Aplicacions ................................ 8 3 Fonaments de robòtica mòbil 9 3.1 Cinemàtica diferencial . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.1.1 Cinemàtica directa per a robots diferencials . . . . . . . . . . 11 3.1.2 Cinemàtica inversa per a robots diferencials . . . . . . . . . . 12 3.2 Control .................................. 14 3.2.1 El control proporcional (P) . . . . . . . . . . . . . . . . . . . . 14 3.2.2 El control PID. Cas d’estudi: Control en bucle tancat respecte alavelocitat............................ 15 3.3 Odometria................................. 17 3.4 Navegacióautònoma ........................... 18 3.4.1 MCL................................ 19 3.4.2 SLAM............................... 19 4 ROS: Un framework de codi obert per a la robòtica 21 4.1 Objectius ................................. 21 4.2 Arquitectura................................ 24 4.3 Conceptesisintaxis............................ 25 4.3.1 Sistemadefitxers......................... 25 4.3.2 Còmput .............................. 28 4.3.3 Altnivell ............................. 33 5 Simulació 37 5.1 Introducció ................................ 37 5.2 Gazebo................................... 38 5.2.1 OGRE............................... 39 5.2.2 ODE................................ 41 i Índex 6 Implementació 43 6.1 Instal·lació................................ 43 6.1.1 Instal·lació independent des dels repositoris d’Ubuntu . . . . 43 6.1.2 Instal·lació des dels respositoris junt al software d’un robot . 44 6.1.3 Instal·lació des del codi font . . . . . . . . . . . . . . . . . . 45 6.2 ModelURDF ............................... 46 6.3 Programació del controlador P en temps real . . . . . . . . . . . . . . 50 6.3.1 La pila pr2_mechanism . . . . . . . . . . . . . . . . . . . . . 51 6.3.2 Programant el nostre controlador . . . . . . . . . . . . . . . . 54 6.4 Teleoperació................................ 59 6.4.1 Teclat ............................... 59 6.4.2 Joystick .............................. 59 6.5 Afegint altres dispositius al nostre model URDF . . . . . . . . . . . . 61 6.5.1 Làser................................ 61 6.5.2 IMU ................................ 62 6.5.3 Càmera .............................. 63 6.5.4 Altresplugins .......................... 63 6.6 Integració amb la Navigation Stack . . . . . . . . . . . . . . . . . . . 64 6.6.1 Odometria............................. 65 6.6.2 Transformacions estàtiques . . . . . . . . . . . . . . . . . . . . 66 6.7 Configurant la Navigation Stack . . . . . . . . . . . . . . . . . . . . . 67 6.7.1 El paquet move_base . . . . . . . . . . . . . . . . . . . . . . . 67 6.7.2 Tipus de navegació . . . . . . . . . . . . . . . . . . . . . . . . 70 6.8 Creació de móns personalitzats . . . . . . . . . . . . . . . . . . . . . 72 7 Descripció del treball realitzat 75 7.1 Arquitectura................................ 75 7.1.1 Nivelldegraf ........................... 75 7.1.2 Nivell de sistema de fitxers . . . . . . . . . . . . . . . . . . . . 77 7.2 Interacció amb la comunitat de software lliure . . . . . . . . . . . . . 78 7.3 Exemples i guies d’utilització . . . . . . . . . . . . . . . . . . . . . . 80 7.3.1 Teleoperació mitjançant teclat . . . . . . . . . . . . . . . . . . 81 7.3.2 Teleoperació mitjaçant joystick . . . . . . . . . . . . . . . . . 82 7.3.3 Navegació autònoma utilitzant posicionament local . . . . . . 83 7.3.4 Navegació autònoma utilitzant posicionament AMCL . . . . . 85 7.3.5 Navegació autònoma utilitzant posicionament SLAM . . . . . 86 8 Conclusions i treballs futurs 89 Annexes 91 ii 1 Introducció. Motivació. Objectius. La robòtica és la branca de la tecnologia encarregada del disseny i construcció de màquines capaces de realitzar tasques repetitives, tasques d’una gran precisió, tasques perilloses per a un ésser humà o simplement, tasques irrealitzables sense l’ajuda d’estes. Aquesta àrea de la ciència combina disciplines tant variades com la informàtica, l’electrònica, la mecànica, la intel·ligència artificial i l’enginyeria de control. No és d’estranyar que, amb l’avanç que ha experimentat en els últims anys la informàtica, la robòtica haja deixat de ser una raresa per començar a convertir-se en quelcom habitual en les nostres vides. La cada volta major capacitat de càlcul i la miniaturització dels elements informàtics fa possible la construcció de robots per a tots els àmbits. Podem trobar robots des de fàbriques on es duen a terme els més complicats processos industrials fins a l’interior de les nostres cases fent la neteja. Aprofitant l’oportunitat que ofereix la Universitat Politècnica de València de realitzar pràctiques en empreses amb les quals mantenen convenis, vaig poder realitzar este projecte a l’empresa Robotnik Automation SLL de la mateixa ciutat. Esta empresa, capdavantera en l’estat en l’àmbit de la robòtica, es dedica al desenvolupament de productes i prestació de serveis de enginyeria i I+D en el sector de la robòtica i l’automàtica. Com a becari de l’àrea de I+D les meues tasques foren l’aprenentatge d’un nou framework per a la robòtica (ROS) i el posterior ús per a la programació i simulació del robot mòbil Guardian en este llenguatge. ROS, sigles de Robot Operating System, és un framework que ens proporciona serveis estàndard dels sistemes operatius com l’abstracció de hardware, el control de dispositius a baix nivell, la implementació prèvia de funcions comuns, la comunicació entre processos i la gestió de paquets. Està basat en una arquitectura de graf, on el processament té lloc als nodes. Estos poden rebre, publicar i multiplexar sensors, controls, estats, planificacions, actuacions i altres missatges. Es tracta d’un llenguatge molt útil i ràpid donada la seua estructura modular, que fa estalviar molt de codi donat que podem re-utilitzar el codi que el propi llenguatge ens ofereix a les seues “llibreries”, des d’interfícies per als sensors fins a complexes algorismes de navegació autònoma. No obstant això, cal dir que la corba d’aprenentatge és bastant pronunciada i exigeix un nivell avançant en C++ o Python (no em d’oblidar que ROS és bàsicament una interfície que s’executa sobre un d’estos dos llenguatges). Per últim cal ressenyar que este framework és software lliure i està enfocat per a treballar sobre GNU/Linux, més concretament amb la distribució Ubuntu, conta amb una gran comunitat que el suporta darrere i les pàgines de col·laboració amb 1 CAPÍTOL 1. INTRODUCCIÓ. MOTIVACIÓ. OBJECTIUS. ella segueixen molt la filosofia 2.0, el que facilita i ajuda molt a la difusió d’este llenguatge i pel que suposem que és un ferm candidats a convertir-se en un dels estàndards de facto per al futur. Una vegada amb el que és el llenguatge ROS clar, podem definir els objectius del projecte que ens ocupa: •Aprenentatge i reforç dels coneixements adquirits en la carrera sobre robòtica mòbil. •Aprenentatge d’un nou framework: ROS. •Programació i simulació del robot mòbil Guardian en este últim llenguatge. Esta memòria està composada de set capítols. En ells s’expliquen els conceptes utilitzats per al desenvolupament final del projecte així com la implementació d’aquest. Anem a fer una vista general del que la memòria ens ofereix, oferint un xicotet resum de cada capítol. El primer capítol amb el que ens trobem, deixant de banda l’actual és l’anomenat “El robot mòbil Guardian”. En aquest capítol s’estudia el robot que més tard modelarem i simularem i que al cap i a la fi serà un dels principals eixos del nostre projecte. Veurem les seues característiques tècniques, parts principals i les aplicacions. Més tard s’oferiran uns conceptes bàsics al capítol “Fonaments de robòtica mòbil”. En este, s’explicaran principis bàsics de cinemàtica diferencial, control, odometria i navegació autònoma, tots ells sense entrar en cap detall d’implementacions. Una vegada estudiats els fonaments del robot, ens centrarem en el framework que anem a utilitzar per a la programació i simulació d’este: ROS. Estudiarem els objectius amb els que fou creat, l’arquitectura que segueix i els conceptes bàsics des dels diferents nivells que l’integren. A continuació, estudiarem la simulació en el món de la robòtica i quins avantatges ens ofereix, a més, ens centrarem en l’estudi del simulador a utilitzar: Gazebo. Una vegada estudiat l’estat de l’art referent al nostre projecte ens centrarem en la implementació del treball. Ací és on es troba reflexada la major part de la feina realitzada. En aquest capitol es detallen minuciosament els passos seguits per dur a terme el projecte, des de la instal·lació de ROS fins a la creació de mons virtuals. Més endavant, en el capitol "Descripció del treball", explicarem l’arquitectura del sistema resultant, com ha sigut la nostra interacció amb la comunitat de software lliure i disposarem d’exemples i guies d’utilització. Per acabar, oferirem les nostres conclusions del projecte i els possibles treballs futurs que poden sorgir en base a aquest 2 2 El robot mòbil Guardian A esta secció anem a estudiar el robot mòbil sobre el qual es centra el nostre treball, la plataforma Guardian de l’empresa Robotnik Automation SLL. Anem a centrar-nos en les característiques tècniques del robot per més tard estudiar les seues possibles aplicacions. No obstant, abans que res, anem a fer una vista general del que és aquest robot i que ens pot oferir. 2.1 Vista general En els últims anys, han proliferat un bon nombre de plataformes mòbils, gran part d’elles dissenyades per a utilitzar-se en investigació i desenvolupament. Els diferents fabricant, com Mobile Robots Inc,Robosoft,Kteam, o la pròpia Robotnik, han introduït al mercat gran varietat de plataformes mòbils amb les que poden investigar en robòtica mòbil, navegació, localització, SLAM, etc, i que serveixen al mateix temps per al desenvolupament d’aplicacions en el cresquent sector de la robòtica de serveis. El robot Guardian pertany a este tipus de plataformes, i s’ha desenvolupat amb l’objectiu de proporcionar una plataforma d’interior i exterior que superarà la mobilitat del seus competidors naturals, tant en entorns urbans com en entorns naturals i amb prestacions que permitisquen la seua utilització en el producte final i no només en el prototipus demostrador. Guardian és una plataforma mòbil modular molt adient per a tasques d’investigació, seguretat i inspecció, gràcies a que disposa d’alta mobilitat, la qual cosa li permet actuar en llocs de difícil accés per a altres tipus de plataformes (escales, terrenys pedregosos, forts desnivells...). Permet la integració de múltiples sensors (laser indoor, outdoor, càmeres, capçals de visió estèreo, unitat de medició inercial, GPS...) i accionaments (braços robotitzats modulars, unitats pan-tilt...). Guardian ofereix un espai suficient en el seu interior per a incorporar dos ordinadors. Açò fa que siga possible un major processament a bord per a visió, telemetria làser, DGPS... La plataforma té un pes de 85Kg que permet la carrega de fins a 100Kg addicionals en forma d’equipament. També s’ha de destacar que no requereix d’un equipament extern voluminós, només d’un maletí de control. 3 CAPÍTOL 2. EL ROBOT MÒBIL GUARDIAN A continuació disposem de dos fotos amb diferents versions d’esta plataforma mòbil. Com vegem l’estructura és sempre la mateixa, variant això si, la mida d’esta, mentre que els sensors i diferents elements que l’integren poden variar depenent de l’aplicació per a la que estiguen dissenyats. Figura 2.1: Diferents versions de la plataforma mòbil Guardian. 2.2 Característiques tècniques A continuació presentem dos taules resum de les característiques tècniques més importants del Guardian, una dedicada a les característiques mecàniques i altra a les de control del robot. Hem de tindre en compte que cada robot fabricat és diferent a l’anterior ja que s’adapta al màxim a l’aplicació per a la que ha sigut dissenyat, per açò volem remarcar que estes taules només són orientatives. Mides 1050 x 600 x 400 mm Pes 85 Kg Capacitat de càrrega 50-100 Kg Velocitat 1,25 m/s Tipus de protecció IP54 / Opcions IP65 i IP66 Sistema de tracció Orugues combinades amb rodes Motorització 2 eixos, control diferencial (skid) 2 x 1000W Bateries 2x12V, 50 Ah Autonomia 3h de funcionament normal Rang de temperatures Dels -10ºals +50ºC Màxima pendent 45º Taula 2.1: Característiques mecàniques del robot Guardian 4 2.3. PARTS PRINCIPALS Sistema modular Permet muntar combinacions d’un o dos manipuladors. Permet la connexió de qualsevol tipus de sensorització. Ports USB i RS-232 a l’exterior. Controlador Versió bàsica: Radio controlada. Versió completa: PC empotrat amb el sistema operatiu LinuxRT. Drivers per a Player/Stage iROS. Taula 2.2: Característiques de control del robot Guardian 2.3 Parts principals En la secció que ara ens ocupa anem a estudiar les diferents parts que conformen el robot. Si ens fixem en la figura de més avall, el robot disposa de quatre elements clarament diferenciats, estos són: el bastidor principal (main chassis), els dos accionaments laterals -dret i esquerre- (lateral drive side), la coberta davantera (front cover) i la coberta posterior (back cover). Figura 2.2: Parts principals del robot Guardian. Robotnik Automation SLL © Anem a vore amb un poc més de detall estes quatre parts principals: •Bastidor principal: Ací dins estan allotjats tots els components elèctrics: Motors, controladores, ordinadors (depenent del model), receptors de ràdio... •Accionaments laterals: Situats tant a l’esquerra com a la dreta del robot, és on estan col·locats els elements que mouen el robot, és a dir, les orugues i les rodes. Esta part del robot és la que més elements mecànics conté i per això necessitarà un cert manteniment. 5 CAPÍTOL 2. EL ROBOT MÒBIL GUARDIAN •Cobertes (davantera i posterior): Permet accedir a l’interior del robot on es troben molts dels elements de control del robot com la controladora AX3500 o l’ordinador d’abord. Com vegem els accionaments laterals són la part mecànica més complexa del robot, anem a veure’ls més detalladament: Figura 2.3: Accionaments laterals del robot. Robotnik Automation SLL ©. •Politja (pulley): Transmet el moviment de les corretges de transmissió a l’eix on estan fixades. És necessari revisar l’estat de les politges una vegada a l’any. •Corretges de transmissió (drive belt): Transmet el moviment des dels motors. Com les politges, és necessari comprovar l’estat de desgast una vegada a l’any. •Corretges/orugues (belt): Estes corretges/orugues tenen dues funcions. Primerament, la de transmetre el moviment entre les politges anteriors i posteriors. En segon lloc, fent ús dels “tacos” externs que incorporen poden evitar obstacles així com pujar escales. És necessari comprovar el nivell de debilitació i consistència dels “tacos” una vegada a l’any com a mínim. •Ajustadors de la tensió de les corretges (belt tension adjusters): Estos elements mantenen la tensió de les corretges. Per a un funcionament correcte és necessari comprovar el seu estat cada 6 mesos. •Rodes (wheels): Les rodes fan possible la transmissió habitual del robot. És necessari comprovar la pressió de les rodes una vegada al mes. Una vegada vistes les parts més importats, volem demostrar la gran modularitat del robot amb un senzill exemple. Este model en concret, disposa d’una estructura mòbil 6 3.1. CINEMÀTICA DIFERENCIAL x(t) = ´V(t)cos[θ(t)]dt y(t) = ´V(t)sin[θ(t)]dt θ(t) = ´ω(t)dt Malauradament, un robot amb cinemàtica diferencial imposa el que són conegudes com a limitacions no-holonòmiques en l’establiment de la seua posició. Per exemple, el robot no podrà moure’s mai al llarg del seu eix. Una limitació no-holonòmica similar és la d’un cotxe que només pot girar amb les seues rodes davanteres. Com sabem, serà impossible que es moga lateralment fent així que el seu aparcament requerisca un conjunt més complicat de maniobres. Açò ens serveix per exemplificar que en el problema cinemàtic invers no anem a poder simplement especificar la posició desitjada (x, y, j ) i obtindre directament les velocitats que ens farien que el robot es traslladés ahí, sinó que és una cosa més complicada i que queda fora de l’objectiu d’este text. No obstant això, si que podem indicar quines són les equacions per al casos especials. •Per al cas en el que Vl = Vr (moviment en línia recta)    x’ y0 θ0   =   x+vcos(θ)δt y+vsin(θ)δt θ    •Per al cas en que Vl=-Vr (moviment rotacional sobre ell mateix)    x’ y0 θ0   =   x y θ+ 2vδt/l    El fet de que estos casos especials siguen senzill de modelar, motiva l’estratègia de fer moure el robot en línies rectes la major part del temps possible per a efectuar els girs sobre ell mateixa quan siga necessari. 13 CAPÍTOL 3. FONAMENTS DE ROBÒTICA MÒBIL 3.2 Control Un sistema de control és un conjunt de components interconnectats dedicats a obtenir la eixida desitjada per a un sistema o procés, de manera que es redueixen les probabilitats d’errors i s’obtinguen els resultats buscats. Al cas que ens ocupa, la robòtica mòbil, trobem sistemes de control implementats la major part de les voltes per controladors PID (Proporcional-IntegralDerivatiu) que s’encarreguen de controlar la velocitat o posició de les rodes depenent del model. Este control pot efectuar-se en diferents parts del sistema, des de a la programació del software del robot com implícitament a l’electrònica de la placa controladora dels motors. A més, pot efectuar-se de diferents formes, estes són: •Sistema de control en llaç obert: És aquell sistema en que només actua el procés sobre la senyal d’entrada i dona com resultat una senyal d’eixida independent a la senyal d’entrada, però en base a la primera. Això significa que no hi ha retroalimentació cap al controlador per que aquest puga ajustar l’acció de control. Es a dir, la senyal d’eixida no es converteix en senyal d’entrada per el controlador. •Sistema de control en llaç tancat: Son els sistemes en els que l’acció de control està en funció de la senyal d’eixida. Els sistemes de circuit tancat utilitzen la retroalimentació des d’un resultat final per ajustar l’acció de control en conseqüència. El llaç obert ens proporciona un control més senzill però per contra no assegura l’estabilitat del sistema ja que no es compara l’eixida amb l’entrada, a més de poder quedar afectat per les pertorbacions. Açò fa que siga pràcticament descartat en la robòtica, ja que en esta és preferible un controlador estable a pertorbacions i possibles variacions internes, sent capaç de retroalimentar l’eixida amb l’entrada i efectuant segons això les accions de control adients. 3.2.1 El control proporcional (P) A continuació presentarem el control de tipus proporcional. Anem a estudiar-lo detalladament ja que és el que utilitza el nostre robot per al control de velocitat de les rodes. En este tipus de control la relació entre l’eixida del controlador u(t) i la senyal d’error e(t) és la següent: u(t) = Kp e(t) El que ve a ser que l’acció de control serà proporcional a la senyal de error. La funció de transferència serà per tant, una constant, on Kp es denominarà guany proporcional. 14 3.2. CONTROL U(s) E(s)=Kp Siga quin siga el mecanisme real i la forma d’aplicar la potència als accionaments, el controlador proporcional és en essència un amplificador de guany ajustable, ja que existeix una relació lineal continua entre el valor de la variable controlada i la posició final de l’element de control. Anem a vore com reacciona el sistema al ser excitat per un escaló d’amplitud A. Analitzarem el sistema tant en bucle obert, com en tancat. En bucle obert, a una senyal de entrada en escaló d’amplada A, el procés respondrà amb un eixida: Y(s) = R(s)G(s) = AG(s) s Si apliquem el teorema del valor final, l’eixida en règim permanent serà: yss = limsY (S) = limsAG(s) s=A·G(0) En bucle tancat, amb realimentació unitària i afegint el controlador proporcional, la resposta en estat estacionari yss a un escaló és: yss(s) = lim sY (s) = lim sKpG(s) 1 + KpG(s)·R(s) = limsA s · KpG(s) 1 + KpG(s)=KpG(0) 11 + KpG(0)·A Podem observar que per a valors alts de Kp, l’eixida del sistema seguirà pràcticament a la senyal de referència. Per tant, un augment del guany del controlador permet reduir l’error en l’estat estacionari, no obstant, per a poder eliminar este error és necessari que la funció de transferència en llaç obert continga algun element integrador i el sistema siga estable, cosa que este tipus de controlador no proporciona. A més a més, la utilització de valors elevats del guany, pot provocar fenòmens com l’aparició de saturació en alguns elements, fent que el sistema entre en règim no lineal o inclús arribant a provocar la inestabilitat d’aquest. 3.2.2 El control PID. Cas d’estudi: Control en bucle tancat respecte a la velocitat. Un dels controladors de llaç tancat més utilitzats és el PID. Segons les estadístiques, més d’un 80% dels controladors presents a l’àmbit industrial són d’este tipus (d’este 15 CAPÍTOL 3. FONAMENTS DE ROBÒTICA MÒBIL Figura 3.3: Gràfic del control P o de qualsevol de les seues configuracions, com poden ser P,PI i en menor mesura PD). Aquest controlador es fa servir dins del camp del control automàtic per a realitzar les operacions bàsiques de l’àlgebra lineal: el producte per un escalar, la suma i la resta. Malgrat la seua senzillesa i facilitat d’utilització proporciona uns resultats molt satisfactoris. Tot i que ja hem apuntat que el nostre robot utilitzarà un controlador P a la simulació, no podem passar per alt el control PID per les raons abans mencionades i perquè el robot real utilitza un control d’este tipus integrat a la electrònica de la controladora. Veiem com funciona. El control PID en bucle tancat respecte a la velocitat es basa en ajustar la potència d’eixida segon la diferència entre la velocitat desitjada (la que proporciona l’usuari) i la posició de la roda actual (la capturada pels encoders). Cada instant, depenent de la configuració, el controlador mesurarà la velocitat actual del motor i li restarà la posició desitjada per obtenir l’anomenat error de velocitat (ev). El resultat obtingut és aleshores multiplicat per un guany proporcional indicat per l’usuari. L’efecte d’esta part de l’algorisme és el d’aplicar potència al motor proporcionalment amb la diferencia entre la velocitat actual i la desitjada: quan més lluny s’estiga, més potència s’aplicarà i viceversa. Un major guany proporcional farà que l’algorisme aplique un major nivell d’energia a un error donat, de manera que el motor reaccionarà més ràpidament als canvis en les ordres. u1=Kpe(t) El component diferencial de l’algorisme calcula els canvis del error d’un instant donat al següent. Aquest canvi serà un nombre relativament gran cada vegada que 16 3.3. ODOMETRIA un canvi brusc es produïsca en el valor de la velocitat desitjada o el valor de la velocitat mesurada. El valor d’aquest canvi es multiplicarà per un guany diferencial que l’usuari pot seleccionar i afegir a l’eixida. L’efecte d’aquesta part de l’algorisme és el de donar un impuls d’energia extra en arrencar el motor a causa dels canvis en el valor de la velocitat desitjada. El component diferencial també és en gran mesura l’encarregat d’ajudar a reduir qualsevol excés i oscil·lació. u2(t) = Kp Tt´e(τ)δτ Per últim, el component integral de l’algorisme fa una suma de l’error al llarg del temps. Este component ajuda al controlador a aplegar i mantindre la velocitat exacta dessitjada quan el valor de l’error està aplegant a zero. Açò es dona quan la velocitat mesurada és pròxima o directament és la desitjada. u3(t) = KpTdδe δt Figura 3.4: Estructura del controlador PID. Nota: A les formules presentades ui(t) és l’eixida de cadascun dels tres termes del controlador, e(t) és el senyal d’error, Kpés la constant proporcional, Tiés el temps integral i Tdés el temps derivatiu. 3.3 Odometria La odometria és el mètode que utilitzen els robots mòbils amb rodes per posicionarse d’una forma aproximada en respecte a la seua posició inicial a l’espai. La idea fonamental de la odometria és la integració d’informació incremental del moviment al llarg del temps, la qual cosa comporta una inevitable acumulació d’errades, que van argumentat proporcionalment amb la distància recorreguda pel mòbil. La odometria es basa en equacions simples i en les dades obtingudes pels encoders situats a les rodes del robot. No obstant, la odometria suposa que les revolucions de 17 CAPÍTOL 3. FONAMENTS DE ROBÒTICA MÒBIL les rodes poder ser traduïdes amb un desplaçament lineal respecte al sòl, cosa que no és absolutament certa, ja que s’ha de tindre en compte fenòmens com la fricció de les rodes amb el sòl, la deformitat al llarg del temps d’estes o el fet de que no giren a les mateixes velocitats. Tot açò, unit a les més diverses raons i imprevistos, comporta unes imprecisions en la traducció de la informació obtinguda de l’encoder amb el que realment s’ha desplaçat el robot, per això, es recomanable que el robot es posicione addicionalment per sistemes de posicionament absoluts com les IMU (Inertial Measurement Unit) o el conegut GPS (Global Positioning System). Figura 3.5: Detall d’un encoder muntat sobre una roda. Els avanços més destacables en este camp giren entorn a l’odometria visual. Esta tecnologia naix motivada pel fet de que aquells robots mòbils sense rodes no poden fer servir l’odometria clàssica, com són per exemple els robots articulats. A més a més, intenta corregir les mancances sistemàtiques de l’odometria basada en rodes com són que els diàmetres de les rodes no siguen iguals, que estes estiguen mal alineades o que l’encoder siga un sistema discret i no continu amb els defectes que açò pot comportar en la mesura. L’odometria visual fa servir imatges seqüencials de les càmeres per estimar la distància viatjada, esta permet millorar la precisió en la navegació dels robots de qualsevol tipus de locomoció en qualsevol superfície. 3.4 Navegació autònoma La navegació en la robòtica és la ciència de dirigir un mòbil al llarg del medi, ja siga terra, aigua o aire. L’objectiu inherent de qualsevol sistema de navegació és aplegar a la destinació sense que el robot es perda o tinga un accident. La capacitat de reacció davant de situacions inesperades ha de ser la principal qualitat per a desenvolupar-se, d’una forma eficaç, en entorns no estructurats. Les tasques involucrades en la navegació d’un robot mòbil són: la percepció de l’entorn a través dels sensors, de forma que li permeta crear una abstracció del món (mapping); 18 3.4. NAVEGACIÓ AUTÒNOMA la planificació d’una trajectòria lliure d’obstacles per a aplegar al punt de de destí seleccionat (planning); i el guiat del vehicle a través de la referència construïda. De forma simultània, el vehicle pot interactuar amb certs elements de l’entorn. La navegació en la robòtica mòbil és tot un món en si mateixa, amb una gran quantitat d’algorismes de guiat, planificació i conducció que queden fora de l’objectiu d’esta memòria. No obstant, creguem necessari explicar el funcionament de dos algorismes de posicionament importants, el MCL i el SLAM, ja que són els que ROS implementa ara per ara i utilitzarem al nostre robot. 3.4.1 MCL Monte Carlo Localization (MCL) es un mètode Monte Carlo (una classe d’algorisme basada en la repetició de resultats aleatoris per extraure els resultats desitjats) que serveix per determinar la posició del robot donat un mapa del seu entorn i basant-se en el mètode de localització Markov. Es tracta bàsicament d’una implementació del filtre de partícules aplicat a la localització del robot, i s’ha convertit en un mètode molt popular en la robòtica. En este mètode, un gran nombre d’hipotètiques configuracions inicials son dispersades aleatòriament per l’espai. Amb cada actualització dels sensors, la probabilitat de que cada configuració hipotètica siga correcta s’actualitza basant-se en un mètode estadístic dels sensors i en la teoria de Baye. De la mateixa manera, tots els moviments que el robot efectua són afegits a esta estadística de configuracions hipotètiques. En quan la probabilitat d’una configuració hipotètica és massa baixa, es reemplaçada per una nova configuració a l’atzar. 3.4.2 SLAM Un mètode més interessant ja que integra la localització i el mapeig d’una forma concurrent és el SLAM, sigles angleses de Simultaneous Localization and Mapping. Esta tècnica busca resoldre els problemes que planteja el col·locar un robot mòbil en un entorn i posició desconeguts, i que ell mateix siga capaç de construir incrementalment un mapa consistent de l’entorn a l’hora que utilitze este mapa per determinar la seua pròpia localització. La solució a este problema, no es trivial, i ha sigut objecte d’estudi per part de la comunitat científica durant les últimes dècades ja que el soroll inherent als sensors, els inevitables errors i aproximacions comeses en els models empleats fan que siga un problema difícil de resoldre, ja siga des d’un punt de vista conceptual (entorn confús, canviant i gens clar) com computacional (quantitat d’informació, forma i costos de tractar-la, així com emmagatzemar-la...). Així doncs, en la base de qualsevol solució a la problemàtica del SLAM ens anem a trobar sempre amb la necessitat de treballar amb quantitats creixents d’informació 19 CAPÍTOL 3. FONAMENTS DE ROBÒTICA MÒBIL (contaminada en menor o major mesura), que manipularem mitjançant models que no són més que aproximacions a la realitat. Les solucions que millor resolen el problema del SLAM són aquelles que es basen en tècniques probabilístiques ja que permeten fer front a les incongruències inherents al procés que hem comentat anteriorment. Este tipus d’algorismes es basa en l’algorisme de Bayes, que relaciona entre si les probabilitats marginal i condicional de dues variables aleatòries. La manera en que treballa este tipus de formulació es considerar que tant la posició del robot com els elements que modelen el seu entorn son variables aleatòries. Així, els algorismes existents modelen de manera probabilística i utilitzant la inferència per a determinar aquella configuració que és més probable tenint en compte les mesures que van obtenint-se. Estos algorismes són: •Filtre Extés de Kalman (EKF): és una de les solucions més utilitzades al problema SLAM i també una de les que millors resultats proporciona. Proporciona característiques tant interessants com el fet de descriure l’entorn a partir d’entitats geomètriques de forma compacta i la possibilitat de realimentar-se gràcies a l’ús d’una matriu de covariàncies del sistema completa que es capaç de tancar bucles amb èxit. •Mapa d’ocupació de cel·les (Occupancy Grid Mapping): Este mètode es basa en la discretització de l’espai, dividint-lo en unitats d’una mida predefinida que es classifiquen com ocupades o buides amb una nivell de confiança o probabilitat. Estes solucions suposen que la posició del robot és coneguda. En la pràctica, es necessita algun mètode alternatiu de localització que estime la posició del robot en cada instant. Malgrat este desavantatge, és un algorisme senzill d’implementar i molt robust a més de distingir entre zones ocupades i buides, aconseguint una partició i descripció completa i detallada de l’espai explorat, fent molt senzilla la planificació i generació de trajectòries utilitzant tècniques convencionals. 20 4 ROS: Un framework de codi obert per a la robòtica Escriure software per a robots és complicat, sobretot degut a que l’escala i els enfocaments de la robòtica no paren de créixer. Diferents tipus de robots poden tindre quantitats de hardware molt diferent, fent que la reutilització de codi siga un problema no trivial. A més a més, la mida del codi requerit pot ser enorme, ja que pot anar des de la programació del driver de les rodes fins a la percepció o el raonament abstracte. Per superar estos reptes, molts desenvolupadors han creat prèviament una gran quantitat de frameworks per facilitat el prototipat de software per a experiments, donant com a resultat molt del software que actualment s’utilitza tant en industria com en investigació. Cadascun d’estos frameworks foren dissenyats amb un objectiu en particular, pot ser en resposta a les febleses percebudes en altres frameworks disponibles o per donar-li prioritats a aspectes que el desenvolupador considera que són més importants en el procés. ROS, el framework que anem a estudiar i hem utilitzat per a la realització del projecte, és també producte de les compensacions i prioritats fetes durant el seu cicle de disseny. Segons els dissenyadors, s’ha posat detall en la gran integració del producte, cosa que el farà útil en una gran varietat de situacions així com en un món on la robòtica és cada vegada una cosa més complexa. Com a visió general, podem vore ROS com un framework de codi obert per a robots, que proporciona els servicis que podrien esperar-se d’un sistema operatiu, com el control de dispositius a baix nivell, l’abstracció del hardware, el pas de missatges entre processos o inclús la gestió de paquets. Cal destacar, que tota la tasca de desenvolupament i implantació d’este nou framework l’esta realitzant l’empresa nordamericana Willow Garage. Esta empresa ha sigut fundada per gent provinent de Google, així com també és financiada per esta mateixa empresa. A continuació descriurem d’una forma detallada els objectius general de ROS i com s’han implementat en el seu desenvolupament. 4.1 Objectius Els objectius principals de ROS poden ser resumits en: 21 CAPÍTOL 4. ROS: UN FRAMEWORK DE CODI OBERT PER A LA ROBÒTICA Peer-to-peer: Un sistema construït utilitzant ROS consisteix en un nombre de processos, potencialment en diferents hosts, connectats en temps d’execució en una topologia punt-a-punt (peer-to-peer). Tot i que alguns frameworks basats en un servidor central (per exemple, CARMEN1) poden tindre beneficis sobre el disseny multi-procés i multi-host, un servidor central és problemàtic si els ordinadors estan connectats en una xarxa heterogènia. Per exemple, en els grans robots de servei per als que ROS ha sigut dissenyat solen haver diversos ordinadors abord connectats via Ethernet. Este segment de la xarxa està pontejant via wireless a ordinadors d’offboard de gran potència que estan executant tasques de comput molt intensives, com poden ser visió o reconeixement de la parla. Que s’execute el servidor central a bord o fora del robot, dona com a resultat un tràfic innecessari creuant el feble pont inalambric, ja que molts dels missatges o serveis necessitats es troben en xarxes i subxarxes, ja siga fora o dins de vehicle. Per altra banda, la connectivitat peer-to-peer, combinada adequadament amb el buffering per software quan és necessari, resol el problema d’una forma completa. La topologia peer-to-peer requereix algun tipus de mecanisme de cerca que permeta als processos trobar-se uns amb els altres en temps d’execució. Açò és el que s’anomenarà name service, o master, i vorem en breu. Multillenguatge: Quan s’escriu codi sempre es tenen unes preferències d’un llenguatge respecte un altre. Este preferències venen donades per l’experiència personal, la facilitat de depuració, la sintaxis, l’eficiència en temps d’execució... Per este raons, ROS ha sigut creat per ser neutral en el llenguatge i per això suporta, a dia de hui diferents llenguatges com són: C++, Python, Octave, LISP, Java i molts llenguatges més que estan en procés de ser suportats. L’especificació ROS es només a la capa dels missatges, no aplega més enllà. La negociació i configuració de la connexió peer-to-peer ocorre en XML-RPC2, per al qual existeix la seua implementació en la major part dels llenguatges. En lloc de proporcionar una aplicació basada en C amb interfícies de codi auxiliar generat per als principals idiomes, ROS es implementat de forma nativa en cada idioma de destí, d’esta manera es segueixen millor les convencions de cada llenguatge. Per donar suport al desenvolupament creuat entre idiomes, ROS utilitza una interfície simple i neutral de cara al llenguatge, l’anomenada IDL per descriure els missatges escrits entre mòduls. IDL utilitza fitxers de text per descriure els camps de cada missatge i permet la composició d’estos. Per exemple: Header header Point32[] pts ChannelFloat32[] chan 1Carnegie Mellon Robot Navigation Toolkit 2Protocol de crida a procediments remots (RPC) que fa servir XML per codificar les crides i HTTP com a mecanisme de transport de les dades. 22 4.3. CONCEPTES I SINTAXIS rosnode info Proporciona informació sobre el node. rosnode kill Mata un node en execució. rosnode list Mostra una llista dels nodes en actiu. rosnode machine Mostra un llistat dels nodes en actiu d’una màquina. rosnode ping Prova la connectivitat a un node en concret. Taula 4.2: Utilitats de rosnode. ROS Master El ROS master proporciona un servei de noms i de registre per a la resta dels nodes en el sistema ROS. Fa un seguiment dels publisher isubscribers dels tòpics, així com dels serveis. El paper del mestre és permetre que els nodes individuals ROS puguen localitzar-se entre ells. Una vegada que aquests nodes és troben un a l’altre, es comuniquen entre si peer-to-peer. El master també proporciona l’anomenat Servidor de Parametres. Per últim, cal indicar que la forma més comú de llançar el master és utilitzant l’ordre roscore , la qual carrega el mestre a més d’altres components essencials. A continuació mostrarem un exemple per il·lustrar d’una manera més clara la tasca que realitza el master. Suposarem que tenim dos nodes: el node d’una camèra i un node “image_viewer”. Una seqüència tipica d’esdeveniments comença amb el node de la camèra notificant al master que vol publicar imatges en el tòpic “images” (Figura 4.1). A continuació, el node “camera” publicarà imatges al topic “images”, però ningú està subscrit a este topic ja que ningun tipus de dada està siguent enviat. Arribats a este punt, el node “image_viewer” vol subscriure’s al topic “images” per vore si hi ha alguna imatge per a obtenir. (Figura 4.2) Finalment, ara que el tòpic “images” te un publicador i un subscriptor, el node mestre notificarà al node “camera” i “image_viewer” sobre l’existència de l’altre i així poden iniciar la transferència d’imatges d’un a l’altre (Figura 4.3). Figura 4.1: Exemple de connexió del master 1/3 29 CAPÍTOL 4. ROS: UN FRAMEWORK DE CODI OBERT PER A LA ROBÒTICA Figura 4.2: Exemple de connexió del master 2/3 Figura 4.3: Exemple de connexió del master 3/3 Servidor de paràmetres El servidor de paràmetres es un diccionari multi-variat i compartit que és accessible via una API de xarxa. Els nodes usen este servidor per emmagatzemar i rebre paràmetres en temps d’execució. Ja que no està dissenyat per a alt rendiment és millor utilitzar-lo en aplicacions estàtiques, no de dades binaries, com per exemple, paràmetres de configuració. Està pensat per ser visible globalment i que les eines puguen inspeccionar i modificar l’estat del sistema conforme siga convenient. El servidor de paràmetres està implementat usant XML-RPC i s’executa a l’interior del Master, el que significa que la seua API es accessible normalment via biblioteques XML-RPC. 30 4.3. CONCEPTES I SINTAXIS Missatges Com ja hem indicat, els nodes es comuniquen uns amb els altres publicant missatges en tòpics. Un missatge és simplement una estructura de dades que comprén camps fortament tipats. Els tipus estàndard primitius (int, float, bool, etc.) estan suportats i a més existeixen els arrays de tipus primitius. Els missatges poden incloure estructures niuades i arrays (com els structs de C). Tota està descripció s’inclourà en el directori /msg i en fitxers .msg. Per altra banda, és interessant presentar la ferramenta de línia de comandes rosmsg, que ens permet obtindre, com moltes altres, informació sobre els missatges. rosmsg show <type> Mostra els camps d’un tipus de missatge. rosmsg users <type> Busca paquets que utilitzen un tipus de msg concret. rosmsg packages Mostra un llistat de tots els paquets amb missatges. rosmsg package <pkg> Mostra un llistat de tots els msg utilitzats pel paquet. rosmsg md5 <type> Obté el md5 sum d’un missatge. Taula 4.3: Utilitats de la ferramenta rosmsg. Tòpics Els tòpics són busos amb un nom sobre els qual els nodes intercanvien missatges. Els tòpics proporcionen una semàntica anònima de publicació/subscripció, la qual cosa separa la producció d’informació del seu consum. En general, els nodes no saben amb qui s’estan comunicant. En lloc d’això, els nodes que estan interessants en un tipus de dada es subscriuen al tòpic que els interessa i els nodes que generen informació la publiquen sobre un tòpic. Poden haver múltiples publicadors i subscriptors a un tòpic. Els tòpics estan destinats a la comunicació unidirecional en streaming. Els nodes que necessiten realitzar crides a procediments remots, com per exemple, respondre a una petició, deuen utilitzar els serveis en compte dels nodes. Cada tòpic està fortament tipat pel tipus de missatges que hem definit anteriorment. El Master no comprovarà la consistència de tipus en els publicadors, ara bé, els subscriptors no establiran la connexió de no ser que el tipus de missatge esperat i el que es transportat pel tòpic coincidisquen. Pel que fa al transport d’informació, ROS suporta el transport de missatges sobre TCP/IP i UDP. El transport basat en TCP/IP és conegut com TCPROS i proporciona missatges d’informació continua sobre connexions persistents TCP/IP. Per altra banda, el transports basat en UDP, que es conegut com UDPROS només està suportat a dia de hui per roscpp i funciona separant els missatges a enviar en paquets UDP. UDPROS es un tipus de transport per a baixes latències i transport no-crític, així que és més adequat per propòsits com la teleoperació de robots mòbils. Els node 31 CAPÍTOL 4. ROS: UN FRAMEWORK DE CODI OBERT PER A LA ROBÒTICA ROS negociaran el transport desitjat en temps d’execució. Per exemple, si un node prefereix utilitzar UDPROS però l’altre no el suporta, hauran d’utilitzar TCPROS que si que està suportat pels dos. Com és habitual, presentem una taula on expliquem de manera resumida les funcionalitats de la ferramenta de línia de comandes per gestionar els tòpics, rostopic. rostopic hz <nom topic> Mostra la ratio de publicació d’un tòpic en Hz. rostopic echo <nom topic> Mostra les dades que circulen per pantalla. rostopic bw <nom topic> Mostra l’amplada de banda utilitzada pel tòpic. rostopic find <msg type> Busca topics per tipus. rostopic list Mostra tots els topics presents als sistema. rostopic pub <nom topic> Publica informació a un tòpic en concret. rostopic type <nom topic> Mostra el tipus de topic. rostopic info <nom topic> Publica informació sobre un topic en concret. Taula 4.4: Utilitats de la ferramenta rostopic. Serveis El model basat en publicadors/subscriptors és un paradigma de comunicació molt flexible, tot i que el seu transport molts-a-molts unidireccional no és el més adequat per a les peticions/respostes RPC requerides habitualment pels sistemes distribuïts. Les peticions/respostes són efectuades via serveis (services), els quals queden definits per un parell de missatges: un per la petició i un altre per la resposta. Un node ROS pot oferir un servei baix un nom (string). El client cridarà al servei enviant el missatge de petició i esperant a la resposta. Les llibreries client solen representar esta interacció al programador com si d’una crida de procediment remot es tractara. El serveis, com hem vist en la secció anterior, queden definits per els fitxers .srv, els quals són compilats en el codi font per les biblioteques de clients ROS (roscpp, rospy, ...). Un client pot establir una connexió persistent a un servei, el qual establirà un alt rendiment a canvi de menys solidesa als canvis del proveïdor de serveis. Tot i que l’ús de serveis, almenys en la nostra experiència no ha sigut massa habitual, creguem convenient presentar les utilitats que ens proporciona l’eina de terminal rosservice. 32 4.3. CONCEPTES I SINTAXIS rosservice args <name> Mostra els arguments necessaris per cridar un srv. rosservice call <name> Crida al servei amb els arguments indicats. rosservice node <name> Mostra els nodes que fan ús d’un servei determinat. rosservice find <type> Busca serveis per tipus. rosservice list Mostra tots els serveis presents als sistema. rosservice type <name> Mostra el tipus de servei. rosservice info <name> Publica informació sobre un servei en concret. Taula 4.5: Utilitats de la ferramenta rosservice. 4.3.3 Alt nivell Com hem vist en seccions anteriors, ROS ens proporciona uns conceptes i una arquitectura clara de com ha d’organitzar-se el sistema. En el primer nivell hem vist com ROS descriu l’estructura i els diferents components, per a després, en un segon nivell vore com estos components interactuen entre si en temps d’execució. No obstant això, i encara que ROS intente estar el més allunyat com siga possible de conceptes complexos, existeixen utilitats i conceptes d’alt nivell que no poden ser englobats en cap de les seccions anteriors ja que agrupen diferents ferramentes i conceptes d’estes. Estos ens faciliten molt la feina, per això és necessària la seua implementació. A continuació explicarem els més importants: Transformacions Els sistemes robotitzats sovint necessiten fer un seguiment sobre les seues relacions espacials per diverses raons, ja siga entre un robot mòbil i algun marc (o frame, anem a utilitzar els dos termes de forma indiferent) de referència fixe per a la localització, com entre els diferents frames de sensors i actuadors fins a col·locar frames de referència com a objectius en finalitats de control. Per unificar i simplificar el tractament dels marcs espacials ROS incorpora un sistema de transformacions anomenat tf. El sistema tf construeix un arbre de transformacions dinàmic que relaciona tots els frames de referència del sistema. A l’igual que els fluxes d’informació que provenen dels diferents subsistemes del robot (encoders, algorismes de localització, etc) el sistema tf produeix fluxos de transformacions entre els nodes de l’arbre, construint una ruta entre el node desitjat i efectuant els càlculs necessaris. En altre paraules, des d’un nivell abstracte podem vore com l’arbre de transformacions defineix les compensacions en termes de translació i rotació entre els diferents marcs de coordenades. Este tipus de càlculs sol ser pesat, amb tendència a l’error i dificil de depurar quan està programat a mà, no obstant, la implementació d’este sistema de tf, combina amb la estructura dinàmica de pas de missatges de ROS, permet una aproximació automatitzada i sistemàtica al problema. 33 CAPÍTOL 4. ROS: UN FRAMEWORK DE CODI OBERT PER A LA ROBÒTICA Per a clarificar tot açò anem a posar un exemple. Considerem un robot mòbil amb un làser muntat sobre ell. Ens referirem als dos objectes mitjançant dos marcs coordenats, un que es correspon al punt central de la base del robot i que anomenarem “base_link” i altre que es correspon al punt central del làser i que anomenarem “base_laser”. En aquest punt, suposem que tenim algunes dades del làser en la forma de distàncies des del centre del làser. En altres paraules, tenim algunes dades al sistema de coordenades de “base_laser”. Suposem que volem utilitzar esta informació per a ajudar a la base del robot mòbil a evitar obstacles mentre navega. Per fer açò amb èxit, necessitem una forma de transformar la informació que ens arriba del frame “base_laser” al frame “base_link”. En resum, necessitem definir una relació entre els dos marcs coordenats. Figura 4.4: Situació dels diferents marcs coordenats. Definint la relació, hem d’assumir que sabem que el làser està montat 10cm per davant i 20cm per damunt del punt central de la base del robot mobil. Açò ens proporciona una translació que ens relaciona els dos marcs de “base_link” a “base_laser”: (x: 0.1m, y: 0.0m, z: 0.2m). Figura 4.5: Efecte de les tf sobre un objecte situat a 0.3 cm. Arribats a este punt, podem triar de gestionar aquesta transformació nosaltres mateixa o deixar que tf treballe per nosaltres. Una vegada definida esta relació entre “base_link” i “base_laser” hem d’afegir-la a l’arbre de transformacions. Conceptualment, cada node en este arbre correspon a un marc coordenat i cada aresta es correspon a la transformació necessària per moure’s d’un node al fill. Tf utilitza una estructura d’arbre per garantir que només hi ha un únic recorregut que uneix els dos marcs coordenat i suposa que totes les arestes en l’arbre es dirigeixen dels pares als nodes fills. 34 4.3. CONCEPTES I SINTAXIS Visualització i monitorització Quan estem dissenyant i depurant software robòtic, sol ser necessari observar l’estat del sistema conforme s’executa. Tot i que printf és una tècnica comú per la depuració de programes en una maquina senzilla, pot ser difícil exportar este procediment a un sistema distribuït de gran escala i a més pot resultar molt poc eficient per a supervisar software d’una forma general i sistemàtica. En lloc d’açò, ROS explota la seua naturalesa dinàmica de connexió en graf per “aprofitar” qualsevol flux de missatges en el sistema. A més a més, la independència entre publishers i subscribers permet la creació de visualitzadors d’ús general. Es poden escriure programes molt senzills que es subscriguen a un tòpic en concret i que mostren per pantalla un tipus de dada, com puguen ser imatge o fluxos provinents del làser. Tanmateix, un concepte més evolucionat de tot açò ens el proporciona rviz, un programa de visualització que utilitza una arquitectura de plugins i que es distruit conjuntament amb ROS. Els panells de visualització poden ser instanciats dinàmicament per visualitzar una gran quantitat de dades, com per exemple imatges, núvols de punts, primitives geomètriques, posicions renderitzades del robot, etc. Estos plugins poden ser escrits fàcilment per visualitzar els nostres propis tipus de dada. Per altra banda, gràcies a Python s’ha escrit una de les ferramentes més potents de ROS, rostopic, la qual s’encarrega de filtrar missatges utilitzant les expressions introduïdes en la línia de comandes, donant com a resultat un capturador de missatges configurable que pot convertir qualsevol fluxe de dades en flux de text. Estos fluxes de text poden ser entubats a altres ferramentes UNIX com grep, sed, i awk per crear complexes ferramentes de monitorització sense escriure cap línia de codi. D’una forma similar, rxplot proporciona la funcionalitat d’un oscil·loscopi virtual, mostrant l’estat de qualsevol variable per pantalla en temps real. Per últim i no per això menys important, presentem la ferramenta rxgraph. Esta ferramenta ens permet visualitzar i inspeccionar gràficament l’estructura de node del sistema en execució. La seua eixida, generada dinàmicament, mostra els nodes com a ovals, els tòpics com a rectangles i les connexions com a arcs. És molt útil ja que clarifica l’estructura i ens permet vore l’evolució del sistema conforme aquest evoluciona. Més endavant serà utilitzada per explicar l’arquitectura del sistema resultant. Model URDF URDF5és una especificació XML6per a la descripció de robots. S’intenta mantindre el més general com siga possible, però açò té certes limitacions, com el no poder 5Unified Robot Description Format 6Extensible Markup Language. Metallenguatge extensible d’etiquetes, desenvolupat pel W3C. 35 CAPÍTOL 4. ROS: UN FRAMEWORK DE CODI OBERT PER A LA ROBÒTICA representar tots els tipus de robots o components d’estos. La principal limitació que ens trobem és que només es poden representar robots que seguisquen una estructura d’arbre, deixant fora els robots paral·lels. A més a més, l’especificació assumeix que el robot està format per cosos rígids (links) units per articulacions (joints). Els elements flexibles no estan suportats. L’especificació dona suport a: •La representació cinemàtica i dinàmica del robot. •La representació visual del robot. •El model de col·lisions del robot. Figura 4.6: Esquema visual d’una configuració URDF. La representació d’un robot consisteix en un conjunt de links ijoints que es connecten. Un fitxer típic de representació URDF d’un robot tindrà esta estructura. <robot name="pr2"> <link> ... </link> <link> ... </link> <link> ... </link> <joint> .... </joint> <joint> .... </joint> <joint> .... </joint> </robot> Per a una visió completa del que és i com s’utilitza el URDF, recomanem visitar la pàgina de referència7XML del format. Més endavant a esta mateixa memòria serà explicat com crear i llançar un URDF del robot que hem simulat. 7http://www.ros.org/wiki/urdf/XML 36 5 Simulació 5.1 Introducció La robòtica és un camp que genera gran interés, malgrat això, la inversió que hi ha que fer per accedir al hardware resulta, de forma general, prohibitiva. La simulació per ordinador és una alternativa vàlida i de baix cost per als qui consideren l’esforç econòmic un impediment. A més a més, no només per això ens pot interessar la simulació per ordinador, sinó que hi ha raons addicionals que motiven a interessar-se per esta: •Mobilitat: Des d’on volem podem simular qualsevol entorn sense haver d’estar present. Per exemple, podem estar a una oficina sense cap robot present mentre estem dissenyant el sistema de control d’un grup de robots a un entorn industrial. •Adaptabilitat: Les modificacions que apliquem al robot o a l’entorn no tenen cost econòmic. •Gestió de recursos: Un simulador, utilitzat junt a una capa de abstracció de hardware, permet desenvolupar software per a un robot que existeix però al que no es té accés en un determinat moment. Açò és especialment útil quan hi ha més d’un desenvolupador i un únic robot. •Protopipat: Mitjançant la simulació, és possible implementar el software d’un robot abans que este haja sigut construït. Açò és útil per a realitzar qualsevol tipus de prova abans de que el robot real es construïsca. •Reusabilitat: Ja que l’ús de simuladors sol estar acompanyat d’algun tipus de capa d’abstracció, el codi generat pot ser compartit i utilitzat per altres persones. •Control del temps: Alguns simuladors permeten parar o accelerar el temps, ja siga avant o arrere, de la simulació. Açò pot ser útil per a inspeccionar l’estat dels robots en certs moment o per a fer proves de durabilitat. 37 CAPÍTOL 5. SIMULACIÓ Tipus de robot Simuladors Robots amb rodes Carmen, Player/Stage Project, Xraptor, Gazebo, etc. Braços robotitzats RobotStudio, SimRobot, Kuka.Sim Pro, RobotWorks Robots amb cames Virtual KHR-1 Robots submarins DeepWorks, Neptune Simulator Taula 5.1: Simuladors per a robòtica Podem trobar una gran quantitat de simuladors, estos els hem organitzat en diverses seccions: robots amb rodes, braços robotitzats, robots amb cames i robots submarins. Una vegada explicats els avantatges de la simulació per a robots i mostrar un llistat dels més importants, en centrarem en el que hem utilitzat per al nostre projecte: Gazebo. 5.2 Gazebo Gazebo és un simulador multi-robot tant per a entorns interiors com exteriors. Com Stage, és capaç de simular poblacions de robots, sensors i objectes però a diferència de l’anterior, Gazebo ho simula en un món tridimensional. A més a més, este simulador genera feedback realista dels sensors, col·lisions i dinàmica d’objectes. Cal indicar primer que res, que comparant-lo amb altres simuladors, Gazebo encara es troba en un estat poc madur (actualment es troba en la versió 0.8), però així i tot, donat que és software lliure, és 3D i més realista i complet que altres, fa que siga una opció molt interessant. Gazebo és normalment utilitzat junt al servidor de dispositius Player. Este proporciona l’abstracció d’un mecanisme central de xarxa (un servidor) sobre el que el els controlador del robot (clients) poden interactuar sobre el hardware del robot. Quan s’utilitza amb Gazebo, Player proporciona dades simulades en lloc de dades provinents dels sensors reals. En principi, els programes client no tenen perquè notar la diferència entre els dispositius reals i els simulats per Gazebo. Este simulador també pot ser controlat mitjançant una API C de baix nivell (libgazebo). Esta llibreria està inclosa per a permetre integrar Gazebo a tercers en els seues propis servidors o arquitectures. És més, la forma en que utilitzarem nosaltres Gazebo dista molt de la comentada més amunt i és possible gràcies a esta API C. En el nostre cas, el simulador s’encarregarà de simular-ho tot, des de l’entorn fins al robot i els diferents sensors que l’integren. ROS es comunicarà amb ell mitjançant plugins que faran possible la integració, així com la comunicació entre controladors i altres elements en temps real. També es comunicaran mitjançant 38 6.1. INSTAL·LACIÓ 6.1.3 Instal·lació des del codi font En este tipus d’instal·lació ens encarregarem primerament de descarregar el codi font per posteriorment anar compilant aquells paquets que ens siguen necessaris. Este tipus d’instal·lació només és recomanable en el cas d’haver treballat prèviament amb ROS o haja de treballar necessàriament sobre versions trunk1ja que pot resultar confús i pesat el satisfer correctament totes les dependències per a disposar d’un sistema estable. Primerament instal·larem les ferramentes bàsiques que ens seran necessàries al llarg de la compilació. sudo apt-get install build-essential python-yaml cmake subversion wget python-setuptools mercurial Tot seguit ens serà necessari rosinstall, una ferramenta que s’encarrega de comprovar canvis al codi font de ROS a partir de múltiples repositoris de control de versions i actualitzar-los segons convinga. sudo easy_install -U rosinstall Per finalitzar esta primera part, baixarem el codi que quedarà desat al fitxer que li indiquem,en el nostre cas: /opt/ros/diamondback. Com sempre recomanem baixar la versió completa per evitar descarregar després el màxim de paquets a mà. rosinstall /opt/ros/diamondback "http://packages.ros.org/ cgi-bin/gen_rosinstall.py?rosdistro=diamondback&variant= desktop-full&overlay=no" Una vegada amb açò baixat ens serà necessari compilar executant l’orde següent. Esta, s’encarregarà de compilar el codi buscant les dependències necessàries ordenadament. rosmake * --rosdep-install 1Al camp del desenvolupament de software, es refereix a la branca sense etiqueta (versió) d’un arbre de fitxers. Normalment és la base del projecte i és on els desenvolupadors incorporen les ultimes novetats. 45 CAPÍTOL 6. IMPLEMENTACIÓ 6.2 Model URDF El primer que férem una vegada instal·làrem el sistema i tinguérem clars els conceptes bàsics de ROS va ser crear el model URDF del robot mòbil Guardian. Per fer més senzilla la feina, començàrem per dissenyar un model simple del robot i el descomposàrem en el mínim possible de parts, quatre rodes i un bastidor. Primerament creàrem el bastidor: <?xml version="1.0"?> <robot name="guardian"> <link name="chassis"> <inertial> <mass value="20.0" /> <origin xyz="0 0 0" /> <inertia ixx="1" ixy="0" ixz="0" iyy="1" iyz="0" izz="1"/> </inertial> <visual> <origin xyz="0 0 0" rpy="0 0 0" /> <geometry> <box size="0.5 0.75 0.2" /> </geometry> </visual> <collision> <origin xyz="0 0 0" rpy="0 0 0 " /> <geometry> <box size="0.5 0.75 0.2" /> </geometry> </collision> </link> <gazebo reference="chassis"> <material>Gazebo/Red</material> <turnGravityOff>false</turnGravityOff> </gazebo> </robot> Com podem observar, es segueix l’estructura que hem comentat en l’apartat corresponent a l’URDF: •Inertial: A esta secció definim la cinemàtica i dinàmica del cos. En este cas hem creat un bastidor de 20kg de pes amb una inèrcia estàndard definida en l’etiqueta inertia. 46 6.2. MODEL URDF •Visual: A visual donarem forma al cos que estem creant. Ací com podem vore creem un objecte de tipus “box” (caixa) amb unes mides de 0’5 en l’eix x, 0’75 en l’y i 0’2 en el z. Açò ens crearà un rectangle 3D. •Colision: En esta etiqueta definim quin volem que siga l’objecte que utilitze el simulador per al model de col·lisions. Generalment no canvia respecte al definit a l’estructura visual. •Gazebo: Esta etiqueta especial per al simulador Gazebo ens permet configurar paràmetres que d’altra manera no podrien ser visualitzats amb este simulador, com per exemple el color, plugins, sensors, friccions dels diferents elements, material o inclús si està activa o no la física del simulador sobre este objecte en concret. Una vegada creat el bastidor haguérem de crear les 4 rodes del vehicle, explicarem com creàrem una d’elles (la roda trasera esquerra, per exemple) i com la connectàrem amb el bastidor: <link name="back_left_wheel"> <inertial> <mass value="1.0" /> <origin xyz="0 0 0" /> <inertia ixx="1" ixy="0" ixz="0" iyy="1" iyz="0" izz="1" /> </inertial> <visual> <origin xyz="0 0 0" rpy="0 0 0" /> <geometry> <cylinder radius="0.125" length="0.2" /> </geometry> </visual> <collision> <origin xyz="0 0 0" rpy="0 0 0 " /> <geometry> <cylinder radius="0.125" length="0.2" /> </geometry> </collision> </link> <gazebo reference="back_left_wheel"> 47 CAPÍTOL 6. IMPLEMENTACIÓ <mu1 value="100.0" /> <mu2 value="10.0" /> <kp value="1000000.0" /> <kd value="1.0" /> <material>Gazebo/Grey</material> <turnGravityOff>false</turnGravityOff> </gazebo> Com vegem, no hi ha diferències aparents respecte al model anterior, però si ens fixem, vegem que el pes i la forma varien ja que per a este model simplificat hem utilitzat cilindres d’un kilogram de pes per simular les rodes. També cal destacar que hem introduït per primera vegada les etiquetes mu1,mu2,kp ikd. Estes etiquetes, corresponents als coeficients de fricció, el valor de rigidesa del contacte i el de l’armortiguació, respectivament, s’utilitzen per al càlcul físic en el motor del simulador. Convé posar uns valors adequats i provar el major nombre de configuracions possibles per tractar d’ajustar-los el màxim al comportament del robot real. Una vegada creats estos dos cossos (links), hem de juntar-los mitjançant una articulació (joint). Esta operació és una de les més dificultoses del modelat URDF i convé posar atenció per a que l’articulació resultant tinga el moviment desitjat. Presentem ací l’articulació creada: <joint name="joint_back_left_wheel" type="continuous"> <parent link="chassis"/> <child link="back_left_wheel"/> <origin xyz="-0.35 -0.375 0" rpy="0 1.5708 0" /> <axis xyz="0 0 1" /> </joint> A la capçalera definirem el nom i el tipus d’articulació. Podem triar entre sis tipus d’articulació (revolute,continuous,planar,fixed,primastic ifloating). En el nostre cas, com volem simular una articulació sense límits superiors ni inferiors utilitzarem el tipus continuous. A continuació relacionarem els dos elements, en el nostre cas el pare serà l’element “chassis” creat al principi i el fill la roda trassera esquerra. Tot i que ja queden relacionats els dos cosos, en cas de deixar-ho així apareixerien els dos elements situats al centre de la simulació, per a això, definim el punt d’origen de l’articulació amb les coordenades xyz. També haurem de modificar a eixa mateixa etiqueta les orientacions respecte a cada angle (rpy), ja que de no canviar-ho tindriem la roda i el bastidor a un mateix planol. Per últim definim la direcció dels eixos en el marc de referència de l’articulació. Una vegada explicat açò, només hem de repetir el procés en les tres rodes restants per conseguir un model aproximat del robot a simular. El resultat esquematitzat i al simulador serà el següent: 48 6.2. MODEL URDF Figura 6.1: Primera versió del URDF de forma esquematitzada i al simulador Gazebo. Arribats a este punt és convenient revisar l’aspecte visual i físic del robot. Gràcies a ferramentes de disseny assistit per computador, com per exemple SolidWorks o AutoCAD podem obtenir fitxers .stl. Este tipus de fitxers, descriuen únicament la geometria de la superfície del model, sense cap resprentació del color, la textura o altres artibuts CAD comuns, no obstant, ens donen un aspecte més aproximat del que és l’aspecte del robot real. Gràcies també a estos programes podem obtenir fàcilment les matrius d’inèrcia de cada objecte, cosa que ens serà imprescindile per a una simulació realista. Per a incloure estos canvis només hem d’afegir i canviar unes quantes línies. En el cas de la inèrcia posarem a l’etiqueta “inertia” de l’apartat “inertial” els valors corresponents a cada sòlid que hagem obtés. Per altra banda, respecte als elements visuals haurem de canviar el que abans eren “box”, “cylinders” o “sphere” per l’etiqueta “mesh”, que ens permet introduir una malla com l’arxiu .stl que abans comentàvem a l’escala que desitgem. L’etiqueta “geometry” de l’apartat visual i de col·lisions quedarà d’una forma semblant a açò: <geometry> <mesh filename="package://guardian_description/meshes/chassis.stl"/> </geometry> Amb estos senzill canvis aconseguirem un model més realista tant física com visualment: 49 CAPÍTOL 6. IMPLEMENTACIÓ Figura 6.2: Model URDF millorat. Vista normal i vista de la física amb Gazebo. 6.3 Programació del controlador P en temps real En esta secció ens ocuparem de la programació del controlador en temps real per al moviment del robot. Esta secció pot ser siga la part més complicada del procés de programació del nostre robot en ROS i més encara en quan estem fent-ho sobre una simulació ja que es combinaran conceptes avançats de ROS amb altres de Gazebo per poder relacionar els dos sistemes. Per fer més comprensible esta secció anem a dividir-la en dos parts. A la primera descriurem de manera detallada la stack pr2_mechanism. Com ja hem comentat abans, molts dels elements que incorpora este robot acaben sent l’estàndard de facto en la programació d’altres i ací tinguem el millor exemple. Esta classe s’encarrega de definir l’estructura d’un control en temps real sobre ROS. Al següent apartat explicarem de forma pràctica el nostre cas i com ho férem per seguir l’estàndard anterior i aplegar a disposar d’un controlador per a les rodes del robot i que este fora controlable mitjançant referències de velocitat. 50 6.3. PROGRAMACIÓ DEL CONTROLADOR P EN TEMPS REAL 6.3.1 La pila pr2_mechanism Esta pila conté la infraestructura necessària per controlar el robot PR2 (o qualsevol similar) en un bucle de control en temps real. Conté biblioteques molt útils per escriure un controlador en temps real amb el que es puga interactuar amb ell. Les biblioteques que ens seran més útils estan contingudes en el següents paquets: •pr2_controller_interface: L’interfície en C++ per a un controlador en temps real. •pr2_controller_manager: Infraestructura que permet executar i controlar diferents controlador en un bucle en temps real. •pr2_mechanism_model: Implementa el model d’un robot controlat per esforç, per això, es basa en el model URDF d’aquest. •pr2_hardware_interface: L’interfície en C++ per al hardware del PR2, des d’actuadors fins a accelerometres, sensors de pressió i més. Només útil en cas de no estar simulant. Podem vore dues parts clarament diferenciades però imprescindibles a l’hora d’escriure un controlador d’este tipus en ROS, una en la que es tracta la gestió del temps real (paquets pr2_controller_interface ipr2_controller_manager) i una altra on es controla la part física del robot (paquets pr2_hardware_interface i pr2_mechanism_model). Pel que fa a la gestió del temps real hem d’indicar que ROS no és, en principi, un framework que suporte al 100% el temps real. Ara bé, existeixen ferramentes com el Controller Manager (paquet pr2_controller_manager) que ens permet executar una infraestructura capaç de executar controladors en un bucle de temps real. En cada cicle d’este bucle, tots els controladors carregats al Controller Manager seran llançat segons l’ordre establert per un planificador2intern que este proporciona. Esta ferramenta proporciona servicis ROS per poder carregar, llançar, parar i descarregar els controladors als CM. Vist des d’una altra perspectiva, tot el graf seguirà executant-se i passant-se informació de forma habitual en un entorn de temps no-real, mentre que per una altra disposarem d’un xicotet mòdul on tot el que s’execute dins satisfarà les regles del temps real. La comunicació entre el que s’executa a l’interior del CM i el que hi ha fora d’este entorn de temps real es farà mitjançant el tòpic /joint_state, on es publicarà un missatge del tipus sensor_msgs/JointState a una freqüència de 100Hz. Arribats a este punt podem suposar que la classe que defineix la interfície per a qualsevol controlador en temps real que haja d’executar-se sobre el Controller Manager 2La funció del planificador és repartir el temps disponible d’un microprocessador entre tots els processos que estan a l’espera de ser executats. 51 CAPÍTOL 6. IMPLEMENTACIÓ Figura 6.3: Estats d’un controlador serà la pr2_controller_interface. Per implementar esta interfície el nostre controlador haurà d’heretar de la classe base pr2_controller_interface::Controller i implementar obligatòriament estos quatre mètodes: •init(): És el mètode serà l’encarregat d’inicialitzar el controlador quan el carreguem al CM, tot açò en temps no-real. És important destacar la diferència entre inicialitzar (init) i executar (starting) un controlador, ja que la inicialització pot realitzar-se prou abans de que el controlador vaja a ser executat. El mètode init() pren dos arguments, robot (que es tracta d’un pr2_mechanism_model::RobotState, classe encarregada de descriure el model mecànic del robot, més endavant parlarem d’ell) i n(un manejador del node del controlador en qüestió del tipus ros::NodeHandle) •starting(): Este mètode s’executa cada volta que el CM executa un controlador. •update(): A este mètode és on es fa la vertadera feina de control i serà cridat periòdicament pel CM a una freqüència de 1000Hz. •stop(): S’executarà cada volta que el CM ordene parar un controlador, esta parada es farà efectiva en el mateix cicle que l’ultima cridada a update(), immediatament després de que esta haja sigut cridada. Figura 6.4: Flux d’execució a un controlador. Com hem vist més amunt, la relació entre el temps real i la mecànica del robot es farà a l’hora d’inicialitzar el controlador gràcies a la classe pr2_mechanism_model però, que és exactament este paquet i que ens proporciona? 52 6.3. PROGRAMACIÓ DEL CONTROLADOR P EN TEMPS REAL El paquet pr2_mechanism_model conté la classe C++ pr2_mechanism_model ::RobotState la qual ens proporciona una interfície a les articulacions del robot i una descripció del model d’aquest. El següent gràfic mostra com participa el model mecànic tant en el robot real com en simulació. Figura 6.5: Model mecànic del robot i la seua relació tant en simulació com al robot real. Com podem deduir esta classe és molt extensa i una vegada més anem a remetre a la documentació oficial per a més informació. De totes maneres anem a fer una vista general del que suposa esta classe centrant-nos en el que més anem a utilitzar a l’hora de simular. •pr2_mechanism_model::RobotState: Com ja hem dit abans, quan un controlador s’inicialitza, el CM passa al controlador un punter al RobotState. Este descriu el model cinemàtic i dinàmic del robot en l’estat actual. Aquest estat queda definit per la posició, velocitat i esforç de cadascuna de les articulacions del robot, que obtindrem de l’URDF dissenyat prèviament. •pr2_mechanism_model::JointState: Donat que el model mecànic del 53 CAPÍTOL 6. IMPLEMENTACIÓ robot es basa en l’estat de les articulacions, estes seran imprescindibles a l’hora de controlar-lo. Les articulacions ens proporcionaran les dades necessàries (paràmetres position ivelocity) per realitzar els càlculs de control, que una vegada efectuats, podrem fer que actuen sobre elles senzillament modificant el paràmetre effort. Suposarem este model de caixa negra que més endavant serà explicat. 6.3.2 Programant el nostre controlador Com hem vist programar un controlador en temps real en ROS no és senzill, ja que s’ha de tenir en compte i seguir una estructura predefinida i algunes vegades un poc confusa. No obstant l’esforç paga la pena, ja que una volta programat, és molt fàcil comunicar-se amb ell i amb la garantia de que s’executarà en temps real. Per dissenyar el nostre controlador ens basarem en el tutorial “Writing a realtime joint controller”3, disponible a la wiki de ROS i al que baix fem referència. En este tutorial se’ns mostra la manera estàndard de programar un controlador en temps real que afegirem al Controller Manager com si es tractara d’un plugin. El diagrama que seguirem serà el següent: Figura 6.6: Diagrama a seguir en la programació del controlador. En la primera fase del disseny començarem per crear un fitxer de capçaleres .h que continga la interfície del nostre programa: variables, mètodes, i declaracions públiques i privades d’estos, entre altres. Com ja vam dir a l’anterior secció, el controlador haurà de satisfer la pr2_controller_interface per a que puga ser llançat per un Controller Manager, per això esta classe haurà d’incloure a la seua capçalera esta referència a més d’altres que seran necessàries per la representació del model cinemàtic/dinàmic del robot, el seu control i navegació. #include <pr2_controller_interface/controller.h> #include <pr2_mechanism_model/joint.h> #include <geometry_msgs/Twist.h> #include <tf/transform_broadcaster.h> #include <nav_msgs/Odometry.h> 3http://www.ros.org/wiki/pr2_mechanism/Tutorials/Writing%20a%20realtime%20joint%20controller 54 6.5. AFEGINT ALTRES DISPOSITIUS AL NOSTRE MODEL URDF 6.5 Afegint altres dispositius al nostre model URDF Fins ara, el nostre model URDF només contenia quatre tipus diferents d’elements: els joints, els links, les etiquetes referides al simulador Gazebo i el plugin per integrar el Controller Manager en la simulació. Tot i que amb estos elements ens és suficient per a simular qualsevol robot mecànica i físicament, no podem incorporar sensors i càmeres si no contem amb els plugins corresponents. A esta secció explicarem com afegir detalladament un làser Hokuyo URG-04LX, una IMU i una càmera per visualitzar per on avança el robot. 6.5.1 Làser Primerament, crearem un link/cos que serà el punt del robot des d’on es capturaran les dades. Idealment seria un cub el més xicotet possible i situat allà on volem que el làser siga visible. Per relacionar este nou link amb el bastidor del robot crearem un nou joint que ho faça, sempre tenient el compte el mantenir l’estructura d’arbre que propugna el model URDF. Una vegada fet açò el làser ja podria capturar les dades des del punt anterior però si volem veure’l en la simulació haurem d’afegir els elements visuals necessaris per a fer-ho. Podríem haver posat simplement un cub, però hem agafat una malla (en format .stl com el bastidor del robot) d’un làser Hokuyo que hi ha als repositoris de ROS, així es mostrarà un làser a la simulació i no un simple punt des d’on es capturen les dades. Per últim, l’apartat més important, ací és on realment li donem al link/cos creat al principi les propietats d’un làser. Açò ho fem incorporant este fragment de codi a l’URDF: Com vegem es tracta novament d’un plugin per a Gazebo que carrega un controlador encarregat de recopilar les dades que van des d’un làser simulat i publicar-les en forma de sensor_msgs::LaserScan al tòpic que indiquem a l’etiqueta corresponent. A més del tòpic al qual es publica la informació, hem d’adaptar els diferents valors (minRange, maxRange, updateRange, minAngle i maxAngle) als del nostre sensor real/desitjat. 61 CAPÍTOL 6. IMPLEMENTACIÓ Figura 6.8: Laser ja instal·lat sobre el robot. Si ens fixem, és el punt negre des del qual ixen les línies blaves que representen gràficament el seu abast. 6.5.2 IMU Una IMU, sigles angleses d’Inertial Measurement Unit (unitat inercial de mesura) és un dispositiu electrònic que mesura velocitats, orientacions i forces gravitacionals fent uns d’una combinació d’acceleròmetres i giroscopis. En un sistema de navegació, les dades obtingudes per la IMU es transmeten a l’ordinador, qui calcula la posició actual basant-se en els diferents valors obtinguts (velocitats, temps, orientacions...). És un sistema molt fiable i per això ens serà molt útil de cara a l’aplicació dels algorismes de navegació al nostre robot simulat. Per a afegir una IMU al nostre robot procedirem igual que al cas anterior, amb la diferència de que ara no ens caldrà polir l’aspecte visual ja que estos dispositius solen situar-se normalment al centre i a l’interior dels robots. El plugin que utilitzarem en esta situació i que col·locarem a l’URDF és el gazebo_ros_imu i s’encarregarà de publicar un missatge del tipus sensor_msgs::Imu al tòpic que especifiquem. 62 6.5. AFEGINT ALTRES DISPOSITIUS AL NOSTRE MODEL URDF 6.5.3 Càmera També podem afegir càmeres al nostre robot simulat. Des d’estes podrem tindre una perspectiva subjectiva d’abord del robot o configurar-lo per a tasques de vigilància remota, entre altres. Com ja suposarem a estes altures, només haurem d’afegir el plugin del controlador necessari per disposar de la funcionalitat de la càmera que en este cas serà gazebo_ros_camera. Posem a continuació una captura de la simulació on puguem observar el robot i la imatge obtinguda desde la càmera. Per a obtenir este punt de vista només hem tingut que subscriure-nos al tòpic on hem definit que es publique la informació (/image_raw) mitjançant esta ordre: rosrun image_view image_view image:=/image_raw. Figura 6.9: Imatge obtinguda des de la càmera incorporada al robot. 6.5.4 Altres plugins Creguem interessant afegir una taula amb tots els plugins dels que disposa Gazebo. Com hem vist, la instal·lació no dista molt d’un model a un altre i les utilitats que es poden obtenir són molt variades. 63 CAPÍTOL 6. IMPLEMENTACIÓ Figura 6.10: Plugins dinàmics disponibles per al simulador Gazebo. 6.6 Integració amb la Navigation Stack La Navigation Stack és molt simple a nivell conceptual. Es tracta d’una pila que proporciona utilitats de navegació autònoma mitjançant diferents algorismes només prenent informació de l’odometria i dels sensors i actuant sobre la base mòbil del robot enviant referències de velocitat. A més, tota la navegació es farà de forma quasi transparent a nosaltres. No obstant, no és trivial fer funcionar la Navigation en qualsevol robot, sinó que l’haurem d’adaptar a l’estàndard de ROS i per a això se’ns exigirà el següent: •Que el robot funcione sobre ROS. •Que es dispose d’un arbre de tf (transformacions) consistent. •Que es publique la informació dels sensors utilitzant un format de missatges de ROS. A hores d’ara només disposem d’un base_controller (guardian_controller) que rep referències de velocitat per via teclat/joystick, a més d’un làser incorporat a la simulació que publica missatges del tipus sensor_msgs::LaserScan al tòpic hokuyo_laser_topic i una IMU simulada que fa el que li és propi amb missatges del tipus sensor_msgs::Imu i el tòpic imu_data. No obstant, encara ens falta per desenvolupar la odometria i les transformacions estàtiques del robot (distàncies entre els diferents elements, com per exemple entre la base i el làser). A partir d’ací dissenyarem estos dos nodes per a continuació descriure detalladament les configuracions dels dos algorismes disponibles en esta pila. 64 6.6. INTEGRACIÓ AMB LA NAVIGATION STACK Figura 6.11: Esquema de la configuració de la Navigation Stack. 6.6.1 Odometria Una bona odometria és fonamental en la navegació autònoma. Per fer-la possible dissenyarem un nou paquet anomenat guardian_odometry. Tot i que la funcionalitat del càlcul de l’odometria podia haver-se incorporat al mètode update() del controlador, creguem que d’esta forma es respecta més la filosofia modular de ROS així com es fomenta la claredat del codi. Este node tindrà accés al que hem definit com “encoders” del simulador, les variables del tipus pr2_mechanism_model::JointState, així que haurem d’especificar-ho a les dependències, com també ho farem amb els missatges de l’IMU, entre altres. Pel que fa a l’eixida, haurà de publicar transformacions i missatges d’odometria, així que incorporarem les dependències corresponents a la capçalera. Una vegada clara l’entrada/eixida del node, podem definir la seua funcionalitat. Este, esperarà missatges JointState i d’Imu mitjançant dos callbacks declarats només s’inicia el node. Arribats a este punt hem d’aclarir una cosa important. Si no ens hem perdut en l’explicació, sabrem que els missatges del tipus JointState ofereixen la velocitat, esforç i posició de cada articulació d’una forma precisa. Tenint estos valors i sabent que la posició del nostre mòbil queda definida pel centre de les quatre rodes podríem directament obtenir una posició quasi perfecta i publicar-la en forma de missatge d’odometria sense fer cap càlcul cinemàtic. No obstant, em volgut cenyir-nos el màxim possible a la realitat, i tot i que podríem fer el que hem comentat i tenir una odometria més precisa, preferim només obtindre la velocitat de les articulacions, com si de la informació obtinguda d’un encoder es tractara per, amb açò i les fórmules adequades obtenir la posició aproximada del robot. Una vegada aclarit açò continuem amb el disseny del node. Este tindrà per eixides uns publicadors de missatges d’odometria i un broadcaster per als missatges de les transformacions. 65 CAPÍTOL 6. IMPLEMENTACIÓ ros::Subscriber joint_subs = n.subscribe("/joint_states", 1, jsCb); ros::Subscriber imu_subs = n.subscribe("/imu_data", 1, imuCb); ros::Publisher odom_pub = n.advertise<nav_msgs::Odom>("/odom", 100); tf::TransformBroadcaster odom_broadcaster; La resta del codi d’inicialització s’encarrega de les variables de posició (px, py, pa) així com algunes variables auxiliars per a la gestió del temps o físiques com la separació entre rodes i el diàmetres d’estes. Pel que fa al bucle principal, és on es farà el càlcul de l’odometria i s’executarà cíclicament cada volta que es reba un missatge. A este node es calcularan les velocitats de les rodes esquerres i dretes del mòbil, tal i com descriu el model cinemàtic diferencial del robot i a partir d’estes s’obtindrà la velocitat lineal. Pel que fa a la velocitat angular, donat que es tracta d’una simulació i resulta quasi impossible ajustar els paràmetres de fricció en el terra com al món real, obtindrem esta velocitat directament gràcies a la IMU. Una vegada tinguem descrit el robot per estes dos velocitats, podem obtenir fàcilment la posició aplicant una senzilla operació del moviment diferencial. // Compute Velocity vx = linearSpeedMps_ * cos(robot_pose_pa_); vy = linearSpeedMps_ * sin(robot_pose_pa_); // Compute Position robot_pose_pa_ += ang_vel_z_ * fSamplePeriod; robot_pose_px_ += vx * fSamplePeriod; robot_pose_py_ += vy * fSamplePeriod; Per últim, amb estes dades de la posició en l’instant actual calculades, creem els missatges de tf i odometria (completant tots els camps, des dels referents a velocitats i posicions fins als referents a temps i informació sobre qui és el marc que ho publica) i els enviem pel respectiu publicador/broadcaster. Amb açò tindrem disponible un node que publique missatges del tipus nav_msgs::Odometry igeometry_msgs::TransformStamped. 6.6.2 Transformacions estàtiques Com ja hem explicat en l’apartat corresponent als conceptes d’alt nivell de ROS, les transformacions permeten establir les relacions entre els diferents marcs coordinats mitjançant una estructura d’arbre i emmagatzemant-les en el temps, açò permet a l’usuari transformar qualsevol punt, vector o informació d’un marc coordinat a un altre, inclús en qualsevol moment passat desitjat. Este, com l’anterior, és un node que haguérem pogut “evitar”, ja que existeix un node a les llibreries de ROS que s’encarrega d’açò amb un simple pas de paràme66 6.7. CONFIGURANT LA NAVIGATION STACK tres, el static_transform_publisher, però que per clarificar conceptes i arribar a l’interior del llenguatge hem preferit programar nosaltres de zero. L’únic que farà este node és, iniciar-se i limitar-se a publicar amb el rati que especifiquem les transformacions estàtiques del robot, és a dir, un bucle infinit mentre el node estiga en execució. En el nostre cas, i conforme s’estableix a les REP5’s, ens faran falta dos transformacions, la que va del chassis_footprint al chassis (anomenat bastidor, fins ara) i la que va d’este últim al làser. La primera transformació és un més dels requeriments de l’adaptació a la Navigation Stack i només serà la distància entre els dos elements (que en efecte només estaran separats una distància en l’eix z). Per altra banda, la segona transformació serveix per una vegada obtingudes les dades del làser aplicar una “correcció” per a que el controlador de la base puga fer-ne ús, cosa que em explicat de manera detallada a l’apartat teòric de les transformacions. A continuació el codi amb que implementem l’explicat: 6.7 Configurant la Navigation Stack Una vegada en este punt anem a fer un resum de tot els nodes i elements que tenim en relació a la navegació. Disposem d’un node controlador (guardian_controller) que rep missatges amb referències de velocitat. També tenim un làser simulat que publica la informació d’allò que escaneja en la simulació de forma estandarditzada al tòpic hokuyo_laser_topic així com una IMU també simulada i que envia informació al tòpic imu_data. A la secció anterior acabem de dissenyar dos nodes, un que publicarà la odometria (guardian_odometry) i la transformació relacionada amb esta i un altre que publicarà les transformacions estàtiques (guardian_tf ). Si ens fixem en la Figura 6.11 de més amunt, vorem com ja estem preparats per configurar la navegació autònoma ja que el paquet move_base té tots els requeriments acomplits. Però, que és exactament este paquet? 6.7.1 El paquet move_base El node move_base proporciona la interfície ROS per configurar, executar i interactuar amb la Navigation Stack d’un robot, podríem dir que es tracta del component principal d’esta. D’una forma més tècnica, move_base proporciona la 5ROS Enhancement Proposals. Són uns documents on s’estableix d’una manera completa l’estil que hauria de tenir la programació en ROS 67 CAPÍTOL 6. IMPLEMENTACIÓ implementació d’una acció (més informació al paquet actionlib) que donat un objectiu en el món, intentarà assolir-lo movent la base mòbil del robot. Este node, conté internament dos planificadors per a fer possible les tasques de navegació, el global i el local, que estudiarem més endavant. A continuació anem a descriure els diferents elements que composen este paquet i de quina forma han estat implementats. Recovery Behaviours (Comportaments de recuperacio) Quan executem el node move_base el resultat serà que este intente assolir la posició objectiu amb la base conforme a la tolerància que haja especificat l’usuari prèviament. Este node pot de manera opcional realitzar un comportament de recuperació quan el robot es perceba encallat. En eixe cas, move_base efectuarà per defecte el següent algoritme. En primer lloc, els obstacles fora de la regió especificada per l’usuari s’esborraran del mapa intern del robot. Després, si es possible, el robot efectuara una rotació sobre si mateix per aclarir l’espai que l’envolta. Si açò també falla, el robot efectuara un aclariment més agressiu del mapa, eliminant tots els obstacles fora de la regió rectangular sobre la qual pot rotar sobre si mateix. Açò vindrà seguit per una altra pivotació sobre si mateix. Si tot açò falla, el robot considerarà el seu objectiu com inassolible i notificarà a l’usuari que ha avortat la navegació. Estos comportaments de recuperació poden ser configurats, així com desactivats mitjançant els paràmetres recovery_behaviors irecovery_behavior_enabled. Figura 6.12: Comportaments de recuperació per defecte de move_base. Una vegada estudiat quin és el comportament que s’espera d’este important node anem a estudiar els diversos elements que el composen: Costmaps (mapes de costos) La Navigation Stack fa ús de dos mapes de costos (el local i el global) per emmagatzemar la informació sobre els obstacles. El global_costmap s’utilitza per a la 68 6.7. CONFIGURANT LA NAVIGATION STACK planificació global i crea planificacions a llarg terme sobre l’entorn complet mentre que el local_costmap serà utilitzat per a evitar obstacles. Hi ha algunes opcions de configuració que seria convenient que els dos costmaps compartiren i d’altres que només ens interessa que estiguen establertes a cada mapa individual i per tant, la configuració dels costmaps es farà en tres fitxers diferent on s’emmagatzemaran en cadascun les opcions de configuració comuns, les globals i les locals. A la Figura 6.13 mostrem els diferents fitxers de configuració al nostre robot i remitim una vegada més a la wiki6corresponent per a una explicació completa dels diferents paràmetres. Figura 6.13: Els tres tipus de costmaps. Local Planner (planificador local) El planificador local és el responsable de generar les comandes de velocitat que seran enviades a la base mòbil del robot i que seguiran una planificació local (local_plan). El local_planner té en compte tant la cinemàtica com la dinàmica del robot i utilitzarà la informació dels sensors per dur a terme una navegació segura. 6http://www.ros.org/wiki/costmap_2d 69 CAPÍTOL 6. IMPLEMENTACIÓ Global_Planner El planificador global (global_planner) és el responsable de generar una planificació d’alt nivell per a la Navigation Stack. Donat un objectiu situat lluny del robot, este planificador crearà una sèrie de “waypoints” que el planificador local haurà de seguir. La implementació actual de la Navigation Stack utilitza un planificador global basat en una malla que assumeix que el robot té forma circular, tot i que açò ultim es pot modificar. Això significa que el planificador global produirà punts que encaixen i puguen ser seguits pel footprint (projecció del robot al plànol base, per exemple en el cas del robot Guardian serà un rectangle mentre que en el cas d’un robot Roomba un cercle) d’este definit prèviament, però també podrà generar-ne d’altres que siguen inassolibles per a este i ací és on entrarà en joc el planificador local. També cal indicar, que el planificador global no té en compte la dinàmica del robot, així que també es poden general plans inassolibles dinàmicament parlant. 6.7.2 Tipus de navegació Una vegada arribats a este punt ja tenim la Navigation Stack quasi configurada. No obstant, encara falta seleccionar la forma que tindrà el robot de posicionarse/localitzar-se en el mapa. Podem dir que hi ha dos formes de fer açò, el posicionament local (basat únicament en la odometria) i el posicionament mitjançant mapes (ja siguen preestablerts o generats simultàniament). A continuació descriurem com configurar la Navigaton Stack per a cada tipus de navegació. Local La navegació local està implementada “per defecte” per la Navigaton Stack ja que esta només utilitza la odometria del robot per localitzar-se. En esta navegació no hi ha cap tipus de mapa i per tant no es generarà cap ruta global. El robot farà servir els sensors per, conforme vaja aproximant-se al seu objectiu evitar els possibles obstacles. AMCL Si ens fixem en la Figura 6.11 vegem que hi ha dos nodes que apareixen de color gris i que segons l’esquema son opcionals (map_server iamcl), açò és perquè com vorem, la navegació mitjançant localització AMCL proporciona una millor experiència que la basada únicament amb l’odometria, però no és imprescindible per a utilitzar la pila com ja hem vist en la secció anterior. L’explicació teòrica de com 70 7.1. ARQUITECTURA •En compte d’haver una teleoperació on s’envien directament les ordres, hi ha un tòpic anomenat /move_base_node/goal que s’encarregarà de rebre la posició objectiu. •Una vegada que el node move_base efectue el càlcul, passarà la informació amb les referències de velocitat per a aplegar a l’objectiu mitjançant el tòpic de habitual (/guardian_controller/command). •En cas de que s’utilitze algun algorisme de localització (amcl oslam) el node corresponent s’encarregarà de publicar les transformacions respecte al mapa, cosa que al gràfic no apareix ja que per motius d’espai preferirem mostrar una navegació local. La forma en que podem visualitzar i interactuar sobre qualsevol navegació autònoma és mitjançant rviz. Podem subscriure’ns a gran quantitat de tòpics que move_base ofereix, així com actuar sobre ells (molt important per facilitat les coses en els objectius/goals i la posició/pose). 7.1.2 Nivell de sistema de fitxers A esta secció anem a descriure el sistema de fitxers resultant, és a dir com s’han organitzat els diferents paquets i quina utilitat s’espera de cadascun d’ells. El nivell superior d’organització d’este sistema serà la stack. Esta s’anomena guardianros-pkg i la podrem trobar disponible al nostre repositori1. Este nivell conté els sis paquets que conformen el sistema així com el fitxer manifest de la pila, anomenat stack.xml. A continuació descriurem els paquets en qüestió: •guardian_2dnav: Este paquet conté tots els necessari per llançar les diferents navegacions autònomes al robot: AMCL, SLAM i local. Disposa d’una carpeta anomenada maps on s’emmagatzemen els mapes que poden ser utilitzats en localització, així com d’una carpeta per cada tipus d’esta. A l’interior d’estes, es troben els fitxers de configuració específics per a cadascuna d’elles. •guardian_controller: Este és un dels paquets més importants del robot. En ell s’aplica el bucle de control sobre les rodes, es relacionen estes amb el seus actuadors corresponent així com és s’habilita per rebre ordres pel teclat o el joystick. A l’interior del paquet trobem dos carpetes, una anomenada /include on trobem les capçaleres del controlador i altra /src, on trobarem el codi font que implementa estes capçaleres. També trobarem diversos fitxers de configuració per a habilitar-lo com a plugin, estos són controller_plugins.xml iguardian_controller.yaml. No hem d’oblidar que com tots els paquets, es disposarà dels típics fitxers manifest.xml,CMakeList iMakefile. 1http://code.google.com/p/guardian-ros-pkg 77 CAPÍTOL 7. DESCRIPCIÓ DEL TREBALL REALITZAT •guardian_description: Ací es contenen els models URDF del robot, les meshes2i els diferents elements gràfics que trobem a la simulació, com cartells, taules, cadires... El paquet està dividit en cinc carpetes. Destaquem la carpeta /launch perquè es on es contenen els fitxers necessaris per iniciar el robot tres maneres predisenyades diferents: amb l’entorn de Robotnik, amb un entorn buit o directament sense controlador. •guardian_joystick_teleop: Node que permet la utilització d’un joystick per controlar el robot Guardian. Com ja s’ha comentat anteriorment està pensat per al joystick Logitech Freedom 2.4 però es pot i es permet adaptar fàcilment a altres dispositius. A l’interior d’este paquet trobem dos carpetes, la /src on trobarem el codi i la /launch on es troba el fitxer necessari per iniciar còmodament este node. •guardian_odometry: Calcula l’odometria del robot basant-se en el moviment de les rodes i certs valors de la IMU. Publica finalment l’odometria al tòpic /odom. Este paquet conté solament una carpeta anomenada /src i els respectius fitxers habituals que contenen tots els paquets: manifest.xml, CMakeList iMakefile. •guardian_tf: Publica les transformacions estàtiques (relatives al bastidor del robot) al tòpic /tf. Segueix la mateixa estructura que el paquet que implementa la odometria amb una carpeta /src i els fitxers habituals. 7.2 Interacció amb la comunitat de software lliure Ja hem comentat anteriorment que ROS compta amb una important comunitat. Esta es dedica a donar suport a iniciats amb el framework, resoldre dubtes, escriure guies, compartir software, resoldre i detectar bugs, entre altres. Per a introduirnos en esta comunitat podem fer-ho de moltes formes, depenent del nostre nivell, experiència o voluntat de dedicació. A continuació ens referim a les més importants. •ROS Wiki: La wiki de ROS. D’ací és d’on hem obtingut la major part de la informació. És una pàgina molt completa que va actualitzant-se cada dia per part de desenvolupadors i usuaris. Compta amb una gran quantitat de guies i tutorials, des dels més senzills i generals fins els més complexos i específics. •ROS Answers: És el primer lloc on podem acudir quan una cosa no ens funciona tal i com esperàvem. Podem fer tot tipus de preguntes, des de les més tècniques (requeriments hardware, instal·lacions...) passant per les centrades en el llenguatge fins a les més teòriques. Cal remarcar que en març del 2011 2Malles en format .stl per donar un aspecte realista al robot. 78 7.2. INTERACCIÓ AMB LA COMUNITAT DE SOFTWARE LLIURE comptava amb uns 300 missatges i a dia de hui (setembre del mateix any) ronda els 2000. •ROS Users: És una llista de correu per als usuaris de ROS. Útil per a preguntes que no hagen obtingut resposta a Answers. També és un bon lloc per a comunicar-se directament amb els desenvolupadors, així com anunciar nous repositoris i actualitzacions. •ROS Code: Lloc on reportar bugs, propostes de millores o inclús on podem proposar les nostres pròpies solucions software si tenim el nivell suficient. Pel que fa a la nostra experiència començàrem utilitzant la Wiki, bàsicament per seguir manuals introductoris, tutorials i guies. No obstant, prompte començaren a aparèixer els primers problemes, la majoria d’ells resolts efectuant cerques sobre Answers o directament preguntant. Més tard, quan ja teníem el model URDF dissenyat i el controlador implementat detectarem un problema. Quan féiem pivotar el robot sobre si mateix este es frenava en el moment en que s’alineava en qualsevol dels eixos de coordenades del món simulat. A peu de pàgina es troba el link a la pregunta3que formulàrem en ROS Answers, on podem trobar també videos explicatius. Figura 7.2: Problema de rotació detectat. Recomanem visualitzar els videos per a una millor comprensió. Després de moltes proves i canvis en els paràmetres dels coeficients de fricció de les rodes en el terra no trobarem solució. Més endavant, i per confirmar que no es tractava d’un error en el controlador implementat, férem totes les proves anteriors efectuant el gir actuant sobre les rodes directament (amb l’ordre apply_joint_effort) i sense el controlador, amb la qual cosa el robot seguia comportant-se de la mateixa manera. Veient que no trobàvem cap resposta, decidirem posar-nos en contacte 3http://answers.ros.org/question/607/rotation-error-in-gazebo-simulation 79 CAPÍTOL 7. DESCRIPCIÓ DEL TREBALL REALITZAT directament amb el mantenidor del simulador Gazebo, John Hsu, enginyer sènior aWillow Garage. Li enviarem el codi font i li explicarem totes les proves que havíem fet. Al cap d’un dies rebem una resposta on ens explica que està tenint els mateixos problemes. Ja passades unes setmanes, rebem un correu on ens explica que Gazebo no implementa correctament la física del motor ODE pel que fa a les friccions en el terra. El simulador només té en compte una direcció quan calcula la fricció, però no la seua perpendicular, cosa que si que té en compte el motor ODE, però no el simulador, amb la qual cosa està obviant la fricció perpendicular i per la qual està fallant sempre que efectua una pivotació sobre si mateix. Al cap d’uns dies rebem resposta amb els canvis que permeten que el simulador transmeta correctament estos paràmetres al motor físic. Per provar-los haguérem de reinstal·lar ROS per a fer una instal·lació neta i des dels fitxers fonts, cosa que ens permetria incorporar els canvis proposats abans de compilar. Una vegada fet açò, el resultat fou l’esperat i conjuntament amb els desenvolupadors de Willow Garage havíem aconseguit resoldre un bug de Gazebo, bug que a la pròxima versió d’este simulador ja no estarà. Més endavant, detectarem una errada similar. Segons el motor ODE les articulacions “mímiques” estan permeses (una articulació imita el moviment d’una altra) però Gazebo no ho implementa. Ja que detectarem el problema i veient que encara no s’havia reportat, decidirem enviar-lo4aROS Code, per si a algún desenvolupador s’animava a solucionar-lo de cara a la nova versió del simulador. Per acabar i com no pot ser d’altra manera, una vegada tinguérem prou depurat i provat el nostre codi, decidirem posar-lo a disposició de tot el món pujant-lo a un repositori svn5aGoogle Code. Des d’ací qualsevol usuari de ROS es pot descarregar el nostre codi, proposar canvis, posar-se en contacte amb nosaltres o documentar-se sobre el robot. El fet de tindre un respositori tant complet dona dret a aparèixer al llistat i menú de robots que utilitzen ROS a la pàgina oficial, tal i com podem vore ací6. 7.3 Exemples i guies d’utilització A esta secció anem a exemplificar a mode de guia les cinc formes diferents que hi ha de controlar la simulació del robot Guardian. Podem vore dos grans maneres de fer-ho: controlar-lo via teleoperació (ja siga en teclat o joystick) o mitjançant la Navigation Stack (utilitzant el posicionament local,AMCL oSLAM). Anem 4https://code.ros.org/trac/ros-pkg/ticket/5005 5Subversion és un sistema de control de versions dissenyat específicament per reemplaçar el popular CVS. 6http://www.ros.org/wiki/Robots 80 7.3. EXEMPLES I GUIES D’UTILITZACIÓ a suposar durant tota la secció que farem les proves en l’escenari/món creat en la secció 6.8. que es correspon amb les instal·lacions de l’empresa Robotnik. 7.3.1 Teleoperació mitjançant teclat Per a teleoperar el robot mitjançant el teclat només haurem d’executar dos senzilles ordres a diferents pestanyes d’una terminal, la primera per carregar el món i el robot, i la segona per executar el node del teclat. roslaunch guardian_description guardian_robotnik.launch roslaunch guardian_controller teleop_keyboard.launch Una vegada fet açò tindrem disponibles les següents finestres, una amb el Gazebo obert mostrant la simulació i una altra amb la terminal executant el node teleop_keyboard. Com podem vore, el robot utilitzarà les tecles W-A-S-D per efectuar un moviment recte, a l’esquerra, enrrere o a la dreta respectivament, mentre que farà servir les tecles Q-E per a pivotar sobre si mateix. Tot açò ho farà amb una velocitat normal, mentre que si mantinguem presionada la tecla Shift, ho farà a una velocitat superior. Figura 7.3: Aspecte després de llançar la simulació i el node teleop_keyboard. A continuació disposem d’unes captures com a exemple d’una teleoperació simple. Primerament tirarem cap avant a una velocitat normal pressionant W. Cal indicar que mentre no pressionem cap altra tecla el robot seguirà anant recte, este només pararà en cas de pressionar qualsevol tecla no esperada (qualsevol que no siga WA-S-D-Q-E). En el cas de que es presione alguna de les tecles anteriors, el robot canviarà de sentit com veurem tot seguit. 81 CAPÍTOL 7. DESCRIPCIÓ DEL TREBALL REALITZAT Figura 7.4: Moguem avant el robot presionant W. 7.3.2 Teleoperació mitjaçant joystick La teleoperació mitjançant joystick conté algunes diferencies en respecte a la teleoperació per teclat que cal comentar. Primerament, hem de senyalar que este node va ser escrit per a un joystick Logitech Freedom 2.4, així que pot ser en altres models s’han d’adaptar alguns paràmetres per a que el control siga el òptim. Per llançar este tipus de teleoperació només hem de fer el següent: roslaunch guardian_description guardian_robotnik.launch roslaunch guardian_joystick_teleop guardian_joy.launch Per a poder controlar millor el robot, afegirem un control de velocitat mitjançant els botons superiors 3i4. Inicialment i per seguretat, la velocitat del robot està fixada a un 10% de la seua potència i amb successives pulsacions d’estos botons podem fixar-la a la desitjada. És molt útil en entorns perillosos o amb poca mobilitat, ja que no haurem de preocupar-nos de si les nostres accions sobre la palanca del joystick son més o menys violentes, ja que tindrem la velocitat en tot moment limitada. Pel que fa al control és l’esperat, palanca avant/arrere (roig a la imatge) generarà un moviment igual, mentre que si tirem la palanca a l’esquerra només es mouran les rodes dretes i si fem el propi amb la palanca cap a la dreta només ho faran les esquerres (de color verd a la imatge). Així i tot, esta ultima forma no és la més eficient per girar. Per a fer-ho d’una manera eficient podem fer que el robot pivote sobre ell mateix, cosa que farem girant la palanca sobre si mateixa a l’esquerra o la dreta (moviment blau a l’esquema). Cal destacar que este moviment no el tenen tots 82 7.3. EXEMPLES I GUIES D’UTILITZACIÓ Figura 7.5: Després de pivotar sobre si mateix pressionant E, el robot anirà rapidament cap enrrere si presionem Shif+S. Figura 7.6: Una vegada en la posició dessitjada, presionarem la barra espaiadora. els joysticks i en cas d’utilitzar algun que no tinga este moviment disponible haurem d’eliminar els dos moviments anteriors esquerra/dreta només movent les rodes d’un costat per el d’estes pivotacions, on cada costat du una direcció. 7.3.3 Navegació autònoma utilitzant posicionament local Una vegada vistes les formes de teleoperar sobre el robot, anem a passar a explicar com llançar i fer ús de la navegació autònoma. Primerament hem de deixar clara una cosa que pot ser més endavant ens dificulte la comprensió d’alguns conceptes i és que Gazebo és un simulador i per tant simularà el món real mentre que Rviz és només un visualitzador 3D del que aquest està observant i capturant pels diferents 83 CAPÍTOL 7. DESCRIPCIÓ DEL TREBALL REALITZAT Figura 7.7: Moviments als eixos del Logitech Freedom 2.4 sensors que l’integren. Una vegada deixat açò clar, que tornem a repetir, pareix clar, anem a vore com executar este tipus de navegació. Primerament iniciarem el simulador Gazebo com estem fent habitualment, seguidament cridarem als nodes encarregats de publicar les transformacions estàtiques i l’odometria (guardian_tf iguardian_odometry) per després llançar el node move_base amb la configuració corresponent. Per últim i per tal de visualitzar i actuar sobre el robot d’una forma més còmoda, executarem el visualitzador Rviz. A continuació la seqüència d’ordres seguides: roslaunch guardian_description guardian_robotnik.launch roslaunch guardian_2dnav guardian_configuration.launch roslaunch guardian_2dnav move_base_local.launch rosrun rviz rviz Açò donarà com a resultat que se’ns obrin dos finestres, una corresponent al simulador i altra al visualitzador, a esta última vorem el robot, els obstacles i els scans del làser en cas d’haver-ho fet correctament (per a açò hi ha un tutorial molt complet i que recomanem seguir ací7). Este es l’aspecte que mostrarà: Una vegada obertes estes dos finestres podrem punxar a l’Rviz a “2D Nav Goal” i a continuació seleccionar en qualsevol punt de la finestra. Com podem vore al vídeo que adjuntem8, el robot es mourà fins a la posició seleccionada, fent ús només de la localització mitjançant la odometria. 7http://www.ros.org/wiki/navigation/Tutorials/Using%20rviz%20with%20the%20Navigation%20Stack 8http://www.youtube.com/watch?v=uWzecxRjBqE 84 7.3. EXEMPLES I GUIES D’UTILITZACIÓ Figura 7.8: Navegació autònoma acabada d’iniciar. 7.3.4 Navegació autònoma utilitzant posicionament AMCL Com hem vist en la secció corresponent, este tipus de navegació fa servir, a banda de l’odometria clàssica, un mapa i l’algorisme AMCL per localitzar-se. Este algorisme utilitza un filtre de partícules per dur un seguiment de la posició aproximada del robot sobre un mapa conegut. Açò, juntament amb l’odometria, fa que la navegació utilitzant este sistema de localització siga molt precisa. Per executar este tipus de navegació seguirem els següents passos. Com vegem només canviarà el penúltim pas, on cridarem al node move_base però ara amb una altra configuració. roslaunch guardian_description guardian_robotnik.launch roslaunch guardian_2dnav guardian_configuration.launch roslaunch guardian_2dnav move_base_amcl.launch rosrun rviz rviz Posem un vídeo9on s’exemplifica com s’utilitza esta navegació. Com vegem, és més intuïtiva que l’anterior ja que a l’Rviz vegem el mapa intern carregat al map_server i el robot respecte a este en tot moment, així com els obstacles i els scans obtinguts del món real (en este cas Gazebo). A l’igual que en l’anterior cas, podem seleccionar un destí punxant sobre “2D Nav Goal” i seleccionant, ara sí, qualsevol punt sobre el mapa, sempre tenint en compte de no seleccionar una paret o un obstacle. 9http://www.youtube.com/watch?v=g7mQLRG56Vk 85 CAPÍTOL 7. DESCRIPCIÓ DEL TREBALL REALITZAT Figura 7.9: Navegació autònoma amb localització AMCL. 7.3.5 Navegació autònoma utilitzant posicionament SLAM Ja per últim presentem la navegació SLAM. Com ja hem estudiat, este sistema s’encarrega de localitzar i mapejar simultàniament un entorn. Amb açò volem dir que al principi el robot només tindrà com a mapa global el seu entorn immediat, és a dir el que des del seu punt inicial puguem capturar els làsers. Segons avance el robot, este anirà construint el mapa, que al mateix temps servirà per a situar-se d’una forma més precisa que només amb l’odometria. És un sistema molt complet i útil ja que obtenim el millor del AMCL sense haver de conèixer prèviament el mapa. Per llançar-lo tant sols haurem d’executar les següents accions. roslaunch guardian_description guardian_robotnik.launch roslaunch guardian_2dnav guardian_configuration.launch roslaunch guardian_2dnav move_base_amcl.launch rosrun rviz rviz Una vegada fet açò tindrem una imatge pareguda a esta, on si li donem un objectiu en el mapa vorem com conforme avança el robot es va creant el mapejat de l’entorn tal i com demostra el video10. 10http://www.youtube.com/watch?v=KWHDUUDdtus 86 Bibliografia [Addison-Wesley] Phillip McKerrow. Introduction To Robotics, 1991. [Cambridge University Press] Gregory Dudek i Michael Jenkin. Computational Principles of Mobile Robotics, 2010. [ICRA99] Frank Dellaert, Dieter Fox, Wolfram Burgard i Sebastian Thrun. Monte Carlo Localization for Mobile Robots, 1999. [ICRA09] Morgan Quigley, Brian Gerkey, Ken Conley, Josh Faust, Tully Foote, Jeremy Leibs, Eric Berger, Rob Wheeler, Andrew Ng. ROS: an open-source Robot Operating System, 2009. [ICRA10] Eitan Marder-Eppstein, Eric Berger, Tully Foote, Brian P. Gerkey i Kurt Konolige. The office marathon: Robust navigation in an indoor office environment, 2010. [ODE] Open Dynamics Engine. http://www.ode.org/, 2011. [OGRE] Ogre-open-source graphics rendering engines. http://www. ogre3d.org/, 2011. [ROS Wiki] Ros. http://www.ros.org, 2011. [ROS Wiki] Ros stacks. http://www.ros.org/wiki/Stacks, 2011. [ROS Wiki] Ros master. http://www.ros.org/wiki/Master, 2011. [ROS Wiki] Ros messages. http://www.ros.org/wiki/Messages, 2011. [ROS Wiki] Ros nodes. http://www.ros.org/wiki/Nodes, 2011. [ROS Wiki] Ros packages. http://www.ros.org/wiki/Packages, 2011. [ROS Wiki] Ros parameter server. http://www.ros.org/wiki/Parameter%20Server, 2011. [ROS Wiki] Ros services. http://www.ros.org/wiki/Services, 2011. 93 Annexes [ROS Wiki] Gazebo plugins. http://www.ros.org/wiki/gazebo_plugins, 2011. [ROS Wiki] Ros topics. http://www.ros.org/wiki/Topics, 2011. [ROS Wiki] Ros URDF. http://www.ros.org/wiki/urdf, 2011. [SLAM] Søren Riisgaard i Morten Rufus Blas. SLAM for Dummies. [University of Michigan] J. Borenstein, H. R. Everet i L. Feng. Where amb I?, 1996. [Wikipedia] Cinemàtica. http://ca.wikipedia.org/wiki/Cinem%C3%A0tica, 2011. [Wikipedia] Control PID. http://es.wikipedia.org/wiki/Proporcional_integral_derivativo, 2011. [Wikipedia] Robotica. http://en.wikipedia.org/wiki/Robot, 2011. [Willow Garage] Robot PR-2. http://www.willowgarage.com/pages/pr2/overview, 2011. [Willow Garage] Simulador Gazebo. http://gazebo.willowgarage.com/, 2011. [Willow Garage] Willow Garage. http://www.willowgarage.com, 2011. 94 Índex de figures 2.1 Diferents versions de la plataforma mòbil Guardian. . . . . . . . . . . 4 2.2 Parts principals del robot Guardian. Robotnik Automation SLL ©. . 5 2.3 Accionaments laterals del robot. Robotnik Automation SLL ©. . . . . 6 2.4 Estructura mòbil per al Guardian. Robotnik Automation SLL ©. . . 7 2.5 Robot Guardian amb l’estructura mòbil ja incorporada. Robotnik Automation SLL ©............................. 7 2.6 Mapa obtingut en Player/Stage mitjançant SLAM. . . . . . . . . . . 8 3.1 Esquema d’una configuració diferencial. . . . . . . . . . . . . . . . . . 10 3.2 Esquema del model diferencial directe. . . . . . . . . . . . . . . . . . 12 3.3 GràficdelcontrolP............................ 16 3.4 Estructura del controlador PID. . . . . . . . . . . . . . . . . . . . . . 17 3.5 Detall d’un encoder muntat sobre una roda. . . . . . . . . . . . . . . 18 4.1 Exemple de connexió del master 1/3 . . . . . . . . . . . . . . . . . . 29 4.2 Exemple de connexió del master 2/3 . . . . . . . . . . . . . . . . . . 30 4.3 Exemple de connexió del master 3/3 . . . . . . . . . . . . . . . . . . 30 4.4 Situació dels diferents marcs coordenats. . . . . . . . . . . . . . . . . 34 4.5 Efecte de les tf sobre un objecte situat a 0.3 cm. . . . . . . . . . . . . 34 4.6 Esquema visual d’una configuració URDF. . . . . . . . . . . . . . . . 36 5.1 Gràfic de dependències de Gazebo . . . . . . . . . . . . . . . . . . . . 40 5.2 Col·lisió de diversos objectes. Esta demo està inclosa en els fitxers fontsdeODE................................ 42 6.1 Primera versió del URDF de forma esquematitzada i al simulador Gazebo. .................................. 49 6.2 Model URDF millorat. Vista normal i vista de la física amb Gazebo. 50 6.3 Estats d’un controlador . . . . . . . . . . . . . . . . . . . . . . . . . . 52 6.4 Flux d’execució a un controlador. . . . . . . . . . . . . . . . . . . . . 52 6.5 Model mecànic del robot i la seua relació tant en simulació com al robotreal.................................. 53 6.6 Diagrama a seguir en la programació del controlador. . . . . . . . . . 54 6.7 Gràfic de la teleoperació per joystick. . . . . . . . . . . . . . . . . . . 60 6.8 Laser ja instal·lat sobre el robot. Si ens fixem, és el punt negre des del qual ixen les línies blaves que representen gràficament el seu abast. 62 6.9 Imatge obtinguda des de la càmera incorporada al robot. . . . . . . . 63 95 Índex de figures 6.10 Plugins dinàmics disponibles per al simulador Gazebo. . . . . . . . . 64 6.11 Esquema de la configuració de la Navigation Stack. . . . . . . . . . . 65 6.12 Comportaments de recuperació per defecte de move_base. . . . . . 68 6.13 Els tres tipus de costmaps........................ 69 6.14 Planol de les instal·lacions de Robotnik. . . . . . . . . . . . . . . . . 73 6.15Lesparetsen3D.............................. 73 6.16 El món dissenyat ja acabat. . . . . . . . . . . . . . . . . . . . . . . . 74 7.1 Arquitectura de la simulació a nivell de graf. . . . . . . . . . . . . . . 76 7.2 Problema de rotació detectat. Recomanem visualitzar els videos per a una millor comprensió. . . . . . . . . . . . . . . . . . . . . . . . . . 79 7.3 Aspecte després de llançar la simulació i el node teleop_keyboard. . 81 7.4 Moguem avant el robot presionant W. ................. 82 7.5 Després de pivotar sobre si mateix pressionant E, el robot anirà rapidament cap enrrere si presionem Shif+S. ............... 83 7.6 Una vegada en la posició dessitjada, presionarem la barra espaiadora. 83 7.7 Moviments als eixos del Logitech Freedom 2.4 . . . . . . . . . . . . . 84 7.8 Navegació autònoma acabada d’iniciar. . . . . . . . . . . . . . . . . . 85 7.9 Navegació autònoma amb localització AMCL. . . . . . . . . . . . . . 86 7.10 Navegació autònoma amb localització SLAM. . . . . . . . . . . . . . 87 8.1 Arquitectura de la simulació amb navegació autònoma a nivell de graf. 92 96 Índex de taules 2.1 Característiques mecàniques del robot Guardian . . . . . . . . . . . . 4 2.2 Característiques de control del robot Guardian . . . . . . . . . . . . . 5 3.1 Classificació dels robots mòbils. . . . . . . . . . . . . . . . . . . . . . 9 4.1 Relació entre les diferents representacions de msg. . . . . . . . . . . . 27 4.2 Utilitatsderosnode. ........................... 29 4.3 Utilitats de la ferramenta rosmsg. . . . . . . . . . . . . . . . . . . . . 31 4.4 Utilitats de la ferramenta rostopic. . . . . . . . . . . . . . . . . . . . 32 4.5 Utilitats de la ferramenta rosservice. . . . . . . . . . . . . . . . . . . 33 5.1 Simuladors per a robòtica . . . . . . . . . . . . . . . . . . . . . . . . 38 97