Qualcuno sperimenta con Arduino?

[Tom_1971]

Sei un drago, Fausto!

Tienici al corrente, se non altro farai sognare noi miseri vecchi, modellisti e sperimentatori da salotto


P.S. La storia della guida automatica intriga... a me era venuta l'idea di iniziare con una macchinina, più semplice da pilotare (manca la terza dimensione e non risente del vento!) e sicuramente anche più robusta in caso di ... ehm... errori di guida!

[marcosinatti]

Qui trovi informazioni e progetti interessanti anche se non sono per arduino Hardware - Paparazzi

[faustog_2]

ciao marco .. ...scaricando la versione ultima 2.7 ecc..

cerco di capire come adattare il GPS GTPA010 che funzia a 10 Hz e 38.400 bps ..

nel file di include GPS.. ho la possibilità di modificare il bps ..però mi sorge un dubbio... poiche di progetto ardupilot funziona max a 5 hz, non vorrei che una velocità doppia nn possa essere gestita a prescindere della velocita della seriale.. perchè ovviamente da un lato i dati arrivano.. e si può prenderli correttamente a 38.400 , però poi gli stessi devono arrivare dentro la logica di funzionamento rispettendo dei tempi.. poi chè ho letto da diverse parti dei sorgenti max 5hz ..mi sorge il dubbio!

qui c'è la funzione di setaggio:

void change_to_sirf_protocol(void)
{
Serial.begin(4800); // First try in 4800
delay(300);
for (byte x = 0; x <= 28; x++){
Serial.print(byte(gps_buffer[x])); //Sending special bytes declared at the beginning
}
delay(300);
Serial.begin(9600); // Then try in 9600
delay(300);
for (byte x = 0; x <= 28; x++){
Serial.print(byte(gps_buffer[x]));
}
Serial.begin(EM406_GPS); //Universal Sincronus Asyncronus Receiveing Transmiting
}

Originalmente inviato da marcosinatti

Qui trovi informazioni e progetti interessanti anche se non sono per arduino Hardware - Paparazzi

[faustog_2]

ciao Tom sei della stessa annata mia!

allora oggi ho potuto fare una prova, funziona! l'ipotesi era corretta, solo che arduino legge i dati dalla ricevente portando con se piccole sbavature.. tenendo fermo lo stick della radio il segnale ogni tanto porta delle piccole variazioni.. che poi trasferite sul servo significano piccoli e fastidiosi movimenti.. ...occorre per tanto un'istruzione di controllo , che effettua l'assegnamento del nuovo valore solo se il valore assoluto della differenza è > 10 ..in modo da avere un margine..

if ( abs( pulseIn(ENG, HIGH) - RX_engine ) > 10)
RX_engine = pulseIn(ENG, HIGH);

Quindi aggiorna il valore di RX_engine solo se il valore assoluto della differenza con il precedente valore supera 10. Con questa istruzione le sbavature vengono corrette.

Questo software è il primo passo.. vale a dire prendo il segnale dalla ricevente... se non cambia rispetto all'ultimo ordine... allora legge dalla lista dei waypoint per andare ad eseguire il movimento del prox punto..



#include <Servo.h>

Servo myservo1,myservo2; // create servo object to control a servo

const int ENG = 2; // pin lettura ricevente segnale motore INGRESSO
const int DIR = 4; // pin lettura segnale servo di direzione INGRESSO
const int IR = 8; // pin lettura segnale infrarosso INGRESSO
const int ENG_OUT = 9; // pin per segnale motore da inviare USCITA
const int DIR_OUT = 10; // pin per segnale direzione servo da inviare USCITA

long engine; // segnale imposto per la potenza motore
long direct; // segnale imposto al servo di direzione

long RX_engine; // segnale proveniente dalla ricevente potenza motore
long RX_direct; // segnale proveniente dalla ricevente servo direzione

int val_1,val_2;


//__________________________________________________ ________________
void setup()
{
// initialize serial communication:
Serial.begin(38400);
myservo.attach(ENG_OUT);

pinMode(ENG, INPUT);
pinMode(DIR, INPUT);
pinMode(IR, INPUT);
}
//__________________________________________________ ________________
void loop()
{

RX_engine = pulseIn(ENG, HIGH);
RX_direct = pulseIn(DIR, HIGH);

val_1 = map(RX_engine, 1050, 1850, 0, 180);
val_2 = map(RX_direct, 1050, 1850, 0, 180);


myservo.write(val_1);
}

