Archivi tag: PID

Beta1test. Alcune considerazioni

Durante gli ultimi giorni ho affettuato dei tet con il seguente setup:

  • Throttle speed = 30 (Questo valore non permette al drone di volare ma può farlo bilanciare sulla semisfera montata sulla base ).
  • Roll target=pitch target =0.
  • Command =1 ( solo il controllore PID per il roll è attivo). In questa modalità motor1 e motor 3 ( pitch) ruotano alla velocità di throttle.
  • PID k : li ho variati nei diversi test per poter avere un primo confronto.
  • Cycletime = 10ms.

Analizzando i logs salvati ho raccolto le seguetni considerazioni :

  • Il  cycle time medio è = 11ms, con alcuni picchi fino a 21ms.Questo è un punto fondamentale che devo chiarire.beta1_cycletime
  • Ho bisogno di comparare dati dai diversi  threads (main loop esensor per il momento).Cosi’ ho modificato il codice includendo una colonna del tempo assoluto.
  • When I switch from command 0 (no PID controller) to 1 (roll PID controller) I notice a pick on the motor speed. I find a bug: one data initialization missing.Now it is corrected.
  • Nell’istante in cui passo da command 0 a 1 ci impiega circa 1,5 sec a tentare di bilanciarsi anche se la differenza fra le velocità motori è elevata. Possibile spiegazione (da investigare) è l’effetto dellinerzia all’avvio del movimento. Dovrei provare con permettere una maggiore differenza di velocità
  • Per ora il miglior risultato si è ottenuto con Kp= 0.6 Ki=0 Kd=0.5. Voglio provare aumentando un poco  Kp e riducendo Kd.beta1_balancing

 

Alfa3test. Aggiornamento sviluppo

Sono ancora operativo…anche se due settimane fa ho avuto qualche problema con la batteria.Una volta scaricata non ne ha piu’ voluto sapere di farsi ricaricare…

Questo e’ successo mentre stavo raccoglendo un po di dati.In particolare stavo registrando in comportamento della mia struttura di test al variare dei  parametri P,I,D. Sono riuscito a raccogleire solo pochi dati, ma quello che posso mostrare ora e’ un piccolo successo: il mio modello matematico e’ abbastanza fedele al reale.Qui trovi il link

In queste  immagini si puo’ vedere l’andamento teorico (blu) previsto dal modello matematico e il comportametne reale del quadricottero (rosso).

Questo e’ il caso con P=0.3  I=0 D=0.05

comparison teorical _real1

Questo e’ il caso con P=0.5 I=0.7  D=1,75

comparison teorical _real2

Questo e’  molto importante perche in questo modo posso testare sul modello matematico il comportametno del quadricottero, al variare dei parametri  P,I e D  in attesa di sitemare la batteria!

Alfa3Test. Primi risultati e modulo rc.py

Ho effettuato i primi test sul modulo alfa3.py.

Sono emersi alcuni punti su cui devo lavorare.

In prima battuta la struttura di test non permette un movimento del quadricottero del tutto libero.Si puo infatti notare un comportamento anomalo quando la struttura e’ prossima ad una inclinazione nulla. L’attrito fra quadricottero e struttura rende il sistema piu stabile di quello che mi aspettavo.

Dovro’ rivedere il punto di contatto e cercare di renderlo meno soggetto ad attriti.

Potrei provare anche semlipcemente a aumentare il trottle , cioe fare in modo che i 2 motori sollevino di piu il quadricotteroriducendo cosi’ l’attrito.

Attualmente, comesi puo’ notare dalle foto del post precedente, la rotazione del quadricottero e’ limitata da un supporto in legno, a circa +/- 10 gradi.

alfa3_pic2

Ritengo necessario poter dare maggior liberta’ di movimento, per cui dovro’ modificare la struttura.

Veniamo ora al lato software. In alfa3 test ho introdotto un nuovo modulo chiamato rc.py (remote controller)  con lo scopo di rendere indipendente l’iserimento dei comandi dal loop di controllo del quadricottero. Per cui rc.py e’ attualmente un thread indipendente che resta in ascolto di input dall’utente. In questa fase l’input e’ da tastira, ma sto gia lavorando ad un webserver che permetta di ricevere i comandi da qualunque dispositivo dotato di browser (il mio cellulare) .

rc.py  mette a disposizioni i dati imputati da operatore quali  trottle ,roll, pitch e yaw desiderati.Il loop principale di controllo a questo punto, riceve i dati da rc e riceve i dati da sensor.py (che e’ un altro thread in parallelo) quali il roll, pitch e yaw attuali.Calcola l’errore fra dati attuali e desiderati e tramite il controllo PID effettua le necessarie correzioni alle velocita’ dei motori.

Non publico ancora alfa3.py perche’  ho riscontrato un problema su rc.py : i comandi inviati non vengono gestiti immediatamente. Voglio prima capire il motivo di questo ritardo.

 

 

 

 

Alfa3test. Introduzione del PID ed altro…

Partendo da questa serie di test Alfa3, ho introdotto alcune novita’  che vanno verso la soluzione finale. alfa3_pic1In particolare ho fatto le necessarie modifiche per lavorare completamente wireless:

  1. Ho aggiunto un secondo ESC ed un secondo motore.
  2. ho modificato la mia connector board aggiungendo  un nuovo  connettore 3 pin in cui ho anche saldato il cavo di potenza (filo rosso).Ho poi collegato lo zero (filo nero) ed ho ponticellato il pin del segnale (filo bianco) con lo stesso  dell’ultimo segnale (file verde nella foto).connector_board In questo modo posso scegliere se alimentare rpi da esc oppure no, a seconda che collego esc su B o su C.
  3. Pertanto lo schema prevede il motore M[0] collegato sul connettore A, ed il motore M[1] sul connettore C (oppure B se decido di alimentare rpi con usb esterna).
  4. Ho connesso la chiave usb Wifi al rpi. Ho pero’ notato che ne il pc ne la chiave hanno la possibilta’ di diventare accesspoint. E’ possibile verificare la cosa usando il comando:

