RedSleeve 7.1 – L’annuncio ufficiale

RedSleeve7

Ho visto solo da qualche giorno che il 18 luglio sul sito ufficiale della RedSleeve è stato pubblicato un annuncio riguardante l’uscita della RedSleeve 7.1. In effetti l’immagine è rimasta sempre quella pubblicata a Maggio del 2015, quindi gli aggiornamenti risiedono nei pacchetti contenuti nei repository ufficiali. L’ho installata su una nuova microSD per testarla di nuovo e in modo più approfondito. Nel mio caso si tratta di quella realizzata per il Raspberry Pi2. Ricordo che l’utente root ha come password preimpostata “password”. Appena fatta partire ho effettuato alcune operazioni preliminari che descrivo sinteticamente, senza entrare nei particolari per il momento. Il problema più grosso sono i repository di Yum che non esistono più e vanno sostituiti con i nuovi.

  1. Ridefinito la password di root con una più sicura.
  2. Cambiato il nome host in (/etc/hostname).
  3. Aggiunte alcune variazioni nel file /boot/config.txt assegnando il mimimo possibile di memoria alla GPU e aggiungendo lo schema di clocking del RPi2

4. Tolto il NetworkManager che risulta attivo (stop e disable) e ho lasciato gestire la lan wired dall’ifcfg-eth0. Tutto OK.

5. Tra i (pochi) servizi attivi ho rimosso Postfix (stop e disable) che se non utilizzato va tolto da un minimal server.

6. Verificato che Selinux fosse disabilitato e che (per il momento) il firewall (firewalld) fosse spento.

7. Espansa la partizione di root (/) alla capacità massima della scheda, in questo caso 64Gb.

8. I repository di YUM nella directory (/etc/yum.repos.d) non funzionano. Ho rinominato quelli presenti in .old e ho provveduto a creare un nuovo RedSleeve.repo contenente:

Il comando < yum upgrade > li trova correttamente, dopo di che lo < yum update > aggiorna  una certa quantità di pacchetti.

A questo punto inizierò la fase di test, controllando varie tipologie di utilizzo, comprese l’installazione e l’uso delle librerie GPIO che per ora vengono giudicate affidabili (a ragione) solo in ambiente Raspbian. Spero che si dimostri una distro affidabile, visto che la Centos 7 mi risulta ancora in fase Alpha e ci vorrà  svariato tempo prima di essere completata.

 

 

 

Radiatore passivo per la CPU del Raspberry Pi2

Akru_03

Dal momento che i miei 2 Raspberry Pi2 sono destinati ad essere accesi H24 mi sono deciso di dotarli almeno di un radiatore passivo sulla CPU per far scendere la temperatura di esercizio di qualche grado. Ce ne sono di vario tipo ma ho scelto questo kit in rame della Aukru che ne comprende un paio ad un prezzo poco inferiore agli 8 euro. Come si vede in foto sono dotati di un biadesivo costituito da una sorta di pasta conduttiva. Rimossa la protezione bianca rimane esposto uno strato nero e appiccicoso che va messo a contatto della CPU.

Akru_02

Non so quanto tempo ci voglia affinchè questa sorta di pece si stabilizzi, ma dopo circa un’ora dall’applicazione ho notato un calo della temperatura del processore di circa 5 gradi (da 49 gradi a 44 gradi) che mi sembra comunque già buono considerando che si tratta comunque di un radiatore passivo.

Akru_01

La superficie di copertura è buona, siamo appena al di sotto delle dimensioni effettive della CPU, ma è roba di poco conto. Raggiungevo la temperatura di circa 50 gradi con una temperatura ambientale di 27 gradi e con il clock massimo mantenuto ai valori nominali. Quindi quest’inverno mi aspetto ancora qualche grado in meno come temperatura di lavoro, il che non guasta.

pi2

Ho usato per i Raspberry questo tipo di contenitore che tra l’altro è progettato per il B+, quindi come si vede in figura non ha neanche il foro per la CPU perfettamente corrispondente. Per fortuna la plastica di questa copertura non è molto spessa e con un taglierino e qualche minuto di lavoro ho portato allo scoperto buona parte della scheda, il che ha permesso di migliorare la dissipazione del calore in generale e di coprire la CPU con il dissipatore.

