Pages: 1 2 [3] 4   Go Down
Author Topic: input e ragionamenti per il PID  (Read 3648 times)
0 Members and 1 Guest are viewing this topic.
Offline Offline
Edison Member
*
Karma: 11
Posts: 1489
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

veramente, ho trovato + "facile" (si fa x dire =P) modellare le equazioni dei brushed
che, nel caso dei pessimi motori che avevo in laboratorio, hanno una efficienza del 70%
ma tanto fintanto che si tratta di fasi di studio, l'alimentazione non e' un problema
(e' via filo)

quando dico controllo di quota minima, intendo pochi cm da terra: 50cm per l'esattezza
misurati con un sensore ad ultrasuoni (range 10cm-6m)

l'obbiettivo minimo infatti non e' un volo, ma un vertical take off con controllo di quota
cioe' alzarsi da terra, e mantenere quanto meglio la posizione
correggendo quanto meglio ogni singola perturbazione

e questo integrato nel lungo periodo
(anche mantenere la posizione per un paio di giorni)

e' questo che mi interessa studiare, in questo momento

e quando questa fase avra' convinto, si passera' alla successiva: il volo per punti stabili
sempre in laboratorio e per quote minime (40cm - 1m)

a quel punto iniziera' prima la fase a batterie, sempre per piccoli spostamenti
poi + significativi
(cioe' diversi metri da terra, ma sopratutto intorni circolari di diverse decine di metri)
e allora avra' senso .... aggiungere un gps





cmq per la meccanica, per i motori brushless, e per le 2 coppie di propeller
quasi quasi opterei per un kit-drone =P




p.s.
il sistema e' basato su una scheda di sviluppo arm-9-linux/uclibc
connetto i sottomoduli dspic33, 328 sensori e controllo motori
attraverso vari bus, spi, i2c, seriale
conto, se dovesse servire, di fare anche uso del bus locale e del dma

trovo molto comodo questo approccio
perche', assunto che i vari moduli dspic e 328 abbiano fw stabile congelato nelle loro flash
posso compilare a bordo il software di volo
comodamente connesso ssh via wifi
(gcc-chain nativa arm, gira a bordo della scheda, su mmc/sd card)

il kernel linux non e' real time, andrebbe patchato rtai
per ora non e' un problema




p.s.
mi piace il sistema che hai adottato per assorbire le vibrazioni =D
« Last Edit: June 03, 2011, 08:05:04 am by flameman » Logged

0
Online Online
Shannon Member
****
Karma: 117
Posts: 10113
:(){:|:&};: TOX id: fcb8e918bef08581e23f6ddf9d4dba77697c25b217bf372736ed959a95fde36df5b8c5b90fbb
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

se usi gli ultrasuino, e hanno una buona precisione (meno di un cm di errore, poi dipende dalla lunghezza dei bracci) puoi evitare giroscopi e accelerometri.

mi piace molto l'idea dell'uso dell'arm, io sto pensando di prendere un 400/600mHz così posso fare compressione e stream video, oltre che di dati, via wifi (o magari xbee da 1km, si vedrà)

per i test che ho fatto, è meglio se il PID lavora con valori lineari. quindi, a banco, misura per ogni segnale pwm (io ho usato il PPM essendo brushless), qual'è l'effettiva spinta del motore.
Otterrai una parabola, che trasformi in funzione. Il pid ti dirà la spinta in kg forza che vuole, la funzione la trasforma nel segnale e via.
In questo modo un pid anche solo P dovrebbe funzionare, altrimenti il PID dovrebbe avere valori che "assomigliano" alla curva motore+la correzione
Logged

my Arduino code: https://github.com/lestofante/arduinoSketch
sei nuovo? non sai da dove partire? leggi qui: http://playground.arduino.cc/Italiano/Newbie

Rome (Italy)
Offline Offline
Tesla Member
***
Karma: 120
Posts: 9185
"Il Vero Programmatore ha imparato il C sul K&R, qualunque altro testo è inutile e deviante."
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

In questo modo un pid anche solo P dovrebbe funzionare, altrimenti il PID dovrebbe avere valori che "assomigliano" alla curva motore+la correzione

Un PID solo P non esiste, non è nemmeno possibile raggiungere il valore desiderato usando solo la P.
Il PID non deve avere valori che assomigliano alla curva motore+correzione, il PID deve essere modellato sulla funzione di trasferimento del sistema nel suo globale.
Logged

0
Online Online
Shannon Member
****
Karma: 117
Posts: 10113
:(){:|:&};: TOX id: fcb8e918bef08581e23f6ddf9d4dba77697c25b217bf372736ed959a95fde36df5b8c5b90fbb
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

ok, credevo che quello fosse il motivo, comunque sia via simulazione 3d che nella realtà, l'uso del pid sulla forza voluta e non sul segnale ppm ha dato risultati migliori. Io pensavo fosse quel motivo, poi nella realtà cosa succeda, ho "tirato ad indovinare".

Non capisco perchè un solo P non esista, in fondo è una proporzione, più ti avvicini al valore desiderato e più l'output è 0. Che poi il P possa funzionare solo nella teoria, non so.
Logged

my Arduino code: https://github.com/lestofante/arduinoSketch
sei nuovo? non sai da dove partire? leggi qui: http://playground.arduino.cc/Italiano/Newbie

Rome (Italy)
Offline Offline
Tesla Member
***
Karma: 120
Posts: 9185
"Il Vero Programmatore ha imparato il C sul K&R, qualunque altro testo è inutile e deviante."
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Ma l'hai letto il tutor di Livio Orsini sul pid che ti ho linkato ?
Anche se è un entry level contiene molte risposte, inclusa quella perché un PID non può essere solo P, e le basi per capire come funziona il PID.




Logged

Offline Offline
Edison Member
*
Karma: 11
Posts: 1489
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

per l'obbiettivo minimo che ho fissato
"vertical take off e mantenimento di quota"
non basta il solo altimetro!

come ti ha ricordato astro
"i motori sono tra loro vincolati a coppie
e quello che ti interessa è solo la velocità angolare e l'inclinazione per ogni asse"

quindi serve quantomeno anche un "inclinometro di volo"
(varie tecniche per farlo)
che esprime cioe' gli angoli di assetto rispetto all'earth

ma anche cosi' le informazioni non bastano
« Last Edit: June 03, 2011, 06:25:32 pm by flameman » Logged

Offline Offline
Edison Member
*
Karma: 11
Posts: 1489
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

PID
seghalo questo
http://www.ni.com/pdf/manuals/322192a.pdf
e' ottimo se si vuole studiarlo un po' con labview

e questo
http://wwwdsa.uqac.ca/~rbeguena/Systemes_Asservis/PID.pdf
alla voce che effetto hanno i 3 parametri del pid nella risposta dinamica
« Last Edit: June 03, 2011, 03:13:33 pm by flameman » Logged

Offline Offline
Edison Member
*
Karma: 11
Posts: 1489
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

astrobeed ma ti sei cimentato anche tu nella realizzazione di un 4-coptero =P ?
Logged

0
Online Online
Shannon Member
****
Karma: 117
Posts: 10113
:(){:|:&};: TOX id: fcb8e918bef08581e23f6ddf9d4dba77697c25b217bf372736ed959a95fde36df5b8c5b90fbb
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Ma l'hai letto il tutor di Livio Orsini sul pid che ti ho linkato ?
Anche se è un entry level contiene molte risposte, inclusa quella perché un PID non può essere solo P, e le basi per capire come funziona il PID.

no  smiley-red, ma ho letto altri documenti. link? forse questo? http://docs.google.com/viewer?a=v&q=cache:fevaQ11rQ5AJ:www.fabbrimarco.com/droboitalia/Le%2520guide%2520di%2520Roboitalia%2520-%2520il%2520PID%2520facile1.pdf+Livio+Orsini+pid&hl=en&gl=my&pid=bl&srcid=ADGEESiqI5TJLAa8IqOC38cE3kWkwEYus-jSynodEj99bmR3FVkBVGQd9JMN4U0WwZCL_ZrVhL0TEB7hwiAme1K6RMOhwjahvQ-8oY4aCfJupwqU3oqPkwGduuLzjZWxcRBaz8wFWE6v&sig=AHIEtbTW1pjYRCeso6scQnu9k9M_O17ugg

Quote
non basta il solo altimetro!
serve quantomeno anche un "inclinometro di volo"

scusa mi sono espresso male, intendevo che avessi 3 o 4 sensori di distanza:
o uno al centro del mezzo e due all'estremità dei bracci, o i classici 4 all'estremità dei bracci. Però a questo punto il suolo deve essere perpendicolare alla gravità, piano e i sensori precisi (specialmente nella configurazione a 3, che per la stessa precisione in lettura di uno a 4 il sensore deve avere il doppio di risoluzione).
spero do non aver detto ancora castronerie smiley

Quote
e ancora le informazioni non bastano
così hai sensore di quota + inclinometro (sia che usi 3/4 di profondità sia un sistema più canonico come IMU o meglio MARG), quindi dovresti esserci con take off e mantenimento quota. Manca (se usi una MARG) il sensore di posizione assoluta per un sistema a waypoint: il GPS, ma sbaglia di molti metri, oppure una triangolazione di segnale ma devi a priori mette delle antenne (almeno 2 a differenti x, y, e z, se non erro).
Attento all'effetto suolo, a 50cm non credo che si senta, dipende anche dalla potenza dei motori, ma ti sballa un sacco i calcoli
Logged

my Arduino code: https://github.com/lestofante/arduinoSketch
sei nuovo? non sai da dove partire? leggi qui: http://playground.arduino.cc/Italiano/Newbie

Offline Offline
Edison Member
*
Karma: 11
Posts: 1489
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

no, non ci siamo

anche fosse preciso al mm di altimetro ne servirebbe uno soltanto, al centro
serve per stimare la quota h, spannometricamente
perche' non ha troppa importanza che h sia precisa
quello che importa e' che fissata una certa h
questa quota venga mantenuta
senza che l'aeromobile compia rotazioni lungo gli assi
o accellerazioni (in questo caso lungo x y)

per il mantenimento di assetto gli "inclinometri di volo" sono fondamentali
servono per l'axial tilt e si possono realizzare in diversi modi
tra cui
- usare 2 accelerometri inclindati di 45 gradi, 2 accelerometri per asse, x-y
- usare gyro-3assiale e accelerometri-3assiali correlati in logica quaterninica (complesso ma fattibile)
- usare Horizon sensor optical instrument that detects light from the 'limb' of the Earth's atmosphere
es 4 sensori MLX90247-ESF-DSA disposti ai lati di un quadrato

l'ultima non mi convince del tutto
non ho mai potuto usare quei sensori
cmq c'e' chi li usa, a suo dire, con successo

ma anche cosi' non ci siamo: in un caso reale la posizione e' continuamente perturbata
perturbata al punto che la retroazione del pid lavora, e lavora parecchio !
deve lavorare parecchio
e lo deve fare per mantenere quanto piu' nullo l'errore di "posizione desiderata"
a fronte di continue perturbazioni del punto di lavoro che sono inevitabili

e bada bene, si vuole che quel punto sia avvicini al punto desiderato
anche una risposta dinamica particolare
ovvero con la minore sovraelongazione possibile
e con un tempo per andare a regime quanto + corto possibile
e con oscillazioni quanto + irrisorie possibili

ecco qui tutta la presenza sinergica delle 3 azioni P, I, D


per compensare le perturbazioni
che sono accelerazioni lungo i 3 assi e rotazioni attorno ai 3 assi
(anche infinitesime, ma ci sono)

servono anche accelerometri 3-assiali e gyro 3-assiale

per un buon progetto servono cioe' tutte le 9-10 variabili di controllo
- ax,ay,az
- gx,gy,gz
- axial tilt xy, oppure teta1,teta2,teta3 (angoli di eulero)
- h
« Last Edit: June 03, 2011, 07:00:43 pm by flameman » Logged

0
Online Online
Shannon Member
****
Karma: 117
Posts: 10113
:(){:|:&};: TOX id: fcb8e918bef08581e23f6ddf9d4dba77697c25b217bf372736ed959a95fde36df5b8c5b90fbb
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

se mettessi, caso più semplice, 4 sensori di distanza alla fine di ogni braccio, e dando per scontato:
Quote
Però a questo punto il suolo deve essere perpendicolare alla gravità, piano e i sensori precisi
puoi ottenere la tua inclinazione X usando il teorema dei seni, se non erro
angolo =asin( ( distanzaX1-distanzaX2*sin(90°) )/lughezzaBraccioX )


per le 3 azioni pid mi son ben accorto che lavorano alla grande nella realtà smiley

Quote
usare 2 accelerometri inclindati di 45 gradi, 2 accelerometri per asse, x-y
non conoscevo questo metodo, come fai ad eliminare le accelerazioni?

Quote
usare gyro-3assiale e accelerometri-3assiali correlati in logica quaterninica (complesso ma fattibile)
aggiungici anche 3assi di magnetometro se vuoi un controllo assoluto anche sullo yaw, se però vuoi solo il mantenimento di quota ti basta ciò che hai

Quote
usare Horizon sensor
i sensori di orizzonte esistono di vari tipi, so che sono stati usati con successo indoor, ma hanno qualche problema a lavorare all'aperto

Quote
ecco qui tutta la presenza sinergica delle 3 azioni P, I, D
mai detto che non serva, ma che secondo me lavora meglio (ovvero è più facile da settare la terna) se la risposta al suo output è lineare(ovvero il pid da un ouput una forza peso), anziché parabolica (il pid outputta direttamente il PPM)

Quote
per compensare le perturbazioni
che sono accelerazioni lungo i 3 assi e rotazioni attorno ai 3 assi
(anche infinitesime, ma ci sono)
qui non ti seguo. Se precedentemente hai usato uno degli altri 2 punti discussi sopra (4 assi di accelerometro o sensore di orizzonte) in teoria non hai bisogno di tutti questi sensori, perché sono in parte derivabili dai valori che già possiedi.


comunque a livello di test con un motore fisico (jbox2d), possiedo un algoritmo (non fatto da me, ma da un mio compagno di uni) che usa se non erro 3 PID, per mantenere l'angolo, l'altezza, e la posizione. Lavora in 2d, ma non dovrebbe essere difficile portarlo in 3d(ciò vuol dire il doppio dei pid)
se vi interessa posso chiedere se posso postarlo, ma non aspettatevi una buona leggibilità del codice, sono i tentativi fatti mentre preparavo il motore fisico in 3d (jbullet) smiley-grin
Logged

my Arduino code: https://github.com/lestofante/arduinoSketch
sei nuovo? non sai da dove partire? leggi qui: http://playground.arduino.cc/Italiano/Newbie

Offline Offline
Edison Member
*
Karma: 11
Posts: 1489
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Quote
Quote
usare 2 accelerometri inclindati di 45 gradi, 2 accelerometri per asse, x-y
non conoscevo questo metodo, come fai ad eliminare le accelerazioni?

Deve essere, faccio speculazione. una moda lanciata da un articolo scientifico che sinceramente mi devo esser perso, ma di cui ho notato la diffuzione in molti Application Notes da parte di molti costruttori di accelerometri.

Si tratta di 2 inclinometri per asse fra loro ortogonali, messi ad ad "L", per capirci
e il tutto, la "L", e poi e' inclinato di 45 gradi rispetto all'asse di cui si vuole valutare l'inclinazione rispetto all'earth

Disegnando i vettori la "magia" si evince dai conti: del resto il sistema, l'artificio, la geniata di averci pensato, e' progettato apposta per rispondere alla necessita'di essere immune dalle accelerazioni nel valutare l'angolo che assume la normale all'asse del sensore rispetto all'asse del vettore gravita'. Il trucco consiste in una somma differenziale vettoriale. Tutto un gioco di geometria, e di vettori, dunque.

Numericamente ci sono delle limitazioni, sono richiesti calcoli trigonometri inversi, e l'angolo di inclinazione massima e' limitato nel ragne -30..+30.
Correzioni, o calibrazioni, del 45 gradi della "L" rispetto all'earth e' fattibile (anche se in pochi, negli application note, riportano il risultato finale dell'equzione per intero"

Dal mio punto di vista avrebbe senso anche una calibrazione. Del resto ... e' anche vero che poi in molti utilizzano lbrerie fixed con pochi bit decimali, il che vanificherebbe l'informazione correttiva della calibrazione.

Quote
Quote
usare Horizon sensor
i sensori di orizzonte esistono di vari tipi, so che sono stati usati con successo indoor, ma hanno qualche problema a lavorare all'aperto

Infatti non mi convincono. Ma e' anche vero che non li conosco.

Quote
Quote
ecco qui tutta la presenza sinergica delle 3 azioni P, I, D
mai detto che non serva, ma che secondo me lavora meglio (ovvero è più facile da settare la terna) se la risposta al suo output è lineare(ovvero il pid da un ouput una forza peso), anziché parabolica (il pid outputta direttamente il PPM)

Dovresti modellare meglio motori ed attuatori.

Diversamente ti si deve rispondere: assolutamente no! Nell'affermare che un PID sia + facile se e' olo P -- senza ID, ti sembra + facle, ma anche solo abbozzando una funzione di trasferimento del tuo sistmea (compresi trasduttori, attuatatori e risposta in frequenza dei motori), confezionato il regolatore R(S) .... beh, dai conti, antitrasformando da S->t, anche solo per guardare che faccia ha il grafico nel tempo della risposta del sistema retroazionato ad uno stimolo (per esempio uno scalino sca(t)), si evince tutta una discussione che ti porta a dire che R(S) e' bene che abbia tutte e 3 le azioni P.I.D.

Te ne accorgi ulteriormente se sposti la tua attenzione su e(t)

Certo, confezionare un R(S)=Kp, cioe' la sola azione proporzionale, e', anche nei conti, la cosa + facile da farsi, ma non la migliore.


Secondo me, cmq, il problema risiede nella modellazione dell'attuatore e del motore. Dubbi, oppure troppo semplficato.


Quote
Quote
per compensare le perturbazioni
che sono accelerazioni lungo i 3 assi e rotazioni attorno ai 3 assi
(anche infinitesime, ma ci sono)
qui non ti seguo. Se precedentemente hai usato uno degli altri 2 punti discussi sopra (4 assi di accelerometro o sensore di orizzonte) in teoria non hai bisogno di tutti questi sensori, perché sono in parte derivabili dai valori che già possiedi.

i 4 accelerometri sono usati, a coppie, 2 per l'asse x, 2 per l'asse y, per realizzare un inclinometro di volo: sono studiati e progettati per confezionare una coppia di angoli compresi fra -30 e +30 gradi. Il sottomodulo vede cioe' cono di 60 gradi, e si occupa solo ed esclusivamente di questo, e in questo limitato range. E' vitale nella fase di atterraggio, tanto quanto nelle indicazioni di assetto stabile in quota.

Per grandi angoli, invece, ricaverei invece l'axial tilt da accellerometro-3assiale + gyro sfruttando logica quaternionica (al limite integrando anche l'informazione di un magnetometro per meglio contenere gli errori di stima ... ma l'iinformazione andrebbe trasformata in quaternione) sfruttando invece accelerometri, e lo stesso gyro, opportunamente filtrati (kalman).

Questo modulo non lavorera'  per angoli di eulero ma per quaternioni, e questo perche' per ricavare angoli di eulero mi imbatterei in situazioni in cui e' matematicamente inpossibile non perdere un grado di liberta': Gimbal lock ... potrei risolvere usando diversi Gimbal, che soffrono del lock per angoli particolari rispetto all'earth, quindi una prima soluzione consisterebbe nell'usarne diversi, inclinati diversamente, in modo che almeno uno non sia in Gimbal lock.

Ridondanza. In questo caso non mi piace (non e' detto che non sia una soluzione, NASA l'ha usata per le missioni Apollo)

Per quel che mi riguarda, per grandi angoli sfruttero' la logica quaternionica, per piccoli angoli, invece, gli angoli di eulero.

In ogni casto quanto facevo notare e' che mantenere una posizione nello spazio richiede un grande lavoro di retroazione, un discorso interno, e di principio: spesso nelle implementazioni, come hai visto, la ridondanza di informazione trovail suo perche'.

Quote
a livello di test con un motore fisico (jbox2d), possiedo un algoritmo (non fatto da me, ma da un mio compagno di uni) che usa se non erro 3 PID, per mantenere l'angolo, l'altezza, e la posizione.

Interessante.
Logged

0
Online Online
Shannon Member
****
Karma: 117
Posts: 10113
:(){:|:&};: TOX id: fcb8e918bef08581e23f6ddf9d4dba77697c25b217bf372736ed959a95fde36df5b8c5b90fbb
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Quote
Diversamente ti si deve rispondere: assolutamente no! Nell'affermare che un PID sia + facile se e' olo P -- senza ID, ti sembra + facle, ma anche solo abbozzando una funzione di trasferimento del tuo sistmea (compresi trasduttori, attuatatori e risposta in frequenza dei motori), confezionato il regolatore R(S) .... beh, dai conti, antitrasformando da S->t, anche solo per guardare che faccia ha il grafico nel tempo della risposta del sistema retroazionato ad uno stimolo (per esempio uno scalino sca(t)), si evince tutta una discussione che ti porta a dire che R(S) e' bene che abbia tutte e 3 le azioni P.I.D.

non sto parlando nel PID usare solo la P, ma sto dicendo che se gli attuatori lavorando proporzionalmente al valore in ingresso dal pid, lavorano meglio. Quindi nel PID uso comunque i 3 valori, (in particolare nel mio caso P e D), quello che cambia è la risposta degli attuatori.
E' vero che il PID, se correttamente regolato, può tener conto della risposta non lineare degli attuatori (in fondo esiste anche per quello), ma visto che è una risposta conosciuta a priori, preferisco sgravare il problema dal PID, il cui settaggio è divenuto meno critico

Quote
Infatti non mi convincono. Ma e' anche vero che non li conosco.
quelli che ho visto io rilevavano l'orizzonte tramite UV.. inutile parlare dei problemi che si potevano avere nel caso di ombre, ostacoli sull'orizzonte, e settaggio
Logged

my Arduino code: https://github.com/lestofante/arduinoSketch
sei nuovo? non sai da dove partire? leggi qui: http://playground.arduino.cc/Italiano/Newbie

Offline Offline
Edison Member
*
Karma: 11
Posts: 1489
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

i tuoi esc che frequenza di controllo hanno ? 50Hz ?
o stai usando esc modificati per essere i2c (e rate molto molto + altri) ?
Logged

0
Online Online
Shannon Member
****
Karma: 117
Posts: 10113
:(){:|:&};: TOX id: fcb8e918bef08581e23f6ddf9d4dba77697c25b217bf372736ed959a95fde36df5b8c5b90fbb
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

uso PPM puro (50Hz). occhio però che il massimo del motore non corrisponde a 180... in un paio di prove a banco il 100% del motore per me corrisponde a circa 70/80, probabilmente intorno a 90, ovvero "il centro" del servo.

edit: sinceramente non sono molto convinto dell'i2c, sicuri che il motore riesca a battere l'inerzia in così poco tempo? magari per quad piccolini, il mio è da un 1.4kg in ODV, e quindi le eliche son grandi (tripala 9x5, ma dovrei prendere delle bipala 11x4.5)
« Last Edit: June 05, 2011, 05:42:06 pm by lesto » Logged

my Arduino code: https://github.com/lestofante/arduinoSketch
sei nuovo? non sai da dove partire? leggi qui: http://playground.arduino.cc/Italiano/Newbie

Pages: 1 2 [3] 4   Go Up
Jump to: