Multiwii: mantenimento quota e posizione senza baro e gps?

[chetti]

Ciao a tutti.
ho questa cosa da chiedervi, ho provato a cercare ma senza risultati.

ho realizzato un classico tricottero e ho una multiwii di quelle "intergrate" presa da fpv4ever, ha solo i gyro e acc, il telaio è bello rigido in carbonio e dopo diversi settaggi sono arrivato ad un volo molto stabile e sicuro.
il mio obiettivo non sono le "manovre" ma avere il mezzo docile e stabile per l'FPV, non ho bisogno di andare lontano, almeno per ora, e non vorrei aggiungere troppi sensori... (come diceva quello: quello che non c'è non si rompe...)

purtroppo non sono molto esperto di arduino e relativa compilazione, ma mi verrebbe da credere che si possa modificare il firm per riuscire a mantenere (entro certi limiti di deriva dei sensori) sia una "pseudo quota" che una "pseudo posizione" senza barometro, magnetometro e gps.

è possibile?, magari è previsto già e io non ho capito come si imposta/configura?

spiego il mio pensiero:
con gli accelerometri è già possibile vedere nelle tre direzioni dove si sposta il modello in modo lineare, e quindi secondo me si potrebbe "dire" al processore di variare l'assetto livellato e la potenza dei motori in modo da mantenere a zero il valore di "G" di abbrivio longitudinale e laterale, e a 1 G quello verticale.

e chiaro che non si avrebbe un mantenimento perfetto di quota e posizione... ma almeno aiuterebbe molto, tipo contrastare il vento e soprattutto in FPV.

grazie in anticipo e chiedo scusa se per caso c'era già un altra discussione in merito e io non l'ho trovata.

Ale

[magnetron1]

In linea di massima la tua idea è corretta, anche perchè la penso come te basandomi sullo stesso ragionamento che hai fatto.
La cosa però è più complessa in quanto i dati letti dai sensori andrebbero filtrati e poi utilizzati per fare quello che dici. Stiamo mettendo le idee insieme sia con multiwii che con un altro progetto fresco fresco che è in via di sviluppo... appena verrà fuori qualcosa di buono sarà reso pubblico...

[chetti]

bene, sono contento di ciò... e non vedo l'ora!!!
come ho detto purtroppo non ho esperienza con la programmazione di arduino, ma se posso contribuire in qualche modo contattatemi pure, anche eventualmente per fare da "cavia".

ho letto anche che la gestione del throttle nel modo mantenimento quota è problematica.
pensavo a questo:
sarebbe possibile, sempre a livello di programmazione, cambiare il modo di lettura del segnale impostando una divisone?

mi spiego meglio:
porto in hover il modello senza attivare il mantenimento quota e una volta che è attivato fare in modo che l'intera escursione dello stick gas venga interpretata come una sorta di subtrim sull'effettivo valore G verticale, in modo che se si muove lo stick del gas le variazioni siano minime.

pensavo anche che nel caso di utilizzo del sensore barometrico...
se si potesse aggiungere un ulteriore canale in ingresso, si potrebbe usare come "riferimento quota" ovvero, abbinare un "escursione quota" all'escursione del canale aux, per esempio 0-100 metri, a questo punto si porta il mezzo in hover tenendo il canale aux al valore minimo, quando si attiva il mantenimento si "memorizza" la quota e gli si aggiunge il valore incrementale del canale aux (quindi se il mio hover è a 30 metri l'escursione sarà 30/130) a questo punto si può cambiare quota a picere con il canale aux e usare il throttle come "subtrim" della quota raggiunta.
ovviamente disattivando il baro hold il throttle deve essere riportato in "zona" hover manualmente e magari impostare una "curva di raccordo" sul valore effettivo di potenza motori nel passaggio, per evitare "svarioni" improvvisi di quota.

ho detto delle cavolate oppure è sensato/realizzabile?

ciao

Ale

ps
mi sa che mi metto a studiare meglio arduino....

[areis81]

il wookong, se non sbaglio, integra il gps hold con i dati dell'acc 3D per mantenere meglio la posizione, e fa lo stesso con il baro per l'altitudine. se il multiwii avesse un'acc 3D penso la cosa si potrebbe fare, ma visto che se non sbaglio è solo un acc lineare non credo sia fattibile se non per la quota. mi pare però strano che i guru dello sviluppo non ci abbiano pensato, quindi sinceramente non credo sia fattibile. detto da un ignorante in materia, però, vado solo a naso....

[chetti]

non conosco il wookong... ma nel GUI del multiwii si vedono bene 3 direzioni in cui lavora l'accelerometro, credo quindi che si possa considerare 3D anche lui.

se poi esiste una differenza ulteriore non la conosco.

di fatto il termine "accelerometro" indica uno strumento che misura l'accelerazione lineare o angolare, a differenza del giroscopio che rileva solo l'angolo di rotazione degli assi.

ecco... mentre scrivevo in effetti mi sono reso conto che non si capisce bene come distinguere una accelerazione angolare da una accelerazione lineare... è probabile che l'ACC del MWC non abbia il rilevamento "angolare", che però mi sembra che serva a poco per rilevare uno spostamento lineare causato per esempio dal vento.

la parola ai "guru"

[ziojos]

non conosco il wookong... ma nel GUI del multiwii si vedono bene 3 direzioni in cui lavora l'accelerometro, credo quindi che si possa considerare 3D anche lui.

se poi esiste una differenza ulteriore non la conosco.

di fatto il termine "accelerometro" indica uno strumento che misura l'accelerazione lineare o angolare, a differenza del giroscopio che rileva solo l'angolo di rotazione degli assi.

ecco... mentre scrivevo in effetti mi sono reso conto che non si capisce bene come distinguere una accelerazione angolare da una accelerazione lineare... è probabile che l'ACC del MWC non abbia il rilevamento "angolare", che però mi sembra che serva a poco per rilevare uno spostamento lineare causato per esempio dal vento.

la parola ai "guru"

La difficoltà maggire è la doppia integrazione matematica degli accelerometri che è praticamente impossibile da far convergere questo problema è causato dalla presenza di "rumore" nella lettura sia in alta che in bassa frequenza e dal fatto che per vari motivi sono presenti asimmetrie nella lettura.
Se si pensa di ottenere la posizione con la sola integrazio degli accelerometri si possono ottenere risultati utilizzabili solo nei primi istanti dopo in genere il risultato diverge. Ci sono delle tecniche di integrazione basate su filtratura e windowing (finestre di lettura) con cancellazione del rumore ma non si va oltre pochi secondi (almeno con i sensori a nostra disposizione).

In realtà il vero valore degli accelerometri sta nella dinamica, per questo motivo viene effettuata la "fusione" con altri sensori che sono capaci di dare informazioni non divergenti di velocità e/o posizione:

Barometro + Accelerometri per l'atitudine
GPS (Telecamera,Pitot, etc) + Accelerometri per la posizione.

In questo modo si hanno i vantaggi di tutti e due i metodi di misura.

Nulla toglie che facendo molta attenzione alla costruzione ed alla filtratura dei dati si possa avere degli effetti di stabilizzazione.

a tal proposito guarda questo mio filmato in cui sperimento un sistema per il controllo dell' altitudine basato su soli dati accererometrici e di assetto:



In genere questi sistemi funzionano bene nella "turbolenza" e magari si perdono quando l'aria è calma, proprio perchè quando il segnale è forte (raffiche" il rumore ha minore impatto sui calcoli.

credo che su Wookong gli accelerometri sono usati anche mantenere abbastanza fermo il mezzo in mancanza di GPS, ma per far questo hanno sicuramente fatto un' ottimo lavoro elettro-meccanico-dinamico.

Ciao

Josè

[magnetron1]

La difficoltà maggire è la doppia integrazione matematica degli accelerometri che è praticamente impossibile da far convergere questo problema è causato dalla presenza di "rumore" nella lettura sia in alta che in bassa frequenza e dal fatto che per vari motivi sono presenti asimmetrie nella lettura.
Se si pensa di ottenere la posizione con la sola integrazio degli accelerometri si possono ottenere risultati utilizzabili solo nei primi istanti dopo in genere il risultato diverge. Ci sono delle tecniche di integrazione basate su filtratura e windowing (finestre di lettura) con cancellazione del rumore ma non si va oltre pochi secondi (almeno con i sensori a nostra disposizione).