Per il Banana Pro dovrò trovare qualcosa di differente, perché a parte il fatto che se non ricordo male la CPU ha dimensioni maggiori, ma è anche situata nella parte inferiore della scheda e quindi richiede altre soluzioni, non ultima quella di montarla “al contrario”, con il processore in alto. Anche il Banana è acceso H24 e le temperature di esercizio della CPU sono grosso modo le stesse del Raspberry.

Arduino – HC RS04 Gli occhi del Robot

HCRS04

Finalmente mi sono arrivati un paio di HC RS04, sensori ad ultrasuoni che troppe volte si vedono impiegati nei robot basati su Arduino (e non solo) letteralmente come un paio di “occhi”. Occhi di pipistrello per la precisione, che emettono ultrasuoni, quindi funzionano anche al buio, e in base ai tempi di riflessione calcolano la distanza degli oggetti e attuano strategie di comportamento. I pipistrelli emettono a frequenze intorno ai 200KHz, noi ci accontenteremo di 40KHz per stimare la distanza dei nostri ostacoli. Il range di misura dichiarato spazia tra i 2cm e i 400 cm. In genere questo sensore viene montato su un supporto semovente su più assi (destra/sinistra, alto/basso) in modo da poter fornire anche informazioni sulla direzione nello spazio di ostacoli. Un vero “must have” per un Robot, senza dubbio.

Il sensore utilizza un impulso di Trigger emesso per 10 microsecondi, misura il ritardo sul pin di Echo e permette, dividendo per due questo ritardo in quanto frutto di andata e ritorno del segnale, di calcolare la distanza dell’ostacolo. Dal momento che un termine dell’equazione è la velocità del suono nell’aria e quest’ultima è in funzione della temperatura ambientale è possibile aumentare la precisione di misura tenendo conto proprio della temperatura esterna. Ed è proprio quello che ho previsto nello sketch simulando nel mio caso una temperatura di 26,5 gradi. Questo valore naturalmente si può dedurre in tempo reale utilizzando una qualsiasi sonda di temperatura il cui output va inserito nel parametro di entrata della funzione leggi_HCRS04().  Al di là del discorso teorico, metro alla mano ho verificato un miglioramento della precisione di circa 4-5 cm su una distanza di circa 150 cm. Se abbiamo intenzione di costruire un misuratore di distanze ad ultrasuoni tutto questo ha un suo perché.

