BaronPilot - Autostabilizzatore Molto Economico

[danveal]

Beh se le cose con Arduino stanno veramente cosi la cosa e' abbastanza grave. Se poi succede in un multirotore e' impensabile risolvere con il watchdog e resettare in 1 secondo perche tutte le variabili dell'assetto attuale si azzerano e quindi come minimo scende giu come un pero, che comunque e' sempre molto meglio che avere un oggetto impazzito nei cieli con le eliche al massimo.

[BBC25185]

il fatto è che all'arduino non gli piacciono gli sbalzi di tensione...
Praticamente bisogna fornirgli una alimentazione molto pulita per evitare i blocchi... (io, nel sottomarino, ho rimosso la batteria supplementare e inserito un alimentatore da 5 A per alimentare RX, servi e arduino... non ho spazio per fare altre alimentazioni... inoltre ho inserito il watchdog...)

Comunque sia, con il bootloader modificato, l'arduino si riavvia nel giro di meno di un secondo... (cioè, riavvia l'esecuzione dello sketch nel giro di un secondo... evita tutto il tempo di riavvio classico se non è la prima volta dalla sua alimentazione)

per quanto riguarda le variabili di assetto, bhè... sono 3 giroscopi e 3 accelerometri... a parte l'azzeramento che si può salvare a ogni accensione elettrica, direi che non ci sono problemi di sorta nel caso si riavvi in volo (a parte il tempo di riavvio...)

Comunque il Watchdog timer è impostabile...
Puoi impostare che entri in funzione dopo questi tempi di inattività: 15ms, 30ms, 60 ms, 120ms, 250ms, 500ms, 1s, 2s, 4s e 8s... se si imposta un valore tipo 120 o 250 ms e ogni volta che legge i dati dalla ricevente, resetta il contatore, non dovrebbero esserci problemi, no???

[elettro]

se l'arduino si è impallato per l'alimentazione IMHO il watchdog non serve a nulla, si pianta pure lui la cosa più sicura secondo me è un circuito analogico che quando riceve un qualsiasi segnale (tipo ir telecomando, onde evitare frequenze già in uso) toglie l'alimentazione a tutto.
si consiglia un cucchiaino di scorta

[redfox74]

Problemi sulle alimentazioni

Scusate ma state facendo un po' di confusione ... partiamo da un principio di base un microcontrollore qualunque esso sia deve avere uno stadio di alimentazione che rasenta la perfezione , perchè se no è normale che abbia problemi il micro questo vale non solo per arduino ma anche per un qualsiasi arm7 - arm9 - arm11 ecc ecc
Piu' sale la velocità del processore piu' il problema si amplifica , quindi prima di tutto lo stadio di alimentazione .
Nel mio caso , ma anche nel caso di Mikrokopter che usiamo micro della stessa classe di arduino gli AVR 644P il problema lo si risolve lavorando molto sulle alimentazione , questo significa che da un lato se si usa un DCC convertere da 30 a 5 volt come è il caso della multipilot , si riempie ovunque di condensatori e si mettono powerplane praticamente ovunque cosa significa powerplane ?! Nel caso della multipilot per esempio io ho un PCB a 4 strati 2 dei quali uno fa' da GND e l'altro da +5Volt , questo significa che quando ho fatto il master tutti i componenti si collegano al piano di massa e al piano VCC per prelevare la loro alimentazione , su questi piani di alimentazione normalmente per togliere i glitch si riempie la scheda di condensatori ....
Se di base un circuito non ha questi accorgimenti è ovvio che poi spurie sull'alimentazione mettono in crisi il sistema.
Le varie board di valutazione di arduino in quanto board di valutazione sono solo due strati e quindi le alimentazioni e le masse sono portate con delle piste in giro per la scheda e quindi possono risentire sicuramente dei problemi che state segnalando ... la cosa migliore sarebbe con un bell'oscilloscopio controllare le piste di alimentazione del micro per vedere quando si muovono i motori cosa si vedere sul VCC del micro ...
Se sulla vcc si vedono cose diverse da un bel segnale +5Volt senza alcun glitch tutto ok , se no se si vedono cose strane accopiarsi al +5 è la fine ...
il controllo va fatto con l'oscilloscopio in AC e con una scala massima da 50 mv , fino a 15 - 20 mv di spurie ci sta ma non di piu' ... se i circuiti sono fatti mali mi è capitato anche a me di vedere delle alimentazioni che si muovevano anche di 300 mv ...
Poi si puo' decidere di attivare funzioni automatiche del micro con autoreset se ci sono problemi sulla linea di alimentazione o con watchdog , ma sono dei paliativi .... specialmente se il problema accade con una frequenza molto alta . Poi è sempre bene attivare lo watchdog , ma prima bisogna fare in modo che sia l'hw che il firmware non si trovino mai nelle condizioni di doverlo utilizzare.
@Danveal la scheda coridium è multistrato , con i due powerplane per il gnd e il +5Volt ? Se ha piu' di due strati sul PCB sei abbastanza tranquillo se così non fosse sarebbe il caso che anche tu verificassi questa cosa ... prima di trovarti brutte sorprese causate dall'hardware.
Quindi concludendo , Arduino è un framework di sviluppo software a cui non si possono inputare questi tipi di problemi facendo di tutta un'erba un fascio ... collegare delle schede con dei fili volanti non dimensionando correttamente l'hardware porta soltanto a ritrovarsi in situazioni critiche ... sono curioso di provare BaronPilot sul mio hardware per verificarne la qualità ... visto che attualmente con i firmware che ho provato l'hw non mi ha mai mollato anzi. Quando ho progettato a settembre dello scorso anno la prima multipilot la mia idea era proprio quella di offrire agli utenti di arduino una piattaforma stabile per poter volare che secondo me non potevano essere le attuali schedine arduino pensate per altre applicazioni tendenzialmente meno complesse da quelle che attualmente stiamo portando avanti nelle nostre sperimentazioni di oggetti volanti.
Un saluto
Roberto

[BBC25185]

Ok... mi hai preceduto...

Hai perfettamente ragione, l'alimentazione pulita è la prima regola per avere un funzionamento perfetto (me ne sono reso conto dalle mie sperimentazioni)

Il Watchdog timer, però, aiuta ad aumentare la sicurezza del sistema ed evitare che, per un qualunque motivo, l'arduino non si pianti lasciando i motori al massimo (con rischio di vederli cotti, di farsi male etc etc)!!!

In ogni caso il watchdog timer è un circuito interno all'ATMega separato da quello principale che ha l'unico scopo, appunto, di resettare (o generare un innterrupt) nel caso il counter malauguratamente raggiunge lo 0!!!

[redfox74]

Come sarebbe a dire che si pianta anche il watchdog???
Non è un contatore fisico (quindi separato dal software) che, appena arriva a 0, resetta il Chip??? e che, per evitare che venga resettato, deve esserci il programma che gira per evitare che vada a 0???

Oppure cè qualcosa che non sò sul watchdog timer???

Penso che quello che voleva dire eletro era quello che ho scritto anche io sulla mia mail cioè che anche se hai lo watchdog e non hai risolto i problemi di alimentazione poi alla fine ti va comunque tutto in palla ugualmente ...
Scusa che cosa avevi fatto con arduino che andava sott'acqua ? Mi interessa molto il tema hai qualche link ?
Saluti
Roberto

[flybie]

sapreste indicare quale WM+ e nunchuck acquistare (qualche link magari) che sia già testato e funzionante con il BaronPilot con il teensy ++ 2.0 ?

[danveal]

