Okto con APM 2650, configurazione: che ne dite?

[Bobo67]

Scusami, per la resistenza da 1K ne discutono qui, per proteggere in qualche modo l'esc buono se l'altro si fuma e per qualche motivo manda una tensione sul pwm (cosa abbastanza impossibile, ma non improbabile):

Arducopter with 8 motors - First aerial photos - DIY Drones

Se hai un'altra idea son pronto a valutarla, considerando che agli esc va un segnale a 400 Hz (non so se l'APM sopporta anche i 500, ma questi esc si, già testati con l'afroi2c).
Se nel calc invece di 7 Kg provi a metterne 13, che è il peso ipotetico del drone completo con una cam da 6 Kg a bordo, guarda il risultato, 7:45 minuti di volo, 8.56A di corrente per ogni motore (in hovering ovviamente).

[Bobo67]

Si certo, ma 6 Kg di cam, tipo una Red, ci starebbe (in teoria)...
Poi ovvio, vatti a fidare a portar su qualche decina di migliaia di € di cam con un drone del genere...
Ma non è impossibile!
Giuro, piuttosto che un mega eli (coi Trex non si fa una cippa per pesi così importanti, e poi comunque non mi fiderei) opterei per una soluzione del genere, ovviamente per star "sicuri torre MK".
Quando parlo di "20 miuti" son calcolati cui 7Kg, ed i 10 restanti sono "ipotetici", ovvio che più vai su col peso più i consumi aumentano esponenzialmente.
Basta guardare il copterone che hanno fatto per portar su uno che peserà che ne so, 75 Kg?
Quanti motori e lipo hanno usato? Troppi!
Salendo col peso si hanno "purtroppo non linearmente" sempre meno prestazioni, ma è a 6/7 Kg di payload il mio punto d'arrivo.

[jhoexp]

I 7 Kg son calcolati pessimisticamente, considerando 4 lipo da 5000 4s, il peso aggiuntivo dei motori, esc ed anche un'APM+ rx a parte...
Togli un 15% di resa per il coax, e metti pure che i motori vadano a 5/6A... guarda sotto il payload...

Occhio che nel calcolo vedo le 13x6.5 sf, ma queste non esistono in versione slow fly, per avere la coppia cw/ccw devi prendere le thin electric che sono molto più piccole e hanno più meno l'efficienza delle 12x3.8
La perdita del coassiale è il 15% nelle migliori condizioni...per macchine così grosse vedrai anche perdite più alte. (molto più alte man mano che la spinta necessaria sale)
Il vantaggio in peso del coassiale è ridicolo, rispetto alla perdita di spinta e non compensa quasi nulla, anzi ti obbliga spesso ad usare un braccio di sezione maggiore, con ulterire perdita di spinta.
Con un braccio da 15mm perdi oltre il 5% rispetto ad uno da 10mm, con configurazioni leggere! (testato personalmente al banco e su diversi mezzi)
Con mezzi grandi e spinte maggiori saresti sicuramente messo anche peggio...

Insomma, togli qui, togli la, a pieno carico ti sei mangiato come minimo 1/4 dell'autonomia, rispetto ad una configurazione radiale...

I pesi che ipotizzi sono eccessivi e usare un multirotore è sconveniente. Oltretutto non vedo quali vantaggi residui avresti, visto che costi, sicurezza e ingombri sono del tutto paragonabili agli elicotteri, se non peggio sotto molto aspetti.
Ovviamente mi riferisco ad elicotteri che nascono per fare questo lavoro che ti garantiscono prestazioni molto superiori e autonomie degne, non certo basate su meccaniche align...

[jhoexp]

Basta guardare il copterone che hanno fatto per portar su uno che peserà che ne so, 75 Kg?
Quanti motori e lipo hanno usato? Troppi!

Ne tiri su facilmente il doppio con la metà dei motori, ma il problema è sempre lo stesso: il tempo! Il mezzo dei tedeschi non ha alcun futuro e non lo avrà mai, perchè già così ridotto all'osso ha rendimento troppo basso.
Questi mezzi non scalano come gli elicotteri, puoi montare anche 300 motori leggerissimi ed efficientissimi ma tanto la superficie totale che genera spinta è sempre molto inferiore a quella di un solo unico rotore e più sali con le dimensioni più i rendimenti globali peggiorano.

ma è a 6/7 Kg di payload il mio punto d'arrivo.

Sono irraggiungibili con autonomie decenti.

[redfox74]

Ne tiri su facilmente il doppio con la metà dei motori, ma il problema è sempre lo stesso: il tempo! Il mezzo dei tedeschi non ha alcun futuro e non lo avrà mai, perchè già così ridotto all'osso ha rendimento troppo basso.
Questi mezzi non scalano come gli elicotteri, puoi montare anche 300 motori leggerissimi ed efficientissimi ma tanto la superficie totale che genera spinta è sempre molto inferiore a quella di un solo unico rotore e più sali con le dimensioni più i rendimenti globali peggiorano.



Sono irraggiungibili con autonomie decenti.

Non mi sembra tanto uno scherzo ... Noi ne abbiamo lì due che non fanno niente da mesi...
Il progetto procede lentamente, chi ha esigenze lavorative non credo possa aspettare. Io (e il mio socio) abbiamo dedicato tempo e soldi alla cosa ma siamo molto delusi...magari arriverà ad un buon livello, ma per ora siamo distanti e le sperimentazioni non sembrano andare nella direzione voluta.

Ciao Jhoexp,
la mia posizione sull'uso di Arducopter per usi professionali l'ho gia' espressa .
La mia posizione rispetto ad Arducopter32 ovviamente e' totalmente diversa non confondiamo le cose . Dall'esperienza che mi sono fatto negli ultimi 4 anni prima da semplice utilizzatore di Mikrookopter , poi da sviluppatore di Multipilot8 e alla fine di MP32 con Arducopter32 quello che posso dire è che quanto sta' dando questo progetto a tutti gli appassionati di queste fantastiche macchine non ha paragone con quello che invece non ci sta' dando Mikrokopter.
Puntualizzo meglio la cosa ed il punto di vista . Se sono un utente finale con scarse capacita' se non nulle di sviluppo , probabilmente mi oriento su una piattaforma finita e chiusa come puo' essere Mikrokopter , pensando forse in modo non totalmente esatto che sicuramente l'oggetto fara' quello che mi serve e non mi pongo alcun problema dei limiti tecnologici che limitano di fatto la qualita' del funzionament dell'oggetto , non vado oltre perche' se no scrivo un Poema.
Chi abbraccia invece la filosofia di Arducopter , lo stesso discorso vale per MultiWii , la abbraccia perche' vuole imparare in modo profondo qualcosa in piu' di questi sistemi , la piattaforma e' opensource al 100 % qundi se ti vuoi studiare in modo approfondito come funziona la waypoint navigation o la modalita' simple lo puoi fare .
E se sei capace puoi anche apportare modifiche e miglioramenti e pian piano il progetto evolve .
Stiamo parlando di modellismo con componenti di robotica che fanno accrescere il valore di quanto hai per le mani. Parliamo del gusto di sperimentare nuove soluzioni e di farle valore una volta probabilmente era tutto piu' semplice e' vero , ma oggi le potenzialita' con questi nuovi oggetti sono pressoche' infinite.
Il discorso che stai facendo tu invece e' di tipo commerciale , devo fare un servizio , farlo bene e non mi è sufficiente la piattaforma per lavorare perche' di fatto ha limiti oggettivi che non mi consentono di usarla.
Forse il nostro amico che ha aperto questo post , sta curiosando dentro per capirci qualcosa di piu' per spingere oltre ai limiti imposti da piattaforme chiuse una macchina , un prototipo che in realta' gli consente di provare cose che con MK oggettivamente non puoi' fare . Penso ci siamo passati tutti prima o poi.
Per quanto riguarda l'impiego dei quad per riprese aeree rispetto ad MK , io non mi sono sentito mancare le funzioni automatiche RTL - GPS hold , ma l'ergonomia dell'uso dato ad esempio da un OSD piuttosto che dalla telemetria su JETI.
Quella e' una carenza che Arducopoter / Arducopter32 avevano e ora non hanno piu' e tra un po' vi mostrero' il perche' lo sto' dicendo .
Quindi se si cambia prospettiva vedrai che quanto ti da un Arducopter , se sei capace di capirlo nel profondo e'10'000 volte meglio di un Mikrokopter.
Chiusa questa parentesi voglio dire che pero' dal punto di vista professionale non e' nemmeno l'mk l'oggetto giusto' per problemi piu' che di tipo tecnico di tipo normativo e di omologazione . Dall'anno prossimo entrera' in vigore la normativa AERP che imporra' dei vincoli a chi vorra' lavorare con oggetti di questo genere e MK non li rispetta come nemmeno il 99.9 % degli oggetti presenti oggi sul mercato se lo si intende per usi professionali. Quindi quello che bisogna fare oggi in prospettiva commerciale e' lavorare nell'ottica della normativa in arrivo su questi oggeti.
Il vero problema di oggi e' secondo me la leggerezza con cui si affronta l'uso di questi oggetti in certi ambiti . Pensando di avere sempre la fortuna dalla nostra.
Un saluto a tutti e buone sperimentazioni a tutti
Per quanto riguarda Pesi , efficienza tempo di volo Jhoe sposo tutto quello che hai detto , in merito al discorso del Quad a passo variabile che ho contribuito a realizzare con Pippo , in realta' e' uno scenario che potrebbe dare diverse sorprese se unito all'approccio ibrido.
Saluti
Roberto

