ElectroYou

Salve a tutti!

Rieccomi di nuovo con un piccolo problema di tipo robotico/informatico. Come alcuni sapranno, sono l'autore del Robot Ampliabile , e da poco ho aggiunto al piccolo robot nuovi sensori, quali sensori segui-linea, anti-caduta ed evita-ostacoli ad infrarosso. Ora volevo montare degli encoder ai due motori del robot, misurando così con precisione la velocità e la distanza. Per la parte elettrica, non penso di avere troppi problemi (non ho ancora realizzato niente, solo idee). Mentre ho qualche dubbio su come gestire il tutto via software. Il PIC in questione è il famoso 16f877, e avevo in mente di utilizzare due dei tre timer incorporati all'interno del PIC, utilizzando gli impulsi dell'encoder come clock per il timer. Ho sparato assurdità?
Volevo sapere se è possibile fare ciò e se cambia qualcosa il fatto che i moduli CCP (sia 1 che 2) sono in funzione (generano due onde quadre per il pilotaggio dei motori)? E poi come faccio a inizializzare i due timer (1 e 2)? Io so solo utilizzare il timer 0 e sono anche riuscito a misurare i giri al minuto di un motorino con encoder.
Programmo in C con MikroC PRO e per quanto riguarda la frequenza massima degli impulsi che possono arrivare al PIC (non so se può essere rilevante questa informazione) non l'ho ancora ipotizzata. Dovrei misurare i giri al minuto della ruota e moltiplicarli per la riduzione meccanica degli ingranaggi (pensavo di mettere il sensore su una ruota dentata del riduttore per ottenere una misurazione più precisa possibile).

Grazie in anticipo,

Galaxi93,
la gestione di un encoder ottico va effettuata normalmente (non solo con i PIC) in un altro modo da quello da te ipotizzato. Però sei fortunato: il modo che vado a descrivere è supportato dai PIC

Il discorso che segue è valido per un encoder. Se disponi di due encoder, dovrai estendere il ragionamento.

Supponiamo di disporre di due canali in uscita dall'encoder, A e B. Se sei interessato, come credo visto iltuo ottimo lavoro sul robot ampliabile, a determinare tanto le rotazioni orarie quanto antiorarie, i segnali vanno utilizzati entrambi. Come sai, gli encoder presentano normalmente due canali i cui segnali sono sfasati di 90° elettrici.

Il segnale relativo al canale A lo colleghiamo ad un ingresso veloce del PIC, tipicamente un ingresso che può generare un interrupt: RB0/INT. Il canale B lo colleghiamo ad un altro input (ad es. RB1). Normalmente i segnali in uscita dall'encoder sono di tipo push-pull, quindi non avremo bisogno di una resistenza di pull-up o di pull-down per fissare uno stato logico noto. Dovremo però assicurarci che l'encoder dia un segnale con livelli logici TTL, compatibili con quelli del PIC.

Dopo aver configurato i pin RB0 e RB1 come INPUT, va configurata anche la risposta all'interrupt su evento esterno. Il pin RB0/INT scatena un interrupt ogni qualvolta il segnale asociato si porta dal valore logico 0 al valore logico 1 oppure viceversa (il datasheet indica come fare per configurare un caso o l'altro, agendo sul registro OPTION_REG). Supponiamo di aver configurato il PIC affinché l'interrupt si scateni sul passaggio da 0 a 1 del segnale A.
Quando di scatena un interrupt dovuto a RB0/INT all'interno della ISR (Interrupt Service Routine) andiamo a leggere il valore di RB1: se RB1 è alto, convenzionalmente stabiliamo che la rotazione dell'encoder (e del motore) è oraria, se fosse 0 stabiliamo l'opposto. Cosa vuol dire, in soldoni? Significa che andremo a incrementare o decrementare il contatore degli impulsi acquisiti. Chiaramente il numero di impulsi contati, stabilisce una posizione e non una velocità. Per risalire alla velocità, il numero degli impulsi va riferito ad una unità di tempo. E qui entrano in gioco i timer.

Ora, se disponiamo di due encoder da collegare ad un solo PIC, non è possibile utilizzare RB0/INT. Va invece impiegato IOC, Interrupt On Change. La modalità di funzionamento è similare a quella di RB0/INT se non che differisce per questi aspetti:
- IOC è assegnabile a 4 pin (RB4,..., RB7)
- IOC segnala un interrupt sia su eventi di rising edge sia di falling edge: nel fw va discriminato se si tratta di uno o dell'altro evento;
- IOC può contare "qualche impulso" prima di scatenare un interrupt (ma per il nostro caso non è consigliabile).