iwconfig ap

Quindi ho utilizzato il mio smartphone attivando la funzione  router wifi e creando  cosi’ una rete che include anche il pc ed il rpi.

Di seguito lo  schema delle convenzioni per questo test:

alfa3_convention

  • M[0] ruota in senso antiorario , con cavo rosso montato su cavo T dell ‘esc (quello vicino alla T del logo turnigy) ed il cavo giallo sul cavo Y dell’esc.
  • M[0] monta un elica sinistra standard (non marcata R).
  • M[1] ruota in senso orario , con cavo giallo montato su cavo T dell ‘esc ed il cavo rosso sul cavo Y dell’esc.
  • M[1] monta un elica destra (marcata R).
  • Per come e’ stato montato l’IMU, ottengo una rotazione negativa del roll (intorno alla x) quando M[0] va verso il basso.

Con questa configurazione ho gia fatto alcuni test preliminari.Nel prossimo post introdurro’ il nuovo modulo del remote control (rc.py)  ed i primi risultati del controllo PID , in cui ho usato solo il P.

SW Dev: Modello matematico del loop di controllo

Prima di avventurami nello scrivere il codice in python del controllo ho provato a mettere giu il modello matematico che riproduca il comportamento dinamico teorico del quadricottero.Lo potete trovare qui in control_loop.xls.[Rimosso. Vedi qui]

 

Per favore,se qualcuno interessato mi invia i dati del proprio quadricottero (lunghezza motore-centro quad ,  massa braccio, massa motore, massa totale e velocita di hover,e parametri PID) mi piacerebbe buttarli dentro e validare il modello.

Ipotesi iniziali:

  • Quadricottero configurazione +
  • Caso di rotazione Roll

Dati:

  • R.target e’ il valore desiderato
  • R.acc  e’ l’accelerazione angolare ( che calcolo in funzione delle velocita angolari w del motore, al passo precedente

L’equilibrio dimanico e’ dato da:

(F1-F3)b=I R.acc       Kprop(w1^2-w3^2)b= I R.acc

con Kprop=(Mtot*g)/wh^2  I=(Mbar*b^2)12+2*Mmotor*b^2

R.acc=Kprop*(w1^2-w3^2)b/I

  • R.vel  e’ la velocita’ ricavata come integrale di R.acc
  • R.curr e la rotazione teorica del quadricottero ricavata come integrale di R.vel.Tale valore corrisponde il linea teorica al valore che dovrei leggere col giroscopio.

PID

Pertanto questo modello mi permette di  giocare con i parametri P,I,D , vedere come potrebbe oscillare e di ottimizzarli di conseguenza.

SW Dev : intro loop di controllo

Finora lo sviluppo sw ha incluso funzionalita di jogging base andando a modificare direttamente le velocita’ dei motori e lasciando all utilizzatore la loro modulazione.

A questo punto ho introdotto il concetto di controllo in cui l’ operatore indica l’ angolo desiderato ed il controllore , il nostro rapberry pi, deve decidere le velocita’ dei motori.

control_loop

La relazione teorica fra angolo del quadricottero (sia esso roll, pitch, yaw o una combinazione di essi) puo’ essere ritrovata nella pagina del quadricottero.
L equilibrio che si ottiene e’ di tipo instabile: e’ sufficiente un minimo disturbo (ad esempio un alito di vento) perche tale equilibrio si perda.

Nella realta’ bisogna anche considerare dissimetrie costruttive (struttura, eliche etc.), o comportamenti non costanti dei motori.

Cio si traduce nella necessita’ di sapere:

  • qual’e’ il comportamento istantaneo del velivolo
  • qual’e’ la reale relazione fra angoli e velocita motori in quanto differente da quella teorica

Per il primo punto si deve introdurre qualcosa che possa leggere lo stato attuale del quadricottero, diciamo un sensore.
Nella maggior parte dei casi si utilizza un sensore montato a bordo come un giroscopio o un giro+ accelerometro.

Il giroscopio ritorna la velocita angolare dal cui integrale si ottiene l’angolo.
L’ accelerometro ritorna l’ accelerazione nelle sue componenti x,y,z

Quindi, noto l’ angolo attuale e l’ angolo desiderato (target) posso calcolare l’ errore e decidere una strategia di modulazione della velocita’ dei motori.

Tale strategia si traduce in un metodo di controllo denominato PID.

Si ipotizza cioe’ che la relazione fra due variabili (nel nostro caso velocita’ angolare del motore e angolo) sia approssimabile a tre componenti:
Proporzionale (P) = kp*Ei
Integrale(I) = Ki* sum (Ei)*t
Derivativa(D)= kd * (Ei-Ei-1)/t

Dove Ei e’ errore fra w target e w current all’istante i-esimo, t e’ il tempo ciclo del loop
Dove i vari k vanno determinati empiricamente.

Il pid qundi mi restituisce un valore di variazione motori che deve permettere di minimizzare E.

Un loop di lettura da sensore, calcolo correzione con pid e applicazione correzione w motori costituisce la base del controllo d’ angolo.

Nei post seguenti dedichero’ una descrizione specifica agli specifici blocchi: sensore, PID e control loopcon lo scopo di definire la struttura finale del programma.