Archivi categoria: testing

Sulla calibrazione dell’IMU

I’d like to put here some consideration about the imu calibration, that means how it is mounted the imu on the drone respect the propeller plane. This information is fundamental to garanty a perfect hover position without lateral mevement of the drone.

In other words, if I set roll=0 and pitch=0 I want that the prop plane is aligned with the world, evenif the sensor can be not perfectly aligned with the world (and also with the propeller plane).

In this pictures you can see this case: the world (blue) , the sensor (red) and the prop plane ( orange).

IMU_cal1 IMU_cal2

In the next picture let’s put some manes to the angles:

IMU_cal3

Important: Note that gamma is the angle measured by the accelerometer.

The most important information I need to know is the angle beta : the offset between the sensor and the prop plane . this is the error generated to the mechanical installation of the imu.

This value is used to compensate the measured value from the accelerometer.

alpha and beta are the 2 unknowns so I need 2 equations to solve this problem.

I decide to use this simple method to calibrate imu:

1) Take a reference plane ( my kitchen table) . It does not metter if it is not perfect alingned to the world, it is just enough it is stable.

2)Place from behind the prop plane on the “table roof”.

IMU_cal3b

3) Measure the angles of the accelerometer (gamma1).

4)turn the drone 180 degree respect yaw and place it again on the table roof.

5)Measure the angles again ( gamma2) .

6)consider that, in those 2 measurements, the alpha angle is constant ( i do not move the table…) , while the angle beta is equal but inverted ( due to the rotation of the drone).So the result is:

IMU_cal4

 

In order to manage this method in a easy way I added in the code the option called “fine calibration” .

The last version is now on github.

Just run the myQrc.py , move to the new mode “IMU” and follow the instructions.

 

 

 

 

myQrc Rilasciata

I just upload the last and final version of the myQ release candidate on github

DSC_6918

All the software has been debugged and tested.

All the functionalities are now stable.

I tested in different options (debug mode, netscan activated, sensor log) and the result is that I can run the main loop every 10 ms and get sensor data every 6 ms.

It can happen to have a delay on the sensor data loop when a log is added ( 2/3 ms).

 

I removed the webserver from the list of test to do, so it is not supported in this version of the software. The main reason is an instability when runnin gon raspberry. I have to investigate a more robust way to manage the comunication via browser.

 

Next time I will write a post the drone will be just landed…(after its first flight!!!)

myQrc. Aggiornamento sviluppo

Just a quick note of the current development.

I tested sucessfully:

  • ESC mode
  • Motor mode
  • sensor.py – I modify the calibration procedure.Now after a calibratin, you can see the angles really equal to zero.
  • display.py – add yaw in the kayboard command

Performance test: I can run the mian task and update sensor every 5ms.

(need to take care on log: everytime I add a log line this time goes up to 16ms ,probably it is the time to open ,write and close the file. So when flying ,do not use debug level).

I’m now facing on some problem with netscan function. The main scope of it is to monitor that the PC used to send command , is always connected to rpi. It is working fine whentested on laptop. In rpi is not so stable. I’m investigating on that.

Also the webserver has got some problems when running on rpi: if i double click on the browser button, sometime it freeze the main task: not so good… (I’m thinking to remove this funciton from version 1)

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

 

Beta1 Test. Introduzione SW

Questo il codice  Beta1 Software.

Ho completato il test preliminare , validando le seguenti funzionalità di base:

  • Gestione di 4 motori.
  • Gestione IMU, inential measurament unit (MPU6050).
  • Controllo Remoto (fatto usando ssh ed il laptop).Posso variare  roll e pitch target. Yaw non è per il momento gestito. Posso avviare il controllore PID per il solo roll o per roll+pitch.
  • Controllore PID per  roll e pitch.
  • Display con le informazioni attuali.
  • log file.
  • Gestione arg params ( -s = save log, -c = calibrate IMU)

Ho aggiunto un nuovo modulo chiamato quadricopter.py dove ho posto tutti i componenti necessari già discussi in passato.In questo modo vi posso accedere semplicemente: per esempio con myQ.motor[i] o myQ.sensor.roll.

