Arduino Uno accoppiato al controller di volo.

[L4kyITA]

Per absinth84

Ah! Finalmente un dialogo civile! Almeno con te possiamo cominciare una discussione.

Grazie absinth.
Non credo sia necessario un reverse-engineering (me ne guardo bene!), a quel punto sarei passato direttamente ad ArduPilot, ma , come detto , non è quello che cerco per ora.

Forse farei meglio a far colloquiare Arduino via radio. Ma fin' ora non ho trovato uno shield adatto. Sto cercando.
Mi spiego : se Arduino potesse impartire dei segnali di direzione al drone, sempre via radio, per me sarebbe sufficiente. E probabilmente farò così. Siggerimenti bene accetti.

Riguardo ai milioni di gundam che mi hanno preceduto: se ne avessi trovato traccia nelle discussioni precedenti magari mi sarei fermato prima. Suggerirei di non cancellarne le discussioni, per quanto mi sia accorto che qui risultino particolarmente indigeste.
Un saluto.

Il problema è che tu la fai facile e non capisci dell' infinità di ostacoli sia hardware che software presenti per fare "colloquiare Arduino" per impartire comandi.

Cosa vorresti fare? Interrompere il canale della ricevente e per tot tempo impartire un comando diverso? Sai cosa vuol dire? Che in caso di vento o tanti altri fattori non avrai mai i 90° di rotazione..

Per fare un lavoro decente ci vuole una quantità di tempo, conoscenze e soldi che ti conviene comprare una FC decente e fare quel che vuoi fare.


Concordo comunque il volo automatico è vietato e andrebbe anche punito severamente ( attenzione: per automatico intendo che la FC prende il controllo del mezzo e voli per waypoint a coordinate e altitudini preimpostate e senza un intervento di un umano tramite radiocomando, mentre il volo assistito, incluso RTH, lo considero una sicurezza che, a mio parere, molti non riconoscono... incluso ENAC )

[BBC25185]

Per absinth84

Ah! Finalmente un dialogo civile! Almeno con te possiamo cominciare una discussione.

Grazie absinth.
Non credo sia necessario un reverse-engineering (me ne guardo bene!), a quel punto sarei passato direttamente ad ArduPilot, ma , come detto , non è quello che cerco per ora.

Forse farei meglio a far colloquiare Arduino via radio. Ma fin' ora non ho trovato uno shield adatto. Sto cercando.
Mi spiego : se Arduino potesse impartire dei segnali di direzione al drone, sempre via radio, per me sarebbe sufficiente. E probabilmente farò così. Siggerimenti bene accetti.

Riguardo ai milioni di gundam che mi hanno preceduto: se ne avessi trovato traccia nelle discussioni precedenti magari mi sarei fermato prima. Suggerirei di non cancellarne le discussioni, per quanto mi sia accorto che qui risultino particolarmente indigeste.
Un saluto.

Dunque...
A) I milioni di progetti Gundam sono ancora presenti sul forum... se non li hai trovati, vuol dire che non hai cercato bene
B ) Se avessi usato un pò di pazienza, usato il tasto cerca del forum e su Google, avresti scoperto molto facilmente LE BASI del modellismo... come funzionano i comandi etc etc... basi che anche l'Arduino UNO usa per i suoi esempi... quindi se non li hai visti, inizio a dubitare che tu abbi cercato...
C) Usare la scheda arduino collegata a una qualunque FC è una idea che avrò visto almeno 10 volte tra i vari post del barone... e a tutti è stato risposto più o meno la stessa cosa: ILLEGALE, Non sicuro e, sopratutto, NON FUNZIONALE (come qualcuno ha fatto notare... se non hai riscontro come fai a dirgli "ruota di 90"... è come chiedere di andare a 90 all'ora con l'auto senza vedere il contachilometri)
D) Se sei così esperto di programmazione come fai intendere e hai tanta voglia di usare un Arduino, perchè non provare a mettere mano al codice MultiWii??? Usa Arduino... è Open Source... Funziona... Ovviamente è un pò complesso ed è da studiarci un bel pò prima di poter mettere mano!!!
E) Se non hai voglia di mettere mano al codice di una FC, allora potresti studiarti come funzionano le varie Ground Station - OSD che comunicano direttamente con la FC... però penso sia più difficile... (Comunque cercando si trovano informazioni)