Scusate ma state facendo un po' di confusione ... partiamo da un principio di base un microcontrollore qualunque esso sia deve avere uno stadio di alimentazione che rasenta la perfezione , perchè se no è normale che abbia problemi il micro questo vale non solo per arduino ma anche per un qualsiasi arm7 - arm9 - arm11 ecc ecc
Piu' sale la velocità del processore piu' il problema si amplifica , quindi prima di tutto lo stadio di alimentazione .
Nel mio caso , ma anche nel caso di Mikrokopter che usiamo micro della stessa classe di arduino gli AVR 644P il problema lo si risolve lavorando molto sulle alimentazione , questo significa che da un lato se si usa un DCC convertere da 30 a 5 volt come è il caso della multipilot , si riempie ovunque di condensatori e si mettono powerplane praticamente ovunque cosa significa powerplane ?! Nel caso della multipilot per esempio io ho un PCB a 4 strati 2 dei quali uno fa' da GND e l'altro da +5Volt , questo significa che quando ho fatto il master tutti i componenti si collegano al piano di massa e al piano VCC per prelevare la loro alimentazione , su questi piani di alimentazione normalmente per togliere i glitch si riempie la scheda di condensatori ....
Se di base un circuito non ha questi accorgimenti è ovvio che poi spurie sull'alimentazione mettono in crisi il sistema.
Le varie board di valutazione di arduino in quanto board di valutazione sono solo due strati e quindi le alimentazioni e le masse sono portate con delle piste in giro per la scheda e quindi possono risentire sicuramente dei problemi che state segnalando ... la cosa migliore sarebbe con un bell'oscilloscopio controllare le piste di alimentazione del micro per vedere quando si muovono i motori cosa si vedere sul VCC del micro ...
Se sulla vcc si vedono cose diverse da un bel segnale +5Volt senza alcun glitch tutto ok , se no se si vedono cose strane accopiarsi al +5 è la fine ...
il controllo va fatto con l'oscilloscopio in AC e con una scala massima da 50 mv , fino a 15 - 20 mv di spurie ci sta ma non di piu' ... se i circuiti sono fatti mali mi è capitato anche a me di vedere delle alimentazioni che si muovevano anche di 300 mv ...
Poi si puo' decidere di attivare funzioni automatiche del micro con autoreset se ci sono problemi sulla linea di alimentazione o con watchdog , ma sono dei paliativi .... specialmente se il problema accade con una frequenza molto alta . Poi è sempre bene attivare lo watchdog , ma prima bisogna fare in modo che sia l'hw che il firmware non si trovino mai nelle condizioni di doverlo utilizzare.
@Danveal la scheda coridium è multistrato , con i due powerplane per il gnd e il +5Volt ? Se ha piu' di due strati sul PCB sei abbastanza tranquillo se così non fosse sarebbe il caso che anche tu verificassi questa cosa ... prima di trovarti brutte sorprese causate dall'hardware.
Quindi concludendo , Arduino è un framework di sviluppo software a cui non si possono inputare questi tipi di problemi facendo di tutta un'erba un fascio ... collegare delle schede con dei fili volanti non dimensionando correttamente l'hardware porta soltanto a ritrovarsi in situazioni critiche ... sono curioso di provare BaronPilot sul mio hardware per verificarne la qualità ... visto che attualmente con i firmware che ho provato l'hw non mi ha mai mollato anzi. Quando ho progettato a settembre dello scorso anno la prima multipilot la mia idea era proprio quella di offrire agli utenti di arduino una piattaforma stabile per poter volare che secondo me non potevano essere le attuali schedine arduino pensate per altre applicazioni tendenzialmente meno complesse da quelle che attualmente stiamo portando avanti nelle nostre sperimentazioni di oggetti volanti.
Un saluto
Roberto

Spiegazione fantastica, ricordo perfettamente quando facevi queste considerazioni sulle schede sopratutto se utilizzate su velivoli. I multirotori poi sappiamo che sono ricchi di interferenze di vario genere. Mi permetto solo di aggiungere al tuo post alcune considerazioni:
un alimentazione swithcing fatta con gli ubec, a basso costo che ci sono in giro, genera fino 50mV picco-picco di noise. Bisognerebbe poi evitare che ci siano pin non collegati settati come ingressi, i cosidetti ingressi flottanti.
Inoltre i segnali PWM generano tantissimo rumore, non per niente gli smaliziati fanno il twisting dei fili, in particolare la lunghezza dei cavi esc-motore inizia a diventare critica dopo 15-20cm anche per questo ho l'abitudine di mettere gli esc sui bracci
Insomma ci sono tanti piccoli accorgimenti che se non effettuati possono generare problemi strani, del tipo va bene tutto per giorni poi ad un certo punto succedono le stranezze.
Per quanto riguarda l'armmite pro non ho idea di quanti strati abbia, ha i gnd digitali e analogici separati proprio per evitare rumore, so che la usano anche in prototipazioni e piccole serie per controlli industriali, in ogni caso ormai ho fatto decine di ore di volo con l'armquad e non ho mai avuto problemi di nessun genere. L'unica cosa che ho notato e' la delicatezza delle linee analogiche, se si supera il max input di 3.3volt inizia a fare cose strane, mentre le I/O digitali sono 5v tolleranti.

Ciao

[redfox74]

