Sintonizzazione PID Quadcopter

In seguito alla domanda che ho posto qui: instabilità Quadcopter con semplice decollo in modalità autonoma ... Vorrei porre alcune domande sull'implementazione di un PID di base per un quadrotore controllato da un modulo APM 2.6. (Sto usando un frame da 3DRobotics)

Ho ridotto l'intero sistema di controllo a soli due blocchi PID, uno per il controllo del rollio e un altro per il controllo del pitch (imbardata e tutto il resto ... ci penserei più tardi).

Sto testando questa configurazione su un impianto che consiste in una trave a rotazione libera, in cui ho legato due dei bracci del quadrotore. Gli altri due sono liberi di muoversi. Quindi, sto effettivamente testando un grado di libertà (roll o pitch) alla volta.

Controlla l'immagine qui sotto: qui A, B segna il raggio che ruota liberamente su cui è montato il setup. inserisci qui la descrizione dell'immagine

Con un'accurata regolazione dei parametri P e D, sono riuscito a ottenere un volo prolungato di circa 30 secondi.

Ma per "sostenuto" intendo semplicemente un test in cui il drone non sta cadendo da una parte. Il volo stabile su roccia non è ancora visibile e anche più di 30 secondi di volo sembrano piuttosto difficili. Traballa dall'inizio. Quando raggiunge i 20 - 25 secondi, inizia a inclinarsi su un lato. Entro 30 secondi, si è inclinato su un lato di un margine inaccettabile. Presto lo trovo a testa in giù

Per quanto riguarda il codice PID stesso, sto calcolando l'errore proporzionale da un "filtro gratuito" di dati giroscopio + accelerometro. Il termine integrale è impostato su zero. Il termine P arriva a circa 0,39 e il termine D è a 0,0012. (Non sto usando la libreria PID di Arduino di proposito, voglio solo ottenere uno dei miei PID implementati qui.)

Guarda questo video, se vuoi vedere come funziona.

http://www.youtube.com/watch?v=LpsNBL8ydBA&feature=youtu.be [Sì, l'installazione è piuttosto antica! Sono d'accordo. :)]

Per favore fatemi sapere cosa potrei eventualmente fare per migliorare la stabilità in questa fase.

@Ian: Dei molti test che ho fatto con la mia configurazione, ho fatto grafici di tracciamento per alcuni dei test usando la lettura dal monitor seriale. Ecco una lettura di esempio di Roll vs "Motor1 & Motor2 - ingresso PWM" (i due motori che controllano il rollio):

Ingresso roll vs motore PWM

Per quanto riguarda l'ingresso / uscita:

Input: valori di rollio e beccheggio (in gradi), ottenuti da una combinazione di accelerometro + giroscopio

Output: valori PWM per i motori, forniti utilizzando la funzione motor.write () della libreria Servo

Risoluzione

Ho risolto il problema Ecco come:

Il nocciolo della questione risiedeva nel modo in cui ho implementato il programma Arduino. Stavo usando la funzione write () per aggiornare i servo angoli, che sembra accettare solo passi interi nell'argomento (o in qualche modo risponde solo all'input intero, 100 e 100.2 producono lo stesso risultato). L'ho cambiato in writeMicroseconds () e questo ha reso l'elicottero notevolmente più stabile.
Stavo sommando RPM su un motore mantenendo l'altro a un valore costante. Ho cambiato questo per aumentare il numero di giri in un motore mentre diminuivo il motore opposto. Quel tipo mantiene invariata la spinta orizzontale totale, il che potrebbe aiutarmi quando sto cercando di mantenere l'altitudine verticale su questa cosa.
Stavo spingendo il regime massimo al limite massimo, motivo per cui il quadricottero continuava a perdere il controllo a tutto gas. Non c'era spazio per aumentare l'RPM quando percepiva un'inclinazione.
Ho osservato che uno dei motori era intrinsecamente più debole dell'altro, non so perché. Ho codificato un offset nell'ingresso PWM di quei motori.

Grazie per tutto il supporto.

Codice sorgente:

Se sei interessato, ecco il codice sorgente della mia implementazione PID bare-bone: Codice sorgente PID

Non esitate a testarlo nel vostro hardware. Qualsiasi contributo al progetto sarebbe il benvenuto.

— metsburg
fonte

Qual è l'input e qual è l'output del loop?

— Guy Sirton,

@GuySirton: aggiornata la mia domanda

— metsburg

Quali sono quelle sezioni piatte nei comandi del motore? Sembra che qualcosa sia saturo. Rotoli le modifiche come una funzione continua ma i tuoi comandi sembrano molto bruschi. Inoltre, perché entrambi i comandi PWM del motore si spostano mentre l'input del rollio rimane in quello che sembra lo stesso range? Qual è il calendario approssimativo tra l'altro?

— Guy Sirton,

Il motivo per cui stai perdendo il controllo dopo 30 secondi è probabilmente legato alla deriva di entrambi i comandi. Penso che tu stia cercando di controllare la differenza tra i comandi ma non puoi permettere a quelli di continuare a spostarsi.

— Guy Sirton,

