Arduino Uno accoppiato al controller di volo.

[lost_angel133]

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.

A prescindere che tutte le operazioni dovrebbero sempre effettuarsi in VLOS. In ogni caso puoi provare in qualsiasi momento a riguadagnare il controllo del mezzo switchando flight mode. Quindi siamo sempre in ambito di volo automatico e non autonomo perchè la mano del pilota può intervenire in qualsiasi momento.

[PelanDrone]

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????

Credo che tu ti riferisca al bitrate di trasmissione e non c'entra nulla, a parte il fatto che i 22mS sono non eliminabili..
L'Arduino non deve trasmettere nulla, ma elaborare direttamente i dati e passarli dall'altra parte.

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....

e chi li sente?
Il fatto che quando dai un comando sull'RC questo ci impieghi 50ms ad arrivare alla scheda di volo cosa cambia? Forse se parliamo di volo acrobatico....
Mi preoccuperei molto di più della fedeltà del segnale (su questo posso avere qualche dubbio in più) piuttosto che di ritardi dell'ordine di piccole frazioni di secondo....

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...

Bravo!
Io purtroppo con i droni ho appena iniziato, ma di elettronica qualcosa ne capisco

[dtruffo]

A prescindere che tutte le operazioni dovrebbero sempre effettuarsi in VLOS. In ogni caso puoi provare in qualsiasi momento a riguadagnare il controllo del mezzo switchando flight mode. Quindi siamo sempre in ambito di volo automatico e non autonomo perchè la mano del pilota può intervenire in qualsiasi momento.

Se l'RTH e' subentrato per perdita di segnale, hai voglia a switchare. Non e' detto che lo riagganci, quindi e' autonomo (per estremo, ti cade la radio e si rompe).

[Hitman]

Urca il discorso si fa interessante!
Allora, credo che tutti sappiate che quando si sposta e si mantiene una determinata posizione con uno stick della radio non è un mero on/off ma c'è una continua trasmissione di segnale da parte della radio che la ricevente interpreta e trasmette al servo o all'esc sotto forma di onda quadra di ampiezza di tot millisecondi che il servo interpreta come " spostati da posizione 0° portati a posizione tot° e restaci".
Ora immaginiamo, per un discorso di esclusione degli impercettibili movimenti del dito umano, di assegnare il canale di virata dallo stick ad un più stabile commutatore a 3 posizioni che c'è di solito sulle radio....configurandolo su=dx - giù=sx - e centro tale è.
Quando spostiamo il commutatore in una delle tre posizioni la radio inizia a sparare segnali alla ricevente che a sua volta li inoltra in modo continuativo al servo o all'esc.
Sottolineo continuativo poiché se così non fosse , il servo o l'esc tornerebbero in stato di riposo a tot°.
Da qui ne deriva che, per far eseguire una manovra di virata da Arduino, il suddetto dovrebbe "loop are" una stringa di comando in modo continuativo per tot tempo alla main di volo, senza però sapere nulla delle condizioni di assetto rilevate dalla main stessa che è dotata di giroscopio e gps. Fin qui tutto ok (forse) se le condizioni del volo sono stabili!
Ma immaginiamoci, impegnati in questa benedetta virata, di essere colti da una raffica di vento traverso......immediatamente noi umani ridurremmo, o nel caso del commutatore, porteremmo in posizione centrale, il comando di virata per mantenere un'assetto stabile in caso di aereo/ elicottero oppure ,nel caso di un drone, permettere una stabilizzazione di assetto da parte della flight board.
Questo perchè noi altri siamo dotati di occhi e ci rendiamo conto se stiamo eccedendo in una manovra a causa di agenti esterni.....cosa che qualunque arduino (ovviamente non intendo arduino pilot etc etc.) non fa poiché non ha giroscopio, non ha gps non ha nulla che lo informi di eventuali agenti esterni che influenzino o meno l'assetto di manovra.....lui esegue comandi....trigger>scketh con riga di comando speed=map etc.etc.> write Mircoseconds e parte di virata per il tempo da noi impostato! bello direte voi; Si dico io....ma se in quel lasso di tempo un agente esterno aumenta il rateo di virata o manda in crisi l'assetto, Arduino se ne frega e prosegue nella manovra mentre la povera Flight board impazzisce nel provare a non eccedere i limiti di volo....tutto questo finchè arduino non finisce di eseguire il comando oppure noi riprendiamo il controllo del mezzo escludendo l'arduino, ammesso di riuscire a farlo in tempo nel caso di un drone!
Siete voi forse in grado di ovviare a questa ed altre variabili magari scrivendo uno sketch da 10 mega?
Se così fosse mi prostro e vengo a lezione da voi!

[BBC25185]

Credo che tu ti riferisca al bitrate di trasmissione e non c'entra nulla, a parte il fatto che i 22mS sono non eliminabili..
L'Arduino non deve trasmettere nulla, ma elaborare direttamente i dati e passarli dall'altra parte.

Non ci sono BitRate in PPM... ci sono solo i canali in PWM che passano...
E sono creati in uS... non sono digitali!!!! Quindi buon Sync.

e chi li sente?
Il fatto che quando dai un comando sull'RC questo ci impieghi 50ms ad arrivare alla scheda di volo cosa cambia? Forse se parliamo di volo acrobatico....
Mi preoccuperei molto di più della fedeltà del segnale (su questo posso avere qualche dubbio in più) piuttosto che di ritardi dell'ordine di piccole frazioni di secondo....

Non sono solo 50ms... sono 50ms che aggiungi a quelli che già ci sono tra TX e RX...

[PelanDrone]

Non ci sono BitRate in PPM... ci sono solo i canali in PWM che passano...
E sono creati in uS... non sono digitali!!!! Quindi buon Sync.


Non sono solo 50ms... sono 50ms che aggiungi a quelli che già ci sono tra TX e RX...

Fermo restando che trovo piuttosto condivisibili le obiezioni di Hitman (raffiche di vento e altro)..
A livello assolutamente speculativo, ci stiamo facendo pippe mentali sui timer e sui ms di delay, ma secondo te, che sicuramente ne capisci più di me di droni e controller, una soluzione molto più semplice tipo trasferire direttamente l'input sull'output in volo normale quali controindicazioni potrebbe avere?
Mi spiego meglio una roba del tipo:

void loop() {
if(voloNormale){
digitalWrite(out1,digitalRead(in1));
digitalWrite(out2,digitalRead(in2));
digitalWrite(out3,digitalRead(in3));
digitalWrite(out4,digitalRead(in4));
}
else {
........
}
}

cioè in volo normale l'input del canele viene trasferito direttamente all'otput.
A seguito del trigger dell'evento (voloNormale=FALSE) Arduino prende il controllo:
1) mettendo gli output in una posizione nota (livellato)
2) eseguendo la manovra richiesta agendo sugli output
3) restituendo il controllo all'RC

Converrai con me che il delay in questo caso è prossimo allo 0.
Vedo solo una criticità nel momento in cui si passa da una modalità all'altra in quanto i "frame" dei segnali dal ricevitore vengono spezzati bruscamente, ma si tratta di una situazione che ha una durata di tempo minuscola.
Credo che la scheda di volo possa sopravvivere, ma ripeto, mi intendo di Arduino/elettronica, ma sono nuovo al mondo dei droni.
Capisco la gestione dei servocomandi perchè li uso in ambito robotico, ma il resto lo sto scoprendo a poco a poco.

Cosa ne pensi?


P.S. ovviamente non rischierei mai il mio drone con una robaccia del genere...

Approfitto per fare i complimenti a questo Forum al quale mi sono appena unito e che offre spunti veramente interessanti (soprattutto per neofiti comer me)

[BBC25185]

Il problema di quella roba sopra sono 2:
A) non leggi i dati quindi non sai quando azioni l'interruttore...
perdi moltissima precisione (considera che per avere 10bit di precisione hai 16 cicli di clock per sentire il fronte del segnale... A 8 bit, ne hai 64... Considerando che un digitalwrite ne usa circa 60...) Senza considerare che, nel frattempo, ci sono le istruzioni usate da millis() e micros() che occupano altro tempo e possono ritardare il comando fino a 17 us...

Usando, invece, gli interrupt e i timer questo problemi non ci sono...

Inviato dal mio SM-N920C utilizzando Tapatalk

[PelanDrone]

Il problema di quella roba sopra sono 2:
A) non leggi i dati quindi non sai quando azioni l'interruttore...

Il codice per leggere l'interruttore manca, mi interessava solo illustrare la parte di bypass.
Si può tranquillamente usare un interrupt o aggiungere un digitalRead alla fine del loop (perdendo ancora qualcosa)

perdi moltissima precisione (considera che per avere 10bit di precisione hai 16 cicli di clock per sentire il fronte del segnale... A 8 bit, ne hai 64... Considerando che un digitalwrite ne usa circa 60...) Senza considerare che, nel frattempo, ci sono le istruzioni usate da millis() e micros() che occupano altro tempo e possono ritardare il comando fino a 17 us...

infatti, come anticipato nell'intervento precedente, la mia perplessità era la precisione.
Parliamo comunque di microsecondi, forse è accettabile.

Usando, invece, gli interrupt e i timer questo problemi non ci sono...

...ma se ne creano altri, che sono più o meno le perplessità che hai espresso circa la complessità di scrivere un codice che non abbia delay significativi.....

Non resterebbe che fare qualche prova.
Spero le faccia il buon Probolo che ha posto il quesito ora che gli abbiamo dato un po' di elementi su cui riflettere.

Io non ho alcuna intenzione di provarci

[Hitman]

...ah se è per questo neanche io...il mio esa ferro da stiro autocostruito classe 750mm per 4,8 kg di peso vola egregiamente con la sua main dji e compagnia bella e nei test da me eseguiti di volo automatico a waypoint con prua fissa e non, l'elettronica dji fa egregiamente in suo mestiere di pilota. Test eseguiti in Molise dove il vento e le ascensionali non scherzano! E' pur vero che per smuovere 4 kili e otto con baricentro volutamente a 15cm sotto il piano delle eliche è dura....ma per la miseria, tiene il vento traverso che è una bellezza

[BBC25185]

Il codice per leggere l'interruttore manca, mi interessava solo illustrare la parte di bypass.
Si può tranquillamente usare un interrupt o aggiungere un digitalRead alla fine del loop (perdendo ancora qualcosa)



infatti, come anticipato nell'intervento precedente, la mia perplessità era la precisione.
Parliamo comunque di microsecondi, forse è accettabile.


...ma se ne creano altri, che sono più o meno le perplessità che hai espresso circa la complessità di scrivere un codice che non abbia delay significativi.....

Non resterebbe che fare qualche prova.
Spero le faccia il buon Probolo che ha posto il quesito ora che gli abbiamo dato un po' di elementi su cui riflettere.

Io non ho alcuna intenzione di provarci

Forse non hai ben chiaro cosa sia un segnale PPM e come leggerlo...
Il delay che si genera sono i famosi 50ms.... QUELLO é IL DELAY...
i uS sono per il comando.... se non sai di cosa stó parlando, meglio studiarsi cosa é il PPM, il PWM e come viene usato nel modellismo...

Comunque i trucchetti per ridurre i Delay ci sono... e ottenere una buona precisione dei comandi anche... ma é complicato in quanto da adeguare al programma e alle risorse disponibili...
Lavorare con gli interrupt???? si puó... ma non sempre sono disponibili oppure fattibile... (gli interrupt sono limitati come numero e alcuni sono giá usati...)

