MultiWii Quad! Alternativa ad Aeroquad/Baronpilot con sensori wii

[simone76]

solo questo fa capire cosa c'è dietro!

...algoritmi complessi senza bisogno di sbattersi per scriverli efficienti?

[biv2533]

quando avrai modo di riprovare prova un pò di pid tuning ed in particolare per il bmp085
P=2; I=0.02; D=20 o 30... fai dei test.
A presto

Non ricordo cosa avevo su quel mezzo ad ogni modo memorizzo a parto da li per il tuning

Gracias.

[tato-apprendista]

Secondo me eguagliare NAZA con il MULTIWII si può ...
E' il software del MULTIWII che va migliorato, per far questo innanzitutto andrebbe realizzata un po' di documentazione....

[Neo360]

ma perchè volare proprio sopra una strada, in FPV per giunta... testando dev non stabili e volo autonomo... mah

Perché ho la v2.1 ed è testata con decine di voli e sono sicuro che non ha problemi e poi dovevo riprendere mia mamma che si faceva la corsetta!!!

Tranquillo che so quel che faccio, non sono due giorni che volo in FPV.

[magnetron1]

...algoritmi complessi senza bisogno di sbattersi per scriverli efficienti?

Ma non direi così tanto complessi e neppure senza bisogno di sbattersi. Tieni conto che NAZA è un prodotto commerciale, vuol dire che dietro c'è gente che ci lavora a tempo pieno e sicuramente il team è unito, cosa che non accade nei progetti open-source condivisi da più persone che magari sono distanti e dall'altro capo del mondo, che non seguono una linea comune, che hanno esperienze diverse e approcci diversi. In un progetto close-source commerciale c'è una linea guida, un profondo debug, diversi professionisti che parlano tra di loro direttamente perchè direttamente sono nella stessa stanza e comunque sono guidati. Certo che con quel processore non si limitano a guardare il us di una istruzione che "perde" tempo... ma credo che comunque migliorando ed ottimizzando il software multiwii si possa portare a casa un risultato eccellente...

[TermicOne]

Michele ma non è che per caso è cambiato qualcosa nelle routine di gestione baro tra la 2.1 con imu magnetron-mahovik e la dev 1143? Ho la sensazione che volava meglio la 2.1 con le vostre mod rispetto alla attuale dev...ma potrei sbagliarmi....appena riesco provo a ricaricare il vecchio sw

Luciano

[simone76]

Certo che con quel processore non si limitano a guardare il us di una istruzione che "perde" tempo...

questo intendevo

Ma non direi così tanto complessi

onestamente non sarei così convinto che siano semplici quanto quelli delle FC basati su arduino. Se avessero scelto cotanto hardware per non sfruttarlo, il grandioso team di sviluppo che citi sarebbe una manica di cotiglioni, cosa che dubito. E comunque il risultato di altro livello è sotto gli occhi di tutti. In un precedente messaggio parlavo di controllo adattativo, per NAZA è un'ipotesi, mentre ho visto per certo che autoquad segue quella strada e il risultato è anche in quel video che hai postato tu. Vediamo le caratteristiche hardware: AutoQuad v6.6 Flight Controller Breaks New Ground » Odd Copter

STM32F4 168MHz processor

Che poi multiwii possa migliorare ancora, non ho dubbi. Che in quanto open source non possa fare meglio di un sistema chiuso anche (lo dici anche tu). Che Naza sia inarrivabile per multiwii pure. Quindi buon lavoro, se poi mi smentisci coi fatti tanto meglio.

[magnetron1]

Michele ma non è che per caso è cambiato qualcosa nelle routine di gestione baro tra la 2.1 con imu magnetron-mahovik e la dev 1143? Ho la sensazione che volava meglio la 2.1 con le vostre mod rispetto alla attuale dev...ma potrei sbagliarmi....appena riesco provo a ricaricare il vecchio sw

Luciano

Luciano non so, ma controllo...

[magnetron1]

questo intendevo




onestamente non sarei così convinto che siano semplici quanto quelli delle FC basati su arduino. Se avessero scelto cotanto hardware per non sfruttarlo, il grandioso team di sviluppo che citi sarebbe una manica di cotiglioni, cosa che dubito. E comunque il risultato di altro livello è sotto gli occhi di tutti. In un precedente messaggio parlavo di controllo adattativo, per NAZA è un'ipotesi, mentre ho visto per certo che autoquad segue quella strada e il risultato è anche in quel video che hai postato tu. Vediamo le caratteristiche hardware: AutoQuad v6.6 Flight Controller Breaks New Ground » Odd Copter

Che poi multiwii possa migliorare ancora, non ho dubbi. Che in quanto open source non possa fare meglio di un sistema chiuso anche (lo dici anche tu). Che Naza sia inarrivabile per multiwii pure. Quindi buon lavoro, se poi mi smentisci coi fatti tanto meglio.

E' evidente il divario.
Noi usiamo un Arduino (ATMega) che gira a 16MHz con 8-bit, naza usa un 32-bit a 180MHz e Autoquad gira a 168MHz a 32-bit... siamo su un livello completamente diverso. Ma credo che Arduino non abbia raggiunto il limite.
Che i sistemi open source non possono fare meglio di un close source non è vero, linux è un esempio ben evidente.
A te non devo dimostrare nulla, se non ti piace multiwii comprati un naza e buon divertimento, non è questo lo spirito giusto... anzi se dovessi scegliere io prenderei AutoQuad.
Naza non è inarrivabile.

