Camme elettroniche

Scusate, ma alla fine il tutto non si traduce in uno "scostamento" fisso fra la posizione del motore master e quello slave?
cioè (avendo i 2 motori con encoder) basterebbe dire che la posizione del motore B è uguale alla posizione del motore A + lo scostamento previsto.

Janos:
Qualcuno ha qualche idea o ha mai utilizzato Arduino per realizzare camme elettroniche pilotando i motori in posizione o in velocità?

Dipende tutto dalla precisione richiesta e dalla velocità dei movimenti, Arduino non è molto adatto per questo tipo di problematiche, a meno che non sia solo come dimostratore a livello scolastico senza alcuna pretesa di precisione e velocità.
Ti consiglio di utilizzare un processore di classe superiore, molto indicati i dsPIC33 serie MC che sono specifici per il controllo dei motori, possono pilotare direttamente un Brushless, ovviamente tocca aggiungere la parte di potenza, ed eseguire nel contempo calcoli anche molto complessi, pure con float a 32 bit, senza particolari problemi grazie al core DSP.
Oppure vai direttamente su mcu con core ARM Cortex M3/M4, p.e. gli STM32 di ST che sono ottimi e costano poco.

No, non è così semplice. Con un semplice scostamento puoi solo descrivere rette, ovvero una lette del tipo y=m*x+q dome x è il master e y è lo slave. Con una legge del genere non puoi dire allo slave che deve fare una traiettorie strane...

@astro
Te pensa che mi sto documentando perché l'azienda per la quale lavoro utilizzano ancora gli z80 con affiancate 1-2 fpga per questo tipo di applicazioni... =)

Janos:
Te pensa che mi sto documentando perché l'azienda per la quale lavoro utilizzano ancora gli z80 con affiancate 1-2 fpga per questo tipo di applicazioni... =)

Non mi stupisce per nulla, fino a pochi anni fa gli Z80, e le varie evoluzioni, erano ancora largamente utilizzati.
Tieni presente che a livello industriale quando hai un prodotto che funziona bene, e continua a vendere, nessuno pensa a sostituirlo con un prodotto nuovo con tecnologia più recente fino a che non diventa obbligatorio perché le parti che costituiscono il prodotto sono diventate irreperibili e/o troppo costose.

Ma programmare una macchina complessa con 6 motori retroazionati e un bel po di uscite veloci in assembly è da manicomio...

Janos:
Ma programmare una macchina complessa con 6 motori retroazionati e un bel po di uscite veloci in assembly è da manicomio...

Con lo Z80 si lavorava tranquillamente in C, magari con parti in assembly per i punti time critical, comunque all'epoca io gli Z80 li programmavo direttamente in codice macchina senza nemmeno passare per l'assembly :smiley:

Loro lavorano tutto su assembly... Dici che mi conviene non provare nemmeno a proporre una soluzione con l'ARM che monterà l'Arduino Due?

Janos:
Loro lavorano tutto su assembly... Dici che mi conviene non provare nemmeno a proporre una soluzione con l'ARM che monterà l'Arduino Due?

Fino a che la DUE non sarà realmente disponibile, in teoria prima di fine mese, o almeno il suo IDE, è impossibile dire quello che ci si può fare realmente oppure no, almeno rimanendo all'interno del suo ambiente di lavoro, se invece decidi di programmarla in C, lascia perdere il C++, allora basta prendere in mano il datasheet del micro e valutare se contiene tutto quello che ti serve, andrà comunque verificata la mappatura dei pin sul connettore della DUE.
Se non ti interessa l'ambiente di Arduino il mio consiglio è andare direttamente su un STM32F4, ti prendi la scheda STM32F4 Discovery che costa meno di 15 Euro e inizi a lavorarci sopra, hai un processore con core Cortex M4 dotato di FPU senza compromessi di velocità e memoria, il micro costa meno di 10 Euro sulla quantità pertanto l'eventuale produzione di una scheda basata su quel processore ti costa molto meno di Arduino DUE e nulla vieta di usare direttamente la STM32F4 discovery come modulo da montare su una carrier.
In alternativa ci sarebbe anche la ottima Aria G25 di Acme System, azienda Italiana, dove puoi scegliere se usare il micro, un ARM9 @400 MHz, senza S.O. oppure metterci sopra una distro Linux, in particolare la Debian 6, ovviamente senza interfaccia grafica.

astrobeed:
....In alternativa ci sarebbe anche la ottima Aria G25 di Acme System, azienda Italiana, dove puoi scegliere se usare il micro, un ARM9 @400 MHz, senza S.O. oppure metterci sopra una distro Linux, in particolare la Debian 6, ovviamente senza interfaccia grafica.

No no, o ci metto KDE o niente... :stuck_out_tongue_closed_eyes: :stuck_out_tongue_closed_eyes: :stuck_out_tongue_closed_eyes: :stuck_out_tongue_closed_eyes:

Comunque grazie dei consigli. Il STM32F4 come si programma? C'è un framework per semplificare la vita, o quantomeno un RTOS, o tutto a livello HW?