In realtà il vero valore degli accelerometri sta nella dinamica, per questo motivo viene effettuata la "fusione" con altri sensori che sono capaci di dare informazioni non divergenti di velocità e/o posizione:

Barometro + Accelerometri per l'atitudine
GPS (Telecamera,Pitot, etc) + Accelerometri per la posizione.

In questo modo si hanno i vantaggi di tutti e due i metodi di misura.

Nulla toglie che facendo molta attenzione alla costruzione ed alla filtratura dei dati si possa avere degli effetti di stabilizzazione.

a tal proposito guarda questo mio filmato in cui sperimento un sistema per il controllo dell' altitudine basato su soli dati accererometrici e di assetto:



In genere questi sistemi funzionano bene nella "turbolenza" e magari si perdono quando l'aria è calma, proprio perchè quando il segnale è forte (raffiche" il rumore ha minore impatto sui calcoli.

credo che su Wookong gli accelerometri sono usati anche mantenere abbastanza fermo il mezzo in mancanza di GPS, ma per far questo hanno sicuramente fatto un' ottimo lavoro elettro-meccanico-dinamico.

Ciao

Josè

Josè,
trovo le tue osservazioni interessanti.
Come si possono integrare i dati di barometro + accelerometro? Fammi capire meglio questo concetto in modo che io possa trasformarlo in un algoritmo da provare.
Dovrebbe funzionare anche con gyro + acc per mantenere meglio la posizione stabile.
Come possiamo provare questo concetto?

[ziojos]

Josè,
trovo le tue osservazioni interessanti.
Come si possono integrare i dati di barometro + accelerometro? Fammi capire meglio questo concetto in modo che io possa trasformarlo in un algoritmo da provare.
Dovrebbe funzionare anche con gyro + acc per mantenere meglio la posizione stabile.
Come possiamo provare questo concetto?

Ciao Michele,

In genere sensori diversi si integrano con tecniche dette di fusion (Filtri Kalman, Complementari etc).

ad esempio per la valutazione dell' assetto il MWii integra dati di velocità angolare ottenuti dai Gyro con dati di assetto ottenuti dagli Accelerometri sfruttando le caratteristiche di velocità ed accuratezza dei Gyro ed utilizzando gli accelerometri per eliminare il drift.

In Multiwii trovi un filtro complementare in IMU.ino che fa questo. Questi filtri si comportano anche come filtro passa basso e preferibilmente vanno alimentati con dati filtrati il meno possibile per conservare accuratezza e velocità di risposta.

In modo analogo si può fare con il barometro ed i dati di accelerazione verticale.
In questo caso la tecnica è quella di "controllare" l'integrale dell'accelerazione verticale per la velocità e successivamente per spazio (Quota) con i dati di riferimento ottenuti dal barometro. Così facendo si potrà ottenere un controllo dinamico dell' altezza.

La soluzione "ufficiale" della MWii 2.0 utilizza in pratica solo il barometro (VEL PID = 0,0,0) in quanto non è facile programmare un filtro affidabile che controlli adeguatamente il doppio integrale dell' accelerazione e pertanto non gestisce bene i cambiamenti rapidi ed ha ampie oscillazioni prima di trovare la posizione.

Io ho implementato una soluzione completa paragonabile a quella di MK e la sto migliorando per avere una buona risposta anche nel volo traslato veloce (brutta rogna , ... questa caratteristica mi sembra implementata meglio in DIJ Wookong che in MK)

Riassumendo bisogna realizzare un doppio filtro (kalman o complementare) per la fusione dei dati del Barometro e dell' accelerazione verticale

Per quanto riguarda la posizione orizzontale, il ruolo del barometro viene preso dal GPS e dalla Bussola ( ma anche da una telecamera come nel Parrot) comunque i concetti sono gli stessi.