PS: il programma puó avere anche dei delay molto alti... l'importante é che alcune funzioni devono avere alcune prioritá rispetto ad altre...
Esempio... un Display collegato non mi interessa che venga aggiornato 50 volte al secondo... ma mi interessa che se arriva il segnale del comando mentre stó scrivendo lo schermo, interrompa la scrittura per leggere il segnale e, poi, riprenda la scrittura dello schermo... Oppure che scriva lo schermo quando si sá che non riceverá nessun segnale in quel lasso di tempo!!!

[PelanDrone]

Forse non hai ben chiaro cosa sia un segnale PPM e come leggerlo...

Il delay che si genera sono i famosi 50ms.... QUELLO é IL DELAY...
i uS sono per il comando.... se non sai di cosa stó parlando, meglio studiarsi cosa é il PPM, il PWM e come viene usato nel modellismo...

Comunque i trucchetti per ridurre i Delay ci sono... e ottenere una buona precisione dei comandi anche... ma é complicato in quanto da adeguare al programma e alle risorse disponibili...
Lavorare con gli interrupt???? si puó... ma non sempre sono disponibili oppure fattibile... (gli interrupt sono limitati come numero e alcuni sono giá usati...)

PS: il programma puó avere anche dei delay molto alti... l'importante é che alcune funzioni devono avere alcune prioritá rispetto ad altre...
Esempio... un Display collegato non mi interessa che venga aggiornato 50 volte al secondo... ma mi interessa che se arriva il segnale del comando mentre stó scrivendo lo schermo, interrompa la scrittura per leggere il segnale e, poi, riprenda la scrittura dello schermo... Oppure che scriva lo schermo quando si sá che non riceverá nessun segnale in quel lasso di tempo!!!

Quindi avevo ragione dall'inizio! È fattibile!

Comunque ti ringrazio per le esaurienti spiegazioni, ma come ti ho già scritto utilizzo Arduino da diversi anni in applicazioni reali nel campo dell'industria.
Ti assicuro che non ho problemi con concetti come pwm timing timer interrupt: ho superato quella fase da un po'
Scrivo programmi in vari linguaggi da più di 30 anni ed ho iniziato su macchine/microcontrollori (qualcuno ha mai sentito 68HC05?) dalle risorse talmente scarse e su cui l'ottimizazione era veramente importante.

Mi andrò volentieri a studiare le interazioni con i radiocomandi in campo modellistico sulle quali non so quasi nulla a parte far muovere servocomandi con le librerie apposite.

a presto!

[picoely]

Il 68HC05 Motorola! 1986! Anni in meno e neuroni in più!

[BBC25185]

Ma... Scusa... Se hai tutta questa esperienza etc etc... Sapendo le limitazioni a cui vai incontro (le abbiamo dette) che razza di conferma ti serviva, scusa??? Che l'arduino può leggere e generare un segnale PPM??? Mi pareva abbastanza ovvio visto che il MultiWii legge, appunto, il PPM e, in più, stabilizza il drone...
Comunque ho paura che con l'Hubsan non fai nulla... Però verifica... Non si sa mai se, per caso, sei fortunato....

Inviato dal mio SM-N920C utilizzando Tapatalk

[PelanDrone]

[QUOTE=BBC25185;5002773]Ma... Scusa... Se hai tutta questa esperienza etc etc... Sapendo le limitazioni a cui vai incontro (le abbiamo dette) che razza di conferma ti serviva, scusa???
[/quota]
Assolutamente nessuna!
Dall'inizio ho sempre affermato che era possibile senza "grandi" difficoltà.
Capisco che il "grandi" è relativo....
Qualcun'altro ha sollevato questioni di fattibilità....

[PelanDrone]

Ma... Scusa... Se hai tutta questa esperienza etc etc... Sapendo le limitazioni a cui vai incontro (le abbiamo dette) che razza di conferma ti serviva, scusa???

Assolutamente nessuna!
Dall'inizio ho sempre affermato che era possibile senza "grandi" difficoltà.
Capisco che il "grandi" è relativo....
Qualcun'altro ha sollevato questioni di fattibilità....