linuxdronelab / mpu6050_driver Goto Github PK

RC, IMU, BARO, COMPASS, PID, MOTORS.
Ogni componente deve essere configurabile ed abilitabile via kernel.
Definire i messaggi e gestirli

Integrare componenti PWM ed inoltrare l'output motori.

Realizzare su pru-rpmsg-bridge il filtro passa alto per smorzare il rumore del gyro.

Il kernel non supporta calcoli in virgola mobile.
Togliere la bozza di PID dal mpu6050_driver e spostarlo su PRU
Implementazione come da specifica:
PID K Module del 15/01/2019

il segnale PPM da RC deve essere gestito a 10Hz:

• usare contatore cicli di clock per gestire la frequenza corretta.
• sincronizzare con interrupt DMA completion per il canale RC (1)
  Inizio Ricezione:

1. contatore cicli di clock >= 20000000
2. start ecap
3. stop contatore cicli di clock

Fine Ricezione

1. ricevo interrupt EDMA completion.
2. stop ecap
3. trasferimento dati e clean del canale
4. avvio contatore cicli di clock

Progettare i buffer iio necessari per la configurazione dei sensori e per le informazioni da essi fornite.
Inoltre considerare informazioni che devono essere fornite da ARM verso PRU (come YPR, altitudine, etc) laddove sia necessario

Correggere su pru-components-bridge l'estrazione dei dati RC da quanto raccolto in ecap.
In questa prima implementazione prendo la prima occorrenza del segnale PPM. Probabilmente serve l'ultima completa (tutti gli otto canali) disponibile.
Eseguendo il trace dei dati estratti si notano 'scatti' di valori improvvisi. Verificare da cosa derivano.
Scartare sequenze non complete

Oggi si verifica la presenza dei dati via I2C.
Configurare interrupt su MPU6050 (per emetterla) e su PRU (per intercettarla).
Rende più rapido il ciclo di aggiornamento.

Realizzare un client ARM che gestisca la configurazione via iio e realizzi il sistema di controllo di secondo livello.
Il sistema di controllo di primo livello è gestito dalle PRU stesse ed è basato sulla regolazione delle velocità angolari.
Il sistema di controllo di secondo livello è gestito via ARM ed è basato sul controllo dell'assetto (YPR), della altitudine e della posizione

Tutti i sensori ed il RC devono essere configurabili via iio.

1. RC spento => spengo motori
2. Thrust minimo e PID minimo => attiva 'disarm motors'
3. Thrust minimo e PID centro con attivato 'disarm motors' => disarma i motori
4. Thrust minimo e PID massimo => attiva 'arm motors'
5. Thrust minimo e PID centro con attivato 'arm motors' => arma i motori

• eventuali altri comandi (esempio: attivazione calibrazione, etc)

Gli stick del RC hanno un range di valori cablato:
YAW [-60LSB,+60LSB]
PITCH [-250LSB,+250LSB]
ROLL [-250LSB,+250LSB]
THROTTLE [-500LSB,+500LSB]

Rendere configurabile le costanti numeriche.
Verificare cosa configurare in modo da evitare calcoli per i fattori in virgola fissa.

T(RC) proietta il segnale del RC nell'intervallo di valori del gyro espressi in LSB.

il canale EDMA definito per la PRU-ECAP viene oggi 'aperto' manualmente.
Verificare se possibile aprirlo via DTS, altrimenti procedere con il modulo kernel mpu6050_driver

Realizzare su pru-rpmsg-bridge la calibrazione dinamica del Gyro sui primi 10.000 campioni.
identificare offset gli offset come media dei campioni letti.

Modificare pru-components-bridge in modo che divida i segnali RC per 100 e li consegni su uint16_t.
Modificare pru_mylinuxdrone.h convertendo i valori RC in int16_t

Definire un DTS che definisca la configurazione per il drone.
Attualmente si utilizza:
uboot_overlay_addr0=/lib/firmware/PRU-ECAP-00A0.dtbo
uboot_overlay_addr1=/lib/firmware/BB-PWM0-00A0.dtbo

Togliere configurazioni inutili, riportare su un unico file ed adeguare uEnv.txt

La calibrazione dei sensori è meglio gestirla da kernel, occupa spazio inutile su PRU.