[Multicotteri] Elettronica : IMU, MCU, Sensori ed algoritmi di controllo

astrobeed:

dab77:
Scusa, ma perchè dici due Timer? non ne basta uno impostato a 20, o meglio 22ms e fare un ciclo per tutti i canali?

Un timer è il clock di sistema, un timer genera il PPM, io sono abituato a ragionare sempre con un sistema sia event driven (interrupt) che con esigenze ROTS (scheduler degli eventi), per me è la norma avere un sysclock :slight_smile:
Il TINY85 non ha una UART, ha l'USI che è un hardware per comunicazioni seriali castrato :slight_smile: , meglio se vai su una mcu con una vera UART.

Giusto.
Magari (solo perchè ce li ho) uso un attiny2313 che ha USART e 2 Timer...
A questo punto chiedo un piccolo chiarimento. Per quanto riguarda il PPM-SUM, il "vuoto" da lasciare per far da sync al treno di ppm va bene di 4ms? e poi ogni 2ms parte un impulso tra i 1000 e i 2000 uS, e se il canale non è usato 500uS? però mi chiedo, se ho 2 segnali consecutivi da 2ms, devo comunque prevedere un piccolo "vuoto" tra i due?
Perdonatemi se chiedo cose ovvie, è solo perchè tra le info trovate in giro ho trovato alcune discordanze..
Tipo qui danno un buon esempio, ma dal quale si deduce che l'impulso non arriva a 2000 uS, ma un pò di meno.. oltretutto il segnale di sync lungo non è LOW, ma HIGH.. come funziona?

dab77:
A questo punto chiedo un piccolo chiarimento. Per quanto riguarda il PPM-SUM, il "vuoto" da lasciare per far da sync al treno di ppm va bene di 4ms? e poi ogni 2ms parte un impulso tra i 1000 e i 2000 uS, e se il canale non è usato 500uS? però mi chiedo, se ho 2 segnali consecutivi da 2ms, devo comunque prevedere un piccolo "vuoto" tra i due?

Regola generale per il PPMSUM, premesso che può essere sia a logica positiva che negativa, dipende dal tipo di ricevente e nel firmware c'è una opzione per scegliere la logica, di default è logica negativa, ovvero idle a 1 logico e impulsi a 0 logico, la separazione tra i singoli impulsi deve essere almeno 100 us, la durata finale del frame deve essere 100us maggiore della durata massima per l'impulso.
Esempio pratico, tipicamente gli impulsi variano tra 1000 e 2000 us, valori standard e di default previsti da tutti i software, questo comporta che per codificare otto canali, il massimo possibile, servono 2100 * 7 us + 2000 us = 16700 us, separazione per il frame durata minima 2100 us.
Anche se la durata del frame non è obbligatoriamente costante è bene che lo sia, semplifica il lavoro del software di decodifica e garantisce una frequenza costante di refresh dei dati, da questo ne deriva che la durata finale del frame è variabile in funzione della durata dei singoli impulsi.
Nota che sia MultiWii che MegaPirateNG consigliano di regolare la propria radio, se possibile, per emettere impulsi tra 1000 e 2000 us, a seconda di marca e modello tale valore può essere sensibilmente inferiore come default, p.e. tra 1050 e 1950 us con centro a 1500 us come a 1514-1524 us per alcuni modelli di radio.
Domani ti posto una videata del DSO per il PPMSUM in out dalla presa DSC (usata per i simulatori e per mettere due radio in master/slave) del mio Tx (una Aurora 9 Hitech) così hai una misura reale del segnale a cui fare riferimento.
Comunque tutti i software per multi consentono di impostare sia il valore per il centro che quello degli estremi da software se non è possibile farlo sulla radio.

Magari! intanto grazie, della possibilità di logica positiva o negativa non avevo trovato notizie in rete, anche se però le immagini le trovavo in entrambi i modi. Per questo ero confuso sul segnale di link..
anche dalla tua spiegazione però c'è un solo punto che non ho capito. parli di mantenere possibilmente la durata del frame uguale, e mi sembra più logico (anche in fase di misurazione/debug risulterebbe più semplice..), però poi dici che "da questo ne deriva che la durata finale del frame è variabile in funzione della durata dei singoli impulsi."... Per quello che ho capito in realtà se tra due canali lascio 100uS o lascio 100uS+i uS restanti a colmare i 2000uS del segnale massimo, al software che riceve non cambia nulla, giusto?
forse è solo più semplice da programmare lasciare 100uS fissi tra un canale e l'altro..