Prima di passare ai timer, ti consiglio di digerire quanto ho scritto.

Ciao.

Paolo.

Grazie della risposta Paolino, come al solito sei molto disponibile e le tue risposte sono sempre molto chiare e complete! (anche se a volte, nonostante la semplicità, non ci arrivo lo stesso…)

Allora, ammetto di non aver capito appieno quello che hai scritto, soprattutto sugli encoder:

Paolino ha scritto:Supponiamo di disporre di due canali in uscita dall'encoder, A e B. Se sei interessato, come credo visto il tuo ottimo lavoro sul robot ampliabile, a determinare tanto le rotazioni orarie quanto antiorarie, i segnali vanno utilizzati entrambi. Come sai, gli encoder presentano normalmente due canali i cui segnali sono sfasati di 90° elettrici.

In che senso hanno i canali sfasati di 90° elettrici? E poi i pensavo di utilizzare semplicemente un led ad infrarosso e un foto-transistor o qualcosa del genere per rilevare il fascio luminoso. Forse in questo caso non si chiama più encoder... scusa ma non avendo studiato nulla di queste cose, vado ad intuito.
E poi a me non interessa più di tanto sapere se il motore gira in un senso o nell'altro, anzi, più che altro non mi serve occupare una porta in più per saperlo, si spera che il PIC sappia in che direzione sta facendo girare il motore, no?

E questo IOC? Di cosa si tratta? Ho fatto una veloce ricerca, e ho trovato che misura il tempo che trascorre tra un impulso e un altro...è vero?

Grazie,

Galaxi93 ha scritto:In che senso hanno i canali sfasati di 90° elettrici? E poi i pensavo di utilizzare semplicemente un led ad infrarosso e un foto-transistor o qualcosa del genere per rilevare il fascio luminoso. Forse in questo caso non si chiama più encoder...

Osserva questa immagine.

Rappresenta i segnali A e B in uscita da un encoder TTL. L'immagine propone due grafici: quello superiore che (per convenzione) mostra la rotazione oraria (CW, Clock Wise) dell'encoder e quella inferiore l'antioraria (CCW = Counter Clock Wise).
Supponiamo di poter scatenare l'interrupt sul fronte di salita del canale A; analizza quello che accade nell'intorno del fronte, all'interno dell'ovale. Osservando B nel momento in cui si scatena l'interrupt si può distinguere il caso in cui la rotazione sia oraria (B = 0 logico) da quella antioraria (B = 1 logico).

Un sistema costituito da fotodiodo, fototransistor e disco forato è ancora un encoder; la risoluzione probabilmente sarà limitata ma sempre di encoder ottico si può parlare.

L'Interrupt On Change è un sistema adottato per poter rilevare variazioni di stato di una porta fisica; l'interrupt si scatena tanto sui fronti di salita quanto sui fronti di discesa e questo, come puoi immaginare, può permettere la misura della distanza temporale (intervallo) tra due fronti e quindi misurare ad esempio la durata di un'onda quadra. Nel tuo caso il sistema IOC è adottabile, con qualche accorgimento; all'interno della ISR dovrai escludere tutti gli eventi di interrupt riconducibili (ad esempio) a fronti di discesa e contare solamente quelli relativi ai fronti di salita. Il conteggio degli impulsi ti da lo spazio percorso: il numero va incrementato quando piloti i motori in senso positivo e decrementato viceversa. Ma cosa accade se stai pilotando il motore in avanti e per qualche ragione la ruota viene trascinata all'indietro? Gli impulsi che giungono al PIC vanno ad essere incrementati in quanto tu stai pilotando con logica "motore avanti" mentre il robot sta andando all'indietro... Ecco perché è utile disporre di due canali (A e B). Ma se vuoi, questa è una sofisticazione, per il tuo robot. Credo che la soluzione che tu vai a prospettare possa essere sufficiente.

Ciao.

Paolo.

Ah ok, ora penso di aver capito. Quindi alla fine, sono due sensori posti l'uno accanto all'altro (+ o -).

Paolino ha scritto:Un sistema costituito da fotodiodo, fototransistor e disco forato è ancora un encoder; la risoluzione probabilmente sarà limitata ma sempre di encoder ottico si può parlare.

