Arduino e throttle in
 

Sto preparando degli impianti di illuminazione basati su Arduino (mini pro, nano, attiny85), per variare il comportamento delle luci conto di utilizzare anche i segnali provenienti dalla RX: ad esempio il CH3 del throttle per variare la luminosita' di un LED posizionato sul motore.

C'e' qualche contro indicazione se piglio direttamente il segnale dal cavo del segnale CH3 che va' alla ESC e lo infilo in un PIN input di Arduino?

Da qui https://www.arduino.cc/en/Tutorial/DigitalPins leggo che un PIN settato come INPUT (il default) dovrebbe avere un'impendenza di 100 megohm che quindi non dovrebbe dar fastidio all'ESC.

Quando ho dei canali in piu' preferibilmente piglio un canale libero per le bazze con Arduino ma su vari aerei non ho canali liberi disponibili.

Io ho provato al banco e non ho problemi, su un mio aereo e non ho problemi, ne ho messo uno in questa configurazione su un aereo di un amico (ia6 con una ESC di HK da ~20a se non ricordo male) e non si inizializza l'ESC.

Voi avete qualche esperienza a riguardo?

Alla meno peggio potresti pensare di utilizzare un fotoaccoppiatore, in modo da separare elettricamente ESC e arduino evitando problemi di "interferenze".

@aero330 : thanks, ho messo un po' di MOC3043 e PC817 nel carrello e provero' con questi.
Pero' io devo passare il segnale della ricevente -> Arduino, non il contrario.

Oppure un 6N137?

Ma io intendevo proprio come dici tu :lol:, in allegato ti ho messo una foto.
Secondo me basta anche il classico 4n25.

Però l'utilizzo di un fotoaccoppiatore mi sta convincendo sempre di meno...per il fatto che il segnale proveniente dalla RX non so se sia in grado di fornire una corrente di almeno 10mAh per il led del fotoaccoppiatore stesso.....per cui forse meglio inserire un buffer ad OpAmp (TL081) che sicuramente non assorbe corrente

He e' quello che stavo guardando anche io leggendo i datasheet: a pilotare il segnale dal microcontroller non dovrebbe essere un problema ma non so se il segnale della RX liscia puo' essere sufficiente.

Il 6N137 che dovrebbe essere veloce dice 20ma (che poi magari va' anche con un po' meno...): perfetto per Arduino ma non per la RX.
Il MOC3043 5ma.

Poi c'e' anche il forward voltage, magari faccio una prova pero' mi abbassa il voltaggio del segnale di 1.5v!

Provo a guardare anche l'OP amp, che non inserisca una latenza. Grazie anche per il disegno.

Se qualcuno altro passa su questo thread riporto il quesito originale:
Avete mai avuoto problemi a "sniffare" il segnale di un servo (con un cavo in parallelo) da
?

Grazie per i suggerimenti aero330 :)

1.5V è la tensione minima per accendere il led del fotoaccoppiatore, ma il segnale della rx ha un'ampiezza che è dipendente dalla tensione con cui alimenti la rx stessa! Hai un regolatore da 5V? l'uscita al massimo sarà di 5V sotto forma di treni di impulsi. Devi inserire una resistenza per limitare tensione e corrente sul led.
Esempio: alimentazione 5v, If=10ma, Vf=1.5V => Resistenza = (alimentazione -Vf)/10mah=350ohm

Però, come ti ripeto, meglio puntare su un buffer ad opamp
https://i.stack.imgur.com/5lsaY.png

Latenza? non credo proprio, il segnale che pilota l'ESC è identico a quello che pilota i servi e stiamo parlando di frequenze dell'ordine dei 50-100Hz !! valori molto bassi prima che l'operazionale se ne accorga! :wink:

Se cerchi su internet trovi una marea di roba visto che è molto diffusa come cosa, inoltre esiste il comando "pulseIn()" che calcola in automatico la durata di un impulso generico che è quello che fa al caso tuo.

Sempre usato in diretta, in parallelo sia con esc che con servi.

Se proprio si devono/vogliono usare componenti un buon vecchio emitter follower dovrebbe funzionare.

http://ecelabs.njit.edu/ece392/images/392_2_1a.gif

P.S. anche nel caso di utilizzo di un opto-coupler si può mettere la resistenza sul emettitore per evitare l'inversione di polarità del segnale.

:yeah:

Thanks.
Infatti anche io ho sempre fatto cosi', il problema si e' posto con l'aereo di un amico col quale con la lettura in parallelo non si inizializza l'ESC (e lamentava degli errori di erogazione del motore).

Non essendo l'aereo mio non mi e' stato possibile fare tutte le prove che avrei voluto (potete immaginare la gioia del proprietario che dopo tutto lo sbattimento a cablare LED RGB, buca qua e taglia la, si ritrovava con un aereo che non si accende...).

Ora dato che il sistema vorrei usarlo su vari aerei di altri sono alla ricerca di esperienze di altri.

@aero330
Se ho solo uno o due input posso usare PULSEIN(). Pero' questa e' blocking e mi puo' interferire con i fade quando sono rapidi. Userei sempre degli interrupt ma per comodita' saldo direttamente un darlinghton ULN2803 sulla Mini Pro / Nano e finisce che occupo i pin con degli output.

@ElNonino
Grazie dello schema.
Anche io avevo pensato alla peggio di fare un piccolo circuito con un mosfet per leggere il segnale eventualmente.

Pero' il gioco al momento si basa su delle strisce di LED 12v super economiche, dei pacchi di arduino mini pro 168 da 1 euro con 1 o 2 ULN2803 sopra, una libreria a oggetti non blocking per le luci e degli sketch di esempio con delle FSM per chi non e' pratico di programmazione.

Poi conto di "allungare" le mini / nano con dei magnetometri e dei 6 assi che sono dello stesso formato.

