# Proposta di progetto
Il progetto consisterebbe nel far evolvere il lavoro che abbiamo svolto in vista della competizione [Dodge Drone](https://uzh-rpg.github.io/icra2022-dodgedrone/) che ha avuto luogo a Philadelphia, a fine maggio.
Di seguito un breve riassunto di ciò che abbiamo fatto, come lo abbiamo fatto e come vorremmo portarlo avanti come progetto di Sistemi Autonomi.

### Requisiti della gara
- la gara consisteva nel far sì che un drone partisse da un punto A e percorresse una distanza lineare di 60m attraversando un goal, rappresentato da un muro. Il drone doveva giungere in fondo al percorso senza collidere con gli ostacoli. Gli ostacoli erano rappresentati da delle sfere di diverse dimensioni, alcune statiche, altre dinamiche.
- Era possibile scegliere se fare un’implementazione state-based (e quindi avere anche informazioni riguardanti l'ambiente, come, ad esempio, l'esatta posizione degli ostacoli o del drone) o vision-based (le informazioni permesse erano: immagine della videocamera (rgb o depth), attitude del drone, velocità angolare, velocità lineare).
- uno dei vincoli della gara era l'utilizzo di un simulatore basato su Unity, sviluppato dagli organizzatori ([Flightmare](https://uzh-rpg.github.io/flightmare/))
- bisognava partire da un [repository](https://github.com/uzh-rpg/agile_flight) messo a disposizione dagli organizzatori della gara.
- L'ambiente (sincrono) messo a disposizione dagli organizzatori era basato su Python (API gym-like) e si interfacciava al simulatore mediante C++ (usando pybind11).
- La valutazione, invece, veniva fatta in ambiente ROS (asincrono).

### La nostra implementazione
La nostra implementazione (vision-based) è stata fatta sull'ambiente sincrono e poi portata su ROS (cosa che ha causato diversi malfunzionamenti, dovuti alla differenza tra la natura e la configurazione dei due ambienti).
Visto che, quando abbiamo iniziato, mancava solo un mese alla consegna (senza considerare che ci sono voluti almeno 10 giorni per fare le dovute configurazioni, documentarci sulle nozioni che ci sarebbero servite, pensare a un piano d'azione e capire il codice di partenza), abbiamo pensato di poter velocizzare le cose basandoci su una rete pre-addestrata messa a disposizione da [COMPASS](https://www.microsoft.com/en-us/research/blog/compass-contrastive-multimodal-pretraining-for-autonomous-systems/).
Sapevamo che si trattava di una scelta rischiosa poichè, oltre ad essere molto nuovo, la rete era stata addestrata sul problema opposto (il drone doveva entrare in un gate, anziché evitare gli ostacoli). Abbiamo pensato di utilizzare COMPASS come features extractor per una rete MLP (PPO) implementata da noi che reindirizzasse il comportamento su quello desiderato, ricavando una tupla di quattro valori che rappresentavano l’azione del drone con la modalità di guida CTBR (mas-normalized collective thrust and bodyrates) fornita dagli organizzatori.

### Struttura
La nostra implementazione era strutturata come nell'immagine sottostante (presa dalla documentazione di stable baselines3)
- lo spazio delle osservazioni era dato dai valori di velocità, attitude e immagini del drone
- Queste osservazioni venivano date in input a COMPASS che ci faceva da features extractor
- La rete finale faceva uso di PPO. Prendeva in input le features identificate da COMPASS e dava come output l’azione del drone

### Problemi
Il modello che abbiamo infine consegnato presentava diversi problemi, la maggior parte dei quali erano condivisi con i team con cui abbiamo collaborato (il team "senior" composto dai tutor del corso di SVS e un altro team composto da due dottorandi di TII). Non abbiamo avuto abbastanza tempo per indagare a fondo sulle reali cause dei comportamenti indesiderati, ma abbiamo ragione di credere che molti di essi siano dovuti al codice di partenza fornito dagli organizzatori e possono derivare sia da bug (ne abbiamo già trovati diversi, alcuni dei quali ci hanno fatto perdere diverso tempo) che da qualcosa che ci è sfuggito.

Alcuni esempi di problemi riscontrati sono:
- Il drone perdeva stabilità e collideva in maniera anomala quando usavamo MPC. Abbiamo ricondotto questa anomalia al fatto che MPC è troppo lento per un ambiente asincrono.
- Qualsiasi cambiamento provassimo a fare sulla funzione di reward, seppur cambiasse il comportamento del drone, non portava a miglioramenti accettabili.
- Il drone non riesce a generalizzare i livelli, crediamo che la combinazione input-output sia troppo vasta per essere gestita.
- Strumenti appositi per la ricerca di iperparametri adeguati forniscono risultati incoerenti, questo può essere causato dal fatto che un miglioramento apprezzabile in un dato environment richiede molto tempo e non riuscendo a generalizzare ogni iperparametro che porta a un overfitting viene considerato buono.
- L'ambiente asincrono non ha bordi di collisione né sui muri né sul pavimento. Questo porta il drone a comportarsi in maniera anomala quando oltrepassa il perimetro massimo

### Obiettivi del nuovo progetto
Gli obiettivi che ci piacerebbe raggiungere con questo progetto sono i seguenti:
- indagare sul codice su cui abbiamo lavorato per tentare di capire cosa è andato storto e come potremmo risolvere (non sappiamo se e quanto possiamo fidarci della base data dagli organizzatori)
- indagare sull'utilizzo di COMPASS per capire se l'approccio un po' sperimentale che abbiamo usato partiva da un'idea corretta (le feature davvero sono sensate e correlate al problema?)
- in caso affermativo portare avanti il lavoro con COMPASS ottenendo un modello che dia risultati soddisfacenti
- provare a “migliorare” la rete cercando di fare fine-tuning sul problema (cosa che non potevamo fare per ragioni di tempo)
- capire se la depth rappresenta davvero la scelta migliore dato che, contattando gli sviluppatori di COMPASS (verso la fine) abbiamo scoperto che il training si è concentrato maggiormente sull’rgb, rispetto alla depth. Vorremmo inoltre valutare l’utilizzo della flow, capendo se è possibile integrarla nell’ambiente
- ragionare sulle funzioni di reward che abbiamo testato per capire se possiamo giungere a una reward efficace (abbiamo passato buona parte del tempo a cercare una buona funzione di reward perché quelle che provavamo davano risultati scadenti, per poi capire che probabilmente il problema non era la reward stessa ma qualche bug nel codice di partenza o nel modo in cui lo abbiamo utilizzato)
- Rivedere l'algoritmo MPC che ci è stato passato dal team di TII e che abbiamo utilizzato per restringere lo spazio delle azioni anziché per guidare il drone. Valutare se, usato diversamente, può davvero essere una risorsa o se è meglio accantonarlo (l'algoritmo si serviva dell'immagine della depth camera per individuare le coordinate di un varco tra le sfere e dava in output una quaterna che rappresentava l'azione che doveva compiere il drone, ma che non abbiamo usato come "comando").
- Sempre riguardo lo spazio delle azioni, capire se può essere una buona idea passare da uno spazio continuo a uno discreto (uno dei team vincitori ha utilizzato questa tecnica), PPO potrebbe incontrare problemi su uno spazio continuo, non riuscendo a correlare visione e azione
- Capire se ha senso fare lo “stacking” delle immagini (e come farlo), aumentando la complessità dell’input ma permettendo alla rete di avere una visione temporale con più frame (forse flow può aiutare)
- Provare a fare un'implementazione state-based che possa essere utilizzata come campo di prova per capire velocemente se un approccio ha un andamento promettente o meno. Questo perchè il training sarebbe molto più veloce (non avendo le immagini, nè tutta l'impalcatura di COMPASS sarebbe possibile fare molti più step in un determinato lasso di tempo.)

In generale ci piacerebbe riuscire a completare la sfida almeno in difficoltà medium, con un buon success rate. Per ora tutti e tre i team hanno avuto performance non ottimali nell'ambiente. Il drone collideva spesso non riuscendo a generalizzare il problema (COMPASS -> PPO), oppure le collisioni erano poche, ma la velocità era estremamente ridotta(MPC), soprattutto dopo il passaggio su ROS.

Nel caso in cui questo lavoro dia risultati interessanti vorremmo provare a scrivere un paper in collaborazione con gli altri team, per capire se effettivamente la rete COMPASS è così general-purpose, necessita di fine-tuning, oppure semplicemente non ha offerto feature ideali