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

È un po’ complicato da capire perché sono solo al terzo anno di un istituto tecnico elettronico-informatico, ma ho capito il concetto il linea generale.
Potresti reindirizzarmi alla guida che hai fatto, in modo da capire dove e come aggiungere le righe di codice?

mi spiace, niente guida, solo codice: https://github.com/lestofante/arduinoSketch/tree/master/ClassPPM

lesto: mi spiace, niente guida, solo codice: https://github.com/lestofante/arduinoSketch/tree/master/ClassPPM

Scusami se sono insistente, devo aggiungerli allo sketch di multiwii che poi carico su Arduino?

nono, il multiwii ha già qualcosa di simile dentro di sè, e poi io lavoro a basso livello sui registri, quindi sicuramente il codice "cozza" con il multiwii e tutto si schianta per terra. Pensavo che volessi usare un arduino separato per fare le tue cose, cosa che ti consiglio fortemente, da quello che leggo non sei in grado di mettere mano ad un codice che controlla qualcosa di così potenzialmente pericoloso; se invece fai le tue cose su un tuoo arduino o simili, sei tranquillo che il multiwii funziona come al solito, e se il tuo codice si blocca o ha un errore poco male.

lesto: quindi sicuramente il codice "cozza" con il multiwii e tutto si schianta per terra.

Sicuramente si, inoltre le versioni più recenti di Multiwii gestiscono fino a 8 canali radio, quattro sono per i movimenti, uno per i modi di volo, i rimanenti tre per il movimento di un eventuale gimbal (fino a 3 assi) e/o il controllo delle luci. Però sulla UNO, o board similare è possibile collegare solo sei canali radio, nel caso di un quadri, perché i pin sono finiti, solo usando il ppmsum è possibile usare tutti gli otto canali sulla UNO. Rimane comunque la questione che MultiWii è rimasto quello che era quando è uscito, ovvero un software poco ottimizzato con grossi limiti. Tutti i software alternativi sono decisamente migliori di MultiWii, tutti sono passati come minimo al Atmega2560 e pure questo ormai è deprecato, con 25 Euro si compra una CC3D, basata su STM32, che è decisamente meglio di un Arduino UNO o Mega 2560, ci si può caricare sopra diversi software 32 bit. Il top rimangono sempre le FC di DJI, stanno arrivando dei cloni low cost però non so quanto siano affidabili, quelle di 3D Robotics e di Virtualrobotix, certo costicchiano però non c'è paragone in quanto a prestazioni e affidabilità rispetto ad un Arduino con MultiWii- Domani posto qualche foto del super esacottero da qualche migliaio di Euro, uso professionale, che ho realizzato per un mio cliente, verrà impiegato per riprendere le balene in mare aperto, inutile dire che a bordo di Arduino non c'è traccia. :) In realtà volevo usare una pro mini per gestire i led delle luci di segnalazione, però visto che volerà sempre in piena luce solare e abbastanza lontano, raggio operativo circa 600 metri, mi hanno detto di lasciar perdere e risparmiare peso :)

Grazie mille, sia Lesto che Astrobeed, per le risposte chiare e precise. Quindi ho capito che con il solo Arduino Uno si può fare veramente poco, se non il minimo indispensabile, ma alla fine per il progetto scolastico a cui sto lavorando va già più che bene. In futuro, nel caso in cui volessi costruire un drone un po' più completo e complesso, avevo visto la Crius come possibile fc, perché non troppo costosa ma anche qualitativamente buona. E' veramente così? avete altre fc da consigliare? p.s. ho visto che le migliori sono le naza, ma chiedo informazioni per fc non troppo costose (per fare esperienza).

Ecco una foto del esa per uso professionale, sono ancora in fase di messa a punto e il cablaggio elettrico è parzialmente provvisorio, ha già fatto due voli di prova comportandosi molto bene. Il telaio è totalmente in carbonio, pesa meno di 400 grammi, la distanza tra i motori è 70 cm, motori Tmotor 2814, ESC da 40A (molto sovradimensionati), eliche 12x3.8 in carbonio, bracci e carrello sono ripiegabili per facilitare il trasporto, la spinta massima esercitata dai sei rotori è quasi 8.5 kg. Come elettonica la f.c. è una Naza v2 col suo GPS, Gimbal DJI Zenmuse H3-3D sul quale è montata una GoPo Hero 4 (versione con risoluzione 4k), per la telemetria DJI OSD MKII, oltre a fornire tutti i dati di volo in sovra impressione video li registra su una flash in modo da poterli analizzare su pc dopo il volo, Tx video 5.8 GHz da 600 mW dotato di antenna cloverleaf. Per la stazione a terra c'è un radiocomando Graupner HOTT MZ18 e un monitor per fpv della Boscam con integrato un ricevitore diversity 5.8 GHz e DVR, registra il video (720p o 1080p) su SD, il segnale video trasmesso a terra è quello fornito dalla GoPro, un classico pal 16:9 a 25 fps. Batteria 4S da 5200 mAh utilizzabile sia singolarmente che doppia, il peso del esa senza batteria è solo 2150 grammi, molto leggero per la sua categoria, i pacchi batteria pesano 504 grammi, con un singolo pacco l'autonomia di volo è circa 15 minuti, con due pacchi si arriva a poco più di 20 minuti, per tutte e due le condizioni c'è almeno un minuto di riserva per l'eventuale atterraggio di emergenza in automatico, lo gestisce la Naza v2. Dato che l'impiego principale di questo drone è in mare sul carrello verranno montati due galleggianti, realizzati in plastica termoformata in modo da essere leggerissimi, con un volume complessivo di circa 5 litri (2.5 litri per lato carrello) in modo da garantire il galleggiamento in caso di ammaraggio forzato.

