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

Madwriter:
mmm intendete la discovery?ci stavo facendo nju pensierino mentre facevo al lista della spesa purtroppo ora non ho tempo di costruire un quad ho altri progetti in cantiere però mi stavo documentando epr il futuro :slight_smile:

Di Discovery ne esistono tre, inclusa quella in arrivo a fine mese, quale prendere dipende da cosa devi fare, il costo più o meno è identico per tutte, si va dai quasi 15 Euro per quella con il processore Cortex M4, il più potente della serie STM32, ai 11 Euro per quella con il processore più piccolo e senza nessun sensore.
La cosa stupenda di queste board è che includono un secondo STM32 che fa da programmatore e debugger hardware, ST-LINK V2, utilizzabile, spostando dei jumper, per programmare/debuggare altre board basate su STM32, in praticano ti regalano un hardware che se acquistato a parte costa quasi 30 Euro :slight_smile:

astrobeed:

Hal90001:
Ecco allora e' quello che cerco. Tuttavia per configurare i vari giroscopi e tutti gli altri sensori esistono librerie che facilitano questo compito?

Se usi Arduino ti conviene utilizzare un software già pronto e sicuramente funzionante,
Praticamente tutti quelli che scrivono in questo topic, e negli altri due dedicati ai quadricotteri, in particolare il megatopic, ora chiuso, di oltre 100 pagine, hanno iniziato utilizzando MultiWii come software, pure io per i primi test mi sono affidato a questo programma che sebbene carente sotto vari punti di vista è funzionante e affidabile, credo sia il più utilizzato in assoluto da chi realizza un quadri basato su Arduino.
In base al software che decidi di utilizzare verifichi i sensori supportati e acquisti la corretta imu, diversamente dovresti fare un enorme lavoro di adattamento, e quasi sicuramente mettere mano anche alla parte matematica che non è certo semplice da fare.
In pratica se usi MultiWii e una IMU delle supportate colleghi tutto come da istruzioni, carichi il software, configuri i pochi parametri operativi, più che altro per adattare i segnali della radio con quelli attesi da MultiWii, accendi la radio, attacchi la batteria e cominci a volare subito.
Attenzione che pilotare un quadri non è una cosa semplicissima da fare, sopratutto se non hai alcuna esperienza di volo rc, consigliato fare un pochino di pratica con un simulatore su pc.
Sulla radio non fare economia, è la parte più importante, sopratutto se vuoi fare fpv.

Ti ringrazio per la pazienza, va bene allora utilizzerò multiwii con imu. Sai dove la potrei acquistare in Europa quindi senza pagare spese doganali?

Hal90001:
Ti ringrazio per la pazienza, va bene allora utilizzerò multiwii con imu. Sai dove la potrei acquistare in Europa quindi senza pagare spese doganali?

Evita di quotare tutto il testo, solo le parti a cui rispondi direttamente.
In Europa c'è la francese Drotek che vende IMU adatte a MultiWii, questa a sei d.o.f. per il tuo scopo è perfetta, oppure prendi subito questa a 10 d.o.f, ha anche il magnetometro, il barometro altimetrico e il convertitore di livelli logici (LLC), così hai la dotazione completa di sensori e nessun problema di connessione con Arduino, tutte e due sono supportate da MultiWii.

astrobeed:
In Europa c'è la francese Drotek che vende IMU adatte a MultiWii, questa a sei d.o.f. per il tuo scopo è perfetta, oppure prendi subito questa a 10 d.o.f, ha anche il magnetometro, il barometro altimetrico e il convertitore di livelli logici (LLC), così hai la dotazione completa di sensori e nessun problema di connessione con Arduino, tutte e due sono supportate da MultiWii.

Scusami, sono un neofita dei forum :frowning: perfetto, prenderò quelle. Quindi la procedura se non sbaglio e':

  1. prendere imu
  2. caricare multiwii su arduino
  3. programmare l'imu
    E poi costruire fisicamente il quadricottero giusto? Anche se ho già un'idea. In ogni modo sia multiwii che quella imu sono compatibili con arduino uno vero?

non devi programmare l'imu, ma collegarla all'arduino.
La imu immaginala come una scatola chiusa che butta fuori dei dati, l'arduino li legge e li elabora, e di socnseguenza varia il tuo input della ricevente per mantrenere la stabilizzazione.

quindi:
1.colleghi la imu all'arduino
2.programmi l'arduino
3.monti l'arduino sul quad
4.setti i parametri del programma sull'arduino per rendere stabile la tua cofigurazione (il famoso pid)

il tutto cercando di non farti male, anche se piccolini questi motori e le eliche sono tranquillamente in grado di far molto male

lesto:
anche se piccolini questi motori e le eliche sono tranquillamente in grado di far molto male

Ottima osservazione, i motori BLDC usati su i quadri sono da un centinaio di Watt, le eliche sono delle lame rotanti, se ti arriva addosso, ma anche infilare la mano nel disco dell'elica, può causare gravi ferite.

