[Multicotteri] Elettronica : IMU, MCU, Sensori ed algoritmi di controllo

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

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

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?

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.

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).

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

MM81:
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.

MM81:
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

MM81:
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.

MM81:
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.

MM81:
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.

MM81:
Grazie per i tuoi feedback

grazie per la chiaccherata!

Molto interessanti gli spunti che proponi! Grazie.

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.

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).

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.

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

MM81:
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.

MM81:
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

MM81:
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.

MM81:
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?

lesto:
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.

tra precisione e risoluzione

erhmmm :blush: :blush: :blush:

lui deve fare solo hold di altitudine, quindi direi che ci siamo

lesto:
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.

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

lesto:
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 :slight_smile:

1.6 di che cosa?

KK2.1 flight controller
Versione FIRMWARE: 1.6,
Versione SOFTWARE 2.15

Lesto, non ho proprio idea se abbia senso o no quello che ho scritto; ho solo copiato le specifiche dalo schermo quando lo accendo e per un attimo compaiono queste scritte. Non saprei scendere nel dettaglio più di così.
Lavoro permettendo provo ad iniziare quella cosa sul mescolamento dei due sensori che avevi accennato, poi se ne riparla, magari il week end, durante la settimana ho pochissimo tempo. ciao.

si appunto, ma se lui deve fare solo l'hode della ALTITUDINE e non della posizione (e l'altitudine vene già restituita in metri sul livello del mare, se non erro)

Venerdì 17 Enac ha rilasciato la versione 2 del regolamento per gli APR, tralasciando le varie regole per le applicazioni professionali, a partire dall'obbligo delle licenza di volo per i piloti rilasciata da ENAC, per quanto riguarda il settore ludico, che è quello che ci interessa, c'è una importante novità che sta preoccupando molti in attesa di chiarimenti da parte di Enac.
Nella sezione VII, articolo 35, del regolamento, la parte che riguarda gli aeromodelli, il paragrafo 6 cita testualmente:

Su un aeromodello utilizzato in un luogo aperto al pubblico non possono essere istallati
dispositivi o strumenti che ne configurino l’uso in operazioni specializzate,

Questo punto è abbastanza sibillino in quanto non viene detto cosa sono questi strumenti, in teoria anche la sola presenza di una GoPro per fare delle riprese può essere considerata sufficiente per qualificare il mezzo come idoneo per le operazioni specializzate.
Probabilmente l'idea del legislatore, in attesa di chiarimenti, è evitare che il solito "furbo" beccato in flagrante attività professionale senza essere in regola dichiari che si tratta di un volo amatoriale per non incorrere nelle pesanti sanzioni.

Per quanto riguarda il discorso FPV amatoriale è già stato chiarito che è sufficiente tenere il drone nell'area di volo prevista, raggio 200 metri altezza 70 metri oppure raggio 300 metri altezza 150 metri per chi è in possesso dell'attestato di pilota aeromodelli, con possibilità di tenere costantemente in contatto visivo diretto il drone.
Più semplicemente, si può volare in fpv con il monitor o il visore, però deve essere sempre possibile pilotare a vista il modello in qualunque momento.
In alternativa il doppio comando, tramite due radio e l'apposito cavo, dove un pilota usa il visore/monitor e il secondo pilota può prendere in qualunque momento il controllo del drone con la sua radio, che poi è la stessa cosa che si fa per la scuola di pilotaggio con i principianti.

Arrivata da parte di ENAC il chiarimento sul articolo 35 che riguarda gli aeromodelli.

In un’intervista al Corriere della Sera, l’ingegner Cardi di Enac interviene sula questione smorzando le polemiche: “ENAC non intende certo limitare le riprese ad uso personale”, il comma è stato inserito per smascherare gli abusivi che fanno operazioni specializzate mascherandole da attività aeromodellistica: l’uso di sensori a infrarossi, radar, sonar invece fa presumere che il drone sia in realtà un SAPR, e quindi all'”aeromodellista” rimane l’onere di dimostrare che invece stava solo giocando. certo, nessuno proibisce di giocare con una termocamera, ma bisognerà essere molto convincenti.

