Go Down

Topic: [Multicotteri] Elettronica : IMU, MCU, Sensori ed algoritmi di controllo (Read 412364 times) previous topic - next topic

lestofante

uhmm, basta che i galleggianti non vadano a "sporcare" il flusso d'aria sotto le aliche.. sarebbe interessante una prova usando delle poveri per colorare l'aria
Guida per principianti http://playground.arduino.cc/Italiano/newbie
Unoffical Telegram group https://t.me/genuino

astrobeed

uhmm, basta che i galleggianti non vadano a "sporcare" il flusso d'aria sotto le aliche.. s
Il flusso d'aria sotto le eliche è già un caos di suo, dei galleggianti montati sul carrello, che si trova a quasi 23 cm sotto le eliche e solo pochi cm della sua estensione in lunghezza si trova il loro disco, non dovrebbe creare nessun problema.
Scientia potentia est

MM81

Ciao, sono Marco.

Sto provando a controllare la quota di un quad via sensore barometrico. Ho quache problema sia con l'algoritmo di controllo che con la elaborazione dei dati di pressione.

Se qualcuno ha esperienza in merito, o è più avanti di me e vuole condividere la sua esperienza, vorrei aprire una discussione a riguardo.

Grazie. ciao
M.

lestofante

Guida per principianti http://playground.arduino.cc/Italiano/newbie
Unoffical Telegram group https://t.me/genuino

MM81

ciao lesto.

Premessa: Oltre al cervello elettronico di controllo, di serie sul quad (kk 3.0?), ho montato arduino che si intromette tra ricevente radio e segnale da madnare ai motori. Quando aziono lo switch sul telecomando passa da modalità manuale (l'arduino fa da semplice passa carte col segnale ricevuto) a modalità altitude hold (altera il segnale da mandare ai motori in base alle letture del sensore di pressione, montato a bordo).

Il primo problema riguarda la lettura e la manipolazione dei dati misurati a bordo.
Sono riuscito a smussare abbastanza le irregolarità e liberarmi dei picchi. Ho usato un filtro a media mobile. Per ora devo ancora capire bene l'ampiezza della finestra del filtro (il numero di campioni su cui faccio scorrere la media). Devo trovare un compromesso tra reattività (minimizzare la latenza) ed efficacia (smussare troppo o troo poco) del segnale filtrato. Se lascio il sensore fermo sul mio tavolo, vedo comunque delle oscillazioni nell'ordine di 5-10 cm. Non credo di riuscire ad eliminarle: per un sensore da 15 euri non posso aspettarmi di certo i miracoli.
Stavo pensando di combinare le letture di pressione con un sensore di accelerazione verticale, magari proprio quello di cui è dotato di serie il quad. Forse questo potrebbe migliorare le cose.

Cosa ne dici?
Si può migliorare la lettura?
Ed eventualmente come?


scusa se son stato prolisso.
ciao e grazie
Marco

p.s


Il secondo problema riguarda l'algoritmo di controllo che sto usando. Ma prima di aprire un nuovo fronte, credo sia opportuno occuparsi del problema delle misure. Credo che migliorando la qualità dei dati misurati, migliori anche l'efficacio dell'algoritmo PID.

lestofante

sì, direi che migliorare il barometrico di più non puoi, se non adottanto certi trucchi tipo evitare che sia a contatto diretto con l'esterno; lo metti in una scatola stagna e poi ci fai un buco in un luogo dove non arriva aria dai motori/spostamenti, che altera la pressione.

l'accelerometro da solo non basta, devi sapere anche la tua inclinazione, e da quì puoi ricavare la tua accelerazione, e poi integrare per ottenere la velocità... ottieni in risultato molto grezzo, ma è sempre qualcosa in più.

Potresti usare un GPS, che restituisce anche l'altezza, anche quì l'errore è di parecchi cm (se vuoi mantenere una posizione relativa) ma il tutto entra nel calderone: più sensori "misceli" assieme e più gli errori si mediano.

La cosa migliore da usare è un sensore di distanza sonar o laser, in tal modo avresti una lettura spaccata a pochi cm di errore
Guida per principianti http://playground.arduino.cc/Italiano/newbie
Unoffical Telegram group https://t.me/genuino

MM81

Ciao, Lesto. Grazie per la rapida risposta. Rispondo a punti:


Quote
sì, direi che migliorare il barometrico di più non puoi, se non adottanto certi trucchi tipo evitare che sia a contatto diretto con l'esterno; lo metti in una scatola stagna e poi ci fai un buco in un luogo dove non arriva aria dai motori/spostamenti, che altera la pressione.
Questi sono accorgimenti "alla buona" che servono per evitare di sporcare le letture con l'effetto di scie delle eliche, ma dubio fortemente che possano migliorare la qualità dei dati e che adotterei alla fine. Ma per adesso, sarebbe meglio non affidasi a stratagemmi del genere. Sei d'accordo?

Quote
l'accelerometro da solo non basta, devi sapere anche la tua inclinazione, e da quì puoi ricavare la tua accelerazione, e poi integrare per ottenere la velocità... ottieni in risultato molto grezzo, ma è sempre qualcosa in più.
Si è vero, per estrapolare il vero valore di g, devo sapere la sua proiezione sul piano. Quindi un valore per il modulo di g ed un angolo per proettarlo sulla verticale.
Il dead reckoning è una cosa che funziona solo su intervalli piccolissimi. Dopo un poco l'errore esplode e prevale sulla misura. SI vede infatti una vera e propria deriva (verso il basso o l'alto). Integrare da acc a spostamento implica un qadrato, da cui la crescita così rapida dell'errore.


Quote
Potresti usare un GPS, che restituisce anche l'altezza, anche quì l'errore è di parecchi cm (se vuoi mantenere una posizione relativa) ma il tutto entra nel calderone: più sensori "misceli" assieme e più gli errori si mediano.
Vorrei evitare di montare il GPS shield che ho, sul quad. Se mi schianto addio 80 euri. Mentre il sensore di pressione sono solo 15. E poi il GPS ha una accuratezza verticale ridicola (VDOP - vertical dilution of precision- è nell'ordine dei metri se non più....), quindi scarterei anche per un motivo tecnico, oltre che di rischio di perdita dell'attrezzatura (il 10 per cento del mio stipendio mensile).

Quote
La cosa migliore da usare è un sensore di distanza sonar o laser, in tal modo avresti una lettura spaccata a pochi cm di errore.
Anche qui, come sopra, devi sapere l'inclinazione della piattaforma da cui parte l'impulso sonoro (escludo i sensori laser che costano pià del quad...), perchè quando ti sposti in avanti o di lato, il sensore "guarda storto", quindi no è la "vera" distanza verticale tra quad e suolo. Quindi si torna al problema dell'accelerometro. E poi, c'è un problema di latenza con i tempi di ritorno del segnale acustico inviato (ping). Se provi a collegare un sensore ultra-suoni e misurare la distanza tra sensore e mano (piccola), il tempo che intercorre tra misura e risultato su temrinale è MOLTO minore del tempo che intercorre per misurare la distanza dall'arduino al soffitto (molto grande, di circa 10 volte?). Questa latenza renderebbe tutto più instabile e poco fattibile. E poi, altro contro, il sensore ad ultrasuoni è sensibilissimo al vento ed ha una portata di massimo tre metri (quando guarda giù verticalmente, se inclini il piano di proiezione, la distanza verticale tra quad e piano campagna diminuisce di molto). E renderebbe l'altitude hold inutilizzabile sopra i 2 mentri di quota relativa.

Quindi, ammesso che la cosa sia fattibile tecnicamente: si potrebbe prendere il valore dal cervello di bordo per misurare il modulo di g, e poi, con un accelerometro extra montato su arduino, tracciare l'inclinazione ed evincere così la proiezione di g sull'asse z.

Scusa, oggi proprio non riesco ad essere sintetico.

Grazie per i tuoi feedback
ciao

lestofante

Questi sono accorgimenti "alla buona" che servono per evitare di sporcare le letture con l'effetto di scie delle eliche, ma dubio fortemente che possano migliorare la qualità dei dati e che adotterei alla fine. Ma per adesso, sarebbe meglio non affidasi a stratagemmi del genere. Sei d'accordo?
no, si tratta di corretto montaggio del sensore. Ricorda che il barometro si comporta come tubo di pivot nella direzione in cui c'è il buco.

Si è vero, per estrapolare il vero valore di g, devo sapere la sua proiezione sul piano. Quindi un valore per il modulo di g ed un angolo per proettarlo sulla verticale.
Il dead reckoning è una cosa che funziona solo su intervalli piccolissimi. Dopo un poco l'errore esplode e prevale sulla misura. SI vede infatti una vera e propria deriva (verso il basso o l'alto). Integrare da acc a spostamento implica un qadrato, da cui la crescita così rapida dell'errore.
Chissene dell'errore accumulato, se hai un riferimento assoluto (barometro) e vedi che queso metodo aiuta a smussare. Ad esempio stimi la correzzione con il barometro, poi stimi la velocità con la IMU, e vedi se i due valori tornano; se no con un PI(D) mescoli i due valori

Vorrei evitare di montare il GPS shield che ho, sul quad. Se mi schianto addio 80 euri. Mentre il sensore di pressione sono solo 15. E poi il GPS ha una accuratezza verticale ridicola (VDOP - vertical dilution of precision- è nell'ordine dei metri se non più....), quindi scarterei anche per un motivo tecnico, oltre che di rischio di perdita dell'attrezzatura (il 10 per cento del mio stipendio mensile).
attento a non cofondere l'accuratezza ASSOLUTA (cioè rispetto alle coordinate GPS standard) e RELATIVA (ovvero rispetto a quello che il tuo GPS crede essere la coordinata iniziale), che io sappia la relativa è molto migliore. Poi di moduli GPS cerca il neoBlack che per 15-20€ ti porti a casa un buon ricevitore.

Anche qui, come sopra, devi sapere l'inclinazione della piattaforma da cui parte l'impulso sonoro (escludo i sensori laser che costano pià del quad...), perchè quando ti sposti in avanti o di lato, il sensore "guarda storto", quindi no è la "vera" distanza verticale tra quad e suolo. Quindi si torna al problema dell'accelerometro. E poi, c'è un problema di latenza con i tempi di ritorno del segnale acustico inviato (ping). Se provi a collegare un sensore ultra-suoni e misurare la distanza tra sensore e mano (piccola), il tempo che intercorre tra misura e risultato su temrinale è MOLTO minore del tempo che intercorre per misurare la distanza dall'arduino al soffitto (molto grande, di circa 10 volte?). Questa latenza renderebbe tutto più instabile e poco fattibile. E poi, altro contro, il sensore ad ultrasuoni è sensibilissimo al vento ed ha una portata di massimo tre metri (quando guarda giù verticalmente, se inclini il piano di proiezione, la distanza verticale tra quad e piano campagna diminuisce di molto). E renderebbe l'altitude hold inutilizzabile sopra i 2 mentri di quota relativa.
stai sovrastimando i prezzi di un sensore laser, circa 80-100€ mi pare, e sottostimando la velocità del sonar: certo è vero che il tempo di rispota è variabile, ma se tu interpreti il dato correttamente questo problema non dovrebbe sussistere. Poi certo dipende da come hai programmato il tutto, ma cmq se voli a 10m da terra il tempo di risposta è cmq 1/30 di secondo, e dubito che trovi sensori sonar economici che hanno un range simile. E non volare sui panni, che il sonar se lo mangiano.

Quindi, ammesso che la cosa sia fattibile tecnicamente: si potrebbe prendere il valore dal cervello di bordo per misurare il modulo di g, e poi, con un accelerometro extra montato su arduino, tracciare l'inclinazione ed evincere così la proiezione di g sull'asse z.
perchè accelerometro extra? il FC (Flight Controller) contiene già tutte le informazioni di cui hai bisogno. Non so che FW usi, ma molti hanno la telemetria, e puoi attivare il valore dei sensori; in tal modo sei sicuro di non mettere mano al codice di volo, ma ottieni i dati che ti servono.

Grazie per i tuoi feedback
grazie per la chiaccherata!
Guida per principianti http://playground.arduino.cc/Italiano/newbie
Unoffical Telegram group https://t.me/genuino

MM81

Molto interessanti gli spunti che proponi! Grazie.


Quote
no, si tratta di corretto montaggio del sensore. Ricorda che il barometro si comporta come tubo di pivot nella direzione in cui c'è il buco.

Chissene dell'errore accumulato, se hai un riferimento assoluto (barometro) e vedi che queso metodo aiuta a smussare. Ad esempio stimi la correzzione con il barometro, poi stimi la velocità con la IMU, e vedi se i due valori tornano; se no con un PI(D) mescoli i due valori
è una cosa che vorrei approfondire, magari potremmo riparlarne. Credo che per realizzare ciò che ho in mente sarebbe la strada da seguire.

Quote
attento a non cofondere l'accuratezza ASSOLUTA (cioè rispetto alle coordinate GPS standard) e RELATIVA (ovvero rispetto a quello che il tuo GPS crede essere la coordinata iniziale), che io sappia la relativa è molto migliore. Poi di moduli GPS cerca il neoBlack che per 15-20€ ti porti a casa un buon ricevitore.
Non so se ho capito bene, ma: parlo proprio di valori assoluti, quindi come tale slegati da ogni zero arbitrario. Mi riferisco a latitudine, longitudine, e altitudine. Due degli output forniti sono: HDOP e VDOP, cioè la accuratezza della stima di posizone in orizzontale (H) e verticale (V). Questi parametri variano con il numero di satelliti agganciati e l'ordine di grandezza e della decina di metri (dimensioni del guscio di probabilità al 95% che racchiude i valori di lat/lon).

Quote
stai sovrastimando i prezzi di un sensore laser, circa 80-100€ mi pare, e sottostimando la velocità del sonar: certo è vero che il tempo di rispota è variabile, ma se tu interpreti il dato correttamente questo problema non dovrebbe sussistere. Poi certo dipende da come hai programmato il tutto, ma cmq se voli a 10m da terra il tempo di risposta è cmq 1/30 di secondo, e dubito che trovi sensori sonar economici che hanno un range simile. E non volare sui panni, che il sonar se lo mangiano.
Non caspico: quali panni? Per ora volo solo in spazi aperti e campi e mi tengo lontano da panni stesi.
Vorrei non aggiungere altro hardware e fare con quello che ho, le mi risorse sono limitate. Il bello di queste cose è arrangiarsi con poco, altrimenti la fatica supera il gusto.

Quote
perchè accelerometro extra? il FC (Flight Controller) contiene già tutte le informazioni di cui hai bisogno. Non so che FW usi, ma molti hanno la telemetria, e puoi attivare il valore dei sensori; in tal modo sei sicuro di non mettere mano al codice di volo, ma ottieni i dati che ti servono.
Ma è vero!Grande! Non avevo proprio considerato la telemetria che rappresenta una comoda porta di ingresso dal retro. IL FW in uso è 1.6, mentre il SF è versione 2.15 (quadricopter dixit). Devo vedere se posso usare la uscita per la telemetria, ora mi informo.


di nuovo grazie per gli spunti interessanti. Ciao alla prossima.
Marco

lestofante

Molto interessanti gli spunti che proponi! Grazie.

è una cosa che vorrei approfondire, magari potremmo riparlarne. Credo che per realizzare ciò che ho in mente sarebbe la strada da seguire.
si, qualsiasi strada scegli è sempre meglio nnon affidarsi mai ad un sensore solo.

Non so se ho capito bene, ma: parlo proprio di valori assoluti, quindi come tale slegati da ogni zero arbitrario. Mi riferisco a latitudine, longitudine, e altitudine. Due degli output forniti sono: HDOP e VDOP, cioè la accuratezza della stima di posizone in orizzontale (H) e verticale (V). Questi parametri variano con il numero di satelliti agganciati e l'ordine di grandezza e della decina di metri (dimensioni del guscio di probabilità al 95% che racchiude i valori di lat/lon).
quello è errore ASSOLUTO, ovvero rispetto alle coordinate GPS "standard"; la LAT e LON (ma semplifichiamo pure in X Y, tanto per quello che ci concerne la sfericità del mondo non ci dovrebbe dare problemi, poi in realtà tu vuoi lavorare solo sulla Z) possono avere un errore ASSOLUTO di uan decina di metri, ovvero se tu sei alla coordinata 0,0 il sensore ti dice magari 2,3 PERÒ questo errore assoluto resta costante durante il volo; a te interessa restare nella posizione GPS attuale, non ti importa se poi questa corrisponda veramente ad 0,0 o 2,3. L'errore relativo dovrebbe essere più basso, ma non so quantificarlo. Forse astro ha una risposta migliore

Non caspico: quali panni? Per ora volo solo in spazi aperti e campi e mi tengo lontano da panni stesi.
era per avvisarti che esistono superfici che danno fastidio agli ultrasuoni.

IL FW in uso è 1.6, mentre il SF è versione 2.15 (quadricopter dixit). Devo vedere se posso usare la uscita per la telemetria, ora mi informo.
1.6 di che cosa?
Guida per principianti http://playground.arduino.cc/Italiano/newbie
Unoffical Telegram group https://t.me/genuino

astrobeed

Forse astro ha una risposta migliore
Come al solito si sta facendo confusione tra precisione e risoluzione, un buon gps con almeno sette satelliti agganciati, EGNOS/WAAS disponibile, correttamente distribuiti, offre una precisione non maggiore di 2 metri, però la risoluzione è circa 10 cm, ovvero il drone può trovarsi ovunque, inteso come coordinate reali, dentro un cerchio con raggio 2 metri, però è in grado di capire se si è spostato di 10 cm da dove si trovava.
Per uso UAV i gps migliori in assoluto sono quelli di Mteck o di Ublox, in particolare il recente Ublox Neo M8, costa solo 35 Euro.
Rimane il fatto che con le piccole mcu 8 bit più di tanto non si può fare, troppo scarsa la potenza di calcolo e la ram, senza passare ad una f.c. dotata di processore a 32 bit l'attitude hold, funzionante sul serio, è una utopia.
Le f.c. 8 bit vanno bene per divertirsi, p.e. su i racer 250 dove serve un mezzo molto reattivo ed è il pilota a decidere cosa fare, ovviamente serve esperienza di pilotaggio, quando si va sugli automatismi di alto livello gli otto bit fanno vedere tutti i loro limiti.
Scientia potentia est

lestofante

Quote
tra precisione e risoluzione
erhmmm  :smiley-red:  :smiley-red:  :smiley-red:

lui deve fare solo hold di altitudine, quindi direi che ci siamo
Guida per principianti http://playground.arduino.cc/Italiano/newbie
Unoffical Telegram group https://t.me/genuino

astrobeed

lui deve fare solo hold di altitudine, quindi direi che ci siamo
Ci siamo se usi come minimo una CC3D o la Naze32, la vedo molto dura con un Arduino, un pelino meglio con una scheda tipo Crius dove almeno hai un Mega2560 a disposizione con tutta la relativa ram, la potenza di calcolo comunque rimane la stessa del 328.
Scientia potentia est

lestofante

non vedo come mai, il GPS ritorna già un avlore fatto e confezionato, lo stesso un sensore di istanza, poi "grezzamente" puoi agure direttamente sul throttle (se poi sei inclinato di 20°-45° **zzzi tua) oppure puoi sviluppare qualcosa di più complesso
Guida per principianti http://playground.arduino.cc/Italiano/newbie
Unoffical Telegram group https://t.me/genuino

astrobeed

non vedo come mai
Molto semplice, su un 8 bit non hai i double, assolutamente indispensabili se vuoi lavorare di fino col gps, devi sempre fare i conti col fatto che devi comunque calcolare il vettore dello spostamento in base a latitudine e longitudine, calcolo abbastanza complesso anche nella sua forma semplificata al massimo, se lo fai senza double hai un risoluzione di svariate decine di metri invece che di centimetri.
Pure tu hai "giocato" con MultiWii e similari per 8 bit e sai benissimo quali sono i limiti :)

Scientia potentia est

Go Up