Anche di questo ne volevo parlare. perché, non ho la possibilità di mettere un disco forato o colorato sull'asse della ruota per questioni di spazio. Allora avevo pensato di mettere i due sensori all'interno del riduttore (ho trovato lo spazio) su una delle ruote dentate che verrà adeguatamente forata. Mettendo il sensore su una ruota che gira "più velocemente " rispetto alla ruota, e quindi fa più giri, ho una risoluzione nettamente superiore. Il problema è che per mia sfortuna, le ruote dentate hanno un rapporto strano, che da un risultato periodico.
Per sicurezza ti riporto i numeri di denti dei vari ingranaggi in ordine dal motore alla ruota:
8-32; 9-37; 9-37; 8-24.
Io pensavo di mettere il sensore sulla terza coppia, quella da 37 denti. Il risultato è che ad ogni giro della ruota, questa ruota fa 12,3 periodico giri... come lo risolvo questo inconveniente??
Mentre la circonferenza della ruota è di 18cm circa (devi misurala con strumenti più precisi). Quindi ad ogni giro di quel ingranaggio, la ruota percorre 1,459cm.
Il che vorrebbe dire che se questa cifra periodica, la arrotondo per 1,46cm, ogni 100 giri della ruota percorro 146cm (teorici), mentre praticamente ne farà 145,945cm... penso che 0,055cm sia tollerabile no?
Se qualcuno mi controlla i conti, gli ne sarei molto grato!

Comunque alla fine, quello che mi piacerebbe fare, sarebbe di riuscire ad far andare quasi perfettamente dritto il robot, agendo sul duty cycle dei motori in tempo reale. Spero tanto che sia possibile da attuare, altrimenti mi dovrò accontentare.

Paolino ha scritto:Ma cosa accade se stai pilotando il motore in avanti e per qualche ragione la ruota viene trascinata all'indietro?

Ti posso assicurare che ciò è impossibile! perché i motori hanno una bella coppia e il peso del robot è insufficiente ad creare un tale attrito con la ruota e il pavimento (capita spesso che la ruota giri, senza che il robot si muova)

Per il fatto del IOC non ho capito ancora bene, magari un esempio pratico o un qualche documento farebbe comodo.

un'altra idea che mi era venuta, è quella di utilizzare due timer per incrementare o decrementare una variabile in base agli impulsi, mentre attraverso un terzo timer, si calcolano i giri al min sapendo che quel timer genera un interrupt ogni tot tempo. E' fattibile?

Ciao e grazie ancora!

Per far andare dritto il robot devi fare un bel controllo di velocità! L'ideale è realizzare un regolatore PI(D).
I tuoi conti non li ho verificati; non hai modo di fare una misura direttamente sull'albero del motore? Non hai modo di inserirti lì?

Ciao.

Paolo.

Bè, io pensavo semplicemente di far girare alla stessa velocità i due motori, agendo sul PWM...

Paolino ha scritto:I tuoi conti non li ho verificati; non hai modo di fare una misura direttamente sull'albero del motore? Non hai modo di inserirti lì?

E non so... lo spazio c'è, però non so cosa fare precisamente... Ti allego qualche foto.





Secondo te, che risoluzione dovrebbe avere? Intendo, quando dovrebbe essere il passo minimo del robot in cm? Più o meno. Volendo potrei stampare a computer un disco con delle tacchete nere a distanze uguali, su della carta acetata...

Se ho tempo, entro stasera provo a scrivere qualcosa, seguendo l'idea che avevo postato sopra.

Ciao,

Come promesso, ho provato a scrivere qualcosa... non ti scandalizzare per le cavolate che avrò scritto, ma sono troppo stanco (studiare storia ha un brutto effetto su di me ) e poi ci sono alcuni aspetti che non conosco.

Ho cercato di commentare il codice il più possibile, quando hai tempo e voglia prova a darci un occhiata.

Codice: Seleziona tutto