La soluzione per il GPS è più difficile da mettere a punto in quanto richiede una misurazione ottimale dell' heading (Compass) e della velocità in modulo e direzione (GPS ed ACC) oltre ovviamente ad una buona gestione del GPS, anche in questo caso ho la netta impressione che DIJ abbi fatto un lavoro eccellente. Inoltre l'integrazione avviene su due assi e non su uno solo come per l' altezza.

Ad esempio Una soluzione solo GPS e Compass tipo Arducopter è assolutamente inadeguata, magari mantiene la posizione ma le dinamiche sono troppo lente.

Ciao

Josè

[magnetron1]

Ciao Michele,

In genere sensori diversi si integrano con tecniche dette di fusion (Filtri Kalman, Complementari etc).

ad esempio per la valutazione dell' assetto il MWii integra dati di velocità angolare ottenuti dai Gyro con dati di assetto ottenuti dagli Accelerometri sfruttando le caratteristiche di velocità ed accuratezza dei Gyro ed utilizzando gli accelerometri per eliminare il drift.

In Multiwii trovi un filtro complementare in IMU.ino che fa questo. Questi filtri si comportano anche come filtro passa basso e preferibilmente vanno alimentati con dati filtrati il meno possibile per conservare accuratezza e velocità di risposta.

In modo analogo si può fare con il barometro ed i dati di accelerazione verticale.
In questo caso la tecnica è quella di "controllare" l'integrale dell'accelerazione verticale per la velocità e successivamente per spazio (Quota) con i dati di riferimento ottenuti dal barometro. Così facendo si potrà ottenere un controllo dinamico dell' altezza.

La soluzione "ufficiale" della MWii 2.0 utilizza in pratica solo il barometro (VEL PID = 0,0,0) in quanto non è facile programmare un filtro affidabile che controlli adeguatamente il doppio integrale dell' accelerazione e pertanto non gestisce bene i cambiamenti rapidi ed ha ampie oscillazioni prima di trovare la posizione.

Io ho implementato una soluzione completa paragonabile a quella di MK e la sto migliorando per avere una buona risposta anche nel volo traslato veloce (brutta rogna , ... questa caratteristica mi sembra implementata meglio in DIJ Wookong che in MK)

Riassumendo bisogna realizzare un doppio filtro (kalman o complementare) per la fusione dei dati del Barometro e dell' accelerazione verticale

Per quanto riguarda la posizione orizzontale, il ruolo del barometro viene preso dal GPS e dalla Bussola ( ma anche da una telecamera come nel Parrot) comunque i concetti sono gli stessi.

La soluzione per il GPS è più difficile da mettere a punto in quanto richiede una misurazione ottimale dell' heading (Compass) e della velocità in modulo e direzione (GPS ed ACC) oltre ovviamente ad una buona gestione del GPS, anche in questo caso ho la netta impressione che DIJ abbi fatto un lavoro eccellente. Inoltre l'integrazione avviene su due assi e non su uno solo come per l' altezza.

Ad esempio Una soluzione solo GPS e Compass tipo Arducopter è assolutamente inadeguata, magari mantiene la posizione ma le dinamiche sono troppo lente.

Ciao

Josè

Ottima discussione.
Senti, posteresti per grandi linee la tua routine di integrazione dei dati così come l'hai implementata. In effetti la teoria di compensare le derive di gyro e acc tra loro è secondo me vincente e già così con solo gyro + acc + mag sarebbe possibile in via teorica mantenere la posizione senza l'uso di barometro e gps. Disponendo poi del barometro e del gps si potrebbero implementare funzioni più complesse.
Diamo una svolta a questa multiwii?

[danveal]

Ottima discussione.
Senti, posteresti per grandi linee la tua routine di integrazione dei dati così come l'hai implementata. In effetti la teoria di compensare le derive di gyro e acc tra loro è secondo me vincente e già così con solo gyro + acc + mag sarebbe possibile in via teorica mantenere la posizione senza l'uso di barometro e gps. Disponendo poi del barometro e del gps si potrebbero implementare funzioni più complesse.
Diamo una svolta a questa multiwii?

L'idea che chiami vincente è quella che viene comunemente usata dalla nascita dei multirotori a partire dal 2007 in poi, eliminare la deriva dei giro tramite l'accelerometro.
Non è una cosa banale perchè in mezzo ci sono molti compromessi il primo dei quali la limitazione del processore che non è abbastanza veloce nel calcolare gli algoritmi pesanti in tempo utile ( leggi kalman ) e quindi si sono fatti compromessi e approssimazioni.
Il mantimento della posizione e' possibile senza gps ma appena arriva vento a dare un colpetto il quad si sposta per forza di cose, anche ma non solo perchè i sensori hanno una certa soglia di sensibilità per non essere troppo influenzati dalle vibrazioni e quindi non rilevano piccole variazioni.
In assenza di vento invece, i 127 step del segnale pwm uniti agli esc commerciali che sono filtrati fanno in modo che vi siano spostamenti dovuti a un controllo impreciso.
Molto meglio sarebbe avere 255 step ed esc pwm con firmware SimonK che elimina il filtro in ingresso.
Inoltre fare calcoli ad 8 bit su coordinate gps rendera' il tutto molto poco preciso per quanto riguarda navigazione e mantenimento della posizione, per questi calcoli ci vuole minimo 32 bit meglio 64.

[chetti]

Ciao Josè e Michele, dai vostri post è evidente appunto la difficoltà di integrazione dei sensori, e se non sbaglio ho capito anche che l'attuale firmware del multiwii, compreso la versione 2_0 NON prevede questa integrazione, neppure tra barometro e acc verticale oppure tra gps, acc e gyro.
sbaglio?

con questo mio discorso non voglio assolutamente sminuire il lavoro fatto finora da tutti quelli che hanno contribuito... anzi... tanto di cappello !!

ma vedo che c'é ancora molto lavoro da fare per avere un sistema "quasi perfetto" (passatemi il termine).
tra l'altro credo di aver capito che si è ancora lontani dal raggiungere i limiti dell'hardware, che essendo open source è dal mio punto di vista quasi una scelta obbligata... (ho accumulato fin troppa roba che è obsoleta e che non si può aggiornare o integrare).

purtroppo mi sento abbastanza "impotente" perché conosco il mondo dell'elettronica solo marginalmente ma da progettista meccanico che sono comprendo comunque i concetti di base e mi piacerebbe molto poter contribuire a sviluppare il sistema mwii (anche solo di una virgola...).

purtroppo ho poco tempo per dedicarmi alla lettura delle 6000 pagine nel 3D principale e spesso mi accorgo che mi scappano dei concetti o prove già fatte... ho aperto infatti questo 3D proprio per "isolare" un concetto che ritengo delicato e che non si debba rincorrere tra le migliaia di pagine che ci sono già.

domanda:

esiste un tutorial oppure anche una guida su il mondo arduino che sia almeno in italiano e che "parta" da concetti base sulla compilazione di un programma?
avete un link oppure anche un riferimento su un libro cartaceo da acquistare?
sul sito ufficiale non ho trovato gran che... e soprattutto è in inglese, conosco l'inglese ma su certi concetti preferirei l'italiano...

so che è una domanda banale ma a volte con la dritta giusta la salita è meno faticosa

so anche che parto da lontano ma il mio vero hobby principale è "imparare".

ciao

Ale

ps.

oppss... mentre scrivevo mi sono perso il post di danveal,

[ziojos]

L'idea che chiami vincente è quella che viene comunemente usata dalla nascita dei multirotori a partire dal 2007 in poi, eliminare la deriva dei giro tramite l'accelerometro.
Non è una cosa banale perchè in mezzo ci sono molti compromessi il primo dei quali la limitazione del processore che non è abbastanza veloce nel calcolare gli algoritmi pesanti in tempo utile ( leggi kalman ) e quindi si sono fatti compromessi e approssimazioni.
Il mantimento della posizione e' possibile senza gps ma appena arriva vento a dare un colpetto il quad si sposta per forza di cose, anche ma non solo perchè i sensori hanno una certa soglia di sensibilità per non essere troppo influenzati dalle vibrazioni e quindi non rilevano piccole variazioni.
In assenza di vento invece, i 127 step del segnale pwm uniti agli esc commerciali che sono filtrati fanno in modo che vi siano spostamenti dovuti a un controllo impreciso.
Molto meglio sarebbe avere 255 step ed esc pwm con firmware SimonK che elimina il filtro in ingresso.
Inoltre fare calcoli ad 8 bit su coordinate gps rendera' il tutto molto poco preciso per quanto riguarda navigazione e mantenimento della posizione, per questi calcoli ci vuole minimo 32 bit meglio 64.

Michele non parlava della deriva sull' assetto che è già tenuta in conto in tutti i SW per multirotori, ma della capacità di mantenere la posizione in senso tridimensionale.

I filtri complementari sono sufficientemente leggeri da poter girare su un Arduino e consentire un ciclo medio di più 200 Hz, non male I kalman lascerebbero spazio per un centinaio di Hz comunque non male.

E' da poco che sono su MWii comunque ho trovato la IMU molto accurata, da alcune misure che ho fatto consente una precisione prossima a 0.1°, la DCM di Aeroquad/Arducopter a a circa 0.2°, Ho comunque smanettato un poco sui parametri e leggo gli Accelerometri e i Gyro a un bit in più rispetto al SW standard. Per gli accelerometri si potrebbe andare ancora oltre mentre il Gyro ITG3200 non calibrerebbe più. Il problema della precisione non è nel rumore che viene assorbito nei processi di Integrazione Matematica ma nella calibrazione.

Il problema del vento non dipende dalle ESC, pensa al DIJ Wookong che trovo precisissimo e stabilissimo con ESC assolutamente "normali", Comunque l'utima versione di MWii su Mega e PRo Mini genera PWM a 16 Bit che con ESC moddate tipo Simonik portano sicuri ulteriori vantaggi.

Per i calcoli su GPS non ci sono assolutamente problemi di accuratezza, molti sbagliano la tecnica e il formato dei dati e si impelagano in calcoli inutili e complessi, ma di questo non darei la colpa al povero Arduino.

Tra l'altro l'ottimo Ciskje sta realizzando un ottimo progetto (più o meno un MWii molto custom con MARG, ed altre bellurie) che utilizza al massimo le librerie floating point di atmel in considerazione del fatto che sono estremamente ottimizzate e che in fondo in fondo ce la fanno

E' interessante vedere come ad oggi si stanno diffondendo molte schede a 32 bit, prima fra tutte la "definitiva" ma la qualità del Volato non sembra averne un impulso, quindi ben vengano sistemi più potenti ma la questione è nel SW non nell' HW ed oserei dire che fa di più una spugnetta ben posizionata che 50MHz di processore.

Michele,
In via puramente teorica sarebbe possibile quello che dici ma senza sensori di posizione (GPS, Telecamera, Barometro, Sonar, Laser, IR etc) nella pratica non si arriva lontano, inoltre, per quanto riguarda l'integrazione degli accelerometri, come ho detto qualche post prima, i sensori che utilizziamo per quanto ottimi non sono nemmeno lontanamente assimilabili a quelli utilizzati in sistemi di Autoguida Balistica. A tal proposito ho letto un interessante documento della NATO che definisce le architetture migliori per integrare GPS (Quelli a due frequenze con 10 cm di precisione) e Sensori Inerziali in modo da conserare il controllo di mezzi per un tempo ragionevolmente utile (Secondi) in caso di contromisure elettroniche (Jamming).

La mia sperimentazione sugli accelerometri mi è servita a comprenderne i limiti per utilizzarli meglio nel sistema integrato. Utilizzando tecniche di Unbiasing sono riuscitto ad ottenere integrazioni di velocità attendibili fino a due o tre ampie oscillazioni (diciamo di un metro), questo è un buon risultato poichè consente una "fusione" più semplice con i sensori di posizione.

Un' ultima nota, il modo Acro (solo GYRO) mantiene la posizione notevolmente meglio dell' Autolevel poichè contrasta le raffiche mentre l'altro si lascia trasportare dolcemente fin dal primo momento.

Ciao

[ziojos]

Ale

Se cerchi su internet trovi un eramente mare di informazioni, tutorial e semplici esempi,
un libro potrebbe essere questo:

Il manuale di Arduino - Schmidt Maik - Libro - IBS - Apogeo -

