Arduflyer - APM 2.5 (Arducopter)

[Bobo67]

Ciao Sandro "Sonico" ho aprezzato fin dall'inizio la tua iniziativa di creare un nuovo modo di volo.
Ti sei presentato umilmente e hai detto vorrei provare a fare un nuovo modo di volo, la mia impressione e stata che i grandi esperti ti avessero preso sottogamba.

Paolo

Ciao Paolo, il modo di volo "hybrid" nasce da una mia idea, Sonico è un grande ed insieme ad Julien l'hanno resa realtà, è già stato pubblicato tutto dal sottoscritto qui , chi sarebbero per cortesia questi esperti che hanno preso questa cosa sottogamba? Sono curioso...

Marco

[danveal]

Ciao Paolo, il modo di volo "hybrid" nasce da una mia idea, Sonico è un grande ed insieme ad Julien l'hanno resa realtà, è già stato pubblicato tutto dal sottoscritto qui , chi sarebbero per cortesia questi esperti che hanno preso questa cosa sottogamba? Sono curioso...

Marco

Forse direttamente Anderson quando giorni fa su diydrones ha affermato che anche "loro" stavano implementando una cosa simile?
E' innegabile che nonostante le belle parole di circostanza il lato "europeo" dello sviluppo (sopratutto hw ) viene visto non dico come un granellino di sabbia nell'ingranaggio pixhawk, ma quasi
A parte il lead tester ovviamente, lui gode di riconoscimenti bipartisan worldwide

[Bobo67]

Come ho già scritto sul thread della VR Brain l'Hybrid è più che altro uno "smacco" al dev team 3DR, del quale faccio parte ma che spesso va in contrasto con noi italiani, siamo sempre un pò visti come "pizza mandolino maccheroni mafia".
Magari il "lead tester" viene pure preso in considerazione, ma ci sono anche altri italiani che sanno il fatto loro, vedi Roberto, è due anni che la mena "io ho la board con l'ARM pronta e vola, voi andate ancora con la 2560", e loro "no no, niente ARM, va bene la 2560, e ne avanza pure"... e salta fuori PX4, Pixhawk, dopo due anni che Roberto la menava (aveva visto lungo, molto).
Sandro e Julien erano un pò restii a pubblicare qualcosa già adesso ma ho spinto molto sull'avere un "risultato volabile immediato", anche se ancora allo stato embrionale ma perfettamente funzionante.
E' un "ah beccate questo, tiè", e vi assicuro che il messaggio è arrivato, eccome, AHAHAH!
Nessun commento di Chris o di qualsiasi altro sviluppatore 3DR al mio post sul blog, questo lo conferma, palesemente, noi italiani saremo anche un pò coyotes ma sappiamo leggere tra le righe.
Ora vediamo che fanno, il mio dovere credo d'averlo fatto, a vantaggio (spero) del made in Italy e dell'ottimo lavoro svolto da Sandro e Julien, ai quali va il mio plauso, rispetto ed ammirazione.
Spero che Hybrid venga adottato (anzi, verrà adottato, LOL), magari con un nome più chiaro e che piaccia a 3DR, of course!

Marco

[xeshobby]

Ciao Paolo, il modo di volo "hybrid" nasce da una mia idea, Sonico è un grande ed insieme ad Julien l'hanno resa realtà, è già stato pubblicato tutto dal sottoscritto qui , chi sarebbero per cortesia questi esperti che hanno preso questa cosa sottogamba? Sono curioso...

Marco

Ciao Marco, ma verrà rilasciata una 3.1.1 per i possessori di APM oppure questa nuova modalità sarà rilasciata nella 3.2 per i soli possessori di Pix e VRB?

Ciao

Gian

[Bobo67]

