Qualcuno sperimenta con Arduino?

[romoloman]

Originalmente inviato da riki1681

la soluzione con ponte frksy/ppm (quindi un modulo frsky che trasmette a una rx frsky, prendendo un input di segnali ppm generati da arduino che a sua volta prende dal pc i valori e li converte) è una scelta di velocità ed economia.

il software richiede al massimo qualche oretta per lo sviluppo (lato arduino e lato pc), e ho un range di 1,5km spendendo meno di 40 sterline.

ed effettivamente funziona tutto e bene.

sparo una stringa con valori separati da punto e virgola e fine riga con il carattere ascii 10 (\n o vblf o linefeed, o come lo volete chiamare)

arduino attende il fine riga,
legge la stringa e memorizza i valori

ogni 22ms un interrupt richiama una funzione che genera il treno di impulsi ppm, nulla più di una serie di high e low sul pin che va alla tx frsky, di durata variabile in base a quello che invio dalla seriale del pc.

questo richiede una 50ina di righe di codice lato arduino e altrettante lato pc (compresa la lettura dei valori da un joystick collegato al pc)

sinceramente non so quanto invece cubi in termini di tempo implementare uno dei protocolli "seri" che vengono utilizzati da marche che fanno tx/rx.

per quello pensavo di fare un protocollo "light"
e che, magari in futuro, mi permetta, lato pc, di pilotare più tx, tramite le varie uscite di arduino.

poi le mie erano esempi di considerazioni sul perché dare attenzione al messaggio più che a come si invia, non tanto quesiti su come fare un protocollo.
ad ora una stringa di testo svolge egregiamente questa funzione mentre le logiche sono gestite dal pc.
arduino si occupa solo di tenere sotto controllo i valori massimi dei comandi che riceve, in modo da non inviare segnali malformati in caso di comunicazione seriale problematica.

quando tutto sarà più consolidato spero invece di poter implementare una comunicazione più efficace.

FrskyPXX e DSM2 sono protocolli digitali seriali, specialmente il dsm2.
Un modulo dsm2 lo cannibalizzi facile facile da una dx4/dx5 che trovi sul mercato dell'usato a 40€ , considerando che risparmi su arduino tutto sommato mi sembra ragionevole..

[faustog_2]

ciao allora

ecco qui poche righe ma potenti, in ASSEMBLER, fatte per un Pic 16F876 gestisce un Robot dotato di due motori solamente quindi gestisce un segnale PPM di soli due controlli, il terzo gestisce la direzione.. comunque con lo stesso criterio ho progettato un firmware che gestisce 6 servo... il risultato è uguale.. funziona.

; __________________________________________________ ________
;
; MAIN LOOP
; ------------------------------------
;
LOOP btfss INTCON,T0IF ; Controlla che non siano scaduti i 20 mS
GOTO XX ; se TMR0 < 20 mS allora vai XX
CALL MOVE_ALL ; altrimenti vai in MOVE_ALL

XX BTFSS READ_IR_1 ; Se nn legge l infrarosso salta e legge la seriale
call IR_SEND ; altrimenti chiama IR_SEND

btfss PIR1,RCIF ; Receive data from Serial Port
GOTO LOOP ; se non riceve dati vai in LOOP

MOVWF INDF ; carica in INDF il valore

INCFSZ FSR,F ; incrementa l'indirizzo di INDF = FSR

GOTO LOOP ; se FSR < 256 allora vai LOOP

RESET MOVLW 253 ; Nel caso in cui FSR ha raggiunto il 256
MOVWF FSR ; Allora riponi il valore iniziale di 251
GOTO LOOP ; infine torna in LOOP

lo stesso codice si può implementare su Arduino.. la tecnica è sempre la stessa in base all'ordine d'arrivo.. ogni byte sarà dedicato al canale desiderato.. assolutamente sconsigliato inviare posizione valore.. per esempio immaginate che contemporaneamente cambino tre canali su 5 per esempio.. allora dovremmo inviare 2 x 3 = 6 byte.. invece nela caso mio 5 ! se cambiano 5 canali nella prima ipostesi 2 x 5 = 10 byte.. invece la pesantezza della mia soluzione è costante.. vero è che se cambia solo un canale anzichèe 2 bute ne trasferiamo 5 ma alla fine stiamo parlando di un sistema che da un punto di vista pratico è solido.

[romoloman]

Originalmente inviato da faustog_2

ciao allora

ecco qui poche righe ma potenti, in ASSEMBLER, fatte per un Pic 16F876 gestisce un Robot dotato di due motori solamente quindi gestisce un segnale PPM di soli due controlli, il terzo gestisce la direzione.. comunque con lo stesso criterio ho progettato un firmware che gestisce 6 servo... il risultato è uguale.. funziona.

; __________________________________________________ ________
;
; MAIN LOOP
; ------------------------------------
;
LOOP btfss INTCON,T0IF ; Controlla che non siano scaduti i 20 mS
GOTO XX ; se TMR0 < 20 mS allora vai XX
CALL MOVE_ALL ; altrimenti vai in MOVE_ALL

XX BTFSS READ_IR_1 ; Se nn legge l infrarosso salta e legge la seriale
call IR_SEND ; altrimenti chiama IR_SEND

btfss PIR1,RCIF ; Receive data from Serial Port
GOTO LOOP ; se non riceve dati vai in LOOP

MOVWF INDF ; carica in INDF il valore

INCFSZ FSR,F ; incrementa l'indirizzo di INDF = FSR

GOTO LOOP ; se FSR < 256 allora vai LOOP

RESET MOVLW 253 ; Nel caso in cui FSR ha raggiunto il 256
MOVWF FSR ; Allora riponi il valore iniziale di 251
GOTO LOOP ; infine torna in LOOP

lo stesso codice si può implementare su Arduino.. la tecnica è sempre la stessa in base all'ordine d'arrivo.. ogni byte sarà dedicato al canale desiderato.. assolutamente sconsigliato inviare posizione valore.. per esempio immaginate che contemporaneamente cambino tre canali su 5 per esempio.. allora dovremmo inviare 2 x 3 = 6 byte.. invece nela caso mio 5 ! se cambiano 5 canali nella prima ipostesi 2 x 5 = 10 byte.. invece la pesantezza della mia soluzione è costante.. vero è che se cambia solo un canale anzichèe 2 bute ne trasferiamo 5 ma alla fine stiamo parlando di un sistema che da un punto di vista pratico è solido.

