Arduenoveotto - prova scheda con L298 incorporato..

cyclone:
@dab77
appoggio pienamente astrobeed per la storia del petardo.... per i segnali DIR e PWM lo schema che ti consiglio è in allegato.
attenzione ai diodi, ti sconsiglio 1N4004 poichè non sono adatti per questa applicazione.... io utilizzerei qualcosa del tipo fast recovery time BYV27 o superiori.
gli invertitori a tran potrebbero funzionare anche se io li sostituerei con delle porte invertenti magari a trigger schmitt tipo CD40106... /CD4093
inoltre sulle uscite "sense" esce un putiferio .... filtra prima di immettere i segnali sull'adc.

PS: perchè non pensi pure alla gestione di 2 encoder..(magari attraverso l'impiego di chip qu-enc esterni) così da prevedere una controllo a loop chiuso con PID?

KIERUNEK = direzione
PWM = pwm :slight_smile:

ciao

Ciao, allora gli 1N4004 in realtà li ho usati solo come simboli, ho dimenticato di mettere il nome giusto. sorry..
Poi, sto facendo una prova con un'altra schedina che avevo pronta con l'L298N, e sto utilizzando come porta NOT un MC74HC14 che avevo.
Le due direzioni funzionano come spiegato da Astro. (grazie del link) in modalità LAP.
L'unica cosa, Astro, è che così non puoi usare la funzione "freno", giusto?
invece nel disegno che hai messo tu, Cyclone, non riesco a capire se si può.
Riguardo agli encoder, l'avevo scritto nel primo post, che era il punto dove volevo arrivare, ma per gradi.

Allora, carta e matita alla mano, mi pare di capire che con quelle logiche (suggerite da cyclone)con dir HIGH ottengo In2 sempre LOW e In1 PWM.
con dir LOW il contrario. indi anche qui niente funzione "freno", che si ottiene con entrambi gli input alti.

EDIT:
In realtà il datasheet dell'L298 dice che la funzione "freno" avviene con EN alto e in1=in2, quindi sia alti che bassi...
a questo punto tornando al più semplice metodo LAP, si potrebbe ipotizzare una resistenza di pulldown su entrambi gli input, di modo che se si imposta il canale usato come PWM come un INPUT, l'L298 vede entrambi gli ingressi come LOW?

nello schema che ho postato il freno non può essere implementato...... hai solo direzione e pwm,
ma ti assicuro che se implementi il controllore PID il freno non ti serve a nulla, anzi non lo devi neppure nominare :slight_smile:

e come fai a tenere il motore in posizione (fermo) se hai un carico applicato? ovviamente escludendo per ora freni magnetici...

E' il controllo PID (Proporzionale-Integrale-Derivativo) che agendo opportunamente sul PWM e sulla Direzione fornisce la giusta regolazione affinchè il motore rimanga bloccato, nel caso che la velocità sia impostata a zero, o mantenga la velocità costante al variare del carico applicato sull'asse.

il freno non si usa assolutamente in questi casi.... peggiorerebbe il tutto con catastrofi mai viste !

non lo so se sono daccordo..
non limitiamoci solo alle ruote motrici. immagina per esempio che io ho un motore attaccato ad un tamburo che arrotola una corda con 10kg di peso "appeso".
vado su, vado giù, poi devo tenere il peso fermo per 3 minuti. il PID diventa scemo se deve fare su, giù,su, giù continuamente per tenere la posizione.
Sto solo ragionandoci su, perchè in effetti nelle CNC basta il controllo del PID, questo lo so.
Però per lavoro io utilizzo paranchi controllati da computer, e quando questi vanno in stop, interviene il freno magnetico, così da far riposare il driver..
certo, bisognerebbe vedere questo tipo di frenatura quanto tiene e quanto conviene rispetto all'applicazione..

In quel caso (paranchi) meglio usare gli elettropermanenti e non gli elettrofreni, perchè più sicuri.... in termini protezionistici.
cmq .... per realizzare un motion control completo è chiaro che il solo PID (nudo e crudo) non basta, anche perchè nel caso del controllo di posizione con andamento trapezoidale della velocità la cosa si complica e non di poco.

non ho mai parlato di elettrofreni con frenata attiva, che ovviamente non sono sicuri...
Comunque, per fare esperimenti ridisegno la scheda con 3 pin di controllo per ogni ponte, così poi capisco se serve o no 'sta benedetta funzione di brake..

dab77:
non ho mai parlato di elettrofreni con frenata attiva, che ovviamente non sono sicuri...
Comunque, per fare esperimenti ridisegno la scheda con 3 pin di controllo per ogni ponte, così poi capisco se serve o no 'sta benedetta funzione di brake..

Nel caso che citi il brake non serve quasi a nulla, difficilmente il motore starà fermo da solo in quello condizioni, serve una vera frenatura elettronica che ottieni proprio grazie al pid controllo posizione e alla modalità LAP che ti permette il controllo su tutti e quattro i quadranti.
Comunque se vuoi ottenere lo stesso il freno dei 298 basta che usi delle porte NAND con three state per pilotare gli input e delle pull up, quando vuoi frenare metti le NAND in condizione di alta impedenza ed il gioco è fatto.

Eccoci. dopo aver fatto le dovute prove per capire cosa veramente si ottiene 'frenando' il motore dal ponte H, comprendo che raramente può servire questa funzione.
però se si hanno pin liberi tanto vale averla a disposizione. Ho provato ad usare delle pull-up sui pin di controllo, ma non va. ho provato sia con 10k ohm, che con 1k, impostando il pin di controllo di arduino come INPUT, il motore invece di fermarsi continua ad andare in un verso al massimo. Siccome il pin di controllo passa per una porta NOT e da li si sdoppia sui due pin di controllo del ponte, immagino che alla porta NOT non piaccia molto se gli metto le pull-up.
A questo punto trovo molto più semplice usare 6 pin dell'Atmega328p.
Per gli encoder invece conto di usare gli interrupt in questa prima bozza (sapendo di scontrarmi con le limitate risorse del chip... invece cosa consigliate per la lettura dell'encoder esterna all'Atmega?), ma ho visto sul playground un sacco di modi per leggere e contare... ce n'è qualcuno da preferire? inoltre per due encoder (quindi doppia lettura A,B..) riesco a cavarmela con due soli interrupt e due pin normali, o devo attivare altri due interrupt?

Grazie, Davide.

EDIT: Ah, dimenticavo, ho preso un pò di questi sensori di quadratua per provare: AEDR-8300 e realizzerò le ruote dentate con la fresa CNC. Qualcuno ha già provato o conosce quei moduli? il prezzo e le specifiche promettono bene (considerando il livello hobbistico, ovviamente..)

ciao dab,
Come contatori decodificatori in quadratura potresti usare gli LS7366 32bit con interfaccia SPI oppure HCTL2032 che purtroppo costa un tantino... ma ti libera la cpu da incombenze bestiali.
L'HCTL è un dual channel encoder (gestisce due encoder con index) e lavora, se non ricordo male, fino a 20Mhz o più, ha una interfaccia parallela e lo puoi tranquillamente interfacciare mappandolo in memoria se utilizzi Atmega128 o superiori.

PS. hai capito finalmente che il freno non ti serve?
ciao

Grazie delle info.
allora l'HCTL si trova su RS intorno ai 9-10€, nella versione dual channel (2032) in SMD, oppure singolo ma con la comodità del DIP20, anche se con qualche funzione in meno..
chiariscimi però una cosa, quello manda sui suoi 8 pin 4 byte a richiesta uno dopo l'altro, a seconda di come imposti i pin SEL1 e SEL2, e lo riesce a fare a 33MHz, o meglio quello è il clock, se non ho capito male si aggiorna ogni 31ns...mumble,mumble... 32,2MHz!
con Arduino non so di preciso quanto veloce riesci a fare 4 letture consecutive di 8 pin, ma a palmoni dopo che hai letto il primo byte e cominci a leggere il secondo, sto numero di 32bit già è cambiato! tempo che li leggi tutti e 4, può essere cambiato non poco...o sbaglio? o sto facendo i conti senza l'oste, tipo che riesco tranquillamente a leggere tutti e 32 i bit prima che un motore che gira a 10000 rpm riesca a finire uno step completo di encoder? tipo, oggi mi sono fatto questa rozza ma simpatica ruota dentata , che ha 75 denti...se andassi ipoteticamente a 10000 giri al minuto avrei 10000754/60=50000 letture al secondo, che dopo estenuanti calcoli intuisco essere 50kHz... cioè un nuovo valore ogni 20us, giusto? ce la fa Mr Arduino a impostare i due SEL pin e leggere 8bit 4 volte consecutive in 20ns? ...in effetti mi sembra di si, ma aspetto conferme..

dab77:
allora l'HCTL si trova su RS intorno ai 9-10€, nella versione dual channel (2032) in SMD, oppure singolo ma con la comodità del DIP20, anche se con qualche funzione in meno..

Dipende da cosa devi fare con gli encoder, gli HCTL 2032 ti forniscono solo il numero di click dell'encoder tra due letture successive, ovvero la distanza percorsa, non ti forniscono la velocità e non puoi nemmeno saperla facendo un calcolo in base ai click trascorsi tra due letture perché non hai alcuna certezza se la velocità è rimasta costante o se il motore non ha invertito il senso di rotazione.
Gli HCTL 2032 sono componenti obsoleti che non usa più nessuno, molto meglio usare un micro dotato di modulo QEI (Quadrature Encoder Interface), il che mette fuori gioco l'ATmega 328 col quale puoi scordarti di gestire un pid realmente efficiente per gestire un motore veloce.
Un ottimo processore per gestire due motori, sia come controllo velocita, coppia e distanza, è il dsPIC33 serie MC (Motion Controller), costano circa 6 Euro, includono 2 moduli QEI, sono dei 16 bit con core DSP da 40 Mips reali, sono dotati di DMA e un ricco assortimento di periferiche, incluso un sofisticato generatore pwm che consente il controllo anche di motori brushless,
Per farla breve, se vuoi realizzare un controllo motori realmente efficiente devi usare il giusto micro, l'ATmega 328 è un general purpose, ci puoi realizzare un controllo motori, ma nulla di performante e efficiente se parliamo di movimenti veloci.

Simpatici 'sti chip, grazie! trovati diversi tipi qui da rs (cliccando su prodotti simili..). la serie MC parte nelle versioni semplici da meno di 3€.. quello del link sta a 4€ con un canale. insomma ce ne sono di vari tipi, molto belli...
domandina da 'gnorante...come si programmano questi? intanto continuo a leggermi un pò di datasheet.. la ricerca su rs comunque lascia sempre a desiderare, ho passato una serata a cercare cose tipo: 'quadrature counter' o 'quadrature decoder' e varie, ma uscivano fuori solo gli HCTL..

Grazie ancora dell'interessamento.
Davide.

EDIT: Trovato, si scaricano IDE e Compilatore in versione prova (completamente funzionanti, a parte poche funzioni di nicchia), che gira su win..
poi si tratta di C. mmmh...

MA invece, per rimanere in ambito Atmel, che ne dici degli XMega? hanno il loro modulo QEI.. almeno li programmo da Linux..

Se scarichi MikroC nella versione PIC (cè anche per AVR e AMR e funziona davvero bene) puoi programmare i pic in maniera molto più semplice che non con MPLAB....
Non l'ho mai terminata ma se ti può essere d'aiuto leggiti questa (è un inizio) :

Tutorial PIC.pdf (190 KB)

dab77:
MA invece, per rimanere in ambito Atmel, che ne dici degli XMega? hanno il loro modulo QEI.. almeno li programmo da Linux..

Gli Xmega non li uso, i dsPIC33 sono nettamente superiori, costano di meno e li trovi pure in case pdip 28, MPLAB c'è anche per Linux e MAC OS, devi scaricare MPLABX che usa come IDE Netbean, la versione free dei compilatori Microchip, quello per i dsPIC usa come engine gcc con apposite librerie di cross compiling realizzate da Microchip, ha come unica limitazione il non poter usare i livelli superiori per le ottimizzazioni, cosa che non crea nessun problema per un uso amatoriale.
Se ti serve il software che usa il doppio modulo QEI e ti fornisce su SPI/I2C/UART gli ultimi valori di posizione e velocità del motore, volendo congelati ad istanti precisi predeterminabili, te lo passo io già pronto all'uso, in pratica ti diventa un'interfaccia intelligente per due encoder.
Se cominci ad usare i dsPIC stai pure certo che poi molli Arduino :grin:

astrobeed:

dab77:
MA invece, per rimanere in ambito Atmel, che ne dici degli XMega? hanno il loro modulo QEI.. almeno li programmo da Linux..

Gli Xmega non li uso, i dsPIC33 sono nettamente superiori, costano di meno e li trovi pure in case pdip 28, MPLAB c'è anche per Linux e MAC OS, devi scaricare MPLABX che usa come IDE Netbean, la versione free dei compilatori Microchip, quello per i dsPIC usa come engine gcc con apposite librerie di cross compiling realizzate da Microchip, ha come unica limitazione il non poter usare i livelli superiori per le ottimizzazioni, cosa che non crea nessun problema per un uso amatoriale.
Se ti serve il software che usa il doppio modulo QEI e ti fornisce su SPI/I2C/UART gli ultimi valori di posizione e velocità del motore, volendo congelati ad istanti precisi predeterminabili, te lo passo io già pronto all'uso, in pratica ti diventa un'interfaccia intelligente per due encoder.
Se cominci ad usare i dsPIC stai pure certo che poi molli Arduino :grin:

e tu che ci fai ancora qua, allora!!! XD XD bè, le potenzialità le posso immaginare.. uno dovrebbe sapere usare varietà di chip, a seconda dell'uso che di volta in volta ne devi fare.. ovvio che se devo fare dei giocattolini, le porte e la velocità dell'atmega, con la sua programmazione semplificata sono i migliori, ma studiare anche cose più potenti mi piacerebbe molto.
m'intrigano molto 'sti dspic33, se puoi mandarmi quel software te ne sarei molto grato, anche perchè non ho idea di come sia strutturato il loro codice, quindi me lo studio volentieri. intanto cerco anche degli esempi o dei tutorial in giro.

Grazie, Davide.

@Ratto grazie, me la leggo di sicuro.

Ciao!

astrobeed:
Dipende da cosa devi fare con gli encoder, gli HCTL 2032 ti forniscono solo il numero di click dell'encoder tra due letture successive, ovvero la distanza percorsa, non ti forniscono la velocità e non puoi nemmeno saperla facendo un calcolo in base ai click trascorsi tra due letture perché non hai alcuna certezza se la velocità è rimasta costante o se il motore non ha invertito il senso di rotazione.

Sul fatto che adesso è un componente obsoleto te ne do atto, ma proprio per questo motivo si trova anche a 1.0 euro o meno.
Ma sul fatto che non riesci a misurare la velocità ....
Beh! su questo ti contraddico poichè basta implementare un sample-timer ed aggiornare ad ogni chiamata di int la lettura della posizione ....
ogni 10mSec calcoli la differenza tra la nuova lettura e la precedente ed ottieni perfettamente la velocità espressa in numero di impulsi/10mSec oppure altro rapporto... dipende dalla precisione e da quello che ti serve.
L'HCTL2032 (obsoleto) che non usa più nessuno :slight_smile: è, anzi è stato un ottimo counter up/down, dual-channel quadrature decoder con index..... fino al 2010.
Per non parlare del famosissimo HCTL1100 che adesso proprio la
Mektronix MCP-1200 Motion Control IC plug-in compatible to surplus HCTL-1100 and HCTL-1100#PLC ha riprogettato e riconvertito in MCP-1200 dopo aver acquisito i diritti dalla HP e AVAGO, per rimetterlo sul mercato con caratteristiche attuali e performanti rispetto al suo predecessore che oltre alla decodifica in quadratura implementava un pid hardware,
generatore di profilo trapezoidale, generatore fasi x stepmotor, uscita dac, uscita pwm ... una moltitudine di registri per azionare al meglio motori molto diversi tra loro.

Poi è chiaro che impiegando al posto del cippetto m328p un xMega hai risolto il problema..... ma questo è un altro discorso...
qui dab77 voleva qualcosa da collegare al suo arduinetto per leggere 2 encoder.

anche io ho risolto da tempo queste problematiche passando agli xMega....e ai Cortex-M3....

Ciao

sono arrivati oggi i fotoquadratori AEDR-830 da domani mi ci metto.. nel frattempo mi chiedevo...
ma una volta che uno ha un encoder con lettura tutto bello funzionante, cosa deve aggiungere per farlo diventare assoluto?
immagino un qualche tipo di memoria, ma che si fa si scrive ad ogni lettura? mi pare un pò tanto... oppure si mette una batteria tampone e si fa una scrittura solo quando viene a mancare l'alimentazione?

Allora, giusto per completare la discussione, dopo ponderato pensare :slight_smile: alla fine ho preso dei dsPIC33FJ64MC802 ed il programmatore pickit2. Gli XMega alla fine sembravano più difficili da programmare, meno efficenti e oltretutto non c'è versione PDIP.
Chiedo scusa per l'insistenza dell'OT, ma purtroppo, finchè non arriva la signorina Arduino DUE, pare che non si possono leggere encoder in quadratura a velocità decenti..

Ciao!