dab77:
però poi dici che "da questo ne deriva che la durata finale del frame è variabile in funzione della durata dei singoli impulsi."...

Intendevo dire che la durata finale in stato di idle è variabile, in funzione della durata dei singoli impulsi, in modo da ottenere sempre un frame di durata costante, p.e. il classico 20 ms pari a 50 Hz.

ah, avevo capito male! quindi, ricapitolando:
sync -> ( impulso HIGH ch1 variabile -> impulso LOW 100uS ) ripetuto per 8ch -> impulso HIGH variabile a colmare i 20mS(sync)

ma, che tu sappia, si usa anche di fare l'impulso LOW variabile per singolo canale?

dab77:
ma, che tu sappia, si usa anche di fare l'impulso LOW variabile per singolo canale?

L'ho visto sulle vecchie radio analogiche dove il PPMSUM era creato con una cascata di monostabili, ma è preistoria :slight_smile:
Attualmente tutti i sistemi RC sono totalmente digitali gestiti con micro, la generazione del PPMSUM è precisa sia nelle tempistiche che nelle separazioni.
Tieni presenti che i valori indicati sono quelli sicuri e molto conservativi, puoi trovare sistemi radio che sul PPMSUM usano solo 10 us di separazione e impulsi compresi tra 1100 e 1900 us in modo da poter codificare 9 canali invece di otto.
Attualmente tutte le radio di recente uscita usano solo sistemi di codifica digitale per la trasmissione dei canali, il che permette di avere Tx da 9-10-12-14 canali, cosa impossibile con i vecchi sistemi, e sta prendendo sempre più piede non usare le singole uscite PPM per i servo/esc ma un sistema a bus, p.e. l'S.BUS di Futaba, in modo da eliminare i grovigli di fili semplificando il cablaggio e aumentare la velocità di risposta dei device.

e immagino tu ti riferisci a questo.
Ok, grazie molto per le spiegazioni.
Se poi hai tempo di postare una lettura del tuo ppm-sum sarebbe un gesto molto gradito.

Allora mi metto al lavoro sulla schedina ppm-encoder.. a presto!

dab77:
e immagino tu ti riferisci a questo.

Questo è il vecchio sistema PCM, modulazione numerica digitale con informazione numerica che consentiva una risoluzione di 1024 step su 90°, il precedente sistema di modulazione analogica su segnale AM/FM al massimo consentiva non più di 600 step reali.
Attualmente si usano sistemi radio a 2.4 GHz che sono simili ad un cellulare GSM per come lavora la parte RF, numero di canali trasmissibile virtualmente illimitato, risoluzione fino a 4096 step (a mio avviso assolutamente inutile), la cosa migliore di questi sistemi radio, oltre all'elevata immunità ai disturbi, è che lavorano su più canali in automatico cambiandoli come serve ed è possibile usare più sistemi radio in contemporanea senza darsi fastidio.
Per contro i sistemi radio a 2.4 GHz possono soffrire di problemi di latenza, quando piloti un modello rc anche pochi ms si fanno sentire, c'è voluto del tempo per risolverli.
Attualmente tutte le radio dei produttori principali sono perfette e affidabili, molte hanno sistemi radio bidirezionali che consentono di ricevere informazioni telemetriche dalla ricevente, che è anche un Tx, incluso anche l'uso di un GPS per sapere a che distanza, quota si trova un modello, la sua velocità e le esatte coordinate per ritrovarlo in caso di incidente.

intanto ho trovato questo pdf sul ppm per chi fosse interessato:
http://www.omegaco.demon.co.uk/mectnpdf/mectn004.pdf

Ecco un paio di misure dirette del PPM in uscita dal mio Tx Hitec Aurora 9, la prima è tutto il frame dei nove canali, la seconda il dettaglio del primo canale.
Mi sono ricordato che a seconda del numero di canali il separatore può essere utilizzato per comporre la durata complessiva dell'impulso, nel caso della Aurora 9 il separatore è di 400 us e va sommato con l'impulso per ottenere la durata reale, nel dettaglio del canale 1 lo stick è al centro e sono 1500 us complessivi sommando il separatore, la logica è negativa, idle a 1.

frame.bmp (146 KB)

first.bmp (146 KB)

mmm ok, quindi i LOW fissi a 400uS e gli HIGH vanno da (1000-400)uS minimo a (2000-400)uS massimo. immagino che la tua Aurora fa così per farci stare comodi 9ch in 20ms (2000uS * 9 = 18ms), anche se poi lascia 10ms (?) di HIGH per il Sync.
Perchè chiami questa logica negativa? l'idle è HIGH e il segnale del singolo canale è HIGH..