Per i maniaci della precisione esiste anche una libreria esterna opzionale che si chiama NewPing (http://playground.arduino.cc/Code/NewPing) che effettua letture multiple mediate e pesate, in modo tale da usare al meglio questo sensore. Potrebbe valere la pena perderci un po’ di tempo, chissà….

Collegamenti ad Arduino:

Sketch di esempio:

Sunfounder compatibile Arduino Uno R3 e shield Ethernet

A dire il vero mi serviva uno shield ethernet W5100 e il fatto che fosse in vendita insieme alla scheda compatibile UNO R3 sempre della Sunfounder allo stesso prezzo di un Arduino originale mi ha invogliato a comprare il kit.

arduino_sunfounder

La qualità costruttiva del clone mi sembra effettivamente buona, sia per la componentistica usata che per la qualità dell’assemblaggio e delle saldature. Questa mia impressione viene comunque confermata in genere dai giudizi che ho trovato in giro per la Rete. Lo shield W5100 non è proprio il modello più recente, lascia infatti non replicate le ultime coppie di piedini dell’R3 e questo sembra attribuire il progetto alla versione R2 di Arduino, ma spero che questo non comporti problemi nell’uso che intendo farne.

ethernet_shield

Nella foto dove lo shield risulta montato si possono vedere infatti gli ultimi due piedini di Arduino che non hanno corrispondenza sullo shield, e lo stesso accade dall’altro lato. Per confronto si possono esaminare gli shield originali nel sito Arduino.cc (https://www.arduino.cc/en/Main/ArduinoEthernetShield) dove si vede la differenza tra quello nuovo e quello precedente. Tramite lo stesso link, nella parte finale della pagina, è possibile accedere alla Ethernet Library Reference per questa scheda.

Infine qui in basso la Sunfounder a confronto con la scheda Arduino italiana di arduino.org

arduino2

Raspberry e Banana Pi/Pro – Leggere la temperatura della cpu

Ecco due brevi script utili per leggere la temperatura corrente della CPU rispettivamente sulle schede Rasbberry e Banana Pi/Pro. Sulla prima scheda le ho testate su distribuzioni Fedora e Centos (mi aspetto che funzioni anche sulla Redsleeve). Nel secondo caso è testato sulla Bananian,

Raspberry:

Banana Pi/Pro:

Si può ad esempio copiare il codice in uno script chiamato cpu_temp.sh nella directory /root/scripts (da creare) e dopo aver dato un comando chmod 755 cpu_temp.sh lanciarlo con ./cpu_temp.sh.

Arduino – KY032 rilevatore di ostacoli

KY032

Questo è uno di quei sensori specificatamente dedicati alla robotica che servono per segnalare la presenza di ostacoli. In questo caso sono presenti due dispositivi IR, uno dedicato alla trasmissione del segnale ed uno per ricevere un eventuale rimbalzo da un ostacolo. Esistono altri sensori di questo tipo, come il KY033, detto anche Tracking Sensor, che possono essere utilizzati anche collegandone più di uno accanto all’altro per far seguire ad un robot semovente una “pista” di colore nero, preferibilmente su di uno sfondo bianco. Questo tipo di sensori ha la caratteristica di non individuare ostacoli di colore nero o molto scuri, in quanto questi ultimi assorbono la maggior parte della radiazione IR e quindi non restituiscono segnale riflesso. Con ostacoli di colore chiaro o bianchi a pochi cm dal sensore viene emesso il segnale di rilevamento. Per evitare questo tipo di problema è meglio utilizzare sensori ad ultrasuoni come l’HC SR04 che è in grado anche di effettuare una buona misura della distanza dell’ostacolo da pochi cm a circa 4mt.

Sensore digitale quindi, alimentabile max a 5V. Collegamenti:

Sketch di test:

Arduino – KY026 Flame sensor

ky026

 

Questo sensore, basato su un led infrarosso, intercetta fiamme accese nell’ambiente. Va alimentato a 5V ed è ibrido, ovvero utilizzabile sia come analogico che digitale. La lettura analogica mi sembra che non abbia molto senso, per cui l’utilizzo più razionale mi sembra quello di collegarlo ad una porta digitale e fargli segnalare o meno la presenza di una fiamma nei dintorni. Copre un angolo di circa 60 gradi rispetto la parte anteriore del led ma si potrebbe provare a dotarlo di un qualche diffusore, un po’ come si fa con i sensori PIR di movimento, per ampliare l’angolo di misura. Funziona piuttosto bene, sono rimasto sorpreso dal constatare che intercetta la fiamma di un comune accendino già a 1mt di distanza. I collegamenti:

Sketch di test:

Arduino – KY021 e KY025 sensori switch Reed di campo magnetico

KY021-025

Ho già provato dei sensori rilevatori di campi magnetici basati sull’effetto Hall. Questi due sono di tipo Reed, entrambi switch (on/off), alimentati a 5V, digitale il primo e ibrido il secondo. Meglio i Reed o gli Hall? Mah, non saprei. Tutto sommato mi sembra che vengano usati per gli stessi scopi, ovvero controlli di velocità di rotazione, contatori, e via dicendo. A questo punto diventa una questione didattica approfondire i principi che utilizzano i due tipi di sensori, ovvero i contatti Reed in genere:

https://it.wikipedia.org/wiki/Reed_(dispositivo)

e l’effetto Hall:

https://it.wikipedia.org/wiki/Effetto_Hall

Personalmente quello che preferisco più di tutti è il KY025, che mi sembra decisamente il più sensibile di tutti e 4 quelli che ho provato. Oltretutto è dotato di un regolatore di soglia, nonché il solito chip comparatore che se non sbaglio è l’LM393 e un po’ di elettronica di contorno. Immagino però che avrà un consumo di corrente più alto. A favore dei sensori ad effetto Hall, tipo il KY024, va detto che non hanno parti meccaniche mobili come i Reed e riescono anche a intercettare la polarità del campo magnetico rilevato.

Sketch simili quindi visto che ho usato il KY025 sull’uscita digitale ma attenzione perché il KY021 manda a LOW il pin segnale quando intercetta una fonte di campo magnetico mentre il KY025 si comporta all’opposto.

SKETCH DI TEST:

 

Arduino – KY002 e KY031 sensori di vibrazioni e colpi

KY002-031

Questi sensori sono entrambi digitali e vanno alimentati a 5V. Il primo, il KY002 è un sensore di vibrazioni e fornisce un segnale basso sul pin relativo quando intercetta uno scuotimento. Può registrare anche un colpo naturalmente e in questo si rileva più sensibile del KY031 e rimane in stato LOW fino alla cessazione della vibrazione. Il secondo sensore, il KY031 attua la stessa strategia ma solo in presenza di un colpo; se viene semplicemente scosso vibrando non segnala nulla. Va detto che sono basati entrambi su minuscole molle (quella del KY031 si intravede nella foto) e quindi presentano dei “rimbalzi” di segnale anche quando il fenomeno è cessato. Sono comunque molto brevi e possono essere eventualmente gestiti con funzioni temporali (tipo la millis() per dirne una) per non tenerne conto. Gli sketch di test per entrambi sono praticamente identici: io li inserisco tutti e due ma, insomma, cambiano solo le stringhe di presentazione del codice. Il resto si equivale.

SKETCH DI TEST:

Banana Pi/Pro – Installazione librerie Python e C per i GPIO

La preparazione dell’ambiente di sviluppo C e Python nelle 2 schede Lemaker avviene in maniera analoga ai passi compiuti con i Raspberry. Lemaker ha infatti adattato le stesse librerie GPIO e WiringPi per i due linguaggi rendendo le cose molto più semplici.

Ho scelto come S.O. di riferimento per il Banana Pro in mio possesso il Bananian 15.04 . Non è dotato di interfaccia grafica quindi è ideale per ottenere il massimo delle prestazioni dalla scheda pur richiedendo solo l’accesso SSH e quindi conoscenze di Linux Debian in generale. Immagino che il tutto funzioni perfettamente anche su Raspbian mentre invece ho rilevato dei problemi insanabili con la Fedora: un problema con una libreria del cross compiler rende impossibile la compilazione sia delle GPIO che delle WiringPi. Mi viene il sospetto che sia colpa di come è stato preparato il kernel della distribuzione, quindi niente da fare.

Sulla Bananian si opera come utente Root, quindi non si usa l’elevazione “sudo”. Chi usa la Raspbian si regoli di conseguenza e premetta “sudo” ai comandi di tipo amministrativo.

Installazione preliminare:

Procediamo con le librerie per il Python. Il possesso di un Banana Pi oppure Pro impone due download differenti:

Banana Pro:

Banana Pi:

Installazione della libreria:

Controllare dai messaggi di uscita che tutto sia andato bene. Durante la compilazione vengono prodotti dei “warning”. Sarebbe meglio se non ci fossero ma non comportano problemi.

Passiamo alle librerie WiringPi per il linguaggio C. Torniamo alla directory /root.  Il download anche qui dipende dalla scheda Pi o Pro:

Banana Pro:

Banana Pi:

E installiamo:

Se tutto è andato bene possiamo controllare l’installazione con

ma soprattutto vedere le mappature del connettore a 26 o 40 pin con:

Ecco ad esempio l’output relativo al Banana Pro:

Schermata 2015-08-08 alle 08.53.29

 

Al centro si vedono quindi i Pin Fisici della scheda, che in fase di setup vengono denominati BOARD, poi quelli codificati dalla libreria C WiringPi e infine i BCM.

Io in genere in Python preferisco iniziare il codice con una GPIO.setmode(GPIO.BOARD), utilizzando quindi i Pin Fisici della scheda. Quando ci sono varie versioni di schede con diverse mappature (sia su Banana che su Raspberry) mi sembra che si faccia meno confusione in questo modo.