Ciao Gian, Hybrid è stato testato principalmente su APM quindi anche ArduFlyer lo sopporta, of course, isolando però alcune funzionalità nell'APM_Config.h o non c'è spazio per farcelo entrare!
Personalmente ho utilizzato VR Brain perchè non possiedo più APM, da tester devo guardare avanti e l'ARM è il presente per quel che mi riguarda, l'Atmel un glorioso passato.
E' ovvio che gli utilizzatori di oggi volano quasi tutti con APM/ArduFlyer, costi notevolmente inferiori a pari prestazioni, anche se non è proprio così ma l'importante è far finta di non saperlo, fregarsene e volare lo stesso, finchè va VA, è la filosofia comune da quel che leggo.

[xeshobby]

Ciao Gian, Hybrid è stato testato principalmente su APM quindi anche ArduFlyer lo sopporta, of course, isolando però alcune funzionalità nell'APM_Config.h o non c'è spazio per farcelo entrare!
Personalmente ho utilizzato VR Brain perchè non possiedo più APM, da tester devo guardare avanti e l'ARM è il presente per quel che mi riguarda, l'Atmel un glorioso passato.
E' ovvio che gli utilizzatori di oggi volano quasi tutti con APM/ArduFlyer, costi notevolmente inferiori a pari prestazioni, anche se non è proprio così ma l'importante è far finta di non saperlo, fregarsene e volare lo stesso, finchè va VA, è la filosofia comune da quel che leggo.

Sarebbe interessante creare un bin versione Lite della 3.1, eliminando il superfluo da APM_Config.h (gimbal ecc) .
In questo modo tutti potrebbero installarlo.
Ricordo che Sandro lo aveva già inglobato in una release candidate (credo la RC5), quindi se si può condividere il codice basato su 3.1 stable si potrebbe benissimo installare questa versione "lite" su Atmel senza problemi.


ho tirato giu il master ma li siamo alla 3.2 dev con filtro di Kalman ecc

potrebbe esser un idea no?

Ciao

Gian

[Bobo67]

Certo Gian, ma in tutto questo io d'ora innanzi conterò come il due di coppe a briscola.
Il codice volabile per APM con l'Hybrid è in mio possesso ma essendo tutto ancora da testare per bene non lo posso rilasciare, solo Sandro e Julien ora devono decidere come procedere, io gli ho spianato la strada, ora sono loro che devono valutare come e se percorrerla.

[Paolo - BT]

Ciao Paolo, il modo di volo "hybrid" nasce da una mia idea, Sonico è un grande ed insieme ad Julien l'hanno resa realtà, è già stato pubblicato tutto dal sottoscritto qui , chi sarebbero per cortesia questi esperti che hanno preso questa cosa sottogamba? Sono curioso...

Marco

Non era nulla di personale o altro.
Solo una sensazione iniziale arriva uno sconosciuto e al secondo post ti scrive sviluppo un nuovo modo di volo
Però come tu scrivi, sembra che qualcuno faccia fatica a mandare giù il boccone adesso, ma è abbastanza tipico.
A me è successo una cosa simile l'unica differenza che quelli che hanno fatto fatica mandare giù il boccone sono gli italiani.
Hai ragione quando dici che siamo conosciuti "pizza mandolino maccheroni mafia", ma questo in parte è anche colpa nostra, che facciamo conoscere all'estero solo il peggio.
Complimenti a tutti quanti.
Ciao
Paolo

[sonico]

Eccomi, innanzitutto ringrazio Marco per il lavoro che ha fatto e per l'auito che ci stà dando. Ringrazio poi tutti quelli che apprezzano il lavoro che stiamo portando avanti.