Spiegazione fantastica, ricordo perfettamente quando facevi queste considerazioni sulle schede sopratutto se utilizzate su velivoli. I multirotori poi sappiamo che sono ricchi di interferenze di vario genere. Mi permetto solo di aggiungere al tuo post alcune considerazioni:
un alimentazione swithcing fatta con gli ubec, a basso costo che ci sono in giro, genera fino 50mV picco-picco di noise. Bisognerebbe poi evitare che ci siano pin non collegati settati come ingressi, i cosidetti ingressi flottanti.
Inoltre i segnali PWM generano tantissimo rumore, non per niente gli smaliziati fanno il twisting dei fili, in particolare la lunghezza dei cavi esc-motore inizia a diventare critica dopo 15-20cm anche per questo ho l'abitudine di mettere gli esc sui bracci
Insomma ci sono tanti piccoli accorgimenti che se non effettuati possono generare problemi strani, del tipo va bene tutto per giorni poi ad un certo punto succedono le stranezze.
Per quanto riguarda l'armmite pro non ho idea di quanti strati abbia, ha i gnd digitali e analogici separati proprio per evitare rumore, so che la usano anche in prototipazioni e piccole serie per controlli industriali, in ogni caso ormai ho fatto decine di ore di volo con l'armquad e non ho mai avuto problemi di nessun genere. L'unica cosa che ho notato e' la delicatezza delle linee analogiche, se si supera il max input di 3.3volt inizia a fare cose strane, mentre le I/O digitali sono 5v tolleranti.

Ciao

Ottimo il tuo intervento ... sicuramente gli ingressi liberi in questo tipo di applicazione vanno settati come uscite e non lasciati come input e free .
In merito ai BEC economici io ho preferito mettere direattamente su scheda lo switching per l'alimentazione questo perchè così non ci sono problemi di sorta a livello di cavi cavetti ecc ecc ... ogni cavo a seconda della tensione e delle correnti che transitano genera una resistenza che abbassa dall'altro capo del filo la tensione che va poi ad alimentare le schede quindi un cavo troppo piccolo e troppo lungo porta ad una tensione troppo bassa all'ingresso del controllore . I controller I2C che ho realizzato o quelli dell'MK che utilizzo abitualmente hanno un approccio decisamente piu' furbo dei classici ESC PWM, infatti l'alimentazione è separata e gli ESC hanno un loro regolatore indipendente che puo' arrivare fino a 30 volt in ingresso e poi il bus i2c si occupa di comunicare la velocità del motore BL collegato .
A differenza dell'approccio "classico" dove il micro pilota direttamente in PWM gli ESC un bus i2c se si impalla il micro smette di impartire comandi ai motori e semplicemente il motore si spegne e quindi non accade che rimangano settati motori a velocità fuori controllo.
Non conosco gli ESC PWM in modo approfondito , forse qui @Denveal @Ciskje e altri possono spiegare meglio il problema , quanto supportano in ingresso come voltaggio ? sicuramente se devono supportare 20 amp non prendono alimentazione dalla scheda di controllo ma direttamente dalla LIPO.
Quanto sporcano le alimentazioni ? Qualcuno ha già fatto delle misure , specialmente sotto stress ... Il PWM generato per pilotare il motore sicuramente succhia sul cavo un bel po' di corrente e quando i motori sono a spinta piena se i cavi sono piccoli o mal dimensionati si vedranno le onde quadre delle uscite A B C per pilotare il trifase che tornano indietro , Se questo sporoc intacca l'alimentazione dei micro degli ESC o della scheda di controllo abbiamo già belle che fatto la frittata ;)
Quindi armatevi di oscilloscopio e guardatevi la pulizia di queste alimentazioni , risolto quello si puo' andare avanti a parlare del resto
Il BaronPilot , visto che stiamo parlando in questo Thread ... dovrà diventare oltre che economico ... e qui dopo i vari accorgimenti vedremo quanto lo sarà ancora ;) ... ultra affidabile e robusto anche grazie a questi accorgimenti hardware che vanno sottolineati 10 volte a livello di assemblaggio dei kit !!
Saluti
Roberto

[biv2533]

Domanda da inesperto

Se le alimentazioni sono tanto sporche, perche' montate alimentatori switching?

Un vecchio alimentatore lineare penso che andrebbe piu' che bene, in fin dei conti i processori e le varie circuiterie, mi pare che assorbano solo qualche centinaio di milliampere.

[redfox74]

Per quanto riguarda l'armmite pro non ho idea di quanti strati abbia, ha i gnd digitali e analogici separati proprio per evitare rumore, so che la usano anche in prototipazioni e piccole serie per controlli industriali, in ogni caso ormai ho fatto decine di ore di volo con l'armquad e non ho mai avuto problemi di nessun genere. L'unica cosa che ho notato e' la delicatezza delle linee analogiche, se si supera il max input di 3.3volt inizia a fare cose strane, mentre le I/O digitali sono 5v tolleranti.

Ciao