lesto:
il tutto cercando di non farti male, anche se piccolini questi motori e le eliche sono tranquillamente in grado di far molto male

Si me l'ero immaginato, guardo di fare attenzione. Vi tengo aggiornati nei prossimi giorni. Grazie per ora mi avete chiarito molto le idee.

astrobeed:
configuri i pochi parametri operativi, più che altro per adattare i segnali della radio con quelli attesi da MultiWii

a proposito, che valori si aspetta?
io nell'attesa di convincermi ad affrontare l'impresa sto facendo la parte di trasmissione che consiste in: joystick->python->xbee
Invio una stringa del tipo ax1by1cx1dy1 al quale si aggiunge altro se premo un bottone della pulsantiera. I valori variano da 0 a 255 perora, se potreste darmi qualche suggerimento.. :slight_smile:

sciorty:
io nell'attesa di convincermi ad affrontare l'impresa sto facendo la parte di trasmissione che consiste in: joystick->python->xbee

Lascia perdere, con MultiWii devi usare un vero radiocomando, pure decente, se non vuoi schiantare il quadri in meno di 0.1s :smiley:

Ma per motivi gestionali del software o perchè la velocità di trasmissione sarebbe bassa per un quadri?

sciorty:
Ma per motivi gestionali del software o perchè la velocità di trasmissione sarebbe bassa per un quadri?

Perché sei tu a dover pilotare il quadri ed è già difficile farlo con un vero radiocomando, figuriamoci con un "accrocchio" (senza offesa) di un qualche tipo.
MultiWii non possiede capacità di volo autonomo inoltre si aspetta in ingresso dei segnali PPM provenienti da un radiocomando.