P.S.
sul fatto che autonomie di quel genere siano irraggiungibili io ho partecipato ad una demo di un nostro oggetto con delle batterie particolari dove abbiamo fatto 40 min di volo Non posso dire altro ....
L'unico problema e' che alla fine del test del prototipo di batteria si e' incendiata ... ci vorra' ancora qualche mese per stabilizzare questo tipo di tecnologia , ma forse tra un poco ci siamo

[Bobo67]

Grazie Jo per le preziose considerazioni, ed anche a tutti gli altri... provo l'okto intanto, poi vedrò.
Ci sarebbe da discutere per migliaia di post sulla questione "lavoro o svago", ritengo che se uno riesce a raggiungere risultati accettabili per quel che vuol fare ha già fatto 13.
Essendo smanettone da sempre MK mi piace poco perchè è molto blindato, anche se indiscutibilmente affidabile, Roberto ci ha visto lavorare in condizioni abbastanza problematiche (sotto i fili dell'alta tensione, sfiorando un capannone dove ci passano sopra, passandoci in mezzo ovviamente) ed MK non ha fatto una piega.

[redfox74]

Grazie Jo per le preziose considerazioni, ed anche a tutti gli altri... provo l'okto intanto, poi vedrò.
Ci sarebbe da discutere per migliaia di post sulla questione "lavoro o svago", ritengo che se uno riesce a raggiungere risultati accettabili per quel che vuol fare ha già fatto 13.
Essendo smanettone da sempre MK mi piace poco perchè è molto blindato, anche se indiscutibilmente affidabile, Roberto ci ha visto lavorare in condizioni abbastanza problematiche (sotto i fili dell'alta tensione, sfiorando un capannone dove ci passano sopra, passandoci in mezzo ovviamente) ed MK non ha fatto una piega.

Si Decisamente vi ho visti lavorare in un modo molto professionale ,
mi e' piaciuto da un lato il comportamento di MK che oggi ha decisamente raggiunto una maturita' notevole , ma piu' che altro la ground station con epi e la telemetria su Jeti secondo me sono il vero valore aggiunto che ti da' la possibilita' di poter comprendere come verra' il girato e avere tutti i parametri sotto controllo.
Sul tema della sicurezza invece avendo o no un MK io in quella condizione non avrei volato. Quella e' una questione di scelta e di valutazione del rischio.
Troppe macchine che giravano libere sulla strada tra il campo e il capannone. Non e' un ambiente che ritegno idoneo ad un volo in sicurezza ! Poi che l'oggetto si sia comportato bene quello e' vero , ma non mi basta.

Saluti
Roberto

[danveal]

ed MK non ha fatto una piega.

Beh anche quando lo usava Roberto l' MK non faceva una piega, infatti cadeva come un ferro da stiro

Roberto che sarebbe la normativa AERP, qualche link?

[Bobo67]

Roberto, ma che stai adddì!!!??
Nel filmato che hai fatto a Bergamo voli sopra le persone in riva ad un lago!!!
O mi sbaglio?
Io in quelle condizioni non avrei girato assolutamente!
Dove ci hai visti lavorare, mal che andasse, avrebbe cozzato su oggetti...
Poi sappiamo benissimo entrambi che puoi prendere tutte le precauzioni possibili inimmaginabili ed alla fine passa uno stormo di cormorani e ti abbatte il drone, oppure impazzisce l'elettronica e te lo trovi ad 1 Km nella boscaglia (se va bene)!
Io sono uno di quelli che il fail safe lo testa spegnendo la radio col drone in volo...

@danveal: LOLLISSIMOOooo!

[jhoexp]

Chi abbraccia invece la filosofia di Arducopter , lo stesso discorso vale per MultiWii , la abbraccia perche' vuole imparare in modo profondo qualcosa in piu' di questi sistemi , la piattaforma e' opensource al 100 % qundi se ti vuoi studiare in modo approfondito come funziona la waypoint navigation o la modalita' simple lo puoi fare .

Non è del tutto vero perchè il progetto Arducopter si pone in maniera diversa, volendo colmare quel gap che c'è tra il progetto amatoriale senza alcuna pretesa (come multiwii) ed MK. Arducopter è un progetto che si fissa degli obiettivi precisi che dovrebbero consentirne l'uso semi professionale.
Peccato che non ci sia ancora riuscito.

Per carità, nessuno pretende niente...ma se non si arriva neanche al livello di base degli altri progetti amatoriali stupidi, secondo me qualche problema c'è.

Il discorso che stai facendo tu invece e' di tipo commerciale , devo fare un servizio , farlo bene e non mi è sufficiente la piattaforma per lavorare perche' di fatto ha limiti oggettivi che non mi consentono di usarla.

Esattamente. Io quando ho allestito la prima elettronica apm lo sapevo che era una eventualità e mica mi strappo i capelli, tanto la macchina MK ce l'ho. Ma ci si aspettava dal progetto una evoluzione maggiore e in tempi più brevi.

Purtroppo l'avvenire mi pare ancora un po' fumoso, senza una strada ben definita da percorrere e con un approccio che non mi sembra portare a soluzioni vere. Magari le cose cambieranno....

Forse il nostro amico che ha aperto questo post , sta curiosando dentro per capirci qualcosa di piu' per spingere oltre ai limiti imposti da piattaforme chiuse una macchina , un prototipo che in realta' gli consente di provare cose che con MK oggettivamente non puoi' fare .

Ma che sono queste cose che oggettivamente con mk non puoi fare?? E' troppo presto per pensare ai vantaggi teorici quando mancano le basi del volo.
Continuiamo a sognare quando le cose che servono non ci sono!
Bobo vuole costruire un grosso multirotore per videoripresa e come gli abbiamo già detto tutti (anche te), la piattaforma non è certo quella più indicata.

Per quanto riguarda l'impiego dei quad per riprese aeree rispetto ad MK , io non mi sono sentito mancare le funzioni automatiche RTL - GPS hold , ma l'ergonomia dell'uso dato ad esempio da un OSD piuttosto che dalla telemetria su JETI.
Quella e' una carenza che Arducopoter / Arducopter32 avevano e ora non hanno piu' e tra un po' vi mostrero' il perche' lo sto' dicendo .

Non è solo questione di gps hold (comunque indispensabile su una macchina destinata anche a fare foto di un certo tipo) ma tutta una serie di evidenti limiti di volo che non lo rendono ancora adatto all'uso per scopi specifici.

Di osd ce ne sono decine aftermarket...è una carenza colmabile in qualsiasi momento...io non uso l'epi osd su mk ad esempio, ma solo la telemetria a terra e sui miei mezzi ho tutto eagletree.

sul fatto che autonomie di quel genere siano irraggiungibili io ho partecipato ad una demo di un nostro oggetto con delle batterie particolari dove abbiamo fatto 40 min di volo Non posso dire altro ....
L'unico problema e' che alla fine del test del prototipo di batteria si e' incendiata ... ci vorra' ancora qualche mese per stabilizzare questo tipo di tecnologia , ma forse tra un poco ci siamo

I miei esa di serie ne fanno 32 vuoti. costi minimi, tutto disponibile subito.
Con un elicottero stai su tutto il tempo che vuoi e non hai bisogno di nessuna batteria incendiaria. Queste cose chi lavora lo sa benissimo e i mezzi si usano per quello che sono. Di richieste assurde non sai quante me ne sono arrivate... ovviamente più che farsi una risata sopra non ci posso fare.

Per il resto, se volete sognare di andare in giro appesi ai multirotori elettrici, fate pure...ma poi toccherà svegliarsi.

[redfox74]

Per carità, nessuno pretende niente...ma se non si arriva neanche al livello di base degli altri progetti amatoriali stupidi, secondo me qualche problema c'è.

Paragonare Multiwii ad Arducopter non e' possibile , lo si potra' fare a parita' di funzioni . Oggi Multiwii non ha nulla nemmeno di abbozzato sulla parte autonoma , che possa volare bene in acro e' un dato di fatto. Ma e' l'unica cosa che puoi paragonare. Il gps c'e' solo un parser e qualche funzioncina giusto per fare qualche test , quindi non siamo nemmeno all'abc Se usi tutta la potenza di calcolo si fa' per dire di arduino per l'assetto e non per le restanti funzioni e piu' facile far funzionare bene una cosa su 10

Ma ci si aspettava dal progetto una evoluzione maggiore e in tempi più brevi.

Alcuni passaggi forse non ti sono chiarissimi ma sono stati fondamentali .... per esempio il protocollo mavlink è una rivoluzione che ha alzato il livello del progetto in modo incredibile a livello di modularita' e possibilita' di evoluzioni future.

Il mission planner ... anche li e' stato un passaggio decisamente notevole. L'architettura di sistema e le librerie facci un giretto dentro e vedrai quanto sono strutturate e ben fatte .

Nascono per esigenze di portarbilita' e riusabilita' non hanno paragone con niente di diponibile.

L'unica pecca di tutto il progetto e' il micro sotto dimensionato ed e' il motivo per cui ho lavorato per primo alla piattaforma a 32 bit.

Anche io non sono ancora soddisfatto della qualita' delle funzionalita' automatiche ma sono sicuro che e' solo questione di tempo.

Se calcoli che l'anno scorso MP32 nemmeno esisteva ... e' nata a marzo. A nemmeno un anno di distanza sono qua' per me' e' stato un balzo da gigante , da solo senza aderire 4 anni fa' ad un progetto così stimolante ed in continua evoluzione non sarei andato da nessuna parte.

Spero che tra un annetto non ci sara' piu' assolutamente nulla ancora da affinare e si ragionera' su cose più a livello applicativo che a livello architetturale.

Purtroppo l'avvenire mi pare ancora un po' fumoso, senza una strada ben definita da percorrere e con un approccio che non mi sembra portare a soluzioni vere. Magari le cose cambieranno....

L'avvenire e' molto chiaro almeno a me e alla nostra community di sviluppo.
L'obbiettivo e' di avere un robot volante che viene usato in modo completamente autonomo e parametrico , già i primi voli autonomi sono stati fatti e i risultati ci sono .
Ora si sta' lavorando di lima si sta' lavorando sulla stabilizzazione dell'altitude hold utilizzando sia la velocita' di salita e discesa che l'integrazione dell'accelerazione per ottenere il rate di salita discesa . Inoltre si usera' un nuovo barometro con maggior risoluzione , un nuovo componente MPU6000 per avere una imu ancor piu' performante . Digitale e con un range piu' esteso oltre che avere un processore interno che ti ritorna in automatico gli angoli di Eulero

Cosa serve tutta sta' roba per fare riprese aeree ... niente ... ma per la sperimentazione robotica eccome servono ;)

Poi se uno vuol fare il suo prodotto ad hoc per fare video e foto aeree puo' farlo ... io lo sto' facendo ... e sono piu' che soddisfatto dei risultati che sto' ottenendo.

Altra news in arrivo la Telemetry board che usa protocollo mavlink per interfacciarsi alla cpu , osd per mettere in sovra impressione i dati , l'uscita per jeti che ti porta sul jetibox i parametri fondamentali del volo e il gprs per il long range telemetry e il ritrovamento del velivolo.

Come vedi le idee sono mooolto chiare . Altra cosa imortante la certificazione per le versioni professionali del prodotto.

Ma che sono queste cose che oggettivamente con mk non puoi fare??
Non ho detto che MK non puo' fare delle cose ho detto che MK non ti da' tutte quelle informazioni in modo chiaro come invece lo fa' un progetto opensoruce come arducopter che se sei capace di leggere il codice ed imparare da quello che gli altri fanno porta il tuo livello di consapevolezza dei meccanismi di assetto , di navigazione automatica ecc ecc che con un oggetto chiuso non ti da' .

Di osd ce ne sono decine aftermarket...è una carenza colmabile in qualsiasi momento...io non uso l'epi osd su mk ad esempio, ma solo la telemetria a terra e sui miei mezzi ho tutto eagletree.

Eagle tree non è integrato nella elettronica di bordo del velivolo , i nostri OSD con protocollo mavlink lo sono e ti possono consentire oltre che di avere tutti i dati che interessano rispetto allo stato del velivolo anche di settare qualsiasi parametro , si tratta di definire a livevllo ergonomico quali sono i dati piu' importanti da poter settare .. .faccio un esempio ... se vuoi cambiare il gain del brandeggio , puoi entrare nel parametro del brandeggio alzare o abbassare il valore e vedere il risultato in tempo reale tutto da jetibox per esempio. Stessa cosa vale per i pid , tutto sempre da jetibox , non mi sembra che l'mk ti consenta il setup di questi parametri da jetibox o mi sbaglio ... forse ora lo supporta ...

Con protocollo mavlink e gprs puoi anche fare in modo che oltre a darti tutte le info su osd jetibox le puo' trasmettere ad una groundstation che sta' ovunque nel mondo ed aggiorna in tempo reale tutti i parametri durante il volo ....

Non vedere queste funzioni come specifiche per un app particolare ma come esercizi di sperimentazione per capire se si ottengono oggettivi vantaggi in termini di ergonomia dell'uso e sicurezza.

I miei esa di serie ne fanno 32 vuoti. costi minimi, tutto disponibile subito.

wow io sono arrivato solo a 20 Facci vedere qualche bel video della tua belva che porta 32 kg in volo

Con un elicottero stai su tutto il tempo che vuoi e non hai bisogno di nessuna batteria incendiaria.

Si ma un elicottero ha dei problemi di sicurezza enormi difficilmente potra' essere omologato per usi civili. Uno dei requisiti di base e' la ridondanza che non c'e' ...

[jhoexp]

Se usi tutta la potenza di calcolo si fa' per dire di arduino per l'assetto e non per le restanti funzioni e piu' facile far funzionare bene una cosa su 10

E allora si dovrebbe reiniziare dalle cose basilari e mettere a posto per prima cosa l'assetto. Se il mezzo non vola bene è inutile perdersi in mille altre cose.

uni passaggi forse non ti sono chiarissimi ma sono stati fondamentali .... per esempio il protocollo mavlink è una rivoluzione che ha alzato il livello del progetto in modo incredibile a livello di modularita' e possibilita' di evoluzioni future.

Ricordavo tuo parere contrario e mi sembrava avessi diversi dubbi sul peso il mavlink ha sul sistema. Forse sulla tua mp32 ha molto più senso, ma per ora mi concentrerei sulle attuali condizioni del progetto... le evoluzioni future lasciamole al futuro.

Il mission planner ... anche li e' stato un passaggio decisamente notevole. L'architettura di sistema e le librerie facci un giretto dentro e vedrai quanto sono strutturate e ben fatte .

Sìsì, tutto bellissimo. Ma se il mezzo non vola decentemente in modalità manuale/stabile, come deve assolutamente fare, non me ne faccio niente.

L'unica pecca di tutto il progetto e' il micro sotto dimensionato ed e' il motivo per cui ho lavorato per primo alla piattaforma a 32 bit.

Quello è solo uno dei problemi, ma il principale è che quelli che scrivono codice non hanno per nulla le idee chiare (e fanno un sacco di cappelle). Tu hai scritto un sacco di cose utili e molto bene, ma gli algoritmi di volo non li hai toccati. Purtroppo si deve iniziare da lì perchè sono quelli più trascurati e che più necessitano revisione.

Le ultime modifiche hanno rovinato parecchio...le prime versioni funzionavano molto meglio. Le funzionalità avanzate si implementano quando le basi sono consolidate, non come hanno fatto e stanno facendo loro.

L'avvenire e' molto chiaro almeno a me e alla nostra community di sviluppo.
L'obbiettivo e' di avere un robot volante che viene usato in modo completamente autonomo e parametrico , già i primi voli autonomi sono stati fatti e i risultati ci sono .
Ora si sta' lavorando di lima si sta' lavorando sulla stabilizzazione dell'altitude hold utilizzando sia la velocita' di salita e discesa che l'integrazione dell'accelerazione per ottenere il rate di salita discesa . Inoltre si usera' un nuovo barometro con maggior risoluzione , un nuovo componente MPU6000 per avere una imu ancor piu' performante . Digitale e con un range piu' esteso oltre che avere un processore interno che ti ritorna in automatico gli angoli di Eulero

Cosa serve tutta sta' roba per fare riprese aeree ... niente ... ma per la sperimentazione robotica eccome servono ;)

Peccato che stiamo parlando di mezzi per fare essenzialmente foto e video aerei e la sperimentazione robotica qui non mi pare l'argomento principale.
Nuovi sensori, robot autonomi, alabarda spaziale, con l'energia del sole vincerò!!!

Stiamo con i piedi per terra!
Io vi suggerisco di dedicarvi a qualcosa di più realistico e di sviliuppare almeno un progetto paragonabile a quello dei concorrenti, sistemando innanzitutto le funzionaltià fondamentali che devono essere consolidate. Così da avere una buona base su cui poi sperimentare tutti i vostri sogni di automazione totale.

Eagle tree non è integrato nella elettronica di bordo del velivolo , i nostri OSD con protocollo mavlink lo sono e ti possono consentire oltre che di avere tutti i dati che interessano rispetto allo stato del velivolo anche di settare qualsiasi parametro , si tratta di definire a livevllo ergonomico quali sono i dati piu' importanti da poter settare .. .faccio un esempio ... se vuoi cambiare il gain del brandeggio , puoi entrare nel parametro del brandeggio alzare o abbassare il valore e vedere il risultato in tempo reale tutto da jetibox per esempio. Stessa cosa vale per i pid , tutto sempre da jetibox , non mi sembra che l'mk ti consenta il setup di questi parametri da jetibox o mi sbaglio ... forse ora lo supporta ...

Faccio già tutto su MK senza problemi, e poi che me ne faccio dello jetibox? Con tool seri, ho il pc/tablet/netbook/cellulare o quan'taltro, con tutti i dati che voglio, e cambio qualsiasi parametro a distanza.
Gli osd li uso quando piloto in soggettiva... e comunque che siano integrati con la fc è superfluo, visto che i dati di volo li ho lo stesso e spesso la ridondanza non fa male.

Con protocollo mavlink e gprs puoi anche fare in modo che oltre a darti tutte le info su osd jetibox le puo' trasmettere ad una groundstation che sta' ovunque nel mondo ed aggiorna in tempo reale tutti i parametri durante il volo ....

Non vedere queste funzioni come specifiche per un app particolare ma come esercizi di sperimentazione per capire se si ottengono oggettivi vantaggi in termini di ergonomia dell'uso e sicurezza.

Sì appunto solo esercizi di sperimentazione. Tutta roba che piace agli sviluppatori ma il progetto rimane fermo con grosse lacune di base.

wow io sono arrivato solo a 20 Facci vedere qualche bel video della tua belva che porta 32 kg in volo

Si parlava di minuti, non di Kg! E comunque 32 minuti li fa qualsiasi MK BASE con le giuste batterie. Anzi facilmente si fa anche di meglio...
Noi comunque con 32 kg abbiamo già volato, ovviamente non con un multirotore.E se tu non vieni ai raduni o alle manifestazioni, non vedrai mai niente!

Si ma un elicottero ha dei problemi di sicurezza enormi difficilmente potra' essere omologato per usi civili. Uno dei requisiti di base e' la ridondanza che non c'e' ...

Veramente gli unici ad essere attualmente omologati per usi civili sono proprio alcuni elicotteri. La ridondanza c'è eccome con le meccaniche giuste.

I problemi di sicurezza ci sono per tutti, e se si esagera con pesi e dimensioni dei multirotori i problemi sono gli stessi, anzi anche peggiori, visto la destinazione d'uso generalmente diversa...

Ma torniamo in topic?

Okto con APM2560: che ne dite? Io dico: NO, grazie!

[danveal]

Io concordo sul fatto che se l'algoritmo del volo base rende il volo non all'altezza delle aspettative tutto il resto sara' pessimo.
Aggiungere mattoni a fondamenta precarie non fa altro che aumentare l'instabilita' e il caos, si sommano errori su errori e tornare indietro per risolvere la madre di tutti gli errori potrebbe essere impossibile.

Per quanto riguarda MK e Jeti io uso il firmware di Martin che ha modificato l'ultima versione rendendo possibile modificare tutti i parametri dell'mktools con la jetibox compresi i canali seriali, oltre che avere il beep sonoro generato dalla jetibox quando con il vario si aumenta / diminuisce l'altezza.

Per tornare in topic, la mia l'ho gia detta sull'uso PRO di un okto con apm2560 e la ripeto, BUONA FORTUNA

[Bobo67]

Credo che Jo abbia ragione, io per ora ho utilizzato solo droni con MK, e non ho MAI (lo ribadisco, MAI) avuto un problema nel volo, ho sempre fatto quello che avrei dovuto fare.
Non ho visto dal vivo molti altri sistemi volare, intendo multirotori, ma per quei pochi che ho pututo valutare ho sempre "storto il naso", nessuno escluso.
Il thread l'ho creato per discutere sulla configurazione motori/eliche/peso, intendo comunque sperimentare questo sistema per aver un quadro più ampio della situazione, e stiamo strutturandolo per montarci la torre MK in pochi minuti (con afroi2c per ora), in modo da poter utilizzarlo comunque con un buon margine di stabilità.
Il codice Ardu dovrebbe appunto esser migliorato, debuggato ed ottimizzato per quel che concerne il volo e la stabilità, ma purtroppo nascendo come progetto per lo svolazzo domenicale credo che continueranno ad implementare cose nuove "per noi obsolete" tralasciando altre cose fondamentali.
Dell'hovering piantato col sonar che me fotte, se poi a 50 metri di quota inizia ad andarsene per i fatti suoi?
Roberto, non ho preso la tua scheda perchè ti avrei massacrato di mail per ogni piccola magagna che avrei notato, poichè credo non sia facile, dopo un porting su un altro micro, sistemare la stabilità di volo se ci lavorate in pochi e se siete appunto orientati sulle implementazioi piuttosto che sul debug, ecco perchè ho scelto APM, la community che sviluppa è numericamente superiore... speriamo in un futuro migliore!
Per la telemetria lo ribadisco, personalmente ho bisogno di 2 parametri: consumo in tempo reale delle lipo e tensione residua, fine... tutto il resto per lavorarci non m'interessa, principalmente piloto a vista, è per me fondamentale avere sulla groundstation un ottimo live view della cam di bordo + quei due parametri, fine... se poi mi voglio rilassare me ne sto ad analizzare il resto della telemetria sul pc, via xbee o wii232/bluetooth, ma questo mi servirà esclisivamente per il tuning.
Dell'orizzonte artificiale, segnale gps, etc. etc. non me ne faccio nulla, quello serve a chi tira l'interruttore, lo pianta la, e sta li a contemplare il display dell'osd divertendosi a leggere tutto quello che vede e vantandosene con l'amico di turno, non è il mio caso.

[redfox74]

Io concordo sul fatto che se l'algoritmo del volo base rende il volo non all'altezza delle aspettative tutto il resto sara' pessimo.
Aggiungere mattoni a fondamenta precarie non fa altro che aumentare l'instabilita' e il caos, si sommano errori su errori e tornare indietro per risolvere la madre di tutti gli errori potrebbe essere impossibile.

Per quanto riguarda MK e Jeti io uso il firmware di Martin che ha modificato l'ultima versione rendendo possibile modificare tutti i parametri dell'mktools con la jetibox compresi i canali seriali, oltre che avere il beep sonoro generato dalla jetibox quando con il vario si aumenta / diminuisce l'altezza.

Per tornare in topic, la mia l'ho gia detta sull'uso PRO di un okto con apm2560 e la ripeto, BUONA FORTUNA

@Jhoexp,
non capisco cosa vuoi di piu' dal punto di vista dello stable mode di Arducopter , almeno nella mia versione il velivolo e' inchiodato in cielo ... la modalita' stabile e' quella che funziona meglio in assoluto a detta di molti il feeling che ti da' e' superiore anche a MK . Ovviamente va tarato in modo adeguato allo stile di volo . Ora anche su tuo consiglio abbiamo inserito un PID aggiuntivo per il rate nel volo acrobatico cosi se si vuole giocare anche con quello lo si puo' fare. In merito agli algoritmi oltre alla DCM ci sono anche alcune versioni che usano MARG e nell'ultima revisione ci sara' anche la gestione della DMP di MPU6000 vediao come si comporta quindi non e' piu' il micro che ti fa l'assetto ma il chip che ti torna gli angoli d'assetto.
E' ovvio che non puoi fare tutto quello che vuoi e il modo stabile ti limita parecchio so' che quello che non ti piace e' che e' lui che vola e non tu
Per Mavlink , sulla piattaforma a 8 bit e' molto pesante sulla mia ci puo' stare e porta decisamente dei vantaggi applicativi non indifferenti il vero problema e' mantenere alta l'affidabilita' con una complessita' crescente del codice dovuta all'introduzione della flessibilita' della piattaforma.
Scusa quale Eli e' stato certificato AERP6 ? A me non risulta nessuno , a parte un Hexa Coax e qualche aereo come Raven nessun Eli ha passato la certificazione proprio perche' mancano alcuni requisiti di sicurezza legati ai droni!!!
Per decollare un Arducopter alzi lo stick e lui fa' tutto da solo , i milgioramente e ci sono decissamente stati nelle ultime versioni sulla tenuta di quota sono da apportare su altri temi in particolare sul loiter . In particolare nelle ultime revisioni sono stati introdotti una serie di stratagemmi sull'analisi delle accelerezioni sullo Z per far si che tenga la quota a prescindere dal barometro.

Quindi l'uso di Arducopter 2560 per applicazioni PRO io dico no se sei un end user con scarse o nulle capacita' di sviluppo e comprensione del codice del prodotto ma dico si per sperimentare piattaforme avanzate e per comprenderne le peculiarti specifiche di volo ,magari con un micro piu' performante .