raspibo - Contributi utente [it]

OV7670

2025-02-08T10:11:21Z

Oloturia: /* Come funziona OV7670 e come non aver paura di YCbCr */

Diversi anni fa comprai questa OV7670 con l'illusione che sarebbe stato divertente farla funzionare con un Arduino. Il mio obiettivo era una cosa molto semplice, come un sensore che scatta foto quando triggerato e che salvasse l'immagine su una SD. Purtroppo non si è rivelato possibile per diverse limitazioni delle schede Arduino più economiche: una scheda come l'Uno non ha abbastanza RAM per memorizzare un'immagine intera alle risoluzioni più alte, ma anche la più dotata Due ha bisogno di una gabola per riuscire ad avere i colori.

[[File:OV7670.JPG]]

Per ovviare a questo occorre una memoria FIFO, normalmente integrata nella scheda assieme a OV7670, ma la mia non l'aveva e acquistarla a parte ha solo comportato avere due problemi (come far funzionare la cam E come far funzionare la FIFO) al posto di uno.

Fra tutte le schede ho scelto l'Arduino Due perché ha abbastanza memoria per tenere un'intera immagine in QVGA (320x240) in bianco e nero e perché ha livelli logici a 3,3V, il che permette di collegarlo a OV7670 senza bisogno di un partitore di tensione.

= Le Guide =

== Instructables ==

Il primo passo per far funzionare una qualsiasi cosa è cercare guide e datasheet. La prima guida in cui ci si imbatte è questa:
https://www.instructables.com/How-to-Connect-OV7670-to-Arduino-Due/

Questo Instructable è stato il mio punto di partenza. Inizia con un semplice schema per il wiring:

DUE OV7670
3.3V VDD
GND GND
SCL(21) SDIOC
SDA(20) SDIOD
52 VSYNC
32 PCLK
7 XCLK
44 D7
45 D6
46 D5
47 D4
48 D3
49 D2
50 D1
51 D0
33 RESET
GND PWDN

A questo schema -senza nessun commento- manca il collegamento di HREF. Non verrà utilizzato e non è necessario collegarlo, ma nella guida non è specificato.
Nel resto della guida si spiega come il Due debba generare un clock e come scrivere nei registri di OV7670 tramite I²C. Viene fornito anche uno sketch che sembrerebbe funzionare e che in teoria leggerebbe l'immagine in bianco e nero per poi mandare l'output su seriale. Putroppo i programmi per decodificare questo segnale sono su un sito irraggiungibile. Ero quindi a un punto morto.

Ok ok non del tutto, nei commenti (ahimè l'ho scoperto quando ormai avevo già riscritto parte del codice) c'è una soluzione fatta in Processing che funziona bene:
https://pastebin.com/weAEcrQG

== Come funziona OV7670 e come non aver paura di YCbCr ==

http://embeddedprogrammer.blogspot.com/2012/07/hacking-ov7670-camera-module-sccb-cheat.html

Trovandomi un po' spiazzato, ho pensato che forse avrei dovuto approfittarne per riscrivere da capo tutto quanto, così da far funzionare finalmente la cam e allo stesso tempo imparare qualcosa di nuovo. Lo sketch dell'instructable precedente era per me un po' ostico da leggere, con molti riferimenti a me sconosciuti ai registri interni dell'Arduino Due e della cam. Punto di partenza è stato questo sito che spiega diverse cose sul funzionamento di OV7670.

Qui scopriamo che:
VSYNC è il segnale di sincronia verticale (HREF quello orizzontale, ma non lo useremo)
PCLK è il clock del pixel (in realtà -mezzo- pixel)
XCLK è il clock esterno, OV7670 ha bisogno di un clock esterno per funzionare: se volete scansionare gli indirizzi I²C per scoprire quello della cam, dovrete prima collegare un clock a XCLK

Un pixel su un monitor è composto da due informazioni: la posizione e il colore. La posizione è espressa in coordinate X e Y mentre il colore dalla luminosità dei colori primari R=Red/Rosso, G=Green/Verde e B=Blue/Blu. Normalmente ogni colore è espresso con 8 bit, da cui il nome RGB888. Purtroppo OV7670 invece comunica i pixel sequenzialmente a partire da 0,0 a 320,240 riga per riga e come formati di colore ha RGB565, RGB555 e RGB444 oppure YCbCr422. Il primo semplicemente manda 5 bit di R, 6 di G e 5 di B oppure rispettivamente 5 e 4 per ogni colore. L'ultimo formato invece è completamente diverso e necessita di un approfondimento.

Nel format YCbCr l'immagine è separata in tre canali: la luma (Y) ossia la luminosità (se prendessimo solo Y come valore per RGB allora vedremmo l'immagine in bianco e nero) e la croma, ovvero i livelli di differenza da Y dal blu (Cb) e dal rosso (Cr). Ognuno di questi occupa un byte di informazione.

Ogni falling del PCLK la cam invia un byte di informazione in modo parallelo sui pin da D0 a D7. Come fa quindi a comunicare un pixel ogni colpo PCLK? Semplice: non lo fa. Manda i valori alternati in questo modo:
Cb0,Y0,Cr0,Y1,Cb2,Y2,Cr2,Y3...
La definizione di "Pixel Clock" è infatti fuorviante. Sarebbe "Half Pixel Clock" semmai.

Se bastasse l'immagine in bianco e nero allora basterà memorizzare un PCLK no e uno sì e avremo la luma. Questo è quello che faceva in teoria lo sketch del primo instructable. Ovviamente a me non bastava (a parte il fatto che comunque non funzionava), volevo anche i colori. Cb e Cr sono comuni per due pixel alla volta. Sempre secondo il link alla guida sopra:
pixel 0 = Y0 Cb0 Cr0
pixel 1 = Y1 Cb0 Cr0
pixel 2 = Y2 Cb2 Cr2
pixel 3 = Y3 Cb2 Cr2

Questo semplificava molto le cose. Invece di mandare la luma via seriale e scartare la croma, avrei mandato alternativamente prima la luma del frame e successivamente la croma. Avrebbe causato degli strani effetti nelle immagini in movimento ma sarebbe stato meglio di prima.
Perché non mandare contemporaneamente l'informazione? L'Arduino Due ha solo 96KB di SRAM, la luma o le crome da sole sono 320*240*1 byte = 76.8KB l'una. Mandare i dati via seriale alla fine della riga poteva essere una soluzione ma causava numerosi glitch sull'immagine risultante.

La guida è chiara, ma purtroppo manca uno sketch per il Due e relativo programma per processare l'immagine da seriale.

== Il datasheet ==

http://web.mit.edu/6.111/www/f2015/tools/OV7670app.pdf

In questo datasheet sono elencati i registri interni di OV7670. Nello sketch dell'Instructable sono impostati nella maggior parte dei casi senza spiegare cosa servono. Gli stessi valori li ho trovati anche in quest'altra guida: http://embeddedprogrammer.blogspot.com/2012/07/hacking-ov7670-camera-module-sccb-cheat.html e dal relativo codice su github: https://github.com/indrekluuk/LiveOV7670 per il collegamento della cam a un display.
Da quel che mi è parso di capire, sono i valori che il driver di Linux mette di default e usa per le varie impostazioni della cam (ad es. per passare da QVGA ad altri formati come il QCIF). Molto interessante ma a questo punto la mia missione era già diventata qualcos'altro, ovvero fare in modo che questi registri potessero essere modificati in modo interattivo.

= La soluzione =

L'obiettivo è quindi creare un programma che leggesse la seriale e restituisse l'immagine e allo stesso tempo fare in modo che si potessero leggere e scrivere i registri della cam.

== Lato Arduino Due ==

Lo sketch dell'Instructable fa le seguenti cose:
* Imposta i registri di OV7670 in modo che sia QVGA in formato YCbCr422
* Manda un segnale "*RDY*" e memorizza su una matrice un byte no e uno sì dei pin D0-D7
* Quando l'immagine è completa, manda via seriale ogni singolo byte della matrice

La modifica più importante è stata quella di mandare alternati il valore di Y e quello di CbCr. Nel frattempo avrebbe anche aspettato dallo script lato computer un segnale per dare il via alla lettura oppure un comando per leggere o scrivere su uno dei registri. Successivamente ho anche eliminato tutte le configurazioni che non cambiavano significativamente l'immagine e che probabilmente hanno a che fare con cose come il bilanciamento del bianco.

Vediamo alcuni dettagli dello sketch.

=== Generare un segnale di clock con Arduino ===

Arduino Due ha un generatore di PWM con i quali è possibile creare un segnale di clock di almeno 8MHz sufficienti per il XCLK di OV7670.

int32_t PWM_pin = digitalPinToBitMask(XCLK);
REG_PMC_PCER1 = 1 << 4; // Enable peripheral ID 36 (PWM) in the peripheral clock enable register - see 28.15.23
REG_PIOC_PDR |= PWM_pin; // Allow peripheral control for PWM_pin
REG_PIOC_ABSR |= PWM_pin; // Select peripheral B
REG_PWM_CPRD6 = 8; // Period: 84 MHz / 8 = 10.5 MHz - see 38.6.2.2 of datasheet
REG_PWM_CDTY6 = 4; // Duty Cycle: 8 / 4 = 0.5
REG_PWM_ENA = 1 << 6; // Enable PWML6 (pin 7) - see 38.5.1 and 38.7.5 of datasheet for more info

Gran parte delle informazioni su come funziona questo codice è spiegato su questa guida:
https://nhoffmanresearch.com/index.php/12-arduino-trap-control
e relativo datasheet del SAM3X9E:
http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-11057-32-bit-Cortex-M3-Microcontroller-SAM3X-SAM3A_Datasheet.pdf

=== I registri ===

Tramite I²C è possibile leggere lo stato di un registro o scrivere un nuovo valore. La lista dei registri è elencata sul datasheet, tuttavia alcuni, descritti come "Reserved", non sono documentati. La prima cosa quando si accende la cam è settare i registri in modo che trasmetta le informazioni nel formato QVGA e YCbCr, inoltre sono abilitate alcune funzioni come l'autobilanciamento del bianco. Una volta impostate queste cose, si può cominciare a catturare le immagini.

=== Loop ===

Una delle cose che non riuscivo a far funzionare era centrare l'immagine. Essendo scollegato HREF il punto di inizio era arbitrario, e questo comportava che l'immagine fosse fuori quadro. Ho cambiato un po' questa filosofia e ho fatto in modo che l'Arduino Due aspettasse un segnale sulla seriale prima di iniziare a trasmettere. Il segnale è composto da due byte, se sono entrambi 0xD0 allora invia una nuova immagine, se invece il primo è un altro valore, viene inviato il registro corrispondente a quel valore, se sono entrambi diversi il registro corrispondente al primo valore viene aggiornato con il secondo valore. Non esiste un registro 0xD0, quindi possiamo usare tale byte per segnalare quando siamo pronti a ricevere una nuova immagine.

In questo modo è possibile alterare in diretta l'immagine, cambiare luminosità, formato e anche scoprire a cosa servono i registri "Reserved".

=== Cattura dell'immagine ===

La cattura è fatta in due passate per questioni di spazio sulla RAM. Per prima cosa leggiamo Y e poi CbCr. Se non siamo interessati al colore, possiamo commentare la seconda chiamata alla funzione captureImg a cui ho aggiunto un terzo parametro, il bool chroma, per specificare se salvare i bit pari o quelli dispari.
Ogni PCLK basso viene aggiunto un valore (Y oppure CbCr) alla matrice che rappresenta le righe e le colonne. Durante la lettura il tempo è critico, per cui occorrono alcuni accorgimenti per sveltire le operazioni.

noInterrupts();

Questo comando disabilita gli interrupt. Non mi sembra che abbia nessun effetto benefico, ma male non fa.

REG_PIOB_PDSR & (1 << 21)
REG_PIOD_PDSR & (1 << 10)

Purtroppo le tanto comode funzioni digitalRead() di Arduino sono troppo lente per l'output di OV7670. Leggere direttamente il Pin Data Status Register (PDSR) di SAM3X9E è molto più veloce. Il bit 21 del PortB corrisponde al pin 52, che è quello dove abbiamo attaccato VSYNC, il bit 10 del PortD è il pin 32, dove abbiamo attaccato PCLK. Non è immediato convertire il pin in registro, ma ci sono moltissimi schemi con il pinout del Due, con descritto per ogni pin il Port e il bit.

(REG_PIOC_PDSR & 0xFF000) >> 12

Invece il PortC sono tutti i pin dov0 abbiamo collegato da D0 a D7. Memorizzando lo stato del Port e applicando un filtro in modo che restituisca solo i valori che ci interessano (PortC dalla 12 alla 19), non dobbiamo subire la costrizione di leggere lo stato di un pin alla volta.

Allo stesso tempo non è possibile usare la seriale di programmazione per trasmettere la matrice, occorre usare la porta nativa (Native) e invece di Serial, la funzione SerialUSB.write. Non c'è bisogno di inizializzarla con un baud rate perché andrà sempre alla velocità massima possibile. Questo dualismo mi ha permesso anche di fare alcune cose interessanti, come usare la porta nativa per la comunicazione con il programma che elabora le immagini e la porta di programmazione per mandare dei messaggi di debug.

== Lato Python ==

Sul computer ho scritto un piccolo script che pettinasse l'output dell'Arduino.

Per prima cosa manda un segnale di due byte. Se il segnale è 0xD0 0xD0 allora si mette in attesa di larghezza*altezza byte. Una volta ricevuti e messi in ordine (ricordate, un dato di croma vale per due pixel, mentre la luma c'è per ognuno) occorre usare alcune formule per trasformare i dati in RGB. Ho usato questa formula, che si può trovare nelle guide già citate sopra:
R = int(max(0, min(255,Y + 1.40200 * (Cr - 0x80))))
G = int(max(0, min(255,Y - 0.34414 * (Cb - 0x80) - 0.71414 * (Cr - 0x80))))
B = int(max(0, min(255,Y + 1.77200 * (Cb - 0x80))))

Lo script readYUV422.py restituisce quindi una bitmap. Gli altri script saveYUV422.py e showYUV422.py rispettivamente salvano l'immagine con PIL oppure la mostrano con pygame. L'altro script, tkinterface.py, invece è un'interfaccia fatta con tkinter con cui possiamo interagire direttamente con i registri di OV7670. Per risolvere il problema delle azioni concorrenti, ho usato un thread che facesse il refresh dell'immagine. La porta usata è /dev/ttyACM0, ma è possibile cambiarla aggiungendo un argomento quando si lancia lo script.

[[File:OVCAM.JPG]]

= I risultati =

Non è andato sempre tutto bene al primo colpo. Soprattutto all'inizio, quando non avevo ancora capito come leggere l'output, la cam ha dato degli output interessanti. Eccone alcuni.
[[File:Glitches.jpg]]

= Il repo =

Tutta la roba, con tutte le istruzioni e quant'altro, lo trovate nel repository su:
https://github.com/oloturia/ovcam

OV7670

2025-02-08T10:10:48Z

Oloturia: /* Come funziona OV7670 e come non aver paura di YCbCr */

Diversi anni fa comprai questa OV7670 con l'illusione che sarebbe stato divertente farla funzionare con un Arduino. Il mio obiettivo era una cosa molto semplice, come un sensore che scatta foto quando triggerato e che salvasse l'immagine su una SD. Purtroppo non si è rivelato possibile per diverse limitazioni delle schede Arduino più economiche: una scheda come l'Uno non ha abbastanza RAM per memorizzare un'immagine intera alle risoluzioni più alte, ma anche la più dotata Due ha bisogno di una gabola per riuscire ad avere i colori.

[[File:OV7670.JPG]]

Per ovviare a questo occorre una memoria FIFO, normalmente integrata nella scheda assieme a OV7670, ma la mia non l'aveva e acquistarla a parte ha solo comportato avere due problemi (come far funzionare la cam E come far funzionare la FIFO) al posto di uno.

Fra tutte le schede ho scelto l'Arduino Due perché ha abbastanza memoria per tenere un'intera immagine in QVGA (320x240) in bianco e nero e perché ha livelli logici a 3,3V, il che permette di collegarlo a OV7670 senza bisogno di un partitore di tensione.

= Le Guide =

== Instructables ==

Il primo passo per far funzionare una qualsiasi cosa è cercare guide e datasheet. La prima guida in cui ci si imbatte è questa:
https://www.instructables.com/How-to-Connect-OV7670-to-Arduino-Due/

Questo Instructable è stato il mio punto di partenza. Inizia con un semplice schema per il wiring:

DUE OV7670
3.3V VDD
GND GND
SCL(21) SDIOC
SDA(20) SDIOD
52 VSYNC
32 PCLK
7 XCLK
44 D7
45 D6
46 D5
47 D4
48 D3
49 D2
50 D1
51 D0
33 RESET
GND PWDN

A questo schema -senza nessun commento- manca il collegamento di HREF. Non verrà utilizzato e non è necessario collegarlo, ma nella guida non è specificato.
Nel resto della guida si spiega come il Due debba generare un clock e come scrivere nei registri di OV7670 tramite I²C. Viene fornito anche uno sketch che sembrerebbe funzionare e che in teoria leggerebbe l'immagine in bianco e nero per poi mandare l'output su seriale. Putroppo i programmi per decodificare questo segnale sono su un sito irraggiungibile. Ero quindi a un punto morto.

Ok ok non del tutto, nei commenti (ahimè l'ho scoperto quando ormai avevo già riscritto parte del codice) c'è una soluzione fatta in Processing che funziona bene:
https://pastebin.com/weAEcrQG

== Come funziona OV7670 e come non aver paura di YCbCr ==

http://embeddedprogrammer.blogspot.com/2012/07/hacking-ov7670-camera-module-sccb-cheat.html

Trovandomi un po' spiazzato, ho pensato che forse avrei dovuto approfittarne per riscrivere da capo tutto quanto, così da far funzionare finalmente la cam e allo stesso tempo imparare qualcosa di nuovo. Lo sketch dell'instructable precedente era per me un po' ostico da leggere, con molti riferimenti a me sconosciuti ai registri interni dell'Arduino Due e della cam. Punto di partenza è stato questo sito che spiega diverse cose sul funzionamento di OV7670.

Qui scopriamo che:
VSYNC è il segnale di sincronia verticale (HREF quello orizzontale, ma non lo useremo)
PCLK è il clock del pixel (in realtà -mezzo- pixel)
XCLK è il clock esterno, OV7670 ha bisogno di un clock esterno per funzionare: se volete scansionare gli indirizzi I²C per scoprire quello della cam, dovrete prima collegare un clock a XCLK

Un pixel su un monitor è composto da due informazioni: la posizione e il colore. La posizione è espressa in coordinate X e Y mentre il colore dalla luminosità dei colori primari R=Red/Rosso, G=Green/Verde e B=Blue/Blu. Normalmente ogni colore è espresso con 8 bit, da cui il nome RGB888. Purtroppo OV7670 invece comunica i pixel sequenzialmente a partire da 0,0 a 320,240 riga per riga e come formati di colore ha RGB565, RGB555 e RGB444 oppure YCbCr422. Il primo semplicemente manda 5 bit di R, 6 di G e 5 di B oppure rispettivamente 5 e 4 per ogni colore. L'ultimo formato invece è completamente diverso e necessita di un approfondimento.

Nel format YCbCr l'immagine è separata in tre canali: la luma (Y) ossia la luminosità (se prendessimo solo Y come valore per RGB allora vedremmo l'immagine in bianco e nero) e la croma, ovvero i livelli di differenza da Y del blu (Cb) e del rosso (Cr). Ognuno di questi occupa un byte di informazione.

Ogni falling del PCLK la cam invia un byte di informazione in modo parallelo sui pin da D0 a D7. Come fa quindi a comunicare un pixel ogni colpo PCLK? Semplice: non lo fa. Manda i valori alternati in questo modo:
Cb0,Y0,Cr0,Y1,Cb2,Y2,Cr2,Y3...
La definizione di "Pixel Clock" è infatti fuorviante. Sarebbe "Half Pixel Clock" semmai.

Se bastasse l'immagine in bianco e nero allora basterà memorizzare un PCLK no e uno sì e avremo la luma. Questo è quello che faceva in teoria lo sketch del primo instructable. Ovviamente a me non bastava (a parte il fatto che comunque non funzionava), volevo anche i colori. Cb e Cr sono comuni per due pixel alla volta. Sempre secondo il link alla guida sopra:
pixel 0 = Y0 Cb0 Cr0
pixel 1 = Y1 Cb0 Cr0
pixel 2 = Y2 Cb2 Cr2
pixel 3 = Y3 Cb2 Cr2

Questo semplificava molto le cose. Invece di mandare la luma via seriale e scartare la croma, avrei mandato alternativamente prima la luma del frame e successivamente la croma. Avrebbe causato degli strani effetti nelle immagini in movimento ma sarebbe stato meglio di prima.
Perché non mandare contemporaneamente l'informazione? L'Arduino Due ha solo 96KB di SRAM, la luma o le crome da sole sono 320*240*1 byte = 76.8KB l'una. Mandare i dati via seriale alla fine della riga poteva essere una soluzione ma causava numerosi glitch sull'immagine risultante.

La guida è chiara, ma purtroppo manca uno sketch per il Due e relativo programma per processare l'immagine da seriale.

== Il datasheet ==

http://web.mit.edu/6.111/www/f2015/tools/OV7670app.pdf

In questo datasheet sono elencati i registri interni di OV7670. Nello sketch dell'Instructable sono impostati nella maggior parte dei casi senza spiegare cosa servono. Gli stessi valori li ho trovati anche in quest'altra guida: http://embeddedprogrammer.blogspot.com/2012/07/hacking-ov7670-camera-module-sccb-cheat.html e dal relativo codice su github: https://github.com/indrekluuk/LiveOV7670 per il collegamento della cam a un display.
Da quel che mi è parso di capire, sono i valori che il driver di Linux mette di default e usa per le varie impostazioni della cam (ad es. per passare da QVGA ad altri formati come il QCIF). Molto interessante ma a questo punto la mia missione era già diventata qualcos'altro, ovvero fare in modo che questi registri potessero essere modificati in modo interattivo.

= La soluzione =

L'obiettivo è quindi creare un programma che leggesse la seriale e restituisse l'immagine e allo stesso tempo fare in modo che si potessero leggere e scrivere i registri della cam.

== Lato Arduino Due ==

Lo sketch dell'Instructable fa le seguenti cose:
* Imposta i registri di OV7670 in modo che sia QVGA in formato YCbCr422
* Manda un segnale "*RDY*" e memorizza su una matrice un byte no e uno sì dei pin D0-D7
* Quando l'immagine è completa, manda via seriale ogni singolo byte della matrice

La modifica più importante è stata quella di mandare alternati il valore di Y e quello di CbCr. Nel frattempo avrebbe anche aspettato dallo script lato computer un segnale per dare il via alla lettura oppure un comando per leggere o scrivere su uno dei registri. Successivamente ho anche eliminato tutte le configurazioni che non cambiavano significativamente l'immagine e che probabilmente hanno a che fare con cose come il bilanciamento del bianco.

Vediamo alcuni dettagli dello sketch.

=== Generare un segnale di clock con Arduino ===

Arduino Due ha un generatore di PWM con i quali è possibile creare un segnale di clock di almeno 8MHz sufficienti per il XCLK di OV7670.

int32_t PWM_pin = digitalPinToBitMask(XCLK);
REG_PMC_PCER1 = 1 << 4; // Enable peripheral ID 36 (PWM) in the peripheral clock enable register - see 28.15.23
REG_PIOC_PDR |= PWM_pin; // Allow peripheral control for PWM_pin
REG_PIOC_ABSR |= PWM_pin; // Select peripheral B
REG_PWM_CPRD6 = 8; // Period: 84 MHz / 8 = 10.5 MHz - see 38.6.2.2 of datasheet
REG_PWM_CDTY6 = 4; // Duty Cycle: 8 / 4 = 0.5
REG_PWM_ENA = 1 << 6; // Enable PWML6 (pin 7) - see 38.5.1 and 38.7.5 of datasheet for more info

Gran parte delle informazioni su come funziona questo codice è spiegato su questa guida:
https://nhoffmanresearch.com/index.php/12-arduino-trap-control
e relativo datasheet del SAM3X9E:
http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-11057-32-bit-Cortex-M3-Microcontroller-SAM3X-SAM3A_Datasheet.pdf

=== I registri ===

Tramite I²C è possibile leggere lo stato di un registro o scrivere un nuovo valore. La lista dei registri è elencata sul datasheet, tuttavia alcuni, descritti come "Reserved", non sono documentati. La prima cosa quando si accende la cam è settare i registri in modo che trasmetta le informazioni nel formato QVGA e YCbCr, inoltre sono abilitate alcune funzioni come l'autobilanciamento del bianco. Una volta impostate queste cose, si può cominciare a catturare le immagini.

=== Loop ===

Una delle cose che non riuscivo a far funzionare era centrare l'immagine. Essendo scollegato HREF il punto di inizio era arbitrario, e questo comportava che l'immagine fosse fuori quadro. Ho cambiato un po' questa filosofia e ho fatto in modo che l'Arduino Due aspettasse un segnale sulla seriale prima di iniziare a trasmettere. Il segnale è composto da due byte, se sono entrambi 0xD0 allora invia una nuova immagine, se invece il primo è un altro valore, viene inviato il registro corrispondente a quel valore, se sono entrambi diversi il registro corrispondente al primo valore viene aggiornato con il secondo valore. Non esiste un registro 0xD0, quindi possiamo usare tale byte per segnalare quando siamo pronti a ricevere una nuova immagine.

In questo modo è possibile alterare in diretta l'immagine, cambiare luminosità, formato e anche scoprire a cosa servono i registri "Reserved".

=== Cattura dell'immagine ===

La cattura è fatta in due passate per questioni di spazio sulla RAM. Per prima cosa leggiamo Y e poi CbCr. Se non siamo interessati al colore, possiamo commentare la seconda chiamata alla funzione captureImg a cui ho aggiunto un terzo parametro, il bool chroma, per specificare se salvare i bit pari o quelli dispari.
Ogni PCLK basso viene aggiunto un valore (Y oppure CbCr) alla matrice che rappresenta le righe e le colonne. Durante la lettura il tempo è critico, per cui occorrono alcuni accorgimenti per sveltire le operazioni.

noInterrupts();

Questo comando disabilita gli interrupt. Non mi sembra che abbia nessun effetto benefico, ma male non fa.

REG_PIOB_PDSR & (1 << 21)
REG_PIOD_PDSR & (1 << 10)

Purtroppo le tanto comode funzioni digitalRead() di Arduino sono troppo lente per l'output di OV7670. Leggere direttamente il Pin Data Status Register (PDSR) di SAM3X9E è molto più veloce. Il bit 21 del PortB corrisponde al pin 52, che è quello dove abbiamo attaccato VSYNC, il bit 10 del PortD è il pin 32, dove abbiamo attaccato PCLK. Non è immediato convertire il pin in registro, ma ci sono moltissimi schemi con il pinout del Due, con descritto per ogni pin il Port e il bit.

(REG_PIOC_PDSR & 0xFF000) >> 12

Invece il PortC sono tutti i pin dov0 abbiamo collegato da D0 a D7. Memorizzando lo stato del Port e applicando un filtro in modo che restituisca solo i valori che ci interessano (PortC dalla 12 alla 19), non dobbiamo subire la costrizione di leggere lo stato di un pin alla volta.

Allo stesso tempo non è possibile usare la seriale di programmazione per trasmettere la matrice, occorre usare la porta nativa (Native) e invece di Serial, la funzione SerialUSB.write. Non c'è bisogno di inizializzarla con un baud rate perché andrà sempre alla velocità massima possibile. Questo dualismo mi ha permesso anche di fare alcune cose interessanti, come usare la porta nativa per la comunicazione con il programma che elabora le immagini e la porta di programmazione per mandare dei messaggi di debug.

== Lato Python ==

Sul computer ho scritto un piccolo script che pettinasse l'output dell'Arduino.

Per prima cosa manda un segnale di due byte. Se il segnale è 0xD0 0xD0 allora si mette in attesa di larghezza*altezza byte. Una volta ricevuti e messi in ordine (ricordate, un dato di croma vale per due pixel, mentre la luma c'è per ognuno) occorre usare alcune formule per trasformare i dati in RGB. Ho usato questa formula, che si può trovare nelle guide già citate sopra:
R = int(max(0, min(255,Y + 1.40200 * (Cr - 0x80))))
G = int(max(0, min(255,Y - 0.34414 * (Cb - 0x80) - 0.71414 * (Cr - 0x80))))
B = int(max(0, min(255,Y + 1.77200 * (Cb - 0x80))))

Lo script readYUV422.py restituisce quindi una bitmap. Gli altri script saveYUV422.py e showYUV422.py rispettivamente salvano l'immagine con PIL oppure la mostrano con pygame. L'altro script, tkinterface.py, invece è un'interfaccia fatta con tkinter con cui possiamo interagire direttamente con i registri di OV7670. Per risolvere il problema delle azioni concorrenti, ho usato un thread che facesse il refresh dell'immagine. La porta usata è /dev/ttyACM0, ma è possibile cambiarla aggiungendo un argomento quando si lancia lo script.

[[File:OVCAM.JPG]]

= I risultati =

Non è andato sempre tutto bene al primo colpo. Soprattutto all'inizio, quando non avevo ancora capito come leggere l'output, la cam ha dato degli output interessanti. Eccone alcuni.
[[File:Glitches.jpg]]

= Il repo =

Tutta la roba, con tutte le istruzioni e quant'altro, lo trovate nel repository su:
https://github.com/oloturia/ovcam

Pagina principale

2021-07-16T15:59:49Z

Oloturia: /* Makerspace */

__NOTOC__

{| id="table-top-top" style="margin-top:2px; background:none;align:center;width:100%;border:1px solid red;-moz-border-radius: 10px; -webkit-border-radius: 10px; border-radius:10px;"
| style="background:white; width:75%; vertical-align:top; color:#000; padding: 5px 10px 10px 8px; " |
[[File:Emblem-important-2.png|left|48px|link=Prossimi appuntamenti]]

=[[Prossimi appuntamenti|Prossimi appuntamenti]]=

{{:Prossimi appuntamenti}}

-----------
'' Iscriviti alle nostre [http://liste.raspibo.org/wws/ mailing list]! ''

-----------

Gli appuntamenti fissi si tengono ogni '''secondo e quarto martedì del mese''' dalle ore 20.30 in avanti. La sala resta a disposizione anche i restanti martedì e tutti i giovedì: se volete usare i nostri spazi per i vostri incontri e progetti, scrivetelo sulla lista pubblica [http://liste.raspibo.org/wws/info/agora agora] e segnalate la vostra presenza sul nostro [http://lela.ismito.it:3000 sistema di prenotazioni].

[[Eventi passati]]

| style="background:white; width:75%; vertical-align:top; color:#000; padding: 5px 10px 10px 8px; " |
[[File:Go-home-9.png|right|48px|link=makerspace]]

= [[makerspace|Makerspace]] =
[http://centrocroce.blogspot.it/ Presso il centro sociale CROCE]
[[makerspace|Via Canonica 18 a Casalecchio di Reno]].<br/>

= Cookie =
Questo sito usa solamente Cookie Tecnici. <br/>
[[Cookie Tecnici|maggiori informazioni]]
|}


{| id="table-central" style="margin-top:10px; background:none;"
| style="background:white; width:35%; border:1px solid #a7d7f9; vertical-align:top; color:#000; padding: 5px 10px 10px 8px; -moz-border-radius: 10px; -webkit-border-radius: 10px; border-radius:10px;" |

{| id="table-central-left" cellpadding="2" cellspacing="5" style="width:100%; vertical-align:top; background:transparent;"
[[File:PCB-icon.png|right|48px]]

= [[gruppi|Gruppi]] e [[:Categoria:Progetti|Progetti]] =

{{:Gruppi}}

[[File:Maker-faire.png|right|128px|link=Maker_Faire_2014]]
[[File:Maker_of_merit.jpg|right|128px|link=FotoMakerFaireRome2014]]

'''Dettagli sui [[I_gruppi_di_lavoro_del_non-corso|gruppi di lavoro]].'''

'''Vetrina dei [[:Categoria:Progetti|progetti in corso]].'''

'''Leggi la [[Documentazione|documentazione prodotta]].'''

'''Iscrivetevi alle [http://liste.raspibo.org mailing list].'''

'''[[ wireless_comunity_network |NINUX Bologna - Wireless community network]].'''

'''[[ link_e_idee |Link&Idee]].'''

'''[[ Renzo's Bliki ]].'''

'''[[ Laboratory of Making ]].'''

Abbiamo raccolto alcuni progetti di autoproduzione riguardanti il '''[[ Covid19 ]].'''

[[File:Applications-science.png|right|48px]]

== Serate aperte a tutti ==

''Gli incontri presso il [[makerspace]] sono ad accesso libero e gratuito, vedi anche le [[RIVOLUZIONE ALL'INCONTRO DEL 7 MARZO|note su come di solito procediamo]]''<br />

Se pensate di partecipare, segnalate la vostra presenza sul sistema [https://ibt2.ismito.it/ RaspiBO makerspace booking], basta il vostro nickname. Per favore ricordate di aggiornarlo.

== Gite, fiere ed eventi ==

Maker, segnalate [[Gite|qui ]] tutti gli eventi che ritenete interessanti!

= Acquisti ossessivo-compulsivi =

Ogni tanto ci vengono voglie strane; per amortizzare le spese di spedizione, cerchiamo di [[Elenco degli acquisti|aggregare gli ordini]].

= Convenzioni acquisti =
La ditta Homotix e la ditta Katodo praticano, agli utenti RaspiBo, uno sconto. Per usufruirne segui le '''[[convenzioni acquisti | istruzioni]]'''.

= Il non-staff ed i contatti =

Non desideriamo strutturare troppo la '''non-associazione''', ma un gruppetto si sta prendendo in carico di seguirne la gestione; [[Non-staff|scoprite chi sono]] e soprattutto come potete aiutarli, dato che c'è [[Aiuto:Indice|bisogno del contributo]] di tutti!
|}


| style="border:3px solid transparent;" |


| style="width:65%; border:1px solid #a7d7f9; background:#f5faff; vertical-align:top; padding: 5px 10px 10px 8px; -moz-border-radius: 10px; -webkit-border-radius: 10px; border-radius:10px;" |
{| id="table-central-right" cellpadding="2" cellspacing="5" style="width:100%; vertical-align:top; background:#f5faff; background:transparent;"

[[File:RASPIBOfinale.png|left|130px|link=http://www.raspibo.org]]
[[File:Help-3.png|right|48px]]
= Chi siamo =

'''''RaspiBO''''' è un gruppo informale di appassionati di elettronica ed informatica libera della zona di '''Bologna''' (ma non solo).

Nato ad inizio 2013 per iniziativa del professor [http://www.cs.unibo.it/~renzo/ Renzo Davoli], [http://www.raccattaraee.net/ RaccattaRAEE], [http://erlug.linux.it/ ERLUG] e [http://www.bfsf.it/ BFSF], il gruppo si muove ora autonomamente, incontrandosi con frequenza almeno bimensile per serate dedicate allo sviluppo ed alla presentazione di nuove idee.<br />
Chiamiamo questi incontri '''''il non-corso''''', perché non vogliono essere delle semplici lezioni frontali, ma un momento di scambio di opinioni ed esperienze.

Le nostre competenze sono molto varie; '''informatica''', '''elettronica''', '''meccanica''', '''arti''' e mestieri vari: qualcuno è un esperto nel proprio campo, alcuni sono alle prime armi, ma tutti hanno tanta voglia di mettere a disposizione la propria esperienza.<br />
Potete definirci '''makers'''; quello che più conta per noi resta comunque '''l'imparare''' sempre qualcosa di nuovo ed il '''far circolare la conoscenza''' coinvolgendo quante più persone possibile.

Se preferisci abbiamo raccolto qualche informazione [http://www.raspibo.org/wiki/index.php/Chi_siamo in questa pagina].

[[File:Audio-card-3.png|right|48px]]

= Gli incontri del non-corso ed i gruppi di lavoro =

'''Gratuiti e aperti a tutti''', chiunque voglia passare a trovarci anche solo per fare due chiacchiere su elettronica, informatica e meccanica (tutto rigorosamente in ''salsa libera'') è il benvenuto!

Lo spirito dei nostri incontri è espresso nelle nostre [[Linee guida per gli incontri|linee guida]].<br />
Oltre a tanta improvvisazione, di norma alcuni di noi si organizzano in '''tavoli''' per proseguire su specifici progetti; appena possibile, il [[I gruppi di lavoro del non-corso|lavoro svolto dai singoli gruppi]] viene presentato e documentato a beneficio di tutti.

[[File:Apps-system-users-icon.png|right|48px]]

= Serate a tema =

Occasionalmente RaspiBO organizza serate per sviluppare un tema specifico, generalmente invitiamo uno o più ospiti per introdurre temi di interesse comune e condividere esperienze. [http://www.raspibo.org/wiki/index.php?title=Categoria:Serate_a_tema Serate a tema]

[[File:Books-1-icon.png|right|48px]]

= Dalla teoria alla pratica =

Se vuoi puoi iniziare con l'[[1-_Elettronica_di_Base|elettronica]] oppure scoprire come configurare [[Raspberry Pi]] per iniziare i primi test.

Se sei già pratico o se vuoi capire come utilizzare Raspberry Pi puoi visualizzare un elenco di [[6- Applicazioni di Raspberry PI|applicazioni]] che abbiamo già testato e documentato.

Tutte queste informazioni le trovi nella sezione [[Documentazione|Documentazione]] .

Sono inoltre disponibili [[Archivio dei Lucidi|lucidi e registrazioni]] di alcune lezioni frontali.

[[File:User-group-new-2.png|link=http://social.raspibo.org|right|48px]]

Con calma stiamo anche raccogliendo [[SanboxManuali|qui]] link a documentazione, pinout e tutto quanto serve avere sottomano quando si sperimenta.

= la mailing list =

Il nostro principale strumento di comunicazione è la '''[http://liste.raspibo.org/wws/subscribe/agora mailing list agora]''', i cui archivi sono [http://liste.raspibo.org/wws/arc/agora consultabili da qui].

Se invece preferite ricevere periodicamente nostre notizie via mail, potete [http://liste.raspibo.org/wws/subscribe/newsletter iscrivervi alla newsletter].

[[File:Strumenti.png|link=http://social.raspibo.org|right|48px]]

= Strumenti per la collaborazione =

Se vi piace chattare o volete una info al volo vi suggeriamo di utilizzare il canale #raspibo sul server freenode.net anche in [https://webchat.freenode.net/?channels=raspibo&uio=d4 webchat].

Alcuni software sviluppati per i nostri progetti li appoggiamo sul nostro [https://github.com/raspibo/ archivio github].

= Un pochino di storia =
[http://www.raspibo.org/wiki/index.php/Chi_siamo Un piccolo riassunto]

|}

|}



{| id="table-footer" style="margin-top:10px; background:none;"
| style="width:35%; border:1px solid #a7d7f9; background:#f5faff; vertical-align:top; padding: 5px 10px 10px 8px; -moz-border-radius: 10px; -webkit-border-radius: 10px; border-radius:10px;" |

{| id="table-footer-left" cellpadding="2" cellspacing="5" style="width:100%; vertical-align:top; background:#f5faff; background:transparent;"

[[File:Emblem-what.png|right|48px]]

= Help! =

Vuoi modificare una pagina di questo wiki ma non ci riesci? Assicurati di aver letto le [[Qui|istruzioni]] per sconfiggere il nostro potente sistema anti-bot. :-)

|}


| style="border:5px solid transparent;" |


| style="background:white; width:65%; border:1px solid #a7d7f9; vertical-align:top; color:#000; padding: 5px 10px 10px 8px; -moz-border-radius: 10px; -webkit-border-radius: 10px; border-radius:10px;" |
{| id="table-footer-right" cellpadding="2" cellspacing="5" style="width:100%; vertical-align:top; background:transparent;"

= Ringraziamenti =

[[File:Stemma Comune Casalecchio.png|70px|right]]

Si ringrazia il Centro Sociale Croce ed il [http://www.comune.casalecchio.bo.it Comune di Casalecchio di Reno] .

|}

|}

ESProbottino

2021-06-20T16:25:43Z

Oloturia:

ESProbottino è l'evoluzione di [[Ardubottino]]. L'idea è quella di sfruttare le capacità wi-fi dell'[https://www.espressif.com/en/products/socs/esp32 ESP32] per fare un piccolo server per il controllo remoto di un piccolo rover. L'ESP32 usato in questo caso è l'[https://docs.ai-thinker.com/en/esp32-cam Ai-Thinker ESP32-CAM] che ha a bordo una cam per lo streaming. La cam purtroppo impegna gran parte dei pin disponibili, per cui è stato necessario usare un altro integrato, in questo caso un ATmega8, per la gestione dei motori, dei sensori e degli encoder.[[File:ESP32BOTTINO.JPG]]

= Componenti =

La maggior parte dei componenti è la stessa dell'Ardubottino:
* Ai-Thinker ESP32-CAM [https://docs.ai-thinker.com/en/esp32-cam]
* AVR ATmega8 [https://www.microchip.com/wwwproducts/en/ATmega8]
* Board per ponte H L298
* Kit Tamiya per robotica, con chassis e motori
* Sensore a ultrasuoni SRF05
* Sensore di vicinanza IR
* RobotShop coppia di Encoder [https://www.robotshop.com/en/encoder-pair-tamiya-twin-motor-gearbox.html]
* Batterie e powerbank

= ESP32-CAM =

Per aggiungere le schede ESP32 alle board programmabili dalla IDE di Arduino occorre inserire questo indirizzo fra le Preferences, alla voce Additional Boards Manager URLs. Se avete già delle voci, separatele con una virgola.
https://dl.espressif.com/dl/package_esp32_index.json

Questo aggiungerà le board ESP32 al vostro menu Tools/Board e aggiungerà uno sketch di esempio.

L'ESP32-CAM, con il programma di esempio, fa tre cose:
* Si collega o crea una wi-fi
* Tira su un piccolo server web con una pagina con alcuni controlli per la cam
* Scrive sulla porta seriale dei messaggi di debug (l'indirizzo IP)

Per piegare ESP32-CAM alle nostre esigenze, occorrerà fare delle piccole modifiche.

== CameraWebServer - Sketch principale ==

Per prima cosa modifichiamo lo sketch principale. Negli esempi della board si trova con il nome di CameraWebServer.

Per prima cosa occorre selezionare la nostra board scegliendo la define giusta. Nel nostro caso occorre decommentare la riga:
#define CAMERA_MODEL_AI_THINKER
e commentare le altre.

Nelle due righe successive
const char* ssid = "nostra_rete";
const char* password = "password_rete";
bisogna specificare una rete alla quale il nostro ESP32 dovrà collegarsi.

Non occorre fare altro, ma già che c'ero ho cambiato alcune cose per migliorare alcuni aspetti.
* Tolto tutte le comunicazioni seriali non necessarie perché avrebbero potuto interferire con l'ATmega8
* Abbassato il baud da 115200 a 9600, mi sembra che i motori facessero un po' di disturbo sulla seriale e mi è sembrato che abbassare il rate risolvesse gli errori
* Prima dell'assegnamento dell'indirizzo IP ho messo come comando una richiesta al sensore a ultrasuoni (manda un 0 sulla seriale), in modo che lampeggi durante l'attesa

Per i test avevo aggiunto anche la stampa sulla porta seriale del MAC address e dell'indirizzo IP. Nella versione finale è disabilitata perché interferiva con i comandi di movimento del robot e inoltre, essendo la seriale attaccata all'ATmega8, non era comunque possibili leggere tali messaggi. Le funzioni da chiamare sono:

WiFi.macAddress()

e

WiFi.localIP()

Riguardo il setup della camera non occorre modificare niente. Dal codice si può notare come gran parte dei pin sia occupato dalla CAM. È possibile (credo) anche modificare i parametri di default, tuttavia funzionano perfettamente out-of-the-box.

== app_httpd.cpp - Server web ==

Questa parte del codice lancia un server web con l'interfaccia per cambiare i parametri della CAM e lanciare o arrestare lo streaming, nonché gestire la parte di riconoscimento facciale. Di particolare interesse sono le variabili "variable" e "value" che contengono il nome di una variabile e del suo valore passato tramite GET. I controlli della CAM mandano una richiesta GET che chiama una funzione che ha come parametro il valore. Ad es.
s->set_wb_mode(s,val)
altera il bilanciamento del bianco del valore "val" ("val" è "value" tradotta in integer).

Per aggiungere i controlli del robot avrei dovuto quindi creare dei bottoni che inviassero alla Seriale il valore val. Il tutto è stato abbastanza semplice, è bastato aggiungere queste due righe:
else if(!strcmp(variable, "controls")){
Serial.print(value); }
alla lista dei vari altri controlli. Se GET legge la variabile "controls", il suo valore "value" viene mandato dalla seriale all'ATmega8.

== camera_index.h - La pagina web ==

Alla pagina web occorre aggiungere i pulsanti per il controllo del nostro rover. Ogni pulsante chiamerà una funzione che passerà tramite GET la variabile "controls" e un carattere che corrisponde all'azione da fare.

Ora però c'è un problema: la pagina è in html ma 1) in esadecimale e 2) compressa in gz. Qui c'è stato bisogno di un aiuto da CyberChef!

https://gchq.github.io/CyberChef/

Questo software traduce da e in esadecimale, g/un/zippa e fa anche moltissime altre cose. Per ora però limitiamoci a chiedergli queste tre cose:

* Remove whitespace (toglie gli spazi fra le cifre hex, nonché gli a capo)
* From Hex, 0x with comma (traduce da hex a dec)
* Gunzip

Ora incolliamo nella finestra input tutto l'array "const uint8_t index_ov2640_html_gz[]". Come per magia comparirà la pagina html! Modifichiamola aggiungendo i comandi per il robot.
Aggiungo un nuovo <div> con i bottoni sotto il layer dove dovrebbe comparire lo streaming. Già che c'ero ho aggiunto uno stile al css.

<controls>
<\div class="grid-container" align="center">
<\div class="item1"> </\div>
<\div class="item2"><button id="Forward">↑</button></\div>
<\div class="item3"> </\div>
<\div class="item4"><button id="Left">←</button></\div>
<\div class="item5"><button id="NoMov">O</button></\div>
<\div class="item6"><button id="Right">→</button></\div>
<\div class="item7"> </\div>
<\div class="item8"><button id="Back">↓</button></\div>
... (eccetera)
</\div>
</controls>

Ora bisogna associare a ogni tasto una chiamata GET. Per far questo mi appoggio allo script che già viene usato per i controlli della CAM. Andiamo quindi a modificare la funzione document.addEventListener

Per prima cosa si prendono i vari elementi e si mettono nelle costanti:

const forward = document.getElementById('Forward')
const left = document.getElementById('Left')
const right = document.getElementById('Right')
const back = document.getElementById('Back')
const nomov = document.getElementById('NoMov')
...

Poi si associano i listener:

forward.onclick = () => { fetch(`${baseHost}/control?var=controls&val=F`) }
left.onclick = () => { fetch(`${baseHost}/control?var=controls&val=L`) }
right.onclick = () => { fetch(`${baseHost}/control?var=controls&val=R`) }
back.onclick = () => { fetch(`${baseHost}/control?var=controls&val=B`) }
nomov.onclick = () => { fetch(`${baseHost}/control?var=controls&val=N`) }

Al click la pagina control viene richiamata la pagina control che prende una variabile "controls" di valore "val". Questo valore viene letto dal server che lo manda via seriale all'ATmega8.

Una volta fatto questo occorre ri-usare CyberChef e fare l'esatto opposto per codificare la pagina com'era in origine, ovvero:

* gzip
* To Hex, 0x with comma

Per quanto riguarda gli a capo e gli spazi, possiamo ignorarlo perché possiamo scrivere tranquillamente tutto su una sola linea.

Invece è importante cambiare la lunghezza dell'array. Nel mio caso sono passato da 4926 a:

#define index_ov2640_html_gz_len 5022

Se non mettiamo la lunghezza giusta la pagina verrà troncata. CyberChef conta i caratteri dell'output in automatico, ovviamente compresso. Ri-traducete la vostra pagina come all'inizio però disabilitando il gunzip e dovrebbe dirvi quanti byte è lunga.

Lato ESP32-CAM abbiamo finito. Occorre adesso flashare.

== Flashare l'ESP32-CAM ==

Per flashare l'ESP32-CAM occorre un adattatore USB a TTL. Collegare il filo rosso a +5v, il nero a un GND, bianco a TX e verde a RX.

Per mettere l'ESP32-CAM in modalità programmazione occorre collegare il pin 0 a GND e resettare. Occorre farlo subito dopo aver lanciato l'uploading quando compare il messaggio "Connecting ......______......", se fallisce (e se state usando la IDE di Arduino) conviene copiare il comando che lancia esptool e abbassare il baud rate.

= ATmega8 =

All'ATmega8 è lasciata tutta la parte di controllo dei pin. Il suo lavoro è molto semplice: legge un comando in entrata sulla seriale ed esegue una delle operazioni. Oltre a questo, controlla anche lo stato dei sensori e degli encoder. L'ATmega8 è molto ridotto e molto economico ma è sufficiente per quel che dobbiamo fare.

== Seriale ==

ESP32-CAM e ATmega8 sono collegati tramite la porta seriale. La funzione Serial.available() è >0 quando ci sono dei caratteri in attesa di essere letti. Serial.read() li legge. Il carattere lo si mette solitamente in una variabile char.

if (Serial.available() > 0) {
command = Serial.read(); }

Una volta ricevuto il comando, verrà chiamata una funzione.

switch(command) {
case 'F':
forward(4);
case 'R':
right(4);
(etc.)
}

Le funzioni forward(), backward(), right() e left() (rispettivamente comandi 'F', 'B', 'R' e 'L') prendono come parametro un intero. Quel parametro sarà la distanza da coprire in passi dell'encoder. Alcuni comandi non vengono eseguiti ad es. se il sensore di caduta segnala che c'è rischio di caduta. Le funzioni accendono i pin collegati al ponte ad H in modo che i motori girino nella direzione desiderata e li tengono accesi fino a che non è finita l'esecuzione della funzione steps, che calcola i passi.

Il comando 'M' abiliterà l'automazione del movimento. Esprobottino andrà in giro da solo evitando gli ostacoli (per quanto possibile) facendo affidamento sul sensore di distanza.

Ci sono anche quattro comandi ('1','2','3' e '4') per calibrare i due motori e uno per scrivere ('W') la calibrazione nella EEPROM. Questi comandi variano il duty cycle del PWM collegato agli Enable dei motori.

Altri comandi che possono essere interpretati: 'D' abilita il debug via seriale, '0' interroga i sensori e 'C' dovrebbe far partire la calibrazione in automatico (ma è ancora da rivedere).

== Encoder ==

A differenza di quanto pensavo per la prima versione dell'Ardubottino, gli encoder non sono digitali ma analogici. Per questo avevo delle letture non precise. Il problema di questo tipo di sensore è che non potendo usare l'interrupt, occorre fare delle letture continue, il polling, durante la marcia. Questo però comporta che durante il movimento il nostro integrato deve rimanere in ascolto e non può fare nient'altro.

La funzione steps conta quanti passi sono stati fatti.

== Sensori di distanza ==

Ci sono due sensori di distanza sull'ESProbottino.

=== Sensore a ultrasuoni ===

Il sensore a ultrasuoni ci restituisce la distanza in cm dall'ostacolo più vicino. Funziona come un sonar: lanciando un ultrasuono e ascoltandone l'eco possiamo capire quanto sia distante l'oggetto che sta davanti al sensore.
Qui c'è un link sul suo funzionamento, con anche un programma di esempio:
https://create.arduino.cc/projecthub/abdularbi17/ultrasonic-sensor-hc-sr04-with-arduino-tutorial-327ff6

=== Sensore IR ===

Il sensore IR è molto più semplice. Tramite una vite si regola quale dev'essere la soglia oltre il quale si accende. Uso questo sensore per capire se davanti a ESProbottino c'è un vuoto. Semplicemente se il pin è acceso, allora c'è un vuoto, altrimenti non c'è rischio di caduta. Se c'è un vuoto, la variabile falling diventa vera e impedisce ad es. di eseguire la funzione forward()

== Ponte ad H ==

Il ponte ad H permette di manovrare i due motori.
Per ogni motore ci sono tre pin: uno è un Enable, ovvero accende il motore quando riceve +5v, gli altri due determinano il verso in cui girerà.

EN P1 P2
+ - - Motore fermo
+ + - Motore gira in senso orario
+ - + Motore gira in senso antiorario
- ? ? Motore fermo

Un PWM al pin Enable permette di controllare la velocità del motore.

La board del ponte H dovrebbe essere in grado anche di alimentare a 5v la board ESP32 e l'ATmega8, ma dopo diversi tentativi ho preferito separare le alimentazioni. Spesso la partenza dei motori richiedeva troppa corrente che riavviava o creava rumore nell'ESP32.

== Movimento automatico ==

Il movimento automatico non è molto elaborato per ora. Va avanti, se incontra un ostacolo guarda prima a destra, poi a sinistra e infine decide di prendere la strada dove ha sentito più spazio. Se si accende il sensore di caduta allora fa retromarcia e poi fa circa 180° prima di ripartire.

== Flash ==

Per flashare l'ATmega8 occorre un Arduino che abbia il firmware "Arduino as ISP". Nell'ultima versione della IDE, nel Boards Manager c'è la possibilità di aggiungere le board ATmega8. Nelle Preferences, in "Additional Boards Manager URLs" occorre inserire:
https://mcudude.github.io/MiniCore/package_MCUdude_MiniCore_index.json
(se avete già degli indirizzi, separateli con una virgola)
dovrebbe comparire fra le board un nuovo menu chiamato "MiniCore", fra cui c'è anche l'ATmega8.

Per tutti i problemi relativi al flash dell'ATmega8 vi rimando all'[[OttoBot]], che è basato sullo stesso integrato.

= Il codice =

TBD

ESProbottino

2021-05-20T15:11:29Z

Oloturia: Creata pagina con 'Coming soon... File:ESP32BOTTINO.JPG'

Coming soon...

[[File:ESP32BOTTINO.JPG]]

File:ESP32BOTTINO.JPG

2021-05-20T15:10:24Z

Oloturia: ESP32bottino

ESP32bottino

Gruppo Robottini

2021-05-17T17:43:45Z

Oloturia: /* Progetti completati */

{{Gruppo
|nome=Robottini
|descrizione=l'umanità non ha speranza!
|social=http://raspibo.ofpcina.net/groups/profile/2815/robottini-terrestri
|mailinglist=http://liste.raspibo.org/wws/subscribe/robot.terrestri Vuoi partecipare o solamente essere informato? Iscriviti alla mailing list
|iscritti=Daniele [http://raspibo.ofpcina.net/profile/dancast78 dancast78], Savino [http://raspibo.ofpcina.net/profile/thegamer thegamer], Carmelo [http://raspibo.ofpcina.net/profile/tarmelop tarmelop], Gianni, Peppe, Marco, Luigi, Antonio, [http://raspibo.ofpcina.net/profile/oloturia1979 Oloturia], Elia [http://raspibo.ofpcina.net/profile/DasNetz DasNetz],
Lupo [http://raspibo.ofpcina.net/profile/Desmolupo Desmolupo],Walter [http://raspibo.ofpcina.net/profile/wave wave]}}

= Progetti in corso =

* [[RaspiRuga]]: un piccolo robot mosso da due motori passo-passo.
* [[OttoBot]]: il tentativo di fare un robottino con il cheap(!) ATmega8
* [[MultiFollower]]: Robot didattico che segue percorsi di tipo diverso.
* [[:Categoria:Ruschino]]: Interfaccia WiFi, si pilota da una pagina web con smartphone e tablet, hardware di recupero, esperimenti in corso!
* [[Pinza robotica]]: Dopo Ruschino proviamo a riciclare un altro tipo di motori del distributore automatico

= Progetti completati =

* [[Ardubottino]]: un robottino che evita gli ostacoli.
* [[ESProbottino]]: Ardubottino ha avuto un upgrade.
* [[Milkbot]]: un automa parzialmente scremato.
* [[RaspiTank]]: l'evoluzione della RaspiCar basata su un vecchio giocattolo; caratteristiche: servi comandati da Raspberry Pi, braccio meccanico.
* [[RaspiCar]]: automobilina radiocomandata basata su Raspberry Pi; caratteristiche: motori comandati da relè, relè azionati da transistor, comandare due pin contemporaneamente creando dei thread in Python.
* [[WindCar]]: (quasi) come sopra, ma con Arietta G25 al posto di Raspberry Pi
* Il [[braccio robot]] di Simone.
* [[Camera di sorveglianza]]: una semplicissima camera montata su un pan-tilt che fa lo streaming di cosa succede a casa vostra
* [[BlueCar]]: un'altra macchinina comandata da un RPi via Wi-Fi o Bluetooth
* [[Contalike]]: un aggeggino che vi permette di vedere quando perdete o guadagnate un like da un noto social network
* [[Cesarino]]: un robot assemblato in fretta e furia per testare quanto siano cool le fotoresistenze
* [[Roomba_scheduler]]: se avete un robot spazzino e volete schedularne l'avvio

= Varie =

* [[Display LCD Hitachi HD44780]] come usarlo, per esempio per avere un feedback sullo status del nostro robot.
* [[Display LCD SPI a colori]] e tutti i numerosi grattacapi per farlo funzionare.
* [[HC-05 e HC-06]] i moduli per trasmettere la seriale tramite il Bluetooth.
* [[Presepe]] un presepe con lucette comandate dal Raspberry Pi.
* [[OV7670]] come collegare una OV7670 ad Arduino Due.

= Informazioni utili =

* [http://www.servocity.com/index.html Servocity] store di materiale per la robotica particolarmente orientato ai motori e ai servo.
* [https://www.youtube.com/watch?v=9BQQLgB_mZQ Stepper Motor Pressed Gear Removal] Procedura di rimozione della corona sui motori passo passo. La procedura e' corretta ma occorre procedere delicatamente per non danneggiare i componenti.
* [http://www.raspibo.org/wiki/index.php?title=AxR75Project001 AxR75Project001] Interfacciamento motore lego, con SN75441ONE e con Raspberry Pi
* [http://shallowsky.com/blog/hardware/motors-with-arduino.html Interfacciamento motori] in particolare per Arduino, ma adattabile anche ad altri sistemi.

OV7670

2021-02-20T12:50:59Z

Oloturia: /* Lato Arduino Due */

Diversi anni fa comprai questa OV7670 con l'illusione che sarebbe stato divertente farla funzionare con un Arduino. Il mio obiettivo era una cosa molto semplice, come un sensore che scatta foto quando triggerato e che salvasse l'immagine su una SD. Purtroppo non si è rivelato possibile per diverse limitazioni delle schede Arduino più economiche: una scheda come l'Uno non ha abbastanza RAM per memorizzare un'immagine intera alle risoluzioni più alte, ma anche la più dotata Due ha bisogno di una gabola per riuscire ad avere i colori.

[[File:OV7670.JPG]]

Per ovviare a questo occorre una memoria FIFO, normalmente integrata nella scheda assieme a OV7670, ma la mia non l'aveva e acquistarla a parte ha solo comportato avere due problemi (come far funzionare la cam E come far funzionare la FIFO) al posto di uno.

Fra tutte le schede ho scelto l'Arduino Due perché ha abbastanza memoria per tenere un'intera immagine in QVGA (320x240) in bianco e nero e perché ha livelli logici a 3,3V, il che permette di collegarlo a OV7670 senza bisogno di un partitore di tensione.

= Le Guide =

== Instructables ==

Il primo passo per far funzionare una qualsiasi cosa è cercare guide e datasheet. La prima guida in cui ci si imbatte è questa:
https://www.instructables.com/How-to-Connect-OV7670-to-Arduino-Due/

Questo Instructable è stato il mio punto di partenza. Inizia con un semplice schema per il wiring:

DUE OV7670
3.3V VDD
GND GND
SCL(21) SDIOC
SDA(20) SDIOD
52 VSYNC
32 PCLK
7 XCLK
44 D7
45 D6
46 D5
47 D4
48 D3
49 D2
50 D1
51 D0
33 RESET
GND PWDN

A questo schema -senza nessun commento- manca il collegamento di HREF. Non verrà utilizzato e non è necessario collegarlo, ma nella guida non è specificato.
Nel resto della guida si spiega come il Due debba generare un clock e come scrivere nei registri di OV7670 tramite I²C. Viene fornito anche uno sketch che sembrerebbe funzionare e che in teoria leggerebbe l'immagine in bianco e nero per poi mandare l'output su seriale. Putroppo i programmi per decodificare questo segnale sono su un sito irraggiungibile. Ero quindi a un punto morto.

Ok ok non del tutto, nei commenti (ahimè l'ho scoperto quando ormai avevo già riscritto parte del codice) c'è una soluzione fatta in Processing che funziona bene:
https://pastebin.com/weAEcrQG

== Come funziona OV7670 e come non aver paura di YCbCr ==

http://embeddedprogrammer.blogspot.com/2012/07/hacking-ov7670-camera-module-sccb-cheat.html

Trovandomi un po' spiazzato, ho pensato che forse avrei dovuto approfittarne per riscrivere da capo tutto quanto, così da far funzionare finalmente la cam e allo stesso tempo imparare qualcosa di nuovo. Lo sketch dell'instructable precedente era per me un po' ostico da leggere, con molti riferimenti a me sconosciuti ai registri interni dell'Arduino Due e della cam. Punto di partenza è stato questo sito che spiega diverse cose sul funzionamento di OV7670.

Qui scopriamo che:
VSYNC è il segnale di sincronia verticale (HREF quello orizzontale, ma non lo useremo)
PCLK è il clock del pixel (in realtà -mezzo- pixel)
XCLK è il clock esterno, OV7670 ha bisogno di un clock esterno per funzionare: se volete scansionare gli indirizzi I²C per scoprire quello della cam, dovrete prima collegare un clock a XCLK

Un pixel su un monitor è composto da due informazioni: la posizione e il colore. La posizione è espressa in coordinate X e Y mentre il colore dalla luminosità dei colori primari R=Red/Rosso, G=Green/Verde e B=Blue/Blu. Normalmente ogni colore è espresso con 8 bit, da cui il nome RGB888. Purtroppo OV7670 invece comunica i pixel sequenzialmente a partire da 0,0 a 320,240 riga per riga e come formati di colore ha RGB565, RGB555 e RGB444 oppure YCbCr422. I primi tre semplicemente mandavano 5 bit di R, 6 di G e 5 di B oppure rispettivamente 5 oppure 4 per ogni colore. L'ultimo formato invece era completamente diverso e necessita di un approfondimento.

Nel format YCbCr l'immagine è separata in tre canali: la luma (Y) ossia la luminosità (se prendessimo solo Y come valore per RGB allora vedremmo l'immagine in bianco e nero) e la croma, ovvero i livelli di differenza da Y del blu (Cb) e del rosso (Cr). Ognuno di questi occupa un byte di informazione.

Ogni falling del PCLK la cam invia un byte di informazione in modo parallelo sui pin da D0 a D7. Come fa quindi a comunicare un pixel ogni colpo PCLK? Semplice: non lo fa. Manda i valori alternati in questo modo:
Cb0,Y0,Cr0,Y1,Cb2,Y2,Cr2,Y3...
La definizione di "Pixel Clock" è infatti fuorviante. Sarebbe "Half Pixel Clock" semmai.

Se bastasse l'immagine in bianco e nero allora basterà memorizzare un PCLK no e uno sì e avremo la luma. Questo è quello che faceva in teoria lo sketch del primo instructable. Ovviamente a me non bastava (a parte il fatto che comunque non funzionava), volevo anche i colori. Cb e Cr sono comuni per due pixel alla volta. Sempre secondo il link alla guida sopra:
pixel 0 = Y0 Cb0 Cr0
pixel 1 = Y1 Cb0 Cr0
pixel 2 = Y2 Cb2 Cr2
pixel 3 = Y3 Cb2 Cr2

Questo semplificava molto le cose. Invece di mandare la luma via seriale e scartare la croma, avrei mandato alternativamente prima la luma del frame e successivamente la croma. Avrebbe causato degli strani effetti nelle immagini in movimento ma sarebbe stato meglio di prima.
Perché non mandare contemporaneamente l'informazione? L'Arduino Due ha solo 96KB di SRAM, la luma o le crome da sole sono 320*240*1 byte = 76.8KB l'una. Mandare i dati via seriale alla fine della riga poteva essere una soluzione ma causava numerosi glitch sull'immagine risultante.

La guida è chiara, ma purtroppo manca uno sketch per il Due e relativo programma per processare l'immagine da seriale.

== Il datasheet ==

http://web.mit.edu/6.111/www/f2015/tools/OV7670app.pdf

In questo datasheet sono elencati i registri interni di OV7670. Nello sketch dell'Instructable sono impostati nella maggior parte dei casi senza spiegare cosa servono. Gli stessi valori li ho trovati anche in quest'altra guida: http://embeddedprogrammer.blogspot.com/2012/07/hacking-ov7670-camera-module-sccb-cheat.html e dal relativo codice su github: https://github.com/indrekluuk/LiveOV7670 per il collegamento della cam a un display.
Da quel che mi è parso di capire, sono i valori che il driver di Linux mette di default e usa per le varie impostazioni della cam (ad es. per passare da QVGA ad altri formati come il QCIF). Molto interessante ma a questo punto la mia missione era già diventata qualcos'altro, ovvero fare in modo che questi registri potessero essere modificati in modo interattivo.

= La soluzione =

L'obiettivo è quindi creare un programma che leggesse la seriale e restituisse l'immagine e allo stesso tempo fare in modo che si potessero leggere e scrivere i registri della cam.

== Lato Arduino Due ==

Lo sketch dell'Instructable fa le seguenti cose:
* Imposta i registri di OV7670 in modo che sia QVGA in formato YCbCr422
* Manda un segnale "*RDY*" e memorizza su una matrice un byte no e uno sì dei pin D0-D7
* Quando l'immagine è completa, manda via seriale ogni singolo byte della matrice

La modifica più importante è stata quella di mandare alternati il valore di Y e quello di CbCr. Nel frattempo avrebbe anche aspettato dallo script lato computer un segnale per dare il via alla lettura oppure un comando per leggere o scrivere su uno dei registri. Successivamente ho anche eliminato tutte le configurazioni che non cambiavano significativamente l'immagine e che probabilmente hanno a che fare con cose come il bilanciamento del bianco.

Vediamo alcuni dettagli dello sketch.

=== Generare un segnale di clock con Arduino ===

Arduino Due ha un generatore di PWM con i quali è possibile creare un segnale di clock di almeno 8MHz sufficienti per il XCLK di OV7670.

int32_t PWM_pin = digitalPinToBitMask(XCLK);
REG_PMC_PCER1 = 1 << 4; // Enable peripheral ID 36 (PWM) in the peripheral clock enable register - see 28.15.23
REG_PIOC_PDR |= PWM_pin; // Allow peripheral control for PWM_pin
REG_PIOC_ABSR |= PWM_pin; // Select peripheral B
REG_PWM_CPRD6 = 8; // Period: 84 MHz / 8 = 10.5 MHz - see 38.6.2.2 of datasheet
REG_PWM_CDTY6 = 4; // Duty Cycle: 8 / 4 = 0.5
REG_PWM_ENA = 1 << 6; // Enable PWML6 (pin 7) - see 38.5.1 and 38.7.5 of datasheet for more info

Gran parte delle informazioni su come funziona questo codice è spiegato su questa guida:
https://nhoffmanresearch.com/index.php/12-arduino-trap-control
e relativo datasheet del SAM3X9E:
http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-11057-32-bit-Cortex-M3-Microcontroller-SAM3X-SAM3A_Datasheet.pdf

=== I registri ===

Tramite I²C è possibile leggere lo stato di un registro o scrivere un nuovo valore. La lista dei registri è elencata sul datasheet, tuttavia alcuni, descritti come "Reserved", non sono documentati. La prima cosa quando si accende la cam è settare i registri in modo che trasmetta le informazioni nel formato QVGA e YCbCr, inoltre sono abilitate alcune funzioni come l'autobilanciamento del bianco. Una volta impostate queste cose, si può cominciare a catturare le immagini.

=== Loop ===

Una delle cose che non riuscivo a far funzionare era centrare l'immagine. Essendo scollegato HREF il punto di inizio era arbitrario, e questo comportava che l'immagine fosse fuori quadro. Ho cambiato un po' questa filosofia e ho fatto in modo che l'Arduino Due aspettasse un segnale sulla seriale prima di iniziare a trasmettere. Il segnale è composto da due byte, se sono entrambi 0xD0 allora invia una nuova immagine, se invece il primo è un altro valore, viene inviato il registro corrispondente a quel valore, se sono entrambi diversi il registro corrispondente al primo valore viene aggiornato con il secondo valore. Non esiste un registro 0xD0, quindi possiamo usare tale byte per segnalare quando siamo pronti a ricevere una nuova immagine.

In questo modo è possibile alterare in diretta l'immagine, cambiare luminosità, formato e anche scoprire a cosa servono i registri "Reserved".

=== Cattura dell'immagine ===

La cattura è fatta in due passate per questioni di spazio sulla RAM. Per prima cosa leggiamo Y e poi CbCr. Se non siamo interessati al colore, possiamo commentare la seconda chiamata alla funzione captureImg a cui ho aggiunto un terzo parametro, il bool chroma, per specificare se salvare i bit pari o quelli dispari.
Ogni PCLK basso viene aggiunto un valore (Y oppure CbCr) alla matrice che rappresenta le righe e le colonne. Durante la lettura il tempo è critico, per cui occorrono alcuni accorgimenti per sveltire le operazioni.

noInterrupts();

Questo comando disabilita gli interrupt. Non mi sembra che abbia nessun effetto benefico, ma male non fa.

REG_PIOB_PDSR & (1 << 21)
REG_PIOD_PDSR & (1 << 10)

Purtroppo le tanto comode funzioni digitalRead() di Arduino sono troppo lente per l'output di OV7670. Leggere direttamente il Pin Data Status Register (PDSR) di SAM3X9E è molto più veloce. Il bit 21 del PortB corrisponde al pin 52, che è quello dove abbiamo attaccato VSYNC, il bit 10 del PortD è il pin 32, dove abbiamo attaccato PCLK. Non è immediato convertire il pin in registro, ma ci sono moltissimi schemi con il pinout del Due, con descritto per ogni pin il Port e il bit.

(REG_PIOC_PDSR & 0xFF000) >> 12

Invece il PortC sono tutti i pin dov0 abbiamo collegato da D0 a D7. Memorizzando lo stato del Port e applicando un filtro in modo che restituisca solo i valori che ci interessano (PortC dalla 12 alla 19), non dobbiamo subire la costrizione di leggere lo stato di un pin alla volta.

Allo stesso tempo non è possibile usare la seriale di programmazione per trasmettere la matrice, occorre usare la porta nativa (Native) e invece di Serial, la funzione SerialUSB.write. Non c'è bisogno di inizializzarla con un baud rate perché andrà sempre alla velocità massima possibile. Questo dualismo mi ha permesso anche di fare alcune cose interessanti, come usare la porta nativa per la comunicazione con il programma che elabora le immagini e la porta di programmazione per mandare dei messaggi di debug.

== Lato Python ==

Sul computer ho scritto un piccolo script che pettinasse l'output dell'Arduino.

Per prima cosa manda un segnale di due byte. Se il segnale è 0xD0 0xD0 allora si mette in attesa di larghezza*altezza byte. Una volta ricevuti e messi in ordine (ricordate, un dato di croma vale per due pixel, mentre la luma c'è per ognuno) occorre usare alcune formule per trasformare i dati in RGB. Ho usato questa formula, che si può trovare nelle guide già citate sopra:
R = int(max(0, min(255,Y + 1.40200 * (Cr - 0x80))))
G = int(max(0, min(255,Y - 0.34414 * (Cb - 0x80) - 0.71414 * (Cr - 0x80))))
B = int(max(0, min(255,Y + 1.77200 * (Cb - 0x80))))

Lo script readYUV422.py restituisce quindi una bitmap. Gli altri script saveYUV422.py e showYUV422.py rispettivamente salvano l'immagine con PIL oppure la mostrano con pygame. L'altro script, tkinterface.py, invece è un'interfaccia fatta con tkinter con cui possiamo interagire direttamente con i registri di OV7670. Per risolvere il problema delle azioni concorrenti, ho usato un thread che facesse il refresh dell'immagine. La porta usata è /dev/ttyACM0, ma è possibile cambiarla aggiungendo un argomento quando si lancia lo script.

[[File:OVCAM.JPG]]

= I risultati =

Non è andato sempre tutto bene al primo colpo. Soprattutto all'inizio, quando non avevo ancora capito come leggere l'output, la cam ha dato degli output interessanti. Eccone alcuni.
[[File:Glitches.jpg]]

= Il repo =

Tutta la roba, con tutte le istruzioni e quant'altro, lo trovate nel repository su:
https://github.com/oloturia/ovcam

OV7670

2021-02-20T01:57:36Z

Oloturia: OV7670

Diversi anni fa comprai questa OV7670 con l'illusione che sarebbe stato divertente farla funzionare con un Arduino. Il mio obiettivo era una cosa molto semplice, come un sensore che scatta foto quando triggerato e che salvasse l'immagine su una SD. Purtroppo non si è rivelato possibile per diverse limitazioni delle schede Arduino più economiche: una scheda come l'Uno non ha abbastanza RAM per memorizzare un'immagine intera alle risoluzioni più alte, ma anche la più dotata Due ha bisogno di una gabola per riuscire ad avere i colori.

[[File:OV7670.JPG]]

Per ovviare a questo occorre una memoria FIFO, normalmente integrata nella scheda assieme a OV7670, ma la mia non l'aveva e acquistarla a parte ha solo comportato avere due problemi (come far funzionare la cam E come far funzionare la FIFO) al posto di uno.

Fra tutte le schede ho scelto l'Arduino Due perché ha abbastanza memoria per tenere un'intera immagine in QVGA (320x240) in bianco e nero e perché ha livelli logici a 3,3V, il che permette di collegarlo a OV7670 senza bisogno di un partitore di tensione.

= Le Guide =

== Instructables ==

Il primo passo per far funzionare una qualsiasi cosa è cercare guide e datasheet. La prima guida in cui ci si imbatte è questa:
https://www.instructables.com/How-to-Connect-OV7670-to-Arduino-Due/

Questo Instructable è stato il mio punto di partenza. Inizia con un semplice schema per il wiring:

DUE OV7670
3.3V VDD
GND GND
SCL(21) SDIOC
SDA(20) SDIOD
52 VSYNC
32 PCLK
7 XCLK
44 D7
45 D6
46 D5
47 D4
48 D3
49 D2
50 D1
51 D0
33 RESET
GND PWDN

A questo schema -senza nessun commento- manca il collegamento di HREF. Non verrà utilizzato e non è necessario collegarlo, ma nella guida non è specificato.
Nel resto della guida si spiega come il Due debba generare un clock e come scrivere nei registri di OV7670 tramite I²C. Viene fornito anche uno sketch che sembrerebbe funzionare e che in teoria leggerebbe l'immagine in bianco e nero per poi mandare l'output su seriale. Putroppo i programmi per decodificare questo segnale sono su un sito irraggiungibile. Ero quindi a un punto morto.

Ok ok non del tutto, nei commenti (ahimè l'ho scoperto quando ormai avevo già riscritto parte del codice) c'è una soluzione fatta in Processing che funziona bene:
https://pastebin.com/weAEcrQG

== Come funziona OV7670 e come non aver paura di YCbCr ==

http://embeddedprogrammer.blogspot.com/2012/07/hacking-ov7670-camera-module-sccb-cheat.html

Trovandomi un po' spiazzato, ho pensato che forse avrei dovuto approfittarne per riscrivere da capo tutto quanto, così da far funzionare finalmente la cam e allo stesso tempo imparare qualcosa di nuovo. Lo sketch dell'instructable precedente era per me un po' ostico da leggere, con molti riferimenti a me sconosciuti ai registri interni dell'Arduino Due e della cam. Punto di partenza è stato questo sito che spiega diverse cose sul funzionamento di OV7670.

Qui scopriamo che:
VSYNC è il segnale di sincronia verticale (HREF quello orizzontale, ma non lo useremo)
PCLK è il clock del pixel (in realtà -mezzo- pixel)
XCLK è il clock esterno, OV7670 ha bisogno di un clock esterno per funzionare: se volete scansionare gli indirizzi I²C per scoprire quello della cam, dovrete prima collegare un clock a XCLK

Un pixel su un monitor è composto da due informazioni: la posizione e il colore. La posizione è espressa in coordinate X e Y mentre il colore dalla luminosità dei colori primari R=Red/Rosso, G=Green/Verde e B=Blue/Blu. Normalmente ogni colore è espresso con 8 bit, da cui il nome RGB888. Purtroppo OV7670 invece comunica i pixel sequenzialmente a partire da 0,0 a 320,240 riga per riga e come formati di colore ha RGB565, RGB555 e RGB444 oppure YCbCr422. I primi tre semplicemente mandavano 5 bit di R, 6 di G e 5 di B oppure rispettivamente 5 oppure 4 per ogni colore. L'ultimo formato invece era completamente diverso e necessita di un approfondimento.

Nel format YCbCr l'immagine è separata in tre canali: la luma (Y) ossia la luminosità (se prendessimo solo Y come valore per RGB allora vedremmo l'immagine in bianco e nero) e la croma, ovvero i livelli di differenza da Y del blu (Cb) e del rosso (Cr). Ognuno di questi occupa un byte di informazione.

Ogni falling del PCLK la cam invia un byte di informazione in modo parallelo sui pin da D0 a D7. Come fa quindi a comunicare un pixel ogni colpo PCLK? Semplice: non lo fa. Manda i valori alternati in questo modo:
Cb0,Y0,Cr0,Y1,Cb2,Y2,Cr2,Y3...
La definizione di "Pixel Clock" è infatti fuorviante. Sarebbe "Half Pixel Clock" semmai.

Se bastasse l'immagine in bianco e nero allora basterà memorizzare un PCLK no e uno sì e avremo la luma. Questo è quello che faceva in teoria lo sketch del primo instructable. Ovviamente a me non bastava (a parte il fatto che comunque non funzionava), volevo anche i colori. Cb e Cr sono comuni per due pixel alla volta. Sempre secondo il link alla guida sopra:
pixel 0 = Y0 Cb0 Cr0
pixel 1 = Y1 Cb0 Cr0
pixel 2 = Y2 Cb2 Cr2
pixel 3 = Y3 Cb2 Cr2

Questo semplificava molto le cose. Invece di mandare la luma via seriale e scartare la croma, avrei mandato alternativamente prima la luma del frame e successivamente la croma. Avrebbe causato degli strani effetti nelle immagini in movimento ma sarebbe stato meglio di prima.
Perché non mandare contemporaneamente l'informazione? L'Arduino Due ha solo 96KB di SRAM, la luma o le crome da sole sono 320*240*1 byte = 76.8KB l'una. Mandare i dati via seriale alla fine della riga poteva essere una soluzione ma causava numerosi glitch sull'immagine risultante.

La guida è chiara, ma purtroppo manca uno sketch per il Due e relativo programma per processare l'immagine da seriale.

== Il datasheet ==

http://web.mit.edu/6.111/www/f2015/tools/OV7670app.pdf

In questo datasheet sono elencati i registri interni di OV7670. Nello sketch dell'Instructable sono impostati nella maggior parte dei casi senza spiegare cosa servono. Gli stessi valori li ho trovati anche in quest'altra guida: http://embeddedprogrammer.blogspot.com/2012/07/hacking-ov7670-camera-module-sccb-cheat.html e dal relativo codice su github: https://github.com/indrekluuk/LiveOV7670 per il collegamento della cam a un display.
Da quel che mi è parso di capire, sono i valori che il driver di Linux mette di default e usa per le varie impostazioni della cam (ad es. per passare da QVGA ad altri formati come il QCIF). Molto interessante ma a questo punto la mia missione era già diventata qualcos'altro, ovvero fare in modo che questi registri potessero essere modificati in modo interattivo.

= La soluzione =

L'obiettivo è quindi creare un programma che leggesse la seriale e restituisse l'immagine e allo stesso tempo fare in modo che si potessero leggere e scrivere i registri della cam.

== Lato Arduino Due ==

Lo sketch dell'Instructable fondamentalmente fa le seguenti cose
Imposta i registri di OV7670 in modo che sia QVGA in formato YCbCr422
Manda un segnale "*RDY*" e memorizza su una matrice un byte no e uno sì dei pin D0-D7
Quando l'immagine è completa, manda via seriale ogni singolo byte della matrice

La modifica più importante è stata quella di mandare alternati il valore di Y e quello di CbCr. Nel frattempo avrebbe anche aspettato dallo script lato computer un segnale per dare il via alla lettura oppure un comando per leggere o scrivere su uno dei registri. Successivamente ho anche eliminato tutte le configurazioni che non cambiavano significativamente l'immagine e che probabilmente hanno a che fare con cose come il bilanciamento del bianco.

Vediamo alcuni dettagli dello sketch.

=== Generare un segnale di clock con Arduino ===

Arduino Due ha un generatore di PWM con i quali è possibile creare un segnale di clock di almeno 8MHz sufficienti per il XCLK di OV7670.

int32_t PWM_pin = digitalPinToBitMask(XCLK);
REG_PMC_PCER1 = 1 << 4; // Enable peripheral ID 36 (PWM) in the peripheral clock enable register - see 28.15.23
REG_PIOC_PDR |= PWM_pin; // Allow peripheral control for PWM_pin
REG_PIOC_ABSR |= PWM_pin; // Select peripheral B
REG_PWM_CPRD6 = 8; // Period: 84 MHz / 8 = 10.5 MHz - see 38.6.2.2 of datasheet
REG_PWM_CDTY6 = 4; // Duty Cycle: 8 / 4 = 0.5
REG_PWM_ENA = 1 << 6; // Enable PWML6 (pin 7) - see 38.5.1 and 38.7.5 of datasheet for more info

Gran parte delle informazioni su come funziona questo codice è spiegato su questa guida:
https://nhoffmanresearch.com/index.php/12-arduino-trap-control
e relativo datasheet del SAM3X9E:
http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-11057-32-bit-Cortex-M3-Microcontroller-SAM3X-SAM3A_Datasheet.pdf

=== I registri ===

Tramite I²C è possibile leggere lo stato di un registro o scrivere un nuovo valore. La lista dei registri è elencata sul datasheet, tuttavia alcuni, descritti come "Reserved", non sono documentati. La prima cosa quando si accende la cam è settare i registri in modo che trasmetta le informazioni nel formato QVGA e YCbCr, inoltre sono abilitate alcune funzioni come l'autobilanciamento del bianco. Una volta impostate queste cose, si può cominciare a catturare le immagini.

=== Loop ===

Una delle cose che non riuscivo a far funzionare era centrare l'immagine. Essendo scollegato HREF il punto di inizio era arbitrario, e questo comportava che l'immagine fosse fuori quadro. Ho cambiato un po' questa filosofia e ho fatto in modo che l'Arduino Due aspettasse un segnale sulla seriale prima di iniziare a trasmettere. Il segnale è composto da due byte, se sono entrambi 0xD0 allora invia una nuova immagine, se invece il primo è un altro valore, viene inviato il registro corrispondente a quel valore, se sono entrambi diversi il registro corrispondente al primo valore viene aggiornato con il secondo valore. Non esiste un registro 0xD0, quindi possiamo usare tale byte per segnalare quando siamo pronti a ricevere una nuova immagine.

In questo modo è possibile alterare in diretta l'immagine, cambiare luminosità, formato e anche scoprire a cosa servono i registri "Reserved".

=== Cattura dell'immagine ===

La cattura è fatta in due passate per questioni di spazio sulla RAM. Per prima cosa leggiamo Y e poi CbCr. Se non siamo interessati al colore, possiamo commentare la seconda chiamata alla funzione captureImg a cui ho aggiunto un terzo parametro, il bool chroma, per specificare se salvare i bit pari o quelli dispari.
Ogni PCLK basso viene aggiunto un valore (Y oppure CbCr) alla matrice che rappresenta le righe e le colonne. Durante la lettura il tempo è critico, per cui occorrono alcuni accorgimenti per sveltire le operazioni.

noInterrupts();

Questo comando disabilita gli interrupt. Non mi sembra che abbia nessun effetto benefico, ma male non fa.

REG_PIOB_PDSR & (1 << 21)
REG_PIOD_PDSR & (1 << 10)

Purtroppo le tanto comode funzioni digitalRead() di Arduino sono troppo lente per l'output di OV7670. Leggere direttamente il Pin Data Status Register (PDSR) di SAM3X9E è molto più veloce. Il bit 21 del PortB corrisponde al pin 52, che è quello dove abbiamo attaccato VSYNC, il bit 10 del PortD è il pin 32, dove abbiamo attaccato PCLK. Non è immediato convertire il pin in registro, ma ci sono moltissimi schemi con il pinout del Due, con descritto per ogni pin il Port e il bit.

(REG_PIOC_PDSR & 0xFF000) >> 12

Invece il PortC sono tutti i pin dov0 abbiamo collegato da D0 a D7. Memorizzando lo stato del Port e applicando un filtro in modo che restituisca solo i valori che ci interessano (PortC dalla 12 alla 19), non dobbiamo subire la costrizione di leggere lo stato di un pin alla volta.

Allo stesso tempo non è possibile usare la seriale di programmazione per trasmettere la matrice, occorre usare la porta nativa (Native) e invece di Serial, la funzione SerialUSB.write. Non c'è bisogno di inizializzarla con un baud rate perché andrà sempre alla velocità massima possibile. Questo dualismo mi ha permesso anche di fare alcune cose interessanti, come usare la porta nativa per la comunicazione con il programma che elabora le immagini e la porta di programmazione per mandare dei messaggi di debug.

== Lato Python ==

Sul computer ho scritto un piccolo script che pettinasse l'output dell'Arduino.

Per prima cosa manda un segnale di due byte. Se il segnale è 0xD0 0xD0 allora si mette in attesa di larghezza*altezza byte. Una volta ricevuti e messi in ordine (ricordate, un dato di croma vale per due pixel, mentre la luma c'è per ognuno) occorre usare alcune formule per trasformare i dati in RGB. Ho usato questa formula, che si può trovare nelle guide già citate sopra:
R = int(max(0, min(255,Y + 1.40200 * (Cr - 0x80))))
G = int(max(0, min(255,Y - 0.34414 * (Cb - 0x80) - 0.71414 * (Cr - 0x80))))
B = int(max(0, min(255,Y + 1.77200 * (Cb - 0x80))))

Lo script readYUV422.py restituisce quindi una bitmap. Gli altri script saveYUV422.py e showYUV422.py rispettivamente salvano l'immagine con PIL oppure la mostrano con pygame. L'altro script, tkinterface.py, invece è un'interfaccia fatta con tkinter con cui possiamo interagire direttamente con i registri di OV7670. Per risolvere il problema delle azioni concorrenti, ho usato un thread che facesse il refresh dell'immagine. La porta usata è /dev/ttyACM0, ma è possibile cambiarla aggiungendo un argomento quando si lancia lo script.

[[File:OVCAM.JPG]]

= I risultati =

Non è andato sempre tutto bene al primo colpo. Soprattutto all'inizio, quando non avevo ancora capito come leggere l'output, la cam ha dato degli output interessanti. Eccone alcuni.
[[File:Glitches.jpg]]

= Il repo =

Tutta la roba, con tutte le istruzioni e quant'altro, lo trovate nel repository su:
https://github.com/oloturia/ovcam

File:Glitches.jpg

2021-02-20T01:33:47Z

Oloturia:

File:OVCAM.JPG

2021-02-20T01:26:48Z

Oloturia:

File:OV7670.JPG

2021-02-20T01:19:44Z

Oloturia:

Gruppo Robottini

2021-02-20T01:03:32Z

Oloturia: /* Varie */

{{Gruppo
|nome=Robottini
|descrizione=l'umanità non ha speranza!
|social=http://raspibo.ofpcina.net/groups/profile/2815/robottini-terrestri
|mailinglist=http://liste.raspibo.org/wws/subscribe/robot.terrestri Vuoi partecipare o solamente essere informato? Iscriviti alla mailing list
|iscritti=Daniele [http://raspibo.ofpcina.net/profile/dancast78 dancast78], Savino [http://raspibo.ofpcina.net/profile/thegamer thegamer], Carmelo [http://raspibo.ofpcina.net/profile/tarmelop tarmelop], Gianni, Peppe, Marco, Luigi, Antonio, [http://raspibo.ofpcina.net/profile/oloturia1979 Oloturia], Elia [http://raspibo.ofpcina.net/profile/DasNetz DasNetz],
Lupo [http://raspibo.ofpcina.net/profile/Desmolupo Desmolupo],Walter [http://raspibo.ofpcina.net/profile/wave wave]}}

= Progetti in corso =

* [[RaspiRuga]]: un piccolo robot mosso da due motori passo-passo.
* [[OttoBot]]: il tentativo di fare un robottino con il cheap(!) ATmega8
* [[MultiFollower]]: Robot didattico che segue percorsi di tipo diverso.
* [[:Categoria:Ruschino]]: Interfaccia WiFi, si pilota da una pagina web con smartphone e tablet, hardware di recupero, esperimenti in corso!
* [[Pinza robotica]]: Dopo Ruschino proviamo a riciclare un altro tipo di motori del distributore automatico

= Progetti completati =

* [[Ardubottino]]: un robottino che evita gli ostacoli.
* [[Milkbot]]: un automa parzialmente scremato.
* [[RaspiTank]]: l'evoluzione della RaspiCar basata su un vecchio giocattolo; caratteristiche: servi comandati da Raspberry Pi, braccio meccanico.
* [[RaspiCar]]: automobilina radiocomandata basata su Raspberry Pi; caratteristiche: motori comandati da relè, relè azionati da transistor, comandare due pin contemporaneamente creando dei thread in Python.
* [[WindCar]]: (quasi) come sopra, ma con Arietta G25 al posto di Raspberry Pi
* Il [[braccio robot]] di Simone.
* [[Camera di sorveglianza]]: una semplicissima camera montata su un pan-tilt che fa lo streaming di cosa succede a casa vostra
* [[BlueCar]]: un'altra macchinina comandata da un RPi via Wi-Fi o Bluetooth
* [[Contalike]]: un aggeggino che vi permette di vedere quando perdete o guadagnate un like da un noto social network
* [[Cesarino]]: un robot assemblato in fretta e furia per testare quanto siano cool le fotoresistenze
* [[Roomba_scheduler]]: se avete un robot spazzino e volete schedularne l'avvio

= Varie =

* [[Display LCD Hitachi HD44780]] come usarlo, per esempio per avere un feedback sullo status del nostro robot.
* [[Display LCD SPI a colori]] e tutti i numerosi grattacapi per farlo funzionare.
* [[HC-05 e HC-06]] i moduli per trasmettere la seriale tramite il Bluetooth.
* [[Presepe]] un presepe con lucette comandate dal Raspberry Pi.
* [[OV7670]] come collegare una OV7670 ad Arduino Due.

= Informazioni utili =

* [http://www.servocity.com/index.html Servocity] store di materiale per la robotica particolarmente orientato ai motori e ai servo.
* [https://www.youtube.com/watch?v=9BQQLgB_mZQ Stepper Motor Pressed Gear Removal] Procedura di rimozione della corona sui motori passo passo. La procedura e' corretta ma occorre procedere delicatamente per non danneggiare i componenti.
* [http://www.raspibo.org/wiki/index.php?title=AxR75Project001 AxR75Project001] Interfacciamento motore lego, con SN75441ONE e con Raspberry Pi
* [http://shallowsky.com/blog/hardware/motors-with-arduino.html Interfacciamento motori] in particolare per Arduino, ma adattabile anche ad altri sistemi.

HC-05 e HC-06

2021-02-01T13:06:26Z

Oloturia: /* Bluetooth Manager */

HC-05 e HC-06 sono due tipi di moduli Bluetooth che ci permettono di trasmettere e ricevere dati tramite l'interfaccia seriale (ma non solo). Sono molto semplici da usare e hanno molteplici utilizzi.

[[File:Hc-05.jpg]]

Nella foto potete vedere a sinistra il modulo senza lo zoccolo, i cui pin sono i contatti intorno, a destra la versione più comune, saldata su uno zoccolo con i pin di alimentazione e la seriale libera. Gli zoccoli hanno diverse forme e alcuni (come questo) hanno anche alcuni pin in più con funzioni diverse.

= Pinout =

Le board hanno il seguente pinout ([http://www.14core.com/working-with-hc05-hc06-to-configure-and-implementations/ immagine tratta da 14core.com])
[[File:Bluetooth-HC06-Versus-HC05-Bluetooth-Module-Comparison-001.jpg]]

Essendo la board spesso saldata su uno zoccolo ed essendo quest'ultimo non standard, non è possibile dare un pinout preciso. I pin che troverete sempre sono:

* '''Vcc''' e '''GND'''
* '''TXD''' e '''RXD''' (sono TX e RX seriali)

Quelli opzionali:

* '''Key''' questo pin è collegato al pin della board che deve essere collegato alla 3,3V per entrare in modalità AT, normalmente lo zoccolo ha anche un pulsante che fa la stessa cosa, in mancanza dell'uno e dell'altro dovrete fare ponte con qualcosa di conduttivo fra una sorgente a 3,3V e il pin Key sulla board
* '''State''' questo pin dovrebbe essere alto quando il device è connesso a qualcosa e basso quando non è collegato a niente
* '''EN''' dovrebbe essere l'enable, ma non è chiaro come funzioni

Le board hanno anche il collegamento per un LED di stato. Lo zoccolo di solito ne possiede uno. Il LED ha tre stati:

* Lampeggia velocemente: la board è accesa e non è collegata a niente
* Lampeggia piano (circa 1s): la board è collegata a qualcosa
* Lampeggia molto piano (circa 2s): la board è in modalità AT

= Differenze HC-05 e HC-06 =

I due device sono molto simili. Nella maggior parte dei casi potete prendere l'uno o l'altro indifferentemente. Le uniche differenze degne di nota sono:

* L'HC-05 può essere impostato come master, mentre l''''HC-06 è solo slave'''. Questo comporta che entrambi possono ricevere connessioni ma '''solo l'HC-05 può iniziarne una'''.

* L'HC-06 è sempre in modalità AT quando non è collegato a un altro dispositivo, mentre l'HC-05 occorre accenderlo mandando 3,3 volt allo speciale pin "key" (gli zoccoli di solito hanno un pin "Key" oppure un pulsante da premere).

* Il pinout è diverso (ovviamente s'intende il pinout della board, non quello dello zoccolo).

= Alimentazione =
I moduli vanno alimentati a 3,3V. Gli zoccoli più comuni permettono anche alimentazioni diverse tramite un regolatore di voltaggio, ma i livelli logici sono sempre a 3,3V.

= Collegamento all'Arduino =
Potete collegare direttamente la seriale UART dell'Arduino al modulo HC-0X. RX (ricevitore seriale) e TX (trasmittente seriale) di Arduino (pin 0 e 1) vanno collegati rispettivamente al TX e all'RX del modulo Bluetooth (in pratica: dovete incrociarli: RX con TX e TX con RX). Se vi serve solo come ricevente, potete collegare solo il TX dell'HC-0X all'RX dell'Arduino, al contrario se vi serve solo una trasmittente collegate solo l'RX dell'HC-0X al TX dell'Arduino. RX e TX a volte sono scritti RXD e TXD. Non cambia assolutamente nulla.

Se la seriale fisica dovesse essere occupata, è possibile averne una software su due pin diversi con la libreria [https://www.arduino.cc/en/Reference/SoftwareSerial SoftwareSerial].

= Collegamento Bluetooth al PC =

Sotto Linux ci sono diversi modi per attivare una comunicazione seriale fra il SO e un dispositivo che permette questo tipo di servizio. La seriale comparirà come file di device nella posizione /dev/rfcommX dove X è un numero che parte da 0. Se abbiamo una sola comunicazione seriale avremo quindi /dev/rfcomm0. A questo file ci si può collegare ad esempio con il comando screen.

# screen /dev/rfcommX <velocità baud>

Occorre essere root o dare il comando con sudo, perché l'utente normale non dovrebbe essere in grado di scrivere su rfcommX.

== Prerequisiti ==

L'utente deve essere nel gruppo "bluetooth". Per aggiungersi al gruppo bisogna editare il file /etc/group e aggiungere il vostro nome al gruppo, troverete qualcosa come

bluetooth:x:<ID>:

dovete aggiungere l'utente dopo i due punti

bluetooth:x:<ID>:utente

per attivare la modifica fate log out e log in

== Bluetooth Manager ==

Bluetooth Manager è il programma che viene aperto di default quando un adattatore Bluetooth USB è collegato al PC. Purtroppo è anche pieno di bug e abbastanza prono a crashare. Nelle ultime versioni pare che vada molto meglio. Nel caso abbiate problemi vi consiglio di chiudere il programma (dovete cliccare col tasto destro sull'icona del Bluetooth sulla barra delle applet oppure killate blueman-manager) e lanciare da un terminale blueman-manager. Vediamo passo passo come fare a creare un collegamento seriale.

Cliccate su "Search" e cercate il dispositivo a cui dovete collegarvi. Se non l'avete rinominato, gli HC si chiameranno HC-05 o HC-06. Nel caso ce ne sia più di uno, cercate di ricordare l'indirizzo fisico, il MAC Address.

[[File:Hc0506 1.png]]

Cliccate col tasto destro e selezionate "Pair". Uscirà un pop up in cui vi verrà chiesto il pin. Se non l'avete modificato normalmente è 1234.

[[File:Hc0506 2.png]]

Una volta avvenuto il pairing, comparirà il simbolo di una chiave vicino all'icona del vostro device Bluetooth. Cliccate di nuovo il tasto destro e selezionate Serial Port.

[[File:Hc0506 4.png]]

Se tutto è andato come doveva, vedrete l'indicazione di quale file di device è la vostra comunicazione seriale. Ora potete aprirlo con screen o altri programmi.

[[File:Hc0506 5.png]]

== bluetoothctl ==

È possibile anche usare questo tool per riga di comando, molto utile se ad esempio siete in collegamento ssh con un Raspberry o se non amate le GUI.

Anzitutto, consiglio di usare l'agente KeyboardOnly, altrimenti potrebbe chiedervi il pairing in un pop-up, e se siete in modalità solo testo c'è il caso che non compaia.

# agent off

# agent KeyboardOnly

Per vedere la lista dei dispositivi bluetooth occorre usare il comando scan.

# scan on

Questo mostrerà gli indirizzi MAC dei dispositivi rilevati.
Per fare il pairing si usa il comando pair:

# pair <indirizzo MAC>

A questo punto dovremo inserire il PIN del dispositivo. Una volta fatto questo il nostro computer e il dispositivo saranno accoppiati. Dando il comando quit si potrà uscire da bluetoothctl. A questo punto apriamo una porta seriale con rfcomm

$ sudo rfcomm connect /dev/rfcomm0 <indirizzo MAC> 1 &

Questo creerà una porta seriale su /dev/rfcomm0 alla quale possiamo collegarci con screen, minicom o qualsiasi altro programma per la comunicazione seriale.

= Cambiare configurazione =

Gran parte di questo capitolo è preso da [http://www.instructables.com/id/AT-command-mode-of-HC-05-Bluetooth-module/ questa guida su Instructables].
Per cambiare configurazione al vostro modulo (ad es. cambiare velocità di trasmissione, nome, pin, ecc.) dovete entrare in modalità AT. L'HC-06 dovrebbe essere sempre in questa modalità, mentre l'HC-05 dev'essere acceso tenendo premuto il tasto "KEY" oppure mettendo a +3.3v il pin key sulla board. Quando è in modalità AT, l'HC-05 lampeggerà a intervalli di 2 secondi circa e potrete mandare i comandi AT alla seriale fisica sulla board. Se non avete un convertitore USB TTL, potete riciclare un Arduino per fare da ponte. Poiché l'Arduino Uno e simili (non il Mega, ad es.) ha una sola porta seriale, dovrete usare una porta seriale emulata via software. Lo sketch sarà più o meno così:

#include <SoftwareSerial.h>
SoftwareSerial mySerial(10, 11); // RX, TX
void setup() {
Serial.begin(9600);
pinMode(9,OUTPUT); digitalWrite(9,HIGH);
Serial.println("Enter AT commands:");
mySerial.begin(38400);
}

void loop() {
if (mySerial.available()) Serial.write(mySerial.read());
if (Serial.available()) mySerial.write(Serial.read());
}

Notate alcune cose di questo codice: mySerial è la software seriale dove andrà collegato il vostro HC, nei pin 10 e 11 (10 è RX e 11 TX, quindi il 10 andrà collegato al TX dell'HC e l'11 al RX). '''In modalità AT il modulo HC comunica a 38400 baud'''.

Ora aprite una seriale (va bene anche quella dell'IDE di Arduino, ricordatevi di mettere come CR e NL come fine linea) a 38400 baud e scrivete:

AT

L'HC dovrebbe rispondervi

OK

Se non lo fa forse avete sbagliato uno dei passi precedenti.

I comandi più utili sono:
* AT+NAME=<nome> cambia nome all'ID Bluetooth
* AT+UART=<baudrate> cambia la velocità della trasmissione Bluetooth (la modalità AT rimane a 38400)
* AT+ROLE=<1:master 0:slave> permette l'HC-05 di essere master o di essere solo slave in una comunicazione
* AT+ORGL ripristina le configurazioni di fabbrica
* AT+PSWD cambia la password

I comandi, se seguiti da ?, dovrebbero dire quale è il valore al momento memorizzato, ad esempio:

AT+UART?

dovrebbe restituire

9600

In [http://cdn.instructables.com/ORIG/FKY/Z0UT/HX7OYY7I/FKYZ0UTHX7OYY7I.pdf questa guida] potete trovare dettagli più approfonditi.

Pagina principale

2020-03-31T10:41:19Z

Oloturia: /* Gruppi e Progetti */

__NOTOC__

{| id="table-top-top" style="margin-top:2px; background:none;align:center;width:100%;border:1px solid red;-moz-border-radius: 10px; -webkit-border-radius: 10px; border-radius:10px;"
| style="background:white; width:75%; vertical-align:top; color:#000; padding: 5px 10px 10px 8px; " |
[[File:Emblem-important-2.png|left|48px|link=Prossimi appuntamenti]]

=[[Prossimi appuntamenti|Prossimi appuntamenti]]=

{{:Prossimi appuntamenti}}

-----------
'' Iscriviti alle nostre [http://liste.raspibo.org/wws/ mailing list]! ''

-----------

Gli appuntamenti fissi si tengono ogni '''secondo e quarto martedì del mese''' dalle ore 20.30 in avanti. La sala resta a disposizione anche i restanti martedì e tutti i giovedì: se volete usare i nostri spazi per i vostri incontri e progetti, scrivetelo sulla lista pubblica [http://liste.raspibo.org/wws/info/agora agora] e segnalate la vostra presenza sul nostro [http://lela.ismito.it:3000 sistema di prenotazioni].

[[Eventi passati]]

| style="background:white; width:75%; vertical-align:top; color:#000; padding: 5px 10px 10px 8px; " |
[[File:Go-home-9.png|right|48px|link=makerspace]]

= [[makerspace|Makerspace]] =
[http://centrocroce.blogspot.it/ Presso il centro sociale CROCE]
[[makerspace|Via Canonica 18 a Casalecchio di Reno]].<br/>
Una sala messa a disposizione all'interno del centro, dove ogni martedì e giovedì i gruppi e le persone che insieme collaborano ad un progetto, possono utilizzare.


= Cookie =
Questo sito usa solamente Cookie Tecnici. <br/>
[[Cookie Tecnici|maggiori informazioni]]
|}


{| id="table-central" style="margin-top:10px; background:none;"
| style="background:white; width:35%; border:1px solid #a7d7f9; vertical-align:top; color:#000; padding: 5px 10px 10px 8px; -moz-border-radius: 10px; -webkit-border-radius: 10px; border-radius:10px;" |

{| id="table-central-left" cellpadding="2" cellspacing="5" style="width:100%; vertical-align:top; background:transparent;"
[[File:PCB-icon.png|right|48px]]

= [[gruppi|Gruppi]] e [[:Categoria:Progetti|Progetti]] =

{{:Gruppi}}

[[File:Maker-faire.png|right|128px|link=Maker_Faire_2014]]
[[File:Maker_of_merit.jpg|right|128px|link=FotoMakerFaireRome2014]]

'''Dettagli sui [[I_gruppi_di_lavoro_del_non-corso|gruppi di lavoro]].'''

'''Vetrina dei [[:Categoria:Progetti|progetti in corso]].'''

'''Leggi la [[Documentazione|documentazione prodotta]].'''

'''Iscrivetevi alle [http://liste.raspibo.org mailing list].'''

'''[[ wireless_comunity_network |NINUX Bologna - Wireless community network]].'''

'''[[ link_e_idee |Link&Idee]].'''

'''[[ Renzo's Bliki ]].'''

'''[[ Laboratory of Making ]].'''

Abbiamo raccolto alcuni progetti di autoproduzione riguardanti il '''[[ Covid19 ]].'''

[[File:Applications-science.png|right|48px]]

== Serate aperte a tutti ==

''Gli incontri presso il [[makerspace]] sono ad accesso libero e gratuito, vedi anche le [[RIVOLUZIONE ALL'INCONTRO DEL 7 MARZO|note su come di solito procediamo]]''<br />

Se pensate di partecipare, segnalate la vostra presenza sul sistema [https://ibt2.ismito.it/ RaspiBO makerspace booking], basta il vostro nickname. Per favore ricordate di aggiornarlo.

== Gite, fiere ed eventi ==

Maker, segnalate [[Gite|qui ]] tutti gli eventi che ritenete interessanti!

= Acquisti ossessivo-compulsivi =

Ogni tanto ci vengono voglie strane; per amortizzare le spese di spedizione, cerchiamo di [[Elenco degli acquisti|aggregare gli ordini]].

= Convenzioni acquisti =
La ditta Homotix e la ditta Katodo praticano, agli utenti RaspiBo, uno sconto. Per usufruirne segui le '''[[convenzioni acquisti | istruzioni]]'''.

= Il non-staff ed i contatti =

Non desideriamo strutturare troppo la '''non-associazione''', ma un gruppetto si sta prendendo in carico di seguirne la gestione; [[Non-staff|scoprite chi sono]] e soprattutto come potete aiutarli, dato che c'è [[Aiuto:Indice|bisogno del contributo]] di tutti!
|}


| style="border:3px solid transparent;" |


| style="width:65%; border:1px solid #a7d7f9; background:#f5faff; vertical-align:top; padding: 5px 10px 10px 8px; -moz-border-radius: 10px; -webkit-border-radius: 10px; border-radius:10px;" |
{| id="table-central-right" cellpadding="2" cellspacing="5" style="width:100%; vertical-align:top; background:#f5faff; background:transparent;"

[[File:RASPIBOfinale.png|left|130px|link=http://www.raspibo.org]]
[[File:Help-3.png|right|48px]]
= Chi siamo =

'''''RaspiBO''''' è un gruppo informale di appassionati di elettronica ed informatica libera della zona di '''Bologna''' (ma non solo).

Nato ad inizio 2013 per iniziativa del professor [http://www.cs.unibo.it/~renzo/ Renzo Davoli], [http://www.raccattaraee.net/ RaccattaRAEE], [http://erlug.linux.it/ ERLUG] e [http://www.bfsf.it/ BFSF], il gruppo si muove ora autonomamente, incontrandosi con frequenza almeno bimensile per serate dedicate allo sviluppo ed alla presentazione di nuove idee.<br />
Chiamiamo questi incontri '''''il non-corso''''', perché non vogliono essere delle semplici lezioni frontali, ma un momento di scambio di opinioni ed esperienze.

Le nostre competenze sono molto varie; '''informatica''', '''elettronica''', '''meccanica''', '''arti''' e mestieri vari: qualcuno è un esperto nel proprio campo, alcuni sono alle prime armi, ma tutti hanno tanta voglia di mettere a disposizione la propria esperienza.<br />
Potete definirci '''makers'''; quello che più conta per noi resta comunque '''l'imparare''' sempre qualcosa di nuovo ed il '''far circolare la conoscenza''' coinvolgendo quante più persone possibile.

Se preferisci abbiamo raccolto qualche informazione [http://www.raspibo.org/wiki/index.php/Chi_siamo in questa pagina].

[[File:Audio-card-3.png|right|48px]]

= Gli incontri del non-corso ed i gruppi di lavoro =

'''Gratuiti e aperti a tutti''', chiunque voglia passare a trovarci anche solo per fare due chiacchiere su elettronica, informatica e meccanica (tutto rigorosamente in ''salsa libera'') è il benvenuto!

Lo spirito dei nostri incontri è espresso nelle nostre [[Linee guida per gli incontri|linee guida]].<br />
Oltre a tanta improvvisazione, di norma alcuni di noi si organizzano in '''tavoli''' per proseguire su specifici progetti; appena possibile, il [[I gruppi di lavoro del non-corso|lavoro svolto dai singoli gruppi]] viene presentato e documentato a beneficio di tutti.

[[File:Apps-system-users-icon.png|right|48px]]

= Serate a tema =

Occasionalmente RaspiBO organizza serate per sviluppare un tema specifico, generalmente invitiamo uno o più ospiti per introdurre temi di interesse comune e condividere esperienze. [http://www.raspibo.org/wiki/index.php?title=Categoria:Serate_a_tema Serate a tema]

[[File:Books-1-icon.png|right|48px]]

= Dalla teoria alla pratica =

Se vuoi puoi iniziare con l'[[1-_Elettronica_di_Base|elettronica]] oppure scoprire come configurare [[Raspberry Pi]] per iniziare i primi test.

Se sei già pratico o se vuoi capire come utilizzare Raspberry Pi puoi visualizzare un elenco di [[6- Applicazioni di Raspberry PI|applicazioni]] che abbiamo già testato e documentato.

Tutte queste informazioni le trovi nella sezione [[Documentazione|Documentazione]] .

Sono inoltre disponibili [[Archivio dei Lucidi|lucidi e registrazioni]] di alcune lezioni frontali.

[[File:User-group-new-2.png|link=http://social.raspibo.org|right|48px]]

Con calma stiamo anche raccogliendo [[SanboxManuali|qui]] link a documentazione, pinout e tutto quanto serve avere sottomano quando si sperimenta.

= la mailing list =

Il nostro principale strumento di comunicazione è la '''[http://liste.raspibo.org/wws/subscribe/agora mailing list agora]''', i cui archivi sono [http://liste.raspibo.org/wws/arc/agora consultabili da qui].

Se invece preferite ricevere periodicamente nostre notizie via mail, potete [http://liste.raspibo.org/wws/subscribe/newsletter iscrivervi alla newsletter].

[[File:Strumenti.png|link=http://social.raspibo.org|right|48px]]

= Strumenti per la collaborazione =

Se vi piace chattare o volete una info al volo vi suggeriamo di utilizzare il canale #raspibo sul server freenode.net anche in [https://webchat.freenode.net/?channels=raspibo&uio=d4 webchat].

Alcuni software sviluppati per i nostri progetti li appoggiamo sul nostro [https://github.com/raspibo/ archivio github].

= Un pochino di storia =
[http://www.raspibo.org/wiki/index.php/Chi_siamo Un piccolo riassunto]

|}

|}



{| id="table-footer" style="margin-top:10px; background:none;"
| style="width:35%; border:1px solid #a7d7f9; background:#f5faff; vertical-align:top; padding: 5px 10px 10px 8px; -moz-border-radius: 10px; -webkit-border-radius: 10px; border-radius:10px;" |

{| id="table-footer-left" cellpadding="2" cellspacing="5" style="width:100%; vertical-align:top; background:#f5faff; background:transparent;"

[[File:Emblem-what.png|right|48px]]

= Help! =

Vuoi modificare una pagina di questo wiki ma non ci riesci? Assicurati di aver letto le [[Qui|istruzioni]] per sconfiggere il nostro potente sistema anti-bot. :-)

|}


| style="border:5px solid transparent;" |


| style="background:white; width:65%; border:1px solid #a7d7f9; vertical-align:top; color:#000; padding: 5px 10px 10px 8px; -moz-border-radius: 10px; -webkit-border-radius: 10px; border-radius:10px;" |
{| id="table-footer-right" cellpadding="2" cellspacing="5" style="width:100%; vertical-align:top; background:transparent;"

= Ringraziamenti =

[[File:Stemma Comune Casalecchio.png|70px|right]]

Si ringrazia il Centro Sociale Croce ed il [http://www.comune.casalecchio.bo.it Comune di Casalecchio di Reno] .

|}

|}

Prossimi appuntamenti

2020-03-31T10:38:57Z

Oloturia:

'''Chiusura temporanea del Centro Sociale Croce di Casalecchio di Reno.'''

Come comunicato dalla direzione vi segnaliamo che da Domenica 23.02.2020 fino alle ore 24,00 di Domenica 01.03.2020, il Centro Sociale Croce di Casalecchio di Reno sarà chiuso e saranno annullati a data da destinarsi tutti gli eventi programmati.

A presto

Covid19

2020-03-31T10:37:46Z

Oloturia:

'''Qui trovi tutti i progetti relativi al Corona Virus: {{Special:PrefixIndex/Covid19/ |hideredirects=1}}'''

[https://pad.riseup.net/p/COVID-19_RaspiBO_Links-keep Link non revisionati che sono passati nelle mailing list e nelle chat.]

OttoBot

2019-07-05T17:49:49Z

Oloturia: /* Aggiungere le opzioni alla IDE di Arduino */

OttoBot è il risultato di un tentativo di usare un [http://www.atmel.com/devices/atmega8.aspx ATmega8] al posto di una board Arduino.

= Le specifiche tecniche =
L'ATmega8, prodotto da Atmel, è piuttosto modesto.

* Ha 8KB di memoria flash. Se usate il bootloader di Arduino allora ve ne rimarranno solo 7.
* Il clock è massimo 16Mhz usando un risuonatore esterno. Quello interno va a 8Mhz (ma vi risparmiate un bel po' di circuiteria). Per usare il risuonatore interno occorre cambiare un fuse.
* 23 pin programmabili.
* 2 interrupt.
* Porte SPI, I²C e seriale (ma non è possibile usare seriali software, presenti nella libreria di Arduino).
* Costa una bazzecola.

Per essere acceso ha bisogno da 2,7 a 5,5 Volt.
Il prezzo oscilla attorno all'euro.
[[Category:Progetti]]

= Prime versioni =

[[File:8bot.jpg]]

Come potete vedere, la dimensione è proprio mini. Si comanda tramite bluetooth. Ruote e chassis sono stampate 3d.

[[File:8bots.JPG]]

Da sinistra a destra, l'evoluzione di 8bot!

= Modificare l'ATmega8 affinché sembri un Arduino =

Per approfondire questo argomento leggete anche [[Programmazione dei microcontrollori]].

Per ottenere questo occorre fare tre cose:
* Trovare un programmatore (potete usare la [http://www.instructables.com/id/Simplest-AVR-Parallel-port-programmer/ porta parallela] oppure acquistarne uno, ma anche un normalissimo Arduino può essere usato come programmatore)
* Settare i fuses
* Caricare il bootloader
* Aggiungere l'ATmega8 nel file boards.txt di Arduino

Una volta fatti questi passi, potrete usare l'IDE come per qualsiasi altra board.

Di guide su come usare i programmatori ne trovate a bizzeffe su internet, noi ci concentreremo sull'utilizzo di Arduino come ISP, che è la procedura che ho usato io.

== Arduino as ISP ==

Negli sketch di esempio nella IDE di Arduino c'è "Arduino as ISP" (In-System Programmer). Caricatelo su un Arduino di vostra scelta con l'accortezza di controllare i pin da usare: sui Mega sono diversi. Dovrete usare la porta SPI e in genere avete: 10 reset, 11 MOSI, 12 MISO e 13 clock (SCK). Sui Mega le porte sono rispettivamente 53, 51, 50 e 52. Trovate tutto nei commenti dello sketch.
Altri pin, opzionali, sono il 9 (heartbeat, mostra se il programma sta girando), 8 (error, si accende se c'è un problema), 7 (programming, si accende durante le comunicazioni).

La porta SPI va così collegata, MISO con MISO, MOSI con MOSI, SCK con SCK e reset con reset. Il datasheet lo trovate qui [http://www.atmel.com/Images/Atmel-2486-8-bit-AVR-microcontroller-ATmega8_L_datasheet.pdf]

[[File:Atmega8 arduinopinout.png]]

I pin che vedete sono quelli come da IDE di Arduino. Se lo programmate con altri sistemi (come Eclipse) i riferimenti possono essere diversi.
Se il vostro ATmega8 è settato per avere un risuonatore esterno, dovrete collegarlo con un pin XTAL1 e l'altro su XTAL2. Entrambi i pin XTAL1 e XTAL2 vanno poi collegati a terra con un condensatore da 22 picofarad. Ne avrete bisogno se volete raggiungere frequenze superiori agli 8 Mhz o se avete bisogno di maggiore stabilità (il risuonatore interno non è molto preciso). Per contro, il risuonatore interno non ha bisogno di collegare nulla. Per approfondire guardate questa guida [http://kskpages.weebly.com/clock-settings.html]

== avrdude ==

Per interagire con l'ATmega8 dovrete usare avrdude, questa è una riga di esempio:
avrdude -p m8 -c arduino -P /dev/ttyACM1 -U flash:w:{bootloader}.hex -U hfuse:w:0xd9:m -U lfuse:w:0xe3:m -b 19200

Per saperne di più [http://www.nongnu.org/avrdude/user-manual/avrdude_4.html]

-p m8
dice che abbiamo a che fare con un ATmega8

-c arduino
segnala che stiamo usando un Arduino come programmatore, nelle nuove versioni della IDE, con il nuovo sketch ArduinoISP probabilmente il protocollo da usare è stk500v1

-P /dev/(porta)
è la porta dove avete collegato il programmatore, di solito per gli Arduino è ttyACMx o ttyUSBx; per conoscerla ci sono due modi: guardare nella IDE di Arduino le porte disponibili o collegare l'Arduino e guardare gli ultimi messaggi in dmesg

-U flash:w:{bootloader}.hex
scrive il bootloader, vedi sotto

-U hfuse:w:0xd9:m -U lfuse:w:0xe3:m
modifica i fuse, vedi sotto

-b 19200
la velocità di comunicazione in baud

== Caricare il bootloader ==

Se volete usarlo come Arduino dovreste caricare il bootloader. Potete farne anche a meno e risparmiare 1Kb (su 8, non è poco). In teoria potreste farne a meno e continuare a caricare gli sketch sull'ATmega8 l'Arduino come programmatore. Fatto sta che l'ho caricato una volta e non ho mai provato a toglierlo (del resto: if ain't broke, don't fix it). I bootloader li trovate in {cartella di Arduino}/hardware/arduino/avr/bootloaders. Se non li avete li trovate qua [https://github.com/arduino/Arduino/tree/master/hardware/arduino/avr/bootloaders]

== Settare i fuse ==

Molte opzioni dell'ATmega8 sono settabili tramite dei fuse. I fuse sono dei bit su una memoria EEPROM che dicono al microcontrollore come deve comportarsi. Tramite i fuses è possibile settare il clock, se usare un oscillatore esterno o interno, quanto deve aspettare durante il boot per una nuova programmazione, etc.
Qui trovate due calcolatori di fuse, questo è più semplice da usare [https://elektronik-kompendium.de/public/arnerossius/programme/web/avrfuse/ avrfuse] questo è più completo [http://www.engbedded.com/fusecalc/ Engbedded AVR Fuse Calculator].

== Aggiungere le opzioni alla IDE di Arduino ==

Se siete affezionati alla IDE dovrete aggiungere al menu delle board l'ATmega8.

In teoria, nel menu Tools/boards, c'è già "Arduino NG or older" che ha, fra le varie opzioni, anche la possibilità di usare l'ATmega8, ma io ho avuto una serie di problemi a usarla e alla fine non ho provato a capire perché non funzionasse.

Andate in {cartella di Arduino}/hardware/arduino/avr e aprite il file boards.txt (se avete paura di fare dei danni, fate una copia di questo file prima, per precauzione).

Per aggiungere l'ATmega8 basta aggiungere queste opzioni alla fine [https://github.com/chuckb/atmega/blob/master/atmega/avr/boards.txt].

''In alternativa''

Copiate i files dal repository https://github.com/chuckb/atmega, cartellle incluse, nella directory hardware del programma arduino, per esempio (nel mio caso):
<pre style="color:blue;overflow:auto">
ls ~/arduino-sketches/hardware/atmega/avr/
</pre>

oppure:
<pre style="color:blue;overflow:auto">
ls /opt/arduino-1.8.7/hardware/atmega/avr/
</pre>

<pre style="color:green;overflow:auto">
boards.txt platform.txt
</pre>

Se caricate uno sketch sul microcontrollore con un clock sbagliato accadranno risultati imprevedibili, ad es. caricate dalla IDE usando ATmega8 a 4Mhz con i fuses settati in modo che vada a 8Mhz scoprirete che tutto andrà al doppio della velocità.
I secondi diventano mezzi secondi, 9600 baud diventano 19200 e così via. Non una gran cosa se state cercando di programmare, però può sfuggirvi perché non segnala nessun errore.

Una volta editato boards.txt riavviate la IDE se l'avevate aperta e vedrete comparire nel menu Tools/board una nuova voce, quella dell'ATmega8.

== Caricare uno sketch ==

Collegate il programmatore (nei nostri esempi, l'Arduino) all'ATmega8 alla seriale (se avete caricato il bootloader) o alla SPI, collegate il reset (di default su Arduino as ISP è il pin 10), il +5v e la terra, andate sotto Sketch e usate "Upload Using Programmer". Alternativamente potete cliccare shift+pulsante del caricamento dello sketch. Se tutto è andato come dovrebbe vedrete lampeggiare i LED della seriale dell'Arduino per qualche secondo fino a che l'IDE non ci comunicherà "done".
Se invece non volete usare la IDE, potete compilare il vostro sketch con avr-gcc e uploadarlo direttamente con avrdude (ma di questo non tratteremo qui).

Problemi più frequenti: cavetti non collegati bene, cavetti invertiti, alimentazione non sufficiente, oscillatore esterno previsto ma mancante.

== Altri metodi ==

Potete usare, ad esempio, la SPI del Raspberry Pi, guardate la pagina [[Programmazione_dei_microcontrollori]].

= Lo schema elettrico =

È estremamente banale. Collegate le batterie a modulo Bluetooth, integrato e motori, in parallelo, collegate i fili del segnale dei servo a un pin libero dell'ATmega8, collegate RX dell'integrato a TX del modulo Bluetooth. Se volete un feedback dall'integrato allora collegate anche il TX dell'integrato al RX del modulo Bluetooth.

[[File:8botschema.png]]

In sintesi:
* il + delle batterie va collegato a: vcc del modulo Bluetooth, vcc dell'ATmega8, + del servo 1 e 2
* il - delle batterie va collegato a: gnd del modulo Bluetooth, due gnd dell'ATmega8, - del servo 1 e 2
* TX del modulo Bluetooth va collegato a RX dell'ATmega8
* RX del modulo Bluetooth va collegato a TX dell'ATmega8
* i segnali dei servi vanno collegati a due pin liberi (nel nostro caso 14 e 15 ma potete benissimo sceglierne degli altri)

= Lo sketch =

Lo trovate sul repository:
[https://gitlab.com/oloturia/8bot]

Vediamo un po' i punti più strani.

#include <Servo.h>
#include <EEPROM.h>

Servo dx_servo;
Servo sx_servo;

const int dx_pin = 8;
const int sx_pin = 9;
int fd_spd_dx = 180; //initial values
int bk_spd_dx = 0; //180 is full forward, 0 full backward
int fd_spd_sx = 0; //stop is somewhere in the middle
int bk_spd_sx = 180; //but the motors keep running

Per far funzionare il nostro robottino servirà la libreria Servo. La EEPROM ci servirà per mantenere la calibrazione da spento. Ci sono due costanti, i pin a cui sono collegati il segnale dei servi, e i valori che passeremo al metodo write degli oggetti dx_servo e sx_servo. Nei servo continui 0 è antiorario e 180 orario, lo stato fermo è più o meno 90. In questo caso però li staccheremo con detach così da non mantenerli in tensione. Se il vostro progetto non ha bisogno che il servo faccia resistenza (ad es. deve tenere un peso) allora è meglio staccarlo. Non è solo una questione di risparmio energetico: i piccoli servo e quelli di scarsa qualità quando sono in tensione tendono a scaldare.
Le quattro variabili sono rispettivamente il valore avanti e indietro del motore a destra e il valore avanti e indietro del motore a sinistra.

void setup() {
Serial.begin(9600);
Serial.println("READY");
if (EEPROM.read(4) == 1) {
fd_spd_dx = EEPROM.read(0);//reserve 4 bytes
bk_spd_dx = EEPROM.read(1);//for saved calibration
fd_spd_sx = EEPROM.read(2);
bk_spd_sx = EEPROM.read(3);
}
}

Accende la seriale e si legge la EEPROM. La memoria non scritta ha come valore 255 quindi serve un quinto elemento che comunichi se la calibrazione è stata fatta o meno. Scrivere e aggiornare la EEPROM è facilissimo. Vi consiglio di leggere la guida ufficiale [https://www.arduino.cc/en/Reference/EEPROM]. Ricordate che l'ATmega8 ha 512 bytes a disposizione nella EEPROM.

void loop() {
if(Serial.available()){
char command = Serial.read(); //every command is a char
if (command == 's') { //it is possible to write to the bot
turnOnServo(); //using a keyboard
dx_servo.write(fd_spd_dx);
sx_servo.write(fd_spd_sx);
} else if (command == 'd') {
[...]

Ogni comando ricevuto dalla seriale è un char. Si potrebbe eventualmente mandare un byte, ma così è più comodo soprattutto quando ancora non avevo pronta la app e dovevo pilotare il piccolo bot con la tastiera. Si può ancora fare: i tasti sono wasd. Sulla funzione turnOnServo() torneremo dopo.

[...]
} else if (command == 'h') {
if (fd_spd_dx > 90) {
fd_spd_dx --;
}
[...]

Altri comandi servono per la calibrazione. Purtroppo nella app la calibrazione è ancora molto confusionaria. Ogni variabile può diventare da 0 a 90 e da 91 a 180.

[...]
} else if (command == 'z') { //save calibration into eeprom
EEPROM.update(0,fd_spd_dx);
EEPROM.update(1,bk_spd_dx);
EEPROM.update(2,fd_spd_sx);
EEPROM.update(3,bk_spd_sx);
EEPROM.update(4,1);
Serial.println("OK");
} else {
stopServo(); //if the serial is empty, stop the motors
}

Infine, ecco dove la EEPROM viene scritta, incluso l'indirizzo 4 che diventa 1 e segnala al prossimo riavvio di leggersi i valori che avevamo salvato. Se non arriva nessun comando i servo vengono staccati.

void turnOnServo() {
dx_servo.attach(dx_pin);
sx_servo.attach(sx_pin);
}

void stopServo() {
dx_servo.detach();
sx_servo.detach();
}

Ogni volta che arriva un comando vengono riattaccati. In questo modo non rimarranno sotto tensione.

= Il bluetooth =

Il collegamento fra l'Ottobot e il vostro smartphone o il vostro computer avverrà tramite il modulo HC-05 o HC-06. Il modulo è molto semplice da usare: ha una porta seriale fisica dove legge e scrive tutto ciò che arriva via il servizio di porta seriale via Bluetooth. Nel nostro caso sarà attaccato direttamente ai pin RX e TX del nostro ATmega8 e farà come da ponte fra il nostro dispositivo e il microcontrollore. Potete leggere più informazioni su come giocare con questo tipo di moduli nella pagina [[HC-05 e HC-06]].

= L'app =

Potete scaricarla, guardarla e modificarla all'indirizzo di App Inventor (serve account Google) [http://ai2.appinventor.mit.edu/?locale=en&galleryId=5162309564235776 qua].

L'app è stata scritta con il MIT App Inventor 2. È un tool molto potente utile per chi, come me, è ancora fermo a cercare di fare un "Hello World" decente su Android. Non è la soluzione più efficace, ma nell'attesa di imparare qualcosa di migliore, è la più semplice.

L'App Inventor è basato sul popolare linguaggio educativo Scratch. Permette di inserire pulsanti, grafica e di interagire con i sensori e, nel nostro caso, con dispositivi Bluetooth. Permette di collegarsi a un dispositivo Android (anche emulato) per fare dei test in real-time e fare correzioni al volo. Quando avrete finito potrete creare un .apk da installare così non avrete più bisogno dell'App Inventor per usarla.

Tutte le informazioni su come utilizzarlo le trovate nel sito ufficiale [http://appinventor.mit.edu/explore/ai2/setup.html].

Nel repository c'è il sorgente in formato .aia, che potete caricare sull'App Inventor con Import.

Per prima cosa ho creato, nello Screen 1, una lista che si carica con la lista dei dispositivi Bluetooth che sono nel range del nostro tablet o telefono. Nella schermata c'è solo una lista e un componente "Bluetooth Client" chiamato BluetoothClient1.

[[File:Initbt.png]]

AfterPicking, ovvero dopo aver scelto un dispositivo, andrà nello screen "Controls" portandosi dietro il nome del dispositivo a cui ci vogliamo connettere.

Andiamo ora nella schermata "Controls".

[[File:Controls_8bot.png]]

Ci sono i pulsanti per le direzioni, un pulsante per connettersi a un altro dispositivo (che non fa altro che tornare a Screen1), e i pulsanti per la taratura (ancora in beta). Anche qui c'è BluetoothClient1. Appena arriva in questa schermata l'app si fermerà per permettere di fare l'accoppiamento tramite Bluetooth. Il pin è di solito 1234.

[[File:Initcontr.png]]

Se non riesce a connettersi o se clicchiamo "Connect" tornerà nella schermata di selezione precedente.

[[File:Controlscomm.png]]

I controlli sono molto semplici: ogni tasto invia un carattere. Quando viene rilasciato manda un carattere che spegne i servo. Non è ancora perfetto perché se perde la connessione i motori rimangono accesi, in futuro questo problema sarà corretto.

[[File:Trim8bot.png]]

Infine il codice per la calibrazione. A seconda se il robot sta andando avanti oppure indietro saranno calibrati i valori che vengono usati per muovere i motori. Purtroppo questa parte non è ancora scritta in modo efficace (ad es. il motore che va avanti in senso antiorario va più veloce con un valore INFERIORE, quindi per farlo andare più veloce occorre premere il tasto MENO). Quando la calibrazione è soddisfacente, con il tasto "Write" la si memorizza nella EEPROM dell'ATmega8.

= I motori =

L'8bot ha bisogno di due servo motori 9g continui, detti anche servo a 360°. Se volete risparmiare ulteriormente potete acquistare dei normalissimi servo a 180° e fare qualche modifica per trasformarli in 360°.
Per effettuare la modifica seguite [[Modifica_servo_rc_per_rotazione_continua|questa guida]].

= Lo chassis =
Tutti gli .stl di 8bot li trovate su git [https://gitlab.com/oloturia/8bot]

== Le ruote ==
Per le ruote ci sono due modelli, uno è della dimensione delle gomme delle mini4wd Tamiya[https://gitlab.com/oloturia/8bot/blob/master/wheel-mini4wd.stl]:

[[File:8bot4wd.png]]

mentre l'altro è della dimensione di un o-ring[https://gitlab.com/oloturia/8bot/blob/master/wheel0ring.stl]:

[[File:8botoring.png]]

entrambe si incastrano sul pignone del servo senza bisogno di viti o altro (ma se volete metterne una, male non fa).

== Il telaio ==
Il telaio è una piccola piattaforma con due fessure per inserire un'aletta del servi e un foro per la casterball. Recentemente ho aggiunto altre due alette per tenere fermo il portabatterie[https://gitlab.com/oloturia/8bot/blob/master/body.stl].

[[File:Chass.png]]

= Corso di costruzione Ottobot =
Nell'autunno 2016 a Raspibo un gruppo di makers si e' riunito specificamente per costruire Ottobot e programmarli sotto la guida paziente di Oloturia, creatore del progetto.

== Materiale ==
Il materiale e' stato procurato dallo stesso Oloturia da vari fornitori durante l'estate con un occhio particolare ai costi per permettera tutti di realizzare un piccolo robot didattico.

Alcune parti progettate appositamente, sono state stampate in 3D.

Ad ogni partecipante del corso e' stato fornito un kit, oltre a questo ogni partecipante ha portato un po' di attrezzi ed un pc.

[[File:Ottobot kit.jpg|600px|thumb|center|Il kit completo del corso ottobot]]

== Preparazione dei motori ==
Nel kit i due servo possono essere sia a rotazione continua quindi gia' pronti oppure standard.

Per i motori standard e' neccessario procedere ad una modifica vedi [[Modifica_servo_rc_per_rotazione_continua]]

== Assemblaggio del robot ==

{|style="margin-top:2px; background:none;align:center;width:100%;border:1px solid red;-moz-border-radius: 10px; -webkit-border-radius: 10px; border-radius:10px;"
|[[File:Ottobot assemblaggio 10.jpg|400px|thumb|left|Montare le ruote sul microservo modificato per rotazione continua]]
|Le ruote vanno montate sull'asse con una vite che si trova nel sacchetto degli accessori del servo. Il tutto va poi incastrato sulla base. Se la stampa e' perfetta i motori si incastrano perfettamete sulla base altrimenti ci si puo' aiutare con colla, viti o nastro biadesivo.
|
|}

{|style="margin-top:2px; background:none;align:center;width:100%;border:1px solid red;-moz-border-radius: 10px; -webkit-border-radius: 10px; border-radius:10px;"
|[[File:Ottobot assemblaggio 20.jpg|400px|thumb|left|Fissare la ball caster]]
|Come terzo appoggio utilizziamo una ballcaster che consente liberta' di movimento e di sterzata. Inserire il pezzo nel foro centrale e fissarlo con tre viti, oppure colla.
|
|}

Gruppo Meteo/HowTo/StimaVersione2

2019-04-09T19:31:35Z

Oloturia: /* Upload del firmware */

= How To =

== Guida pubblicata su ElettronicaIn ==
Gli articoli pubblicati nel 2016:
# [http://liste.raspibo.org/wws/d_read/meteo/elettronicain/prima_puntata.pdf Prima puntata]
# [http://liste.raspibo.org/wws/d_read/meteo/elettronicain/seconda_puntata.pdf Seconda puntata]
# [http://liste.raspibo.org/wws/d_read/meteo/elettronicain/terza_puntata.pdf Terza puntata]

La guida aggiornata su WIKI la puoi trovare qui divisa in tre sezioni:

# http://bfsf.it/wiki/FuturaStima1
# http://bfsf.it/wiki/FuturaStima2
# http://bfsf.it/wiki/FuturaStima3

== HowTo per Stima-wifi ==

[[File:stima_wifi.jpg|none|400px|thumb|left|Stima wifi con Honeywell HPM e sensore Temperatura e Umidità]] <br clear=all>

=== Elenco materiali ===

* [https://www.homotix.it/vendita/wemos/wemos-mini-v300 Wemos D1 mini V3]
* [https://www.homotix.it/vendita/wemos/oled-shield-v110-for-wemos-mini OLED Shield V2.0.0 for Wemos D1 mini]
* [https://www.homotix.it/vendita/wemos-shield-alimentazione/power-shield Wemos DC Power Shield V1.1.0]
* [https://www.homotix.it/vendita/wemos-shield-prototipazione-cavi/connettori connettori] (quando necessari)

sensore polveri:
* [http://www.plantower.com/en/content/?108.html Plantower pms5003]

in alternativa:
* [https://it.rs-online.com/web/p/sensori-di-luce-e-colore/1454279/ Honeywell HPM-115S0]
* [https://it.rs-online.com/web/p/wire-to-board-cable-assemblies/1250750/ Cavo connessione PicoBlade Molex 8 vie]

* [https://www.homotix.it/vendita/sensori-polveri-sottili/sensore-polveri-sottili-sds011 SDS011]

NOTA BENE

In particolare il sensore Honeywell HPMA richiede una alimentazione a 5V stabilizzata e molto precisa

Alimentazione per distanze fino a circa 50m. dall'alimentazione di rete a 220V:
* [https://www.homotix.it/vendita/alimentatori/alimentatore-12v-2a Alimentatore-12v-2a]
* cavo bipolare della lunghezza opportuna

=== Configurazioni sul server ===

==== Registrazione ====
[http://rmap.cc/registrazione/register/ Registrasi] o fare [http://rmap.cc/registrazione/login] login sul server.
==== Configurazione stazione ====
Registrare una nuova stazione sul [http://rmap.cc/insertdata/newstation server]; dopo aver selezionato le coordinate utilizzando l'indirizzo o selezionandole dalla mappa inserire il nome stazione ( nome consigliato come predefinito "stimaesp")
e il modello stazione che sarà
* "airquality_sds" se è collegato solo il sensore delle polveri SDS011.
* "airquality_hpm" se è collegato solo il sensore delle polveri Honeywell HPM
* "airquality_pms" se è collegato solo il sensore delle polveri Plantower pms5003
* "stima_thd" se sono collegati il sensore delle polveri Honeywell HPM e il modulo stima_th
* "stima_thdm" se sono collegati il sensore delle polveri Honeywell HPM, il modulo stima_th, il modulo stima_gas

=== Attivazione stazione ===
Accendere la stazione collegandola tramite l'apposito alimentatore a una alimentazione USB.

==== Se si ha il display ====
Tenendo premuto il pulsante A premere il pulsante Reset.
Dovranno apparire le seguenti scritte:
Clean FS
Reset wifi configuration

Con un PC o uno smathphone collegarsi al WIFI con ssed "STIMA-config" e password "bellastima" come indicato sul display.

Una volta attivata la connessione dovrà comparire una pagina di configurazione intitolata "STIMA-config".

Se questo non avviene automaticamente puntare il browser all'indirizzo http://192.168.4.1/

Selezionare la prima voce "Configure WiFi".

Selezionare dall'elenco l'ssed della rete WiFi di accesso alla rete che dovrà essere utilizzata dalla stazione e inserire nell'apposita casella la relativa password di accesso se necessaria.
Nella casella "rmap user" inserire il nome utente utilizzato nella registrazione sul server e nella casella "rmap password".

Lasciare "stimaesp" come nome stazione se non è sttao precedentemente personalizzato.

premere il tasto "save" per salvare.

Se si ottiene la pagina con la scritta "Credentials Saved" la procedura ha avuto successo.

A questo punto sul display dopo la pagina con la scritta "Starting up!" e la versione del firmware dovrà comparire la scritta "WIFI OK".

Se questo non avviene rieseguire le istruzioni di questa sezione.

==== Se non si ha il display ====
Con un filo connettere il pin 7 a massa e premere il pulsante Reset e attendere 5 secondi prima di scollegare il filo dal pin 7.

Con un PC o uno smathphone collegarsi al WIFI con ssed "STIMA-config" e password "bellastima" come indicato sul display.

Una volta attivata la connessione dovrà comparire una pagina di configurazione intitolata "STIMA-config".

Se questo non avviene automaticamente puntare il browser all'indirizzo http://192.168.4.1/

Selezionare la prima voce "Configure WiFi".

Selezionare dall'elenco l'ssed della rete WiFi di accesso alla rete che dovrà essere utilizzata dalla stazione e inserire nell'apposita casella la relativa password di accesso se necessaria.

Nella casella "rmap user" inserire il nome utente utilizzato nella registrazione sul server e nella casella "rmap password".

Lasciare "stimaesp" come nome stazione se non è sttao precedentemente personalizzato.

premere il tasto "save" per salvare.

Se entro 60 secondi si accenderà un led blu per una decina di secondi tutto è andato a buon fine.

Se questo non avviene rieseguire le istruzioni di questa sezione.

=== Legenda segnalazioni tramite LED blu onboard ===

* riavvio: 3 impulsi luminosi di 1 secondo
* tentativo aggiornamento firmware in corso: led lampeggiante a 1Hz
* risultato aggiornamento firmware:
** nessun aggiornamento disponibile: 1 impulso luminosi di 1 secondo
** aggiornamento firmware fallito: 2 impulsi luminosi di 1 secondo
** firmware aggiornato: 3 impulsi luminosi di 1 secondo
* in attesa di configurazione: led lampeggiante a 1Hz per tutto il periodo di configurazione
* configurazione remota fallita: led lampeggiante a 1Hz per 5 secondi
* connect MQTT fallita/errore pubblicazione: impulso medio a 1Hz per 5 secondi
* sensore assente o rotto/errore comunicazione: impulso lungo a 1Hz per 5 secondi
* dato mancante: un impulso luminoso di 1 secondo a 2Hz

Un corretto funzionamento della stazione viene evidenziato dal led blu che si accende per circa 5 secondi ogni 60 secondi.

=== Visualizzazione dei dati ===
[http://rmapv.rmap.cc/accounts/profile/ Dati stazione] <br clear=all>

=== Cancellazione delle configurazioni e reset alle condizioni di "fabbrica" ===
==== Se si ha il display ====
Tenendo premuto il pulsante A premere il pulsante Reset.
Dovranno apparire le seguenti scritte:
Clean FS
Reset wifi configuration

Potranno essere necessarie alcune decine di secondi prima che queste scritte scompaiano e si possa procedere.

==== Se non si ha il display ====
Con un filo connettere il pin 7 a massa e premere il pulsante Reset e attendere 5 secondi prima di scollegare il filo dal pin 7 e attendere ulteriori 60 secondi.

=== Assemblaggio ===
Infilare i connettori con i pin lunghi e saldarli sul modulo Wemos D1 mini.
Se si dispone di un display Wemos v2 impilarlo sul modulo Wemos D1 mini.
AggiungereWemos il DC Power Shield

==== opzione display oled ====
Se si possiede la versione v2.0.0 sul circuito stampato dal lato opposto del display interrompere la piazzola sulla destra indicata con D3 (pulsante A, piazzola indicata con la freccia) e della stessa colonna di piazzole saldare quella indicata con D7.
Se si possiede la versione v1.x (senza pulsanti A e B) è necessario realizzare una saldatura dove previsto (sul retro del circuito stampato rispetto al display) selezionando l'indirizzo I2C corrispondente a 0x3C.

==== opzione Plantower PMS5003 ====
numbering pins from left to right with "plantower" stamps on the floor

Effettuare i seguenti collegamenti tra Wemos e [https://github.com/r-map/rmap/blob/master/arduino/sketchbook/libraries/pms/doc/pms5003-manual_v2-3.pdf PMS5003]:
Connettere:
{| class="wikitable"
! Wemos D1 mini
!
! PMS5003
|-
| GND || <-> || PIN 2
|-
| 5V || <-> || PIN 1
|-
| D5 || <-> || PIN 5
|-
| D6 || <-> || PIN 4
|}

eventualmente connettere anche il PIN 6 (reset) e PIN 3 (SET) (DA FARE)

==== opzione SDS011 ====
Effettuare i seguenti collegamenti tra Wemos e SDS011:
Connettere:
{| class="wikitable"
! Wemos D1 mini
!
! SDS011
|-
| GND || <-> || GND
|-
| 5V || <-> || 5V
|-
| D5 || <-> || TXD
|-
| D6 || <-> || RXD
|}

==== opzione Honeywell HPM ====
Effettuare i seguenti collegamenti tra Wemos e Honeywell hpm:
[[File:Honeywell_hpm_pinout.png|300px|thumb|left|Honeywell pinout]] <br clear=all>
Connettere:
{| class="wikitable"
! Wemos D1 mini
!
! Honeywell HPM
|-
| GND || <-> || PIN 8 GND
|-
| 5V || <-> || PIN 2 5V
|-
| D5 || <-> || PIN 6 TX
|-
| D6 || <-> || PIN 7 RX
|}

[[File:assemblaggioinscatolaelettrica.jpg|400px|thumb|left|Assemblaggio moduli in scatola elettrica]] <br clear=all>

[[File:assemblaggioinscatolaelettricaflusso.jpg|400px|thumb|left|Assemblaggio materiale espanso per flusso aria]] <br clear=all>

[[File:presearia.jpg|400px|thumb|left|Messa in opera con canaletta angolo a 90 gradi per flusso aria in/out antipioggia]] <br clear=all>

[[File:filtroinsetti.jpg|400px|thumb|left|Uso di rete zanzariera per filtro contro gli insetti]] <br clear=all>

==== Opzione modulo Stima-th ====

[[File:sensoretemperaturaeumidita.jpg|400px|thumb|left|Sensore temperatura e umidità all'interno di apposito schermo per le radiazioni]] <br clear=all>

* ponticellare (con un resistore) A1-centrale con A1-
* ponticellare (con un resistore) A0-centrale con A0+

Una volta saldati i terminali dei cavi e protetti con nastro autoagglomerante è importante preservare le connessioni dalla corrosione degli agenti atmosferici e consigliamo uno strato di silicone protettivo spray del tipo Electrolube DCR200H; solo una volta asciugato lo strato di vernice protettiva rimuovere la protezione adesiva del sensore HIH

Connettere:
{| class="wikitable"
! Wemos D1 mini
!
! modulo Stima-th
|-
| GND || <-> || GND
|-
| 3V3 || <-> || VCC
|-
| D1 || <-> || SCL
|-
| D2 || <-> || SDA
|}

E' necessario fare una modifica al modulo wemos per aggiungere un pin di collegamento a GND.
Saldare a 45 gradi di inclinazione un pin aggiuntivo per connettore Dupont a GND come da figura:
[[File:stima_wifi_addpintognd.jpg|300px|thumb|center|Pin aggiunto a GND]] <br clear=all>

==== Opzione modulo Stima-i2c-sdsmics ====

vedi:
http://www.raspibo.org/wiki/index.php?title=Gruppo_Meteo/HowTo#Modulo_Stima-i2c-sdsmics

==== Opzione per alimentazione con cavo di lunghezza superiore a 2m. ====
Tagliare il cavo dell'alimentatore e inserire una piattina bipolare con rame di diametro opportuno ovviamente della lunghezza necessaria.

==== Per caricare il firmware ====

===== Installare il driver USB2Serial =====

====== Windows ======
Per comunicare col Wemos c’è bisogno del driver usb2serial.

====== Linux ======
Nessuna installazione necessaria.

====== MacOS ======
Per Sierra vedere queste instruzioni che sono state testate: https://github.com/adrianmihalko/ch340g-ch34g-ch34x-mac-os-driver

===== Upload del firmware =====

Effettuare il download del firmware da http://rmap.cc/media/firmware/rmap_esp8266.ino.d1_mini_yhbp7E2.bin
e caricarlo sul Wemos dopo averlo connesso tramite cavetto USB.
Per fare questo seguire le istruzioni a:
https://github.com/espressif/esptool
e in particolare:
https://github.com/espressif/esptool#writing-binaries-to-flash

== HowTo per il bando di gara ARPAE 2016 ==

=== Installazione ambiente di sviluppo ===

==== SDK Arduino ====
* Installare arduino 1.8.1 da https://www.arduino.cc/en/Main/Software
* scaricare l'ultima versione del software stima (file stimasketchbookbluetooth) da https://github.com/r-map/rmap/releases
* scompattare il file zip

* aprire l'ide arduino e in file -> impostazioni -> percorso della cartella degli sketch selezionare la cartella sketchbook appena scompattata dal file scaricato
* chiudere e riaprire l'ide

* sezionare in -> strumenti
Scheda: Microduino Core+ (644pa)
Processore: ATmega644pa@16M5V
Porta: (quella disponibile)

* selezionare in -> Sketch -> Verifica e compila

Ora per uplodare il firmware sul microprocessore dovrete collegare tra loro SOLO

* MICRODUINO Core+ ATMEGA644PA
* MICRODUINO Shield USB/TTL

poi selezionate nella IDE di arduino:

* selezionare in -> Sketch -> Carica

Utilizzando MICRODUINO Core+ con ATMEGA 1284 sostituire 1284 a 644 nei passi precedenti.

==== Pacchetto python RMAP ====

Queste istruzioni permettono di installare il pacchetto RMAP scritto in python utile alla configurazione delle stazioni:

mkdir rmap
cd rmap
virtualenv myrmap
source myrmap/bin/activate
pip install rmap

successivamente ogni volta che si vuole eseguire un comando rmap eseguire preventivamente:

cd rmap
source myrmap/bin/activate

=== Modulo Stima-th ===

==== Hardware ====
* ponticellare con un resistore A1-centrale con A1-
* ponticellare con un resistore A0-centrale con A0+

Una volta saldati i terminali dei cavi e protetti con nastro autoagglomerante è importante preservare le connessioni dalla corrosione degli agenti atmosferici e consigliamo uno strato di silicone protettivo spray del tipo Electrolube DCR200H; solo una volta asciugato lo strato di vernice protettiva rimuovere la protezione adesiva del sensore HIH

==== Configurazione ====
Bisogna modificare l'indirizzo i2c del sensore hih.

* Assemblare microduino core+ con microduino FT232RL con Stima-i2c
* Caricare il firmware sensor_config
* connettere:
* Stima-th VCC -> Stima-i2c rl2
* Stima-th GND -> Stima-i2c GND
* Stima-th SDA -> Stima-i2c SDA
* Stima-th SCL -> Stima-i2c SCL

alla porta seriale inviare i comandi:

Sensor to config:
w = i2c-wind
s = i2c-windsonic
t = i2c-th
r = i2c-rain
h = hih humidity sensor

? = help - this page
h
If you want to use Command Mode to setup HIH61xx sensor you MUST use one pin to power the HIH!
If not this will not work!
digit old i2c address for HIH sensor (1-127)
39
digit the pin number for power HIH sensor (1-127)
4
started HIH fo command mode
digit new i2c address for HIH sensor (1-127)
38
Done; switch off

==== Assemblaggio ====

Utilizzare un cavo quadripolare a bassa capacità se possibile schermato da esterno con da un lato connettore rj45 e dall'altro la connssione a Stima-th.

Per questi sensori installati all'esterno è importante preservare le connessioni dalla corrosione degli agenti atmosferici e consigliamo uno strato di silicone protettivo spray del tipo Electrolube DCR200H.

Inserire Stima-th nell'apposito schermo per le radiazioni.

=== Modulo Stima-I2C-th ===

==== Hardware ====
Assemblare le schede impilabili:
* Board microduino core+ 644
* Board microduino SD
* Board STIMA-I2C
* Microduino FT232RL

==== Software ====
* Caricare il firmware i2c-th tramite microduino FT232RL

==== Configurazione ====

Bisogna configurare l'indirizzo i2c del sensore hih.

* Assemblare microduino core+ con microduino FT232RL con Stima-i2c
* Caricare il firmware sensor_config
* connettere:

* Stima-i2c modulo configurazione +5 -> Stima-i2c modulo stima +5
* Stima-th modulo configurazione GND -> Stima-i2c modulo stima GND
* Stima-th modulo configurazione SDA -> Stima-i2c modulo stima SDA
* Stima-th modulo configurazione SCL -> Stima-i2c modulo stima SCL

alla porta seriale inviare i comandi:
Terminal ready
Start sensor config
Sensor configuration - 1.0

scan I2C bus:
i = scan one time

Sensor to config:
w = i2c-wind
s = i2c-windsonic
t = i2c-th
r = i2c-rain
h = hih humidity sensor

? = help - this page

digit new i2c address for i2c-th (1-127)

35

digit new i2c_temperature address for i2c-th (1-127)

73

digit new i2c_humidity address for i2c-th (1-127)

38

digit 1 for oneshotmode; 0 for continous mode for i2c-th (0/1)

0

Done; switch off

===== Assemblaggio =====

* connettere:

* Stima-i2c modulo configurazione +5 -> Stima-i2c modulo stima +5
* Stima-th modulo configurazione GND -> Stima-i2c modulo stima GND
* Stima-th modulo configurazione SDA -> Stima-i2c modulo stima SDA
* Stima-th modulo configurazione SCL -> Stima-i2c modulo stima SCL

=== Modulo Stima-I2C-rain ===

==== Hardware ====

* Assemblare le schede impilabili:
* Board microduino core+ 644
* Board microduino SD
* Board STIMA-I2C
* Microduino FT232RL

==== Software ====

* Caricare il firmware i2c-rain tramite microduino FT232RL

==== Configurazione ====

Nessuna necessaria.

==== Assemblaggio ====

Il due poli del contatto della bascula vanno collegati l'uno a massa e l'altro al pin D2 del microcontrollore.
Aggiungere una resistenza di pullup di qualche migliaio di ohm tra il pin D2 e +5V.

=== Scheda STIMA-I2C-Hub ===

==== Hardware ====

* Segare il circuito stampato seguendo i fori guida dopo il secondo connettore RJ45.
* Ponticellare con saldature per ottenere 4 file di dupoint a 5V e uno a 3.3V
* Ponticellare con saldature per ottenere un rj45 a 5V e un rg45 a 3.3v.

==== Assemblaggio ====

Collegare i moduli Stima-th Stima-rain Stima-GSM e il display LCDtramite cavo quadripolare alle file di dupoint su Stima-i2c-hub impostati a 5V.

Collegare i sensori Stima-th al connettore RJ45 alimentato a 3.3V.

=== stazione STIMA GSM THP ===
==== Modulo Stima-GSM ====

===== Hardware =====
Apportare queste due modifiche al modulo microduino GPRS/GSM:
* cortocircuitare con una saldatura i due terminali del pulsante di accensione "POWR KEY"
* connettere il punto "RST" al pin D6
* saldare i ponticelli per portarli a TX1,RX1 (jumper for tx, jumper for rx)

Assemblare le schede impilabili:
* Board microduino core+ 1284
* Board microduino GPRS/GSM
* Board microduino SD
* Board STIMA-I2C
* Microduino FT232RL

===== Software =====
In arduino/sketchbook/rmap/rmap copiare il file stima_gsm_report.h in rmap_config.h

In sketchbook/libraries/PubSubClient/PubSubClient.h modificare come segue:

// if use sim800 client
#include "sim800Client.h"
#define TCPCLIENT sim800Client

// if use arduino_uip or etherclient
//#include "Client.h"
//#include "Stream.h"
//#define TCPCLIENT Client

Caricare il firmware rmap tramite microduino FT232RL.

==== Assemblaggio ====

Collegare tutti i moduli tramite l'hub i2c rispettando le corrette tensioni di alimentazione (STIMA-TH a 3.3V).
Collegare all'HUB i2c anche il Display LCD 20x4 con interfaccia I²C alimentandolo a 5V.

Inserire la SIM della TIM senza richiesta di PIN e la scheda SD nel modulo Stima-GSM.

Alimentare il modulo Stima-GSM tramite il connettore micro USB della scheda Stima-i2c con un alimentatore a 5V 2A o in alternativa tramite i pin GND e +5 della scheda Stima-i2c.
Collegare i pin denominati "LED" della scheda del display LCD a un pulsante per l'attivazione della retroilluminazione.

E' possibile utilizzare il connettore micro USB della scheda Microduino FT232RL dei vari moduli per ottenere su porta
seriale messaggi di debug.

===== Configurazione =====

Per ottenere una username e una password iscriversi al sito http://rmap.cc/registrazione/register/

Eventualmente (dopo la prima configurazione) ponticellare sulla scheda Stima-i2c i pin "Set".

eseguire i comandi:

rmapctrl --syncdb
rmap-configure --wizard --station_slug=<nome_stazione> --height=<height> --stationname=<nome_descrittivo> --username=<username> --password=<password> --server=rmap.cc --lat=<xx.xxxxx> --lon=<xx.xxxxx> --mqttrootpath=report --mqttmaintpath=report
rmap-configure --addboard --station_slug=<nome_stazione> --board_slug=<board_name> --user=<username> --serialactivate --mqttactivate --mqttuser=<username> --mqttpassword=<password> --mqttsamplerate=900
rmap-configure --addsensors_by_template=stima_report_thp --station_slug=<nome_stazione> --board_slug=<nome_board> --user=<username> --password=<password> --upload_to_server
rmap-configure --config_station --station_slug=<nome_stazione> --board_slug=<nome_board> --username=<username> --baudrate 115200

sostituendo i valori <> con opportuni valori.

Rimuovere il ponticello ai pin "Set".

==== Operazioni finali ====
Una volta verificato il corretto funzionamento della stazione è possibile ricaricare i firmware con l'opzione di debug disabilitata commentando l'apposita variabile del preprocessore C nei file config.h presenti nelle cartelle dei firmware; in questo caso sarà anche possibile rimuovere le schede Microduino FT232RL dai moduli.

=== stazione STIMA MASTER THP ===
==== Modulo Stima-master ====

===== Hardware =====

Assemblare le schede impilabili:
* Board microduino core+ 1284
* Board microduino wiz W5500 oppure microduino ENC28j60
* Board microduino SD
* Board microduino RJ45-POE
* Board STIMA-I2C
* Microduino FT232RL

===== Software =====
In arduino/sketchbook/rmap/rmap copiare il file stima_master_report.h in rmap_config.h

In sketchbook/libraries/PubSubClient/PubSubClient.h modificare come segue:

// if use sim800 client
//#include "sim800Client.h"
//#define TCPCLIENT sim800Client

// if use arduino_uip or etherclient
#include "Client.h"
#include "Stream.h"
#define TCPCLIENT Client

Caricare il firmware rmap tramite microduino FT232RL.

==== Assemblaggio ====

Collegare tutti i moduli tramite l'hub i2c rispettando le corrette tensioni di alimentazione (STIMA-TH a 3.3V).
Collegare all'HUB i2c anche il Display LCD 20x4 con interfaccia I²C e Modulo Tiny RTC I²C Real Time Clock con DS1307 alimentandoli a 5V

Alimentare il modulo Stima-master tramite il cavo ethernet con power over ethernet con opportuno injector e alimentazione.
Ponticellare i pin denominati "LED" della scheda del display LCD.

E' possibile utilizzare il connettore micro USB della scheda Microduino FT232RL dei vari moduli per ottenere su porta seriale messaggi di debug.

===== Configurazione =====

Per ottenere una username e una password iscriversi al sito http://rmap.cc/registrazione/register/

Eventualmente (dopo la prima configurazione) ponticellare sulla scheda Stima-i2c i pin "Set".

Eseguire i comandi:

rmapctrl --syncdb
rmap-configure --wizard --station_slug=<nome_stazione> --height=<height> --stationname=<nome_descrittivo> --username=<username> --password=<password> --server=rmap.cc --lat=<xx.xxxxx> --lon=<xx.xxxxx> --mqttrootpath=report --mqttmaintpath=report
rmap-configure --addboard --station_slug=<nome_stazione> --board_slug=<nome_board> --user=<username> --serialactivate --mqttactivate --mqttuser=<username> --mqttpassword=<password> --mqttsamplerate=900 --tcpipactivate --tcpipntpserver="it.pool.ntp.org" --tcpipname=stima
rmap-configure --addsensors_by_template=stima_report_thp --station_slug=<nome_stazione> --board_slug=<nome_board> --user=<username> --password=<password> --upload_to_server
rmap-configure --config_station --station_slug=<nome_stazione> --board_slug=<nome_board> --username=<username> --baudrate 115200

sostituendo i valori tra <> con opportuni valori.

Rimuovere il ponticello ai pin "Set".

==== Operazioni finali ====

Una volta verificato il corretto funzionamento della stazione è possibile ricaricare i firmware con l'opzione di debug disabilitata commentando l'apposita variabile del preprocessore C nei file config.h presenti nelle cartelle dei firmware; in questo caso sarà anche possibile rimuovere le schede Microduino FT232RL dai moduli.

== HowTo in sintesi sempre aggiornato per gli altri moduli ==

=== Hardware ===
==== Modulo Stima-bluetooth ====
E' composto dalle seguenti schede:
* Board microduino core+ 644
* Board stima-bluetooth
* Board STIMA-I2C
* Board microduino nRF24 (opzionale)

==== Modulo Stima-Master ====
E' composto dalle seguenti schede:
* Board microduino core+ 1284
* Board microduino ENC
* Board STIMA-I2C
* Board microduino nRF24 (opzionale)

==== Modulo Stima-Satellite ====
E' composto dalle seguenti schede:
* Board microduino core+ 644
* Board microduino nRF24
* Board STIMA-I2C

==== Modulo Stima-GSM/GPRS ====
E' composto dalle seguenti schede:
* Board microduino core+ 1284
* Board microduino nRF24
* Board microduino sim800
* Board microduino SD
* Board STIMA-I2C

==== Modulo Stima-i2c-sdsmics ====

E' composto dalle seguenti schede:
* Board microduino core+ 644 5V
* Board STIMA-AirQuality_Connector

* Board STIMA-NO2-CO

questa la disposizione dei pin dell'hardware versione 2 osservata dal lato dei connettori:

Board STIMA-NO2-CO

{| class="wikitable"
| GND || PWM
|-
| GNDD || SCALE1
|-
| VREF || SCALE2
|-
| VDD || NO2
|-
| +5 || CO
|}

Board STIMA-AirQuality_Connector

{| class="wikitable"
| GND || GND || VREF || NONE || +5V
|}

{| class="wikitable"
| +3.3V || || +5V || || PWM
|-
| GND || || GND || || SCALE1
|-
| SDA || || TX || || SCALE2
|-
| SCL || || RX || || CO
|-
| +5V || || || || NO2
|}

Connettere:
{| class="wikitable"
! STIMA-NO2-CO
!
! STIMA-AirQuality_Connector
|-
| GNDD || <-> || GND
|-
| VREF || <-> || VREF
|-
| VDD || <-> || +5V
|-
| PWM || <-> || PWM
|-
| SCALE1 || <-> || SCALE1
|-
| SCALE2 || <-> || SCALE2
|-
| NO2 || <-> || NO2
|-
| CO || <-> || CO
|}

=== Firmware STIMA-BlueTooth ===

installare arduino 1.6.5 da https://www.arduino.cc/en/Main/Software o tramite la propria distribuzione

scaricare l'ultima versione del software stima (file stimasketchbook) da https://github.com/r-map/rmap/releases
scompattare il file zip

aprire l'ide arduino e in file -> impostazioni -> percorso della cartella degli sketch selezionare la cartella sketchbook appena scompattata dal file scaricato
chiudere e riaprire l'ide

==== modulo Stima-bluetooth ====

Se in questo modulo avete montato anche la board microduino nRF24 e quindi volete utilizzare anche il modulo Stima-Satellite con un editor modificate il file sketchbook/libraries/SensorDriver/SensorDriver_config.h scommentando l'opzione
#define RADIORF24
scommentando anche l'opzione
#define AES
abiliterete anche la crittografia AES ma consigliamo questa ultima opzione solo ai più esperti.

In sketchbook/rmap/rmap copiare il file stima_bluetooth.h in rmap_config.h

sezionare in -> strumenti
Scheda: Microduino Core+ (644pa)
Processore: ATmega644pa@16M5V
Porta: (quella disponibile)

selezionare in -> Sketch -> Verifica e compila

Ora per uplodare il firmware sul microprocessore dovrete collegare tra loro SOLO

MICRODUINO Core+ ATMEGA644PA
MICRODUINO Shield USB/TTL

poi selezionate nella IDE di arduino:

selezionare in -> Sketch -> Carica

==== modulo Stima-master ====
Se in questo modulo avete montato anche la board microduino nRF24 e quindi volete utilizzare anche il modulo Stima-Satellite con un editor modificate il file sketchbook/libraries/SensorDriver/SensorDriver_config.h scommentando l'opzione "#define RADIORF24" ; scommentando anche l'opzione #define AES abiliterete anche la crittografia AES ma consigliamo questa ultima opzione solo ai più esperti.

In sketchbook/rmap/rmap copiare il file stima_master.h in rmap_config.h

sezionare in -> strumenti

Scheda: Microduino Core+ (1284pa)
Processore: ATmega1284pa@16M5V
Porta: (quella disponibile)

sezionare in -> strumenti -> cartella degli sketch -> rmap -> rmap

selezionare in -> Sketch -> Carica

==== modulo Stima-satellite ====
In sketchbook/rmap/rmap copiare il file stima_satellite.h in rmap_config.h

sezionare in -> strumenti

Scheda: Microduino Core+ (644pa)
Processore: ATmega644pa@16M5V
Porta: (quella disponibile)

sezionare in -> strumenti -> cartella degli sketch -> rmap -> rmap

selezionare in -> Sketch -> Carica

==== modulo Stima-gsm ====
In sketchbook/rmap/rmap copiare il file stima_gsm.h in rmap_config.h Se non utilizzerete una SIM card della TIM inserite in fondo al file rmap_config.h:

#define GSMAPN ""
#define GSMUSER ""
#define GSMPASSWORD ""

con gli opportuni valori.

In sketchbook/libraries/PubSubClient/PubSubClient.h modificare come segue:

// if use sim800 client
#include "sim800Client.h"
#define TCPCLIENT sim800Client

// if use arduino_uip or etherclient
//#include "Client.h"
//#include "Stream.h"
//#define TCPCLIENT Client

sezionare in -> strumenti

Scheda: Microduino Core+ (1284pa)
Processore: ATmega1284pa@16M5V
Porta: (quella disponibile)

sezionare in -> strumenti -> cartella degli sketch -> rmap -> rmap

selezionare in -> Sketch -> Carica

=== Applicazione Rmap ===

==== Android ====

L'installazione su android è semplicissima; è sufficiente ricercare tra le app su google play "rmap" e procedere all'installazione: https://play.google.com/store/apps/details?id=org.test.rmap.

==== Linux ====

L'installazione in ambiente Linux richiede la disponibilità di alcuni pacchetti e del comando pip. Prima di tutto bisogna installare Kivy seguendo le istruzioni sul sito di Kivy http://kivy.org/docs/installation/installation-linux.html. Per il comando pip nelle distribuzioni Linux più diffure lo si ottiene installando il pacchetto python-pip. Per installare da utente non privilegiato l'ambiente rmap si può usare virtualenv e pip; da terminale eseguire:

virtualenv --system-site-packages rmap
source rmap/bin/activate

pip install --upgrade rmap

Poi attivare l'interfaccia utente grafica:

source rmap/bin/activate
rmapgui

In alternativa si può provare a installare Kivy tramite pip:

pip install cython
pip install kivy

Per aggiornare l'App una volta chiusa la finestra grafica nella finestra dei comandi al prompt digitare:

pip install --upgrade rmap

==== Windows ====

Seguire le istruzioni a https://kivy.org/docs/installation/installation-windows.html

poi:
python -m pip install rmap

Le istruzioni che seguono sono per una vecchia modalità per un vecchio pacchetto:

L'installazione in windows è molto semplice in quanto il file d scaricare è autoscompattante e comprende tutto l'ambiente necessario a
Rmap. Sacricare quindi il file rmapwindows da: https://github.com/r-map/rmap/releases/ ed eseguirlo per scompattarlo.
Per far partire l'applicazione a questo punto basterà eseguire il file rmapgui contenuto nella cartella rmap
Per aggiornare l'App una volta chiusa la finestra grafica nella finestra dei comandi al prompt digitare:
pip install --upgrade rmap

==== Mac OSX ====

Prima di tutto bisogna installare Kivy su Macosx seguendo le istruzioni https://kivy.org/docs/installation/installation-osx.html e installere gettext da http://www.ellert.se/twain-sane/

poi:

kivi -m pip install --upgrade rmap

si può attivare il programma:

/Applications/Kivy.app/Contents/Resources/venv/bin/rmapgui

Per aggiornare l'App una volta chiusa la finestra grafica nella finestra dei comandi al prompt digitare:

pip install --upgrade rmap

=== Configurazione moduli ===

Per pubblicare i dati sul server RMAP.cc bisogna registrarsi al sito; il bottone "Registrazione" dell'app dovrebbe aprire un browser alla url della registrazione che comunque è http://rmap.cc/registrazione/register/ Una volta fatta la registrazione sarete in possesso di uno user e di una password.

A questo punto dovrete trasferire la vostra configurazione sulla eeprom del microcontrollore; per farlo:

ponticellate sulla board Stima-I2C i pin contrassegnati con "SET" con un jumper.
collegate il modulo con la board Microduino FT232RL alla USB del vostro PC.

==== Configurazione tramite l'applicazione grafica ====

Dovrete accedere al menu "Impostazioni" che si aprirà automaticamente al primo avvio e accedere alle sottosezioni:

Nella sezione "Rmap" dovrete inserire "RMAP user" e "RMAP password" ottenuti durante la registrazione a rmap.cc

Dopo aver accoppiato il dispositivo bluetooth (dispositivo HC-05 inserendo come pin "1234") si può attivare il programma. In windows tramite le apposite interfacce di windows procedere all'accoppiamento del dispositivo blue-tooth (dispositivo HC-05 inserendo come pin "1234") e richiedere la creazione della relativa porta seriale COM13; in Linux per accoppiare il dispositivo stima-bluetooth cosigliamo di utilizzare blueman-manager contenuto nel pacchetto blueman; seguendo pochi passi con l'interfaccia grafica risulta molto facile accoppiare il dispositivo HC-05 inserendo come pin "1234"; il device RFCOM0 viene utilizzato per la comunicazione seriale.

Ora dal menu Impostazioni selezionate la sezione "Sensors" e impostate:

per il modulo Stima-Bluetooth
Name: HC-05
Station: BT_fixed
Board:
su android: BT_fixed
su linux: BT_fixed_LINUX
su windows: BT_fixed_WINDOWS
su OSX: BT_fixed_OSX
Template: test_indirect
Remote Board: stima_bt
Remote Template: test
per il modulo Stima-Master o Stima-gsm
Station: ETH_fixed
Board:
su linux: rmapgui_LINUX
su windows: rmapgui_WINDOWS
su OSX: rmapgui_OSX
Template: test_indirect
Remote Board: master_eth_fixed
Remote Template: test (test_master se avete la board nRF24)
per il modulo Stima-Satellite
come per il modulo Stima-Master ma come Remote Board: satellite_eth_fixed

Nella sezione "Location" potete inserire manualmente le vostre coordinate e selezionare "Close" attivando la stazione. Se non conoscete le vostre coordinate dalla pagina "Posizione" selezionate accuratamente la vostra posizione e salvatela con il tasto "Salva posizione". La prima pagina dell'App "Avvia" presenta un manuale che potrà aiutarvi.

Dalla pagina "Dati automatici" premere il bottone "configura" e verificate che tutto vada a buon fine.

==== Configurazione a linea di comando ====

E' possibile fare tutte le funzioni di configurazioni con due comandi da terminale: nel caso di windows utilizzate la finestra che rimane aperta dopo aver eseguito rmap-configure.bat; su Linux o OSX attivate il virtualenv di python come per eseguire l'App grafica. Il primo comando inizializza il DB. Il secondo con l'opzione --wizard inserisce tutti i metadati nel DB, --config_station trasferisce la configurazione sulla eeprom del microcontrollore e --upload_to_server comunica i metadati al server:

rmapctrl --syncdb
rmap-configure --station_slug=ETH_fixed --board_slug=master_eth_fixed --height=<altezza stazione in metri> --stationname="<descrizione della stazione>" --username=<il vostro utente> --password=<la vostra password> --server=rmap.cc --samplerate=5 --lat=<latitudine stazione> --lon=<longitudine stazione> --addsensors_by_template=<sensortemplate> --wizard --config_station --upload_to_server

Ovviamente sostituite il contenuto tra <> con i vostri dati; cercate di avere latitudine e longitudine definita fino alla quinta cifra decimale; <sensortemplate> dovrà essere "test_master" se il vostro modulo Stima-master o Stima-gsm comprende una board microduino nRF24, "test" in tutti gli altri casi.

=== Operazioni finali ===

Scollegare il modulo dalla USB, rimuovete la board Microduino FT232RL e attivate l'alimentazione saldando insieme il ponticello della board Stima-I2C come da figura. attachment:microduino_r_freccia.png Ricordatevi di rimuovere il jumper dai pin contrassegnati con "SET" sulla board Stima-I2C.
Messa in opera

Ai moduli potete collegare il display LCD e/o i relays. Sul modulo Stima-gsm inserite una micro SD formattata FAT; dovete inserire anche una SIM card; tutto è preconfigurato per una sim della TIM. Alimentate i moduli tramite il connettore micro-USB sulla board Stima-I2C; il modulo Stima-master potete alimentarlo con l'apposito Injector e un alimentatore da 12 a 24V (connettore con positivo al centro). Sul modulo Stima-gsm il sim800 va acceso manualmente tenendo premuto l'apposito switch. Se tutto funziona regolarmente ogni 5 secondi i dati della temperatura del modulo verranno inviati a rmap.cc. Se sul server rmap.cc a questo punto fate login con il vostro utente accederete alla vostra pagina personale con l'elenco delle vostre stazioni di misura e la possibilità di visualizzare i grafici dei vostri dati. Ma per ora potete inviare solo i dati di test (temperatura del modulo); nella prossima puntata impareremo ad aggiungere sensori e navigare il server per la visualizzazione dei dati.

=== Messa in opera ===

Ai moduli potete collegare il display LCD e/o i relays. Sul modulo Stima-GSM/GPRS inserite una micro SD formattata FAT; dovete inserire anche una SIM card; tutto è preconfigurato per una sim della TIM. Alimentate i moduli tramite il connettore micro-USB sulla board Stima-I2C; il modulo Stima-master potete alimentarlo con l'apposito Injector e un alimentatore da 12 a 24V (connettore con positivo al centro). Sul modulo Stima-GSM/GPRS il sim800 va acceso manualmente tenendo premuto l'apposito switch. Sulla rete ethernet dovrte avere un server DHCP in quanto STIMA-Master lo richiede. Se tutto funziona regolarmente ogni 5 secondi i dati della temperatura di test del modulo verranno inviati a rmap.cc. Se sul server rmap.cc a questo punto fate login con il vostro utente accederete alla vostra pagina personale con l'elenco delle vostre stazioni di misura e la possibilità di visualizzare i grafici dei vostri dati. Ma per ora potete inviare solo i dati di test (temperatura del modulo); nella prossima puntata impareremo ad aggiungere sensori e navigare il server per la visualizzazione dei dati.

=== Box ===

Abbiamo progettato un interessante box per il modulo Stima-bluetooth e i sensori di temperatura e umidità (presentati nella prossima puntata); é composto da alcuni elementi impilabili a seconda delle esigenze. Ora lo presentiamo nella versione con un comodo attacco a elastico da usare ad esempio sul manubrio della bici per monitorare il percorso delle nostre escursioni.
Sono disponibili i file stl per stamparlo con una stampante 3D. I file per il box progettato da Mirco Bergamini si scaricano da https://github.com/r-map/rmap/releases ; è consigliato stamparlo in PLA bianco per ridurre gli effetti della radiazione solare. attachment:box.jpg Il box è composto da tre pezzi: un attacco "a elastico", un contenitore per il modulo stima, uno schermo per le radiazioni per l'alloggiamento dei sensori. Gli ultimi due pezzi posso essere montati a due a due permettendo di aumentare lo spazio contenuto dal box; Sarà poi necessario praticare un foro tra il contenitore del modulo stima e lo schermo pr i sensori per il passaggio dei 4 fili del bus I2C; barre filettate e dadi completano l'assemblaggio.

Vedi anche: [[Gruppo Meteo/HowToOld]]

Installare MicroPython su NUCLEO-F401RE

2019-03-10T00:46:38Z

Oloturia: /* Test! */

Questa guida è basata quasi tutta su quella di Carmine Noviello https://www.carminenoviello.com/2015/06/03/running-micropyton-stm32nucleo-f4/ che peraltro trovate anche in italiano https://www.carminenoviello.com/it/2015/08/11/compilare-micropython-una-scheda-stm32nucleo-f4/ per cui scriverò solo le differenze.

La versione di Carmine di micropython, che si trova sul suo [https://github.com/cnoviello/micropython github], risolve il problema relativo alla mancanza di memoria SD della scheda Nucleo. Il file con il programma .py sarà caricato direttamente sulla flash.

= La scheda =

NUCLEO-F401RE della STMicroelectronics è una scheda basata su ARM Cortex M4 e fa parte della famiglia STM32 Nucleo Boards. Ha 512KB di Flash, 96 KB di SRAM, un clock di 84MHz, 50 GPIO, RTC, supporto I²C, SPI, USART e molto altro ([https://os.mbed.com/platforms/ST-Nucleo-F401RE/ maggiori info]). La sua forma le permette di alloggiare sia gli shield per Arduino che le estensioni Morpho di STMicroelectronics.
Il prezzo è abbastanza contenuto (attorno ai 12€ su Mouser) il che ne fa una scheda piuttosto interessante.

Normalmente si programmerebbe tramite l'[https://ide.mbed.com/compiler editor online di Mbed]. Il compilatore genererà dal nostro codice un file con estensione bin. Collegando la scheda verrà montato un volume, chiamato "NUCLEO" sul quale caricare il file bin. Quando la scheda verrà resettata, il codice verrà eseguito. È possibile anche usare editor offline con toolchain di compilazione come Eclipse.

= Installazione MicroPython =

== Primo tentativo ==

=== Toolchain e OpenOCD ===

Per compilare vi servirà la toolchain gcc-arm-embedded. Non è nei repo ufficiali quindi la dovete installare a mano oppure aggiungere un PPA. https://launchpad.net/gcc-arm-embedded
Il programma per comunicare col debugger della scheda, openocd, invece è nei repo di Debian.

=== Come installare MicroPython ===

Potete seguire la [https://www.carminenoviello.com/it/2015/08/11/compilare-micropython-una-scheda-stm32nucleo-f4/ guida di Carmine Noviello] per la compilazione. Ovviamente se avete installato la toolchain con apt non è necessario aggiungere il path a tutti i comandi, perché sono già dentro a /usr/bin.

OpenOCD ci permette di caricare il firmware che abbiamo crosscompilato. Basterà lanciare il comando:
$ openocd -f board/st_nucleo_f4.cfg
Un LED della scheda dovrebbe lampeggiare rosso/verde. Il debugger è attivo. Per collegarcisi:
$ telnet localhost 4444
e poi scrivete:
> reset halt
e infine:
> flash write_image erase <file .elf da flashare>

Inizialmente non sembrava funzionare. Il tentativo finale che ha sbloccato la situazione è stato dare il comando shutdown. Non sono sicuro però che sia stato proprio quel comando e bisognerebbe indagare meglio.

=== Usare MicroPython dall'interprete ===

Aprendo la porta della nostra scheda (la trovate su dmesg non appena la attaccate, è /dev/ttyACMx dove x è un numero che parte da 0) con un emulatore di terminale (come screen, picocom o minicom) alla velocità di 115200 baud, dovreste vedere l'interprete dei comandi (REPL, ovvero Read, Eval, Print and Loop) di MicroPython. Provate a dare il comando:
>>> pyb.LED(1).on()
per vedere se si accende il LED onboard.

=== Usare MicroPython dal PC ===

Fra i tool di MicroPython, che trovate nella cartella di git micropython/tools, c'è pyboard.py, un programma che vi permette di eseguire uno script in MicroPython. Se la vostra porta non è accessibile dall'utente dovrete usare sudo.
# ./pyboard.py --device=/dev/ttyACMx <nome file>.py

=== Caricare uno script ===

Carmine ha fatto una modifica a pyboard in modo che possa caricare un file sulla board.
# ./pyboard.py --device=/dev/ttyACMx --send <nome file>.py

MicroPython ha due file di default quando viene installato: boot.py e main.py. Il primo è un file di sistema che serve allo stesso MicroPython di partire. Non occorre di solito modificarlo. Il secondo, main.py, è uno script che viene eseguito all'avvio. Se carichiamo un file main.py questo verrà eseguito all'accensione.

=== Considerazioni finali ===

Molto bene, ma la versione di micropython non è aggiornata. Forse è per questo che non riesco a far funzionare la porta I²C?

== Secondo tentativo ==

Boochow fornisce dei firmware già compilati su https://blog.boochow.com/micropython-firmware-for-mbed-boards basta scegliere la board giusta e caricare il file .bin nel volume "NUCLEO" che si monta quando si collega la USB.

=== Caricare uno script ===

Un modo piuttosto comodo di inviare e ricevere file sulla flash della Nucleo è usare uPyLoader:
https://github.com/BetaRavener/uPyLoader/
ma quasi sempre dà un errore di timeout.

Il programma fornito da Adafruit sembra funzionare decisamente meglio
https://learn.adafruit.com/micropython-basics-load-files-and-run-code/install-ampy

Per installarlo usare pip (o pip3):
pip install adafruit-ampy

Per usarlo:
ampy -p <porta seriale> put <nome file>

= Display OLED I²C =

Per testare il funzionamento di MicroPython, proviamo a usare un piccolo display OLED I²C.

== Caricare la libreria ==

Con ampy carichiamo la [https://github.com/micropython/micropython/blob/master/drivers/display/ssd1306.py libreria ssd1306].

ampy -p /dev/ttyACM0 put ssd1306.py

== Manovrare il display da REPL ==

Se la libreria è stata caricata si può importare scrivendo:

>>> import ssd1306

Occorre poi creare un oggetto I2C specificando quali pin usare per SCL e SDA (in teoria dovrebbe essere automatico, ma secondo [https://forum.micropython.org/viewtopic.php?t=4663 questo post sul forum di micropython] l'automatismo non funziona), la libreria machine dovrebbe essere già importata di default:

>>> pscl = machine.Pin('D15',machine.Pin.OUT_PP)
>>> psda = machine.Pin('D14',machine.Pin.OUT_PP)
>>> i2c = machine.I2C(scl=pscl,sda=psda)

e poi creare un oggetto che gestisca il display:

>>> oled = ssd1306.SSD1306_I2C(128,64,i2c)

dove 128 e 64 sono le dimensioni.

== Test! ==

Per prima cosa occorre cancellare un'eventuale scritta precedente:

>>> oled.fill(0)

Poi scriviamo qualcosa, nella posizione x 0, y 0:

>>> oled.text('qualcosa',0,0)

e infine lo mostriamo:

>>> oled.show()

et voilà!

[[File:Micropython_test_oled.jpg]]

Più informazioni su come funziona la libreria, corredata da esempi, le potete trovare sul [https://learn.adafruit.com/micropython-hardware-ssd1306-oled-display/circuitpython sito di Adafruit].

Installare MicroPython su NUCLEO-F401RE

2019-03-10T00:18:25Z

Oloturia: /* Usare MicroPython dal PC */

Questa guida è basata quasi tutta su quella di Carmine Noviello https://www.carminenoviello.com/2015/06/03/running-micropyton-stm32nucleo-f4/ che peraltro trovate anche in italiano https://www.carminenoviello.com/it/2015/08/11/compilare-micropython-una-scheda-stm32nucleo-f4/ per cui scriverò solo le differenze.

La versione di Carmine di micropython, che si trova sul suo [https://github.com/cnoviello/micropython github], risolve il problema relativo alla mancanza di memoria SD della scheda Nucleo. Il file con il programma .py sarà caricato direttamente sulla flash.

= La scheda =

NUCLEO-F401RE della STMicroelectronics è una scheda basata su ARM Cortex M4 e fa parte della famiglia STM32 Nucleo Boards. Ha 512KB di Flash, 96 KB di SRAM, un clock di 84MHz, 50 GPIO, RTC, supporto I²C, SPI, USART e molto altro ([https://os.mbed.com/platforms/ST-Nucleo-F401RE/ maggiori info]). La sua forma le permette di alloggiare sia gli shield per Arduino che le estensioni Morpho di STMicroelectronics.
Il prezzo è abbastanza contenuto (attorno ai 12€ su Mouser) il che ne fa una scheda piuttosto interessante.

Normalmente si programmerebbe tramite l'[https://ide.mbed.com/compiler editor online di Mbed]. Il compilatore genererà dal nostro codice un file con estensione bin. Collegando la scheda verrà montato un volume, chiamato "NUCLEO" sul quale caricare il file bin. Quando la scheda verrà resettata, il codice verrà eseguito. È possibile anche usare editor offline con toolchain di compilazione come Eclipse.

= Installazione MicroPython =

== Primo tentativo ==

=== Toolchain e OpenOCD ===

Per compilare vi servirà la toolchain gcc-arm-embedded. Non è nei repo ufficiali quindi la dovete installare a mano oppure aggiungere un PPA. https://launchpad.net/gcc-arm-embedded
Il programma per comunicare col debugger della scheda, openocd, invece è nei repo di Debian.

=== Come installare MicroPython ===

Potete seguire la [https://www.carminenoviello.com/it/2015/08/11/compilare-micropython-una-scheda-stm32nucleo-f4/ guida di Carmine Noviello] per la compilazione. Ovviamente se avete installato la toolchain con apt non è necessario aggiungere il path a tutti i comandi, perché sono già dentro a /usr/bin.

OpenOCD ci permette di caricare il firmware che abbiamo crosscompilato. Basterà lanciare il comando:
$ openocd -f board/st_nucleo_f4.cfg
Un LED della scheda dovrebbe lampeggiare rosso/verde. Il debugger è attivo. Per collegarcisi:
$ telnet localhost 4444
e poi scrivete:
> reset halt
e infine:
> flash write_image erase <file .elf da flashare>

Inizialmente non sembrava funzionare. Il tentativo finale che ha sbloccato la situazione è stato dare il comando shutdown. Non sono sicuro però che sia stato proprio quel comando e bisognerebbe indagare meglio.

=== Usare MicroPython dall'interprete ===

Aprendo la porta della nostra scheda (la trovate su dmesg non appena la attaccate, è /dev/ttyACMx dove x è un numero che parte da 0) con un emulatore di terminale (come screen, picocom o minicom) alla velocità di 115200 baud, dovreste vedere l'interprete dei comandi (REPL, ovvero Read, Eval, Print and Loop) di MicroPython. Provate a dare il comando:
>>> pyb.LED(1).on()
per vedere se si accende il LED onboard.

=== Usare MicroPython dal PC ===

Fra i tool di MicroPython, che trovate nella cartella di git micropython/tools, c'è pyboard.py, un programma che vi permette di eseguire uno script in MicroPython. Se la vostra porta non è accessibile dall'utente dovrete usare sudo.
# ./pyboard.py --device=/dev/ttyACMx <nome file>.py

=== Caricare uno script ===

Carmine ha fatto una modifica a pyboard in modo che possa caricare un file sulla board.
# ./pyboard.py --device=/dev/ttyACMx --send <nome file>.py

MicroPython ha due file di default quando viene installato: boot.py e main.py. Il primo è un file di sistema che serve allo stesso MicroPython di partire. Non occorre di solito modificarlo. Il secondo, main.py, è uno script che viene eseguito all'avvio. Se carichiamo un file main.py questo verrà eseguito all'accensione.

=== Considerazioni finali ===

Molto bene, ma la versione di micropython non è aggiornata. Forse è per questo che non riesco a far funzionare la porta I²C?

== Secondo tentativo ==

Boochow fornisce dei firmware già compilati su https://blog.boochow.com/micropython-firmware-for-mbed-boards basta scegliere la board giusta e caricare il file .bin nel volume "NUCLEO" che si monta quando si collega la USB.

=== Caricare uno script ===

Un modo piuttosto comodo di inviare e ricevere file sulla flash della Nucleo è usare uPyLoader:
https://github.com/BetaRavener/uPyLoader/
ma quasi sempre dà un errore di timeout.

Il programma fornito da Adafruit sembra funzionare decisamente meglio
https://learn.adafruit.com/micropython-basics-load-files-and-run-code/install-ampy

Per installarlo usare pip (o pip3):
pip install adafruit-ampy

Per usarlo:
ampy -p <porta seriale> put <nome file>

= Display OLED I²C =

Per testare il funzionamento di MicroPython, proviamo a usare un piccolo display OLED I²C.

== Caricare la libreria ==

Con ampy carichiamo la [https://github.com/micropython/micropython/blob/master/drivers/display/ssd1306.py libreria ssd1306].

ampy -p /dev/ttyACM0 put ssd1306.py

== Manovrare il display da REPL ==

Se la libreria è stata caricata si può importare scrivendo:

>>> import ssd1306

Occorre poi creare un oggetto I2C specificando quali pin usare per SCL e SDA (in teoria dovrebbe essere automatico, ma secondo [https://forum.micropython.org/viewtopic.php?t=4663 questo post sul forum di micropython] l'automatismo non funziona), la libreria machine dovrebbe essere già importata di default:

>>> pscl = machine.Pin('D15',machine.Pin.OUT_PP)
>>> psda = machine.Pin('D14',machine.Pin.OUT_PP)
>>> i2c = machine.I2C(scl=pscl,sda=psda)

e poi creare un oggetto che gestisca il display:

>>> oled = ssd1306.SSD1306_I2C(128,64,i2c)

dove 128 e 64 sono le dimensioni.

== Test! ==

Per prima cosa occorre cancellare un'eventuale scritta precedente:

>>> oled.fill(0)

Poi scriviamo qualcosa:

>>> oled.text('qualcosa',0,0)

e infine lo mostriamo:

>>> oled.show()

et voilà!

[[File:Micropython_test_oled.jpg]]

Più informazioni su come funziona la libreria, corredata da esempi, le potete trovare sul [https://learn.adafruit.com/micropython-hardware-ssd1306-oled-display/circuitpython sito di Adafruit].

Installare MicroPython su NUCLEO-F401RE

2019-03-10T00:17:11Z

Oloturia: /* Usare MicroPython dall'interprete */

Questa guida è basata quasi tutta su quella di Carmine Noviello https://www.carminenoviello.com/2015/06/03/running-micropyton-stm32nucleo-f4/ che peraltro trovate anche in italiano https://www.carminenoviello.com/it/2015/08/11/compilare-micropython-una-scheda-stm32nucleo-f4/ per cui scriverò solo le differenze.

La versione di Carmine di micropython, che si trova sul suo [https://github.com/cnoviello/micropython github], risolve il problema relativo alla mancanza di memoria SD della scheda Nucleo. Il file con il programma .py sarà caricato direttamente sulla flash.

= La scheda =

NUCLEO-F401RE della STMicroelectronics è una scheda basata su ARM Cortex M4 e fa parte della famiglia STM32 Nucleo Boards. Ha 512KB di Flash, 96 KB di SRAM, un clock di 84MHz, 50 GPIO, RTC, supporto I²C, SPI, USART e molto altro ([https://os.mbed.com/platforms/ST-Nucleo-F401RE/ maggiori info]). La sua forma le permette di alloggiare sia gli shield per Arduino che le estensioni Morpho di STMicroelectronics.
Il prezzo è abbastanza contenuto (attorno ai 12€ su Mouser) il che ne fa una scheda piuttosto interessante.

Normalmente si programmerebbe tramite l'[https://ide.mbed.com/compiler editor online di Mbed]. Il compilatore genererà dal nostro codice un file con estensione bin. Collegando la scheda verrà montato un volume, chiamato "NUCLEO" sul quale caricare il file bin. Quando la scheda verrà resettata, il codice verrà eseguito. È possibile anche usare editor offline con toolchain di compilazione come Eclipse.

= Installazione MicroPython =

== Primo tentativo ==

=== Toolchain e OpenOCD ===

Per compilare vi servirà la toolchain gcc-arm-embedded. Non è nei repo ufficiali quindi la dovete installare a mano oppure aggiungere un PPA. https://launchpad.net/gcc-arm-embedded
Il programma per comunicare col debugger della scheda, openocd, invece è nei repo di Debian.

=== Come installare MicroPython ===

Potete seguire la [https://www.carminenoviello.com/it/2015/08/11/compilare-micropython-una-scheda-stm32nucleo-f4/ guida di Carmine Noviello] per la compilazione. Ovviamente se avete installato la toolchain con apt non è necessario aggiungere il path a tutti i comandi, perché sono già dentro a /usr/bin.

OpenOCD ci permette di caricare il firmware che abbiamo crosscompilato. Basterà lanciare il comando:
$ openocd -f board/st_nucleo_f4.cfg
Un LED della scheda dovrebbe lampeggiare rosso/verde. Il debugger è attivo. Per collegarcisi:
$ telnet localhost 4444
e poi scrivete:
> reset halt
e infine:
> flash write_image erase <file .elf da flashare>

Inizialmente non sembrava funzionare. Il tentativo finale che ha sbloccato la situazione è stato dare il comando shutdown. Non sono sicuro però che sia stato proprio quel comando e bisognerebbe indagare meglio.

=== Usare MicroPython dall'interprete ===

Aprendo la porta della nostra scheda (la trovate su dmesg non appena la attaccate, è /dev/ttyACMx dove x è un numero che parte da 0) con un emulatore di terminale (come screen, picocom o minicom) alla velocità di 115200 baud, dovreste vedere l'interprete dei comandi (REPL, ovvero Read, Eval, Print and Loop) di MicroPython. Provate a dare il comando:
>>> pyb.LED(1).on()
per vedere se si accende il LED onboard.

=== Usare MicroPython dal PC ===

Fra i tool di MicroPython, che trovate nella cartella di git micropython/tools, c'è pyboard.py, un programma che vi permette di eseguire uno script in MicroPython. Se la vostra porta non è accessibile dall'utente dovrete usare sudo.
# ./pyboard.py <nome file>.py

=== Caricare uno script ===

Carmine ha fatto una modifica a pyboard in modo che possa caricare un file sulla board.
# ./pyboard.py --device=/dev/ttyACMx --send <nome file>.py

MicroPython ha due file di default quando viene installato: boot.py e main.py. Il primo è un file di sistema che serve allo stesso MicroPython di partire. Non occorre di solito modificarlo. Il secondo, main.py, è uno script che viene eseguito all'avvio. Se carichiamo un file main.py questo verrà eseguito all'accensione.

=== Considerazioni finali ===

Molto bene, ma la versione di micropython non è aggiornata. Forse è per questo che non riesco a far funzionare la porta I²C?

== Secondo tentativo ==

Boochow fornisce dei firmware già compilati su https://blog.boochow.com/micropython-firmware-for-mbed-boards basta scegliere la board giusta e caricare il file .bin nel volume "NUCLEO" che si monta quando si collega la USB.

=== Caricare uno script ===

Un modo piuttosto comodo di inviare e ricevere file sulla flash della Nucleo è usare uPyLoader:
https://github.com/BetaRavener/uPyLoader/
ma quasi sempre dà un errore di timeout.

Il programma fornito da Adafruit sembra funzionare decisamente meglio
https://learn.adafruit.com/micropython-basics-load-files-and-run-code/install-ampy

Per installarlo usare pip (o pip3):
pip install adafruit-ampy

Per usarlo:
ampy -p <porta seriale> put <nome file>

= Display OLED I²C =

Per testare il funzionamento di MicroPython, proviamo a usare un piccolo display OLED I²C.

== Caricare la libreria ==

Con ampy carichiamo la [https://github.com/micropython/micropython/blob/master/drivers/display/ssd1306.py libreria ssd1306].

ampy -p /dev/ttyACM0 put ssd1306.py

== Manovrare il display da REPL ==

Se la libreria è stata caricata si può importare scrivendo:

>>> import ssd1306

Occorre poi creare un oggetto I2C specificando quali pin usare per SCL e SDA (in teoria dovrebbe essere automatico, ma secondo [https://forum.micropython.org/viewtopic.php?t=4663 questo post sul forum di micropython] l'automatismo non funziona), la libreria machine dovrebbe essere già importata di default:

>>> pscl = machine.Pin('D15',machine.Pin.OUT_PP)
>>> psda = machine.Pin('D14',machine.Pin.OUT_PP)
>>> i2c = machine.I2C(scl=pscl,sda=psda)

e poi creare un oggetto che gestisca il display:

>>> oled = ssd1306.SSD1306_I2C(128,64,i2c)

dove 128 e 64 sono le dimensioni.

== Test! ==

Per prima cosa occorre cancellare un'eventuale scritta precedente:

>>> oled.fill(0)

Poi scriviamo qualcosa:

>>> oled.text('qualcosa',0,0)

e infine lo mostriamo:

>>> oled.show()

et voilà!

[[File:Micropython_test_oled.jpg]]

Più informazioni su come funziona la libreria, corredata da esempi, le potete trovare sul [https://learn.adafruit.com/micropython-hardware-ssd1306-oled-display/circuitpython sito di Adafruit].

Installare MicroPython su NUCLEO-F401RE

2019-03-10T00:14:39Z

Oloturia: /* Come installare MicroPython */

Questa guida è basata quasi tutta su quella di Carmine Noviello https://www.carminenoviello.com/2015/06/03/running-micropyton-stm32nucleo-f4/ che peraltro trovate anche in italiano https://www.carminenoviello.com/it/2015/08/11/compilare-micropython-una-scheda-stm32nucleo-f4/ per cui scriverò solo le differenze.

La versione di Carmine di micropython, che si trova sul suo [https://github.com/cnoviello/micropython github], risolve il problema relativo alla mancanza di memoria SD della scheda Nucleo. Il file con il programma .py sarà caricato direttamente sulla flash.

= La scheda =

NUCLEO-F401RE della STMicroelectronics è una scheda basata su ARM Cortex M4 e fa parte della famiglia STM32 Nucleo Boards. Ha 512KB di Flash, 96 KB di SRAM, un clock di 84MHz, 50 GPIO, RTC, supporto I²C, SPI, USART e molto altro ([https://os.mbed.com/platforms/ST-Nucleo-F401RE/ maggiori info]). La sua forma le permette di alloggiare sia gli shield per Arduino che le estensioni Morpho di STMicroelectronics.
Il prezzo è abbastanza contenuto (attorno ai 12€ su Mouser) il che ne fa una scheda piuttosto interessante.

Normalmente si programmerebbe tramite l'[https://ide.mbed.com/compiler editor online di Mbed]. Il compilatore genererà dal nostro codice un file con estensione bin. Collegando la scheda verrà montato un volume, chiamato "NUCLEO" sul quale caricare il file bin. Quando la scheda verrà resettata, il codice verrà eseguito. È possibile anche usare editor offline con toolchain di compilazione come Eclipse.

= Installazione MicroPython =

== Primo tentativo ==

=== Toolchain e OpenOCD ===

Per compilare vi servirà la toolchain gcc-arm-embedded. Non è nei repo ufficiali quindi la dovete installare a mano oppure aggiungere un PPA. https://launchpad.net/gcc-arm-embedded
Il programma per comunicare col debugger della scheda, openocd, invece è nei repo di Debian.

=== Come installare MicroPython ===

Potete seguire la [https://www.carminenoviello.com/it/2015/08/11/compilare-micropython-una-scheda-stm32nucleo-f4/ guida di Carmine Noviello] per la compilazione. Ovviamente se avete installato la toolchain con apt non è necessario aggiungere il path a tutti i comandi, perché sono già dentro a /usr/bin.

OpenOCD ci permette di caricare il firmware che abbiamo crosscompilato. Basterà lanciare il comando:
$ openocd -f board/st_nucleo_f4.cfg
Un LED della scheda dovrebbe lampeggiare rosso/verde. Il debugger è attivo. Per collegarcisi:
$ telnet localhost 4444
e poi scrivete:
> reset halt
e infine:
> flash write_image erase <file .elf da flashare>

Inizialmente non sembrava funzionare. Il tentativo finale che ha sbloccato la situazione è stato dare il comando shutdown. Non sono sicuro però che sia stato proprio quel comando e bisognerebbe indagare meglio.

=== Usare MicroPython dall'interprete ===

Aprendo la porta della nostra scheda (la trovate su dmesg non appena la attaccate, è /dev/ttyACMx dove x è un numero che parte da 0) con un emulatore di terminale (come console) alla velocità di 115200 baud, dovreste vedere l'interprete dei comandi (REPL, ovvero Read, Eval, Print and Loop) di MicroPython. Provate a dare il comando:
>>> pyb.LED(1).on()
per vedere se si accende il LED onboard.

=== Usare MicroPython dal PC ===

Fra i tool di MicroPython, che trovate nella cartella di git micropython/tools, c'è pyboard.py, un programma che vi permette di eseguire uno script in MicroPython. Se la vostra porta non è accessibile dall'utente dovrete usare sudo.
# ./pyboard.py <nome file>.py

=== Caricare uno script ===

Carmine ha fatto una modifica a pyboard in modo che possa caricare un file sulla board.
# ./pyboard.py --device=/dev/ttyACMx --send <nome file>.py

MicroPython ha due file di default quando viene installato: boot.py e main.py. Il primo è un file di sistema che serve allo stesso MicroPython di partire. Non occorre di solito modificarlo. Il secondo, main.py, è uno script che viene eseguito all'avvio. Se carichiamo un file main.py questo verrà eseguito all'accensione.

=== Considerazioni finali ===

Molto bene, ma la versione di micropython non è aggiornata. Forse è per questo che non riesco a far funzionare la porta I²C?

== Secondo tentativo ==

Boochow fornisce dei firmware già compilati su https://blog.boochow.com/micropython-firmware-for-mbed-boards basta scegliere la board giusta e caricare il file .bin nel volume "NUCLEO" che si monta quando si collega la USB.

=== Caricare uno script ===

Un modo piuttosto comodo di inviare e ricevere file sulla flash della Nucleo è usare uPyLoader:
https://github.com/BetaRavener/uPyLoader/
ma quasi sempre dà un errore di timeout.

Il programma fornito da Adafruit sembra funzionare decisamente meglio
https://learn.adafruit.com/micropython-basics-load-files-and-run-code/install-ampy

Per installarlo usare pip (o pip3):
pip install adafruit-ampy

Per usarlo:
ampy -p <porta seriale> put <nome file>

= Display OLED I²C =

Per testare il funzionamento di MicroPython, proviamo a usare un piccolo display OLED I²C.

== Caricare la libreria ==

Con ampy carichiamo la [https://github.com/micropython/micropython/blob/master/drivers/display/ssd1306.py libreria ssd1306].

ampy -p /dev/ttyACM0 put ssd1306.py

== Manovrare il display da REPL ==

Se la libreria è stata caricata si può importare scrivendo:

>>> import ssd1306

Occorre poi creare un oggetto I2C specificando quali pin usare per SCL e SDA (in teoria dovrebbe essere automatico, ma secondo [https://forum.micropython.org/viewtopic.php?t=4663 questo post sul forum di micropython] l'automatismo non funziona), la libreria machine dovrebbe essere già importata di default:

>>> pscl = machine.Pin('D15',machine.Pin.OUT_PP)
>>> psda = machine.Pin('D14',machine.Pin.OUT_PP)
>>> i2c = machine.I2C(scl=pscl,sda=psda)

e poi creare un oggetto che gestisca il display:

>>> oled = ssd1306.SSD1306_I2C(128,64,i2c)

dove 128 e 64 sono le dimensioni.

== Test! ==

Per prima cosa occorre cancellare un'eventuale scritta precedente:

>>> oled.fill(0)

Poi scriviamo qualcosa:

>>> oled.text('qualcosa',0,0)

e infine lo mostriamo:

>>> oled.show()

et voilà!

[[File:Micropython_test_oled.jpg]]

Più informazioni su come funziona la libreria, corredata da esempi, le potete trovare sul [https://learn.adafruit.com/micropython-hardware-ssd1306-oled-display/circuitpython sito di Adafruit].

Installare MicroPython su NUCLEO-F401RE

2019-03-10T00:13:27Z

Oloturia: /* La scheda */

Questa guida è basata quasi tutta su quella di Carmine Noviello https://www.carminenoviello.com/2015/06/03/running-micropyton-stm32nucleo-f4/ che peraltro trovate anche in italiano https://www.carminenoviello.com/it/2015/08/11/compilare-micropython-una-scheda-stm32nucleo-f4/ per cui scriverò solo le differenze.

La versione di Carmine di micropython, che si trova sul suo [https://github.com/cnoviello/micropython github], risolve il problema relativo alla mancanza di memoria SD della scheda Nucleo. Il file con il programma .py sarà caricato direttamente sulla flash.

= La scheda =

NUCLEO-F401RE della STMicroelectronics è una scheda basata su ARM Cortex M4 e fa parte della famiglia STM32 Nucleo Boards. Ha 512KB di Flash, 96 KB di SRAM, un clock di 84MHz, 50 GPIO, RTC, supporto I²C, SPI, USART e molto altro ([https://os.mbed.com/platforms/ST-Nucleo-F401RE/ maggiori info]). La sua forma le permette di alloggiare sia gli shield per Arduino che le estensioni Morpho di STMicroelectronics.
Il prezzo è abbastanza contenuto (attorno ai 12€ su Mouser) il che ne fa una scheda piuttosto interessante.

Normalmente si programmerebbe tramite l'[https://ide.mbed.com/compiler editor online di Mbed]. Il compilatore genererà dal nostro codice un file con estensione bin. Collegando la scheda verrà montato un volume, chiamato "NUCLEO" sul quale caricare il file bin. Quando la scheda verrà resettata, il codice verrà eseguito. È possibile anche usare editor offline con toolchain di compilazione come Eclipse.

= Installazione MicroPython =

== Primo tentativo ==

=== Toolchain e OpenOCD ===

Per compilare vi servirà la toolchain gcc-arm-embedded. Non è nei repo ufficiali quindi la dovete installare a mano oppure aggiungere un PPA. https://launchpad.net/gcc-arm-embedded
Il programma per comunicare col debugger della scheda, openocd, invece è nei repo di Debian.

=== Come installare MicroPython ===

Potete seguire la guida di Carmine per la compilazione. Ovviamente se avete installato la toolchain con apt non è necessario aggiungere il path a tutti i comandi, perché sono già dentro a /usr/bin.

OpenOCD ci permette di caricare il firmware che abbiamo crosscompilato. Basterà lanciare il comando:
$ openocd -f board/st_nucleo_f4.cfg
Un LED della scheda dovrebbe lampeggiare rosso/verde. Il debugger è attivo. Per collegarcisi:
$ telnet localhost 4444
e poi scrivete:
> reset halt
e infine:
> flash write_image erase <file .elf da flashare>

Inizialmente non sembrava funzionare. Il tentativo finale che ha sbloccato la situazione è stato dare il comando shutdown. Non sono sicuro però che sia stato proprio quel comando e bisognerebbe indagare meglio.

=== Usare MicroPython dall'interprete ===

Aprendo la porta della nostra scheda (la trovate su dmesg non appena la attaccate, è /dev/ttyACMx dove x è un numero che parte da 0) con un emulatore di terminale (come console) alla velocità di 115200 baud, dovreste vedere l'interprete dei comandi (REPL, ovvero Read, Eval, Print and Loop) di MicroPython. Provate a dare il comando:
>>> pyb.LED(1).on()
per vedere se si accende il LED onboard.

=== Usare MicroPython dal PC ===

Fra i tool di MicroPython, che trovate nella cartella di git micropython/tools, c'è pyboard.py, un programma che vi permette di eseguire uno script in MicroPython. Se la vostra porta non è accessibile dall'utente dovrete usare sudo.
# ./pyboard.py <nome file>.py

=== Caricare uno script ===

Carmine ha fatto una modifica a pyboard in modo che possa caricare un file sulla board.
# ./pyboard.py --device=/dev/ttyACMx --send <nome file>.py

MicroPython ha due file di default quando viene installato: boot.py e main.py. Il primo è un file di sistema che serve allo stesso MicroPython di partire. Non occorre di solito modificarlo. Il secondo, main.py, è uno script che viene eseguito all'avvio. Se carichiamo un file main.py questo verrà eseguito all'accensione.

=== Considerazioni finali ===

Molto bene, ma la versione di micropython non è aggiornata. Forse è per questo che non riesco a far funzionare la porta I²C?

== Secondo tentativo ==

Boochow fornisce dei firmware già compilati su https://blog.boochow.com/micropython-firmware-for-mbed-boards basta scegliere la board giusta e caricare il file .bin nel volume "NUCLEO" che si monta quando si collega la USB.

=== Caricare uno script ===

Un modo piuttosto comodo di inviare e ricevere file sulla flash della Nucleo è usare uPyLoader:
https://github.com/BetaRavener/uPyLoader/
ma quasi sempre dà un errore di timeout.

Il programma fornito da Adafruit sembra funzionare decisamente meglio
https://learn.adafruit.com/micropython-basics-load-files-and-run-code/install-ampy

Per installarlo usare pip (o pip3):
pip install adafruit-ampy

Per usarlo:
ampy -p <porta seriale> put <nome file>

= Display OLED I²C =

Per testare il funzionamento di MicroPython, proviamo a usare un piccolo display OLED I²C.

== Caricare la libreria ==

Con ampy carichiamo la [https://github.com/micropython/micropython/blob/master/drivers/display/ssd1306.py libreria ssd1306].

ampy -p /dev/ttyACM0 put ssd1306.py

== Manovrare il display da REPL ==

Se la libreria è stata caricata si può importare scrivendo:

>>> import ssd1306

Occorre poi creare un oggetto I2C specificando quali pin usare per SCL e SDA (in teoria dovrebbe essere automatico, ma secondo [https://forum.micropython.org/viewtopic.php?t=4663 questo post sul forum di micropython] l'automatismo non funziona), la libreria machine dovrebbe essere già importata di default:

>>> pscl = machine.Pin('D15',machine.Pin.OUT_PP)
>>> psda = machine.Pin('D14',machine.Pin.OUT_PP)
>>> i2c = machine.I2C(scl=pscl,sda=psda)

e poi creare un oggetto che gestisca il display:

>>> oled = ssd1306.SSD1306_I2C(128,64,i2c)

dove 128 e 64 sono le dimensioni.

== Test! ==

Per prima cosa occorre cancellare un'eventuale scritta precedente:

>>> oled.fill(0)

Poi scriviamo qualcosa:

>>> oled.text('qualcosa',0,0)

e infine lo mostriamo:

>>> oled.show()

et voilà!

[[File:Micropython_test_oled.jpg]]

Più informazioni su come funziona la libreria, corredata da esempi, le potete trovare sul [https://learn.adafruit.com/micropython-hardware-ssd1306-oled-display/circuitpython sito di Adafruit].

Installare MicroPython su NUCLEO-F401RE

2019-03-09T17:03:00Z

Oloturia: /* Test! */

Questa guida è basata quasi tutta su quella di Carmine Noviello https://www.carminenoviello.com/2015/06/03/running-micropyton-stm32nucleo-f4/ che peraltro trovate anche in italiano https://www.carminenoviello.com/it/2015/08/11/compilare-micropython-una-scheda-stm32nucleo-f4/ per cui scriverò solo le differenze.

La versione di Carmine di micropython, che si trova sul suo [https://github.com/cnoviello/micropython github], risolve il problema relativo alla mancanza di memoria SD della scheda Nucleo. Il file con il programma .py sarà caricato direttamente sulla flash.

= La scheda =

NUCLEO-F401RE della STMicroelectronics è una scheda basata su ARM Cortex M4 e fa parte della famiglia STM32 Nucleo Boards. Ha 512KB di Flash, 96 KB di SRAM, un clock di 84MHz, 50 GPIO, RTC, supporto I²C, SPI, USART e molto altro ([https://os.mbed.com/platforms/ST-Nucleo-F401RE/ maggiori info]). La sua forma le permette di alloggiare sia gli shield per Arduino che le estensioni Morpho di STMicroelectronics.
Il prezzo è abbastanza contenuto (attorno ai 12€ su Mouser) il che ne fa una scheda piuttosto interessante.

Normalmente si programmerebbe tramite l'[https://ide.mbed.com/compiler editor online di Mbed]. Il compilatore genererà dal nostro codice un file con estensione bin. Collegando la scheda verrà montato un volume, chiamato "NUCLEO" sul quale caricare il file bin. Quando la scheda verrà resettata, il codice verrà eseguito. È possibile anche usare editor offline con toolchain di compilazione come Eclipse. Non credo sia possibile usare la IDE di Arduino.

= Installazione MicroPython =

== Primo tentativo ==

=== Toolchain e OpenOCD ===

Per compilare vi servirà la toolchain gcc-arm-embedded. Non è nei repo ufficiali quindi la dovete installare a mano oppure aggiungere un PPA. https://launchpad.net/gcc-arm-embedded
Il programma per comunicare col debugger della scheda, openocd, invece è nei repo di Debian.

=== Come installare MicroPython ===

Potete seguire la guida di Carmine per la compilazione. Ovviamente se avete installato la toolchain con apt non è necessario aggiungere il path a tutti i comandi, perché sono già dentro a /usr/bin.

OpenOCD ci permette di caricare il firmware che abbiamo crosscompilato. Basterà lanciare il comando:
$ openocd -f board/st_nucleo_f4.cfg
Un LED della scheda dovrebbe lampeggiare rosso/verde. Il debugger è attivo. Per collegarcisi:
$ telnet localhost 4444
e poi scrivete:
> reset halt
e infine:
> flash write_image erase <file .elf da flashare>

Inizialmente non sembrava funzionare. Il tentativo finale che ha sbloccato la situazione è stato dare il comando shutdown. Non sono sicuro però che sia stato proprio quel comando e bisognerebbe indagare meglio.

=== Usare MicroPython dall'interprete ===

Aprendo la porta della nostra scheda (la trovate su dmesg non appena la attaccate, è /dev/ttyACMx dove x è un numero che parte da 0) con un emulatore di terminale (come console) alla velocità di 115200 baud, dovreste vedere l'interprete dei comandi (REPL, ovvero Read, Eval, Print and Loop) di MicroPython. Provate a dare il comando:
>>> pyb.LED(1).on()
per vedere se si accende il LED onboard.

=== Usare MicroPython dal PC ===

Fra i tool di MicroPython, che trovate nella cartella di git micropython/tools, c'è pyboard.py, un programma che vi permette di eseguire uno script in MicroPython. Se la vostra porta non è accessibile dall'utente dovrete usare sudo.
# ./pyboard.py <nome file>.py

=== Caricare uno script ===

Carmine ha fatto una modifica a pyboard in modo che possa caricare un file sulla board.
# ./pyboard.py --device=/dev/ttyACMx --send <nome file>.py

MicroPython ha due file di default quando viene installato: boot.py e main.py. Il primo è un file di sistema che serve allo stesso MicroPython di partire. Non occorre di solito modificarlo. Il secondo, main.py, è uno script che viene eseguito all'avvio. Se carichiamo un file main.py questo verrà eseguito all'accensione.

=== Considerazioni finali ===

Molto bene, ma la versione di micropython non è aggiornata. Forse è per questo che non riesco a far funzionare la porta I²C?

== Secondo tentativo ==

Boochow fornisce dei firmware già compilati su https://blog.boochow.com/micropython-firmware-for-mbed-boards basta scegliere la board giusta e caricare il file .bin nel volume "NUCLEO" che si monta quando si collega la USB.

=== Caricare uno script ===

Un modo piuttosto comodo di inviare e ricevere file sulla flash della Nucleo è usare uPyLoader:
https://github.com/BetaRavener/uPyLoader/
ma quasi sempre dà un errore di timeout.

Il programma fornito da Adafruit sembra funzionare decisamente meglio
https://learn.adafruit.com/micropython-basics-load-files-and-run-code/install-ampy

Per installarlo usare pip (o pip3):
pip install adafruit-ampy

Per usarlo:
ampy -p <porta seriale> put <nome file>

= Display OLED I²C =

Per testare il funzionamento di MicroPython, proviamo a usare un piccolo display OLED I²C.

== Caricare la libreria ==

Con ampy carichiamo la [https://github.com/micropython/micropython/blob/master/drivers/display/ssd1306.py libreria ssd1306].

ampy -p /dev/ttyACM0 put ssd1306.py

== Manovrare il display da REPL ==

Se la libreria è stata caricata si può importare scrivendo:

>>> import ssd1306

Occorre poi creare un oggetto I2C specificando quali pin usare per SCL e SDA (in teoria dovrebbe essere automatico, ma secondo [https://forum.micropython.org/viewtopic.php?t=4663 questo post sul forum di micropython] l'automatismo non funziona), la libreria machine dovrebbe essere già importata di default:

>>> pscl = machine.Pin('D15',machine.Pin.OUT_PP)
>>> psda = machine.Pin('D14',machine.Pin.OUT_PP)
>>> i2c = machine.I2C(scl=pscl,sda=psda)

e poi creare un oggetto che gestisca il display:

>>> oled = ssd1306.SSD1306_I2C(128,64,i2c)

dove 128 e 64 sono le dimensioni.

== Test! ==

Per prima cosa occorre cancellare un'eventuale scritta precedente:

>>> oled.fill(0)

Poi scriviamo qualcosa:

>>> oled.text('qualcosa',0,0)

e infine lo mostriamo:

>>> oled.show()

et voilà!

[[File:Micropython_test_oled.jpg]]

Più informazioni su come funziona la libreria, corredata da esempi, le potete trovare sul [https://learn.adafruit.com/micropython-hardware-ssd1306-oled-display/circuitpython sito di Adafruit].

Installare MicroPython su NUCLEO-F401RE

2019-03-09T17:02:41Z

Oloturia:

Questa guida è basata quasi tutta su quella di Carmine Noviello https://www.carminenoviello.com/2015/06/03/running-micropyton-stm32nucleo-f4/ che peraltro trovate anche in italiano https://www.carminenoviello.com/it/2015/08/11/compilare-micropython-una-scheda-stm32nucleo-f4/ per cui scriverò solo le differenze.

La versione di Carmine di micropython, che si trova sul suo [https://github.com/cnoviello/micropython github], risolve il problema relativo alla mancanza di memoria SD della scheda Nucleo. Il file con il programma .py sarà caricato direttamente sulla flash.

= La scheda =

NUCLEO-F401RE della STMicroelectronics è una scheda basata su ARM Cortex M4 e fa parte della famiglia STM32 Nucleo Boards. Ha 512KB di Flash, 96 KB di SRAM, un clock di 84MHz, 50 GPIO, RTC, supporto I²C, SPI, USART e molto altro ([https://os.mbed.com/platforms/ST-Nucleo-F401RE/ maggiori info]). La sua forma le permette di alloggiare sia gli shield per Arduino che le estensioni Morpho di STMicroelectronics.
Il prezzo è abbastanza contenuto (attorno ai 12€ su Mouser) il che ne fa una scheda piuttosto interessante.

Normalmente si programmerebbe tramite l'[https://ide.mbed.com/compiler editor online di Mbed]. Il compilatore genererà dal nostro codice un file con estensione bin. Collegando la scheda verrà montato un volume, chiamato "NUCLEO" sul quale caricare il file bin. Quando la scheda verrà resettata, il codice verrà eseguito. È possibile anche usare editor offline con toolchain di compilazione come Eclipse. Non credo sia possibile usare la IDE di Arduino.

= Installazione MicroPython =

== Primo tentativo ==

=== Toolchain e OpenOCD ===

Per compilare vi servirà la toolchain gcc-arm-embedded. Non è nei repo ufficiali quindi la dovete installare a mano oppure aggiungere un PPA. https://launchpad.net/gcc-arm-embedded
Il programma per comunicare col debugger della scheda, openocd, invece è nei repo di Debian.

=== Come installare MicroPython ===

Potete seguire la guida di Carmine per la compilazione. Ovviamente se avete installato la toolchain con apt non è necessario aggiungere il path a tutti i comandi, perché sono già dentro a /usr/bin.

OpenOCD ci permette di caricare il firmware che abbiamo crosscompilato. Basterà lanciare il comando:
$ openocd -f board/st_nucleo_f4.cfg
Un LED della scheda dovrebbe lampeggiare rosso/verde. Il debugger è attivo. Per collegarcisi:
$ telnet localhost 4444
e poi scrivete:
> reset halt
e infine:
> flash write_image erase <file .elf da flashare>

Inizialmente non sembrava funzionare. Il tentativo finale che ha sbloccato la situazione è stato dare il comando shutdown. Non sono sicuro però che sia stato proprio quel comando e bisognerebbe indagare meglio.

=== Usare MicroPython dall'interprete ===

Aprendo la porta della nostra scheda (la trovate su dmesg non appena la attaccate, è /dev/ttyACMx dove x è un numero che parte da 0) con un emulatore di terminale (come console) alla velocità di 115200 baud, dovreste vedere l'interprete dei comandi (REPL, ovvero Read, Eval, Print and Loop) di MicroPython. Provate a dare il comando:
>>> pyb.LED(1).on()
per vedere se si accende il LED onboard.

=== Usare MicroPython dal PC ===

Fra i tool di MicroPython, che trovate nella cartella di git micropython/tools, c'è pyboard.py, un programma che vi permette di eseguire uno script in MicroPython. Se la vostra porta non è accessibile dall'utente dovrete usare sudo.
# ./pyboard.py <nome file>.py

=== Caricare uno script ===

Carmine ha fatto una modifica a pyboard in modo che possa caricare un file sulla board.
# ./pyboard.py --device=/dev/ttyACMx --send <nome file>.py

MicroPython ha due file di default quando viene installato: boot.py e main.py. Il primo è un file di sistema che serve allo stesso MicroPython di partire. Non occorre di solito modificarlo. Il secondo, main.py, è uno script che viene eseguito all'avvio. Se carichiamo un file main.py questo verrà eseguito all'accensione.

=== Considerazioni finali ===

Molto bene, ma la versione di micropython non è aggiornata. Forse è per questo che non riesco a far funzionare la porta I²C?

== Secondo tentativo ==

Boochow fornisce dei firmware già compilati su https://blog.boochow.com/micropython-firmware-for-mbed-boards basta scegliere la board giusta e caricare il file .bin nel volume "NUCLEO" che si monta quando si collega la USB.

=== Caricare uno script ===

Un modo piuttosto comodo di inviare e ricevere file sulla flash della Nucleo è usare uPyLoader:
https://github.com/BetaRavener/uPyLoader/
ma quasi sempre dà un errore di timeout.

Il programma fornito da Adafruit sembra funzionare decisamente meglio
https://learn.adafruit.com/micropython-basics-load-files-and-run-code/install-ampy

Per installarlo usare pip (o pip3):
pip install adafruit-ampy

Per usarlo:
ampy -p <porta seriale> put <nome file>

= Display OLED I²C =

Per testare il funzionamento di MicroPython, proviamo a usare un piccolo display OLED I²C.

== Caricare la libreria ==

Con ampy carichiamo la [https://github.com/micropython/micropython/blob/master/drivers/display/ssd1306.py libreria ssd1306].

ampy -p /dev/ttyACM0 put ssd1306.py

== Manovrare il display da REPL ==

Se la libreria è stata caricata si può importare scrivendo:

>>> import ssd1306

Occorre poi creare un oggetto I2C specificando quali pin usare per SCL e SDA (in teoria dovrebbe essere automatico, ma secondo [https://forum.micropython.org/viewtopic.php?t=4663 questo post sul forum di micropython] l'automatismo non funziona), la libreria machine dovrebbe essere già importata di default:

>>> pscl = machine.Pin('D15',machine.Pin.OUT_PP)
>>> psda = machine.Pin('D14',machine.Pin.OUT_PP)
>>> i2c = machine.I2C(scl=pscl,sda=psda)

e poi creare un oggetto che gestisca il display:

>>> oled = ssd1306.SSD1306_I2C(128,64,i2c)

dove 128 e 64 sono le dimensioni.

== Test! ==

Per prima cosa occorre cancellare un'eventuale scritta precedente:

>>> oled.fill(0)

Poi scriviamo qualcosa:

>>> oled.text('qualcosa',0,0)

e infine lo mostriamo:

>>> oled.show()

et voilà!
[[File:Micropython_test_oled.jpg]]

Più informazioni su come funziona la libreria, corredata da esempi, le potete trovare sul [https://learn.adafruit.com/micropython-hardware-ssd1306-oled-display/circuitpython sito di Adafruit].

File:Micropython test oled.jpg

2019-03-09T17:00:51Z

Oloturia:

Ardubottino

2019-03-05T15:44:03Z

Oloturia: /* Il codice */

Ardubottino è stato creato soprattutto per testare tre componenti: l'Arduino, il sensore della distanza a ultrasuoni e il ponte ad H. Lo chassis e i motori sono Tamiya.

[[File:Ardubottino.jpg]]

= Prima Versione =

== Componenti ==
Ardubottino ha questi componenti:
* Arduino UNO [http://arduino.cc/en/Main/arduinoBoardUno]
* Sensore di distanza a ultrasuoni SRF05 [http://www.robot-electronics.co.uk/htm/srf05tech.htm]
* Il board con montato il ponte ad H L298 [http://www.vetco.net/catalog/product_info.php?products_id=14337]
* Kit Tamiya per lo chassis e i motori
* Batteria da 9v
* Ulteriori batterie per il motore (inizialmente 4,5v, poi 4,8v)

Il sensore di distanza è sprovvisto di pin, occorre quindi saldarne una strip prima di procedere.

== Il sensore di distanza a ultrasuoni SRF05 ==
[[File:102_1298.JPG]]

È piuttosto semplice da usare. Seguendo le istruzioni [ http://www.robot-electronics.co.uk/htm/srf05tech.htm trovate qui] si può notare che ha due modalità di comunicazioni, date dal pin Mode. Se questo pin è collegato alla 0v il sensore userà un solo pin per la comunicazione dei dati dell'eco (Echo) e la ricezione dei comandi (Trigger), se, al contrario, non è connesso a niente allora saranno usati due pin diversi. Nel caso dell'Ardubottino ho preferito usare la prima modalità, quella con un pin solo (soprattutto per pigrizia: perché è già così lo sketch di esempio "ping" nella libreria di Arduino!). Oltre al pin Mode e al pin Trigger/Echo occorre collegare il primo e l'ultimo pin rispettivamente a +5v e a terra.
Nella foto si può vedere, da sinistra: +5v, non usato, Trigger/Echo (collegato al pin 13 di Arduino), Mode (terra), Terra (terra).

== Il board ponte ad H L298 ==
[[File:Ardubottino_dettagliol298.jpg]]

Il ponte ad H L298 è utilissimo per manovrare due motori indipendenti. Può essere usato anche per muovere un motore passo-passo.
Ha due ingressi per la corrente: tramite un ponticello può essere separata fra corrente per la logica e corrente per i motori. La logica dev'essere alimentata da +5v; se l'alimentazione è separata, i motori possono ricevere fino a +12v. Per comodità (e anche dopo diversi goffi tentativi per capire come funzionava) ho preferito alimentare i motori solo con i 5v.

Sui lati ci sono le connessioni per i motori mentre, a fianco dell'alimentazione, ci sono i pin che servono per comandarli. I pin sono sei, due sono gli enable per i motori e quattro servono per dare la direzione, due per motore. I pin dell'enable si possono chiudere con dei ponticelli, comandarli da Arduino/Raspberry Pi oppure gli si può mandare un impulso PWM per regolare la velocità.

== Motori ad encoder, gioie (poche) e dolorer (tanto) ==
Il problema di Ardubottino è che non va dritto. Il motivo? Forse il ponte ad H non dà gli stessi voltaggi ai motori, forse i motori sono un po' diversi, forse si stanno usurando in modo diverso, forse i cingoli hanno qualche imperfezione, forse le ruote sono storte, forse è sbilanciato. Ad ogni modo ognuno di questi problemi (tranne le ruote storte e le imperfezioni dei cingoli) si sarebbero risolti scoprendo a che velocità vanno i motori. Per scoprire questo dato sono necessari gli encoder. Un encoder è una rotellina con dei fori e un sensore o due, composti da un LED e da un ricevitore a infrarossi, che sentono quando un foro è passato. Encoder di questo tipo si trovano ad esempio nelle rotelline dei mouse o in quelli che hanno ancora la pallina.

[[File:EncoderArdubottino.JPG]]

Ora: questi sarebbero degli encoder "fatti apposta" per il kit Tamiya. Uso il condizionale perché, se non sono stato io ad averli montati in modo approssimativo, il loro utilizzo è alquanto scomodo. Anzitutto la rotella non sta fissa sull'albero. Il foro esagonale è troppo grande e ha un notevole gioco. Il range del sensore è minimo e non tiene conto della struttura del kit Tamiya (la rotella va quasi a sfregare contro le viti che lo fissano allo chassis). Inoltre sono estremamente fragili: una delle rotelle si è spaccata subito in due. I sensori stessi, poi, non si incastrano nella sede e occorre incollarli.
La lettura degli encoder andrebbe fatta sfruttando gli interrupt di Arduino. Gli interrupt sono dei pin che restano in ascolto e fanno scattare degli eventi quando cambiano valore[http://arduino.cc/en/Reference/AttachInterrupt]. Purtroppo uno dei due pin (sull'Arduino Uno sono il pin 2 e il pin 3) dava dei risultati estremamente inaffidabili. Dopo varie prove, il risultato migliore l'ho ottenuto usando la libreria Encoder [http://www.pjrc.com/teensy/td_libs_Encoder.html] su due pin non di interrupt. Il risultato di tutta questa fatica è un robottino che grosso modo va dritto. Un risultato mediocre di molto inferiore alla calibrazione a occhio. Alla fine, infatti, ho preferito quest'ultima.

== Lo sketch ==

Lo sketch deriva per una parte dall'esempio ''Ping'' già presente nella libreria di Arduino. In pratica fa avanzare Ardubottino fino a che non incontra un ostacolo. Se lo incontra sterza in un senso e poi nell'altro e alla fine prosegue per la direzione dove ha trovato più campo libero.
4 7 6 5 sono i pin a cui ho collegato il ponte ad H. Sterzo è il tempo che deve impiegare per sterzare. pinping è il pin a cui è attaccato il trigger/echo del sensore a ultrasuoni.
long duration;
long dursx;
long durdx;
const int en1 = 11; //pin enable
const int en2 = 9;
const int m1fd = 4; //controlli motore
const int m2fd = 7;
const int m1bk = 5;
const int m2bk = 6;
const int pinping = 13; //pin sensore distanza
const int sterzo = 600; //durata dello sterzo
const int distanza = 500; //distanza minima ostacoli
int motore1 = 67;//pwm motore dx
int motore2 = 74;//pwm motore sx

void setup() {
pinMode(m1fd, OUTPUT);
pinMode(m1bk, OUTPUT);
pinMode(m2fd, OUTPUT);
pinMode(m2bk, OUTPUT);
pinMode(en1, OUTPUT);
pinMode(en2, OUTPUT);
analogWrite(en1,motore1);
analogWrite(en2,motore2);
dritto();
}

void loop() {
if (echo() < distanza){ //trovato un ostacolo
analogWrite(en1,170);
analogWrite(en2,170);
ferma();
sinistra();
delay(sterzo);
ferma();
dursx = echo(); //guarda a sinistra
destra();
delay(sterzo*2);
ferma();
durdx = echo(); //guarda a destra
if (dursx < distanza && durdx < distanza){
destra();
delay(sterzo);
} else if (dursx > durdx) {
sinistra();
delay(sterzo*2);
} //sceglie dove c'è più spazio
dritto();
analogWrite(en1,motore1);
analogWrite(en2,motore2);
}
}

void dritto() {
digitalWrite(m1bk,LOW);
digitalWrite(m2bk,LOW);
digitalWrite(m2fd,HIGH);
digitalWrite(m1fd,HIGH);
}

void rovescia() {
digitalWrite(m1fd,LOW);
digitalWrite(m2fd,LOW);
digitalWrite(m1bk,HIGH);
digitalWrite(m2bk,HIGH);
}

void destra() {
digitalWrite(m1fd,LOW);
digitalWrite(m2fd,HIGH);
digitalWrite(m1bk,HIGH);
digitalWrite(m2bk,LOW);
}

void sinistra() {
digitalWrite(m1fd,HIGH);
digitalWrite(m2fd,LOW);
digitalWrite(m1bk,LOW);
digitalWrite(m2bk,HIGH);
}

void ferma() {
digitalWrite(m1fd,LOW);
digitalWrite(m2fd,LOW);
digitalWrite(m1bk,LOW);
digitalWrite(m2bk,LOW);
delay(50);
}

long echo() {
pinMode(pinping, OUTPUT);
digitalWrite(pinping, LOW);
delayMicroseconds(2);
digitalWrite(pinping, HIGH);
delayMicroseconds(5);
digitalWrite(pinping, LOW);
pinMode(pinping, INPUT);
duration = pulseIn(pinping,HIGH);
return duration;
}

= Seconda Versione =
Ok, la modifica è un po' minima per essere una vera e propria seconda versione, ma dopo il fallimento degli encoder ero un po' giù di morale.
Il progetto era di rendere Ardubottino telecomandabile con qualche mezzo estremamente low cost e nella maniera più semplice possibile. La mia scelta è caduta sull'infrarosso.

== Il sensore a infrarossi ==
[[File:Arduir.jpg]]

Quello che potete vedere nella foto è un sensore a infrarossi come quelli che potreste recuperare in qualsivoglia elettrodomestico. I sensori IR hanno tre pin: +5v, terra e dati. Questo in particolare aveva le stesse specifiche di quest'altro[http://learn.adafruit.com/ir-sensor/testing-an-ir-sensor] usato nel tutorial di Adafruit per leggere gli impulsi infrarossi con Arduino. Potrebbero non essere tutti uguali, quindi cautela.

== La libreria IRremote ==
Gran parte del lavoro lo fa la libreria IRremote (che trovate qui [https://github.com/shirriff/Arduino-IRremote]). Con questo sketch [http://www.mediafire.com/view/6qnsndqp9a838xe/Decode_IR.ino] si possono leggere, sotto forma di cifre, i codici del telecomando che volete usare. Tramite il monitor seriale noterete dapprincipio che ogni tasto ha assegnato due codici, questo per fare in modo che ci sia una differenza fra tenere premuto il tasto (dà lo stesso codice in uscita, in modo continuo) e dei clic ripetuti (ogni clic diverso il codice cambia). Con questo sketch sono riuscito a capire che il codice del tasto SU del telecomando era legato ai codici 2742014623 e 31889539.
La libreria IRremote permette anche di trasmettere, ma per ora non sfrutteremo questa sua proprietà. Potete trovare più informazioni qui [http://www.righto.com/2009/08/multi-protocol-infrared-remote-library.html]

== Lo sketch finale ==
Non ho voluto togliere all'Ardubottino la possibilità di andarsene in giro da solo, quindi ho assegnato al tasto OK del telecomando la capacità di passare dallo stato manuale a quello automatico.
La libreria IRremote ci permette di creare la classe IRrecv che, tramite i suoi metodi, prepara (enableIrIN) , legge (decode), e aspetta il prossimo segnale (resume). I valori sono memorizzati nella struttura decode_results, il cui valore value è il codice del segnale del telecomando. La variabile booleana automat determina se Ardubottino è in modalità automatica o meno.

<span style="color:#FF0000">ATTENZIONE: La libreria IRremote.h non è compatibile con la libreria RobotIRRemote fornita con l'ultima versione della IDE di Arduino. Per compilare questo sketch occorre prima disabilitare RobotIRRemote. Per disabilitare una libreria occorre andare in arduino/libraries e spostare la cartella della libreria in un altro posto.</span>

#include <IRremote.h>

int IRpin =2; //pin del sensore IR
IRrecv irrecv(IRpin);
long duration;
long dursx;
long durdx;

const int en1 = 10; //pin enable
const int en2 = 9;
const int m1fd = 4; //controlli motore
const int m2fd = 7;
const int m1bk = 5;
const int m2bk = 6;
const int pinping = 13; //pin sensore distanza
const int sterzo = 600; //durata dello sterzo
const int distanza = 500; //distanza minima ostacoli
int motore1 = 66;//pwm motore dx
int motore2 = 72;//pwm motore sx
boolean automat = false;

decode_results results;

void setup() {
pinMode(m1fd, OUTPUT);
pinMode(m1bk, OUTPUT);
pinMode(m2fd, OUTPUT);
pinMode(m2bk, OUTPUT);
pinMode(en1, OUTPUT);
pinMode(en2, OUTPUT);
analogWrite(en1,motore1);
analogWrite(en2,motore2);
irrecv.enableIRIn();
}

void loop() {
if(irrecv.decode(&results)){
if (!automat) {
if(results.value == 2742014623 || results.value == 31889539){
dritto();
} else if (results.value == 2383694249 || results.value == 2039764837 ) {
sinistra();
} else if (results.value == 15111918 || results.value == 2725237002) {
rovescia();
} else if (results.value == 1665824360 || results.value == 3250666572 ) {
destra();
} else {
ferma();
}
}
if (results.value == 3969632309 || results.value == 18594425) {
if (automat) {
automat = false;
ferma();
delayMicroseconds(300000);
}else{
automat = true;
dritto();
delayMicroseconds(300000);
}
}
irrecv.resume();
}
if (automat && echo() < distanza){ //trovato un ostacolo
analogWrite(en1,170);
analogWrite(en2,170);
ferma();
sinistra();
delay(sterzo);
ferma();
dursx = echo(); //guarda a sinistra
destra();
delay(sterzo*2);
ferma();
durdx = echo(); //guarda a destra
if (dursx < distanza && durdx < distanza){
destra();
delay(sterzo);
} else if (dursx > durdx) {
sinistra();
delay(sterzo*2);
} //sceglie dove c'è più spazio
dritto();
analogWrite(en1,motore1);
analogWrite(en2,motore2);
}
}

void dritto() {
digitalWrite(m1bk,LOW);
digitalWrite(m2bk,LOW);
digitalWrite(m2fd,HIGH);
digitalWrite(m1fd,HIGH);
}

void rovescia() {
digitalWrite(m1fd,LOW);
digitalWrite(m2fd,LOW);
digitalWrite(m1bk,HIGH);
digitalWrite(m2bk,HIGH);
}

void destra() {
digitalWrite(m1fd,LOW);
digitalWrite(m2fd,HIGH);
digitalWrite(m1bk,HIGH);
digitalWrite(m2bk,LOW);
}

void sinistra() {
digitalWrite(m1fd,HIGH);
digitalWrite(m2fd,LOW);
digitalWrite(m1bk,LOW);
digitalWrite(m2bk,HIGH);
}

void ferma() {
digitalWrite(m1fd,LOW);
digitalWrite(m2fd,LOW);
digitalWrite(m1bk,LOW);
digitalWrite(m2bk,LOW);
delay(50);
}

long echo() {
pinMode(pinping, OUTPUT);
digitalWrite(pinping, LOW);
delayMicroseconds(2);
digitalWrite(pinping, HIGH);
delayMicroseconds(5);
digitalWrite(pinping, LOW);
pinMode(pinping, INPUT);
duration = pulseIn(pinping,HIGH);
return duration;
}

= Terza Versione =
Dopo l'ennesimo disastroso trasporto di Ardubottino, nel quale si è smontato tutto, ho deciso di dargli una sistemata definitiva. Saldature migliori, componenti fissati e meno fili volanti. Inoltre sono state fatte le seguenti modifiche.

[[File:ardubottino_3ver.jpg]]

== Passaggio dal Micro al Pro Mini ==
Per ragioni di spazio sono passato dall'Arduino Micro al Pro Mini della Deek Robots.

[[File:Newardbot2.JPG]]

C'è poco da dire su questa board. È sotto tutti gli aspetti un Arduino Pro Mini. Per essere programmato ha bisogno dell'adattatore USB. Purtroppo, come si può vedere nell'immagine, l'ho montato alla rovescia sulla breadboard e così non è possibile capire il numero dei pin. Capirci qualcosa è stato particolarmente ostico.

== Abbastanza batterie ==
Avere l'alimentazione separata motori/logica è una soluzione che non mi soddisfa per niente. Come fare però per fare in modo che gli spikes dei motori non facciano riavviare l'Arduino? La questione è stata risolta in questa maniera.

=== Condensatori ===
Sono stati aggiunti dei condensatori ai motori. In questo modo lo spike dovrebbe essere assorbito in parte.

=== L'Arduino e i motori hanno una sorgente comune ===
Le batterie dei motori, 4 stilo da 2100mAh l'una, hanno amperaggio più che sufficiente per tenere acceso Arduino e motori. Dal + delle batterie partono due fili, uno va all'Arduino e l'altro al ponte ad H. Nei tentativi precedenti, davo al ponte ad H l'uscita a 5v dell'Arduino. Evidentemente la richiesta dei motori era eccessiva per il regolatore a 5v.

== Turbo! ==
Aggiunta la modalità turbo, che fa andare il ns. robot più veloce!

== Altri problemi ==
Avrei voluto mettere il sensore a ultrasuoni su un servo ma un bug della libreria Servo blocca il PWM in alcuni pin[http://forum.arduino.cc/index.php?topic=243264.0] per cui ho lasciato perdere.

== Nuovo codice! ==
Inutile incollarlo qui. Ho aperto uno spazio su GitHub:

[https://github.com/raspibo/ardubottino Link]

= Quarta versione =
Era giunto il momento di sfruttare un po' di roba che rimaneva inutilizzata.
Le modifiche sono state:

* Encoder, stavolta funzionanti
* Calibrazione automatica
* Modalità programmazione
* Blocco quando una ruota non gira
* Sensore di caduta

== Encoders ==
Nonostante abbia rotto le rondelle originali (che comunque erano fatte malissimo) sono riuscito a trovare alcuni modelli funzionanti. Il PLA azzurro, a differenza di quello bianco e di quello nero, sembra riflettere l'infrarosso dell'encoder. Tutto stava nel capire quale forma funzionasse meglio.

[[File:Arduencoder.JPG]]

La forma che funziona meglio (per ora) è quella a destra. Potete trovare l'STL nel [https://github.com/raspibo/ardubottino repository ardubottino su GitHub].

Il problema principale, nel creare questo tipo di oggetto in 3D, è stato il foro a forma di prisma esagonale. In Blender occorre creare un cilindro, ridurre i vertici a 6 e poi modificarne la dimensione solo con lo strumento proporzionale, in modo da non deformarlo.

[[File:Newardbot3.JPG]]

Gli encoder permettono di fare diverse cose interessanti. Ora Ardubottino sente quando una ruota non sta girando, ad esempio, inoltre sono state aggiunte due nuove modalità: la modalità "programmazione" (vai avanti di 10, poi gira a destra di 5, ecc.) e la modalità "calibrazione" (modifica la velocità di un motore fino a che le ruote non girano più o meno uguali).

Purtroppo gli encoder non sono tanto precisi, ogni tanto leggono male e segnano un passo in più o in meno. Questo però era così anche con le rotelle originali.

== Il sensore di caduta ==
Posto sul davanti, sente quando ad Ardubottino manca la terra sotto i cingoli. Quando sente il vuoto ferma tutto.

[[File:Newardbot1.JPG]]

== Il codice ==
Il codice sta diventando veramente troppo lungo per essere incollato qui, su questa pagina, per cui ne commenterò solo alcune parti. Lo sketch completo lo trovate su [https://github.com/raspibo/ardubottino GitHub].

#include "ardubottino.h"
Sì, era ora che creassi un header con tutti i codici del telecomando. Per adattare Ardubottino a un altro telecomando basterà cambiare header.

volatile long right_interval = 0;
volatile long left_interval = 0;
volatile int right_count = 0;
volatile int left_count = 0;

Le variabili che sono modificate dagli encoder devono essere di tipo "volatile". Le variabili volatile possono essere cambiate da un evento esterno, nel nostro caso da un evento scatenato da un interrupt.

void right_encoder() {
static unsigned long last_interrupt = 0;
unsigned long time_interrupt = micros();
if(time_interrupt - last_interrupt >5000){
right_interval = time_interrupt - last_interrupt;
next_check_right = micros()+right_interval*2;
right_count +=1;
last_interrupt = time_interrupt;
}
}

void left_encoder() {
static unsigned long last_interrupt = 0;
unsigned long time_interrupt = micros();
if(time_interrupt - last_interrupt >5000) {
left_interval = time_interrupt - last_interrupt;
next_check_left = micros()+left_interval*2;
left_count +=1;
last_interrupt = time_interrupt;
}
}

Ecco le brevi funzioni chiamate da
attachInterrupt(0, right_encoder,RISING);
attachInterrupt(1, left_encoder,RISING);
gli interrupt.
La variabile x_count conta quanti giri (quanti quarti di giro) ha fatto la ruota; x_interval l'intervallo, in millisecondi, fra un passaggio e l'altro; next_check_x è una stima massima di quando dovrebbe essere il prossimo passaggio, serve per capire se una ruota s'è inceppata.

if (irrecv.decode(&results)) {
curr_result = results.value;
if (curr_result == prev_result) {
curr_result = 0;
} else {
prev_result = curr_result;
}
(...)
}

Ricordate quando vi dissi che il telecomando per ogni tasto ha due codici? Serve per distinguere se state tenendo premuto il tasto o se lo state premendo più volte contemporaneamente. Con questo piccolo brandello di codice faccio in modo di ignorare i codici ripetuti, visto che ad Ardubottino non servono. Non tutti i telecomandi funzionano così.
if (program) {
if (curr_result == OKA || curr_result == OKB) {
blinkOK();
executeProgram();
clearMoves();
noMotion();
} else if (curr_result == NUM1A || curr_result == NUM1B) {
moves[pointer][0] = (moves[pointer][0]*10) +1;
blinkOK();
} else if (curr_result == NUM2A || curr_result == NUM2A) {
moves[pointer][0] = (moves[pointer][0]*10) +2;
blinkOK();
} else if (curr_result == NUM3A || curr_result == NUM3B) {
moves[pointer][0] = (moves[pointer][0]*10) +3;
blinkOK();
} else if (curr_result == NUM4A || curr_result == NUM4B) {
moves[pointer][0] = (moves[pointer][0]*10) +4;
blinkOK();
} else if (curr_result == NUM5A || curr_result == NUM5B) {
moves[pointer][0] = (moves[pointer][0]*10) +5;
blinkOK();
} else if (curr_result == NUM6A || curr_result == NUM6B) {
moves[pointer][0] = (moves[pointer][0]*10) +6;
blinkOK();
} else if (curr_result == NUM7A || curr_result == NUM7B) {
moves[pointer][0] = (moves[pointer][0]*10) +7;
blinkOK();
} else if (curr_result == NUM8A || curr_result == NUM8B) {
moves[pointer][0] = (moves[pointer][0]*10) +8;
blinkOK();
} else if (curr_result == NUM9A || curr_result == NUM9B) {
moves[pointer][0] = (moves[pointer][0]*10) +9;
blinkOK();
} else if (curr_result == NUM0A || curr_result == NUM0B) {
moves[pointer][0] = (moves[pointer][0]*10);
blinkOK();
} else if (curr_result == FORWARDA || curr_result == FORWARDB) {
moves[pointer][1] = 1;
pointer ++;
blinkOK();
} else if (curr_result == BACKA || curr_result == BACKB) {
moves[pointer][1] = 2;
pointer ++;
blinkOK();
} else if (curr_result == LEFTA || curr_result == LEFTB) {
moves[pointer][1] = 3;
pointer ++;
blinkOK();
} else if (curr_result == RIGHTA || curr_result == RIGHTB) {
moves[pointer][1] = 4;
pointer ++;
blinkOK();
} else if (curr_result == WINA || curr_result == WINB) {
clearMoves();
blinkOK();
} else {
blinkNO();
}
if(moves[pointer][0] > 99) {
moves[pointer][0] = moves[pointer][0]-((moves[pointer][0]/100)*100);
}
if (pointer >49) {
executeProgram();
}
}

Et voilà: 50 mosse programmabili per il nostro robottino. Si scrive un numero di massimo 2 cifre e una direzione per massimo 50 istruzioni. Premendo OK si dà inizio al programma.
Ho anche aggiunto un lampeggiamento del LED di bordo in modo da dare un feedback visivo. Come ben saprete, i telecomandi a volte non trasmettono bene.

void executeProgram() {
int right_count_program = right_count;

for (int x=0;x<=49;x++){
if (moves[x][1] == 0) {
break;
} else if (moves[x][1] == 1){
forward();
} else if (moves[x][1] == 2){
backward();
} else if (moves[x][1] == 3){
left();
} else if (moves[x][1] == 4){
right();
}
while(moves[x][0] > 0) {
if (right_count_program != right_count ) {
moves[x][0] --;
right_count_program = right_count;

}
if (digitalRead(fall)) {
noMotion();
program = false;
return;
}
}
moves[x][1] = 0;
}
program = false;
noMotion();
}

Come potete vedere a metà c'è anche un check (c'è anche per le modalità automatica e manuale) sul sensore di caduta.

if (curr_result == BLUEA|| curr_result == BLUEB) { //calibration
blinkOK();
program = false;
automat = false;
noMotion();
delay(500);
forward();
int loops = 0;
int last_left = left_count;
int last_right = right_count;
bool left_pass = false;
bool right_pass = false;
while (loops < 12) {
if (last_left != left_count) {
left_pass = true;
}
if (last_right != right_count) {
right_pass = true;
}
if (left_pass && right_pass) {
left_pass = false;
right_pass = false;
last_left = left_count;
last_right = right_count;
if (abs(right_interval - left_interval) < 80) {
loops +=1;
} else if (right_interval > left_interval) {
motor1PWM += 1;
analogWrite(en1,motor1PWM);
loops = 0;
} else {
motor1PWM -= 1;
analogWrite(en1,motor1PWM);
loops = 0;
}
if(debug) {
Serial.print(motor1PWM);
Serial.print(" ");
Serial.println(motor2PWM);
}
}
}
noMotion();
}

La calibrazione: modifica la potenza di uno dei due motori fino a che gli intervalli degli encoder delle due ruote non sono quasi uguali. Occorre staccare i cingoli o mettere Ardubottino in un posto sopraelevato perché per funzionare ha bisogno di andare forward() per qualche minuto.

[[Category:Progetti]]

Ardubottino

2019-03-05T15:30:26Z

Oloturia:

Ardubottino è stato creato soprattutto per testare tre componenti: l'Arduino, il sensore della distanza a ultrasuoni e il ponte ad H. Lo chassis e i motori sono Tamiya.

[[File:Ardubottino.jpg]]

= Prima Versione =

== Componenti ==
Ardubottino ha questi componenti:
* Arduino UNO [http://arduino.cc/en/Main/arduinoBoardUno]
* Sensore di distanza a ultrasuoni SRF05 [http://www.robot-electronics.co.uk/htm/srf05tech.htm]
* Il board con montato il ponte ad H L298 [http://www.vetco.net/catalog/product_info.php?products_id=14337]
* Kit Tamiya per lo chassis e i motori
* Batteria da 9v
* Ulteriori batterie per il motore (inizialmente 4,5v, poi 4,8v)

Il sensore di distanza è sprovvisto di pin, occorre quindi saldarne una strip prima di procedere.

== Il sensore di distanza a ultrasuoni SRF05 ==
[[File:102_1298.JPG]]

È piuttosto semplice da usare. Seguendo le istruzioni [ http://www.robot-electronics.co.uk/htm/srf05tech.htm trovate qui] si può notare che ha due modalità di comunicazioni, date dal pin Mode. Se questo pin è collegato alla 0v il sensore userà un solo pin per la comunicazione dei dati dell'eco (Echo) e la ricezione dei comandi (Trigger), se, al contrario, non è connesso a niente allora saranno usati due pin diversi. Nel caso dell'Ardubottino ho preferito usare la prima modalità, quella con un pin solo (soprattutto per pigrizia: perché è già così lo sketch di esempio "ping" nella libreria di Arduino!). Oltre al pin Mode e al pin Trigger/Echo occorre collegare il primo e l'ultimo pin rispettivamente a +5v e a terra.
Nella foto si può vedere, da sinistra: +5v, non usato, Trigger/Echo (collegato al pin 13 di Arduino), Mode (terra), Terra (terra).

== Il board ponte ad H L298 ==
[[File:Ardubottino_dettagliol298.jpg]]

Il ponte ad H L298 è utilissimo per manovrare due motori indipendenti. Può essere usato anche per muovere un motore passo-passo.
Ha due ingressi per la corrente: tramite un ponticello può essere separata fra corrente per la logica e corrente per i motori. La logica dev'essere alimentata da +5v; se l'alimentazione è separata, i motori possono ricevere fino a +12v. Per comodità (e anche dopo diversi goffi tentativi per capire come funzionava) ho preferito alimentare i motori solo con i 5v.

Sui lati ci sono le connessioni per i motori mentre, a fianco dell'alimentazione, ci sono i pin che servono per comandarli. I pin sono sei, due sono gli enable per i motori e quattro servono per dare la direzione, due per motore. I pin dell'enable si possono chiudere con dei ponticelli, comandarli da Arduino/Raspberry Pi oppure gli si può mandare un impulso PWM per regolare la velocità.

== Motori ad encoder, gioie (poche) e dolorer (tanto) ==
Il problema di Ardubottino è che non va dritto. Il motivo? Forse il ponte ad H non dà gli stessi voltaggi ai motori, forse i motori sono un po' diversi, forse si stanno usurando in modo diverso, forse i cingoli hanno qualche imperfezione, forse le ruote sono storte, forse è sbilanciato. Ad ogni modo ognuno di questi problemi (tranne le ruote storte e le imperfezioni dei cingoli) si sarebbero risolti scoprendo a che velocità vanno i motori. Per scoprire questo dato sono necessari gli encoder. Un encoder è una rotellina con dei fori e un sensore o due, composti da un LED e da un ricevitore a infrarossi, che sentono quando un foro è passato. Encoder di questo tipo si trovano ad esempio nelle rotelline dei mouse o in quelli che hanno ancora la pallina.

[[File:EncoderArdubottino.JPG]]

Ora: questi sarebbero degli encoder "fatti apposta" per il kit Tamiya. Uso il condizionale perché, se non sono stato io ad averli montati in modo approssimativo, il loro utilizzo è alquanto scomodo. Anzitutto la rotella non sta fissa sull'albero. Il foro esagonale è troppo grande e ha un notevole gioco. Il range del sensore è minimo e non tiene conto della struttura del kit Tamiya (la rotella va quasi a sfregare contro le viti che lo fissano allo chassis). Inoltre sono estremamente fragili: una delle rotelle si è spaccata subito in due. I sensori stessi, poi, non si incastrano nella sede e occorre incollarli.
La lettura degli encoder andrebbe fatta sfruttando gli interrupt di Arduino. Gli interrupt sono dei pin che restano in ascolto e fanno scattare degli eventi quando cambiano valore[http://arduino.cc/en/Reference/AttachInterrupt]. Purtroppo uno dei due pin (sull'Arduino Uno sono il pin 2 e il pin 3) dava dei risultati estremamente inaffidabili. Dopo varie prove, il risultato migliore l'ho ottenuto usando la libreria Encoder [http://www.pjrc.com/teensy/td_libs_Encoder.html] su due pin non di interrupt. Il risultato di tutta questa fatica è un robottino che grosso modo va dritto. Un risultato mediocre di molto inferiore alla calibrazione a occhio. Alla fine, infatti, ho preferito quest'ultima.

== Lo sketch ==

Lo sketch deriva per una parte dall'esempio ''Ping'' già presente nella libreria di Arduino. In pratica fa avanzare Ardubottino fino a che non incontra un ostacolo. Se lo incontra sterza in un senso e poi nell'altro e alla fine prosegue per la direzione dove ha trovato più campo libero.
4 7 6 5 sono i pin a cui ho collegato il ponte ad H. Sterzo è il tempo che deve impiegare per sterzare. pinping è il pin a cui è attaccato il trigger/echo del sensore a ultrasuoni.
long duration;
long dursx;
long durdx;
const int en1 = 11; //pin enable
const int en2 = 9;
const int m1fd = 4; //controlli motore
const int m2fd = 7;
const int m1bk = 5;
const int m2bk = 6;
const int pinping = 13; //pin sensore distanza
const int sterzo = 600; //durata dello sterzo
const int distanza = 500; //distanza minima ostacoli
int motore1 = 67;//pwm motore dx
int motore2 = 74;//pwm motore sx

void setup() {
pinMode(m1fd, OUTPUT);
pinMode(m1bk, OUTPUT);
pinMode(m2fd, OUTPUT);
pinMode(m2bk, OUTPUT);
pinMode(en1, OUTPUT);
pinMode(en2, OUTPUT);
analogWrite(en1,motore1);
analogWrite(en2,motore2);
dritto();
}

void loop() {
if (echo() < distanza){ //trovato un ostacolo
analogWrite(en1,170);
analogWrite(en2,170);
ferma();
sinistra();
delay(sterzo);
ferma();
dursx = echo(); //guarda a sinistra
destra();
delay(sterzo*2);
ferma();
durdx = echo(); //guarda a destra
if (dursx < distanza && durdx < distanza){
destra();
delay(sterzo);
} else if (dursx > durdx) {
sinistra();
delay(sterzo*2);
} //sceglie dove c'è più spazio
dritto();
analogWrite(en1,motore1);
analogWrite(en2,motore2);
}
}

void dritto() {
digitalWrite(m1bk,LOW);
digitalWrite(m2bk,LOW);
digitalWrite(m2fd,HIGH);
digitalWrite(m1fd,HIGH);
}

void rovescia() {
digitalWrite(m1fd,LOW);
digitalWrite(m2fd,LOW);
digitalWrite(m1bk,HIGH);
digitalWrite(m2bk,HIGH);
}

void destra() {
digitalWrite(m1fd,LOW);
digitalWrite(m2fd,HIGH);
digitalWrite(m1bk,HIGH);
digitalWrite(m2bk,LOW);
}

void sinistra() {
digitalWrite(m1fd,HIGH);
digitalWrite(m2fd,LOW);
digitalWrite(m1bk,LOW);
digitalWrite(m2bk,HIGH);
}

void ferma() {
digitalWrite(m1fd,LOW);
digitalWrite(m2fd,LOW);
digitalWrite(m1bk,LOW);
digitalWrite(m2bk,LOW);
delay(50);
}

long echo() {
pinMode(pinping, OUTPUT);
digitalWrite(pinping, LOW);
delayMicroseconds(2);
digitalWrite(pinping, HIGH);
delayMicroseconds(5);
digitalWrite(pinping, LOW);
pinMode(pinping, INPUT);
duration = pulseIn(pinping,HIGH);
return duration;
}

= Seconda Versione =
Ok, la modifica è un po' minima per essere una vera e propria seconda versione, ma dopo il fallimento degli encoder ero un po' giù di morale.
Il progetto era di rendere Ardubottino telecomandabile con qualche mezzo estremamente low cost e nella maniera più semplice possibile. La mia scelta è caduta sull'infrarosso.

== Il sensore a infrarossi ==
[[File:Arduir.jpg]]

Quello che potete vedere nella foto è un sensore a infrarossi come quelli che potreste recuperare in qualsivoglia elettrodomestico. I sensori IR hanno tre pin: +5v, terra e dati. Questo in particolare aveva le stesse specifiche di quest'altro[http://learn.adafruit.com/ir-sensor/testing-an-ir-sensor] usato nel tutorial di Adafruit per leggere gli impulsi infrarossi con Arduino. Potrebbero non essere tutti uguali, quindi cautela.

== La libreria IRremote ==
Gran parte del lavoro lo fa la libreria IRremote (che trovate qui [https://github.com/shirriff/Arduino-IRremote]). Con questo sketch [http://www.mediafire.com/view/6qnsndqp9a838xe/Decode_IR.ino] si possono leggere, sotto forma di cifre, i codici del telecomando che volete usare. Tramite il monitor seriale noterete dapprincipio che ogni tasto ha assegnato due codici, questo per fare in modo che ci sia una differenza fra tenere premuto il tasto (dà lo stesso codice in uscita, in modo continuo) e dei clic ripetuti (ogni clic diverso il codice cambia). Con questo sketch sono riuscito a capire che il codice del tasto SU del telecomando era legato ai codici 2742014623 e 31889539.
La libreria IRremote permette anche di trasmettere, ma per ora non sfrutteremo questa sua proprietà. Potete trovare più informazioni qui [http://www.righto.com/2009/08/multi-protocol-infrared-remote-library.html]

== Lo sketch finale ==
Non ho voluto togliere all'Ardubottino la possibilità di andarsene in giro da solo, quindi ho assegnato al tasto OK del telecomando la capacità di passare dallo stato manuale a quello automatico.
La libreria IRremote ci permette di creare la classe IRrecv che, tramite i suoi metodi, prepara (enableIrIN) , legge (decode), e aspetta il prossimo segnale (resume). I valori sono memorizzati nella struttura decode_results, il cui valore value è il codice del segnale del telecomando. La variabile booleana automat determina se Ardubottino è in modalità automatica o meno.

<span style="color:#FF0000">ATTENZIONE: La libreria IRremote.h non è compatibile con la libreria RobotIRRemote fornita con l'ultima versione della IDE di Arduino. Per compilare questo sketch occorre prima disabilitare RobotIRRemote. Per disabilitare una libreria occorre andare in arduino/libraries e spostare la cartella della libreria in un altro posto.</span>

#include <IRremote.h>

int IRpin =2; //pin del sensore IR
IRrecv irrecv(IRpin);
long duration;
long dursx;
long durdx;

const int en1 = 10; //pin enable
const int en2 = 9;
const int m1fd = 4; //controlli motore
const int m2fd = 7;
const int m1bk = 5;
const int m2bk = 6;
const int pinping = 13; //pin sensore distanza
const int sterzo = 600; //durata dello sterzo
const int distanza = 500; //distanza minima ostacoli
int motore1 = 66;//pwm motore dx
int motore2 = 72;//pwm motore sx
boolean automat = false;

decode_results results;

void setup() {
pinMode(m1fd, OUTPUT);
pinMode(m1bk, OUTPUT);
pinMode(m2fd, OUTPUT);
pinMode(m2bk, OUTPUT);
pinMode(en1, OUTPUT);
pinMode(en2, OUTPUT);
analogWrite(en1,motore1);
analogWrite(en2,motore2);
irrecv.enableIRIn();
}

void loop() {
if(irrecv.decode(&results)){
if (!automat) {
if(results.value == 2742014623 || results.value == 31889539){
dritto();
} else if (results.value == 2383694249 || results.value == 2039764837 ) {
sinistra();
} else if (results.value == 15111918 || results.value == 2725237002) {
rovescia();
} else if (results.value == 1665824360 || results.value == 3250666572 ) {
destra();
} else {
ferma();
}
}
if (results.value == 3969632309 || results.value == 18594425) {
if (automat) {
automat = false;
ferma();
delayMicroseconds(300000);
}else{
automat = true;
dritto();
delayMicroseconds(300000);
}
}
irrecv.resume();
}
if (automat && echo() < distanza){ //trovato un ostacolo
analogWrite(en1,170);
analogWrite(en2,170);
ferma();
sinistra();
delay(sterzo);
ferma();
dursx = echo(); //guarda a sinistra
destra();
delay(sterzo*2);
ferma();
durdx = echo(); //guarda a destra
if (dursx < distanza && durdx < distanza){
destra();
delay(sterzo);
} else if (dursx > durdx) {
sinistra();
delay(sterzo*2);
} //sceglie dove c'è più spazio
dritto();
analogWrite(en1,motore1);
analogWrite(en2,motore2);
}
}

void dritto() {
digitalWrite(m1bk,LOW);
digitalWrite(m2bk,LOW);
digitalWrite(m2fd,HIGH);
digitalWrite(m1fd,HIGH);
}

void rovescia() {
digitalWrite(m1fd,LOW);
digitalWrite(m2fd,LOW);
digitalWrite(m1bk,HIGH);
digitalWrite(m2bk,HIGH);
}

void destra() {
digitalWrite(m1fd,LOW);
digitalWrite(m2fd,HIGH);
digitalWrite(m1bk,HIGH);
digitalWrite(m2bk,LOW);
}

void sinistra() {
digitalWrite(m1fd,HIGH);
digitalWrite(m2fd,LOW);
digitalWrite(m1bk,LOW);
digitalWrite(m2bk,HIGH);
}

void ferma() {
digitalWrite(m1fd,LOW);
digitalWrite(m2fd,LOW);
digitalWrite(m1bk,LOW);
digitalWrite(m2bk,LOW);
delay(50);
}

long echo() {
pinMode(pinping, OUTPUT);
digitalWrite(pinping, LOW);
delayMicroseconds(2);
digitalWrite(pinping, HIGH);
delayMicroseconds(5);
digitalWrite(pinping, LOW);
pinMode(pinping, INPUT);
duration = pulseIn(pinping,HIGH);
return duration;
}

= Terza Versione =
Dopo l'ennesimo disastroso trasporto di Ardubottino, nel quale si è smontato tutto, ho deciso di dargli una sistemata definitiva. Saldature migliori, componenti fissati e meno fili volanti. Inoltre sono state fatte le seguenti modifiche.

[[File:ardubottino_3ver.jpg]]

== Passaggio dal Micro al Pro Mini ==
Per ragioni di spazio sono passato dall'Arduino Micro al Pro Mini della Deek Robots.

[[File:Newardbot2.JPG]]

C'è poco da dire su questa board. È sotto tutti gli aspetti un Arduino Pro Mini. Per essere programmato ha bisogno dell'adattatore USB. Purtroppo, come si può vedere nell'immagine, l'ho montato alla rovescia sulla breadboard e così non è possibile capire il numero dei pin. Capirci qualcosa è stato particolarmente ostico.

== Abbastanza batterie ==
Avere l'alimentazione separata motori/logica è una soluzione che non mi soddisfa per niente. Come fare però per fare in modo che gli spikes dei motori non facciano riavviare l'Arduino? La questione è stata risolta in questa maniera.

=== Condensatori ===
Sono stati aggiunti dei condensatori ai motori. In questo modo lo spike dovrebbe essere assorbito in parte.

=== L'Arduino e i motori hanno una sorgente comune ===
Le batterie dei motori, 4 stilo da 2100mAh l'una, hanno amperaggio più che sufficiente per tenere acceso Arduino e motori. Dal + delle batterie partono due fili, uno va all'Arduino e l'altro al ponte ad H. Nei tentativi precedenti, davo al ponte ad H l'uscita a 5v dell'Arduino. Evidentemente la richiesta dei motori era eccessiva per il regolatore a 5v.

== Turbo! ==
Aggiunta la modalità turbo, che fa andare il ns. robot più veloce!

== Altri problemi ==
Avrei voluto mettere il sensore a ultrasuoni su un servo ma un bug della libreria Servo blocca il PWM in alcuni pin[http://forum.arduino.cc/index.php?topic=243264.0] per cui ho lasciato perdere.

== Nuovo codice! ==
Inutile incollarlo qui. Ho aperto uno spazio su GitHub:

[https://github.com/raspibo/ardubottino Link]

= Quarta versione =
Era giunto il momento di sfruttare un po' di roba che rimaneva inutilizzata.
Le modifiche sono state:

* Encoder, stavolta funzionanti
* Calibrazione automatica
* Modalità programmazione
* Blocco quando una ruota non gira
* Sensore di caduta

== Encoders ==
Nonostante abbia rotto le rondelle originali (che comunque erano fatte malissimo) sono riuscito a trovare alcuni modelli funzionanti. Il PLA azzurro, a differenza di quello bianco e di quello nero, sembra riflettere l'infrarosso dell'encoder. Tutto stava nel capire quale forma funzionasse meglio.

[[File:Arduencoder.JPG]]

La forma che funziona meglio (per ora) è quella a destra. Potete trovare l'STL nel [https://github.com/raspibo/ardubottino repository ardubottino su GitHub].

Il problema principale, nel creare questo tipo di oggetto in 3D, è stato il foro a forma di prisma esagonale. In Blender occorre creare un cilindro, ridurre i vertici a 6 e poi modificarne la dimensione solo con lo strumento proporzionale, in modo da non deformarlo.

[[File:Newardbot3.JPG]]

Gli encoder permettono di fare diverse cose interessanti. Ora Ardubottino sente quando una ruota non sta girando, ad esempio, inoltre sono state aggiunte due nuove modalità: la modalità "programmazione" (vai avanti di 10, poi gira a destra di 5, ecc.) e la modalità "calibrazione" (modifica la velocità di un motore fino a che le ruote non girano più o meno uguali).

Purtroppo gli encoder non sono tanto precisi, ogni tanto leggono male e segnano un passo in più o in meno. Questo però era così anche con le rotelle originali.

== Il sensore di caduta ==
Posto sul davanti, sente quando ad Ardubottino manca la terra sotto i cingoli. Quando sente il vuoto ferma tutto.

[[File:Newardbot1.JPG]]

== Il codice ==
Il codice sta diventando veramente troppo lungo per essere incollato qui, su questa pagina, per cui ne commenterò solo alcune parti. Lo sketch completo lo trovate su [https://github.com/raspibo/ardubottino GitHub].

#include "ardubottino.h"
Sì, era ora che creassi un header con tutti i codici del telecomando. Per adattare Ardubottino a un altro telecomando basterà cambiare header.

volatile long right_interval = 0;
volatile long left_interval = 0;
volatile int right_count = 0;
volatile int left_count = 0;

Le variabili che sono modificate dagli encoder devono essere di tipo "volatile". Le variabili volatile possono essere cambiate da un evento esterno, nel nostro caso da un evento scatenato da un interrupt.

void right_encoder() {
static unsigned long last_interrupt = 0;
unsigned long time_interrupt = millis();
if(time_interrupt - last_interrupt >70){
right_interval = time_interrupt - last_interrupt;
next_check_right = millis()+right_interval*2;
right_count +=1;
last_interrupt = time_interrupt;
}
}

void left_encoder() {
static unsigned long last_interrupt = 0;
unsigned long time_interrupt = millis();
if(time_interrupt - last_interrupt >70) {
left_interval = millis() - last_interrupt;
next_check_left = millis()+left_interval*2;
left_count +=1;
last_interrupt = millis();
}
}

Ecco le brevi funzioni chiamate da
attachInterrupt(0, right_encoder,RISING);
attachInterrupt(1, left_encoder,RISING);
gli interrupt.
La variabile x_count conta quanti giri (quanti quarti di giro) ha fatto la ruota; x_interval l'intervallo, in millisecondi, fra un passaggio e l'altro; next_check_x è una stima massima di quando dovrebbe essere il prossimo passaggio, serve per capire se una ruota s'è inceppata.

if (irrecv.decode(&results)) {
curr_result = results.value;
if (curr_result == prev_result) {
curr_result = 0;
} else {
prev_result = curr_result;
}
(...)
}

Ricordate quando vi dissi che il telecomando per ogni tasto ha due codici? Serve per distinguere se state tenendo premuto il tasto o se lo state premendo più volte contemporaneamente. Con questo piccolo brandello di codice faccio in modo di ignorare i codici ripetuti, visto che ad Ardubottino non servono. Non tutti i telecomandi funzionano così.
if (program) {
if (curr_result == OKA || curr_result == OKB) {
blinkOK();
executeProgram();
clearMoves();
noMotion();
} else if (curr_result == NUM1A || curr_result == NUM1B) {
moves[pointer][0] = (moves[pointer][0]*10) +1;
blinkOK();
} else if (curr_result == NUM2A || curr_result == NUM2A) {
moves[pointer][0] = (moves[pointer][0]*10) +2;
blinkOK();
} else if (curr_result == NUM3A || curr_result == NUM3B) {
moves[pointer][0] = (moves[pointer][0]*10) +3;
blinkOK();
} else if (curr_result == NUM4A || curr_result == NUM4B) {
moves[pointer][0] = (moves[pointer][0]*10) +4;
blinkOK();
} else if (curr_result == NUM5A || curr_result == NUM5B) {
moves[pointer][0] = (moves[pointer][0]*10) +5;
blinkOK();
} else if (curr_result == NUM6A || curr_result == NUM6B) {
moves[pointer][0] = (moves[pointer][0]*10) +6;
blinkOK();
} else if (curr_result == NUM7A || curr_result == NUM7B) {
moves[pointer][0] = (moves[pointer][0]*10) +7;
blinkOK();
} else if (curr_result == NUM8A || curr_result == NUM8B) {
moves[pointer][0] = (moves[pointer][0]*10) +8;
blinkOK();
} else if (curr_result == NUM9A || curr_result == NUM9B) {
moves[pointer][0] = (moves[pointer][0]*10) +9;
blinkOK();
} else if (curr_result == NUM0A || curr_result == NUM0B) {
moves[pointer][0] = (moves[pointer][0]*10);
blinkOK();
} else if (curr_result == FORWARDA || curr_result == FORWARDB) {
moves[pointer][1] = 1;
pointer ++;
blinkOK();
} else if (curr_result == BACKA || curr_result == BACKB) {
moves[pointer][1] = 2;
pointer ++;
blinkOK();
} else if (curr_result == LEFTA || curr_result == LEFTB) {
moves[pointer][1] = 3;
pointer ++;
blinkOK();
} else if (curr_result == RIGHTA || curr_result == RIGHTB) {
moves[pointer][1] = 4;
pointer ++;
blinkOK();
} else if (curr_result == WINA || curr_result == WINB) {
clearMoves();
blinkOK();
} else {
blinkNO();
}
if(moves[pointer][0] > 99) {
moves[pointer][0] = moves[pointer][0]-((moves[pointer][0]/100)*100);
}
if (pointer >49) {
executeProgram();
}
}

Et voilà: 50 mosse programmabili per il nostro robottino. Si scrive un numero di massimo 2 cifre e una direzione per massimo 50 istruzioni. Premendo OK si dà inizio al programma.
Ho anche aggiunto un lampeggiamento del LED di bordo in modo da dare un feedback visivo. Come ben saprete, i telecomandi a volte non trasmettono bene.

void executeProgram() {
int right_count_program = right_count;

for (int x=0;x<=49;x++){
if (moves[x][1] == 0) {
break;
} else if (moves[x][1] == 1){
forward();
} else if (moves[x][1] == 2){
backward();
} else if (moves[x][1] == 3){
left();
} else if (moves[x][1] == 4){
right();
}
while(moves[x][0] > 0) {
if (right_count_program != right_count ) {
moves[x][0] --;
right_count_program = right_count;

}
if (digitalRead(fall)) {
noMotion();
program = false;
return;
}
}
moves[x][1] = 0;
}
program = false;
noMotion();
}

Come potete vedere a metà c'è anche un check (c'è anche per le modalità automatica e manuale) sul sensore di caduta.

if (curr_result == BLUEA|| curr_result == BLUEB) { //calibration
blinkOK();
program = false;
automat = false;
noMotion();
delay(500);
forward();
int loops = 0;
int last_left = left_count;
int last_right = right_count;
bool left_pass = false;
bool right_pass = false;
while (loops < 12) {
if (last_left != left_count) {
left_pass = true;
}
if (last_right != right_count) {
right_pass = true;
}
if (left_pass && right_pass) {
left_pass = false;
right_pass = false;
last_left = left_count;
last_right = right_count;
if (abs(right_interval - left_interval) < 80) {
loops +=1;
} else if (right_interval > left_interval) {
motor1PWM += 1;
analogWrite(en1,motor1PWM);
loops = 0;
} else {
motor1PWM -= 1;
analogWrite(en1,motor1PWM);
loops = 0;
}
if(debug) {
Serial.print(motor1PWM);
Serial.print(" ");
Serial.println(motor2PWM);
}
}
}
noMotion();
}

La calibrazione: modifica la potenza di uno dei due motori fino a che gli intervalli degli encoder delle due ruote non sono quasi uguali. Occorre staccare i cingoli o mettere Ardubottino in un posto sopraelevato perché per funzionare ha bisogno di andare forward() per qualche minuto.

[[Category:Progetti]]

Installare MicroPython su NUCLEO-F401RE

2019-03-02T15:45:21Z

Oloturia: /* Caricare uno script */

Questa guida è basata quasi tutta su quella di Carmine Noviello https://www.carminenoviello.com/2015/06/03/running-micropyton-stm32nucleo-f4/ che peraltro trovate anche in italiano https://www.carminenoviello.com/it/2015/08/11/compilare-micropython-una-scheda-stm32nucleo-f4/ per cui scriverò solo le differenze.

La versione di Carmine di micropython, che si trova sul suo [https://github.com/cnoviello/micropython github], risolve il problema relativo alla mancanza di memoria SD della scheda Nucleo. Il file con il programma .py sarà caricato direttamente sulla flash.

= La scheda =

NUCLEO-F401RE della STMicroelectronics è una scheda basata su ARM Cortex M4 e fa parte della famiglia STM32 Nucleo Boards. Ha 512KB di Flash, 96 KB di SRAM, un clock di 84MHz, 50 GPIO, RTC, supporto I²C, SPI, USART e molto altro ([https://os.mbed.com/platforms/ST-Nucleo-F401RE/ maggiori info]). La sua forma le permette di alloggiare sia gli shield per Arduino che le estensioni Morpho di STMicroelectronics.
Il prezzo è abbastanza contenuto (attorno ai 12€ su Mouser) il che ne fa una scheda piuttosto interessante.

Normalmente si programmerebbe tramite l'[https://ide.mbed.com/compiler editor online di Mbed]. Il compilatore genererà dal nostro codice un file con estensione bin. Collegando la scheda verrà montato un volume, chiamato "NUCLEO" sul quale caricare il file bin. Quando la scheda verrà resettata, il codice verrà eseguito. È possibile anche usare editor offline con toolchain di compilazione come Eclipse. Non credo sia possibile usare la IDE di Arduino.

= Installazione MicroPython =

== Primo tentativo ==

=== Toolchain e OpenOCD ===

Per compilare vi servirà la toolchain gcc-arm-embedded. Non è nei repo ufficiali quindi la dovete installare a mano oppure aggiungere un PPA. https://launchpad.net/gcc-arm-embedded
Il programma per comunicare col debugger della scheda, openocd, invece è nei repo di Debian.

=== Come installare MicroPython ===

Potete seguire la guida di Carmine per la compilazione. Ovviamente se avete installato la toolchain con apt non è necessario aggiungere il path a tutti i comandi, perché sono già dentro a /usr/bin.

OpenOCD ci permette di caricare il firmware che abbiamo crosscompilato. Basterà lanciare il comando:
$ openocd -f board/st_nucleo_f4.cfg
Un LED della scheda dovrebbe lampeggiare rosso/verde. Il debugger è attivo. Per collegarcisi:
$ telnet localhost 4444
e poi scrivete:
> reset halt
e infine:
> flash write_image erase <file .elf da flashare>

Inizialmente non sembrava funzionare. Il tentativo finale che ha sbloccato la situazione è stato dare il comando shutdown. Non sono sicuro però che sia stato proprio quel comando e bisognerebbe indagare meglio.

=== Usare MicroPython dall'interprete ===

Aprendo la porta della nostra scheda (la trovate su dmesg non appena la attaccate, è /dev/ttyACMx dove x è un numero che parte da 0) con un emulatore di terminale (come console) alla velocità di 115200 baud, dovreste vedere l'interprete dei comandi di MicroPython. Provate a dare il comando:
>>> pyb.LED(1).on()
per vedere se si accende il LED onboard.

=== Usare MicroPython dal PC ===

Fra i tool di MicroPython, che trovate nella cartella di git micropython/tools, c'è pyboard.py, un programma che vi permette di eseguire uno script in MicroPython. Se la vostra porta non è accessibile dall'utente dovrete usare sudo.
# ./pyboard.py <nome file>.py

=== Caricare uno script ===

Carmine ha fatto una modifica a pyboard in modo che possa caricare un file sulla board.
# ./pyboard.py --device=/dev/ttyACMx --send <nome file>.py

MicroPython ha due file di default quando viene installato: boot.py e main.py. Il primo è un file di sistema che serve allo stesso MicroPython di partire. Non occorre di solito modificarlo. Il secondo, main.py, è uno script che viene eseguito all'avvio. Se carichiamo un file main.py questo verrà eseguito all'accensione.

=== Considerazioni finali ===

Molto bene, ma la versione di micropython non è aggiornata. Forse è per questo che non riesco a far funzionare la porta I²C?

== Secondo tentativo ==

Boochow fornisce dei firmware già compilati su https://blog.boochow.com/micropython-firmware-for-mbed-boards basta scegliere la board giusta e caricare il file .bin nel volume "NUCLEO" che si monta quando si collega la USB.

=== Caricare uno script ===

Un modo piuttosto comodo di inviare e ricevere file sulla flash della Nucleo è usare uPyLoader:
https://github.com/BetaRavener/uPyLoader/
ma quasi sempre dà un errore di timeout.

Il programma fornito da Adafruit sembra funzionare decisamente meglio
https://learn.adafruit.com/micropython-basics-load-files-and-run-code/install-ampy

Per installarlo usare pip (o pip3):
pip install adafruit-ampy

Per usarlo:
ampy -p <porta seriale> put <nome file>

Installare MicroPython su NUCLEO-F401RE

2019-03-02T15:43:10Z

Oloturia:

Questa guida è basata quasi tutta su quella di Carmine Noviello https://www.carminenoviello.com/2015/06/03/running-micropyton-stm32nucleo-f4/ che peraltro trovate anche in italiano https://www.carminenoviello.com/it/2015/08/11/compilare-micropython-una-scheda-stm32nucleo-f4/ per cui scriverò solo le differenze.

La versione di Carmine di micropython, che si trova sul suo [https://github.com/cnoviello/micropython github], risolve il problema relativo alla mancanza di memoria SD della scheda Nucleo. Il file con il programma .py sarà caricato direttamente sulla flash.

= La scheda =

NUCLEO-F401RE della STMicroelectronics è una scheda basata su ARM Cortex M4 e fa parte della famiglia STM32 Nucleo Boards. Ha 512KB di Flash, 96 KB di SRAM, un clock di 84MHz, 50 GPIO, RTC, supporto I²C, SPI, USART e molto altro ([https://os.mbed.com/platforms/ST-Nucleo-F401RE/ maggiori info]). La sua forma le permette di alloggiare sia gli shield per Arduino che le estensioni Morpho di STMicroelectronics.
Il prezzo è abbastanza contenuto (attorno ai 12€ su Mouser) il che ne fa una scheda piuttosto interessante.

Normalmente si programmerebbe tramite l'[https://ide.mbed.com/compiler editor online di Mbed]. Il compilatore genererà dal nostro codice un file con estensione bin. Collegando la scheda verrà montato un volume, chiamato "NUCLEO" sul quale caricare il file bin. Quando la scheda verrà resettata, il codice verrà eseguito. È possibile anche usare editor offline con toolchain di compilazione come Eclipse. Non credo sia possibile usare la IDE di Arduino.

= Installazione MicroPython =

== Primo tentativo ==

=== Toolchain e OpenOCD ===

Per compilare vi servirà la toolchain gcc-arm-embedded. Non è nei repo ufficiali quindi la dovete installare a mano oppure aggiungere un PPA. https://launchpad.net/gcc-arm-embedded
Il programma per comunicare col debugger della scheda, openocd, invece è nei repo di Debian.

=== Come installare MicroPython ===

Potete seguire la guida di Carmine per la compilazione. Ovviamente se avete installato la toolchain con apt non è necessario aggiungere il path a tutti i comandi, perché sono già dentro a /usr/bin.

OpenOCD ci permette di caricare il firmware che abbiamo crosscompilato. Basterà lanciare il comando:
$ openocd -f board/st_nucleo_f4.cfg
Un LED della scheda dovrebbe lampeggiare rosso/verde. Il debugger è attivo. Per collegarcisi:
$ telnet localhost 4444
e poi scrivete:
> reset halt
e infine:
> flash write_image erase <file .elf da flashare>

Inizialmente non sembrava funzionare. Il tentativo finale che ha sbloccato la situazione è stato dare il comando shutdown. Non sono sicuro però che sia stato proprio quel comando e bisognerebbe indagare meglio.

=== Usare MicroPython dall'interprete ===

Aprendo la porta della nostra scheda (la trovate su dmesg non appena la attaccate, è /dev/ttyACMx dove x è un numero che parte da 0) con un emulatore di terminale (come console) alla velocità di 115200 baud, dovreste vedere l'interprete dei comandi di MicroPython. Provate a dare il comando:
>>> pyb.LED(1).on()
per vedere se si accende il LED onboard.

=== Usare MicroPython dal PC ===

Fra i tool di MicroPython, che trovate nella cartella di git micropython/tools, c'è pyboard.py, un programma che vi permette di eseguire uno script in MicroPython. Se la vostra porta non è accessibile dall'utente dovrete usare sudo.
# ./pyboard.py <nome file>.py

=== Caricare uno script ===

Carmine ha fatto una modifica a pyboard in modo che possa caricare un file sulla board.
# ./pyboard.py --device=/dev/ttyACMx --send <nome file>.py

MicroPython ha due file di default quando viene installato: boot.py e main.py. Il primo è un file di sistema che serve allo stesso MicroPython di partire. Non occorre di solito modificarlo. Il secondo, main.py, è uno script che viene eseguito all'avvio. Se carichiamo un file main.py questo verrà eseguito all'accensione.

=== Considerazioni finali ===

Molto bene, ma la versione di micropython non è aggiornata. Forse è per questo che non riesco a far funzionare la porta I²C?

== Secondo tentativo ==

Boochow fornisce dei firmware già compilati su https://blog.boochow.com/micropython-firmware-for-mbed-boards basta scegliere la board giusta e caricare il file .bin nel volume "NUCLEO" che si monta quando si collega la USB.

== Caricare uno script ==

Un modo piuttosto comodo di inviare e ricevere file sulla flash della Nucleo è usare uPyLoader:
https://github.com/BetaRavener/uPyLoader/
ma quasi sempre dà un errore di timeout.

Il programma fornito da Adafruit sembra funzionare decisamente meglio
https://learn.adafruit.com/micropython-basics-load-files-and-run-code/install-ampy

Per installarlo usare pip (o pip3):
pip install adafruit-ampy

Per usarlo:
ampy -p <porta seriale> put <nome file>

Installare MicroPython su NUCLEO-F401RE

2019-03-02T15:36:09Z

Oloturia: /* Secondo tentativo */

Questa guida è basata quasi tutta su quella di Carmine Noviello https://www.carminenoviello.com/2015/06/03/running-micropyton-stm32nucleo-f4/ che peraltro trovate anche in italiano https://www.carminenoviello.com/it/2015/08/11/compilare-micropython-una-scheda-stm32nucleo-f4/ per cui scriverò solo le differenze.

La versione di Carmine di micropython, che si trova sul suo [https://github.com/cnoviello/micropython github], risolve il problema relativo alla mancanza di memoria SD della scheda Nucleo. Il file con il programma .py sarà caricato direttamente sulla flash.

= La scheda =

NUCLEO-F401RE della STMicroelectronics è una scheda basata su ARM Cortex M4 e fa parte della famiglia STM32 Nucleo Boards. Ha 512KB di Flash, 96 KB di SRAM, un clock di 84MHz, 50 GPIO, RTC, supporto I²C, SPI, USART e molto altro ([https://os.mbed.com/platforms/ST-Nucleo-F401RE/ maggiori info]). La sua forma le permette di alloggiare sia gli shield per Arduino che le estensioni Morpho di STMicroelectronics.
Il prezzo è abbastanza contenuto (attorno ai 12€ su Mouser) il che ne fa una scheda piuttosto interessante.

Normalmente si programmerebbe tramite l'[https://ide.mbed.com/compiler editor online di Mbed]. Il compilatore genererà dal nostro codice un file con estensione bin. Collegando la scheda verrà montato un volume, chiamato "NUCLEO" sul quale caricare il file bin. Quando la scheda verrà resettata, il codice verrà eseguito. È possibile anche usare editor offline con toolchain di compilazione come Eclipse. Non credo sia possibile usare la IDE di Arduino.

= Installazione MicroPython =

== Primo tentativo ==

=== Toolchain e OpenOCD ===

Per compilare vi servirà la toolchain gcc-arm-embedded. Non è nei repo ufficiali quindi la dovete installare a mano oppure aggiungere un PPA. https://launchpad.net/gcc-arm-embedded
Il programma per comunicare col debugger della scheda, openocd, invece è nei repo di Debian.

=== Come installare MicroPython ===

Potete seguire la guida di Carmine per la compilazione. Ovviamente se avete installato la toolchain con apt non è necessario aggiungere il path a tutti i comandi, perché sono già dentro a /usr/bin.

OpenOCD ci permette di caricare il firmware che abbiamo crosscompilato. Basterà lanciare il comando:
$ openocd -f board/st_nucleo_f4.cfg
Un LED della scheda dovrebbe lampeggiare rosso/verde. Il debugger è attivo. Per collegarcisi:
$ telnet localhost 4444
e poi scrivete:
> reset halt
e infine:
> flash write_image erase <file .elf da flashare>

Inizialmente non sembrava funzionare. Il tentativo finale che ha sbloccato la situazione è stato dare il comando shutdown. Non sono sicuro però che sia stato proprio quel comando e bisognerebbe indagare meglio.

=== Usare MicroPython dall'interprete ===

Aprendo la porta della nostra scheda (la trovate su dmesg non appena la attaccate, è /dev/ttyACMx dove x è un numero che parte da 0) con un emulatore di terminale (come console) alla velocità di 115200 baud, dovreste vedere l'interprete dei comandi di MicroPython. Provate a dare il comando:
>>> pyb.LED(1).on()
per vedere se si accende il LED onboard.

=== Usare MicroPython dal PC ===

Fra i tool di MicroPython, che trovate nella cartella di git micropython/tools, c'è pyboard.py, un programma che vi permette di eseguire uno script in MicroPython. Se la vostra porta non è accessibile dall'utente dovrete usare sudo.
# ./pyboard.py <nome file>.py

=== Caricare uno script ===

Carmine ha fatto una modifica a pyboard in modo che possa caricare un file sulla board.
# ./pyboard.py --device=/dev/ttyACMx --send <nome file>.py

MicroPython ha due file di default quando viene installato: boot.py e main.py. Il primo è un file di sistema che serve allo stesso MicroPython di partire. Non occorre di solito modificarlo. Il secondo, main.py, è uno script che viene eseguito all'avvio. Se carichiamo un file main.py questo verrà eseguito all'accensione.

=== Considerazioni finali ===

Molto bene, ma la versione di micropython non è aggiornata. Forse è per questo che non riesco a far funzionare la porta I²C?

== Secondo tentativo ==

Boochow fornisce dei firmware già compilati su https://blog.boochow.com/micropython-firmware-for-mbed-boards basta scegliere la board giusta e caricare il file .bin nel volume "NUCLEO" che si monta quando si collega la USB.
È l'ultima versione ed è quella più completa.

== Terzo tentativo ==

Sul forum di MicroPython, l'utente dhylands ha messo il link a una versione di MicroPython precedente. Caricata con OpenOCD funziona. Anche in questo caso però il caricamento di un file sulla scheda ha dato problemi di timeout.
https://forum.micropython.org/viewtopic.php?t=3709

== Caricare uno script ==

Un modo piuttosto comodo di inviare e ricevere file sulla flash della Nucleo è usare uPyLoader.
https://github.com/BetaRavener/uPyLoader/

È una versione alfa ma in qualche modo sono riuscito a caricare il file della libreria di un display OLED che vorrei usare come test per la porta I²C.

Installare MicroPython su NUCLEO-F401RE

2019-03-02T15:35:15Z

Oloturia: /* Terzo tentativo */

Questa guida è basata quasi tutta su quella di Carmine Noviello https://www.carminenoviello.com/2015/06/03/running-micropyton-stm32nucleo-f4/ che peraltro trovate anche in italiano https://www.carminenoviello.com/it/2015/08/11/compilare-micropython-una-scheda-stm32nucleo-f4/ per cui scriverò solo le differenze.

La versione di Carmine di micropython, che si trova sul suo [https://github.com/cnoviello/micropython github], risolve il problema relativo alla mancanza di memoria SD della scheda Nucleo. Il file con il programma .py sarà caricato direttamente sulla flash.

= La scheda =

NUCLEO-F401RE della STMicroelectronics è una scheda basata su ARM Cortex M4 e fa parte della famiglia STM32 Nucleo Boards. Ha 512KB di Flash, 96 KB di SRAM, un clock di 84MHz, 50 GPIO, RTC, supporto I²C, SPI, USART e molto altro ([https://os.mbed.com/platforms/ST-Nucleo-F401RE/ maggiori info]). La sua forma le permette di alloggiare sia gli shield per Arduino che le estensioni Morpho di STMicroelectronics.
Il prezzo è abbastanza contenuto (attorno ai 12€ su Mouser) il che ne fa una scheda piuttosto interessante.

Normalmente si programmerebbe tramite l'[https://ide.mbed.com/compiler editor online di Mbed]. Il compilatore genererà dal nostro codice un file con estensione bin. Collegando la scheda verrà montato un volume, chiamato "NUCLEO" sul quale caricare il file bin. Quando la scheda verrà resettata, il codice verrà eseguito. È possibile anche usare editor offline con toolchain di compilazione come Eclipse. Non credo sia possibile usare la IDE di Arduino.

= Installazione MicroPython =

== Primo tentativo ==

=== Toolchain e OpenOCD ===

Per compilare vi servirà la toolchain gcc-arm-embedded. Non è nei repo ufficiali quindi la dovete installare a mano oppure aggiungere un PPA. https://launchpad.net/gcc-arm-embedded
Il programma per comunicare col debugger della scheda, openocd, invece è nei repo di Debian.

=== Come installare MicroPython ===

Potete seguire la guida di Carmine per la compilazione. Ovviamente se avete installato la toolchain con apt non è necessario aggiungere il path a tutti i comandi, perché sono già dentro a /usr/bin.

OpenOCD ci permette di caricare il firmware che abbiamo crosscompilato. Basterà lanciare il comando:
$ openocd -f board/st_nucleo_f4.cfg
Un LED della scheda dovrebbe lampeggiare rosso/verde. Il debugger è attivo. Per collegarcisi:
$ telnet localhost 4444
e poi scrivete:
> reset halt
e infine:
> flash write_image erase <file .elf da flashare>

Inizialmente non sembrava funzionare. Il tentativo finale che ha sbloccato la situazione è stato dare il comando shutdown. Non sono sicuro però che sia stato proprio quel comando e bisognerebbe indagare meglio.

=== Usare MicroPython dall'interprete ===

Aprendo la porta della nostra scheda (la trovate su dmesg non appena la attaccate, è /dev/ttyACMx dove x è un numero che parte da 0) con un emulatore di terminale (come console) alla velocità di 115200 baud, dovreste vedere l'interprete dei comandi di MicroPython. Provate a dare il comando:
>>> pyb.LED(1).on()
per vedere se si accende il LED onboard.

=== Usare MicroPython dal PC ===

Fra i tool di MicroPython, che trovate nella cartella di git micropython/tools, c'è pyboard.py, un programma che vi permette di eseguire uno script in MicroPython. Se la vostra porta non è accessibile dall'utente dovrete usare sudo.
# ./pyboard.py <nome file>.py

=== Caricare uno script ===

Carmine ha fatto una modifica a pyboard in modo che possa caricare un file sulla board.
# ./pyboard.py --device=/dev/ttyACMx --send <nome file>.py

MicroPython ha due file di default quando viene installato: boot.py e main.py. Il primo è un file di sistema che serve allo stesso MicroPython di partire. Non occorre di solito modificarlo. Il secondo, main.py, è uno script che viene eseguito all'avvio. Se carichiamo un file main.py questo verrà eseguito all'accensione.

=== Considerazioni finali ===

Molto bene, ma la versione di micropython non è aggiornata. Forse è per questo che non riesco a far funzionare la porta I²C?

== Secondo tentativo ==

Boochow fornisce dei firmware già compilati su https://blog.boochow.com/micropython-firmware-for-mbed-boards basta scegliere la board giusta e caricare il file .bin nel volume "NUCLEO" che si monta quando si collega la USB.
L'ultima versione però non è molto stabile, soprattutto quando si è trattato di inviare dei file alla flash della Nucleo, per cui ho dovuto ripiegare a una versione successiva.

== Terzo tentativo ==

Sul forum di MicroPython, l'utente dhylands ha messo il link a una versione di MicroPython precedente. Caricata con OpenOCD funziona. Anche in questo caso però il caricamento di un file sulla scheda ha dato problemi di timeout.
https://forum.micropython.org/viewtopic.php?t=3709

== Caricare uno script ==

Un modo piuttosto comodo di inviare e ricevere file sulla flash della Nucleo è usare uPyLoader.
https://github.com/BetaRavener/uPyLoader/

È una versione alfa ma in qualche modo sono riuscito a caricare il file della libreria di un display OLED che vorrei usare come test per la porta I²C.

Installare MicroPython su NUCLEO-F401RE

2019-02-21T19:56:02Z

Oloturia:

Questa guida è basata quasi tutta su quella di Carmine Noviello https://www.carminenoviello.com/2015/06/03/running-micropyton-stm32nucleo-f4/ che peraltro trovate anche in italiano https://www.carminenoviello.com/it/2015/08/11/compilare-micropython-una-scheda-stm32nucleo-f4/ per cui scriverò solo le differenze.

La versione di Carmine di micropython, che si trova sul suo [https://github.com/cnoviello/micropython github], risolve il problema relativo alla mancanza di memoria SD della scheda Nucleo. Il file con il programma .py sarà caricato direttamente sulla flash.

= La scheda =

NUCLEO-F401RE della STMicroelectronics è una scheda basata su ARM Cortex M4 e fa parte della famiglia STM32 Nucleo Boards. Ha 512KB di Flash, 96 KB di SRAM, un clock di 84MHz, 50 GPIO, RTC, supporto I²C, SPI, USART e molto altro ([https://os.mbed.com/platforms/ST-Nucleo-F401RE/ maggiori info]). La sua forma le permette di alloggiare sia gli shield per Arduino che le estensioni Morpho di STMicroelectronics.
Il prezzo è abbastanza contenuto (attorno ai 12€ su Mouser) il che ne fa una scheda piuttosto interessante.

Normalmente si programmerebbe tramite l'[https://ide.mbed.com/compiler editor online di Mbed]. Il compilatore genererà dal nostro codice un file con estensione bin. Collegando la scheda verrà montato un volume, chiamato "NUCLEO" sul quale caricare il file bin. Quando la scheda verrà resettata, il codice verrà eseguito. È possibile anche usare editor offline con toolchain di compilazione come Eclipse. Non credo sia possibile usare la IDE di Arduino.

= Installazione MicroPython =

== Primo tentativo ==

=== Toolchain e OpenOCD ===

Per compilare vi servirà la toolchain gcc-arm-embedded. Non è nei repo ufficiali quindi la dovete installare a mano oppure aggiungere un PPA. https://launchpad.net/gcc-arm-embedded
Il programma per comunicare col debugger della scheda, openocd, invece è nei repo di Debian.

=== Come installare MicroPython ===

Potete seguire la guida di Carmine per la compilazione. Ovviamente se avete installato la toolchain con apt non è necessario aggiungere il path a tutti i comandi, perché sono già dentro a /usr/bin.

OpenOCD ci permette di caricare il firmware che abbiamo crosscompilato. Basterà lanciare il comando:
$ openocd -f board/st_nucleo_f4.cfg
Un LED della scheda dovrebbe lampeggiare rosso/verde. Il debugger è attivo. Per collegarcisi:
$ telnet localhost 4444
e poi scrivete:
> reset halt
e infine:
> flash write_image erase <file .elf da flashare>

Inizialmente non sembrava funzionare. Il tentativo finale che ha sbloccato la situazione è stato dare il comando shutdown. Non sono sicuro però che sia stato proprio quel comando e bisognerebbe indagare meglio.

=== Usare MicroPython dall'interprete ===

Aprendo la porta della nostra scheda (la trovate su dmesg non appena la attaccate, è /dev/ttyACMx dove x è un numero che parte da 0) con un emulatore di terminale (come console) alla velocità di 115200 baud, dovreste vedere l'interprete dei comandi di MicroPython. Provate a dare il comando:
>>> pyb.LED(1).on()
per vedere se si accende il LED onboard.

=== Usare MicroPython dal PC ===

Fra i tool di MicroPython, che trovate nella cartella di git micropython/tools, c'è pyboard.py, un programma che vi permette di eseguire uno script in MicroPython. Se la vostra porta non è accessibile dall'utente dovrete usare sudo.
# ./pyboard.py <nome file>.py

=== Caricare uno script ===

Carmine ha fatto una modifica a pyboard in modo che possa caricare un file sulla board.
# ./pyboard.py --device=/dev/ttyACMx --send <nome file>.py

MicroPython ha due file di default quando viene installato: boot.py e main.py. Il primo è un file di sistema che serve allo stesso MicroPython di partire. Non occorre di solito modificarlo. Il secondo, main.py, è uno script che viene eseguito all'avvio. Se carichiamo un file main.py questo verrà eseguito all'accensione.

=== Considerazioni finali ===

Molto bene, ma la versione di micropython non è aggiornata. Forse è per questo che non riesco a far funzionare la porta I²C?

== Secondo tentativo ==

Boochow fornisce dei firmware già compilati su https://blog.boochow.com/micropython-firmware-for-mbed-boards basta scegliere la board giusta e caricare il file .bin nel volume "NUCLEO" che si monta quando si collega la USB.
L'ultima versione però non è molto stabile, soprattutto quando si è trattato di inviare dei file alla flash della Nucleo, per cui ho dovuto ripiegare a una versione successiva.

== Terzo tentativo ==

Sul forum di MicroPython, l'utente dhylands ha messo il link a una versione di MicroPython precedente. Caricata con OpenOCD funziona.
https://forum.micropython.org/viewtopic.php?t=3709

=== Caricare uno script ===

Un modo piuttosto comodo di inviare e ricevere file sulla flash della Nucleo è usare uPyLoader.
https://github.com/BetaRavener/uPyLoader/

È una versione alfa ma in qualche modo sono riuscito a caricare il file della libreria di un display OLED che vorrei usare come test per la porta I²C.

Installare MicroPython su NUCLEO-F401RE

2019-02-21T19:31:03Z

Oloturia:

Questa guida è basata quasi tutta su quella di Carmine Noviello https://www.carminenoviello.com/2015/06/03/running-micropyton-stm32nucleo-f4/ che peraltro trovate anche in italiano https://www.carminenoviello.com/it/2015/08/11/compilare-micropython-una-scheda-stm32nucleo-f4/ per cui scriverò solo le differenze.

La versione di Carmine di micropython, che si trova sul suo [https://github.com/cnoviello/micropython github], risolve il problema relativo alla mancanza di memoria SD della scheda Nucleo. Il file con il programma .py sarà caricato direttamente sulla flash.

= La scheda =

NUCLEO-F401RE della STMicroelectronics è una scheda basata su ARM Cortex M4 e fa parte della famiglia STM32 Nucleo Boards. Ha 512KB di Flash, 96 KB di SRAM, un clock di 84MHz, 50 GPIO, RTC, supporto I²C, SPI, USART e molto altro ([https://os.mbed.com/platforms/ST-Nucleo-F401RE/ maggiori info]). La sua forma le permette di alloggiare sia gli shield per Arduino che le estensioni Morpho di STMicroelectronics.
Il prezzo è abbastanza contenuto (attorno ai 12€ su Mouser) il che ne fa una scheda piuttosto interessante.

Normalmente si programmerebbe tramite l'[https://ide.mbed.com/compiler editor online di Mbed]. Il compilatore genererà dal nostro codice un file con estensione bin. Collegando la scheda verrà montato un volume, chiamato "NUCLEO" sul quale caricare il file bin. Quando la scheda verrà resettata, il codice verrà eseguito. È possibile anche usare editor offline con toolchain di compilazione come Eclipse. Non credo sia possibile usare la IDE di Arduino.

= Installazione MicroPython =

== Primo tentativo ==

=== Toolchain e OpenOCD ===

Per compilare vi servirà la toolchain gcc-arm-embedded. Non è nei repo ufficiali quindi la dovete installare a mano oppure aggiungere un PPA. https://launchpad.net/gcc-arm-embedded
Il programma per comunicare col debugger della scheda, openocd, invece è nei repo di Debian.

=== Come installare MicroPython ===

Potete seguire la guida di Carmine per la compilazione. Ovviamente se avete installato la toolchain con apt non è necessario aggiungere il path a tutti i comandi, perché sono già dentro a /usr/bin.

OpenOCD ci permette di caricare il firmware che abbiamo crosscompilato. Basterà lanciare il comando:
$ openocd -f board/st_nucleo_f4.cfg
Un LED della scheda dovrebbe lampeggiare rosso/verde. Il debugger è attivo. Per collegarcisi:
$ telnet localhost 4444
e poi scrivete:
> reset halt
e infine:
> flash write_image erase <file .elf da flashare>

Inizialmente non sembrava funzionare. Il tentativo finale che ha sbloccato la situazione è stato dare il comando shutdown. Non sono sicuro però che sia stato proprio quel comando e bisognerebbe indagare meglio.

=== Usare MicroPython dall'interprete ===

Aprendo la porta della nostra scheda (la trovate su dmesg non appena la attaccate, è /dev/ttyACMx dove x è un numero che parte da 0) con un emulatore di terminale (come console) alla velocità di 115200 baud, dovreste vedere l'interprete dei comandi di MicroPython. Provate a dare il comando:
>>> pyb.LED(1).on()
per vedere se si accende il LED onboard.

=== Usare MicroPython dal PC ===

Fra i tool di MicroPython, che trovate nella cartella di git micropython/tools, c'è pyboard.py, un programma che vi permette di eseguire uno script in MicroPython. Se la vostra porta non è accessibile dall'utente dovrete usare sudo.
# ./pyboard.py <nome file>.py

=== Caricare uno script ===

Carmine ha fatto una modifica a pyboard in modo che possa caricare un file sulla board.
# ./pyboard.py --device=/dev/ttyACMx --send <nome file>.py

MicroPython ha due file di default quando viene installato: boot.py e main.py. Il primo è un file di sistema che serve allo stesso MicroPython di partire. Non occorre di solito modificarlo. Il secondo, main.py, è uno script che viene eseguito all'avvio. Se carichiamo un file main.py questo verrà eseguito all'accensione.

=== Considerazioni finali ===

Molto bene, ma la versione di micropython non è aggiornata. Forse è per questo che non riesco a far funzionare la porta I²C?

== Secondo tentativo ==

Boochow fornisce dei firmware già compilati su https://blog.boochow.com/micropython-firmware-for-mbed-boards basta scegliere la board giusta e caricare il file .bin nel volume "NUCLEO" che si monta quando si collega la USB.
L'ultima versione però non è molto stabile, soprattutto quando si è trattato di inviare dei file alla flash della Nucleo, per cui ho dovuto ripiegare a una versione successiva.

== Terzo tentativo ==

Sul forum di MicroPython, l'utente dhylands ha messo il link a una versione di MicroPython precedente. Caricata con OpenOCD funziona e sembra più stabile delle altre.
https://forum.micropython.org/viewtopic.php?t=3709

=== Caricare uno script ===

Un modo piuttosto comodo di inviare e ricevere file sulla flash della Nucleo è usare uPyLoader.
https://github.com/BetaRavener/uPyLoader/

È una versione alfa ma in qualche modo sono riuscito a caricare il file della libreria di un display OLED che vorrei usare come test per la porta I²C.

Installare MicroPython su NUCLEO-F401RE

2019-02-21T19:30:23Z

Oloturia:

Questa guida è basata quasi tutta su quella di Carmine Noviello https://www.carminenoviello.com/2015/06/03/running-micropyton-stm32nucleo-f4/ che peraltro trovate anche in italiano https://www.carminenoviello.com/it/2015/08/11/compilare-micropython-una-scheda-stm32nucleo-f4/ per cui scriverò solo le differenze.

La versione di Carmine di micropython, che si trova sul suo [https://github.com/cnoviello/micropython github], risolve il problema relativo alla mancanza di memoria SD della scheda Nucleo. Il file con il programma .py sarà caricato direttamente sulla flash.

= La scheda =

NUCLEO-F401RE della STMicroelectronics è una scheda basata su ARM Cortex M4 e fa parte della famiglia STM32 Nucleo Boards. Ha 512KB di Flash, 96 KB di SRAM, un clock di 84MHz, 50 GPIO, RTC, supporto I²C, SPI, USART e molto altro ([https://os.mbed.com/platforms/ST-Nucleo-F401RE/ maggiori info]). La sua forma le permette di alloggiare sia gli shield per Arduino che le estensioni Morpho di STMicroelectronics.
Il prezzo è abbastanza contenuto (attorno ai 12€ su Mouser) il che ne fa una scheda piuttosto interessante.

Normalmente si programmerebbe tramite l'[https://ide.mbed.com/compiler editor online di Mbed]. Il compilatore genererà dal nostro codice un file con estensione bin. Collegando la scheda verrà montato un volume, chiamato "NUCLEO" sul quale caricare il file bin. Quando la scheda verrà resettata, il codice verrà eseguito. È possibile anche usare editor offline con toolchain di compilazione come Eclipse. Non credo sia possibile usare la IDE di Arduino.

== Primo tentativo ==

=== Toolchain e OpenOCD ===

Per compilare vi servirà la toolchain gcc-arm-embedded. Non è nei repo ufficiali quindi la dovete installare a mano oppure aggiungere un PPA. https://launchpad.net/gcc-arm-embedded
Il programma per comunicare col debugger della scheda, openocd, invece è nei repo di Debian.

=== Come installare MicroPython ===

Potete seguire la guida di Carmine per la compilazione. Ovviamente se avete installato la toolchain con apt non è necessario aggiungere il path a tutti i comandi, perché sono già dentro a /usr/bin.

OpenOCD ci permette di caricare il firmware che abbiamo crosscompilato. Basterà lanciare il comando:
$ openocd -f board/st_nucleo_f4.cfg
Un LED della scheda dovrebbe lampeggiare rosso/verde. Il debugger è attivo. Per collegarcisi:
$ telnet localhost 4444
e poi scrivete:
> reset halt
e infine:
> flash write_image erase <file .elf da flashare>

Inizialmente non sembrava funzionare. Il tentativo finale che ha sbloccato la situazione è stato dare il comando shutdown. Non sono sicuro però che sia stato proprio quel comando e bisognerebbe indagare meglio.

=== Usare MicroPython dall'interprete ===

Aprendo la porta della nostra scheda (la trovate su dmesg non appena la attaccate, è /dev/ttyACMx dove x è un numero che parte da 0) con un emulatore di terminale (come console) alla velocità di 115200 baud, dovreste vedere l'interprete dei comandi di MicroPython. Provate a dare il comando:
>>> pyb.LED(1).on()
per vedere se si accende il LED onboard.

=== Usare MicroPython dal PC ===

Fra i tool di MicroPython, che trovate nella cartella di git micropython/tools, c'è pyboard.py, un programma che vi permette di eseguire uno script in MicroPython. Se la vostra porta non è accessibile dall'utente dovrete usare sudo.
# ./pyboard.py <nome file>.py

=== Caricare uno script ===

Carmine ha fatto una modifica a pyboard in modo che possa caricare un file sulla board.
# ./pyboard.py --device=/dev/ttyACMx --send <nome file>.py

MicroPython ha due file di default quando viene installato: boot.py e main.py. Il primo è un file di sistema che serve allo stesso MicroPython di partire. Non occorre di solito modificarlo. Il secondo, main.py, è uno script che viene eseguito all'avvio. Se carichiamo un file main.py questo verrà eseguito all'accensione.

=== Considerazioni finali ===

Molto bene, ma la versione di micropython non è aggiornata. Forse è per questo che non riesco a far funzionare la porta I²C?

== Secondo tentativo ==

Boochow fornisce dei firmware già compilati su https://blog.boochow.com/micropython-firmware-for-mbed-boards basta scegliere la board giusta e caricare il file .bin nel volume "NUCLEO" che si monta quando si collega la USB.
L'ultima versione però non è molto stabile, soprattutto quando si è trattato di inviare dei file alla flash della Nucleo, per cui ho dovuto ripiegare a una versione successiva.

== Terzo tentativo ==

Sul forum di MicroPython, l'utente dhylands ha messo il link a una versione di MicroPython precedente. Caricata con OpenOCD funziona e sembra più stabile delle altre.
https://forum.micropython.org/viewtopic.php?t=3709

=== Caricare uno script ===

Un modo piuttosto comodo di inviare e ricevere file sulla flash della Nucleo è usare uPyLoader.
https://github.com/BetaRavener/uPyLoader/

È una versione alfa ma in qualche modo sono riuscito a caricare il file della libreria di un display OLED che vorrei usare come test per la porta I²C.

Installare MicroPython su NUCLEO-F401RE

2019-02-20T18:34:07Z

Oloturia:

Installare MicroPython su NUCLEO-F401RE

2019-02-20T18:26:03Z

Oloturia: /* La scheda */

Installare MicroPython su NUCLEO-F401RE

2019-02-19T20:38:45Z

Oloturia:

Installare MicroPython su NUCLEO-F401RE

2019-02-19T19:48:06Z

Oloturia: Creata pagina con 'Questa guida è basata quasi tutta su quella di Carmine Noviello https://www.carminenoviello.com/2015/06/03/running-micropyton-stm32nucleo-f4/ che peraltro trovate anche in it...'

Gruppo µPython

2019-02-19T19:08:17Z

Oloturia: /* NUCLEO-F401RE */

{{Gruppo
|nome=MicroPython
|descrizione=Proviamo il MicroPython https://micropython.org/
|iscritti=Oloturia
}}

Il linguaggio più bello del mondo approda anche ai microcontrollori. Ecco qui le nostre esperienze.

=== Micro:Bit ===

Il Micro:Bit è una piattaforma educational che si può programmare anche in MicroPython. https://microbit.org/guide/python/

=== NUCLEO-F401RE ===

Sulla scheda NUCLEO-F401RE della STMicroelectronics è possibile installare MicroPython, con alcuni accorgimenti. Leggi la [[Installare MicroPython su NUCLEO-F401RE|guida]] qui.

Gruppo µPython

2019-02-19T19:06:34Z

Oloturia:

{{Gruppo
|nome=MicroPython
|descrizione=Proviamo il MicroPython https://micropython.org/
|iscritti=Oloturia
}}

Il linguaggio più bello del mondo approda anche ai microcontrollori. Ecco qui le nostre esperienze.

=== Micro:Bit ===

Il Micro:Bit è una piattaforma educational che si può programmare anche in MicroPython. https://microbit.org/guide/python/

=== NUCLEO-F401RE ===

Sulla scheda NUCLEO-F401RE della STMicroelectronics è possibile installare MicroPython, con alcuni accorgimenti. Leggi la [[guida|Installare MicroPython su NUCLEO-F401RE]] qui.

Gruppo µPython

2019-02-19T18:57:49Z

Oloturia: Creata pagina con '{{Gruppo |nome=MicroPython |descrizione=Proviamo il micro python |iscritti=Oloturia }} Il linguaggio più bello del mondo approda anche ai microcontrollori. Ecco qui le nostr...'

{{Gruppo
|nome=MicroPython
|descrizione=Proviamo il micro python
|iscritti=Oloturia
}}

Il linguaggio più bello del mondo approda anche ai microcontrollori. Ecco qui le nostre esperienze.

Gruppi

2019-02-19T18:52:03Z

Oloturia:

Gruppo Meteo/Software/Devel/StimaVersione2

2018-11-13T22:14:27Z

Oloturia: /* C++ */

= Guide per developers =
== Software rmap ==
=== Libreria di "driver" per sensori ===
Esistono attualmente due versioni, una in C++ e una in python

==== C++ ====

https://github.com/r-map/rmap/tree/master/arduino/sketchbook/libraries/SensorDriver

Porta le gestione della sensoristica ad un livello di astrazione più
alto. Praticamente si tratterebbe di estendere una classe
con quattro metodi per effettuare la lettura di uno specifico sensore:

virtual int setup(const char* driver, const int address, const int node=0, const char* type=NULL, char* mainbuf=0, size_t lenbuf=0, RF24Network* network=NULL);
effettua eventuali settaggi necessari al funzionamento del sensore;
esempio per temperatura: numero di bit di risoluzione, operazione di
misura one-shot; i paramteri const int node=0, const char* type=NULL, char* mainbuf=0, size_t lenbuf=0, RF24Network* network=NULL servono per la gestione di un sensore remoto eseguendo una jsonrpc su trasporto NRF24Network

virtual int prepare(unsigned long* waittime) = 0;
impartisce al sensore il comando per effettuare una singola misurazione
torna il tempo in millisecondi di attesa necessario

virtual int get(int values[],size_t lenvalues) = 0;
torna i valori della misurazione

virtual aJsonObject* getJson() = 0;
torna i valori in formato json, formato preferito ed utilizzato in r-map
Vedi RFC-rmap

Questa piccola libreria è nata per sensori I2C, ma non per forza
limitata a quelli e infatti prevede già una json-rpc con trasporto via radio.
Sarà estesa per umidità, pressione, direzione e intensità del vento e
precipitazione.

il file SensorDriver_config.h definisce quali driver includere nella libreria e altri parametri di configurazione a compile time

==== python ====

https://github.com/r-map/rmap/blob/master/python/rmap/sensordriver.py

OttoBot

2018-06-04T15:26:24Z

Oloturia: /* Lo chassis */

OttoBot è il risultato di un tentativo di usare un [http://www.atmel.com/devices/atmega8.aspx ATmega8] al posto di una board Arduino.

= Le specifiche tecniche =
L'ATmega8, prodotto da Atmel, è piuttosto modesto.

* Ha 8KB di memoria flash. Se usate il bootloader di Arduino allora ve ne rimarranno solo 7.
* Il clock è massimo 16Mhz usando un risuonatore esterno. Quello interno va a 8Mhz (ma vi risparmiate un bel po' di circuiteria). Per usare il risuonatore interno occorre cambiare un fuse.
* 23 pin programmabili.
* 2 interrupt.
* Porte SPI, I²C e seriale (ma non è possibile usare seriali software, presenti nella libreria di Arduino).
* Costa una bazzecola.

Per essere acceso ha bisogno da 2,7 a 5,5 Volt.
Il prezzo oscilla attorno all'euro.
[[Category:Progetti]]

= Prime versioni =

[[File:8bot.jpg]]

Come potete vedere, la dimensione è proprio mini. Si comanda tramite bluetooth. Ruote e chassis sono stampate 3d.

[[File:8bots.JPG]]

Da sinistra a destra, l'evoluzione di 8bot!

= Modificare l'ATmega8 affinché sembri un Arduino =

Per approfondire questo argomento leggete anche [[Programmazione dei microcontrollori]].

Per ottenere questo occorre fare tre cose:
* Trovare un programmatore (potete usare la [http://www.instructables.com/id/Simplest-AVR-Parallel-port-programmer/ porta parallela] oppure acquistarne uno, ma anche un normalissimo Arduino può essere usato come programmatore)
* Settare i fuses
* Caricare il bootloader
* Aggiungere l'ATmega8 nel file boards.txt di Arduino

Una volta fatti questi passi, potrete usare l'IDE come per qualsiasi altra board.

Di guide su come usare i programmatori ne trovate a bizzeffe su internet, noi ci concentreremo sull'utilizzo di Arduino come ISP, che è la procedura che ho usato io.

== Arduino as ISP ==

Negli sketch di esempio nella IDE di Arduino c'è "Arduino as ISP" (In-System Programmer). Caricatelo su un Arduino di vostra scelta con l'accortezza di controllare i pin da usare: sui Mega sono diversi. Dovrete usare la porta SPI e in genere avete: 10 reset, 11 MOSI, 12 MISO e 13 clock (SCK). Sui Mega le porte sono rispettivamente 53, 51, 50 e 52. Trovate tutto nei commenti dello sketch.
Altri pin, opzionali, sono il 9 (heartbeat, mostra se il programma sta girando), 8 (error, si accende se c'è un problema), 7 (programming, si accende durante le comunicazioni).

La porta SPI va così collegata, MISO con MISO, MOSI con MOSI, SCK con SCK e reset con reset. Il datasheet lo trovate qui [http://www.atmel.com/Images/Atmel-2486-8-bit-AVR-microcontroller-ATmega8_L_datasheet.pdf]

[[File:Atmega8 arduinopinout.png]]

I pin che vedete sono quelli come da IDE di Arduino. Se lo programmate con altri sistemi (come Eclipse) i riferimenti possono essere diversi.
Se il vostro ATmega8 è settato per avere un risuonatore esterno, dovrete collegarlo con un pin XTAL1 e l'altro su XTAL2. Entrambi i pin XTAL1 e XTAL2 vanno poi collegati a terra con un condensatore da 22 picofarad. Ne avrete bisogno se volete raggiungere frequenze superiori agli 8 Mhz o se avete bisogno di maggiore stabilità (il risuonatore interno non è molto preciso). Per contro, il risuonatore interno non ha bisogno di collegare nulla. Per approfondire guardate questa guida [http://kskpages.weebly.com/clock-settings.html]

== avrdude ==

Per interagire con l'ATmega8 dovrete usare avrdude, questa è una riga di esempio:
avrdude -p m8 -c arduino -P /dev/ttyACM1 -U flash:w:{bootloader}.hex -U hfuse:w:0xd9:m -U lfuse:w:0xe3:m -b 19200

Per saperne di più [http://www.nongnu.org/avrdude/user-manual/avrdude_4.html]

-p m8
dice che abbiamo a che fare con un ATmega8

-c arduino
segnala che stiamo usando un Arduino come programmatore, nelle nuove versioni della IDE, con il nuovo sketch ArduinoISP probabilmente il protocollo da usare è stk500v1

-P /dev/(porta)
è la porta dove avete collegato il programmatore, di solito per gli Arduino è ttyACMx o ttyUSBx; per conoscerla ci sono due modi: guardare nella IDE di Arduino le porte disponibili o collegare l'Arduino e guardare gli ultimi messaggi in dmesg

-U flash:w:{bootloader}.hex
scrive il bootloader, vedi sotto

-U hfuse:w:0xd9:m -U lfuse:w:0xe3:m
modifica i fuse, vedi sotto

-b 19200
la velocità di comunicazione in baud

== Caricare il bootloader ==

Se volete usarlo come Arduino dovreste caricare il bootloader. Potete farne anche a meno e risparmiare 1Kb (su 8, non è poco). In teoria potreste farne a meno e continuare a caricare gli sketch sull'ATmega8 l'Arduino come programmatore. Fatto sta che l'ho caricato una volta e non ho mai provato a toglierlo (del resto: if ain't broke, don't fix it). I bootloader li trovate in {cartella di Arduino}/hardware/arduino/avr/bootloaders. Se non li avete li trovate qua [https://github.com/arduino/Arduino/tree/master/hardware/arduino/avr/bootloaders]

== Settare i fuse ==

Molte opzioni dell'ATmega8 sono settabili tramite dei fuse. I fuse sono dei bit su una memoria EEPROM che dicono al microcontrollore come deve comportarsi. Tramite i fuses è possibile settare il clock, se usare un oscillatore esterno o interno, quanto deve aspettare durante il boot per una nuova programmazione, etc.
Qui trovate due calcolatori di fuse, questo è più semplice da usare [https://elektronik-kompendium.de/public/arnerossius/programme/web/avrfuse/ avrfuse] questo è più completo [http://www.engbedded.com/fusecalc/ Engbedded AVR Fuse Calculator].

== Aggiungere le opzioni alla IDE di Arduino ==

Se siete affezionati alla IDE dovrete aggiungere al menu delle board l'ATmega8.

In teoria, nel menu Tools/boards, c'è già "Arduino NG or older" che ha, fra le varie opzioni, anche la possibilità di usare l'ATmega8, ma io ho avuto una serie di problemi a usarla e alla fine non ho provato a capire perché non funzionasse.

Andate in {cartella di Arduino}/hardware/arduino/avr e aprite il file boards.txt (se avete paura di fare dei danni, fate una copia di questo file prima, per precauzione).

Per aggiungere l'ATmega8 basta aggiungere queste opzioni alla fine [https://github.com/chuckb/atmega/blob/master/atmega/avr/boards.txt].

''In alternativa''

Copiate i files dal repository https://github.com/chuckb/atmega, cartellle incluse, nella directory hardware degli sketches arduino, per esempio (nel mio caso):
<pre style="color:blue;overflow:auto">
ls ~/arduino-sketches/hardware/atmega/avr/
</pre>
<pre style="color:green;overflow:auto">
boards.txt platform.txt
</pre>

Se caricate uno sketch sul microcontrollore con un clock sbagliato accadranno risultati imprevedibili, ad es. caricate dalla IDE usando ATmega8 a 4Mhz con i fuses settati in modo che vada a 8Mhz scoprirete che tutto andrà al doppio della velocità.
I secondi diventano mezzi secondi, 9600 baud diventano 19200 e così via. Non una gran cosa se state cercando di programmare, però può sfuggirvi perché non segnala nessun errore.

Una volta editato boards.txt riavviate la IDE se l'avevate aperta e vedrete comparire nel menu Tools/board una nuova voce, quella dell'ATmega8.

== Caricare uno sketch ==

Collegate il programmatore (nei nostri esempi, l'Arduino) all'ATmega8 alla seriale (se avete caricato il bootloader) o alla SPI, collegate il reset (di default su Arduino as ISP è il pin 10), il +5v e la terra, andate sotto Sketch e usate "Upload Using Programmer". Alternativamente potete cliccare shift+pulsante del caricamento dello sketch. Se tutto è andato come dovrebbe vedrete lampeggiare i LED della seriale dell'Arduino per qualche secondo fino a che l'IDE non ci comunicherà "done".
Se invece non volete usare la IDE, potete compilare il vostro sketch con avr-gcc e uploadarlo direttamente con avrdude (ma di questo non tratteremo qui).

Problemi più frequenti: cavetti non collegati bene, cavetti invertiti, alimentazione non sufficiente, oscillatore esterno previsto ma mancante.

== Altri metodi ==

Potete usare, ad esempio, la SPI del Raspberry Pi, guardate la pagina [[Programmazione_dei_microcontrollori]].

= Lo schema elettrico =

È estremamente banale. Collegate le batterie a modulo Bluetooth, integrato e motori, in parallelo, collegate i fili del segnale dei servo a un pin libero dell'ATmega8, collegate RX dell'integrato a TX del modulo Bluetooth. Se volete un feedback dall'integrato allora collegate anche il TX dell'integrato al RX del modulo Bluetooth.

[[File:8botschema.png]]

In sintesi:
* il + delle batterie va collegato a: vcc del modulo Bluetooth, vcc dell'ATmega8, + del servo 1 e 2
* il - delle batterie va collegato a: gnd del modulo Bluetooth, due gnd dell'ATmega8, - del servo 1 e 2
* TX del modulo Bluetooth va collegato a RX dell'ATmega8
* RX del modulo Bluetooth va collegato a TX dell'ATmega8
* i segnali dei servi vanno collegati a due pin liberi (nel nostro caso 14 e 15 ma potete benissimo sceglierne degli altri)

= Lo sketch =

Lo trovate sul repository:
[https://gitlab.com/oloturia/8bot]

Vediamo un po' i punti più strani.

#include <Servo.h>
#include <EEPROM.h>

Servo dx_servo;
Servo sx_servo;

const int dx_pin = 8;
const int sx_pin = 9;
int fd_spd_dx = 180; //initial values
int bk_spd_dx = 0; //180 is full forward, 0 full backward
int fd_spd_sx = 0; //stop is somewhere in the middle
int bk_spd_sx = 180; //but the motors keep running

Per far funzionare il nostro robottino servirà la libreria Servo. La EEPROM ci servirà per mantenere la calibrazione da spento. Ci sono due costanti, i pin a cui sono collegati il segnale dei servi, e i valori che passeremo al metodo write degli oggetti dx_servo e sx_servo. Nei servo continui 0 è antiorario e 180 orario, lo stato fermo è più o meno 90. In questo caso però li staccheremo con detach così da non mantenerli in tensione. Se il vostro progetto non ha bisogno che il servo faccia resistenza (ad es. deve tenere un peso) allora è meglio staccarlo. Non è solo una questione di risparmio energetico: i piccoli servo e quelli di scarsa qualità quando sono in tensione tendono a scaldare.
Le quattro variabili sono rispettivamente il valore avanti e indietro del motore a destra e il valore avanti e indietro del motore a sinistra.

void setup() {
Serial.begin(9600);
Serial.println("READY");
if (EEPROM.read(4) == 1) {
fd_spd_dx = EEPROM.read(0);//reserve 4 bytes
bk_spd_dx = EEPROM.read(1);//for saved calibration
fd_spd_sx = EEPROM.read(2);
bk_spd_sx = EEPROM.read(3);
}
}

Accende la seriale e si legge la EEPROM. La memoria non scritta ha come valore 255 quindi serve un quinto elemento che comunichi se la calibrazione è stata fatta o meno. Scrivere e aggiornare la EEPROM è facilissimo. Vi consiglio di leggere la guida ufficiale [https://www.arduino.cc/en/Reference/EEPROM]. Ricordate che l'ATmega8 ha 512 bytes a disposizione nella EEPROM.

void loop() {
if(Serial.available()){
char command = Serial.read(); //every command is a char
if (command == 's') { //it is possible to write to the bot
turnOnServo(); //using a keyboard
dx_servo.write(fd_spd_dx);
sx_servo.write(fd_spd_sx);
} else if (command == 'd') {
[...]

Ogni comando ricevuto dalla seriale è un char. Si potrebbe eventualmente mandare un byte, ma così è più comodo soprattutto quando ancora non avevo pronta la app e dovevo pilotare il piccolo bot con la tastiera. Si può ancora fare: i tasti sono wasd. Sulla funzione turnOnServo() torneremo dopo.

[...]
} else if (command == 'h') {
if (fd_spd_dx > 90) {
fd_spd_dx --;
}
[...]

Altri comandi servono per la calibrazione. Purtroppo nella app la calibrazione è ancora molto confusionaria. Ogni variabile può diventare da 0 a 90 e da 91 a 180.

[...]
} else if (command == 'z') { //save calibration into eeprom
EEPROM.update(0,fd_spd_dx);
EEPROM.update(1,bk_spd_dx);
EEPROM.update(2,fd_spd_sx);
EEPROM.update(3,bk_spd_sx);
EEPROM.update(4,1);
Serial.println("OK");
} else {
stopServo(); //if the serial is empty, stop the motors
}

Infine, ecco dove la EEPROM viene scritta, incluso l'indirizzo 4 che diventa 1 e segnala al prossimo riavvio di leggersi i valori che avevamo salvato. Se non arriva nessun comando i servo vengono staccati.

void turnOnServo() {
dx_servo.attach(dx_pin);
sx_servo.attach(sx_pin);
}

void stopServo() {
dx_servo.detach();
sx_servo.detach();
}

Ogni volta che arriva un comando vengono riattaccati. In questo modo non rimarranno sotto tensione.

= Il bluetooth =

Il collegamento fra l'Ottobot e il vostro smartphone o il vostro computer avverrà tramite il modulo HC-05 o HC-06. Il modulo è molto semplice da usare: ha una porta seriale fisica dove legge e scrive tutto ciò che arriva via il servizio di porta seriale via Bluetooth. Nel nostro caso sarà attaccato direttamente ai pin RX e TX del nostro ATmega8 e farà come da ponte fra il nostro dispositivo e il microcontrollore. Potete leggere più informazioni su come giocare con questo tipo di moduli nella pagina [[HC-05 e HC-06]].

= L'app =

Potete scaricarla, guardarla e modificarla all'indirizzo di App Inventor (serve account Google) [http://ai2.appinventor.mit.edu/?locale=en&galleryId=5162309564235776 qua].

L'app è stata scritta con il MIT App Inventor 2. È un tool molto potente utile per chi, come me, è ancora fermo a cercare di fare un "Hello World" decente su Android. Non è la soluzione più efficace, ma nell'attesa di imparare qualcosa di migliore, è la più semplice.

L'App Inventor è basato sul popolare linguaggio educativo Scratch. Permette di inserire pulsanti, grafica e di interagire con i sensori e, nel nostro caso, con dispositivi Bluetooth. Permette di collegarsi a un dispositivo Android (anche emulato) per fare dei test in real-time e fare correzioni al volo. Quando avrete finito potrete creare un .apk da installare così non avrete più bisogno dell'App Inventor per usarla.

Tutte le informazioni su come utilizzarlo le trovate nel sito ufficiale [http://appinventor.mit.edu/explore/ai2/setup.html].

Nel repository c'è il sorgente in formato .aia, che potete caricare sull'App Inventor con Import.

Per prima cosa ho creato, nello Screen 1, una lista che si carica con la lista dei dispositivi Bluetooth che sono nel range del nostro tablet o telefono. Nella schermata c'è solo una lista e un componente "Bluetooth Client" chiamato BluetoothClient1.

[[File:Initbt.png]]

AfterPicking, ovvero dopo aver scelto un dispositivo, andrà nello screen "Controls" portandosi dietro il nome del dispositivo a cui ci vogliamo connettere.

Andiamo ora nella schermata "Controls".

[[File:Controls_8bot.png]]

Ci sono i pulsanti per le direzioni, un pulsante per connettersi a un altro dispositivo (che non fa altro che tornare a Screen1), e i pulsanti per la taratura (ancora in beta). Anche qui c'è BluetoothClient1. Appena arriva in questa schermata l'app si fermerà per permettere di fare l'accoppiamento tramite Bluetooth. Il pin è di solito 1234.

[[File:Initcontr.png]]

Se non riesce a connettersi o se clicchiamo "Connect" tornerà nella schermata di selezione precedente.

[[File:Controlscomm.png]]

I controlli sono molto semplici: ogni tasto invia un carattere. Quando viene rilasciato manda un carattere che spegne i servo. Non è ancora perfetto perché se perde la connessione i motori rimangono accesi, in futuro questo problema sarà corretto.

[[File:Trim8bot.png]]

Infine il codice per la calibrazione. A seconda se il robot sta andando avanti oppure indietro saranno calibrati i valori che vengono usati per muovere i motori. Purtroppo questa parte non è ancora scritta in modo efficace (ad es. il motore che va avanti in senso antiorario va più veloce con un valore INFERIORE, quindi per farlo andare più veloce occorre premere il tasto MENO). Quando la calibrazione è soddisfacente, con il tasto "Write" la si memorizza nella EEPROM dell'ATmega8.

= I motori =

L'8bot ha bisogno di due servo motori 9g continui, detti anche servo a 360°. Se volete risparmiare ulteriormente potete acquistare dei normalissimi servo a 180° e fare qualche modifica per trasformarli in 360°.
Per effettuare la modifica seguite [[Modifica_servo_rc_per_rotazione_continua|questa guida]].

= Lo chassis =
Tutti gli .stl di 8bot li trovate su git [https://gitlab.com/oloturia/8bot]

== Le ruote ==
Per le ruote ci sono due modelli, uno è della dimensione delle gomme delle mini4wd Tamiya[https://gitlab.com/oloturia/8bot/blob/master/wheel-mini4wd.stl]:

[[File:8bot4wd.png]]

mentre l'altro è della dimensione di un o-ring[https://gitlab.com/oloturia/8bot/blob/master/wheel0ring.stl]:

[[File:8botoring.png]]

entrambe si incastrano sul pignone del servo senza bisogno di viti o altro (ma se volete metterne una, male non fa).

== Il telaio ==
Il telaio è una piccola piattaforma con due fessure per inserire un'aletta del servi e un foro per la casterball. Recentemente ho aggiunto altre due alette per tenere fermo il portabatterie[https://gitlab.com/oloturia/8bot/blob/master/body.stl].

[[File:Chass.png]]

= Corso di costruzione Ottobot =
Nell'autunno 2016 a Raspibo un gruppo di makers si e' riunito specificamente per costruire Ottobot e programmarli sotto la guida paziente di Oloturia, creatore del progetto.

== Materiale ==
Il materiale e' stato procurato dallo stesso Oloturia da vari fornitori durante l'estate con un occhio particolare ai costi per permettera tutti di realizzare un piccolo robot didattico.

Alcune parti progettate appositamente, sono state stampate in 3D.

Ad ogni partecipante del corso e' stato fornito un kit, oltre a questo ogni partecipante ha portato un po' di attrezzi ed un pc.

[[File:Ottobot kit.jpg|600px|thumb|center|Il kit completo del corso ottobot]]

== Preparazione dei motori ==
Nel kit i due servo possono essere sia a rotazione continua quindi gia' pronti oppure standard.

Per i motori standard e' neccessario procedere ad una modifica vedi [[Modifica_servo_rc_per_rotazione_continua]]

== Assemblaggio del robot ==

{|style="margin-top:2px; background:none;align:center;width:100%;border:1px solid red;-moz-border-radius: 10px; -webkit-border-radius: 10px; border-radius:10px;"
|[[File:Ottobot assemblaggio 10.jpg|400px|thumb|left|Montare le ruote sul microservo modificato per rotazione continua]]
|Le ruote vanno montate sull'asse con una vite che si trova nel sacchetto degli accessori del servo. Il tutto va poi incastrato sulla base. Se la stampa e' perfetta i motori si incastrano perfettamete sulla base altrimenti ci si puo' aiutare con colla, viti o nastro biadesivo.
|
|}

{|style="margin-top:2px; background:none;align:center;width:100%;border:1px solid red;-moz-border-radius: 10px; -webkit-border-radius: 10px; border-radius:10px;"
|[[File:Ottobot assemblaggio 20.jpg|400px|thumb|left|Fissare la ball caster]]
|Come terzo appoggio utilizziamo una ballcaster che consente liberta' di movimento e di sterzata. Inserire il pezzo nel foro centrale e fissarlo con tre viti, oppure colla.
|
|}

OttoBot

2018-06-04T15:24:51Z

Oloturia: /* Lo sketch */

OttoBot è il risultato di un tentativo di usare un [http://www.atmel.com/devices/atmega8.aspx ATmega8] al posto di una board Arduino.

= Le specifiche tecniche =
L'ATmega8, prodotto da Atmel, è piuttosto modesto.

* Ha 8KB di memoria flash. Se usate il bootloader di Arduino allora ve ne rimarranno solo 7.
* Il clock è massimo 16Mhz usando un risuonatore esterno. Quello interno va a 8Mhz (ma vi risparmiate un bel po' di circuiteria). Per usare il risuonatore interno occorre cambiare un fuse.
* 23 pin programmabili.
* 2 interrupt.
* Porte SPI, I²C e seriale (ma non è possibile usare seriali software, presenti nella libreria di Arduino).
* Costa una bazzecola.

Per essere acceso ha bisogno da 2,7 a 5,5 Volt.
Il prezzo oscilla attorno all'euro.
[[Category:Progetti]]

= Prime versioni =

[[File:8bot.jpg]]

Come potete vedere, la dimensione è proprio mini. Si comanda tramite bluetooth. Ruote e chassis sono stampate 3d.

[[File:8bots.JPG]]

Da sinistra a destra, l'evoluzione di 8bot!

= Modificare l'ATmega8 affinché sembri un Arduino =

Per approfondire questo argomento leggete anche [[Programmazione dei microcontrollori]].

Per ottenere questo occorre fare tre cose:
* Trovare un programmatore (potete usare la [http://www.instructables.com/id/Simplest-AVR-Parallel-port-programmer/ porta parallela] oppure acquistarne uno, ma anche un normalissimo Arduino può essere usato come programmatore)
* Settare i fuses
* Caricare il bootloader
* Aggiungere l'ATmega8 nel file boards.txt di Arduino

Una volta fatti questi passi, potrete usare l'IDE come per qualsiasi altra board.

Di guide su come usare i programmatori ne trovate a bizzeffe su internet, noi ci concentreremo sull'utilizzo di Arduino come ISP, che è la procedura che ho usato io.

== Arduino as ISP ==

Negli sketch di esempio nella IDE di Arduino c'è "Arduino as ISP" (In-System Programmer). Caricatelo su un Arduino di vostra scelta con l'accortezza di controllare i pin da usare: sui Mega sono diversi. Dovrete usare la porta SPI e in genere avete: 10 reset, 11 MOSI, 12 MISO e 13 clock (SCK). Sui Mega le porte sono rispettivamente 53, 51, 50 e 52. Trovate tutto nei commenti dello sketch.
Altri pin, opzionali, sono il 9 (heartbeat, mostra se il programma sta girando), 8 (error, si accende se c'è un problema), 7 (programming, si accende durante le comunicazioni).

La porta SPI va così collegata, MISO con MISO, MOSI con MOSI, SCK con SCK e reset con reset. Il datasheet lo trovate qui [http://www.atmel.com/Images/Atmel-2486-8-bit-AVR-microcontroller-ATmega8_L_datasheet.pdf]

[[File:Atmega8 arduinopinout.png]]

I pin che vedete sono quelli come da IDE di Arduino. Se lo programmate con altri sistemi (come Eclipse) i riferimenti possono essere diversi.
Se il vostro ATmega8 è settato per avere un risuonatore esterno, dovrete collegarlo con un pin XTAL1 e l'altro su XTAL2. Entrambi i pin XTAL1 e XTAL2 vanno poi collegati a terra con un condensatore da 22 picofarad. Ne avrete bisogno se volete raggiungere frequenze superiori agli 8 Mhz o se avete bisogno di maggiore stabilità (il risuonatore interno non è molto preciso). Per contro, il risuonatore interno non ha bisogno di collegare nulla. Per approfondire guardate questa guida [http://kskpages.weebly.com/clock-settings.html]

== avrdude ==

Per interagire con l'ATmega8 dovrete usare avrdude, questa è una riga di esempio:
avrdude -p m8 -c arduino -P /dev/ttyACM1 -U flash:w:{bootloader}.hex -U hfuse:w:0xd9:m -U lfuse:w:0xe3:m -b 19200

Per saperne di più [http://www.nongnu.org/avrdude/user-manual/avrdude_4.html]

-p m8
dice che abbiamo a che fare con un ATmega8

-c arduino
segnala che stiamo usando un Arduino come programmatore, nelle nuove versioni della IDE, con il nuovo sketch ArduinoISP probabilmente il protocollo da usare è stk500v1

-P /dev/(porta)
è la porta dove avete collegato il programmatore, di solito per gli Arduino è ttyACMx o ttyUSBx; per conoscerla ci sono due modi: guardare nella IDE di Arduino le porte disponibili o collegare l'Arduino e guardare gli ultimi messaggi in dmesg

-U flash:w:{bootloader}.hex
scrive il bootloader, vedi sotto

-U hfuse:w:0xd9:m -U lfuse:w:0xe3:m
modifica i fuse, vedi sotto

-b 19200
la velocità di comunicazione in baud

== Caricare il bootloader ==

Se volete usarlo come Arduino dovreste caricare il bootloader. Potete farne anche a meno e risparmiare 1Kb (su 8, non è poco). In teoria potreste farne a meno e continuare a caricare gli sketch sull'ATmega8 l'Arduino come programmatore. Fatto sta che l'ho caricato una volta e non ho mai provato a toglierlo (del resto: if ain't broke, don't fix it). I bootloader li trovate in {cartella di Arduino}/hardware/arduino/avr/bootloaders. Se non li avete li trovate qua [https://github.com/arduino/Arduino/tree/master/hardware/arduino/avr/bootloaders]

== Settare i fuse ==

Molte opzioni dell'ATmega8 sono settabili tramite dei fuse. I fuse sono dei bit su una memoria EEPROM che dicono al microcontrollore come deve comportarsi. Tramite i fuses è possibile settare il clock, se usare un oscillatore esterno o interno, quanto deve aspettare durante il boot per una nuova programmazione, etc.
Qui trovate due calcolatori di fuse, questo è più semplice da usare [https://elektronik-kompendium.de/public/arnerossius/programme/web/avrfuse/ avrfuse] questo è più completo [http://www.engbedded.com/fusecalc/ Engbedded AVR Fuse Calculator].

== Aggiungere le opzioni alla IDE di Arduino ==

Se siete affezionati alla IDE dovrete aggiungere al menu delle board l'ATmega8.

In teoria, nel menu Tools/boards, c'è già "Arduino NG or older" che ha, fra le varie opzioni, anche la possibilità di usare l'ATmega8, ma io ho avuto una serie di problemi a usarla e alla fine non ho provato a capire perché non funzionasse.

Andate in {cartella di Arduino}/hardware/arduino/avr e aprite il file boards.txt (se avete paura di fare dei danni, fate una copia di questo file prima, per precauzione).

Per aggiungere l'ATmega8 basta aggiungere queste opzioni alla fine [https://github.com/chuckb/atmega/blob/master/atmega/avr/boards.txt].

''In alternativa''

Copiate i files dal repository https://github.com/chuckb/atmega, cartellle incluse, nella directory hardware degli sketches arduino, per esempio (nel mio caso):
<pre style="color:blue;overflow:auto">
ls ~/arduino-sketches/hardware/atmega/avr/
</pre>
<pre style="color:green;overflow:auto">
boards.txt platform.txt
</pre>

Se caricate uno sketch sul microcontrollore con un clock sbagliato accadranno risultati imprevedibili, ad es. caricate dalla IDE usando ATmega8 a 4Mhz con i fuses settati in modo che vada a 8Mhz scoprirete che tutto andrà al doppio della velocità.
I secondi diventano mezzi secondi, 9600 baud diventano 19200 e così via. Non una gran cosa se state cercando di programmare, però può sfuggirvi perché non segnala nessun errore.

Una volta editato boards.txt riavviate la IDE se l'avevate aperta e vedrete comparire nel menu Tools/board una nuova voce, quella dell'ATmega8.

== Caricare uno sketch ==

Collegate il programmatore (nei nostri esempi, l'Arduino) all'ATmega8 alla seriale (se avete caricato il bootloader) o alla SPI, collegate il reset (di default su Arduino as ISP è il pin 10), il +5v e la terra, andate sotto Sketch e usate "Upload Using Programmer". Alternativamente potete cliccare shift+pulsante del caricamento dello sketch. Se tutto è andato come dovrebbe vedrete lampeggiare i LED della seriale dell'Arduino per qualche secondo fino a che l'IDE non ci comunicherà "done".
Se invece non volete usare la IDE, potete compilare il vostro sketch con avr-gcc e uploadarlo direttamente con avrdude (ma di questo non tratteremo qui).

Problemi più frequenti: cavetti non collegati bene, cavetti invertiti, alimentazione non sufficiente, oscillatore esterno previsto ma mancante.

== Altri metodi ==

Potete usare, ad esempio, la SPI del Raspberry Pi, guardate la pagina [[Programmazione_dei_microcontrollori]].

= Lo schema elettrico =

È estremamente banale. Collegate le batterie a modulo Bluetooth, integrato e motori, in parallelo, collegate i fili del segnale dei servo a un pin libero dell'ATmega8, collegate RX dell'integrato a TX del modulo Bluetooth. Se volete un feedback dall'integrato allora collegate anche il TX dell'integrato al RX del modulo Bluetooth.

[[File:8botschema.png]]

In sintesi:
* il + delle batterie va collegato a: vcc del modulo Bluetooth, vcc dell'ATmega8, + del servo 1 e 2
* il - delle batterie va collegato a: gnd del modulo Bluetooth, due gnd dell'ATmega8, - del servo 1 e 2
* TX del modulo Bluetooth va collegato a RX dell'ATmega8
* RX del modulo Bluetooth va collegato a TX dell'ATmega8
* i segnali dei servi vanno collegati a due pin liberi (nel nostro caso 14 e 15 ma potete benissimo sceglierne degli altri)

= Lo sketch =

Lo trovate sul repository:
[https://gitlab.com/oloturia/8bot]

Vediamo un po' i punti più strani.

#include <Servo.h>
#include <EEPROM.h>

Servo dx_servo;
Servo sx_servo;

const int dx_pin = 8;
const int sx_pin = 9;
int fd_spd_dx = 180; //initial values
int bk_spd_dx = 0; //180 is full forward, 0 full backward
int fd_spd_sx = 0; //stop is somewhere in the middle
int bk_spd_sx = 180; //but the motors keep running

Per far funzionare il nostro robottino servirà la libreria Servo. La EEPROM ci servirà per mantenere la calibrazione da spento. Ci sono due costanti, i pin a cui sono collegati il segnale dei servi, e i valori che passeremo al metodo write degli oggetti dx_servo e sx_servo. Nei servo continui 0 è antiorario e 180 orario, lo stato fermo è più o meno 90. In questo caso però li staccheremo con detach così da non mantenerli in tensione. Se il vostro progetto non ha bisogno che il servo faccia resistenza (ad es. deve tenere un peso) allora è meglio staccarlo. Non è solo una questione di risparmio energetico: i piccoli servo e quelli di scarsa qualità quando sono in tensione tendono a scaldare.
Le quattro variabili sono rispettivamente il valore avanti e indietro del motore a destra e il valore avanti e indietro del motore a sinistra.

void setup() {
Serial.begin(9600);
Serial.println("READY");
if (EEPROM.read(4) == 1) {
fd_spd_dx = EEPROM.read(0);//reserve 4 bytes
bk_spd_dx = EEPROM.read(1);//for saved calibration
fd_spd_sx = EEPROM.read(2);
bk_spd_sx = EEPROM.read(3);
}
}

Accende la seriale e si legge la EEPROM. La memoria non scritta ha come valore 255 quindi serve un quinto elemento che comunichi se la calibrazione è stata fatta o meno. Scrivere e aggiornare la EEPROM è facilissimo. Vi consiglio di leggere la guida ufficiale [https://www.arduino.cc/en/Reference/EEPROM]. Ricordate che l'ATmega8 ha 512 bytes a disposizione nella EEPROM.

void loop() {
if(Serial.available()){
char command = Serial.read(); //every command is a char
if (command == 's') { //it is possible to write to the bot
turnOnServo(); //using a keyboard
dx_servo.write(fd_spd_dx);
sx_servo.write(fd_spd_sx);
} else if (command == 'd') {
[...]

Ogni comando ricevuto dalla seriale è un char. Si potrebbe eventualmente mandare un byte, ma così è più comodo soprattutto quando ancora non avevo pronta la app e dovevo pilotare il piccolo bot con la tastiera. Si può ancora fare: i tasti sono wasd. Sulla funzione turnOnServo() torneremo dopo.

[...]
} else if (command == 'h') {
if (fd_spd_dx > 90) {
fd_spd_dx --;
}
[...]

Altri comandi servono per la calibrazione. Purtroppo nella app la calibrazione è ancora molto confusionaria. Ogni variabile può diventare da 0 a 90 e da 91 a 180.

[...]
} else if (command == 'z') { //save calibration into eeprom
EEPROM.update(0,fd_spd_dx);
EEPROM.update(1,bk_spd_dx);
EEPROM.update(2,fd_spd_sx);
EEPROM.update(3,bk_spd_sx);
EEPROM.update(4,1);
Serial.println("OK");
} else {
stopServo(); //if the serial is empty, stop the motors
}

Infine, ecco dove la EEPROM viene scritta, incluso l'indirizzo 4 che diventa 1 e segnala al prossimo riavvio di leggersi i valori che avevamo salvato. Se non arriva nessun comando i servo vengono staccati.

void turnOnServo() {
dx_servo.attach(dx_pin);
sx_servo.attach(sx_pin);
}

void stopServo() {
dx_servo.detach();
sx_servo.detach();
}

Ogni volta che arriva un comando vengono riattaccati. In questo modo non rimarranno sotto tensione.

= Il bluetooth =

Il collegamento fra l'Ottobot e il vostro smartphone o il vostro computer avverrà tramite il modulo HC-05 o HC-06. Il modulo è molto semplice da usare: ha una porta seriale fisica dove legge e scrive tutto ciò che arriva via il servizio di porta seriale via Bluetooth. Nel nostro caso sarà attaccato direttamente ai pin RX e TX del nostro ATmega8 e farà come da ponte fra il nostro dispositivo e il microcontrollore. Potete leggere più informazioni su come giocare con questo tipo di moduli nella pagina [[HC-05 e HC-06]].

= L'app =

Potete scaricarla, guardarla e modificarla all'indirizzo di App Inventor (serve account Google) [http://ai2.appinventor.mit.edu/?locale=en&galleryId=5162309564235776 qua].

L'app è stata scritta con il MIT App Inventor 2. È un tool molto potente utile per chi, come me, è ancora fermo a cercare di fare un "Hello World" decente su Android. Non è la soluzione più efficace, ma nell'attesa di imparare qualcosa di migliore, è la più semplice.

L'App Inventor è basato sul popolare linguaggio educativo Scratch. Permette di inserire pulsanti, grafica e di interagire con i sensori e, nel nostro caso, con dispositivi Bluetooth. Permette di collegarsi a un dispositivo Android (anche emulato) per fare dei test in real-time e fare correzioni al volo. Quando avrete finito potrete creare un .apk da installare così non avrete più bisogno dell'App Inventor per usarla.

Tutte le informazioni su come utilizzarlo le trovate nel sito ufficiale [http://appinventor.mit.edu/explore/ai2/setup.html].

Nel repository c'è il sorgente in formato .aia, che potete caricare sull'App Inventor con Import.

Per prima cosa ho creato, nello Screen 1, una lista che si carica con la lista dei dispositivi Bluetooth che sono nel range del nostro tablet o telefono. Nella schermata c'è solo una lista e un componente "Bluetooth Client" chiamato BluetoothClient1.

[[File:Initbt.png]]

AfterPicking, ovvero dopo aver scelto un dispositivo, andrà nello screen "Controls" portandosi dietro il nome del dispositivo a cui ci vogliamo connettere.

Andiamo ora nella schermata "Controls".

[[File:Controls_8bot.png]]

Ci sono i pulsanti per le direzioni, un pulsante per connettersi a un altro dispositivo (che non fa altro che tornare a Screen1), e i pulsanti per la taratura (ancora in beta). Anche qui c'è BluetoothClient1. Appena arriva in questa schermata l'app si fermerà per permettere di fare l'accoppiamento tramite Bluetooth. Il pin è di solito 1234.

[[File:Initcontr.png]]

Se non riesce a connettersi o se clicchiamo "Connect" tornerà nella schermata di selezione precedente.

[[File:Controlscomm.png]]

I controlli sono molto semplici: ogni tasto invia un carattere. Quando viene rilasciato manda un carattere che spegne i servo. Non è ancora perfetto perché se perde la connessione i motori rimangono accesi, in futuro questo problema sarà corretto.

[[File:Trim8bot.png]]

Infine il codice per la calibrazione. A seconda se il robot sta andando avanti oppure indietro saranno calibrati i valori che vengono usati per muovere i motori. Purtroppo questa parte non è ancora scritta in modo efficace (ad es. il motore che va avanti in senso antiorario va più veloce con un valore INFERIORE, quindi per farlo andare più veloce occorre premere il tasto MENO). Quando la calibrazione è soddisfacente, con il tasto "Write" la si memorizza nella EEPROM dell'ATmega8.

= I motori =

L'8bot ha bisogno di due servo motori 9g continui, detti anche servo a 360°. Se volete risparmiare ulteriormente potete acquistare dei normalissimi servo a 180° e fare qualche modifica per trasformarli in 360°.
Per effettuare la modifica seguite [[Modifica_servo_rc_per_rotazione_continua|questa guida]].

= Lo chassis =
Tutti gli .stl di 8bot li trovate su git [https://github.com/raspibo/8bot]

== Le ruote ==
Per le ruote ci sono due modelli, uno è della dimensione delle gomme delle mini4wd Tamiya[https://github.com/raspibo/8bot/blob/master/wheel-mini4wd.stl]:

[[File:8bot4wd.png]]

mentre l'altro è della dimensione di un o-ring[https://github.com/raspibo/8bot/blob/master/wheel0ring.stl]:

[[File:8botoring.png]]

entrambe si incastrano sul pignone del servo senza bisogno di viti o altro (ma se volete metterne una, male non fa).

== Il telaio ==
Il telaio è una piccola piattaforma con due fessure per inserire un'aletta del servi e un foro per la casterball. Recentemente ho aggiunto altre due alette per tenere fermo il portabatterie[https://github.com/raspibo/8bot/blob/master/body.stl].

[[File:Chass.png]]

= Corso di costruzione Ottobot =
Nell'autunno 2016 a Raspibo un gruppo di makers si e' riunito specificamente per costruire Ottobot e programmarli sotto la guida paziente di Oloturia, creatore del progetto.

== Materiale ==
Il materiale e' stato procurato dallo stesso Oloturia da vari fornitori durante l'estate con un occhio particolare ai costi per permettera tutti di realizzare un piccolo robot didattico.

Alcune parti progettate appositamente, sono state stampate in 3D.

Ad ogni partecipante del corso e' stato fornito un kit, oltre a questo ogni partecipante ha portato un po' di attrezzi ed un pc.

[[File:Ottobot kit.jpg|600px|thumb|center|Il kit completo del corso ottobot]]

== Preparazione dei motori ==
Nel kit i due servo possono essere sia a rotazione continua quindi gia' pronti oppure standard.

Per i motori standard e' neccessario procedere ad una modifica vedi [[Modifica_servo_rc_per_rotazione_continua]]

== Assemblaggio del robot ==

{|style="margin-top:2px; background:none;align:center;width:100%;border:1px solid red;-moz-border-radius: 10px; -webkit-border-radius: 10px; border-radius:10px;"
|[[File:Ottobot assemblaggio 10.jpg|400px|thumb|left|Montare le ruote sul microservo modificato per rotazione continua]]
|Le ruote vanno montate sull'asse con una vite che si trova nel sacchetto degli accessori del servo. Il tutto va poi incastrato sulla base. Se la stampa e' perfetta i motori si incastrano perfettamete sulla base altrimenti ci si puo' aiutare con colla, viti o nastro biadesivo.
|
|}

{|style="margin-top:2px; background:none;align:center;width:100%;border:1px solid red;-moz-border-radius: 10px; -webkit-border-radius: 10px; border-radius:10px;"
|[[File:Ottobot assemblaggio 20.jpg|400px|thumb|left|Fissare la ball caster]]
|Come terzo appoggio utilizziamo una ballcaster che consente liberta' di movimento e di sterzata. Inserire il pezzo nel foro centrale e fissarlo con tre viti, oppure colla.
|
|}

HC-05 e HC-06

2018-06-04T15:20:20Z

Oloturia:

HC-05 e HC-06 sono due tipi di moduli Bluetooth che ci permettono di trasmettere e ricevere dati tramite l'interfaccia seriale (ma non solo). Sono molto semplici da usare e hanno molteplici utilizzi.

[[File:Hc-05.jpg]]

Nella foto potete vedere a sinistra il modulo senza lo zoccolo, i cui pin sono i contatti intorno, a destra la versione più comune, saldata su uno zoccolo con i pin di alimentazione e la seriale libera. Gli zoccoli hanno diverse forme e alcuni (come questo) hanno anche alcuni pin in più con funzioni diverse.

= Pinout =

Le board hanno il seguente pinout ([http://www.14core.com/working-with-hc05-hc06-to-configure-and-implementations/ immagine tratta da 14core.com])
[[File:Bluetooth-HC06-Versus-HC05-Bluetooth-Module-Comparison-001.jpg]]

Essendo la board spesso saldata su uno zoccolo ed essendo quest'ultimo non standard, non è possibile dare un pinout preciso. I pin che troverete sempre sono:

* '''Vcc''' e '''GND'''
* '''TXD''' e '''RXD''' (sono TX e RX seriali)

Quelli opzionali:

* '''Key''' questo pin è collegato al pin della board che deve essere collegato alla 3,3V per entrare in modalità AT, normalmente lo zoccolo ha anche un pulsante che fa la stessa cosa, in mancanza dell'uno e dell'altro dovrete fare ponte con qualcosa di conduttivo fra una sorgente a 3,3V e il pin Key sulla board
* '''State''' questo pin dovrebbe essere alto quando il device è connesso a qualcosa e basso quando non è collegato a niente
* '''EN''' dovrebbe essere l'enable, ma non è chiaro come funzioni

Le board hanno anche il collegamento per un LED di stato. Lo zoccolo di solito ne possiede uno. Il LED ha tre stati:

* Lampeggia velocemente: la board è accesa e non è collegata a niente
* Lampeggia piano (circa 1s): la board è collegata a qualcosa
* Lampeggia molto piano (circa 2s): la board è in modalità AT

= Differenze HC-05 e HC-06 =

I due device sono molto simili. Nella maggior parte dei casi potete prendere l'uno o l'altro indifferentemente. Le uniche differenze degne di nota sono:

* L'HC-05 può essere impostato come master, mentre l''''HC-06 è solo slave'''. Questo comporta che entrambi possono ricevere connessioni ma '''solo l'HC-05 può iniziarne una'''.

* L'HC-06 è sempre in modalità AT quando non è collegato a un altro dispositivo, mentre l'HC-05 occorre accenderlo mandando 3,3 volt allo speciale pin "key" (gli zoccoli di solito hanno un pin "Key" oppure un pulsante da premere).

* Il pinout è diverso (ovviamente s'intende il pinout della board, non quello dello zoccolo).

= Alimentazione =
I moduli vanno alimentati a 3,3V. Gli zoccoli più comuni permettono anche alimentazioni diverse tramite un regolatore di voltaggio, ma i livelli logici sono sempre a 3,3V.

= Collegamento all'Arduino =
Potete collegare direttamente la seriale UART dell'Arduino al modulo HC-0X. RX (ricevitore seriale) e TX (trasmittente seriale) di Arduino (pin 0 e 1) vanno collegati rispettivamente al TX e all'RX del modulo Bluetooth (in pratica: dovete incrociarli: RX con TX e TX con RX). Se vi serve solo come ricevente, potete collegare solo il TX dell'HC-0X all'RX dell'Arduino, al contrario se vi serve solo una trasmittente collegate solo l'RX dell'HC-0X al TX dell'Arduino. RX e TX a volte sono scritti RXD e TXD. Non cambia assolutamente nulla.

Se la seriale fisica dovesse essere occupata, è possibile averne una software su due pin diversi con la libreria [https://www.arduino.cc/en/Reference/SoftwareSerial SoftwareSerial].

= Collegamento Bluetooth al PC =

Sotto Linux ci sono diversi modi per attivare una comunicazione seriale fra il SO e un dispositivo che permette questo tipo di servizio. La seriale comparirà come file di device nella posizione /dev/rfcommX dove X è un numero che parte da 0. Se abbiamo una sola comunicazione seriale avremo quindi /dev/rfcomm0. A questo file ci si può collegare ad esempio con il comando screen.

# screen /dev/rfcommX <velocità baud>

Occorre essere root o dare il comando con sudo, perché l'utente normale non dovrebbe essere in grado di scrivere su rfcommX.

== Prerequisiti ==

L'utente deve essere nel gruppo "bluetooth". Per aggiungersi al gruppo bisogna editare il file /etc/group e aggiungere il vostro nome al gruppo, troverete qualcosa come

bluetooth:x:<ID>:

dovete aggiungere l'utente dopo i due punti

bluetooth:x:<ID>:utente

per attivare la modifica fate log out e log in

== Bluetooth Manager ==

Bluetooth Manager è il programma che viene aperto di default quando un adattatore Bluetooth USB è collegato al PC. Purtroppo è anche pieno di bug e abbastanza prono a crashare. Nelle ultime versioni pare che vada molto meglio. Nel caso abbiate problemi vi consiglio di chiudere il programma (dovete cliccare col tasto destro sull'icona del Bluetooth sulla barra delle applet oppure killate blueman-manager) e lanciare da un terminale blueman-manager. Vediamo passo passo come fare a creare un collegamento seriale.

Cliccate su "Search" e cercate il dispositivo a cui dovete collegarvi. Se non l'avete rinominato, gli HC si chiameranno HC-05 o HC-06. Nel caso ce ne sia più di uno, cercate di ricordare l'indirizzo fisico, il MAC Address.

[[File:Hc0506 1.png]]

Cliccate col tasto destro e selezionate "Pair". Uscirà un pop up in cui vi verrà chiesto il pin. Se non l'avete modificato normalmente è 1234.

[[File:Hc0506 2.png]]

Una volta avvenuto il pairing, comparirà il simbolo di una chiave vicino all'icona del vostro device Bluetooth. Cliccate di nuovo il tasto destro e selezionate Serial Port.

[[File:Hc0506 4.png]]

Se tutto è andato come doveva, vedrete l'indicazione di quale file di device è la vostra comunicazione seriale. Ora potete aprirlo con screen o altri programmi.

[[File:Hc0506 5.png]]

= Cambiare configurazione =

Gran parte di questo capitolo è preso da [http://www.instructables.com/id/AT-command-mode-of-HC-05-Bluetooth-module/ questa guida su Instructables].
Per cambiare configurazione al vostro modulo (ad es. cambiare velocità di trasmissione, nome, pin, ecc.) dovete entrare in modalità AT. L'HC-06 dovrebbe essere sempre in questa modalità, mentre l'HC-05 dev'essere acceso tenendo premuto il tasto "KEY" oppure mettendo a +3.3v il pin key sulla board. Quando è in modalità AT, l'HC-05 lampeggerà a intervalli di 2 secondi circa e potrete mandare i comandi AT alla seriale fisica sulla board. Se non avete un convertitore USB TTL, potete riciclare un Arduino per fare da ponte. Poiché l'Arduino Uno e simili (non il Mega, ad es.) ha una sola porta seriale, dovrete usare una porta seriale emulata via software. Lo sketch sarà più o meno così:

#include <SoftwareSerial.h>
SoftwareSerial mySerial(10, 11); // RX, TX
void setup() {
Serial.begin(9600);
pinMode(9,OUTPUT); digitalWrite(9,HIGH);
Serial.println("Enter AT commands:");
mySerial.begin(38400);
}

void loop() {
if (mySerial.available()) Serial.write(mySerial.read());
if (Serial.available()) mySerial.write(Serial.read());
}

Notate alcune cose di questo codice: mySerial è la software seriale dove andrà collegato il vostro HC, nei pin 10 e 11 (10 è RX e 11 TX, quindi il 10 andrà collegato al TX dell'HC e l'11 al RX). '''In modalità AT il modulo HC comunica a 38400 baud'''.

Ora aprite una seriale (va bene anche quella dell'IDE di Arduino, ricordatevi di mettere come CR e NL come fine linea) a 38400 baud e scrivete:

AT

L'HC dovrebbe rispondervi

OK

Se non lo fa forse avete sbagliato uno dei passi precedenti.

I comandi più utili sono:
* AT+NAME=<nome> cambia nome all'ID Bluetooth
* AT+UART=<baudrate> cambia la velocità della trasmissione Bluetooth (la modalità AT rimane a 38400)
* AT+ROLE=<1:master 0:slave> permette l'HC-05 di essere master o di essere solo slave in una comunicazione
* AT+ORGL ripristina le configurazioni di fabbrica
* AT+PSWD cambia la password

I comandi, se seguiti da ?, dovrebbero dire quale è il valore al momento memorizzato, ad esempio:

AT+UART?

dovrebbe restituire

9600

In [http://cdn.instructables.com/ORIG/FKY/Z0UT/HX7OYY7I/FKYZ0UTHX7OYY7I.pdf questa guida] potete trovare dettagli più approfonditi.

RaspiTank

2018-06-04T15:14:29Z

Oloturia: /* Il codice! Sempre più mal scritto! Sempre più mal commentato! */

Il RaspiTank è un tentativo di integrare il Raspberry Pi con un vecchio giocattolo a motore elettrico con i cingoli. Il controllo del motore è analogo a quello della [[RaspiCar]] mentre lo sterzo è affidato a un differenziale mosso tramite un servo.

= Prima versione =

[[File:Raspitank finale.jpg]]

Il RaspiTank aveva le seguenti caratteristiche:
* Motore alimentato da due batterie tipo D, alloggiate nel vano originale del giocattolo
* Raspberry Pi modello A, con Wi-Fi dongle, alimentato da 4 pile AA; garantisce qualche ora di autonomia, a seconda dell'uso
* Marcia avanti e indietro
* Sterzo ottenuto facendo girare un cingolo solo alla volta, usando il differenziale originale del giocattolo mosso da un servocomando
* Streaming dalla camera frontale
* Luci a LED accendibili e spegnibili
* Si può comandare da remoto tramite ssh con le frecce

[[File:RaspiTank_inlavorazione.jpeg]]

== Il nostro amico servocomando ==
I servi si muovono grazie a un impulso PWM come descritto in questa pagina: [[Servo (radio control)]]. A cicli di 20ms, a seconda dell'ampiezza dell'impulso, il servo si metterà in una posizione. Per il RaspiTank abbiamo usato la libreria ServoBlaster[https://github.com/richardghirst/PiBits/tree/master/ServoBlaster]. Poiché useremo (per ora) solo un servo abbiamo disabilitato tutti gli altri pin utilizzati dal demone di Servoblaster che altrimenti sarebbero stati inutilizzabili per altri scopi.

== Il groviglio di fili, ovvero la parte elettronica ==

[[File:Raspitank interior.jpg]]

Per l'azionamento del motore abbiamo riciclato i circuiti già fatti per la [[RaspiCar]] ovvero questi.

[[File:RaspiCar Schema Motor.png]]

La tensione data al motore circola in un senso o nell'altro a seconda di come scattano i due relè. Se il primo è acceso e il secondo è spento il motore girerà in un senso, vice versa se il primo è spento e il secondo è acceso il motore girerà nell'altro senso. Il motore resta spento se i due relè sono entrambi accesi o spenti.
Questo è il circuito per far scattare il singolo relè.

[[File:RaspiCar Schema Relay.png]]

Per via di una interferenza che portava il servo a muoversi da solo durante la marcia, abbiamo usato un ulteriore relè che alimenta il servo solo quando si deve muovere. Il circuito per l'alimentazione del servo è lo stesso degli altri due relè.
Per l'illuminazione abbiamo usato una luce alimentata da USB a due LED. Abbiamo collegato la terra alla terra della USB e il +5V al pin 15 wiringpi (pin 8 fisico). Nonostante siano solo 3,3V l'illuminazione è sufficiente per vedere diversi centimetri nell'oscurità ed evitare gli ostacoli.

== La camera ==
Inizialmente il RaspiTank usava una webcam recuperata da un EeePC della ASUS collegata alla porta USB. Con il passaggio dal Raspberry Pi modello B al modello A è venuta meno una porta USB e aggiungere un HUB sarebbe stato scomodo. Abbiamo così deciso di non usare MjpegStreamer[http://sourceforge.net/projects/mjpg-streamer/] e di usare la camera da attaccare direttamente alla porta CSI del Raspberry Pi. Questo ci ha costretti a disabilitare un pin di ServoBlaster (vedete la issue qui[https://github.com/richardghirst/PiBits/issues/11])

== Il codice, mal scritto e mal commentato ==

La libreria usata per la gestione della GPIO è wiringpi [https://projects.drogon.net/raspberry-pi/wiringpi/]. Per l'interfaccia testuale abbiamo usato curses.
Il codice accetta un argomento, il nome del file xml su cui scrivere le azioni registrate. Se non è specificato non verrà registrato nulla. Al momento esiste uno script per riprodurre le azioni salvate o scritte a mano. Purtroppo il motore del RaspiTank non è molto preciso e quindi la registrazione, al momento, non è molto affidabile.

Le frecce su e giù controllano il motore. Per fermare il RaspiTank occorre dare il controllo contrario (i.e. se sta avanzando occorre premere giù). Le frecce destra e sinistra fanno spostare l'ingranaggio del differenziale. Non è possibile cambiare la direzione mentre il RaspiTank sta muovendosi.
Il tasto spazio accende e spegne le luci.
Il tasto home accende la camera e fa partire lo streaming.
#!/usr/bin/python
import os
import wiringpi
import curses
import time
import sys
import threading

#PIN da usare
#11 controllo relay avanti
#10 controllo relay indietro
#14 controllo relay servo
#7 PWM servo (servo n.0 ServoBlaster)
#I relay devono essere alimentati da +5V
#Il servo puo' essere alimentato da +3,3V

class getkey(threading.Thread):
key = ''
light = False
motion = 'stop'
direction = 'straight'
def run(self):
while self.key != ord('q'):
self.key = stdscr.getch()
if self.key == ord(' '): #spazio accende e spegne le luci
if self.light:
motor.digitalWrite(15,motor.LOW)
time.sleep(0.5)
self.light = False
stdscr.addstr(6,5,"Lights:off")
else:
motor.digitalWrite(15,motor.HIGH)
time.sleep(0.5)
self.light = True
stdscr.addstr(6,5,"Lights:on ")
elif self.key == curses.KEY_HOME or self.key == curses.KEY_SHOME:
self.videostart = os.system("ps -ae|grep raspivid > /dev/null")
if self.videostart !=0:
stdscr.addstr(7,5,"Stream:on USE nc raspitank.local 9999 |mplayer -fps 150 -demuxer h264es -")
if self.key == curses.KEY_HOME:
os.system('raspivid -t 0 -fps 15 -w 640 -h 480 -rot 180 -o - |nc -l 9999 &')
else:
os.system('raspivid -t 0 -fps 15 -w 640 -h 480 -rot 180 -ex night -o - |nc -l 9999 &')
else:
stdscr.addstr(7,5,"Stream:off ")
os.system('killall raspivid >/dev/null')
os.system('killall nc >/dev/null')
elif self.key == curses.KEY_UP:
if self.motion == 'down':
stop()
self.motion = 'stop'
time.sleep(0.2)
elif self.motion == 'stop':
avanti()
self.motion = 'up'
stdscr.addstr(2,5,"Motion:"+self.motion+" ")
stdscr.refresh()
elif self.key == curses.KEY_DOWN:
if self.motion == 'up':
stop()
self.motion = 'stop'
time.sleep(0.2)
elif self.motion == 'stop':
indietro()
self.motion = 'down'
stdscr.addstr(2,5,"Motion:"+self.motion+" ")
stdscr.refresh()
elif self.key == curses.KEY_LEFT:
stop()
self.motion = 'stop'
if self.direction == 'right':
dritto()
self.direction = 'straight'
time.sleep(0.2)
elif self.direction == 'straight':
self.direction = 'left'
orario()
else:
self.direction = 'left'
time.sleep(0.2)
stdscr.addstr(2,5,"Motion:"+self.motion+" ")
stdscr.addstr(3,5,"Direct:"+self.direction+" ")
stdscr.refresh()
elif self.key == curses.KEY_RIGHT:
stop()
self.motion = 'stop'
if self.direction == 'left':
dritto()
self.direction ='straight'
time.sleep(0.2)
elif self.direction == 'straight':
self.direction = 'right'
antiorario()
else:
self.direction = 'right'
time.sleep(0.2)
stdscr.addstr(2,5,"Motion:"+self.motion+" ")
stdscr.addstr(3,5,"Direct:"+self.direction+" ")
stdscr.refresh()

exit()

def antiorario():
motor.digitalWrite(14,motor.HIGH)
os.system("echo 0=60 > /dev/servoblaster")
time.sleep(0.5)
motor.digitalWrite(14,motor.LOW)

def indietro():
motor.digitalWrite(10,motor.HIGH)

def avanti():
motor.digitalWrite(11,motor.HIGH)

def stop():
motor.digitalWrite(10,motor.LOW)
motor.digitalWrite(11,motor.LOW)

def orario():
motor.digitalWrite(14,motor.HIGH)
os.system("echo 0=240 > /dev/servoblaster")
time.sleep(0.5)
motor.digitalWrite(14,motor.LOW)

def dritto():
motor.digitalWrite(14,motor.HIGH)
os.system("echo 0=145 > /dev/servoblaster")
time.sleep(0.5)
motor.digitalWrite(14,motor.LOW)

if os.system("ps -ae |grep servod > /dev/null") !=0:
os.system("sudo servod > /dev/null")
motor = wiringpi.GPIO(wiringpi.GPIO.WPI_MODE_PINS)
motor.pinMode(10,motor.OUTPUT) #motore direzione 1
motor.pinMode(11,motor.OUTPUT) #motore direzione -1
motor.pinMode(14,motor.OUTPUT) #accensione servo
motor.pinMode(15,motor.OUTPUT) #luci
motor.digitalWrite(12,motor.LOW)
stop()
dritto()
if __name__=="__main__":
stdscr = curses.initscr()
curses.cbreak()
curses.noecho()
stdscr.keypad(1)
stdscr.addstr(0,5,"Press 'q' to quit, up/down = Motion, left/right = Direct, space = Lights")
stdscr.addstr(1,5,"home = Stream, shift+home = Night stream")
stdscr.addstr(2,5,"Motion:")
stdscr.addstr(3,5,"Direct:straight")
stdscr.addstr(6,5,"Lights:off")
stdscr.addstr(7,5,"Stream:off")
curses.curs_set(0)
stdscr.refresh()
getkey = getkey()
getkey.start()
key=' '
secondpass = time.time()
while getkey.key != ord('q'):
if time.time() - secondpass > 1:
link = os.popen('iwconfig wlan0 |grep "Link Quality"') #deprecated
stdscr.addstr(15,5,link.read().strip())
stdscr.refresh()
secondpass = time.time()
os.system('killall raspivid >/dev/null')
os.system('killall nc > /dev/null')
stop()
curses.endwin()
motor.digitalWrite(15,motor.LOW)

= RaspiTank con RaspiArm =

Tutto è iniziato quando ho trovato un braccio meccanico in scatola di montaggio[http://www.owirobots.com/store/index.php?l=product_detail&p=110]. Originariamente era filoguidato da un sistema di interruttori a levette, ma il fatto che avesse i contatti esterni con i pin perfettamente compatibili con quelli dei cavetti per la breadboard lo rendeva particolarmente irresistibile.
Inizialmente il gioco è stato eliminare il controller e usare la GPIO del Raspberry Pi per comandarlo. Essendo composto da cinque motori e dovendo comunque muovere il motore della base, ci sarebbero dovuti essere sette relè: due per determinare il senso della corrente e cinque per attivare ognuno dei motori. L'ultimo relè avrebbe mosso alternativamente il motore n.5 del braccio o il motore dei cingoli.

==Il nostro nuovo amico ULN2803==

ULN2803 è un driver che permette di dirigere i 5V del Raspberry Pi in 7 uscite diverse comandate dai pin della GPIO. In pratica sostituisce tutto quel circuito composto dal diodo e il transistor. Lo potete intravedere in questa foto, al centro della breadboard.

[[File:RaspiArm.jpeg]]

Non sto a scendere nel dettaglio del circuito: in pratica è il circuito già usato prima con più motori.

==L'unione dei due==

[[File:Raspitank_arm.jpeg]]

Una volta riportato il circuito della breadboard su una millefori è bastato fissare il braccio sulla base. Le luci sono state sostituite da un led già integrato sulla pinza. L'alimentazione del motore non è più dato da due pile torcia nella sede originale del carro ma sono le quattro che stanno dentro al braccio. Essendo raddoppiato il voltaggio adesso va molto più veloce.

==Il codice! Sempre più mal scritto! Sempre più mal commentato!==

Lo trovate su GitLab [https://gitlab.com/oloturia/raspitank https://gitlab.com/oloturia/raspitank]

Contiene:
* audio.sh Piccolo script per lo streaming audio (serve una scheda sonora USB con microfono)
* raspitank.ino Nella nuova versione un ATmega8 si occupa dei relay tramite seriale.
* roboy.py Il codice sul Raspberry
* videoday.sh Due script in bash per far partire lo streaming video normale...
* videonig.sh ...e con filtro notturno

= I video e altre foto =

[http://www.youtube.com/watch?v=H2Sz7JgYbbQ Il RaspiTank con il RaspiArm]

[http://www.youtube.com/watch?v=QB28DayPIVk Il video della prima scampagnata del RaspiTank]

[http://www.youtube.com/watch?v=3hHXWNNRBxU Il video della prima escursione notturna]

[[File:Raspitank_insegue_Ardubottino.png]]

Scappa, [[Ardubottino]], scappa!! (questa foto è quel che si vede dalla camera del RaspiTank)

[[Category:Progetti]]

Ardubottino

2018-06-04T15:13:30Z

Oloturia: /* Il codice */

Ardubottino è stato creato soprattutto per testare tre componenti: l'Arduino, il sensore della distanza a ultrasuoni e il ponte ad H. Lo chassis e i motori sono Tamiya.

[[File:Ardubottino.jpg]]

= Prima Versione =

== Componenti ==
Ardubottino ha questi componenti:
* Arduino UNO [http://arduino.cc/en/Main/arduinoBoardUno]
* Sensore di distanza a ultrasuoni SRF05 [http://www.robot-electronics.co.uk/htm/srf05tech.htm]
* Il board con montato il ponte ad H L298 [http://www.vetco.net/catalog/product_info.php?products_id=14337]
* Kit Tamiya per lo chassis e i motori
* Batteria da 9v
* Ulteriori batterie per il motore (inizialmente 4,5v, poi 4,8v)

Il sensore di distanza è sprovvisto di pin, occorre quindi saldarne una strip prima di procedere.

== Il sensore di distanza a ultrasuoni SRF05 ==
[[File:102_1298.JPG]]

È piuttosto semplice da usare. Seguendo le istruzioni [ http://www.robot-electronics.co.uk/htm/srf05tech.htm trovate qui] si può notare che ha due modalità di comunicazioni, date dal pin Mode. Se questo pin è collegato alla 0v il sensore userà un solo pin per la comunicazione dei dati dell'eco (Echo) e la ricezione dei comandi (Trigger), se, al contrario, non è connesso a niente allora saranno usati due pin diversi. Nel caso dell'Ardubottino ho preferito usare la prima modalità, quella con un pin solo (soprattutto per pigrizia: perché è già così lo sketch di esempio "ping" nella libreria di Arduino!). Oltre al pin Mode e al pin Trigger/Echo occorre collegare il primo e l'ultimo pin rispettivamente a +5v e a terra.
Nella foto si può vedere, da sinistra: +5v, non usato, Trigger/Echo (collegato al pin 13 di Arduino), Mode (terra), Terra (terra).

== Il board ponte ad H L298 ==
[[File:Ardubottino_dettagliol298.jpg]]

Il ponte ad H L298 è utilissimo per manovrare due motori indipendenti. Può essere usato anche per muovere un motore passo-passo.
Ha due ingressi per la corrente: tramite un ponticello può essere separata fra corrente per la logica e corrente per i motori. La logica dev'essere alimentata da +5v; se l'alimentazione è separata, i motori possono ricevere fino a +12v. Per comodità (e anche dopo diversi goffi tentativi per capire come funzionava) ho preferito alimentare i motori solo con i 5v.

Sui lati ci sono le connessioni per i motori mentre, a fianco dell'alimentazione, ci sono i pin che servono per comandarli. I pin sono sei, due sono gli enable per i motori e quattro servono per dare la direzione, due per motore. I pin dell'enable si possono chiudere con dei ponticelli, comandarli da Arduino/Raspberry Pi oppure gli si può mandare un impulso PWM per regolare la velocità.

== Motori ad encoder, gioie (poche) e dolorer (tanto) ==
Il problema di Ardubottino è che non va dritto. Il motivo? Forse il ponte ad H non dà gli stessi voltaggi ai motori, forse i motori sono un po' diversi, forse si stanno usurando in modo diverso, forse i cingoli hanno qualche imperfezione, forse le ruote sono storte, forse è sbilanciato. Ad ogni modo ognuno di questi problemi (tranne le ruote storte e le imperfezioni dei cingoli) si sarebbero risolti scoprendo a che velocità vanno i motori. Per scoprire questo dato sono necessari gli encoder. Un encoder è una rotellina con dei fori e un sensore o due, composti da un LED e da un ricevitore a infrarossi, che sentono quando un foro è passato. Encoder di questo tipo si trovano ad esempio nelle rotelline dei mouse o in quelli che hanno ancora la pallina.

[[File:EncoderArdubottino.JPG]]

Ora: questi sarebbero degli encoder "fatti apposta" per il kit Tamiya. Uso il condizionale perché, se non sono stato io ad averli montati in modo approssimativo, il loro utilizzo è alquanto scomodo. Anzitutto la rotella non sta fissa sull'albero. Il foro esagonale è troppo grande e ha un notevole gioco. Il range del sensore è minimo e non tiene conto della struttura del kit Tamiya (la rotella va quasi a sfregare contro le viti che lo fissano allo chassis). Inoltre sono estremamente fragili: una delle rotelle si è spaccata subito in due. I sensori stessi, poi, non si incastrano nella sede e occorre incollarli.
La lettura degli encoder andrebbe fatta sfruttando gli interrupt di Arduino. Gli interrupt sono dei pin che restano in ascolto e fanno scattare degli eventi quando cambiano valore[http://arduino.cc/en/Reference/AttachInterrupt]. Purtroppo uno dei due pin (sull'Arduino Uno sono il pin 2 e il pin 3) dava dei risultati estremamente inaffidabili. Dopo varie prove, il risultato migliore l'ho ottenuto usando la libreria Encoder [http://www.pjrc.com/teensy/td_libs_Encoder.html] su due pin non di interrupt. Il risultato di tutta questa fatica è un robottino che grosso modo va dritto. Un risultato mediocre di molto inferiore alla calibrazione a occhio. Alla fine, infatti, ho preferito quest'ultima.

== Lo sketch ==

Lo sketch deriva per una parte dall'esempio ''Ping'' già presente nella libreria di Arduino. In pratica fa avanzare Ardubottino fino a che non incontra un ostacolo. Se lo incontra sterza in un senso e poi nell'altro e alla fine prosegue per la direzione dove ha trovato più campo libero.
4 7 6 5 sono i pin a cui ho collegato il ponte ad H. Sterzo è il tempo che deve impiegare per sterzare. pinping è il pin a cui è attaccato il trigger/echo del sensore a ultrasuoni.
long duration;
long dursx;
long durdx;
const int en1 = 11; //pin enable
const int en2 = 9;
const int m1fd = 4; //controlli motore
const int m2fd = 7;
const int m1bk = 5;
const int m2bk = 6;
const int pinping = 13; //pin sensore distanza
const int sterzo = 600; //durata dello sterzo
const int distanza = 500; //distanza minima ostacoli
int motore1 = 67;//pwm motore dx
int motore2 = 74;//pwm motore sx

void setup() {
pinMode(m1fd, OUTPUT);
pinMode(m1bk, OUTPUT);
pinMode(m2fd, OUTPUT);
pinMode(m2bk, OUTPUT);
pinMode(en1, OUTPUT);
pinMode(en2, OUTPUT);
analogWrite(en1,motore1);
analogWrite(en2,motore2);
dritto();
}

void loop() {
if (echo() < distanza){ //trovato un ostacolo
analogWrite(en1,170);
analogWrite(en2,170);
ferma();
sinistra();
delay(sterzo);
ferma();
dursx = echo(); //guarda a sinistra
destra();
delay(sterzo*2);
ferma();
durdx = echo(); //guarda a destra
if (dursx < distanza && durdx < distanza){
destra();
delay(sterzo);
} else if (dursx > durdx) {
sinistra();
delay(sterzo*2);
} //sceglie dove c'è più spazio
dritto();
analogWrite(en1,motore1);
analogWrite(en2,motore2);
}
}

void dritto() {
digitalWrite(m1bk,LOW);
digitalWrite(m2bk,LOW);
digitalWrite(m2fd,HIGH);
digitalWrite(m1fd,HIGH);
}

void rovescia() {
digitalWrite(m1fd,LOW);
digitalWrite(m2fd,LOW);
digitalWrite(m1bk,HIGH);
digitalWrite(m2bk,HIGH);
}

void destra() {
digitalWrite(m1fd,LOW);
digitalWrite(m2fd,HIGH);
digitalWrite(m1bk,HIGH);
digitalWrite(m2bk,LOW);
}

void sinistra() {
digitalWrite(m1fd,HIGH);
digitalWrite(m2fd,LOW);
digitalWrite(m1bk,LOW);
digitalWrite(m2bk,HIGH);
}

void ferma() {
digitalWrite(m1fd,LOW);
digitalWrite(m2fd,LOW);
digitalWrite(m1bk,LOW);
digitalWrite(m2bk,LOW);
delay(50);
}

long echo() {
pinMode(pinping, OUTPUT);
digitalWrite(pinping, LOW);
delayMicroseconds(2);
digitalWrite(pinping, HIGH);
delayMicroseconds(5);
digitalWrite(pinping, LOW);
pinMode(pinping, INPUT);
duration = pulseIn(pinping,HIGH);
return duration;
}

= Seconda Versione =
Ok, la modifica è un po' minima per essere una vera e propria seconda versione, ma dopo il fallimento degli encoder ero un po' giù di morale.
Il progetto era di rendere Ardubottino telecomandabile con qualche mezzo estremamente low cost e nella maniera più semplice possibile. La mia scelta è caduta sull'infrarosso.

== Il sensore a infrarossi ==
[[File:Arduir.jpg]]

Quello che potete vedere nella foto è un sensore a infrarossi come quelli che potreste recuperare in qualsivoglia elettrodomestico. I sensori IR hanno tre pin: +5v, terra e dati. Questo in particolare aveva le stesse specifiche di quest'altro[http://learn.adafruit.com/ir-sensor/testing-an-ir-sensor] usato nel tutorial di Adafruit per leggere gli impulsi infrarossi con Arduino. Potrebbero non essere tutti uguali, quindi cautela.

== La libreria IRremote ==
Gran parte del lavoro lo fa la libreria IRremote (che trovate qui [https://github.com/shirriff/Arduino-IRremote]). Con questo sketch [http://www.mediafire.com/view/6qnsndqp9a838xe/Decode_IR.ino] si possono leggere, sotto forma di cifre, i codici del telecomando che volete usare. Tramite il monitor seriale noterete dapprincipio che ogni tasto ha assegnato due codici, questo per fare in modo che ci sia una differenza fra tenere premuto il tasto (dà lo stesso codice in uscita, in modo continuo) e dei clic ripetuti (ogni clic diverso il codice cambia). Con questo sketch sono riuscito a capire che il codice del tasto SU del telecomando era legato ai codici 2742014623 e 31889539.
La libreria IRremote permette anche di trasmettere, ma per ora non sfrutteremo questa sua proprietà. Potete trovare più informazioni qui [http://www.righto.com/2009/08/multi-protocol-infrared-remote-library.html]

== Lo sketch finale ==
Non ho voluto togliere all'Ardubottino la possibilità di andarsene in giro da solo, quindi ho assegnato al tasto OK del telecomando la capacità di passare dallo stato manuale a quello automatico.
La libreria IRremote ci permette di creare la classe IRrecv che, tramite i suoi metodi, prepara (enableIrIN) , legge (decode), e aspetta il prossimo segnale (resume). I valori sono memorizzati nella struttura decode_results, il cui valore value è il codice del segnale del telecomando. La variabile booleana automat determina se Ardubottino è in modalità automatica o meno.

<span style="color:#FF0000">ATTENZIONE: La libreria IRremote.h non è compatibile con la libreria RobotIRRemote fornita con l'ultima versione della IDE di Arduino. Per compilare questo sketch occorre prima disabilitare RobotIRRemote. Per disabilitare una libreria occorre andare in arduino/libraries e spostare la cartella della libreria in un altro posto.</span>

#include <IRremote.h>

int IRpin =2; //pin del sensore IR
IRrecv irrecv(IRpin);
long duration;
long dursx;
long durdx;

const int en1 = 10; //pin enable
const int en2 = 9;
const int m1fd = 4; //controlli motore
const int m2fd = 7;
const int m1bk = 5;
const int m2bk = 6;
const int pinping = 13; //pin sensore distanza
const int sterzo = 600; //durata dello sterzo
const int distanza = 500; //distanza minima ostacoli
int motore1 = 66;//pwm motore dx
int motore2 = 72;//pwm motore sx
boolean automat = false;

decode_results results;

void setup() {
pinMode(m1fd, OUTPUT);
pinMode(m1bk, OUTPUT);
pinMode(m2fd, OUTPUT);
pinMode(m2bk, OUTPUT);
pinMode(en1, OUTPUT);
pinMode(en2, OUTPUT);
analogWrite(en1,motore1);
analogWrite(en2,motore2);
irrecv.enableIRIn();
}

void loop() {
if(irrecv.decode(&results)){
if (!automat) {
if(results.value == 2742014623 || results.value == 31889539){
dritto();
} else if (results.value == 2383694249 || results.value == 2039764837 ) {
sinistra();
} else if (results.value == 15111918 || results.value == 2725237002) {
rovescia();
} else if (results.value == 1665824360 || results.value == 3250666572 ) {
destra();
} else {
ferma();
}
}
if (results.value == 3969632309 || results.value == 18594425) {
if (automat) {
automat = false;
ferma();
delayMicroseconds(300000);
}else{
automat = true;
dritto();
delayMicroseconds(300000);
}
}
irrecv.resume();
}
if (automat && echo() < distanza){ //trovato un ostacolo
analogWrite(en1,170);
analogWrite(en2,170);
ferma();
sinistra();
delay(sterzo);
ferma();
dursx = echo(); //guarda a sinistra
destra();
delay(sterzo*2);
ferma();
durdx = echo(); //guarda a destra
if (dursx < distanza && durdx < distanza){
destra();
delay(sterzo);
} else if (dursx > durdx) {
sinistra();
delay(sterzo*2);
} //sceglie dove c'è più spazio
dritto();
analogWrite(en1,motore1);
analogWrite(en2,motore2);
}
}

void dritto() {
digitalWrite(m1bk,LOW);
digitalWrite(m2bk,LOW);
digitalWrite(m2fd,HIGH);
digitalWrite(m1fd,HIGH);
}

void rovescia() {
digitalWrite(m1fd,LOW);
digitalWrite(m2fd,LOW);
digitalWrite(m1bk,HIGH);
digitalWrite(m2bk,HIGH);
}

void destra() {
digitalWrite(m1fd,LOW);
digitalWrite(m2fd,HIGH);
digitalWrite(m1bk,HIGH);
digitalWrite(m2bk,LOW);
}

void sinistra() {
digitalWrite(m1fd,HIGH);
digitalWrite(m2fd,LOW);
digitalWrite(m1bk,LOW);
digitalWrite(m2bk,HIGH);
}

void ferma() {
digitalWrite(m1fd,LOW);
digitalWrite(m2fd,LOW);
digitalWrite(m1bk,LOW);
digitalWrite(m2bk,LOW);
delay(50);
}

long echo() {
pinMode(pinping, OUTPUT);
digitalWrite(pinping, LOW);
delayMicroseconds(2);
digitalWrite(pinping, HIGH);
delayMicroseconds(5);
digitalWrite(pinping, LOW);
pinMode(pinping, INPUT);
duration = pulseIn(pinping,HIGH);
return duration;
}

= Terza Versione =
Dopo l'ennesimo disastroso trasporto di Ardubottino, nel quale si è smontato tutto, ho deciso di dargli una sistemata definitiva. Saldature migliori, componenti fissati e meno fili volanti. Inoltre sono state fatte le seguenti modifiche.

[[File:ardubottino_3ver.jpg]]

== Passaggio dal Micro al Pro Mini ==
Per ragioni di spazio sono passato dall'Arduino Micro al Pro Mini della Deek Robots.

[[File:Newardbot2.JPG]]

C'è poco da dire su questa board. È sotto tutti gli aspetti un Arduino Pro Mini. Per essere programmato ha bisogno dell'adattatore USB. Purtroppo, come si può vedere nell'immagine, l'ho montato alla rovescia sulla breadboard e così non è possibile capire il numero dei pin. Capirci qualcosa è stato particolarmente ostico.

== Abbastanza batterie ==
Avere l'alimentazione separata motori/logica è una soluzione che non mi soddisfa per niente. Come fare però per fare in modo che gli spikes dei motori non facciano riavviare l'Arduino? La questione è stata risolta in questa maniera.

=== Condensatori ===
Sono stati aggiunti dei condensatori ai motori. In questo modo lo spike dovrebbe essere assorbito in parte.

=== L'Arduino e i motori hanno una sorgente comune ===
Le batterie dei motori, 4 stilo da 2100mAh l'una, hanno amperaggio più che sufficiente per tenere acceso Arduino e motori. Dal + delle batterie partono due fili, uno va all'Arduino e l'altro al ponte ad H. Nei tentativi precedenti, davo al ponte ad H l'uscita a 5v dell'Arduino. Evidentemente la richiesta dei motori era eccessiva per il regolatore a 5v.

== Turbo! ==
Aggiunta la modalità turbo, che fa andare il ns. robot più veloce!

== Altri problemi ==
Avrei voluto mettere il sensore a ultrasuoni su un servo ma un bug della libreria Servo blocca il PWM in alcuni pin[http://forum.arduino.cc/index.php?topic=243264.0] per cui ho lasciato perdere.

== Nuovo codice! ==
Inutile incollarlo qui. Ho aperto uno spazio su GitLab:

[https://gitlab.com/oloturia/ardubottino Link]

= Quarta versione =
Era giunto il momento di sfruttare un po' di roba che rimaneva inutilizzata.
Le modifiche sono state:

* Encoder, stavolta funzionanti
* Calibrazione automatica
* Modalità programmazione
* Blocco quando una ruota non gira
* Sensore di caduta

== Encoders ==
Nonostante abbia rotto le rondelle originali (che comunque erano fatte malissimo) sono riuscito a trovare alcuni modelli funzionanti. Il PLA azzurro, a differenza di quello bianco e di quello nero, sembra riflettere l'infrarosso dell'encoder. Tutto stava nel capire quale forma funzionasse meglio.

[[File:Arduencoder.JPG]]

La forma che funziona meglio (per ora) è quella a destra. Potete trovare l'STL nel [https://gitlab.com/oloturia/ardubottino repository ardubottino su GitLab].

Il problema principale, nel creare questo tipo di oggetto in 3D, è stato il foro a forma di prisma esagonale. In Blender occorre creare un cilindro, ridurre i vertici a 6 e poi modificarne la dimensione solo con lo strumento proporzionale, in modo da non deformarlo.

[[File:Newardbot3.JPG]]

Gli encoder permettono di fare diverse cose interessanti. Ora Ardubottino sente quando una ruota non sta girando, ad esempio, inoltre sono state aggiunte due nuove modalità: la modalità "programmazione" (vai avanti di 10, poi gira a destra di 5, ecc.) e la modalità "calibrazione" (modifica la velocità di un motore fino a che le ruote non girano più o meno uguali).

Purtroppo gli encoder non sono tanto precisi, ogni tanto leggono male e segnano un passo in più o in meno. Questo però era così anche con le rotelle originali.

== Il sensore di caduta ==
Posto sul davanti, sente quando ad Ardubottino manca la terra sotto i cingoli. Quando sente il vuoto ferma tutto.

[[File:Newardbot1.JPG]]

== Il codice ==
Il codice sta diventando veramente troppo lungo per essere incollato qui, su questa pagina, per cui ne commenterò solo alcune parti. Lo sketch completo lo trovate su [https://gitlab.com/oloturia/ardubottino GitLab].

#include "ardubottino.h"
Sì, era ora che creassi un header con tutti i codici del telecomando. Per adattare Ardubottino a un altro telecomando basterà cambiare header.

volatile long right_interval = 0;
volatile long left_interval = 0;
volatile int right_count = 0;
volatile int left_count = 0;

Le variabili che sono modificate dagli encoder devono essere di tipo "volatile". Le variabili volatile possono essere cambiate da un evento esterno, nel nostro caso da un evento scatenato da un interrupt.

void right_encoder() {
static unsigned long last_interrupt = 0;
unsigned long time_interrupt = millis();
if(time_interrupt - last_interrupt >70){
right_interval = time_interrupt - last_interrupt;
next_check_right = millis()+right_interval*2;
right_count +=1;
last_interrupt = time_interrupt;
}
}

void left_encoder() {
static unsigned long last_interrupt = 0;
unsigned long time_interrupt = millis();
if(time_interrupt - last_interrupt >70) {
left_interval = millis() - last_interrupt;
next_check_left = millis()+left_interval*2;
left_count +=1;
last_interrupt = millis();
}
}

Ecco le brevi funzioni chiamate da
attachInterrupt(0, right_encoder,RISING);
attachInterrupt(1, left_encoder,RISING);
gli interrupt.
La variabile x_count conta quanti giri (quanti quarti di giro) ha fatto la ruota; x_interval l'intervallo, in millisecondi, fra un passaggio e l'altro; next_check_x è una stima massima di quando dovrebbe essere il prossimo passaggio, serve per capire se una ruota s'è inceppata.

if (irrecv.decode(&results)) {
curr_result = results.value;
if (curr_result == prev_result) {
curr_result = 0;
} else {
prev_result = curr_result;
}
(...)
}

Ricordate quando vi dissi che il telecomando per ogni tasto ha due codici? Serve per distinguere se state tenendo premuto il tasto o se lo state premendo più volte contemporaneamente. Con questo piccolo brandello di codice faccio in modo di ignorare i codici ripetuti, visto che ad Ardubottino non servono. Non tutti i telecomandi funzionano così.
if (program) {
if (curr_result == OKA || curr_result == OKB) {
blinkOK();
executeProgram();
clearMoves();
noMotion();
} else if (curr_result == NUM1A || curr_result == NUM1B) {
moves[pointer][0] = (moves[pointer][0]*10) +1;
blinkOK();
} else if (curr_result == NUM2A || curr_result == NUM2A) {
moves[pointer][0] = (moves[pointer][0]*10) +2;
blinkOK();
} else if (curr_result == NUM3A || curr_result == NUM3B) {
moves[pointer][0] = (moves[pointer][0]*10) +3;
blinkOK();
} else if (curr_result == NUM4A || curr_result == NUM4B) {
moves[pointer][0] = (moves[pointer][0]*10) +4;
blinkOK();
} else if (curr_result == NUM5A || curr_result == NUM5B) {
moves[pointer][0] = (moves[pointer][0]*10) +5;
blinkOK();
} else if (curr_result == NUM6A || curr_result == NUM6B) {
moves[pointer][0] = (moves[pointer][0]*10) +6;
blinkOK();
} else if (curr_result == NUM7A || curr_result == NUM7B) {
moves[pointer][0] = (moves[pointer][0]*10) +7;
blinkOK();
} else if (curr_result == NUM8A || curr_result == NUM8B) {
moves[pointer][0] = (moves[pointer][0]*10) +8;
blinkOK();
} else if (curr_result == NUM9A || curr_result == NUM9B) {
moves[pointer][0] = (moves[pointer][0]*10) +9;
blinkOK();
} else if (curr_result == NUM0A || curr_result == NUM0B) {
moves[pointer][0] = (moves[pointer][0]*10);
blinkOK();
} else if (curr_result == FORWARDA || curr_result == FORWARDB) {
moves[pointer][1] = 1;
pointer ++;
blinkOK();
} else if (curr_result == BACKA || curr_result == BACKB) {
moves[pointer][1] = 2;
pointer ++;
blinkOK();
} else if (curr_result == LEFTA || curr_result == LEFTB) {
moves[pointer][1] = 3;
pointer ++;
blinkOK();
} else if (curr_result == RIGHTA || curr_result == RIGHTB) {
moves[pointer][1] = 4;
pointer ++;
blinkOK();
} else if (curr_result == WINA || curr_result == WINB) {
clearMoves();
blinkOK();
} else {
blinkNO();
}
if(moves[pointer][0] > 99) {
moves[pointer][0] = moves[pointer][0]-((moves[pointer][0]/100)*100);
}
if (pointer >49) {
executeProgram();
}
}

Et voilà: 50 mosse programmabili per il nostro robottino. Si scrive un numero di massimo 2 cifre e una direzione per massimo 50 istruzioni. Premendo OK si dà inizio al programma.
Ho anche aggiunto un lampeggiamento del LED di bordo in modo da dare un feedback visivo. Come ben saprete, i telecomandi a volte non trasmettono bene.

void executeProgram() {
int right_count_program = right_count;

for (int x=0;x<=49;x++){
if (moves[x][1] == 0) {
break;
} else if (moves[x][1] == 1){
forward();
} else if (moves[x][1] == 2){
backward();
} else if (moves[x][1] == 3){
left();
} else if (moves[x][1] == 4){
right();
}
while(moves[x][0] > 0) {
if (right_count_program != right_count ) {
moves[x][0] --;
right_count_program = right_count;

}
if (digitalRead(fall)) {
noMotion();
program = false;
return;
}
}
moves[x][1] = 0;
}
program = false;
noMotion();
}

Come potete vedere a metà c'è anche un check (c'è anche per le modalità automatica e manuale) sul sensore di caduta.

if (curr_result == BLUEA|| curr_result == BLUEB) { //calibration
blinkOK();
program = false;
automat = false;
noMotion();
delay(500);
forward();
int loops = 0;
int last_left = left_count;
int last_right = right_count;
bool left_pass = false;
bool right_pass = false;
while (loops < 12) {
if (last_left != left_count) {
left_pass = true;
}
if (last_right != right_count) {
right_pass = true;
}
if (left_pass && right_pass) {
left_pass = false;
right_pass = false;
last_left = left_count;
last_right = right_count;
if (abs(right_interval - left_interval) < 80) {
loops +=1;
} else if (right_interval > left_interval) {
motor1PWM += 1;
analogWrite(en1,motor1PWM);
loops = 0;
} else {
motor1PWM -= 1;
analogWrite(en1,motor1PWM);
loops = 0;
}
if(debug) {
Serial.print(motor1PWM);
Serial.print(" ");
Serial.println(motor2PWM);
}
}
}
noMotion();
}

La calibrazione: modifica la potenza di uno dei due motori fino a che gli intervalli degli encoder delle due ruote non sono quasi uguali. Occorre staccare i cingoli o mettere Ardubottino in un posto sopraelevato perché per funzionare ha bisogno di andare forward() per qualche minuto.

[[Category:Progetti]]