In pratica nessun problema per l'uso della classica GoPro, o altro tipo di camera, su i droni ad uso aeromodellistico, rimangono validi tutti i vari limiti imposti per questo genere di attività e il divieto assoluto di volare sulle persone, ma questo è sempre esistito e chi ha un minimo di esperienza aeromodellistica lo sa bene.
Interessante anche il chiarimento su i droni con peso non maggiore di 300 grammi utilizzabili senza patentino/licenza anche a livello professionale, sono considerati innocui, il che permette ai ragazzini, ma anche agli adulti, di giocare con i droni di piccole dimensioni in un parco, ma anche in una piazza, senza rischiare il sequestro e pesanti multe, vale sempre il divieto di sorvolo sulle persone.

In collegamento a questo 3d .

Buona sera a tutti.

Come ho già detto nell'altro 3d sono nuovo del campo e mi appresto a costruire un u300 per imparare prima di tutto.

Avevo intenzione di montare sul telaio una freeIMU prima di tutto perchè consigliata poi perchè mi sembra un progetto mantenuto bene con frequenti aggiornamenti, il tutto accoppiato ad una arduino mini pro da 16 mhz che ho già.

Come controller avevo intenzione di prendere il tunigy 9x in quanto un domani vorrei riutilizzarlo per altro e insieme c'è anche il controller.

Ho bisogno di due informazioni se a voi risultano: se sul telecomando risulta lo stato della batteria rimanente e se posso utilizzare un canale del trasmettitore per trasmettere video. L'idea era di inviare il video (magari con questa peso permettendo visto che pesa 13g(solo camera) +85 di telaio + 98 di batteria + 72 motori =268g manca però arduino imu ed esc però penso di starci sotto i 300g) sul cellulare android e se quindi devo accoppiare un'altro trasmettitore o no e se sapete quanto pesa.

Grazie

G.

gorthan:
In collegamento a questo 3d .

Sarò molto sintetico, nessuno usa più Arduino per far volare un multi, primo perché pone troppi limiti per via della limitata capacità di calcolo, secondo perché ci sono ottime f.c. con processore a 32 bit, complete di imu, che costano meno del solo Arduino, p.e. la CC3D.

astrobeed:
Sarò molto sintetico, nessuno usa più Arduino per far volare un multi, primo perché pone troppi limiti per via della limitata capacità di calcolo, secondo perché ci sono ottime f.c. con processore a 32 bit, complete di imu, che costano meno del solo Arduino, p.e. la CC3D.

Perfetto...come cade un mito.. :frowning: Ok approfondirò.

Grazie

Astro

Sto lavorando su un convertitore di protocollo tra Grapuner SUMD e Futuba SBUS, questo perché tutte le f.c. in ingresso accettano l'SBUS mentre nessuna, o quasi, accetta il SUMD.
Il motivo per cui sto realizzando questo convertitore è che ormai sono passato a radio Graupner Hott sulle cui riceventi è disponibile sia il PPMSUM che il SUMD col vantaggio che nel secondo caso è possibile ottenere tutti i canali della trasmittente anche con le economiche riceventi a sei canali, inoltre la precisione e la risoluzione offerta dal SUMD è maggiore.
Il protocollo SUMD è abbastanza simile a quello SBUS, tutti e due vanno a 115200 8,n,1 però l'SBUS usa una logica invertita, idle a 0, rispetto a quella standard delle UART, tutti e due usano un header seguito da una serie di byte che contengono il valore dei vari canali, risoluzione a 11 bit per l'SBUS, 12 bit per SUMD, il pacchetto dati SBUS ha una lunghezza fissa di 25 byte, il pacchetto dati SUMD ha una lunghezza variabile in base al numero di canali trasmessi, quanti sono è specificato nel header.
Sto facendo i primi test con una MEGA 2560 perché mi servono due seriali hardware, impossibile usare le seriali software a 115200 bps con un traffico elevato come nel caso di questi bus, una volta messo a punto il software lo trasporto sul ATtiny 841, ha le due seriali hardware e un case di solo 14 pin in modo da poter realizzare il definitivo su un piccolo pcb che farà da bridge tra la ricevente HoTT e la f.c.
Per il momento ho pronta la parte software che acquisisce i valori dei canali dal protocollo SUMD, devo scrivere la parte per l'out in SBUS.

Dopo tanti anni, aggiungo questo post solo per segnalare un'applicazione di controllo e stabilizzazione del volo realizzata con una scheda Teensy ...

... chi fosse interessato può leggere il tutto QUI su GitHub.

Guglielmo

1 Like