Se gli devo far fare tagliare dei pezzi di basette preforate per montare due transistor la gente (...) si spaventa.

Non conosco molto Arduino ed il relativo micro però hai provato a giocare con i Pull-Up o Pull-Dwn sugli ingressi digitali che usi ?

Se gli impulsi in uscita dalla Rx sono positivi prova a mettere un diodo in serie al collegamento con Arduino, anodo alla rx e catodo ad Arduino.

Se hai un pull-up attivo su Arduino ed impulsi negativi dalla Rx inverti i collegamenti del diodo.

:yeah:

I PIN settati come input su le arduino avr sono ad alta impendenza (100 megohm) flottanti, quindi non dovrebbero avere problemi a sniffare un canale della RX in parallelo. Si possono mettere (non tutti) in pull-up, il pull-down non c'e'.

Anche il diodo e' una soluzione posto che ci sia il problema, si potrebbe saldare direttemente un smd sul darlinghton per non avere delle parti separate.

Se i pin di Arduino hanno le caratteristiche che riporti non esiste la possibilità che, collegati in parallelo con il pilotaggio del ESC, interferiscano con lo stesso; allora collegando una sonda dell'oscilloscopio con i classici 1/10Mohm sul pin Rx l'ESC dovrebbe dare lo stesso problema.

Quindi o gli input della scheda Arduino non rispettano tali valori o va controllato tutto il circuito (ritorni di massa ???).

:yeah:

Yep, ripensandoci (perche' l'aereo non e' mio e non ci posso guardare) il canale era attaccato al pin A3, che sta di fianco al VCC. Potrebbe essere che la saldatura sia un po' sbavata.

- https://cdn.sparkfun.com/assets/5/8/...4b4b000000.png
- http://git.andreamanni.com/web?p=aer...ti/bugatti.ino

Lunedi' lo rivedo e provo a chiedergli se ha voglia di portarsi dietro l'aereo e guardarci, la palla e' che la scheda e poco accessibile ma visto che cosi' le luci sono tristi (gli ho messo un programma che le cambia con una sequenza determinata non avendo un input) spero che abbia voglia di guardarci.

Thanks per lo spunto, provo a rompere le scatole al padrone che magari colto dall'interesse nazionale della cosa si rende disponibile a farmi riesumare il caso :)

Aspetta un attimo....tu stai sniffando il segnale della Rx col pin A3 dell'arduino?
Se così fosse sbagli perchè vuoi leggere un segnale digitale con un pin che è un ingresso analogico per la lettura di una tensione! Tutto funziona, ma leggi o 5V o 0V per cui dubito che sia un problema di saldatura :wink:

L'istruzione "pinMode(A3,INPUT);" non ha un gran senso in quanto i pin A0,A1,......A5 sono degli ingressi ANALOGICI e non si può modificare il loro "stato"; il compilatore comunque non da errore e lo ritiene un comando corretto (ma concettualmente no)

Per far le cose fate fatte bene devi utilizzare un pin I/O DIGITALE dichiarato come INPUT.

Esempio (considerando di utilizzare il pin 13):

thrPin = 13;
pinMode(thrPin,INPUT);
thrIn = pulseIn(thrPin, HIGH, 25000);

Non direi: io faccio un digital read su A3, che puo' essere configurato pure come OUTPUT.
- https://www.arduino.cc/en/Reference/digitalRead

Sul fatto del pinMode(A3,INPUT) hai perfettamente ragione: i PIN di default sono "input" (ad alta impendenza) quindi quell'istruzione non serve. Pero' dato che non funzionava ce l'ho messa per prova, sai mai che abbiano cambiato qualcosa...

Piuttosto sono i PIN analogici A6,A7 (mini / nano) che non possono essere usati in altro modo se non analogico (non sono manco attaccati al pull up).

Facendo una ricerca su internet, si possono utilizzare persino i pin di ingresso analogici come pin di uscita digitali, questa proprio non la sapevo...ero convinto che non si potesse fare e invece...
https://www.arduino.cc/en/Tutorial/AnalogInputPins
Per cui a questo punto è possibile usare il pulseIn insieme ad A3....:lol:

Ciao,
vorrei condividere un dubbio su arduino e il throttle in (Rx in) degli ESC.
Riapro questa discussione perchè mi sembra a tema e perchè leggendo ho visto che molti usano tranquillamente arduino e l'ESC.

Ho collegato un'uscita di arduino al Rx in dell'ESC e la piloto con la libreria servo.h; in teoria so esattamente che segnale mando all'ESC (se servo.h funziona :huh:).

Secondo gli standard per i ricevitori RC dovrebbe funzionare in questo modo:
- segnale con lunghezza impulso da 1000 microsecondi equivale a manetta tutta indietro
- segnale con lunghezza impulso da 1500 microsecondi equivale a motore fermo
- segnale con lunghezza impulso da 2000 microsecondi equivale a motore a palla avanti.
L'ho trovato su internet, perdonatemi se è una castroneria o generalizzazione sbagliata :rolleyes:.


il mio motore a banco comincia a muoversi a 1600 ms e dopo i 1800 ms non aumenta più, uguale in retromarcia (1400 - 1200).

Ho tolto la deadband, calibrato, ma niente...
..mi rimane solo da pacciocare con le percentuali di frenatura ect...

Posso convivere con questo comportamento ma mi chiedevo se è normale.
Qualcuno ha avuto la stessa esperienza?

Efisio

Ti dirò di più, fare un digitalRead() oppure analogRead() su pin analogici occupa tempi di lettura molto diversi!
Parlo per esperienza personale, la lettura analogica impiega (vado a memoria) circa 10 volte tanto quella digitale!

Si certo, perchè c'è anche una conversione A/D da fare...