Originalmente inviato da Tom_1971

Sei un drago, Fausto!

Tienici al corrente, se non altro farai sognare noi miseri vecchi, modellisti e sperimentatori da salotto


P.S. La storia della guida automatica intriga... a me era venuta l'idea di iniziare con una macchinina, più semplice da pilotare (manca la terza dimensione e non risente del vento!) e sicuramente anche più robusta in caso di ... ehm... errori di guida!

[gawain]

Originalmente inviato da faustog_2

ciao Tom sei della stessa annata mia!

allora oggi ho potuto fare una prova, funziona! l'ipotesi era corretta, solo che arduino legge i dati dalla ricevente portando con se piccole sbavature.. tenendo fermo lo stick della radio il segnale ogni tanto porta delle piccole variazioni.. che poi trasferite sul servo significano piccoli e fastidiosi movimenti.. ...occorre per tanto un'istruzione di controllo , che effettua l'assegnamento del nuovo valore solo se il valore assoluto della differenza è > 10 ..in modo da avere un margine..

if ( abs( pulseIn(ENG, HIGH) - RX_engine ) > 10)
RX_engine = pulseIn(ENG, HIGH);

Quindi aggiorna il valore di RX_engine solo se il valore assoluto della differenza con il precedente valore supera 10. Con questa istruzione le sbavature vengono corrette.

Questo software è il primo passo.. vale a dire prendo il segnale dalla ricevente... se non cambia rispetto all'ultimo ordine... allora legge dalla lista dei waypoint per andare ad eseguire il movimento del prox punto..



#include <Servo.h>

Servo myservo1,myservo2; // create servo object to control a servo

const int ENG = 2; // pin lettura ricevente segnale motore INGRESSO
const int DIR = 4; // pin lettura segnale servo di direzione INGRESSO
const int IR = 8; // pin lettura segnale infrarosso INGRESSO
const int ENG_OUT = 9; // pin per segnale motore da inviare USCITA
const int DIR_OUT = 10; // pin per segnale direzione servo da inviare USCITA

long engine; // segnale imposto per la potenza motore
long direct; // segnale imposto al servo di direzione

long RX_engine; // segnale proveniente dalla ricevente potenza motore
long RX_direct; // segnale proveniente dalla ricevente servo direzione

int val_1,val_2;


//__________________________________________________ ________________
void setup()
{
// initialize serial communication:
Serial.begin(38400);
myservo.attach(ENG_OUT);

pinMode(ENG, INPUT);
pinMode(DIR, INPUT);
pinMode(IR, INPUT);
}
//__________________________________________________ ________________
void loop()
{

RX_engine = pulseIn(ENG, HIGH);
RX_direct = pulseIn(DIR, HIGH);

val_1 = map(RX_engine, 1050, 1850, 0, 180);
val_2 = map(RX_direct, 1050, 1850, 0, 180);


myservo.write(val_1);
}

le sbavature sono dovute al fatto che non hai disattivato l'interrupt per far funzionare i vari delay()
aggiungerei che il pulsein e la libreria servo non sono i metodi piu efficienti ...

[gawain]

a supporto di quanto sopra
allego il PPM.h che contiene un decoder ppm molto configurabile con validazione del frame, un driver pr 6 servi con risoluzione 1000 o 2000 count a seconda che si usi un 8 o 16 mhz, il driver è sincronizzato col ppm in ingresso per minimizzare la latenza..
il sistema è assolutamente glitch free perche:
1- sono disbilitati gli iterrupts primpostati dalla piattaforma arduino
2-è implementato un anticollisione fra i 2 interrupts del driver e quello di scansione dell'ingresso ppm
l'ingresso ppm è testato periodicamente tramite interrupt in modo da non risentire della lunghezza del programma utente (es. autopilota)

[faustog_2]

grazie Gawain..

la tua osservazione è stata preziosa.. .. come accennato è da poco tempo che smanetto su Arduino.. ..al momento faccio riferimento solo agli esempi che trovo sull'IDE di arduino. ..bene la discussione sta prendendo una direzione "costruttiva" penso che chi legge o leggerà in futuro.. avrà modo di apprendere.. mi pare che comunque questo problema degli interrupt me lo facessero anche i Microchip per esempio il Pic16F628..

