APM Copter

[Draghettofly]

Buongiorno.
Ci sono anch'io. Molto interessanti i confronti con tra Pix e VrB. Non ho ben capito se la VrB 5.0 sarà un'evoluzione della 4.5 o se è la versione pro, quella per intenderci da 1000€. Mi piacerebbe se fosse solo un aggiornamento e le cose che gradirei molto sono (oltre alle novità lette):
-ulteriori pin per altri collegamenti;
-alloggiamento integrato per SD card;
-scheda led dedicata ed opzionale, da poter collegare a qualche distanza, con buzzer;
-uscita GPS ext riservata, ben visibile e distinta;
-contenitore che protegga anche i pin esterni, cioè che non li lasci fuori (se cade, anche da dieci cm, si piegano);
-il case dovrebbe avere visibili in rilievo anche i numeri e le indicazioni principali ed avere punti di presa stabili, la forma a freccia è più elegante, forse, ma fa scivolare eventuali fascette e ha, cmq, poco grip rispetto ad una squadrata.
Queste sono solo delle idee, per carità. Quello che conta veramente è il contenuto.
Ma lo conosciamo ed apprezziamo già, tutti, mi sembra.

Emile, quando esce la 3.2...?
Grazie e salutoni a tutti.
Carlo

[Bobo67]

Concordo sulla questione della scatolina, è bellina così ma un pò scomoda.
Anche i pin interni non sarebbero male, ma in quel caso vorrebbe un pelino più complessa, tipo appunto quella della Pixhawk.
La V5 sarà un'evoluzione dell'attuale, ho già visto i pcb e le novità interessanti, ma se lo vorrà ovviamente vi dettaglierà Roberto.
L'alloggio MicroSD è su una piastrina che andrà messa a panino su una strip da "3x2", quindi un accessorio opzionale.

[gibon]

Apm

Ottima iniziativa.. Sintonizzato !!

[Bobo67]

La versione di APM Copter V3.1 verrà rilasciata ufficialmente domani nel Planner e nel forum di DIY Drones, se Emile vuole allineare per la VR Brain non dovrebbero esserci altri commit sul master attuale.

[Bobo67]

APM Copter 3.1 rilasciata

Finalmente è uscita, mi aspettavo nella release il fix per l'S-BUS che ho fatto improntare, è già pronto ma Tridge non l'ha inserito perchè lo dobbiamo ancora testare per bene, quelli con PX4 e Pixhawk per ora dovranno mettere gli endpoint della Futaba a 120 per mantenere gli stessi valori nel Planner rispetto ad una normale ricevente in ppm/ppm-sum, quando sarà nel codice si riporteranno a 100.

[lucasss]

Visto che qua si parla di APM copter, inizio più che con una domanda, con una verifica...
Oggi ho fatto un voletto in AltHold, non avevo intenzione di usare il loiter quindi non ho aspettato i classici 2 minuti affinchè facesse il FIX.
Una volta in AltHold, abilito l'AutoTune per vedere come vengono cambiati i parametri, ed il quad inizia giustamente la procedura di calibrazione...

Ad un tratto, fortunatamente sopra ad un cespuglio, il quad precipita con i motori fermi.
Mi è sembrato di sentire un Beep, ma non sapevo dire se proveniente dalla radio per aver peso il segnale con la ricevente, o proveniente dai motori del quad.

Al che, ho scaricato il log su MP e ho cercato eventuali segnalazione di errore e trovo:

Subsys: 7
ECode: 1 / ECode: 0

Quindi, andando a cercare sul sito di APM copter risalgo che corrispondono a:

7: GPS failsafe

ECode 1: GPS lock lost for at least 5 seconds

ECode 0: GPS lock restored

Quindi, ha perso il segnale GPS per più di 5 sec, ed è quindi subentrato il fail safe che, purtroppo, non avevo configurato da MP, e quindi motori a zero...

Me lo confermate?
Incredibile quanto un log possa aiutare...

Edit: Mi ero dimenticato il dile del log

[biv2533]

Procedura di emergenza autolanding

