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!