pensa alla LAG del sistema;

  1. lettura del joystic da parte PC. il kernel non è real-time, quindi già potresti avere millisecondi di lag, senza contare che se parte qualcosa di CPU hungry la cosa peggiora assai. in oltre la seriale è lentaaaaa (se usi il joystic seriale
  2. interpretazione dei valori ed invio su xbee. l'interpretazione serve per comprimere i dati il più possibile: i cicli macchina sono molto più "economici" in termini di tempo dell'invio di byte su network (anche via cavo eh), ed in oltre, come sopra, la seriale è lentaaaaaaa
  3. tempi di gestione dello stack xbee: quì mi aspetto LAG nell'ordine di massimi qualche centinaio di microsecondi, quindi nulla di problematico.. ma non ho mai fatto test veritieri.
  4. trasformazione input xbee in PPM (se non vuoi cambiare il codice multiwii a mano), altri 2ms almeno di LAG

Ma esiste un semplice test per verificare il tutto: su arduino fai uno sketch che invia il valore di micros via xbee, e uno sketch al pc che legge il dato e lo ritrasmette ad arduino, che calcola la metà della differenza e te la stampa, avrai una mezza idea dei trempi che ci sono di mezzo.
(edit: il test al contrario evita di farlo se non sai cosa stai facendo: datetime - How precise is the internal clock of a modern PC? - Stack Overflow)

per farti capire meglio: la seriale a 9600 baud vuol dire 960byte/s, ovvero circa 1.1milisecondi a byte. poi è anche vero che i tempi di reazione di una persona sono sui 40ms, ma credo che per dare una senzazione di fluidità devi almeno stare sui 20ms..

poi astro ne sa molto di più di me, magari ci sono altri motivi

Interessante discussione, mi chiedevo pero perche aver fatto esempio a 9600?
Gia con 115200 siamo su tempi 10 volte inferiori, e magari si puo anche salire di piu, ma capisco che e' solo una delle variabili.
Premere un unico comando, tipo Vai a Destra, che tipo di stringa viene trasmessa ?

Testato:
Gia con 115200 siamo su tempi 10 volte inferiori, e magari si puo anche salire di piu, ma capisco che e' solo una delle variabili.
Premere un unico comando, tipo Vai a Destra, che tipo di stringa viene trasmessa ?

Il lag è solo uno dei problemi, tra parentesi i moduli Xbee introducono di loro dei lag anche di molti ms, in tutti i casi un normale radiocomando RC lavora a 50 Hz, ovvero i comandi vengono aggiornati ogni 20 ms, a meno di non utilizzare un sistema di trasmissione a pochi bps è impossibile arrivare ad un lag maggiore.
Come vengono codificati i vari comandi, per una trasmissione seriale, dipende dal protocollo che utilizzi, tutti i radiocomandi RC moderni lavorano a 2.4 GHz e trasmettono i dati in seriale con un protocollo proprietario, per alcune marche è noto, a differenza dei radiocomandi più anziani, ancora in circolazione, che inviano direttamente il PPM sotto forma di modulazione FM, o in AM per quelli più vecchi (ora illegali in Italia).
Il vero problema è l'impossibilità di guidare un quadri con un normale Joystick per pc, o peggio con i tasti/mouse, provate con un qualunque simulatore per rendervene conto, questo a meno che il quadri, o altro tipo di velivolo, non sia in grado di volo totalmente autonomo, cosa che non rientra nelle possibilità dei più diffusi software/hardware utilizzati su i quadri.

thanks
karma added :slight_smile:

Testato:
Interessante discussione, mi chiedevo pero perche aver fatto esempio a 9600?

perchè è l'impostazione di default sui moduli xbee. il massimo via UART è 57600 , ma forse via API raggiungi cvelocità superiori, visto il massimo rate del modulo è 250Kbit/s. In oltre il joystick non so a quanti baud parla, credo che anche se USB non sfutta tutta la banda ma dipende dalla qualità del micro e dei componenti che gestisce il tutto

Il vero problema è l'impossibilità di guidare un quadri con un normale Joystick per pc, o peggio con i tasti/mouse, provate con un qualunque simulatore per rendervene conto, questo a meno che il quadri, o altro tipo di velivolo, non sia in grado di volo totalmente autonomo, cosa che non rientra nelle possibilità dei più diffusi software/hardware utilizzati su i quadri.

uhm credo di esserci arrivato, con un joystic hai 2 assi (destra/sinistra e avanti/indietro), mentre a noi ne servono almeno 4 (anche su/giù, ruota a destra/ruota a sinistra). volendo si potrebbe aggirare il problema usando un ping/sonar per l'altezza(mi pare che aeroquad abbia almeno un modello supportato) o usando un potenziometro lineare, e un lock della rotazione ma quindi obbligo di magnetometro. Oopure usando un secondo joistic, hai 4 canali, un pò ingombrante ma potrebbe funzionare

lesto:
perchè è l'impostazione di default sui moduli xbee. il massimo via UART è 57600 ,

La massima velocità UART supportata è 115200, però la banda reale massima è circa 80 kbps, gli Xbee tra loro comunicano a 250 kpbs e in questo modo non c'è un reale overhead sulla banda utente, la maggiore velocità consente di far passare i byte aggiuntivi per il protocollo in modo trasparente rispetto alla banda utilizzata dall''UART.

uhm credo di esserci arrivato, con un joystic hai 2 assi (destra/sinistra e avanti/indietro), mentre a noi ne servono almeno 4 (anche su/giù, ruota a destra/ruota a sinistra). volendo si potrebbe aggirare il problema usando un ping/sonar per l'altezza(mi pare che aeroquad abbia almeno un modello supportato)

Il vero problema è che per pilotare un modello volante servono due mani, esattamente come su un vero velivolo, una controlla il gas e il timone, l'altra gli alettoni e il timone di profondità, tradotto per un quadri, o un ely, con una mano controlli la spinta verticale e la rotazione su se stesso, con l'altra il roll e il pitch, esistono anche altri modi di configurare la ripartizione dei comandi sulle due mani, è una cosa molto soggettiva e dipende da come ci si trova meglio.
Anche i Joystick devono essere di qualità superiore rispetto quelli utilizzati su un pc, a meno che non disponi di prodotti specifici per simulatori di volo che offrono una buona precisione/risoluzione, però costano cari, la più scrausa delle radio RC adatta ad un quadri possiede Joystick migliori di quelli medi/standard utilizzati su un pc.
In teoria nulla vieta di realizzare una console di comando utilizzando due Joystick per radio RC collegati ad un micro che provvede ad inviare i dati tramite Xbee, però viene a costare di più di un vero radiocomando RC che oltretutto offre maggiori funzionalità ed è di sicuro funzionamento.
Tutte queste considerazioni si applicano solo a modelli volanti non autonomi, un quadri che può volare da solo, il che include anche l'atterraggio e il decollo, non richiede particolari accorgimenti per il controllo remoto e quasi nessuna abilità di pilotaggio a differenza di un normale quadri RC che tocca pure imparare a pilotarlo.

molto esaustivo tnx, +1

Salve a tutti,
sapreste indicarmi come procedere per implementare l'algoritmo di controllo della stabilità del mio quadricottero?
Il primo goal che vorrei raggiungere è quello della stabilità in volo statico, ossia che resti fermo in aria, senza oscillazioni o rollii.
Ovviamente a bordo ho un gyro-acc-magn con 3 gradi di libertà
ringrazio anticipatamente

è esattamente quello che sto facendo ora, devi leggere i sonsori e fare una sensor fusion. io uso una DCM e un filtro passa via software, attualmente "spara" fuori un quaternione che poi disegno a PC. Stabile come una roccia, (non il quad, per ora uso i sensori da soli)

oggi pomeriggio ci lavoriamo ancora sopra, e magari anche il test di sollevamento.

ti posto il codice, è ben lungi dall'essere perfetto o "leggibile" (ci sono stati vari problemi nel porting java->c), ma sarà ben contento astro che è in puro stile C :slight_smile:

ITG3200ADXL345.ino (8.03 KB)

imu.h (9.64 KB)