char t=0;
int encoder_sx, encoder_dx
int giri_sx, giri_dx;
char rpm_dx, rpm_sx;


  void interrupt (void)
{
   if (intcon.T0IF)
      {
      t++;   //incrementa t
      if (t==10)           //In questo modo, ogni 10 interruzioni calcola i giri per minuto (ogni 100ms+o-)
         {
         rpm_dx=giri_dx*600;     //Moltiplica  i giri effettuati, per 600.
         rpm_sx=giri_sx*600;
         giri_sx=0; giri_dx=0;
         }
      tmr0=100;
      intcon.T0IF = 0;
      }
   if (//Che metto qui x il timer 1?)
      {
      encoder_sx++;
      giri_sx=encoder_sx/n; //Per ottenere i giri della ruota, divide gli impulsi per le tacchete del disco (n va sostituito con il numero esatto).
      tmr1=255;
      //Manca qualcosa qui?
      }
   if (//Che metto qui x il timer 2?)
      {
      encoder_dx++;
      giri_dx=encoder_dx/n; //Per ottenere i giri della ruota, divide gli impulsi per le tacchete del disco (n va sostituito con il numero esatto).
      tmr2=255;
      //Manca qualcosa qui?
      }
}


void main (void)
     {
     trisa=1;
     trisb=0;
     trisc=0;
     porta=0;
     portb=0;
     portc=0;

     //Timer 0
     OPTION_REG=0x07;           //Imposto un prescaler 1/256.
     TMR0 = 100;                //In questo modo ottengo un'interruzione ogni 10ms
                                //T =(256-100)x(4/16)x 256 = 9984uS=9,984ms

     INTCON.T0IE = 1;
     INTCON.GIE  = 1;
     
     //Timer 1
     T1CON=0x03;                //Penso di aver impostato prescaler 1/1 e il clock è dato dalla porta RC0.
     TMR1 = 255                 //In questo modo ad ogni impulso, si genera un interruzione.
     //??? Cosa devo mettere poi?
     
     
     //Timer 2
     T2CON=0x04                 //Penso di aver impostato prescaler 1/1 e il clock è dato... come si fa ad impostarlo?
     TMR2 = 255                 //In questo modo ad ogni impulso, si genera un interruzione.
     while(1)
             {

             }

     }

Saluti,

Mmmhh...
A dire il vero a me non piace come lo hai impostato, per alcune ragioni:
- non mi è chiaro il modo che hai scelto per acquisire gli impulsi encoder;
- non capisco perché vuoi tirare in ballo 3 timer differenti;
- non mi è chiaro il voler moltiplicare il numero degli impulsi per 600 (o meglio, questo aspetto lo chiariamo poi, un'idea ce l'ho);
- ci sono un po' di errore "formali";
- non hai indicato la velocità massima del motore e quella stimata, secondo i tuoi calcoli, sulla ruota alla quale applichi l'encoder.

Io ti suggerisco questo approccio, poi sei libero di fare come credi, ovviamente

I segnali in arrivo dall'esterno devono essere acquisiti. Il PIC16F877A ha due modalità per acquisire segnali veloci dall'esterno: INT e IOC. Siccome dobbiamo acquisire due segnali con un solo PIC, dobbiamo purtroppo scartare l'ipotesi INT e concentrarci su IOC.
IOC lavora sulle porte RB4, ..., RB7. Scegliamo RB4 e RB5
Partiamo con configurarlo:

Variabili globali e macro che serviranno nel codice:

Codice: Seleziona tutto

// Macro
#define AVANTI 1
#define INDIETRO 0

// Variabili globali
volatile unsigned int uiEncoderDx, uiEncoderSx; // Impulsi encoder per ciascuna ruota
volatile char chActualStatubPortb; // Variabile di appoggio per la lettura della porta PORTB
volatile unsigned int uiSpeedDx, uiSpeedSx; // Velocità delle due ruote
long lGlobalCounterDx, lGlobalCounterSx; // Contatori globali dello spazio percorso
char flag_Movimento;


Codice: Seleziona tutto

void InitPic (void)
{
   TRISB = 0x30; // Corrisponde a 0011 0000, RB4 e RB5 INPUT, gli altri OUTPUT
   INTCON.RBIE = 1; // Abilita solamente Interrupt On Change

   uiEncoderDx = 0;
   uiEncoderSx = 0;
   lGlobalCounterDx = 0;
   lGlobalCounterSx = 0;

   // Da inserire: tutte le altre impostazioni e l'abilitazione dell'interrupt generale
   // .........
}


All'interno della Interrupt Service Routine (ISR) andiamo a gestire l'evento IOC; come dice l'espressione, Interrupt On Change indica lo scatenarsi di una interruzione a fronte di una variazione di stato logico della porta RB4, ..., RB7. La variazione di stato l'abbiamo tanto per il passaggio da 0 a 1 logico quanto viceversa. Per convenzione (scelta da me, in questo caso), stabiliamo che un segnale è considerato "da acquisire" quando passa da 0 a 1 mentre va scartato nel caso opposto.

Codice: Seleziona tutto

// ISR
void interrupt (void)
{
   // Gestione IOC
   if (INTCON.RBIF) // Si è scatenato un interrupt on change. Ma quale???
   {
      chActualStatubPortb = PORTB; // Leggo la porta PORTB per conoscere i valori di RB4 e RB5
      if (chActualStatubPortb&0x10) // Se è RB4 è a 1
      {
         uiEncoderDx++;           // incrementa il contatore impulsi encoder ruota DX
         if (flag_Movimento == AVANTI) // Incrementa o decrementa la distanza globale percorsa dalla ruota DX
         {
            lGlobalCounterDx++;
         } else {
            lGlobalCounterDx--;
         }
      }

      if (chActualStatubPortb&0x20) // Se è RB4 è a 1
      {
         uiEncoderSx++;           // incrementa il contatore impulsi encoder ruota SX
         if (flag_Movimento == AVANTI) // Incrementa o decrementa la distanza globale percorsa dalla ruota SX
         {
            lGlobalCounterSx++;
         } else {
            lGlobalCounterSx--;
         }
      }
   }

   // TIMER 0
   //...
}


A questo punto valutiamo la velocità cui ruota ogni singolo encoderr, come numero di impulsi riferiti all'unità di tempo. Immaginiamo che l'unità di tempo sia il il centesimo di secondo (10ms). All'interno dell'interrupt andiamo ad inserire la gesione del calcolo della velocità.

Codice: Seleziona tutto

void interrupt (void)
{
   // Gestione IOC
   //... non la ripeto, tanto è già scritta prima

   // TIMER 0
   if (INTCON.T0IF)
   {
      uiSpeedDx = uiEncoderDx;
      uiSpeedSx = uiEncoderSx;
      uiEncoderDx = 0;
      uiEncoderSx = 0;

      INTCON.T0IF = 0;
   }

}



La scelta degli interi (int) è una opzione da valutare attentamente sulla base della risoluzione che avrà il tuo disco encoder e della velocità di rotazione massima alla quale si muove. Se si stima che ogni 10ms il numero degli impulsi può superare i 65535, è necessario passare ai long. Attenzione, però: l'uso dei long potrebbe far "esplodere" il codice in quanto vuoi far gestire a una macchiana 8 bit, dati a 32 bit.

Ho inserito anche il conteggio della strada percorsa da ciascuna ruota. Il flag fl_Movimento devi imporlo tu, nel codice, al valore AVANTI o INDIETRO per stabilire se incrementare o decrementare le distanze percorse.

Ti è chiaro come ho impostato il problema? IOC per il conteggio degli impulsi e TMR0 per il calcolo della velocità.
Prova a pensarci su e dimmi se è un approccio che riesci a seguire.

Ciao.

Paolo.

Immaginavo che il mio codice fosse una... hai capito

Per quanto riguarda il tuo di codice, non penso di avere capito tutto. Ad esempio, dovè che imposti quali porte sono input IOC? Basta dichiarare il trisb? E possono essere solo le porte RB4-7? (ahimè tutte porte già occupate...dovrò spostare qualcosa...).

Se ho capito bene, viene generato un interruzione ogni volta che su una delle 4 porte del IOC avviene un cambio di stato, giusto? Nel tuo codice acquisisci solo il passaggio da 0 a 1, giusto? E se dovessi considerare anche l'altro passaggio? Non avrei un raddoppio della risoluzione?

Per quanto riguarda la velocità e quindi la frequenza degli impulsi, mettendo l'encoder sull'asse della ruota e con la massima risoluzione possibile accettata dall'encoder (tutto approssimato), dovrei avere una frequenza di 18 impulsi (positivi=1) al secondo (18Hz... un po' scarsini...). La velocità della ruota dovrebbe essere di 60rpm (quindi 1 rotazione al secondo). Quindi avrei una risoluzione di 1cm ad ogni impulso positivo.
Se invece dovessi contare anche i passaggi da 1 a 0, avrei una risoluzione di 0,5cm e una frequenza di 36Hz.

Ciao e grazie mille per l'aiuto che mi stai dando!