MultiWii Quad! Alternativa ad Aeroquad/Baronpilot con sensori wii

[arnaldo]

Anche Alex ha la stessa "sensazione"

RC Groups - View Single Post - MultiWiiCopter (previously TriWiiCopter)


/Gianni

buone notizie vedo....

[albio]

Non usare il NK ma un altro ACC tipo BMA e vedrai che lo stable mode è molto meglio di quanto tu possa pensare (non che l'NK non funzioni, anzi..)


/Gianni

Ma io sono moooooolto tirchio, e ti dico la verità che non mi dispiace poi tanto di come lavora il NK.
Non mi serve per uso professionale, e lo stable mi serve perché i pollici sono ancora abbastanza acerbi, così mi cava d'impaccio in situazioni critiche.
Mi stuzzica l'idea di poterne migliorare il comportamento, dopo aver settato per bene tutto (vibrazioni, bilanciamenti, ecc.).

Starò a vedere, ma se c'è qualcuno che se la cava con il codice...

[jhoexp]

Non usare il NK ma un altro ACC tipo BMA e vedrai che lo stable mode è molto meglio di quanto tu possa pensare (non che l'NK non funzioni, anzi..)

Dipende da quello che lui stava pensando!!
Sarei curioso di vedere qualche video con lo stable mode, ma non solo di hovering, eh!
Se avete pilotato qualche altro mezzo con stable mode, è meglio che il multiwii non lo proviate neanche perchè non ci siamo ancora. Io ho provato col bma180 e col NK ma le differenze sono minime. Il codice è ancora troppo acerbo e non mi pare che stia cambiando l'approccio al problema.

Non crediate che cambiando l'accellerometro improvvisamente funzioni perchè non è così: la trimmatura separata per la modalità stabile è ininfluente e il delay di lettura del NK non è determinante, quello che va cambiato è tutto il controllo dell'accellerometro, con un nuovo filtro, un pid dedicato, ecc...

Se ci si accontenta di un mezzo che più o meno si autolivella quando è fermo o molto lento va bene, ma davvero non ne capisco quasi l'utilità, visto che la stabilità è già ottimale solo con i giroscopi.
Nel volato normale non è affatto affidabile e conviene usarlo solo settando basso l'autolevel strenght. Dopo un po' comunque fa casino e il mezzo diventa erratico....

Vedo che c'è molto hype dietro i sensori nuovi i2c ma occhio che non sono la panacea. Le prestazioni dei nuovi gyro e accell sono più o meno le stesse e la sostituzione del wmp e del nk è più che altro per motivi economici, per comodità e per eliminare tutti i dubbi sul funzionamento dei sensori che non erano nati per questo scopo. I miglioramenti si vedranno quando il codice cambierà e magari si useranno altri algoritmi di stabilizzazione...per ora non c'è quasi differenza nel volo.

[albio]

Dipende da quello che lui stava pensando!!
Sarei curioso di vedere qualche video con lo stable mode, ma non solo di hovering, eh!
Se avete pilotato qualche altro mezzo con stable mode, è meglio che il multiwii non lo proviate neanche perchè non ci siamo ancora. Io ho provato col bma180 e col NK ma le differenze sono minime. Il codice è ancora troppo acerbo e non mi pare che stia cambiando l'approccio al problema.

Non crediate che cambiando l'accellerometro improvvisamente funzioni perchè non è così: la trimmatura separata per la modalità stabile è ininfluente e il delay di lettura del NK non è determinante, quello che va cambiato è tutto il controllo dell'accellerometro, con un nuovo filtro, un pid dedicato, ecc...

Se ci si accontenta di un mezzo che più o meno si autolivella quando è fermo o molto lento va bene, ma davvero non ne capisco quasi l'utilità, visto che la stabilità è già ottimale solo con i giroscopi.
Nel volato normale non è affatto affidabile e conviene usarlo solo settando basso l'autolevel strenght. Dopo un po' comunque fa casino e il mezzo diventa erratico....

Vedo che c'è molto hype dietro i sensori nuovi i2c ma occhio che non sono la panacea. Le prestazioni dei nuovi gyro e accell sono più o meno le stesse e la sostituzione del wmp e del nk è più che altro per motivi economici, per comodità e per eliminare tutti i dubbi sul funzionamento dei sensori che non erano nati per questo scopo. I miglioramenti si vedranno quando il codice cambierà e magari si useranno altri algoritmi di stabilizzazione...per ora non c'è quasi differenza nel volo.

Stavo pensando a qualcosa che si possa settare nel caso sia troppo sensibile alle vibrazioni.

Concordo con te sul fatto che l'autolevel serva a ben poco allo stato attuale.
Il MIO problema, ripeto, sono i pollici, per cui avere un qualcosa che in caso di necessità mi riporti il quad "quasi orizzontale" mi dà quel minimo di sicurezza in più, che al momento mi serve come il pane.

Se non sbaglio Point65 su RCG aveva provato a leggere il NK direttamente con il bus I2C, senza passare dal WM+, ma non ho trovato molto.
Sarebbe interessante capire se ne ha cavato un ragno dal buco...

E mi piacerebbe anche capire come trimmare il modello per la modalità stabile senza doverlo ritrimmare quando la tolgo...
Per me sarebbe già molto...

Ciao
Alberto

[twobladez]

Dipende da quello che lui stava pensando!!
Sarei curioso di vedere qualche video con lo stable mode, ma non solo di hovering, eh!
Se avete pilotato qualche altro mezzo con stable mode, è meglio che il multiwii non lo proviate neanche perchè non ci siamo ancora. Io ho provato col bma180 e col NK ma le differenze sono minime. Il codice è ancora troppo acerbo e non mi pare che stia cambiando l'approccio al problema.

Non crediate che cambiando l'accellerometro improvvisamente funzioni perchè non è così: la trimmatura separata per la modalità stabile è ininfluente e il delay di lettura del NK non è determinante, quello che va cambiato è tutto il controllo dell'accellerometro, con un nuovo filtro, un pid dedicato, ecc...

Se ci si accontenta di un mezzo che più o meno si autolivella quando è fermo o molto lento va bene, ma davvero non ne capisco quasi l'utilità, visto che la stabilità è già ottimale solo con i giroscopi.
Nel volato normale non è affatto affidabile e conviene usarlo solo settando basso l'autolevel strenght. Dopo un po' comunque fa casino e il mezzo diventa erratico....

Vedo che c'è molto hype dietro i sensori nuovi i2c ma occhio che non sono la panacea. Le prestazioni dei nuovi gyro e accell sono più o meno le stesse e la sostituzione del wmp e del nk è più che altro per motivi economici, per comodità e per eliminare tutti i dubbi sul funzionamento dei sensori che non erano nati per questo scopo. I miglioramenti si vedranno quando il codice cambierà e magari si useranno altri algoritmi di stabilizzazione...per ora non c'è quasi differenza nel volo.

Jhoexp, qui si parla di MultiWii non di confronto fra MultiwWii e altre cose (imparagonabili IMHO sia per costo che per prestazioni)

Fatta questa doverosa precisazione la MultiWii è molto semplice, adatta ad un utente di tipo entry, loop di controllo semplice e facile da settare e, last but not least, costa pure poco.

Per il comportamento nei transitori, ancora non ho visto molto in rete di gente che riesce a spingere questi mezzi come si deve (leggi acro e/o utenti non professionali) ergo.... una piattaforma economica di tipo entry level, prestazioni (per la sua categoria) molto buone se non eccellenti, stable mode assolutamente decente per il tipo di utilizzo che se ne deve fare e per quello che gli utenti di questa tipo di piattaforma necessitano.

Per le differenze nel volo con tempi di loop differenti e fra stable e acro mode non sono cosi convinto come te ma questo è un altro discorso.

/Gianni

[twobladez]

Stavo pensando a qualcosa che si possa settare nel caso sia troppo sensibile alle vibrazioni.

Concordo con te sul fatto che l'autolevel serva a ben poco allo stato attuale.
Il MIO problema, ripeto, sono i pollici, per cui avere un qualcosa che in caso di necessità mi riporti il quad "quasi orizzontale" mi dà quel minimo di sicurezza in più, che al momento mi serve come il pane.

Se non sbaglio Point65 su RCG aveva provato a leggere il NK direttamente con il bus I2C, senza passare dal WM+, ma non ho trovato molto.
Sarebbe interessante capire se ne ha cavato un ragno dal buco...

E mi piacerebbe anche capire come trimmare il modello per la modalità stabile senza doverlo ritrimmare quando la tolgo...
Per me sarebbe già molto...

Ciao
Alberto

Usa i trim separati per le varie condizioni di volo ed il gioco è fatto.

/Gianni

[twobladez]

Stavo pensando a qualcosa che si possa settare nel caso sia troppo sensibile alle vibrazioni.

Concordo con te sul fatto che l'autolevel serva a ben poco allo stato attuale.
Il MIO problema, ripeto, sono i pollici, per cui avere un qualcosa che in caso di necessità mi riporti il quad "quasi orizzontale" mi dà quel minimo di sicurezza in più, che al momento mi serve come il pane.

Se non sbaglio Point65 su RCG aveva provato a leggere il NK direttamente con il bus I2C, senza passare dal WM+, ma non ho trovato molto.
Sarebbe interessante capire se ne ha cavato un ragno dal buco...

E mi piacerebbe anche capire come trimmare il modello per la modalità stabile senza doverlo ritrimmare quando la tolgo...
Per me sarebbe già molto...

Ciao
Alberto

Per la gestione dell'NK non in modalità slave occorre modificare la cirrcuiteria di contorno aggiungendo un paio di transistor/resistenze e modificare il codice di MWii per gestire il nuovo tipo di indirizzamento di WM+ e NK

Se cerchi un pò con google trovi sia lo schema di collegamento , molto semplice peraltro, ed alcuni esempi di codice di selezione/lettura di ACC e GYRO che dovrai implementare sul codice attuale di MWii

/Gianni

[albio]

Usa i trim separati per le varie condizioni di volo ed il gioco è fatto.

/Gianni

Capito, devo rileggermi il manuale della radio...

[jhoexp]

Jhoexp, qui si parla di MultiWii non di confronto fra MultiwWii e altre cose (imparagonabili IMHO sia per costo che per prestazioni)

Fatta questa doverosa precisazione la MultiWii è molto semplice, adatta ad un utente di tipo entry, loop di controllo semplice e facile da settare e, last but not least, costa pure poco.

Scusa ma lo stai spiegando a me cos'è la multiwii? Guarda che sono io che ho aperto il thread e che ho fatto conscere il progetto sul forum, lodandone la semplicità e l'immediatezza....

In questo thread ogni confronto con altre piattaforme è non solo gradito ma assolutamente incoraggiato!! Purchè ovviamente abbia un senso e sia fatto con criterio.
La bontà del progetto si misura anche con i progressi degli altri (specie quelli che usano piattaforme e sensori uguali o del tutto simili per prezzo/prestazioni/destinazione d'uso) e questo thread è assolutamente il posto giusto per farli.


Se aeroquad fa meglio, si prova aeroquad, se simplo/baronpilot fa le stesse cose, si prova e si compara....visto che anche mk usa micro avr, i confronti sono più che aperti.
Lo stable mode è lo stable mode. Che tu lo faccia con un Asctec o con un arduino saldato al volo è sempre lo stable mode. Non è questa cosa impossibile o miracolosa, nè è estremamente esosa di risorse computazionali o necessita di chissà che sensoristica.

Se lo stable mode non va ancora bene, se ci sono altre cose da migliorare non c'è bisogno di fare misteri, si dice le cose come stanno e si cerca le soluzioni. Io il multiwii l'ho scoperto sul forum aeroquad, tanto per dire!

Quindi inutile nasconderci, su alcune cose ci si deve lavorare sopra perchè per ora non ci siamo e basta poco per fare meglio.

Per il comportamento nei transitori, ancora non ho visto molto in rete di gente che riesce a spingere questi mezzi come si deve (leggi acro e/o utenti non professionali) ergo.... una piattaforma economica di tipo entry level, prestazioni (per la sua categoria) molto buone se non eccellenti, stable mode assolutamente decente per il tipo di utilizzo che se ne deve fare e per quello che gli utenti di questa tipo di piattaforma necessitano.

Non sono d'accordo, c'è molta gente che spinge a fondo i mezzi per quello (non molto a dire il vero) che possono dare. Io li massacro sempre con stalli e virate veloci, flip e anche lunghe discese rovesce, basta vedere i video o venire una volta al campo per rendersene conto di persona: YouTube - WiiQuad - Acro test (uno dei primissimi testa dell'anno scorso) e basta vedere uno dei bei video di Alex, Warthox & company per capire che si può massacrarli di g senza alcun problema.

Oltretutto sono manovre piuttosto semplici che qualsiasi elicotterista un minimo smaliziato è in grado di eseguire ad occhi chiusi. La tecnica (e poi il talento vero) lo si vedrà quando avremo macchine a passo variabile e si potrà fare un po' di 3d...

Purtroppo però lo stable mode non è affatto decente perchè se lo spingi un minimo non è più assolutamente affidabile e comunque non è soddisfacente quasi in nessuna condizione ... ma se hai un video o mi dimostri il contrario sono pronto a cambiare idea... per ora però, se tutti quelli che ci volano un minimo la pensano così....

Per le differenze nel volo con tempi di loop differenti e fra stable e acro mode non sono cosi convinto come te ma questo è un altro discorso.

Io mi riferivo alle differenze di volo tra wmp e itg3200. Con questo codice, praticamente non ci sono. Come non ci sono grandi differenze tra nk e altri accellerometri per lo stable mode. La velocità del loop di controllo farà la differenza quando ci saranno altri algoritmi...per ora è evidente che non cambia una mazza fare il ciclo a 3000 o 6000 nè spendere XXX euro in miracolosi aggeggi mems (che sono gli stessi che ci sono nelle patatine).

Se avete problemi col wmp è perchè avete qualche casino: magari il pid completamente cannato (e sono sicuro che troppa gente non ha mai neanche provato a modificarlo!) o perchè avete qualche altro problema sugli esc o avete fatto qualche mostruosità sul telaio.

Ben vengano i nuovi sensori, i nuovi micro e le nuove piattaforme, ma il codice deve evolversi con loro per poterli sfruttare davvero (leggi: si deve implementare la dcm, bisogna integrare le letture di più variabili per lo stesso controllo, ecc...)...per ora va bene così e quello che c'è ci consente di volare allegramente senza grandi pretese, ma il mio invito e anche l'obbiettivo di questa discussione è e sarà sempre quello di NON ACCONTENTARSI e di cercare di ottenere sempre il meglio possibile con gli strumenti a disposizione, con semplicità e immediatezza. Quindi è meglio essere obbiettibi e guardarsi in giro...

[jhoexp]

Concordo con te sul fatto che l'autolevel serva a ben poco allo stato attuale.
Il MIO problema, ripeto, sono i pollici, per cui avere un qualcosa che in caso di necessità mi riporti il quad "quasi orizzontale" mi dà quel minimo di sicurezza in più, che al momento mi serve come il pane.

E' perchè lo usi solo quando sei molto lento o quasi fermo. Se lo usi per un po' di volato vedi che ti passa la voglia di attivarlo...

Se non sbaglio Point65 su RCG aveva provato a leggere il NK direttamente con il bus
E mi piacerebbe anche capire come trimmare il modello per la modalità stabile senza doverlo ritrimmare quando la tolgo...
Per me sarebbe già molto...

Se hai una radio non proprio base basta attivare le modalità di volo con lo stesso switch dello stable mode. Naturalmente dovrai abilitare i trim separati (e non quelli "grouped" se sei familiare con la logica futaba) quando sei nella modalità "stabile". E' già qualcosa, ma il problema vero rimane...

[twobladez]

Scusa ma lo stai spiegando a me cos'è la multiwii? Guarda che sono io che ho aperto il thread e che ho fatto conscere il progetto sul forum, lodandone la semplicità e l'immediatezza....

In questo thread ogni confronto con altre piattaforme è non solo gradito ma assolutamente incoraggiato!! Purchè ovviamente abbia un senso e sia fatto con criterio.
La bontà del progetto si misura anche con i progressi degli altri (specie quelli che usano piattaforme e sensori uguali o del tutto simili per prezzo/prestazioni/destinazione d'uso) e questo thread è assolutamente il posto giusto per farli.


Se aeroquad fa meglio, si prova aeroquad, se simplo/baronpilot fa le stesse cose, si prova e si compara....visto che anche mk usa micro avr, i confronti sono più che aperti.
Lo stable mode è lo stable mode. Che tu lo faccia con un Asctec o con un arduino saldato al volo è sempre lo stable mode. Non è questa cosa impossibile o miracolosa, nè è estremamente esosa di risorse computazionali o necessita di chissà che sensoristica.

Se lo stable mode non va ancora bene, se ci sono altre cose da migliorare non c'è bisogno di fare misteri, si dice le cose come stanno e si cerca le soluzioni. Io il multiwii l'ho scoperto sul forum aeroquad, tanto per dire!

Quindi inutile nasconderci, su alcune cose ci si deve lavorare sopra perchè per ora non ci siamo e basta poco per fare meglio.



Non sono d'accordo, c'è molta gente che spinge a fondo i mezzi per quello (non molto a dire il vero) che possono dare. Io li massacro sempre con stalli e virate veloci, flip e anche lunghe discese rovesce, basta vedere i video o venire una volta al campo per rendersene conto di persona: YouTube - WiiQuad - Acro test (uno dei primissimi testa dell'anno scorso) e basta vedere uno dei bei video di Alex, Warthox & company per capire che si può massacrarli di g senza alcun problema.

Oltretutto sono manovre piuttosto semplici che qualsiasi elicotterista un minimo smaliziato è in grado di eseguire ad occhi chiusi. La tecnica (e poi il talento vero) lo si vedrà quando avremo macchine a passo variabile e si potrà fare un po' di 3d...

Purtroppo però lo stable mode non è affatto decente perchè se lo spingi un minimo non è più assolutamente affidabile e comunque non è soddisfacente quasi in nessuna condizione ... ma se hai un video o mi dimostri il contrario sono pronto a cambiare idea... per ora però, se tutti quelli che ci volano un minimo la pensano così....



Io mi riferivo alle differenze di volo tra wmp e itg3200. Con questo codice, praticamente non ci sono. Come non ci sono grandi differenze tra nk e altri accellerometri per lo stable mode. La velocità del loop di controllo farà la differenza quando ci saranno altri algoritmi...per ora è evidente che non cambia una mazza fare il ciclo a 3000 o 6000 nè spendere XXX euro in miracolosi aggeggi mems (che sono gli stessi che ci sono nelle patatine).

Se avete problemi col wmp è perchè avete qualche casino: magari il pid completamente cannato (e sono sicuro che troppa gente non ha mai neanche provato a modificarlo!) o perchè avete qualche altro problema sugli esc o avete fatto qualche mostruosità sul telaio.

Ben vengano i nuovi sensori, i nuovi micro e le nuove piattaforme, ma il codice deve evolversi con loro per poterli sfruttare davvero (leggi: si deve implementare la dcm, bisogna integrare le letture di più variabili per lo stesso controllo, ecc...)...per ora va bene così e quello che c'è ci consente di volare allegramente senza grandi pretese, ma il mio invito e anche l'obbiettivo di questa discussione è e sarà sempre quello di NON ACCONTENTARSI e di cercare di ottenere sempre il meglio possibile con gli strumenti a disposizione, con semplicità e immediatezza. Quindi è meglio essere obbiettibi e guardarsi in giro...

Tranquillo Jhoexp, ho semplicemente pareri leggermente differenti dai tuoi e sulla tua visone, sempre a mio parere, su alcuni aspetti un pò troppo un pò troppo semplicistica. Tutto qui.

/Gianni

[jhoexp]

Tranquillo Jhoexp, ho semplicemente pareri leggermente differenti dai tuoi e sulla tua visone, sempre a mio parere, su alcuni aspetti un pò troppo un pò troppo semplicistica. Tutto qui.

/Gianni

Di grazia quale sarebbe la mia visione semplicistica e su cosa? Qui si discute e ci si confronta. I pareri si devono sostenere con argomentazioni e prove.

Perchè credi che il thread e il progetto abbia avuto successo? Perchè abbiamo dimostrato che funziona, per quel poco che fa.

Ho visto che hai a cuore il progetto e ne hai spesso preso le parti quando "i soliti" intervengono solo per denigrare senza alcun criterio, senza conoscere gli obbiettivi e l'approccio dell progetto multiwii... e per questo ti ringrazio, ma attento a non cadere nella stessa trappola!

Cerchiamo di rimanere obbiettivi e di non farci illusioni, se altri progetti paragonabili (aeroquad, baronpilot, ardupilot), che hanno un approccio migliore e più evoluto con lo stable mode, ottengono risultati migliori, è inutile nasconderlo.

Se uno ricerca altre cose oltre al volo puramente giroscopico, è meglio essere chiari: guarda anche altro, perchè per ora il multiwii è limitato a questo.

Quello che è stato fatto fino ad ora bisogna darlo per scontato. C'è ancora qualche dettaglio di contorno da rifinire ma la base c'è e funziona. Adesso ci sono tante alternative a basso costo e con grandi performance. Se le vogliamo sfruttare sul serio per migliorare la piattaforma il codice deve cambiare.
Gattopardianamente parlando "tutto deve cambiare perchè tutto rimanga uguale".

[twobladez]

Di grazia quale sarebbe la mia visione semplicistica e su cosa? Qui si discute e ci si confronta. I pareri si devono sostenere con argomentazioni e prove.

Perchè credi che il thread e il progetto abbia avuto successo? Perchè abbiamo dimostrato che funziona, per quel poco che fa.

Ho visto che hai a cuore il progetto e ne hai spesso preso le parti quando "i soliti" intervengono solo per denigrare senza alcun criterio, senza conoscere gli obbiettivi e l'approccio dell progetto multiwii... e per questo ti ringrazio, ma attento a non cadere nella stessa trappola!

Cerchiamo di rimanere obbiettivi e di non farci illusioni, se altri progetti paragonabili (aeroquad, baronpilot, ardupilot), che hanno un approccio migliore e più evoluto con lo stable mode, ottengono risultati migliori, è inutile nasconderlo.

Se uno ricerca altre cose oltre al volo puramente giroscopico, è meglio essere chiari: guarda anche altro, perchè per ora il multiwii è limitato a questo.

Quello che è stato fatto fino ad ora bisogna darlo per scontato. C'è ancora qualche dettaglio di contorno da rifinire ma la base c'è e funziona. Adesso ci sono tante alternative a basso costo e con grandi performance. Se le vogliamo sfruttare sul serio per migliorare la piattaforma il codice deve cambiare.
Gattopardianamente parlando "tutto deve cambiare perchè tutto rimanga uguale".

Jhoexp, io non stò mettendo in dubbio nulla (e probabilmente diciamo le stesse cose ma in modo diverso), dico solo che le cose vanno confrontate ed analizzate per quello che sono e per l'utilizzo che se ne vuole fare.

IMHO la MultiWii è ottima GIA ALLO STATO ATTUALE soprattutto per l'utenza a cui è destinata.
Il progetto MWii è molto giovane ed ha raggiunto livelli di penetrazione e performance , ripeto per il target di utilizzatori a cui è destinata, stellari.
Qui il problema non è lo stable mode (e tu sai meglio di mè che non si può generalizzare scrivendo che lo stable mode è lo stable mode è basta ) ma è altro.
Avrai visto che la stragrande maggioranza degli utenti ha i seguenti tipi di problemi non dipendenti dal tipo di piattaforma (basta farsi un giro e leggere)

Saldatore
Vibrazioni
Collegamenti
Programmazione TX
Programmazione micro
Setup PID
Pollici

e ne ho citati solo alcuni!!

Pochi, molto pochi riescono a tirare fuori il meglio da tutto il complesso e arrivare al limite della piattaforma (tenendo sempre conto del target di utilizzatori a cui è destinata) la vedo dura, molto dura.
Quindi ben vengano le ulteriori modifiche, aggiornamenti, migliorie e quant'altro ma già al punto in cui siamo, se opportunamente gestita nel complesso, la piattaforma è più che soddisfacente.
Io sono il primo a non accontentarsi, ma questo non vuol dire che tutto il lavoro lo deve fare la MWii, soprattutto quando se ne conoscono le caratteristiche e/o i limiti!!!!
Molti problemi (di base e non) si possono risolvere utilizzando al meglio TUTTO quello che c'è intorno, pollici compresi, prima di scomodare nuovi sensori, nuovi algoritimi e quant'altro.
Ben vengano i confronti, ma vanno sempre fatti osservando il panorama dall'alto, in modo da avere una visuale generale più chiara e rapportati sempre al target di utilizzatori.
Non sempre più nuovo/costoso/complesso è sinonimo di migliore ma la scelta dipende da altri fattori, probabilmente nel complesso , IMHO, più importanti.


/Gianni

[jhoexp]

Gianni, dici un sacco di cose sacrosante che per altro sono esattamente le stesse che ho detto io 6 mesi fa nel primo post del thread.

Sullo stable mode però ti sbagli. Un po' di esperienza ce l'ho con diversi mezzi/codice e il polso della situazione e di quello che vuole la gente ce l'ho. Mi spiace ma lo stable mode è lo stable mode.
Non è generalizzare, è una constatazione. E' una cosa normale integrare gli accellerometri e deve funzionare.
O il mezzo si autolivella e lo fa in maniera ripetibile e affidabile oppure lo stable mode non funziona.

Per farlo andare, non si fa come vuole fare lui. Visto che altri progetti sono arrivati a risultati migliori bisogna ripartire da lì, non continuare a cambiare due virgole che non fanno la differenza. (perchè questo ha fatto, non ha cambiato mai niente di fatto!)

... si pensava fosse colpa del NK, ma non lo è. Anche se gli accellerometri non prendono rumore non funziona bene e non lo si può far funzionare decentemente nel modo in cui è implementato ora, altro che trim, è da riscrivere con un pid dedicato, ecc... o meglio iniziamo a copiarlo dagli altri... poi vediamo.

Non cambia niente se lo deve usare un niubbo assoluto o un elicotterista del 3d master.

Il primo magari non se ne accorge perchè ci fa solo hovering ma non è un motivo valido per dire che funziona. Anzi, senza va meglio, ed è altrettanto facile ed amichevole da usare, oltre che sicuramente più educativo per un principiante.

La parte difficile è farglielo capire, perchè purtroppo pochi imparano con metodo o si applicano un po' prima col simulatore, ma questo non è un problema della piattaforma ma dell'approccio del modellista.

Pochi, molto pochi riescono a tirare fuori il meglio da tutto il complesso e arrivare al limite della piattaforma (tenendo sempre conto del target di utilizzatori a cui è destinata) la vedo dura, molto dura.

Questa è una cosa su cui sbagli, la piattaforma è facilissima e basta un minimo di esperienza per sfruttarla al massimo e vederne tutti i limiti.
Se non ci sei ancora arrivato è solo questione di pratica ma fidati che è davvero poca cosa. Assolutamente imparagonabile anche ad un semplicissimo volo acrobatico con un elicottero a passo variabile.
Il target è limitato perchè siamo solo all'inizio e il mezzo attira solo i principianti, ma le cose cambieranno (vedi Brizzi). I "big" del mio campo sono impegnati in altro ma vedrai che anche loro si faranno il quadri scemo per divertirsi senza pensieri... (Seba sei in ascolto?? )

Non prendere ad esempio i risultati di chi è principiante e ha troppa poca esperienza. Non fa testo.... per vedere se una cosa funziona, vai a vedere chi vola.

E' una delle cose che più limita lo sviluppo di questi mezzi, chi scrive il codice non sa volare e chi sa volare lo fa con mezzi più appaganti o non è in grado di aiutare chi scrive il codice. Multiwii è nata bene perchè chi l'ha fatta ci volava e aveva le idee chiare, ma per ora si è fermata lì.

Io sono il primo a non accontentarsi, ma questo non vuol dire che tutto il lavoro lo deve fare la MWii, soprattutto quando se ne conoscono le caratteristiche e/o i limiti!!!!
Molti problemi (di base e non) si possono risolvere utilizzando al meglio TUTTO quello che c'è intorno, pollici compresi, prima di scomodare nuovi sensori, nuovi algoritimi e quant'altro.

Scusa ma che vuol dire "tutto il lavoro lo deve fare la multiwii" Dai questa è una battuta da bar, poi sarei io quello con la visione semplicistica?

Spero che ormai la gente abbia capito come fare un telaio decente e sistemare il mezzo elettricamente (è sufficiente non inventarsi nuove stramberie e almeno per i primi mezzi riprodurre quello che hanno fatto gli altri).
Quindi ottimizzare quello che c'è intorno vuol dire scrivere nuovo codice e utilizzare nuovi algoritmi. Lascia stare i pollici che specie con lo stable mode non centrano nulla.

Non sempre più nuovo/costoso/complesso è sinonimo di migliore ma la scelta dipende da altri fattori, probabilmente nel complesso , IMHO, più importanti.

Sul fatto che nuovo/cari non sia sinonimo di migliore mi sembra che l'abbiamo ormai dimostrato, ma lì ci siamo fermati. Quindi vogliamo arrivare ad una conclusione? Quali sarebbero gli altri fattori importanti se abbiamo ottimizzato già costo/complessità/immediatezza?

Io non vedo molto altro, rimane solo di riscrivere seriamente alcune routine guardando quello che hanno fatto gli altri con gli stessi mezzi. E questo richiede un cambio di approccio e smettere di impuntarsi su certe cose come hanno fatto finora.

Danveal e gli altri non hanno capito lo spirito del progetto e sbagliano su molte cose, ma su altre hanno ragione. Se non lo riconosciamo non andiamo avanti...

[twobladez]

Gianni, dici un sacco di cose sacrosante che per altro sono esattamente le stesse che ho detto io 6 mesi fa nel primo post del thread.

Sullo stable mode però ti sbagli. Un po' di esperienza ce l'ho con diversi mezzi/codice e il polso della situazione e di quello che vuole la gente ce l'ho. Mi spiace ma lo stable mode è lo stable mode.
Non è generalizzare, è una constatazione. E' una cosa normale integrare gli accellerometri e deve funzionare.
O il mezzo si autolivella e lo fa in maniera ripetibile e affidabile oppure lo stable mode non funziona.

Per farlo andare, non si fa come vuole fare lui. Visto che altri progetti sono arrivati a risultati migliori bisogna ripartire da lì, non continuare a cambiare due virgole che non fanno la differenza. (perchè questo ha fatto, non ha cambiato mai niente di fatto!)

... si pensava fosse colpa del NK, ma non lo è. Anche se gli accellerometri non prendono rumore non funziona bene e non lo si può far funzionare decentemente nel modo in cui è implementato ora, altro che trim, è da riscrivere con un pid dedicato, ecc... o meglio iniziamo a copiarlo dagli altri... poi vediamo.

Non cambia niente se lo deve usare un niubbo assoluto o un elicotterista del 3d master.

Il primo magari non se ne accorge perchè ci fa solo hovering ma non è un motivo valido per dire che funziona. Anzi, senza va meglio, ed è altrettanto facile ed amichevole da usare, oltre che sicuramente più educativo per un principiante.

La parte difficile è farglielo capire, perchè purtroppo pochi imparano con metodo o si applicano un po' prima col simulatore, ma questo non è un problema della piattaforma ma dell'approccio del modellista.



Questa è una cosa su cui sbagli, la piattaforma è facilissima e basta un minimo di esperienza per sfruttarla al massimo e vederne tutti i limiti.
Se non ci sei ancora arrivato è solo questione di pratica ma fidati che è davvero poca cosa. Assolutamente imparagonabile anche ad un semplicissimo volo acrobatico con un elicottero a passo variabile.
Il target è limitato perchè siamo solo all'inizio e il mezzo attira solo i principianti, ma le cose cambieranno (vedi Brizzi). I "big" del mio campo sono impegnati in altro ma vedrai che anche loro si faranno il quadri scemo per divertirsi senza pensieri... (Seba sei in ascolto?? )

Non prendere ad esempio i risultati di chi è principiante e ha troppa poca esperienza. Non fa testo.... per vedere se una cosa funziona, vai a vedere chi vola.

E' una delle cose che più limita lo sviluppo di questi mezzi, chi scrive il codice non sa volare e chi sa volare lo fa con mezzi più appaganti o non è in grado di aiutare chi scrive il codice. Multiwii è nata bene perchè chi l'ha fatta ci volava e aveva le idee chiare, ma per ora si è fermata lì.




Scusa ma che vuol dire "tutto il lavoro lo deve fare la multiwii" Dai questa è una battuta da bar, poi sarei io quello con la visione semplicistica?

Spero che ormai la gente abbia capito come fare un telaio decente e sistemare il mezzo elettricamente (è sufficiente non inventarsi nuove stramberie e almeno per i primi mezzi riprodurre quello che hanno fatto gli altri).
Quindi ottimizzare quello che c'è intorno vuol dire scrivere nuovo codice e utilizzare nuovi algoritmi. Lascia stare i pollici che specie con lo stable mode non centrano nulla.



Sul fatto che nuovo/cari non sia sinonimo di migliore mi sembra che l'abbiamo ormai dimostrato, ma lì ci siamo fermati. Quindi vogliamo arrivare ad una conclusione? Quali sarebbero gli altri fattori importanti se abbiamo ottimizzato già costo/complessità/immediatezza?

Io non vedo molto altro, rimane solo di riscrivere seriamente alcune routine guardando quello che hanno fatto gli altri con gli stessi mezzi. E questo richiede un cambio di approccio e smettere di impuntarsi su certe cose come hanno fatto finora.

Danveal e gli altri non hanno capito lo spirito del progetto e sbagliano su molte cose, ma su altre hanno ragione. Se non lo riconosciamo non andiamo avanti...

Johexp, vediamo semplicimente la cosa da due punti di vista differenti.
Io probabilmente chiuderei lo sviluppo di MWii che sò, alla prossima versione 1.7 con eventuale affinamento dei dettagli e concentrerei gli sforzi invece sulla MWii v2.0 o MWii NG, con altre caratteristiche ed altri , ovviamente, obiettivi (E' solo un esempio naturalmente)
Ripeto, visione differente dello stesso panorama.
Tu vai giù piatto sul target mentre io invece preferisco una segmentazione dello stesso.

Tutto qua.

/Gianni