Pianificazione traiettoria di un drone

[dimaios]

Bene, avete un docente che puo' sicuramente aiutarvi molto viste le competenze.

[spud]

Si infatti almeno su quello siamo tranquilli

Purtroppo abbiamo perso quasi un mese e mezzo su una strategia che si è rivelata fallimentare ma adesso ci siamo rimessi sulla strada giusta. Vediamo cosa si riesce a tirare fuori, poi magari se ci scappa un articoletto non sarebbe male.

Intanto grazie ma mi farò sentire presto

[spud]

Ci siamo quasi, abbiamo messo un piedi un piccolo algoritmo di controllo da far girare sul drone.
Ora abbiamo un programmino in C che richiede in ingresso un file di testo con un certo numero di punti da interpolare (pochi massimo 5 poi il risultato oscilla troppo per ora) e fornisce in uscita un file con una sequenza più fitta di punti che viene letta dall'algoritmo di controllo.
Ora non resta che implementare l'inseguimento della traiettoria, volevo chiedere se c'è qualche particolare algoritmo che conviene utilizzare in questi casi, chiedo perché sicuramente avete più esperienza di me e magari qualcuno ha già dovuto fare qualcosa di simile.

Il mio algoritmo in linguaggio naturale sarebbe il seguente.

Codice: Seleziona tutto

   Apri file delle coordinate;
   Posizione = ( 0, 0, 0);   //riferimento dell'origine
   Fintanto che (File != FINITO) {
      Destinazione = Leggi coordinate dal file   //legge una terna dal file
      Fintanto che ((Destinazione - Posizione) > e){   //e = errore accettabile
         Muovi x, y, z;   //risoluzione da definire
         Posizione = nuova posizione;
      }
   }


[dimaios]

Ora abbiamo un programmino in C che richiede in ingresso un file di testo con un certo numero di punti da interpolare (pochi massimo 5 poi il risultato oscilla troppo per ora)

Mmmmmmmmmmhhhhhhhh ...... hai usato per caso una curva polinomiale di ordine improbabile ?
Forse e' per questo che hai un fenomeno di overfitting!

Le spline non andavano bene ?

[spud]

No beh in realtà questa cosa è ancora abbastanza abbozzata, nel senso che abbiamo fatto due versioni, una con interpolazione lineare e una polinomiale; ora stiamo lavorando a un algoritmo che abbiamo visto in teoria dei sistemi e vediamo cosa viene fuori. Consiste nell'usare una base diversa da quella che si usa normalmente per i polinomi, al momento non ho gli appunti in mano quindi non so essere più preciso.

Per l'algoritmo di "inseguimento" che dici? Può avere senso?
La cosa che mi preoccupava particolarmente era l'onerosità del calcolo.

[dimaios]

Non sapendo come vuoi realizzare il controllo di traiettoria mi risulta difficile anzi impossibile risponderti.

[spud]

Cerco di essere più preciso.
Abbiamo dovuto fare alcune considerazioni in quanto abbiamo studiato solo lo studio delle traiettorie nello spazio dei giunti.
I nostri gradi di libertà sono questi:

• movimento avanti
• movimento a destra
• movimento a sinistra
• movimento indietro

di questi controlliamo la velocitè (in percentuale rispetto alla velocità massima raggiungibile) e il tempo durante il quale viene fatto il movimento.
Ora, siccome questi sono i movimenti che può fare un manipolatore cartesiano abbiamo concluso che il nostro spazio dei giunti corrisponde allo spazio operativo, del manipolatore in realtà qua abbiamo solo l'end effector.

Il controllo lo facciamo sui nostri giunti in base alle informazioni lette dai sensori (tutto viene fatto onboard), il come lo facciamo sarebbe ciò che fa l'algoritmo in [13].

Non abbiamo esigenze temporali per l'attraversamento dei punti.

Non so se ho chiarito un po' meglio la cosa..

[dimaios]

La postura dell' end-effector di un robot è caratterizzata dalla sua matrice della trasformazione omogenea associata.
Le coordinate x,y,z rappresentano la metà dell'informazione necessaria per costituirla.
Come la mettiamo con gli angoli di Eulero o rappresentazione equivalente ?

Se dovessi affrontare il problema studierei la traiettoria 3D impiegando il triedro fondamentale dei vettori di Frenet cercando di imprimere al velivolo gli angoli corretti in base alle accelerazioni centrifughe calcolate localmente tramite le coordinate curvilinee.

Poi si dovrebbero studiare le caratteristiche dei sensori ( accelerometri in particolare ) per vedere in quale zona si minimizza l'errore di linearità ecc. ecc.
A mio avviso una caratterizzazione sull'incertezza della misura deve essere fatta altrimenti la stima della posizione potrebbe risultare scarsa.

[spud]

Si ma il nostro end-effector non è un polso sferico, noi non abbiamo controllo sulla sua orientazione, a eccezione dell'imbardata. Rollio e beccheggio se li regola lui in base al fatto che gli venga detto di andare avanti o di lato. Non possiamo farlo stare a mezz'aria con il becco inclinato di 30° per intenderci, lui si inclina solo per potersi muovere in una certa direzione.
Praticamente controllare la sua posizione equivale ad esempio a controllare la posizione di un cartesiano che come end-effector qualcosa che non si possa orientare, non so la punta di un trapano ad esempio.

Per l'incertezza sulle misure ci avevamo pensato anche noi ma in teoria lui applica un filtro di Kalman alle misure che effettua quindi ho supposto che fossero sufficentemente affidabili e ripetibili per la nostra applicazione.

[xyz]

State attenti se ragionate con gli angoli di Eulero ci sono dei problemi se tentate di interpolare le rotazioni, ci sono combinazioni che generano il gimbal lock:

http://en.wikipedia.org/wiki/Gimbal_lock

per evitarlo bisogna rappresentare le rotazioni con i quaternioni:

http://en.wikipedia.org/wiki/Quaternion

I quaternioni oltre a non avere il problema del gimbal lock permettono di interpolare le rotazioni con una particolare funzione che si chiama SLERP (interpolazione lineare sferica):

http://en.wikipedia.org/wiki/SLERP

la SLERP ha molti vantanti rispetto all'interpolazione lineare di Eulero tra cui mantiene la velocità angolare costante.

I dettagli matematici non semplici è descritta in questo PDF ad esempio:

http://www.itu.dk/people/erikdam/DOWNLOAD/98-5.pdf