@GuySirton: non si stanno spostando verso l'alto, lo sto incrementando verso l'alto da zero, in modo che raggiunga un particolare stato stabile entro 3/4 secondi. Tuttavia, penso che tu abbia ragione quando dici "la ragione per cui stai perdendo il controllo dopo 30 secondi è probabilmente correlata alla deriva di entrambi i tuoi comandi". Se non utilizzo questo incremento graduale, se fisso il mio ingresso PWM a un certo livello (inferiore all'ingresso massimo mostrato sopra), il problema di perdere il controllo dopo 30 secondi scompare.

— metsburg

Risposte:

Sembra che il guadagno proporzionale sia troppo alto.
Sembra che aumenti costantemente gli RPM su un motore mentre lo blocchi nell'altro per far ruotare il sistema. Questa non è una buona strategia di controllo in quanto alla fine quelli saranno saturi e perderai il controllo. Inoltre, con l'aumentare del tempo, diminuisce la capacità di comando del sistema. Quindi hai bisogno di un modello migliore del sistema.
Se hai a che fare con # 1 e # 2 avrai un sistema più stabile ma potresti non essere soddisfatto della larghezza di banda di controllo. Per far fronte a ciò è necessario rendere il sistema più rigido, che include l'eliminazione di qualsiasi ritardo sul lato sensore delle cose e sul lato controllo delle cose.

— Guy Sirton
fonte

Comincerei leggendo questa domanda: quali sono le buone strategie per ottimizzare i loop PID?

Se dovessi indovinare, direi che hai un problema nel modo in cui è costruito il tuo filtro gratuito. Con i motori quadricottero spenti, è necessario inclinare il telaio avanti e indietro e vedere se i valori di rollio / inclinazione riportati sono effettivamente accurati.

Per me, sembra che ci sia un ritardo tra l'ingresso dell'accelerometro e l'uscita del tuo filtro - l'oscillazione potrebbe essere spiegata da reazioni tardive ai dati di ingresso. L'eventuale inversione si presenta come un possibile errore di integrazione che si accumula nel tempo - in altre parole, mentre il tuo quadricottero è dalla sua parte in realtà pensa che stia volando lentamente.

(Aggiornamento) Per quanto riguarda il tuo grafico, il fatto che la velocità del tuo motore continui ad aumentare (invece di rimanere in equilibrio) significa che hai un errore da qualche parte. Forse il tuo termine integrale sta crescendo senza limiti e dovresti specificare un limite ragionevole per questo.

— Ian
fonte

Ho aggiornato la mia domanda con i valori di rollio, inclinando avanti e indietro. Ho risolto l'eventuale inversione abbassando il mio input PWM massimo. Sembra che i valori di correzione non funzionino a RPM molto alti. Posso facilmente girare il rig con la mia mano quando lavoro ad alti regimi. A bassi regimi, sento una notevole resistenza e il quadricottero sembra tornare alla sua posizione originale (il che è buono, immagino). Quindi, il problema di "ribaltamento" è probabilmente risolto abbassando l'RPM (non so se il drone decollerà o no, spero che lo faccia). Il problema di oscillazione rimane ancora.

— Metsburg,

Se sto leggendo correttamente questo grafico, il tuo sensore di rollio pensa che inizi a , oscilli e finisca intorno a . Ma nel video, il quadricottero è dalla sua parte a . Da dove viene questa discrepanza?

- 3^{\circ}

$-3^{\circ}$

- 5^{\circ}

$-5^{\circ}$

\pm 90^{\circ}

$\pm90^{\circ}$

— Ian,

Bene, il grafico non è esattamente per il test mostrato nel video. Come accennato in precedenza, il grafico proviene da uno dei tanti test che ho fatto con questa configurazione e non ricordo esattamente come appariva questo caso particolare. Il grafico è solo per darti un'idea di come si comporta la risposta input vs output, e volevo anche stabilire che non c'è molto ritardo tra input e output (dato che il loop funziona a 150+ Hz). La corrispondenza del video con il grafico potrebbe non avere molto senso. Non ho il set esatto di dati per il test nel video.

— Metsburg,

Ho capito che il grafico è un po 'fuorviante, mi dispiace per quello. Proverò ad aggiornare il grafico con uno più accurato. In realtà, da quando stavo disegnando i dati dalla porta seriale, quando ho creato questo grafico, la scheda Arduino è stata collegata al laptop. Dopo un po 'di oscillazione, ho dovuto intervenire e rallentare manualmente l'oscillazione. Ecco perché lo vedi stabilizzarsi a - 5 gradi, mentre in realtà è di circa 90 gradi. Proverò ad aggiornare un grafico più preciso in seguito.

— Metsburg,

Un'altra cosa che vedo dal grafico è che la tua spinta combinata è in costante aumento. Sembra sbagliato.

— Ian,

Bene, potrebbero esserci diverse cose qui ...

1) Gli angoli riportati sono corretti? rumoroso? Puoi facilmente verificarlo inclinando manualmente il tuo quad e monitorando i valori che escono.

2) la tua implementazione PID ha un bug. È possibile utilizzare l'implementazione affidabile disponibile per verificare il codice.

3) Puntelli, motori montati nella direzione sbagliata.

4) ...

— dm76
fonte

1) Ho inclinato e verificato gli angoli riportati, quasi corretto, ma decisamente rumoroso. 2) molto probabilmente ... in effetti, penso che lo riassuma interamente: P 3) non molto probabilmente, due in senso orario, due in senso antiorario ... Ho controllato più volte gli oggetti di scena + Immagino che questo tipo di errore sarebbe hanno provocato errori selvaggi, ben oltre il controllo. 4) ....

— Metsburg,

4) ... un'ottimizzazione PID errata può peggiorare le cose che se non avessi affatto un PID!

— dm76,

Sì, lo vedo ora. Ci lavorerò domani. Il mio primo piano è quello di utilizzare la libreria PID attendibile e il secondo è di modificare l'output del PID dai segnali PWM alla correzione roll.pitch.

— Metsburg,