Cosa aggiungere a quanto già brillantemente esposto da Marco?
Allora qualche dettaglio tecnico, che probabilmente non interessa a nessuno, ma siccome è costato fatica, almeno lasciatemelo scrivere
L' "ibrido" svolazza benone, ok, ma quando vola è sostanzialemente un normalissimo alt-hold con in più una compensazione del vento (tra l'altro, io non l'ho mai fatto volare col vento, quindi non saprei descriverne l'effetto sul volato)
Quando uno od entrambi gli stick vengono rilasciati, entra in azione il codice della frenata, che ha il compito di portare la velocità ad un valore molto basso, prossimo a zero.
La frenata automatica produce, oltretutto, un effetto simile al modo drift, ottenuto però manovrando di yaw. Ma a differenza del modo Drift, il roll rimane attivo, anzi, se il pilota corregge appena un minimo, la frenata viene annullata e prende il sopravvento l'azione del pilota, particolare che forse a Marco è piaciuto.
Il lavoro sulla frenata è stato parecchio, con la creazione di un modello in Matlab e la simulazione di diversi profili, più o meno bruschi. Questa fase ci ha aiutato a comprendere l'importanza della compensazione del vento perchè l'esito della frenata dipende fortemente dal vento. Il profilo è stato messo a punto da Julien, che è partito da una mia soluzione semplice e l'ha modificata in maniera tale da preservarne l'efficacia ma renderne prevedibile la durata.
L'altro grosso scoglio è stato l'ingaggio del loiter, che come avete visto nel video, avviene in maniera assolutamete dolce e non distinguibile dall'alt-hold.
Anche in questo caso, è stato messo a punto un modello matematico per effettuare la simulazione e cercato di capire a fondo come il loiter fosse stato implementato.
Ancora una volta Julien si dimostrato assolutamete geniale e con una intuizione ha cancellato tutto il mio codice e lo ha sostituito con un semplice ritardo (mezzo secondo!) tra la fine della frenata e il loiter. Tanto è bastato.
Tocco finale, un filtro, che raccorda "in dolce" i comandi degli stick quando vengono rilasciati, di modo che non ci siano oscillazioni dei controllori dovuti a discontinuità nei comandi.
Una volta in loiter, parte la fase di "auto apprendimento" del vento, costruendo le due componenti che poi vengono ruotate in tempo reale secondo l'angolo di yaw ed applicate a pitch e roll.

Abbiate pazienza ancora un po', ci sono un paio di bugs potenzialemente pericolosi (vi siete chiesti come mai Marco non decolla in Hybrid? ) e c'e' il discorso dell'allineamento con la 3.1.1.
Potrei farlo, e prob. lo farò, vediamo, la cosa costa tempo e, come dice Marco, non sappiamo se questa modalità verrà accettata nel master (in teoria non ci sta in memoria di APM, bisogna disabilitare qualche funzione), oppure verrà implementata in maniera diversa, quindi lo sforzo potrebbe essere una inutile perdita di tempo.

Come è già stato fatto notare, per VRbrain è già disponibile e allineata all'ultima beta grazie al lavoro di Emile, per APM potrei rilasciare il binario, ma vorrei prima correggere almeno i bugs.

Per finire, in programma ci sarebbe anche una modifica alla gestione dell'elevatore, che in alt-hold ha una grande dead band e poca responsività.
Vediamo...

[redfox74]

Sarebbe interessante creare un bin versione Lite della 3.1, eliminando il superfluo da APM_Config.h (gimbal ecc) .
In questo modo tutti potrebbero installarlo.
Ricordo che Sandro lo aveva già inglobato in una release candidate (credo la RC5), quindi se si può condividere il codice basato su 3.1 stable si potrebbe benissimo installare questa versione "lite" su Atmel senza problemi.


ho tirato giu il master ma li siamo alla 3.2 dev con filtro di Kalman ecc

potrebbe esser un idea no?

Ciao

Gian

Ciao Gian,
non e' solo un problema di spazio sull'atmel ma anche di performances EKF non gira su APM 2.6 anche se e' disponibile . Il modo ibrido invece si.

[redfox74]

Eccomi, innanzitutto ringrazio Marco per il lavoro che ha fatto e per l'auito che ci stà dando. Ringrazio poi tutti quelli che apprezzano il lavoro che stiamo portando avanti.