dab77:
anche se poi lascia 10ms (?) di HIGH per il Sync.
Perchè chiami questa logica negativa? l'idle è HIGH e il segnale del singolo canale è HIGH..

Dove li vedi 10 ms ?
La logica è negativa perché lo stato di idle è positivo.

No, in effetti non li vedo, c'è un solo frame d'impulsi, ma vedo che prima e dopo ce n'è di idle, e ne conto circa 9ms anche se potrebbero essere di più, o sbaglio?

dab77:
No, in effetti non li vedo, c'è un solo frame d'impulsi, ma vedo che prima e dopo ce n'è di idle, e ne conto circa 9ms a

Il prima non conta nulla visto che è legato al trigger, in questo caso settato in modalità larghezza d'impulso maggiore di 3 ms, in realtà la fine del frame si trova esattamente alla fine della videata e sono esattamente 20 ms.
Va da se che a seconda della durata dei nove impulsi il periodo di sync può arrivare anche a 11 ms, però la durata complessiva degli impulsi sarebbe solo 9 ms perché sono tutti al minimo possibile.

Ok, questa è la copia del segnale che esce dall'Aurora di Astrobeed.
ho fatto un treno di 8 impulsi che vanno HIGH da 600uS a 1600uS ogni 20ms.
la seconda immagine è uno zoom su i primi due canali con il primo al minimo (600uS) e il secondo a palla (1600uS)
lo spazio tra due canali, come dall'Aurora, è di 400uS che sommati agli HIGH danno un canale da 1000uS a 2000uS.

C'è qualcosa di strano nel codice però, appena metto a posto lo metto qui.

EDIT: pardon, devo aver sbagliato immagini, che queste hanno un LOW di 200uS...
Scusatemi.

IMAG005.BMP (47 KB)

IMAG006.BMP (47 KB)

Ragazzi ho un problema con il software multiwii.
Nel conf di multiwii il segnale della ricevente fa come gli pare va su e giu, tutti quanti, senza che muovo le leve, se le muovo lui risponde xò oscilla sempre di molto. come posso fare? metto il video così si capisce meglio.

Spero possiate aiutarmi....
grazie in anticipo

non vedo i video, sono blocato dal proxy, ma se vedi delle bande nere/freeze video, allora è erchè il video è trasmesso in analogico, e qualsiasi trasmittente che usa la stessa frequenza si sovrappone degradandoil segnale.

Soluzine è di cambiare frequenza dei trasmettitori o passare alla trasmissione digitale, cosa che purtroppo non ho ancora visto in giro, anche se con rasperry & co. ormai è una fosa fattibilissima.

No no io parla nella GUI di multiwii i valori che mi fa vedere che gli arrivano dalla ricevete sono tutti sballati vanno su e giu come matti senza che io tocco gli stick, se muovo gli stick loro si muovono però restano sempre molto instabili con incremente e decrementi veloci e vertiginosi !

Sono molto probabilmente delle interferenze radio.
Quello che Leo suggeriva era una probabile fonte di interferenza video, se usi trasmissione video tu o se ce n'è nelle vicinanze, sui 2.4GHz.

Non è davvero colpa del multiwii.
Altrimenti la trasmittente, ma su tutti i canali contemporaneamente non è un problema di potenziometri rotti.

io proverei altrove, così da confermare un disturbo radio.

Io nel frattempo vi aggiorno su quanto stavo facendo, così per aggiungere 2 centesimi..
Allora ho fatto una schedina di conversione con un atmega 328p, che prende un protocollo seriale da una APC220 (19200 baud per almeno 600mt forse più..) e lo trasforma in PPM SUM. Trasmetto il movimento di un joystick 4 assi letto tramite processing via pc, il refresh della draw() è di circa 17-18ms.

Devo dire funziona egregiamente, solo che poi ho scoperto che multiwii ha già un suo bel protocollo, e che si possono iniettare direttamente i pacchetti degli 8 canali, più un semplice checksum direttamente su qualsiasi altra UART, quindi ho tradotto il mio protocollo e adesso gli 8 canali sono direttamente spediti ogni 17-18ms, in digitale.
Non mi sembra una brutta cosa..
se uno avesse una scheda radio full-duplex immagino che con la stessa velocità potrebbe ricevere anche dati di telemetria..

Per ora comunque ancora niente voli, solo un pò di tarature dei PID, ma da verificare. Poco tempo a disposizione..

Ciao!