[simone76]

E' evidente il divario.
Noi usiamo un Arduino (ATMega) che gira a 16MHz con 8-bit, naza usa un 32-bit a 180MHz e Autoquad gira a 168MHz a 32-bit... siamo su un livello completamente diverso. Ma credo che Arduino non abbia raggiunto il limite.
Che i sistemi open source non possono fare meglio di un close source non è vero, linux è un esempio ben evidente.
A te non devo dimostrare nulla, se non ti piace multiwii comprati un naza e buon divertimento, non è questo lo spirito giusto... anzi se dovessi scegliere io prenderei AutoQuad.
Naza non è inarrivabile.

Ma che permaloso, discutere obiettivamente ed approfondire i limiti della piattaforma, confrontandola con le altre, non significa denigrare ne il progetto ne chi ci lavora. Significa essere realistici su cosa ci si possa aspettare da un 328 o un mega 2650. Se ritieni che l'hardware su cui gira multiwii non sia un limite, beh lo spero, buon lavoro.

[magnetron1]

Ma che permaloso, discutere obiettivamente ed approfondire i limiti della piattaforma, confrontandola con le altre, non significa denigrare ne il progetto ne chi ci lavora. Significa essere realistici su cosa ci si possa aspettare da un 328 o un mega 2650. Se ritieni che l'hardware su cui gira multiwii non sia un limite, beh lo spero, buon lavoro.

No, tranquillo, dico solo che arduino ha ancora qualcosa da offrire... Vedremo.

[blackfede]

Ma che permaloso, discutere obiettivamente ed approfondire i limiti della piattaforma, confrontandola con le altre, non significa denigrare ne il progetto ne chi ci lavora. Significa essere realistici su cosa ci si possa aspettare da un 328 o un mega 2650. Se ritieni che l'hardware su cui gira multiwii non sia un limite, beh lo spero, buon lavoro.

Piu' che altro non c'e' in realta' questa grande differenza di costi. Nel senso, se a casa Naza utilizzano hardware piu' evoluto la ragione piu' semplice e' che costa pochissimo di piu' di quello meno evoluto e che non devi ottimizzare all'infinito per ottenere il medesimo risultato, risparmiando tempo, che e' la cosa piu' costosa. Se un processore atmega costa 4, il processore arm costa 6...

Detto questo, penso che multiwii giri su atmega perche' c'era il linguaggio di programmazione arduino che aiutava anche chi non era un programmatore vero, e che ora sia un po' complesso variare strada. Se il software venisse portato agilmente su una piattaforma con maggiore potenza di calcolo, e il costo rimanesse sostanzialmente invariato, nessuno se la prenderebbe a male.

Fede

[TermicOne]

Quelli suggeriti a Stefano erano per il BMP085.

Claustro, appena finisci le prove riportaci i risultati.
Fatti uno specchietto con i vari valori dei pid che provi ed i risultati che vedi.
In tutti i casi se fa jo-jo abbassa un po la P e anche la D e prova ad agire solo sulla D.
Per MS5611 la D puoi partire da 30...

Ma anche per questa versione vale la procedura di pid tuning del barometro: metti P e I a 0 - alza D fino a quando fa yoyo e poi abbassa - alza P fino a quando fa yoyo poi abbassa ecc.? Oppure c'é qualche altro metodo?

Io ho preso i valori di default e ho alzato D fino a quando faceva yoyo e poi ho abbassato per ridurre al minimo lo yoyo. Poi ho alzato P fino a quando lo yoyo é peggiorato e poi sono tornato indietro. Sono arrivato a 2 - 0,015 - 40

Ora se attivo Alt Hold quando il quad é bello stabile in quota allora tiene la quota bene....come il video di Steve e come nei miei video.
Se lo attivo in moto o se c'é un poco di vento allora inizia a fare yoyo. A volte lo yoyo in 3 o 4 ondulazioni si assesta a volte invece si amplia fino a quando non tocca terra.

Naturalmente mi sto divertendo con questo Alt Hold piú per sfizio, perché poi quando vado in giro in FPV a fare riprese alla fine volo solo in ACRO che é la modalitá che garantisce il volo meno disturbato e piú fluido senza traballamenti.

Luciano

[TermicOne]

Sul forum multiwii su consiglio di mahowik hanno messo l'imu.ino vecchio modificato da magnetron-mahowik sulla dev nuova e l'ALT Hold sembra andare meglio....boh...proveró anch'io....

Luciano

[TermicOne]

Sembra proprio che, rispetto alla imo.ino originale di magnetron-mahowik, ci sia un bug nella nuova dev relativamente alla gestione del barometro.

Mahowik lo ha rilevato e consiglia:

-----------
Try to comment applyDeadband(vel, 5)

      //D
      // applyDeadband(vel, 5);
      BaroPID -= constrain(conf.D8[PIDALT] * vel / 20, -150, 150);
      debug[3] = BaroPID;

In original version it was a function for deadband and "vel" variable in not overridden with deadband, but with define it's overridden! As result velocity integrator will re-zero in each iteration...
------------

Alexinparis ha riconosciuto il problema e lo sistema cosí:

------------

  float vel_tmp = vel;
  applyDeadband(vel_tmp, 5);
  BaroPID -= constrain(conf.D8[PIDALT] * vel_tmp / 20, -150, 150);

--------

http://www.multiwii.com/forum/viewto...?t=2371#p24276

Se anche magnetron ci dá la sua approvazione nel week end proveremo!

Luciano