Cosa aggiungere a quanto già brillantemente esposto da Marco?
Allora qualche dettaglio tecnico, che probabilmente non interessa a nessuno, ma siccome è costato fatica, almeno lasciatemelo scrivere
L' "ibrido" svolazza benone, ok, ma quando vola è sostanzialemente un normalissimo alt-hold con in più una compensazione del vento (tra l'altro, io non l'ho mai fatto volare col vento, quindi non saprei descriverne l'effetto sul volato)
Quando uno od entrambi gli stick vengono rilasciati, entra in azione il codice della frenata, che ha il compito di portare la velocità ad un valore molto basso, prossimo a zero.
La frenata automatica produce, oltretutto, un effetto simile al modo drift, ottenuto però manovrando di yaw. Ma a differenza del modo Drift, il roll rimane attivo, anzi, se il pilota corregge appena un minimo, la frenata viene annullata e prende il sopravvento l'azione del pilota, particolare che forse a Marco è piaciuto.
Il lavoro sulla frenata è stato parecchio, con la creazione di un modello in Matlab e la simulazione di diversi profili, più o meno bruschi. Questa fase ci ha aiutato a comprendere l'importanza della compensazione del vento perchè l'esito della frenata dipende fortemente dal vento. Il profilo è stato messo a punto da Julien, che è partito da una mia soluzione semplice e l'ha modificata in maniera tale da preservarne l'efficacia ma renderne prevedibile la durata.
L'altro grosso scoglio è stato l'ingaggio del loiter, che come avete visto nel video, avviene in maniera assolutamete dolce e non distinguibile dall'alt-hold.
Anche in questo caso, è stato messo a punto un modello matematico per effettuare la simulazione e cercato di capire a fondo come il loiter fosse stato implementato.
Ancora una volta Julien si dimostrato assolutamete geniale e con una intuizione ha cancellato tutto il mio codice e lo ha sostituito con un semplice ritardo (mezzo secondo!) tra la fine della frenata e il loiter. Tanto è bastato.
Tocco finale, un filtro, che raccorda "in dolce" i comandi degli stick quando vengono rilasciati, di modo che non ci siano oscillazioni dei controllori dovuti a discontinuità nei comandi.
Una volta in loiter, parte la fase di "auto apprendimento" del vento, costruendo le due componenti che poi vengono ruotate in tempo reale secondo l'angolo di yaw ed applicate a pitch e roll.

Abbiate pazienza ancora un po', ci sono un paio di bugs potenzialemente pericolosi (vi siete chiesti come mai Marco non decolla in Hybrid? ) e c'e' il discorso dell'allineamento con la 3.1.1.
Potrei farlo, e prob. lo farò, vediamo, la cosa costa tempo e, come dice Marco, non sappiamo se questa modalità verrà accettata nel master (in teoria non ci sta in memoria di APM, bisogna disabilitare qualche funzione), oppure verrà implementata in maniera diversa, quindi lo sforzo potrebbe essere una inutile perdita di tempo.

Come è già stato fatto notare, per VRbrain è già disponibile e allineata all'ultima beta grazie al lavoro di Emile, per APM potrei rilasciare il binario, ma vorrei prima correggere almeno i bugs.

Per finire, in programma ci sarebbe anche una modifica alla gestione dell'elevatore, che in alt-hold ha una grande dead band e poca responsività.
Vediamo...

E' due giorni che continuo a fare i complimenti , ma visto come siete arrivati ai risultati ottenuti attraverso le simulazioni matlab ve li rifaccio ancora una volta .. domanda ma Julien che fa' nella vita ? Puoi anche rispondermi in privato , mi pare un bel manico come cooder

In merito allo spazio su VRBrain c'e' tutto lo spazio che si vuole sia di flash che di ram 1 mega di flash e 196 kbyte di ram contro i 256 kbyte di flash e 16 kbyte di ram dell'apm e il codice e' assolutametne allineato all'ultima revisione di firmware per APM Copter senza escludere alcuna funzione.