[danveal]

E' interessante vedere come ad oggi si stanno diffondendo molte schede a 32 bit, prima fra tutte la "definitiva" ma la qualità del Volato non sembra averne un impulso, quindi ben vengano sistemi più potenti ma la questione è nel SW non nell' HW ed oserei dire che fa di più una spugnetta ben posizionata che 50MHz di processore.

Infatti, il problema e' nel SW e per far girare un software decente ci vuole potenza che arduino non ha, troppi compromessi.

Per il fatto del kalman che dici sufficiente a 100Hz non sono d'accordo.
La precisione poi che hai rilevato ok ma e' in condizioni "statiche" nel volo entrano in gioco altre dinamiche che inficiano l'elevata precisione.
Insomma su arduino si gioca dal 2009 ma e' sempre allo stesso punto.
Altri giocano su piattaforme a 32 bit dal 2008 FrontPage - UAVP-NG - The Open Source Next Generation Multicopter e la qualita' del volato si vede eccome Videos/Flights - UAVP-NG - The Open Source Next Generation Multicopter

Vedasi anche Arm o Copter, paparazzi nova e derivati nella branch quadricotteri, e il recente openpilot. Software che su arduino ha tempo di ciclo di 1 mese

Ciao

[ziojos]

Infatti, il problema e' nel SW e per far girare un software decente ci vuole potenza che arduino non ha, troppi compromessi.

Per il fatto del kalman che dici sufficiente a 100Hz non sono d'accordo.
La precisione poi che hai rilevato ok ma e' in condizioni "statiche" nel volo entrano in gioco altre dinamiche che inficiano l'elevata precisione.
Insomma su arduino si gioca dal 2009 ma e' sempre allo stesso punto.
Altri giocano su piattaforme a 32 bit dal 2008 FrontPage - UAVP-NG - The Open Source Next Generation Multicopter e la qualita' del volato si vede eccome Videos/Flights - UAVP-NG - The Open Source Next Generation Multicopter

Vedasi anche Arm o Copter, paparazzi nova e derivati nella branch quadricotteri, e il recente openpilot. Software che su arduino ha tempo di ciclo di 1 mese

Ciao

danveal,

I progetti che presenti sono tutti degnissimi, si dovrebbe entrare nel dettaglio per capire se sempre ai proclami seguono i fatti. Nelle ultime settimane ho dato un' occhiata a Openpilot ed ho visto che a fronte di un progetto formalmente impeccabile i risultati sono scarsucci. Se Openpilot impiega un mese a girare probabilmente è un SW pieno di NOP. Un SW che a me non piace Arducopter, ormai su un Arduino fa anche la Birra senza chissa quali compromessi poi ha problemi nel volato ma questo di certo non per problemi di potenza di calcolo

Devo però osservare che, sono sempre il solito ingenuo, provo a dire ( e provo a fare ) che sulle normali piattaforme che usiamo c'è un margine di sviluppo più che significativo e arriva sempre qualcuno che mi conta i MHz. La realtà è che c'è chi con i 16 MHz trova soluzioni funzionali e chi con i Tera Flop Resta a Terra e che molti cercano una panacea che risolva i problemi senza sforzi. Poi per un' unità matematica in virgola mobile in doppia precisione ci metterei la firma .... ma questa è un' altra storia.

Lo so che i Tuoi Multi volano bene, e Ti faccio una domanda Ti sono veramente serviti tanti MHz per ottenere i risultati che hai avuto

Poi, secondo te è giusto aver fatto schede potentissime con tutto integrato che non ti danno la possibilità di mettere il Compass fuori dai campi magnetici o il Baro in modo da avere una buona misurazione della pressione statica ?

Oppure cosa ne pensi del lavoro fatto dalla gente di MWii che ha sviluppato una seriale (in poche righe) che regge senza scomporsi il GPS a 10 Hz e il collegamento ad una Ground Station Wreless ?

Altri su STM a 168 MHz non riescono a fare un I2C affidabile.

La IMU di MWii mi sembra andare bene anche in volo ed il confronto era per dire che con circa 1/4 dei calcoli è più precisa della usatissima DCM.

Ciao