Come vedi abbiamo molti motivi per dire che sei uno che vuole la pappa pronta... In più non vuoi neanche dire cosa vuoi fare... quindi ancora più dubbi!!!
Di Thread aperti con "Ho una idea fantastica, mi dovete aiutare a realizzarla" ne sono stati aperti decine e decine... Basta cercarli!!!!

[Hitman]

...oltretutto, in soldoni, far interfacciare l'arduino con una piattaforma di flight control,
per far fare a qualunque cosa sia il tuo progetto, una virata di 90°, presuppone il controllo da parte del suddetto, della velocità di rotazione di uno o più motori.
Cosa di per se fattibilissima, ma, essendo l'arduino uno una scheda di sviluppo prototipi, non ha nativamente la possibilità di dialogare con un servo o con un esc in modo diretto con un controllo dedicato ma deve utilizzare delle librerie che gli consentano di "tradurre" il movimento in gradi (nel caso di un servo) in impulsi pmw rilasciati poi su una delle uscite in microsecondi. Questo va fatto per il controllo automatico di ogni singolo giro completo di un brushless per esempio. prova tu ad immaginare di dover dire ad un motore del tuo drone o qualunque cosa stai costruendo, di diminuire un 5% di potenza su uno degli ipotetici 4 motori ed allo stesso tempo verificare eventuali eccessive velocità di rotazione, perdite di quota, controllare l'assetto per determinare la fine dell'ipotetica virata senza considerare vento, ed altre variabili non programmabili su arduino uno.
Ok che buona la metà di chi scrive qui, le cose se le studia e fa da solo, ma in questo caso nonostante io apprezzi l'ingegno, ti consiglio vivamente di optare per una altra soluzione tipo ground station o altro dopo aver ben considerato che come già detto, che non è propriamente legale.

Per il resto, buon progetto

[PelanDrone]

Io vedo una soluzione relativamente semplice al problema.

Colleghi le uscite della ricevente dei 4 canali principali nelle entrate AN di Arduino (o con rete RC).
Fai in modo che Arduino legga i valori e li riporti fedelmente (puoi utilizzare la libreria servo) su 4 uscite e le colleghi ai 4 comandi principali della flight board.

In questo modo, in funzionamento normale, Arduino non fa altro che "passare" le informazioni alla scheda.

Quando c'è il trigger dell'evento Arduino può intervenire sostituire i comandi, per esempio iniziando una rotazione di una certa durata.
La flightboard continua comunque a fare il suo lavoro tenendo livellato il mezzo quindi non dovrebbero esserci crash. In pratica è come se ricevesse un normale comando da parte dell'RC.

Se vuoi controllare con precisione la rotazione non ti resta che acquistare un piccolo modulo magnetometro che costa meno di 2 euro sui siti specializzati e lo colleghi ad arduino. Una volta calibrato correttamente è abbastanza preciso (li ho usati in alcuni piccoli robot terrestri per fare angoli di 90°)

Puoi testare il tutto facilmente a terra con i vari strumenti di debugging di Arduino.

[Probole]

Hitman, mi par di capire che è meglio cercare un' altra strada.
Se il drone potesse essere ingannato (da verificare) con una seconda unitá di trasmissione , tipo https://italian-makers.com/it/moduli...r-arduino.html
tutti (meno uno) i problemi che hai segnalato verrebbero bypassati.
Mi devo chiarire parecchie i
dee sulla tecnica di accoppiamento rc_drone.
Qualcuno mi sa consigliare delle fonti valide?
Grazie.

[Probole]

Grazie Fabrizio, ho letto tardi la tua. Faró qualche prova e poi riprendiamo il discorso.

[Probole]

Grazie a L4kyITA : Volo assistito.

[Hitman]

Io vedo una soluzione relativamente semplice al problema.

Colleghi le uscite della ricevente dei 4 canali principali nelle entrate AN di Arduino (o con rete RC).
Fai in modo che Arduino legga i valori e li riporti fedelmente (puoi utilizzare la libreria servo) su 4 uscite e le colleghi ai 4 comandi principali della flight board.

In questo modo, in funzionamento normale, Arduino non fa altro che "passare" le informazioni alla scheda.

Quando c'è il trigger dell'evento Arduino può intervenire sostituire i comandi, per esempio iniziando una rotazione di una certa durata.
La flightboard continua comunque a fare il suo lavoro tenendo livellato il mezzo quindi non dovrebbero esserci crash. In pratica è come se ricevesse un normale comando da parte dell'RC.

Se vuoi controllare con precisione la rotazione non ti resta che acquistare un piccolo modulo magnetometro che costa meno di 2 euro sui siti specializzati e lo colleghi ad arduino. Una volta calibrato correttamente è abbastanza preciso (li ho usati in alcuni piccoli robot terrestri per fare angoli di 90°)

Puoi testare il tutto facilmente a terra con i vari strumenti di debugging di Arduino.

...quando avviene il trigger dell'evento, arduino passa agli esc e conseguentemente ai motori quello che gli è stato detto di fare tramite scketh, e cioè in questo caso, ridurre i giri di un motore per tot tempo per eseguire una virata e non di eseguire una virata controllata da eventuale giroscopio. In questo caso i comandi di volo impartiti dalla flight platrform passando da arduino non verrebbero semplicemente by-passati ma corretti da Arduino che dovrebbe allo stesso tempo, come già detto, ridurre i giri motore su uno o più, ed allo stesso tempo controllare l'assetto del mezzo.
Si avrebbe quindi una situazione in cui la radio impone ad arduino tramite trigger uno stato......arduino mette in opera quanto è stato programmato a fare( es. riduzione 5% giri motore)...il motore ovviamente esegue il comando ma la flight Platform all' oscuro di quanto sta accadendo in quanto non puoi scollegarla neanche momentaneamente, rileva una variazione di assetto che il giroscopio tenta di correggere invano andando a compensare l'evento rilevato;e lo fa nella migliore delle ipotesi andando ad aumentare i giri del motore rallentato da arduino il quale correggerebbe riducendo del 5% arrivando in una posizione di neutralità ed assetto stabile, nella peggiore delle ipotesi la flight potrebbe correggere riducendo o peggio ancora aumentanto i giri del motore sull'asse opposto ed in considerazione del fatto che quanto su detto va (credo) installato su un aggeggio volante e non un robot, a te le dovute conclusioni.

Il discorso cambia se fosse arduino interfacciato a monte della ricevente e quindi di tutto il sistema di stabilizzazione, ad impartire alla flight Platform di virare (come se tu impartissi un comando dalla radio). In questo caso tutto andrebbe secondo i piani MA, caro Fabrizio, se tu fossi in grado di interfacciare un radiocomando ad arduino afffinchè quest'ultimo esegua fedelmente i tutti comandi della radio ( SENZA DELAY PERo') e all'occorrenza attivando un tasto esegua il trigger richiesto per tot secondi per poi tornare in uno stato di stand-by.....invitami per un caffè che avrei bisogno di farti parecchie domande

[PelanDrone]

.....
Il discorso cambia se fosse arduino interfacciato a monte della ricevente e quindi di tutto il sistema di stabilizzazione, ad impartire alla flight Platform di virare (come se tu impartissi un comando dalla radio). In questo caso tutto andrebbe secondo i piani

È esattamente quello che ho proposto di fare se leggi bene.
Lungi da me voler controllare direttamente i motori: quello lo fa già bene la scheda di volo.

MA, caro Fabrizio, se tu fossi in grado di interfacciare un radiocomando ad arduino afffinchè quest'ultimo esegua fedelmente i tutti comandi della radio ( SENZA DELAY PERo') e all'occorrenza attivando un tasto esegua il trigger richiesto per tot secondi per poi tornare in uno stato di stand-by.....invitami per un caffè che avrei bisogno di farti parecchie domande

Il DELAY sarebbe dell'ordine dei millisecondi e, comunque, tale da non fare alcuna differenza rispetto ai comandi impartiti dall'operatore umano (che ha tempi di reazione/decisione moooolto più lunghi)

Per rispondere alla tua domanda... ("se tu fossi in grado di farlo") in realtà vedo difficoltà assolutamente minime.
Prima che tu possa pensare che sto millantando capacità che non posseggo, aggiungo che sono abituato ad utilizzare queste tecnologie in applicazioni reali un bel po' più complesse e dove il timing è critico.

Per il caffè al limite mi inviti tu.

[BBC25185]