Rocordo che l’oggetto sensor e l’oggetto rc stanno ora girando come thread in parallelo.

Il main loop e’ settato con un tempo ciclo di 10ms, ma devo investigare se questo valore resta stabile nel tempo e soprattutto se e’ sufficiente per il controllo del drone.

Un nuovo display mostra lo stato attuale del includendo  roll, pitch and yaw , motors rate , throttle e la lista dei comandi ammessi per il  remote control.

beta1 display

Il principale obiettivo ora è effettuare il tuning dei parametri PID per poter bilancire la struttura ( Ricorda che in questa fase ho posizionato una semi sfera sotto il drone per testare il bilanciamento senza dover volare).

 

 

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. 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.

Alfa2test. Aggiunta del controllo PID

Questo  Alfa2 test  ha lo scopo di introdurre nel codice la parte dedicata al controllo PID (si veda questo post per una descrizione di come funziona il PID).A tale scopo si e’ introdotto il nuovo modulo pid.py.Qusto il codice completo alfa2test

Il layout usato e’ ancora quello del alfa1test,  cioe’  con un solo motore montato sulla struttura e la struttura libera di muoversi  con un solo grado di liberta’.

Il software parte da alfa1test ma introduce due nuovi elementi:

  1. Il controllo PID pre il quale la velocita del motore viene calcolata in automatica dal software  con l’obiettivo di raggiungere un roll target, rispetto al valore di roll letto dal sensore IMU.Da notare che nel software vi sono 2 parametri che possono essere regolati per tenere sotto controllo il  loop di controllo.Questi parametri sono la maxW  che si impone al motore e il pid maxCorrection , cioe il massimo incremento consentito alla veocita’ angolare ad ogni loop.
  2. La possiblita’ da parte dell’operatore di far variare il valore dell’angolo di roll con i tasti a  (incremento) e z (decremento).

Lo scopo principale di questo test era quello di:

  1. puro debug e verifica del codice
  2. verifica del log generato
  3. prima analisi del log generato.

Di seguito l’andamento del roll avendo lasciato sempre roll target =0  ed il valore della velocita angolare del motore.

alfa2

La cosa che piu mi premeva in questa fase era quella di verificar che il valore della correzione seguisse correttamente il valore del roll misurato.

Due commenti:

  1. il questo test non ho lavorato ancora sui singoli parametri del PID.L’obiettivo sara’ sicuramente quello di far variare kp,ki e kd al fine di eliminare questo comportamento periodico
  2. nella fase in cui riduco la velocita’ del motore, l’unica forza che contrasta l’inerzia e solo la gravita’.Ne consegue un overshoot negativo del roll ad ogni periodo.

Al fine quindi di poter avere un comportamento piu realistico del test e poter quindi cominciare a fare il tuning del PID  nel prossimo test alfa3test introdurro il secondo motore.

Alfa1test. Preparazione

Durante gli ultimi fine settimana sono stato impegnato , cosi’ non mi e’ stato possibile continuare i test.

Ad ogni modo ora in questo post introduco il codice che ho creato per quello che ho creato alfa test, una sessione di verifiche per preparare il codice finale.

Alfa1 test include le seguenti funzionalita’:

  1. jogging manuale del motore
  2. lettura del IMU
  3. Logging dei dati(w motore,e angoli dell’IMU)

Le azioni da prendere durante questi test sono:

  1. verificare i disturbi sull’IMU per via delle vibrazioni motore
  2. testare differenti valori del filtro IMU
  3. avviare il motore e provare a capire con questa configurazione qual’e’ il valore di velocita’ angolare di equilibrio (hover w)
  4. capire al variare di w come varia angolo del quadricottero
  5. montare differenti pesi sul braccio del quadricottero e vedere i diversi wh per verificare il mio modello matematico
  6. misurare la velocita’ angolare reale del motore con il mio smartphone (solo curioso sulla possibilita’ di misurare la frequenza usando un sound spektrum analyzer)

Spero di iniziare domani alfa1test , poi potr’ condividere il codice.