Ho visto in rete un video dove un quadricottero, a seguito della rottura di una elica un fermo di un motore o di un regolatore, con soli 3 motori anzichè iniziare a flippare come un matto come solitamente avviene in questi casi, inizia un balletto, una specie di autorotazione controllata e bene o male atterra ad una velociità sufficiente a non fare danni, certo non un atterraggio perfetto, ma se paragonato allo schianto che avrebbe fatto in altre condizioni, più che onorevole.

Credo che il software che gestisce questa cosa sia protetto da brevetto.
E' una cosa pensabile o per il momento ci sono altre problematiche da affrontare?

Inutile dire che se mi ricordassi dove ho visto il video lo posterei qui

[biv2533]

Ecco lo avevo visto di DYI Drones.

[ciskje]

Occribbio, dubito però che sia possiible senza emettitori statici.

[Bobo67]

Invece Fra io credo di si, riflettici, ruotando molto velocemente e dando opportune smotorare nei punti giusti riesci a farlo stare in equilibrio, ovviamente il codice deve lavorare strabene per farlo.
Se guardi al rallentatore il video ti rendi conto di quello che fa.
Non credo sia impossibile ma sicuramente quell'algoritmo non è cosa da poco.

[danveal]

E' un codice dell' ETH in corso di brevetto, dicono che è una routine che tecnicamente si puo' facilmente aggiungere in tutti i software commerciali e non, gia esistenti.
Ovviamente si dovranno pagare le royalties...

[Bobo67]

Il funzionamento è abbastanza semplice, dei 3 motori restanti fai girare più velocemente i due sani sullo stesso asse, e con l'altro rimasto vivo dai accelerazioni progressive "sui 180° opposti", praticamente "due sgasate" per giro completo, in questo modo simuli il sostentamento del motore mancante, oppure mi pare vengano sistematicamente impartite quando il quad si trova col motore spento "in alto".
Infatti il quad viene fatto ruotare molto velocemente perchè con l'inerzia data dalla massa rotante il giochetto è più facile, poi chissà quali altri algoritmi subentrano.
Sicuramente è un codice abbastanza cazzuto, peccato non sarà disponibile sulle piattaforme open source, e che certamente non funzionerà su tutte le configurazioni, devi avere abbastanza potenza per gestire questa cosa.
Inoltre quel test è fatto in una stanza chiusa, senza agenti atmosferici esterni, e pilotato in infrared da un computer, non credo da un codice a bordo del quad, "è un occho esterno" che ne valuta posizione e correzioni.

[danveal]

Parole dello sviluppatore:

During normal flight, a quadcopter can produce three independent torques to control its attitude: ‘roll,’ 'pitch,' and ‘yaw,’” says Müller. “If a propeller fails, this is no longer possible--the strategy for our algorithm is to give up the yaw torque, and let the machine spin uncontrolled about this axis. We then use the remaining propellers to tilt this axis of rotation, allowing the machine to move around.”

“The hardest part of the work was the initial mathematics,” says Müller. “How [do you] describe the system in a way that captures the relevant dynamics, but is still simple enough for us to analyze and manipulate? We started with Euler's law--a set of three differential equations that describe the rotation of a body as a function of the torques applied to that body. These equations are a gold mine of unexpected and surprising results, and trying to wrap our heads around this was probably the biggest challenge.”

If the initial mathematics proved a steep learning curve, however, what surprised Müller about the eventual algorithm was its conceptual simplicity. “The derivation is quite complex, and required a lot of time,” he continues. “The implementation on a quadcopter was relatively simple. The control law that we use (the set of equations that calculate the required motor forces) ends up being very concise: To calculate the motor forces only requires a handful of multiplications and additions.”

[Bobo67]

E' chiaro, è farlo che ci vogliono due zebedei così!

[Bobo67]

Pixhawk....

Non so se avete intenzione d'ordinarla ma vi consiglio d'aspettare, sto trovando una serie di pippe che se non vengono risolte non ne vale la pena, piuttosto una VR Brain ed andate sul sicuro.
Vi aggiorno...

https://groups.google.com/forum/?hl=...ss/jt7V6pwpDGc