È esattamente quello che ho proposto di fare se leggi bene.
Lungi da me voler controllare direttamente i motori: quello lo fa già bene la scheda di volo.

Il DELAY sarebbe dell'ordine dei millisecondi e, comunque, tale da non fare alcuna differenza rispetto ai comandi impartiti dall'operatore umano (che ha tempi di reazione/decisione moooolto più lunghi)

Per rispondere alla tua domanda... ("se tu fossi in grado di farlo") in realtà vedo difficoltà assolutamente minime.
Prima che tu possa pensare che sto millantando capacità che non posseggo, aggiungo che sono abituato ad utilizzare queste tecnologie in applicazioni reali un bel po' più complesse e dove il timing è critico.

Per il caffè al limite mi inviti tu.

Mi spieghi come pensi di avere un delay di qualche ms considerando che l'intero pacchetto di 8Ch impiega, da solo, 22 mS solo per essere trasmesso????
Quindi, interponendolo in mezzo, si avrebbe 22 + 22 mS di ritardo (tempo di ricezione + tempo di trasmissione... senza aggiungere i tempi interni presenti)... quasi 50 ms di ritardo si sentono eccome....
Inoltre.... i comandi inviati devono essere precisi nell'ordine dei uS... altrimenti non vanno bene.... quindi inizia a ragionare su questi numeri e studiati il problema...
Considera che l'Arduino uno ha 3 Timer.... Il Timer 0 (8 bit) viene usato per le funzioni Millis(), Micros(), Delay() e DelayMicroSeconds()... poi c'è il Timer1 (16 bit) che viene usato da alcune librerie per funzionare (ad esempio la libreria SERVO usa il Timer1) e, infine, cè il TIMER2 (8 bit)... usato da pochissime librerie... (ad esempio TONE)...
l'unico modo di avere abbastanza precisione nei comandi è quello di usare questi Timer... SONO INDISPENSABILI per ottenere una buona precisione!!!

Altra cosa che su un sistema del genere riterrei indispensabile è l'uso del WDT!!!

PS: Come si può notare l'Atmega328 che equipaggia l'arduino lo conosco molto bene... sò usare in modo molto buono l'arduino... e conosco bene come funzionano i droni, comandi, interfacce etc etc...

[absinth84]

Mi spieghi come pensi di avere un delay di qualche ms considerando che l'intero pacchetto di 8Ch impiega, da solo, 22 mS solo per essere trasmesso????
Quindi, interponendolo in mezzo, si avrebbe 22 + 22 mS di ritardo (tempo di ricezione + tempo di trasmissione... senza aggiungere i tempi interni presenti)... quasi 50 ms di ritardo si sentono eccome....
Inoltre.... i comandi inviati devono essere precisi nell'ordine dei uS... altrimenti non vanno bene.... quindi inizia a ragionare su questi numeri e studiati il problema...
Considera che l'Arduino uno ha 3 Timer.... Il Timer 0 (8 bit) viene usato per le funzioni Millis(), Micros(), Delay() e DelayMicroSeconds()... poi c'è il Timer1 (16 bit) che viene usato da alcune librerie per funzionare (ad esempio la libreria SERVO usa il Timer1) e, infine, cè il TIMER2 (8 bit)... usato da pochissime librerie... (ad esempio TONE)...
l'unico modo di avere abbastanza precisione nei comandi è quello di usare questi Timer... SONO INDISPENSABILI per ottenere una buona precisione!!!

Altra cosa che su un sistema del genere riterrei indispensabile è l'uso del WDT!!!

PS: Come si può notare l'Atmega328 che equipaggia l'arduino lo conosco molto bene... sò usare in modo molto buono l'arduino... e conosco bene come funzionano i droni, comandi, interfacce etc etc...

Ma 50 o 100ms di ritardo sull'input umano non sono un problema!

Non so che velocità hai tu ma nemmeno flash ha quei tempi di reazione.

L'importante è non averli sull'output verso gli esc atti a stabilizzare.

Con che scopo useresti il wdt? Ci sarebbe solo il rischio di schiantare il modello durante il reboot no?


Secondo me comunque la soluzione più semplice e percorribile è interporsi tra ricevente e fc (probilmente in ppm o sbus) funzionare normalmente in pass-truth e all'occasione modificare il canale prescelto sfruttando un magnetometro per capire quando finire l'intervento.

