Alcuni concetti chiave del corso di robotica

Michele Piffari – V Anno ROBOTICA – A.A. 19/20

Sommario

Ingegneria del software per la robotica ........................................................................................................ 3

Software development for robotics – i middlewares .................................................................................... 4

Robot e ruote................................................................................................................................................. 6

)

Differential Drive robot – twist ( ......................................................................................................... 7

Differential Drive robot – odometria............................................................................................................. 9

Pose and trajectory controller ..................................................................................................................... 11

Pose controller......................................................................................................................................... 12

Path planning (obstacle avoidance) ............................................................................................................ 12

Spazio delle configurazioni ...................................................................................................................... 13

Somme di Minkowski .............................................................................................................................. 13

Strategie di sampling ............................................................................................................................... 14

Decomposizione in celle .......................................................................................................................... 15

Decomposizione in celle completa ...................................................................................................... 15

Decomposizione in celle parziale ........................................................................................................ 16

Probabilistic roadmap (PRM = Probabilistic RoadMap) ...................................................................... 16

Fase di learning .................................................................................................................................... 16

Fase di query ........................................................................................................................................ 17

Rapidly Growing Random Trees .............................................................................................................. 18

Bug algorithm .......................................................................................................................................... 18

VFH – Vector Field Histogram .................................................................................................................. 19

Basic Curvature Velocity Method ............................................................................................................ 20

Dynamic Window Approach ................................................................................................................ 20

Potential fields ......................................................................................................................................... 21

Costruzione di mappe .................................................................................................................................. 21

Errori ........................................................................................................................................................ 22

o Problema delle corrispondenze ................................................................................................... 22

o Dinamicità dell’ambiente ............................................................................................................ 22

o Motion blur .................................................................................................................................. 22

- Tipi di mappe ................................................................................................................................... 22

o Mappe geometriche .................................................................................................................... 22

o Mappe di occupazione ................................................................................................................. 23

o Mappe topologiche ..................................................................................................................... 26

Localizzazione del robot .............................................................................................................................. 27

Localizzazione basata su mappa (Monte Carlo Localization) .................................................................. 27

Localizzazione basata su marcatori (marker based localization) ............................................................ 29

Michele Piffari – V Anno ROBOTICA – A.A. 19/20

Nota la posizione dei marcatori e orientamento del robot ................................................................. 29

Nota la posizione dei marcatori ma non del robot .............................................................................. 30

Triangolazione circolare ...................................................................................................................... 30

SLAM ............................................................................................................................................................ 31

Concetti base di geometria 3D .................................................................................................................... 39

Michele Piffari – V Anno ROBOTICA – A.A. 19/20

Ingegneria del software per la robotica

→ →

- SPL Software Product Line approccio alla codifica software nella realizzazione di sistemi

custom orientato alla riusabilità del codice, per incrementare così le performance in fase di test e

debug, garantendo inoltre elevata flessibilità e portabilità.

- Obbiettivo: essere in grado di separare elementi comuni con altri domini applicativi da quelli

custom dello specifico progetto.

- Nella definizione di un progetto in ambito robotico è molto importante andare a tener traccia di

quelli che sono i costi di produzione: analizzando, in maniera del tutto generale un qualsiasi

progetto (non solo affine all’ambito della robotica, ma anche in altri campi), si può notare come la

parte relativa alla stesura di codice software sia decisamente la parte più costosa e dispendiosa,

perché richiede maggior tempo e deve essere realizzata per far fronte a tutti i possibili casi d’uso in

cui il sistema che si sta progettando potrebbe trovarsi e/o finire.

Risulta quindi essere sicuramente di enorme aiuto andare a strutturare ogni progetto con

un’organizzazione “statica”, in cui si tende a fare un forte riutilizzo del codice: sicuramente un

approccio di questo tipo offre una minore possibilità di custom del prodotto, a meno che si voglia

completamente stravolgere, a favore però di una maggiore robustezza e strutturalità.

È infatti importante andare a definire una corposa fase di ingegnerizzazione del software, in cui si

cerca di strutturare il codice nella maniera più generica possibile: la prima fase quindi da eseguire

non deve essere quella di buttare codice su carta, ma cercare di modellizzare le diverse componenti

del sistema in maniera oculata, cercando il così detto dominio applicativo del sistema, per capire

come generalizzare le strutture.

Qui viene in aiuto una suddivisione in funzionalità, più o meno aggregate, a cui assegnare uno

specifico componente, dotato di interfacce bidirezionali eventualmente (sia dall’esterno verso il

→

componente che dal componente verso l’esterno) UML.

Questo approccio risulta essere decisamente più lungimirante rispetto ad un qualsiasi approccio

più diretto: un tempo maggiore speso inizialmente, può aiutare a ridurre le tempistiche di testing e

debug successive, dato che si avrà un codice maggiormente leggibile, modulare e più flessibile.

Questo è quello che si intende per SPL (Software Product Line), ovvero l’andare a stendere sw in

maniera sequenziale, ma tenendo sempre conto del punto di arrivo e rimanendo il più generici

possibile, come in figura: a sx restringo subito le strade che il programmatore può seguire, ovvero

la varietà di scelte che può effettuare ad un certo livello; per tenermi invece più libertà e flessibilità

tengo più largo il dominio, studiando un modo per renderlo più semplice, in cui il codice custom lo

trovo solo nella valle della parabola, non come il simbolo a sx, in cui già da subito mi customizzo.

Nella robotica è un modo comune di agire andare a trovare pezzi di codice sw già prodotti, in grado

di realizzare le funzionalità necessarie: si hanno nello specifico una serie di 5 macro aree

applicative in cui si può fortemente applicare la riusabilità sui robot, indipendentemente dal

Michele Piffari – V Anno ROBOTICA – A.A. 19/20

dominio applicativo (sia che siano robot per ospedali, aziende chimiche, tessili, macchinine da

combattimento etc..).

Gli esempi precedenti quindi ci permettono di capire come, per astrarre queste funzionalità base,

di cui tutti i robot hanno bisogno, è necessario condurre uno studio approfondito, separando in

diverse “aree tematiche” le necessità che il nostro sistema ha, delineando in maniera precisa

input/output; una volta però portato a termine ciò si è in grado di velocizzare il riuso utilizzando il

codice come una black-box: sono noti gli input e gli output; quello che vi succede al suo interno è

secondario, e sappiamo essere stabile, poiché prodotto /testato/sviluppato da terzi.

Essa offre interfacce verso l’esterno (lollipop) e ne accetta/riceve altre in ingresso (fork),

rielaborandole al suo interno: se quindi quello che ci serve è proprio quello fornito in output da

questa Blackbox possiamo prenderla, come una libreria esterna, e porla nel nostro sistema (plus).

Nello specifico in ambito robotico sono questi i blocchi fondamentali che possono avere una

differente realizzazione:

▪ →

Motion planning path ≠

▪ →

Trajectory planning trajectory (appunto)

▪ Localization

▪ Obstacle avoidance

▪ Motor control and moving

Software development for robotics – i middlewares

- Come visto in precedenza, risulta essere molto importante andare a definire e dedicare una

tempistica adeguata per quella che è la parte di progettazione del software: questo tempo (sempre

necessario) comprende l’andare a definire quelli che sono i blocchi principali, ovvero quali

funzionalità dividere/separare in strutture isolate, sfruttando quindi una programmazione tramite

interfacce che legano i componenti.

Ogni componente prende/fornisce certi dati tramite appunto delle interfacce: questi dati devono

però essere scambiati e trasmessi tra i vari componenti, e perciò sono necessarie delle strutture per

andare a linkare tra di loro i vari pezzi di codice, che necessitano di una certa tipologia di dati ad un

certo istante (dati che gli può fornire un determinato componente).

- Nella definizione della struttura software del sistema in esame, vengono in aiuto i cosiddetti

middlewares: essi non sono altro che uno strato applicativo intermedio, che si frappone fra il

programma applicativo ad alto livello, e il sistema operativo/di rete a basso livello.

In sostanza essi rappresentano degli strati intermedi in grado di rendere più accessibili funzionalità

di basso livello, come ad esempio funzionalità comunicative.

- La presenza di strutture in grado di semplificare la parte comunicativa, ha permesso di strutturare

sistemi distribuiti, ovvero istanziati su due macchine diverse, le quali vanno a scambiarsi messaggi

in maniera remota.

- Middlewares:

- RPC (Remote Procedure Caller)

▪ La comunicazione remota funziona tramite chiamata di funzioni, tramite le quali

avviene anche il passaggio dei dati necessari all’interno della loro “firma”.

▪ Struttura semplice da realizzare, perché implementa un approccio naturale di

comunicazione client/server, di tipo domanda/risposta.

Michele Piffari – V Anno ROBOTICA – A.A. 19/20

Questa facilità di implementazione, basata su un meccanismo sincrono, va ad

inficiare però le prestazioni per colpa di time lock e delay per la gestione del

sincronismo.

- MOM (Message op. Middleware)

▪ Messaggi con una struttura ben definita vengono ad essere scambiati per mezzo di

specifici canali, che rappresentano dei link tra mittente e destinatario.

- ROS (Robot Operating System)

- DDS (Data Distribution Service)

▪ Molto simile a ROS: anzi sarebbe meglio dire che ROS è molto simile a DDS, dato

che, nel caso di ROS II, si ha che esso va a basarsi proprio su DDS.

▪ Struttura basata su publisher/subscriber/topics.

▪ In sostanza, il concetto base di questo middleware è che il publisher pubblica

informazioni, etichettate con certi topic, all’interno di spazi di memoria condivisi

con altri nodi i quali, sottoscrivendosi, vanno ad ottenere le informazioni che vi

sono pubblicate.

In particolare, possiamo aggregare più publisher all’interno dei data writer mentre

più subscribers possono essere aggregati all’interno dei data reader.

C’è anche il concetto di domain participant.

▪ Topic: non è altro che un’etichetta che viene legata ai dati, NON RAPPRESENTA IL

CONTENUTO DEI MESSAGGI, MA SOLO UN’ETICHETTA CHE NE INDICA IL

CONTENUTO.

Ogni istanza di un topic viene ad essere identificato tramite ID, che lo rende

univoco: quindi, se questo campo ID presenterà un numero di bit pari ad 8 bit (per

esempio), si avranno a disposizione fino ad un massimo di 256 topics.

Ogni topic può essere schematizzato in questo modo: topic(name, type, qos)

• →

Name identifica il topic

• Type→contiene la tipologia di dati a cui lo specifico topic fa riferimento

• QoS→quality of service. Indica delle specifiche non funzionali che il topic

deve rispettare. Sono molte, le più importanti sono (qui indicate senza

specificare il nome corretto di tutte, ma indicando quelle che sono le

principali specifiche [non funzionali appunto], che supportano):

o Durability: indica la persistenza dei dati, ovvero se possono essere

salvati, oppure se rappresentano dei dati volatili

o Reliability: indica l’affidabilità della consegna dei dati; nello

specifico è necessario che pub/sub abbiano almeno lo stesso grado

di affidabilità (potrebbe essere anche più stringente, ma non più

largo).

o Massimo numero di messaggi processabili (in lettura e scrittura)

rispettivamente da subscriber e publisher

o History queue, che indica se è necessario mantener traccia di tutti i

messaggi scambiati oppure se è sufficiente conoscere solo l’ultimo

messaggio

o Timeout

Michele Piffari – V Anno ROBOTICA – A.A. 19/20

Robot e ruote

- Robot si basano su

- Cinematica→andamento posizione in ambiente “statico”, senza interazione

→

- Dinamica interazione moto con forze: come cambia il moto in relazione alle forze

applicate al robot stesso

- Possiamo considerare due macro categorie di robot:

- Robot manipolatori (classici a 6 gdl = Gradi Di Libertà)

- Robot mobili

- La tipologia di movimento dei robot mobili è strettamente legata alla tipologia di ruota: sono infatti

le ruote che determinano la tipologia di contatto con il terreno, e che quindi determinano le forze

principali che il robot si scambia con il terreno, determinando l’andamento del moto del robot

stesso.

Ruote diverse quindi determinano differenti movimenti

- Diverse tipologie di ruote:

o Ruote fisse: non possono sterzare, ovvero non hanno alcun grado di libertà

o Ruota sterzante: ruota che può sterzare intorno all’asse passante per il centro della ruota

stessa

o Ruota decentrata: è la classica ruota del carrello della spesa, la quale può ruotare intorno

ad un asse decentrato, cioè che non passa per il centro della ruota stessa.

o Ruota omnidirezionale (ruota svedese): ruota che può muoversi in tutte le direzioni, grazie

alla composizione con rulli inclinati, che permettono alla ruota di traslare in tutte le infinite

continue direzioni.

→ →

- Tipologia di ruota cinematica differente è chiaro che un robot con ruota fissa non potrà

eseguire tutti i movimenti che invece un robot omnidirezionale potrà fare.

- Sicuramente risulta essere di molto semplificativo considerare il contatto ruota-terreno senza

scivolamento, ovvero un contatto di puro rotolamento, senza considerare scivolamenti ne laterali

ne longitudinali. Con il vincolo di puro rotolamento si ha un solo grado di libertà.

,

Se vincolata nel punto di contatto (dx), la ruota ruoterà di un certo angolo andando a far

corrispondere un certo spostamento lungo l’asse X della ruota stessa

Il moto del centro della ruota, baricentro, è determinato da questa legge

= ∙

Da cui si può ricavare lo spazio percorso.

Michele Piffari – V Anno ROBOTICA – A.A. 19/20

- Concetto CIR e ruote sterzanti

o ⊥

CIR = punto di intersezione tra le rette alla velocità di più punti rigidi (ovviamente,

un corpo rigido è composto da un insieme di punti rigidi, i quali si trovano ad una

distanza fissa, che non cambia, per le proprietà di rigidità del corpo stesso); nel caso

delle ruote con vincolo di puro rotolamento questo punto coincide con l’intersezione

degli assi delle ruote, dato che la velocità è sempre orto