Per vedere quanti strati ha una scheda lo puoi capire da due cose da un lato lo spessore che ti consente tra le altre cose di vedere se in trasparenza si vedono gli altri piani di segnali o di alimentazione... e dall'altro se una pista che vedi sopra , esattamente sotto la trovi dove c'e' il vias (buchino che fa' passare da sopra a sotto il segnale) allora potrebbe essere un due strati , ma lo capisci al volo non è così difficile , di solito poi le multistrato hanno delle cuciture vias che passano da sopra a sotto per unire le alimentazioni ai piani di massa o a quelli di alimentazione ... Se hai avuto in mano un po' di schede elettroniche dovresti capirlo al volo
Saluti
Roberto

[redfox74]

Se le alimentazioni sono tanto sporche, perche' montate alimentatori switching?

Un vecchio alimentatore lineare penso che andrebbe piu' che bene, in fin dei conti i processori e le varie circuiterie, mi pare che assorbano solo qualche centinaio di milliampere.

Ciao BIV ,
in realtà non è un problema di alimentatori switching o lineare , prima di tutto il lineare rispetto allo switching ti lavora solo a determinati livelli prestabiliti , poi tutto cio' che c'e' in eccesso scalda e quindi devi dissipare per mantenere un buon rendimento . Anche sulla MK all'inizio montavano gli LM7805 se non sbaglio e poi hanno messo su dei DCC da 1 amp switching .
Quindi un lineare scalda e uno switching no. Lo switching se è fatto bene e va ad alta frequenza non sporca proprio nulla ... i vecchi switching a bassa frequenza avevano questi problemi ma i nuovi no ... ormai anche i gps che hanno correlatori ad alta precisione usano switching da tutte le parti.
Il problema delle spurie non è dato dagli switching , ma da altre tipologie di switch dovute per esempio al pilotaggio dei motori a 3 fasi ... ogni fase è un'onda quadra ogni onda quadra porta al motore una certe quantità di energia , se non è fatto correttamente il dimensionamento dei cavi questa onda quadra la vedrai anche sulla lipo .. se torna indietro fino alla lipo te la trovi all'ingresso della scheda di controllo che se non ha un buon circuito di filtro in ingresso propaga sulla scheda di controllo il problema .
Magari non ti succede nulla finchè fai manovre che richiedono poca energia , ma quando fai qualcosa che richiede picchi di energia e i filtri in ingresso alla scheda di controllo non reggono ... ti trovi delle anomali sull'alimentazione del micro della scheda di controllo che lo blocca e manda in fault tutto il sistema.
Spero di essermi spiegato in parole semplici ;)
Un saluto
Roberto N.

[flybie]

sapreste indicare quale WM+ e nunchuck acquistare (qualche link magari) che sia già testato e funzionante con il BaronPilot con il teensy ++ 2.0 ?

scusate se torno sulla terra.... ( ma non sono ancora decollato... )

quale WM+ e nunchuck acquistare ?

[biv2533]

Spero di essermi spiegato in parole semplici ;)

Tutto chiaro e ti confermo che sulle prime scede MK c'era un xx05 o qualcosa del genere

[danveal]

Non conosco gli ESC PWM in modo approfondito , forse qui @Denveal @Ciskje e altri possono spiegare meglio il problema , quanto supportano in ingresso come voltaggio ? sicuramente se devono supportare 20 amp non prendono alimentazione dalla scheda di controllo ma direttamente dalla LIPO.

Dal lato motore I2C o PWM non fa differenza visto che tutti e due pilotano il motore allo stesso modo. In sostanza un regolatore I2C non e' altro che un regolatore PWM con l'interfaccia I2C ma con firmware dedicato.
In ingresso i regolatori PWM accettano il segnale generato dalle RX, nel mio caso lo piloto con segnali TTL compatibili a 495Hz, anche loro hanno una propria alimentazione, si possono collegare a 2s-3s e via dicendo a seconda dei dati di targa.
Io uso l'ubec lineare del regolatore stesso, che e' da 5V 2A.
La scheda + sensori non e' che assorba chissa cosa quindi non ci sono problemi per il lineare.
Per quanto riguarda l'armmite ieri notte quando ho detto non ho idea era perche' non potevo vederla, e' spessa il doppio della FC MK ed ha ovviamente parecchie via sia piccole che grandi potrebbe essere multistrato non ho voglia di smontarla dal quad per guardarla meglio in controluce e dall'altra faccia anche perche non ho problemi. Piuttosto mi viene in mente, come certamente sai, che anche il disegno delle piste che portano certi segnali può essere critico in certe applicazioni in quanto possono captare rumore. E quà rumore da captare ce ne' un sacco.