Prima di lasciare un dfu che lo integri aspettiamo le correzioni per poi dare in pasto anche ad altri il codice ripulito , se nel frattempo non riuscite a risolvere il decollo in hybrid mode potete fare anche in modo di non consentire il decollo in quella modalità come salvaguardia per evitare che possa accadere come si faceva in precedenza con il loiter.

un saluto
Roberto

[redfox74]

Forse direttamente Anderson quando giorni fa su diydrones ha affermato che anche "loro" stavano implementando una cosa simile?
E' innegabile che nonostante le belle parole di circostanza il lato "europeo" dello sviluppo (sopratutto hw ) viene visto non dico come un granellino di sabbia nell'ingranaggio pixhawk, ma quasi
A parte il lead tester ovviamente, lui gode di riconoscimenti bipartisan worldwide

Ciao Danilo ,
faccio una piccola precisazione , in realtà tutto quello che sta' usando 3DR arriva tutto dall'europa poi loro sono piu' bravi a fare marketing internazionale ... e globalizzare ... Arduino che e' alla base di APM 2.6 arriva dall'italia , Pixhawke arriva da Zurigo che e' in svizzera , la VRBrain 4.5 arriva dall'italia , ma e' rimasta almeno per ora con un head quarter solo in italia Quindi non mi pare che stiano esportando tecnologia , ma anzi la importano e se la rivendono come loro

In merito a Pixhawke penso che il problema fondamentale e' che hanno sottovalutato molto il passaggio alla nuova piattaforma , poca esperienza sui micro a 32 bit e poca esperienza su OS con una diffidenza diffusa degli sviluppatori a fare il salto nel vuoto il risultato e' che da agosto ad oggi non sono ancora fuori con una piattaforma affidabile. Anche a livello hardware hanno giocato male le loro carte , sono dovuti tornare all MPU6000 e a rimettere i parameteri fuori dalla SD perche' cosi' quando si corrompe almeno quelli non li perdi al limite perdi un po' di log esattamente quello che facciamo sulla VRBrain da sempre !!!
VRBrain ormai ha già 2 anni di esperienza sul campo e quindi e' nel pieno della sua maturità in termini anche di affidabilità inoltre noi abbiamo fatto la scelta di supportare sia il mondo OS e non OS quindi abbiamo virtualmente il piede in due scarpe e quello piu' affidabile e' quello che deriva dall'esperienza sul NO OS ovviamente piu' avanti le cose potrebbero cambiare , ma stiamo comunque tenendo monitorata la situazione

[danveal]

Ciao Roberto,
infatti in america non si sono inventati nulla, hanno solo avuto la fortuna di aggregare le persone giuste nel momento giusto. Tutte cose che a livello di codice potevano nascere tranquillamente in Italia, come dicevo il problema da noi e' aggregare le persone giuste disposte a contribuire gratis per la causa open source
A livello hardware nessun problema, insomma i milioni di dollari della 3DR poteva benissimo riceverli virtualrobotix. Se 2-3 anni fa aprivi una sede a silicon valley magari oggi la storia sarebbe diversa

[xeshobby]

Ciao Gian,
non e' solo un problema di spazio sull'atmel ma anche di performances EKF non gira su APM 2.6 anche se e' disponibile . Il modo ibrido invece si.

Si Roberto, ovvio che l'EKF non funzionerà mai su un atmel, già è tanto quello che si riesce a far fare a questo processore con soli 8bit.

Io intendevo la modalità hybrid, quindi disabilitando funzioni aggiuntive come gimbal ecc si potrebbe recuperare un po di spazio e inserire questo nuovo modo di volo in un ipotetica release lite (3.1.1)
che grazie a Marco e dev ora è quasi esente di bug

Sonico anche solo un binario a debug completato va benone ;)

Ciao

Gian

[merendaiomax]

Buongiorno a tutti a quanto ho capito sulla APM siamo al limite di proc e memoria, pertanto quale è ' ultimo firmware montabile su questa piattaforma?

Grazie a tutti e speriamo che a Roma siano un po' "elastici" visto anche le news francesi

Buon volo a tutti