a presto

Originalmente inviato da gawain

a supporto di quanto sopra
allego il PPM.h che contiene un decoder ppm molto configurabile con validazione del frame, un driver pr 6 servi con risoluzione 1000 o 2000 count a seconda che si usi un 8 o 16 mhz, il driver è sincronizzato col ppm in ingresso per minimizzare la latenza..
il sistema è assolutamente glitch free perche:
1- sono disbilitati gli iterrupts primpostati dalla piattaforma arduino
2-è implementato un anticollisione fra i 2 interrupts del driver e quello di scansione dell'ingresso ppm
l'ingresso ppm è testato periodicamente tramite interrupt in modo da non risentire della lunghezza del programma utente (es. autopilota)

[faustog_2]

OK ho capito.. è arrivato (immediatamente) il momento di mettersi a studiare il datasheet! cercando di capire il software.. immediatamente sorge l'esigenza di conoscere i nomi dei registri e i bit relativi agli interrupt

http://www.atmel.com/Images/8271S.pdf

man mano faremo interventi sugli argomenti PWM, interrupt, Timer.

PEr esempio per leggere il segnale PPM da una ricevente serve appunto saper usare il Timer1 attraverso la lettura partendo dal valore LOW.. aspetta che esso diventi HIGHT.. appena cambia di stato.. comincia a contare.. fino a quando appunto non ritorna a valore basso LOW..

a dopo
fausto

[gawain]

Originalmente inviato da faustog_2

OK ho capito.. è arrivato (immediatamente) il momento di mettersi a studiare il datasheet! cercando di capire il software.. immediatamente sorge l'esigenza di conoscere i nomi dei registri e i bit relativi agli interrupt

http://www.atmel.com/Images/8271S.pdf

man mano faremo interventi sugli argomenti PWM, interrupt, Timer.

PEr esempio per leggere il segnale PPM da una ricevente serve appunto saper usare il Timer1 attraverso la lettura partendo dal valore LOW.. aspetta che esso diventi HIGHT.. appena cambia di stato.. comincia a contare.. fino a quando appunto non ritorna a valore basso LOW..

a dopo
fausto

in realta conta sempre in continuo e l'igresso non fa che memorizzare di volta in volta tul registro il valore del contatore dopo ricavii n maniera asincrona(tanto c'e tutto il tempo) la differenza tra due memorizzazioni successive.
il vantaggio di non resettare mai il contatore permette di poterlo usare anche per il driver dei servi, e per eventualmente generare un ppm in uscita sul pin 9.
non bisogna dimenticare che sul 328 cè solo un contatore 16 bit.
p.s. nota che facendo la differena tra unsigned no c'è bisogno di testare quando si attraversa lo zero perche la diiff sara sempre corretta

[Tom_1971]

Originalmente inviato da gawain

a supporto di quanto sopra
allego il PPM.h che contiene un decoder ppm molto configurabile con validazione del frame, un driver pr 6 servi con risoluzione 1000 o 2000 count a seconda che si usi un 8 o 16 mhz, il driver è sincronizzato col ppm in ingresso per minimizzare la latenza..
il sistema è assolutamente glitch free perche:
1- sono disbilitati gli iterrupts primpostati dalla piattaforma arduino
2-è implementato un anticollisione fra i 2 interrupts del driver e quello di scansione dell'ingresso ppm
l'ingresso ppm è testato periodicamente tramite interrupt in modo da non risentire della lunghezza del programma utente (es. autopilota)

Capisco che il codice che hai scritto prende gli input di una rx e a sua volta comanda dei servi, giusto? Ovviamente la cosa ha senso se uno fa delle operazioni sul comando ricevuto dalla rx prima di mandarlo ai servi, no? Ad esempio in base agli input di certi sensori o altro. Altrimenti si possono risparmiare i 20 Euro di Arduino Ho capito bene?
Oddio, si potrebbe anche usare l'Arduino ad es. per realizzare dei mix "creativi" fra i canali oppure delle curve (esponenziali o di giri/passo per un eli) personalizzate al di là delle possibilità offerte dalla radio che si usa. Potrebbe funzionare?