Agire direttamente sugli esc è impossibile, non ci si può sicuramente collegare in parallelo al segnale pwm di un esc e anche riuscendo in pass-truth si destabilizzerebbe tutto creando una schifezza.

[lost_angel133]

La norma dice che il volo autonomo non e' ammesso. Non specifica se per 1 ora o per 1 secondo.

A mio avviso, considerando che, se qualcosa prende il comando dell'oggetto non e' detto che lo restituisca al pilota, il volo autonomo e' da considerare vietato in qualsiasi caso.

Ma si sa, anche l'FPV e' vietato, lo e' il volo per way-point e in teoria anche l'RTH, ma se ne fregano tutti, quindi che lo usa se ne assume la responsabilita', basta che poi non venga piangere dopo.

Tra l'altro mi chiedo, ma che gusto c'e' a far volare un oggetto che va per i fatti suoi ?? Mi sembra tanto il divertimento che c'e' a guardar asciugare la vernice, ma ovviamente, de gustibus. Verto che pilotare e' piu' difficile che lasciar fare all'elettronica

In ogni caso è bene ricordare la differenza tra volo autonomo e volo automatico.
L'utilizzo e ripeto UTILIZZO, perchè è tutto tranne che volo, di un drone con automatismi quali RTH / WAYPOINT / RTH è legale perchè è presente sempre l'uomo che in qualsiasi momento può riprendere il controllo della macchina.

[BBC25185]

Ma 50 o 100ms di ritardo sull'input umano non sono un problema!

Non so che velocità hai tu ma nemmeno flash ha quei tempi di reazione.

L'importante è non averli sull'output verso gli esc atti a stabilizzare.

Con che scopo useresti il wdt? Ci sarebbe solo il rischio di schiantare il modello durante il reboot no?


Secondo me comunque la soluzione più semplice e percorribile è interporsi tra ricevente e fc (probilmente in ppm o sbus) funzionare normalmente in pass-truth e all'occasione modificare il canale prescelto sfruttando un magnetometro per capire quando finire l'intervento.

Agire direttamente sugli esc è impossibile, non ci si può sicuramente collegare in parallelo al segnale pwm di un esc e anche riuscendo in pass-truth si destabilizzerebbe tutto creando una schifezza.

Utilizzo del WDT indispensabile visto che la scheda si può bloccare (e succede... parlo per esperienza...)
PPM = 44 ms di ritardo senza considerare i tempi di altri calcoli e simili...
Sbus... non usabile in quanto servono 2 invertitori HardWare... (il segnale SBUS è invertito e l'Arduino non ha l'inversione del segnale programmabile).

Ricordati che in PassThought non è così semplice come scriverlo...
Significa leggere correttamente il segnale e riscriverlo senza nessun errore, con il minor tempo possibile e, ovviamente, senza perdere nessun frame... pena altri 28 mS da aggiungere ai 44 ms precedenti per aspettare un altro frame (e siamo a 72mS di ritardo da aggiungere a quelli di trasmissione e quelli di elaborazione della FC...

[dtruffo]

In ogni caso è bene ricordare la differenza tra volo autonomo e volo automatico.
L'utilizzo e ripeto UTILIZZO, perchè è tutto tranne che volo, di un drone con automatismi quali RTH / WAYPOINT / RTH è legale perchè è presente sempre l'uomo che in qualsiasi momento può riprendere il controllo della macchina.

L'RTH in caso di perdita di segnale non e' proprio cosi'. Dovrebbe far atterrare sul posto e non riportare a casa. Se riporta a casa e hai perso il segnale, non sei in grado di riprendere il controllo. Visto che l'RTH ormai viene usato non come emergenza ma come normalita...... mi sa che non e' molto legale.

[PelanDrone]

Ma 50 o 100ms di ritardo sull'input umano non sono un problema!

Non so che velocità hai tu ma nemmeno flash ha quei tempi di reazione.

....

La penso anch'io allo stesso modo!

Se anche fossero 10 centesimi di secondo di ritardo, non cambierebbe nulla.
L'unica cosa importante è che i comandi vengano trasferiti con la massima fedeltà attraverso l'Arduino.
Su questo ho dubbi che ci potrebbe essere un certo errore.
Ma se non stiamo parlando di volo acrobatico e il drone rimane controllabile senza difficoltà dovrebbe andare bene.