Archivi categoria: sw dev

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)

myQrc. Release candidate su GitHub

TODO Tradurre…

Hello, I just upload the myQ release candidate on GitHub. (see permanent link on the right).

It is derived by my beta3.py but includes many additional features:

  • a new display that can show the current state of the quadcopter( orientation and motors)
  • The possibility to switch between modes (init ESC, test Motors, tune PID an so on) .Any mode has got its own tab with an explanation of what yuo can do.
  • a web server that can provide a web page to be used as remote control.From any device using browser just connect to 192.168.0.1/myQ.html and you get the command page. (honestly it could be a little too slow for a quadcopter, it should be better to use socket messaging )

webserver

  • a netscan functionality in oder to be sure that quadcopter did not loose connection with the remote control

So finally it is time to move back to the field, load all this new things on the rpi and deeply test it!!!

Beta2Test.Connessione sicura

Oggi il controllo remoto del drone e’ fatto  via wifi col mio laptop tramite ssh.

Ad ogni modo il software e’ progettato (anche se non ancora completamente sviluppato) per ricevere dei comandi da qualunque tipo di device  (smartphone, tablet e cosi via). Guarda questo post per approfondimenti.

comm

Quindi e’ fondamentale che il drone mantenga una stabile e costante connessione con il comando remoto.

Al fine di verificare una costante connessione ho creato una nuova classe chiamata  netscan ch eutilizza in comando ping per verificare la connessione di un dato ip address.

Questo oggetto lavora in un thread in parallelo monitorando la connessione ad intervalli prefissati di tempo.

In questo  esempio di codice si trova  netscan.py e  netscan_test.py

In netscan_test.py si vede come creare a inizializzare l’oggetto netscancan e avviare il thead.

Ho messo particolare attenzione alle performance del sistema al fine di verificare che non riduca il tempo ciclo del main task ( in questo esempio un semplice calcolo).  Per il momento ho effettuato i test solo sul laptop ed il risultato e’ soddisfacente.

Non appena la comunicazione viene persa netscan reagisce.

Aggiungero questo nuovo oggetto nel mio prossimo beta3test  in arrivo.

 

 

 

Beta2test. Prima delle vacanze

Durante l ultima settimana ho introdotto alcune migliorie sul codice che devo riportare qui prima di dimenticarle dopo le imminenti vacanze.

  • aggiunto possibilità di tuning manuale al volo per P,I e D.
  • in pid.py aggiunto una funzione per calcolare la media sul valore di D_correction calculation.Questo aiuta ad avere un valore più arrotondato.
  • Aggiornamento risultati sul display ogni 0.2 sec, invece che ad ogni ciclo (per ridurre il carico CPU ).
  • migliorato log
  • Calcolo della velocità angolare (roll_rate, pitch_rate and yaw_rate) in sensor_py. Questi valori sono ottenuti dalla derivata di roll,pitch e yaw già filtrate col complementary filter. Non come row roll_rate,pithc_rate e yaw rate del giroscopio.

il principale miglioramento e’ comunque stato l introduzione del PID per roll_rate (picth_rate and yaw_rate). Ho creato beta2.py dove ho messo due PIDs in serie. Questo è un tipico approccio per il controllo dei droni. Il primo PID restituisce la Roll_correction. (cioè di quanto voglio far variare l angolo in un passo).

Dividendo Roll_correction per cycletime, si ottiene l la velocità angolare che voglio ottenere in un passo.Questo e il target per il nuovo roll_rate PID. Mentre il feedback e’ la velocità angolare calcolata in sensor.py. Il risultato è un quadricottero molto più stabile, meno nervoso e più pronto.

sotto Ho riportato i primo test.

Beta2_pid_tuning

 

come si può notare e’ ancora presente un oscillazione, comunque compresa fra +/- 1 gradi. Occorre lavorare ora per fare in modo che il sistema raggiunga il target.(ora e’ sempre sotto). Probabilmente occorre incrementare il valore di P ed I.

Beta1test. Bachi e passi avanti

Ieri ho ottenuto questo risultato:

beta1_graph1

Grazie alle seguenti azioni:

1)Il test con la semisfera montata sotto il quadricottero non mi convinceva piu’. l’attrito, i limiti sulle rotazioni dovuti al pavimento sono vincoli non presenti nel volo.

Per cui ho deciso di passare alla soluzione piu usata e riconosciuta , appendendo il drone con due fili.

beta1_tied_up

2) A questo punto mi sono accorto che c’era qualcosa di anomalo nel comportamento dei motori. Eseguendo   beta1.py  il suono del motore era discontinuo e instabile anche se non avevo ancora attivato il controllo PID , ma mantenendo la velocità costante.

Questo non accadeva se eseguivo  motor_test.py.

Alle fine sono riuscito a riprodurre il problema e ho riscontrato un baco (o meglio un comportamento inatteso)  nella libreria RPIO. Ho riprodotto il problema con il loop sottostante :

while true:

mymotor.servo.set_servo(self.pin, PW)

sleep(0.01)

 

La spiegazione che mi son dato e’ che cad ogni chiamata di  set_servo() , viene resettato a zero il segnale e poi settato nuovamente al valore desiderato di PWM.

Pertanto ho usato una funzione a piu basso livello :

myMotor.PWM.add_channel_pulse(1,self.pin,0,PW)

A questo punto nel loop ho ottenuto un suono del motore (e quindi la sua rotazione) perfetto stabile e costante.

Questi 2 miglioramneti mi hanno permeso di fare un passo avanti. Il tuning puo’ procedere in modo piu’ veloce.

Sopra e’  mostrato il grafico del comportameto attuale.In blu in roll target , in rosso la posizione reale del roll. Devo migliorare il tuning per ridurre il tempo necessario a stabilizzarsi (ora 5/6 seconds)e per eliminare le oscillazioni ( +/- 3 gradi). Ma sono comunque soddisfatto della situazione attuale.