La seriale del atmega 328 gestisce senza rogne comunicazioni a 115200.
considerando 2 byte di header 1.5 byte per canale (1024 passi) uno di crc per trasmettere 8 canali trasmettiamo 15 byte ovvero 120bit.
anche trasmettendoli 50 volte al secondo (in realtà un po' meno visto che la lunghezza del frame ppm è 22.5ms) ci ritroviamo a 6000 bit/sec
onestamente abbiamo tutto il margine di sicurezza per riceverli preparare il frame ppm per la routine che nell'interrupt genererà i pulse e ritornare indietro...
Trasmettere le differenze non è salutare, se il micro dovesse perdersi dei pezzi per strada, soprattutto perchè il PC dovrebbe sempre ragionare nella logica che tutto sia sempre stato ricevuto e che non ci sia stato un reset magari dovuto al watchdog del micro.

[faustog_2]

allora..

c' è da dire che il sistema che ho realizzato funziona su Ethernet! quindi una portante sarebbe improponibile ..se guardi l'immagine ti fa capire meglio il progetto.. il tutto è rivolto verso la Domotica.. per cui in ufficio o in un parco in remoto devo poter pilotare un Robot.. o un sistema che attrverso il PPM controlla posizione servo, regolazioni motore , relè, pulsanti, avere indietro dati di sensori, allarmi ecc..

comunque nel nostro caso come modello uso un semplice robot che si muove attraverso due motori ricavati da avvitatori, e un radar infrarosso che legge ostacoli, poi aggiungo, dei sensori di pressione in caso di ostacoli bassi ecc..

bene il sistem in rete Ethernet deve ridurre il piu possibile il trafico, la quantità di dati.. per cui prende per buono gli ultimi comandi inviati.. salvo variazioni che appunto richiede la trasmissione del treno di byte completo, ovviamente se vogliamo 10 bit per segnale PPM allora i byte diventano 16, ovvero 2 per ogni onda quadra.. di cui sappiamo che il secondo byte usa solo 2 bit.. a meno che si prepara un firmware che compatta le informazioni, per cui il tutto nel caso di 8 canali diventa 10 byte ! per ogni variazione. che verrà inviata solo dopo ogni 16 mS ! per evitare problemi di mancato coordinamento il watchdog si può disattivare.. e non creare problemi in ogni caso se esso viene impostato su tempi oltre i 30 mS nn può interferire con i 16 mS

la discussione mi sta cominciando a piacere
a presto
fausto

Originalmente inviato da romoloman

La seriale del atmega 328 gestisce senza rogne comunicazioni a 115200.
considerando 2 byte di header 1.5 byte per canale (1024 passi) uno di crc per trasmettere 8 canali trasmettiamo 15 byte ovvero 120bit.
anche trasmettendoli 50 volte al secondo (in realtà un po' meno visto che la lunghezza del frame ppm è 22.5ms) ci ritroviamo a 6000 bit/sec
onestamente abbiamo tutto il margine di sicurezza per riceverli preparare il frame ppm per la routine che nell'interrupt genererà i pulse e ritornare indietro...
Trasmettere le differenze non è salutare, se il micro dovesse perdersi dei pezzi per strada, soprattutto perchè il PC dovrebbe sempre ragionare nella logica che tutto sia sempre stato ricevuto e che non ci sia stato un reset magari dovuto al watchdog del micro.

[romoloman]

Originalmente inviato da faustog_2

allora..
richiede la trasmissione del treno di byte completo, ovviamente se vogliamo 10 bit per segnale PPM allora i byte diventano 16, ovvero 2 per ogni onda quadra.. di cui sappiamo che il secondo byte usa solo 2 bit.. a meno che si prepara un firmware che

no bastano 1.5fino a 4096
supponi di avere in

uint8_t buffer[12] i 12 byte corrispondenti ai canali letti dalla seriale

uint16_t val[]={0,0,0,0,0,0,0,0};
for (int i=0; i<4; i++){
  val[i*2]= buffer[i*3]<<4;
  val[i*2]|= buffer[i*3+1]>>4;
  val[i*2+i]=buffer[i*3+1]<<8;
  val[i*2+i]|=buffer[i*3+2];
}

nessuna compressione e elaborazione veloce visto che si va di shift a nibble.

Quanto a disabilitare i watchdog... de gustibus... ma io li lascio abilitati per sanità di funzionamento, se il micro si pianta deve ripartire. Ci manca più che una radio si inchiodi con un bello schermo di blocco...

[romoloman]

Originalmente inviato da romoloman

no bastano 1.5fino a 4096
supponi di avere in

uint8_t buffer[12] i 12 byte corrispondenti ai canali letti dalla seriale

uint16_t val[]={0,0,0,0,0,0,0,0};
for (int i=0; i<4; i++){
  val[i*2]= buffer[i*3]<<4;
  val[i*2]|= buffer[i*3+1]>>4;
  val[i*2+i]=buffer[i*3+1]<<8;
  val[i*2+i]|=buffer[i*3+2];
}

codice corretto...

uint8_t buffer[12] i 12 byte corrispondenti ai canali letti dalla seriale

uint16_t val[]={0,0,0,0,0,0,0,0};
for (int i=0; i<4; i++){
  val[i*2]= buffer[i*3]<<4;
  val[i*2]|= buffer[i*3+1]>>4;
  val[i*2+1]=buffer[i*3+1]<<8;
  val[i*2+1|=buffer[i*3+2];
}

[faustog_2]

salve.. una osservazione.. premetto che mi trovo in vacanza.. però con me PC e Internet.. ..dunque tra i miei vecchi lavori trovo un'applicazione java che usa la classe HTTPUrlconnection... in sostanza una qualunque applicazione java può comunicare con un web server.. magari dietro c'è un'applicazione in PHP, non importa.. con questo se dotiamo la nostra applicazione di controllo seriale e di HTTPUrlConnection abbiamo tutto per dialogare direttamente con applicazioni fatte con Easy php, Joomla ecc.. !!!! Non è fantastico? vero che in futuro si dovrà sviluppare su Android.. ma al momento volgio percorrere questa vecchia strada.. a dopo

[riki1681]

Originalmente inviato da romoloman

FrskyPXX e DSM2 sono protocolli digitali seriali, specialmente il dsm2.
Un modulo dsm2 lo cannibalizzi facile facile da una dx4/dx5 che trovi sul mercato dell'usato a 40€ , considerando che risparmi su arduino tutto sommato mi sembra ragionevole..

ok, questo è parlare.
la cosa si fa interessante.
però non voglio intasare la discussione andando OT.
ti scrivo un pm.