|500x375

Ishac: In futuro, nel caso in cui volessi costruire un drone un po' più completo e complesso, avevo visto la Crius come possibile fc, perché non troppo costosa ma anche qualitativamente buona.

Il problema della Crius è che la trovi in varie versione di cui la maggior parte sono cineserie, non è semplice capire quali sono quelle buone e quelle schifezza, anche perché il prezzo cambia di pochi Euro. In tutti i casi se decidi di andare avanti e realizzare un quadri, o un esa, di livello superiore lascia perdere Arduino perché ormai tutti i software non lo supportano più, lo sviluppo è fermo da oltre un anno perché sono stati raggiunti i limiti del Mega2560. Ti conviene andare su fc a 32 bit, la più semplice, ed economica visto che costa solo 25 Euro completa di case e cavi, è la CC3D basata su un STM32 @72MHz come micro e un MPU6500 come IMU, è possibile collegare magnetometro e barometro esterni tramite I2C, ovviamente anche il GPS. La Naza Lite costa solo 130 Euro completa del suo GPS, se ti fai due conti alla fine non spendi molto di più rispetto a qualunque altra fc entry level completa di GPS, è ottima, sicuramente tra le migliori fc esistenti, la puoi avere in bundle con i kit di DJI a solo 50 Euro nel caso del quadri e a solo 30 Euro nel caso del esa. La cosa divertente della Naza Lite è che in realtà è una Naza v2 declassata, viene fornita con la PMU senza can bus e il firmware installato è diverso in modo da togliere alcune funzionalità superiori. Però con un piccola "magia" è possibile installare sulla Naza Lite il firmware della Naza v2 facendola diventare di fatto una Naza v2 con tutte le relative funzioni aggiuntive. Acquistando a parte la PMU della v2 (45 Euro) si ha anche il can bus se si vuole collegare alla Naza il Gimbal DJI o altri add on. La modifica da Lite a v2 non richiede in nessun modo la manomissione hardware, è solo software, ed è reversibile in qualunque momento semplicemente attivando il deep reset della Naza (un jumper su due pin all'accensione) che forza l'upload del firmware originale.

astrobeed: ... In realtà volevo usare una pro mini per gestire i led delle luci di segnalazione, però visto che volerà sempre in piena luce solare e abbastanza lontano, raggio operativo circa 600 metri, mi hanno detto di lasciar perdere e risparmiare peso :)

Vergognati, che spreco di risorse ... i led di segnalazione (5630 ad alta efficenza e basso peso), li si gestisce con un 555 in SMD su un PCB da meno di 5 grammi ... :P :D :D :D

Piuttosto, il salvagente glie l'hai messo ? ... si sa mai, in mare ... ;)

EDIT: si, leggo ora che e' previsto il galleggiante ... Aumentera' un po il peso, ma e' una necessita' imprescindibile, lavorando sull'acqua ... gia' sara' meglio che vernici tutta l'elettronica con 3 o 4 mani di plastivel, l'acqua di mare si mangia le piste di rame che e' un (dis) piacere, specie se sottoposte a differenze di tensione ... (magari l'aerogel idrofobo costasse poco, ci si potrebbero fare dei bei lavoretti :P :D)

Etemenanki: Vergognati, che spreco di risorse ... i led di segnalazione (5630 ad alta efficenza e basso peso), li si gestisce con un 555 in SMD su un PCB da meno di 5 grammi ... :P :D :D :D

Io volevo metterci dei WS2812 in modo da poter cambiare il colore a seconda del verso di marcia e fornire varie segnalazione, p.e. batteria quasi scarica.

Piuttosto, il salvagente glie l'hai messo ? ... si sa mai, in mare ... ;)

sono previsti i galleggianti sul carrello, li stanno facendo.

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

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

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.

esponi il problema

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.

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?