Janos:
Comunque grazie dei consigli. Il STM32F4 come si programma? C'è un framework per semplificare la vita, o quantomeno un RTOS, o tutto a livello HW?

L'STM32 si programma in C, ci sono delle ottime librerie free che semplificano moltissimo la vita, il multitasking/multithread è supportato a livello hardware, per l'RTOS ne puoi usare uno qualunque, p.e. alcuni compilatori, a pagamento, lo integrano, io uso MDK ARM di Keil, se devi produrre applicazioni industriali te lo consiglio caldamente, costicchia però è il migliore in circolazione.
Per iniziare a lavorare/valutare gli STM32 senza spendere soldi ti consiglio di utilizzare il MikroC ARM di MilroElektronika, la versione free compila fino a 32k di eseguibile, anche se sembrano pochi in realtà ci fai molte cose, ti mette a disposizione una ricchissima libreria di funzioni pronte in stile Arduino, in pratica puoi anche non studiare il datasheet, cosa comunque da fare, del micro e riesci fin da subito a realizzare dei semplici applicativi esattamente come fai con Arduino.

ciao
la discussione mi interessa perche' devo realizzare anche io una camma (posizione del motore in funzione della posizione di un altro)
@astrobed
ho letto le tue risposte, sarei curioso di provare le schede che indichi, in particolare la ARIA ma non ho capito come si programma

...Per iniziare a lavorare/valutare gli STM32 senza spendere soldi ti consiglio di utilizzare il MikroC ARM di MilroElektronika, la versione free compila fino a 32k di eseguibile,...

parli di questo?

grazie
stefano

stefa24:
@astrobed
ho letto le tue risposte, sarei curioso di provare le schede che indichi, in particolare la ARIA ma non ho capito come si programma

La Aria G25 nasce come sistema Linux embedded, dato che è una MCU a tutti gli effetti dispone di molti GPIO sia di tipo puramente digitale che abbinati a varie funzionalità quali seriali, I2C, PWM etc, sono tutti accessibili da software in C, ma volendo pure con Python, perchè già mappati nel suo kernel.
In alternativa è possibile utilizzare Aria come una normale MCU, quindi senza caricare nessun OS, nel modo classico, ovvero accedendo direttamente ai registri macchina.

astrobeed:

stefa24:
@astrobed
ho letto le tue risposte, sarei curioso di provare le schede che indichi, in particolare la ARIA ma non ho capito come si programma

La Aria G25 nasce come sistema Linux embedded, dato che è una MCU a tutti gli effetti dispone di molti GPIO sia di tipo puramente digitale che abbinati a varie funzionalità quali seriali, I2C, PWM etc, sono tutti accessibili da software in C, ma volendo pure con Python, perchè già mappati nel suo kernel.
In alternativa è possibile utilizzare Aria come una normale MCU, quindi senza caricare nessun OS, nel modo classico, ovvero accedendo direttamente ai registri macchina.

supporta per caso open cv?

Madwriter:
supporta per caso open cv?

Si e ci stiamo lavorando sopra in diverse persone per una applicazione dedicata alla robotica, scopo identificare oggetti solidi regolari monocromatici su sfondo generico.

astrobeed:

Madwriter:
supporta per caso open cv?

Si e ci stiamo lavorando sopra in diverse persone per una applicazione dedicata alla robotica, scopo identificare oggetti solidi regolari monocromatici su sfondo generico.

interessante,come si comporta?che prestazioni ha?state trovando difficolta nell'elaborazioni real-time?

Per capirci meglio l'obbiettivo finale è ottenere lo stesso risultato del video allegato, ovviamente senza la parte di visualizzazione video, ci bastano le coordinate del COG e le dimensioni in pixel del rettangolo in cui l'oggetto risulta incluso, da questi parametri è possibile ricavare posizione e distanza dell'oggetto partendo dalle sue dimensioni reali che sono note.
L'applicazione nel video è stata realizzata utilizzando l'engine di RoboRealm, che a sua volta è realizzato con le OpenCv, gira su un netbook con Atom @1.6 Ghz a 18 fps con risoluzione della cam (Lifecam VX6000) 640x480.

Madwriter:
interessante,come si comporta?che prestazioni ha?state trovando difficolta nell'elaborazioni real-time?

Come ti ho detto l'obbiettivo è elaborare almeno 5 frame al secondo, attualmente sono arrivato quasi 3fps, però c'è ancora molto lavoro di semplificazione e messa a punto da fare, sono sicuro di riuscire ad ottenere qualcosa di più di 5 fps.

Ehm, la conversazione mi sta scappando di mano... :stuck_out_tongue_closed_eyes: :stuck_out_tongue_closed_eyes: :stuck_out_tongue_closed_eyes: :stuck_out_tongue_closed_eyes:

E' normale, siamo Italiani e ci piace divagare :slight_smile:

astrobeed:

Madwriter:
interessante,come si comporta?che prestazioni ha?state trovando difficolta nell'elaborazioni real-time?

Grazie delle risposte se ti va tieni aggiornato nel topic presente in bar sport credo che prenderò una aria e una lifecam e inizierò a fare un pò di prove :slight_smile: