![]() |
Il tuo codice lo vedo molto critico dal punto di vista del segnale generato, cerco di spiegarti il perché: Codice: void setup(){Codice: pinMode(auxOutput,OUTPUT);Codice: void setup(){continuando.... il seguente codice: Codice: //Acquisisco il valore del throttleovvero il segnale di uscita non verrà generato fino a che, o l'impulso viene rilevato, o avviene un timeout. Andiamo avanti con l'analisi degli orrori :icon_rofl:icon_rofl: Codice: //controllo il valore del throttlecomunque questo non inficia il funzionamento ma è solo un questione di pulizia del codice. Tuttavia non confronterei mai con 0, stai aspettando un segnale che deve avere un ampiezza compresa fra 1000 e 2000us.... perché rischiare di prendere delle spurie da pochi uSec come segnale valido ? Codice: auxServo.write(179); //"invio" un segnale ALTOCodice: auxServo.write(179); //"invio" un segnale ALTOpulseIn aspetta 25ms... ritorna 0.. auxServo.write() genera un impulso di 2ms delay aspetta 15ms in totale il tuo impulso viene generato ogni 42 ms...secondo me sono un po' troppi. forse allora togliendo il delay almeno lo avresti generato ogni 27ms e le cose andrebbero meglio. Nel caso l'impulso sia presente con il tuo codice (tolto il delay e inserito l'else) invece avverrebbe la cosa seguente: chiamiamo Ton il tempo in cui l'impulso di ingresso va alto: Tduty la larghezza dell'impulso in ingresso Ttot il periodo del ppm in ingresso (tipicamente 18ms) servoin aspetta l'impulso T0=Ton al tempo Ton+Tduty (variabile e dipendente dall'impulso in ingresso) auxServo.write() genera un impulso di larghezza 1000uSec e ritorna al ciclo successivo di pulseIn A questo punto pulseIn aspetterà Ttot-1000usec-Tduty che si ripresenti l'impulso successivo. essendo Tduty variabile è evidente che l'impulso generato da auxServo.write() avrà un jitter dipendente dalle variazioni dell'ingresso... E' vero che all'elettronica che legge l'impulso probabilmente non gliene frega nulla, ma è concettualmente sbagliato. La generazione del PPM deve essere fatta in un interrupt che setta l'uscita, regola il timer per la chiamata successiva dopo i ms di ampiezza dell'impulso, la chiamata successiva resetta l'uscita e imposta il timeout dell'interrupt successivo a 22.5-(larghezza impulso) ms (quello che correttamente viene fatto nella ISR(TIMER1_COMPA_vect) del codice da te postato. nel tuo caso andrebbe fatto per un solo canale e non per tutti quelli dello stream PPM: Spero di essere stato sufficientemente chiaro, cordiali saluti |
??? sarà l'età.. o forse mi sono un pò arruginito ! o force troppi Acronimi FC, RX, AUX1 ecc vorrei capire meglio.. ..dunque la scheda MultiWii dotata d acellerometri e giroscopi.. dunque è in grado di rilevare ogni movimento possibile.. con una sensibilità dignitosa.. per quello che ho capito ..tu vorresti in un canale della tua ricevente.. attivare o meno il controllo della MultiWii.. ..dunque essa provvederà a stabilizzare il modello attraverso arduino, che leggendo i valori digitali dell'orizzonte e delle sbandate... riesce a correggere attraverso un opportuno movimento dei servi... ovviamente i servo si muoveranno sempre attraverso i tuoi comandi.. ma nel caso non muovessi gli stick.. , quindi se non rileva variazioni dalla RX montata sul velivolo e inoltre il ch 6 è in modalità fail save... allora solo in questo caso intraprende le azioni che impartisce arduino.. ..dimmi se ho capito bene intanto oppure non ho capito una mazza! Citazione:
|
Innanzi tutto grazie romoloman per essere stato così meticoloso:) Alcuni punti mi sono chiari, altri un pò meno: Citazione:
Citazione:
Quello che però non capisco è perché tu non confronteresti con 0, mi spiego, banalmente quello che ho fatto è stato leggere il valore dalla ricevente e con la trasmittente accesa leggo un valore compreso tra 1000 e 2000, che ovviamente si muove a seconda del movimento dello stick. Nel momento in cui ho spento la trasmittente,simulando una perdita di segnale, questo valore è andato a 0. In che altro modo posso intercettare un'assenza di segnale? se non confrontando questo valore con 0 ? Per tutti gli altri punti che mi hai segnalato credo d'aver capito, grazie per la spiegazione. Per quanto riguarda il fatto di usare le interrupt e il Timer credo di aver più o meno capito concettualmente quello che si va a fare, con le mie competenze attuali non sono in grado di implementare qualcosa,devo vedermi meglio come funzionano i Timer e i vari registri. Se però il codice che ho postato è fatto bene perché non mi funziona? Ho modificato così le define: Codice: //this programm will put out a PPM signalL'unica cosa che ho notato, smanettando un po "a buffo", è che modificando il parametro #define onState e portandolo da 1 a 0, quello che succede è che il valore del canale su multiwii inizia a oscillare, arriva "lentamente" al massimo, e poi torna indietro,al minimo e così via. Cosa mi manca ?:blink: Citazione:
Ho trovato in rete un software Multiwii modificato, che implementa questo genere di failsafe, ma andiamo OT, se riesco volevo proseguire con la mia idea. |
Nel codice il parametro da modificare è #define PPM_PulseLen, ci sono arrivato per tentativi:blink: |
Citazione:
300 è un valore abbastanza standard, ma magari l'interfaccia multiwii lo vuole più lungo (400+uSec) tuttavia non ho capito ma ora ti funziona oppure no ? |
Citazione:
Impostando quel valore tra 1000 e 2000 multiwii lo legge tranquillamente...non so il perché ma è così:blink: A quanto pare funziona, ora non sono al pc,domani posto il codice |
ciao a tutti baccothe scusa l'intromissione, scrivo qui perchè sempre di ppm si parla. ho provato a cercare sul forum e anche su internet, ma non sono riuscito a trovare una funzione, sotto forma di libreria o anche codice scritto, che mi permetta di leggere un segnale ppm prelevato da una rx (FrSky Delta 8) e che mi restituisca i valori divisi canale per canale. esiste? tevere p.s. ho provato anche a guardare i software per multirotori, ma, a causa delle mie poche conoscenze in quest'ambito, non sono riuscito ad estrapolare nulla |
Non è una cosa complicata! tutto sommato non è complicato.... abbiamo il Timer1 che cresce a ritmo di mezzo microsecondo.. (prescaler 8) ovvero 500 nS (nano secondi) quando raggiunge il valore del periodo, si verifica un interrupt.... che viene catturato dalla funzione ISR( ecc...) ..dentro questa funzione viene azzerato il timer... viene eseguito il fronte di salita sul pin in causa... Adesso il compare dovrà osservare non più il periodo ma un altro registro l'OCR1A appena il Timer1 raggiunge questo valore avviene dinuovo un interrupt ma stavolta esegue il fronte di discesa STOP! fine della storia.. ovviamente i registri Citazione:
|
| Tutti gli orari sono GMT +2. Adesso sono le 09:17. |
Basato su: vBulletin versione 3.8.11
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
E' vietata la riproduzione, anche solo in parte, di contenuti e grafica. Copyright 1998/2019 - K-Bits P.I. 09395831002