Bentornati al nostro appuntamento con la prototipazione rapida. In questo articolo continueremo a basare lo sviluppo delle nostre idee di progetto sui principi fondamentali del rapid prototyping e dell'Open Source. Questa volta, però, il caso di studio che vorremmo realizzare riguarda il nostro smartphone. In particolare, un sistema di supporto per rendere più automatizzati alcuni meccanismi tipici della domotica. Scopriremo che il prototipo potrà essere utile non soltanto in casa ma anche al lavoro. Siete pronti?

INTRODUZIONE

Ormai è chiaro: la prototipazione rapida è un paradigma abilitante per la sperimentazione. Le sue possibilità sono davvero infinite e consentono realmente di cambiare il nostro modo di ragionare e progettare. Dopo aver visto in generale cosa significa fare l’IoT, nell'ambito di progetti più o meno complessi, oggi proviamo a guardare con occhi diversi un altro oggetto di uso comune, sicuramente sulla scrivania di molti, ovvero lo stand del cellulare. Non sono molti quelli di noi che utilizzano lo smartphone senza uno stand che lo tenga sollevato sulla scrivania, accanto allo schermo del computer. Chiunque faccia un lavoro di ufficio sa che questa configurazione consente di rispondere in maniera più efficiente alle chiamate, diminuire il consumo della batteria, ottimizzare le pause e propone anche diversi altri vantaggi. Il problema è che lo stand del cellulare è un elemento puramente passivo, talvolta un elemento d'arredo ma sicuramente non propone nessun livello di interazione con l'utente. Serve a svolgere semplicemente la sua funzione, ovvero mantenere il cellulare in una data posizione. Eppure, anche un oggetto così semplice può essere trasformato in qualcosa di estremamente più complesso e che rientri a far parte di un ecosistema di automazione che migliora le condizioni di lavoro e, in definitiva, la vita di chi lo possiede.

POSSIBILI SCENARI

Proviamo ad analizzare questo oggetto per capire esattamente come può funzionare e per cosa può essere utilizzato oltre ciò che naturalmente vediamo. Il cellulare ha una proprietà: viaggia insieme con l'utente, si sposta con lui, in sostanza vive la stessa realtà del suo possessore. Molto spesso il telefono consente di svolgere azioni nel mondo come ad esempio il pagamento al supermercato oppure al cinema. Quando l'utente è al lavoro, occupa il suo posto in scrivania, mantiene quell'assetto per diverse ore durante la giornata, e non è detto che non riceva anche telefonate. Probabilmente, quando l'utente arriva al lavoro, seduto alla sua scrivania, ha anche una connessione Wi-Fi alla quale collegarsi. Ciò propone anche dei vantaggi in termini di efficienza energetica, dal momento che consente all'utente di limitare il consumo energetico sfruttando proprio la connessione Wi-Fi piuttosto che la rete dati. Inoltre, una volta che si è giunti alla propria postazione, non dovendosi muovere più per diverse ore durante la giornata, si potrebbe sfruttare il tempo per ricaricare il cellulare. Queste sono possibilità che lo smartphone già offre e che si possono già sfruttare. Quando si arriva a casa, probabilmente si possiede un altro stand, che svolge il ruolo di deposito del cellulare durante il periodo di permanenza in ambito domestico. Questo ci suggerisce che lo stand possa essere in qualche modo collegato all'ambiente in cui il cellulare si trova. Non sarebbe bello se questo potesse diventare parte dell'intelligenza dell' oggetto, in chiave 2.0? Dovremmo avere a disposizione qualche forma di tecnologia che sia in grado di capire quando il cellulare si trova in prossimità dello stand e ovviamente quando se ne allontana. Ma qualcosa di questo tipo già esiste: si tratta dell'NFC, acronimo di Near Field Communications. Si potrebbe anche pensare di utilizzare il Bluetooth. Quindi esistono almeno due possibili tecnologie sulle quali potremmo basare lo sviluppo del nostro prototipo. Entrambe, infatti, si rivolgono alle interconnessioni ed alle interazioni a corto raggio, sebbene il Bluetooth riesca a coprire distanze maggiori dell’NFC. Quest'ultima tecnologia, infatti, è rivolta alle comunicazioni a cortissimo raggio, ovvero non oltre i 10 cm, nel caso migliore. Il Bluetooth, invece, è una tecnologia di comunicazione che si rivolge a comunicazioni a corto raggio ma sempre nell'ambito di distanze leggermente più grandi, tipicamente della decina di metri. Analoghe considerazioni andrebbero fatte per la mole di dati gestita, che nel caso del Bluetooth è decisamente superiore rispetto a quanto accade con l'NFC. Queste differenze non sono importanti solo quando si vogliono valutare le prestazioni di una rete di telecomunicazioni, ma anche quando si vuole comprendere se la tecnologia sia più o meno utile, se la sua applicabilità sia valida o meno. Il caso specifico che stiamo considerando prevede il cellulare che viene poggiato sullo stand e lasciato lì fino a quando non arriva il motivo per cui l'utente, proprietario del telefono, debba spostarlo. Il telefono sarà appoggiato, ovvero si assume che la distanza sia davvero irrisoria. Ecco per quale motivo possiamo pensare che le Near Field Communications rappresentino il candidato ottimo per tale applicazione. Adesso che abbiamo a disposizione una tecnologia, sappiamo che il nostro cellulare deve essere abilitato NFC. Supponiamo di voler progettare uno stand per il luogo di lavoro, la rilevazione dell'NFC, in questo caso, dovrà semplicemente abilitare la rete Wi-Fi, già salvata in precedenza (e quindi l'autenticazione sarà automatica), spegnere la connessione dati, magari abilitare il Bluetooth per la connessione del cellulare al computer in maniera tale da poter scambiare dati facilmente e diminuire la luminosità dello schermo. Queste sono azioni abbastanza semplici che possono essere svolte anche con l'utilizzo di un’app elementare. Peraltro, di app che gestiscono tag NFC ce ne sono tantissime, per cui non vale la pena passarle in rassegna tutte. Abbiamo, quindi, capito che il caso in cui vogliamo semplicemente che lo stand identifichi il posto, si può risolvere facilmente con un solo tag collegato allo stand ed un cellulare abilitato con un controllo tramite app. Da progettare, qui, non c'è molto altro. Vediamo di complicare un po' le cose. Supponiamo di voler non soltanto programmare uno stand da ufficio ma anche uno da automobile ed uno da casa. Naturalmente si potrebbe pensare di gestire tutto tramite app nello stesso modo, ma la cosa comincia a complicarsi un po' quando invece di spegnere ed accendere i dispositivi all'interno dello smartphone, vogliamo fare qualcosa di più complesso, come ad esempio tenere traccia dei nostri spostamenti per poter creare degli ambienti di lavoro che siano più confortevoli ed un ambiente domestico più smart. Supponiamo, quindi, di voler mappare gli spostamenti di una persona da casa a lavoro per poter decidere se accendere o spegnere il riscaldamento oppure realizzare funzioni più complesse come, ad esempio, aprire automaticamente il cancello di casa una volta che si arrivi da lavoro con la macchina. Per poter implementare tutte queste funzioni diverse abbiamo sicuramente bisogno di un sistema più complesso che sia in grado di leggere i tag NFC, ma sia anche in grado di connettersi ad Internet per poter elaborare le informazioni in tempo reale. Immaginiamo, allora, che lo scopo del progetto sia seguire un utente durante i suoi spostamenti. L'utente esce di casa, togliendo il cellulare dallo stand domestico, per muoversi verso l'ufficio. Una volta uscito di casa con l'automobile, sarà disponibile la sua posizione GPS, per cui la triangolazione della sua posizione restituirà un punto non più all'interno delle mura domestiche. A cosa potrebbe servire tutto ciò? Beh, le luci di casa potrebbero essere rimaste accese, e comunque non ha senso tenere il router Wi-Fi attivo quando non ci siamo, il riscaldamento sicuramente può essere abbassato in maniera tale da garantire un minor spreco energetico. Le variabili all'interno dell'ambiente domestico sono davvero tantissime. Aspettiamoci, sul luogo di lavoro, che il funzionamento possa essere riproposto nella misura in cui prima abbiamo identificato alcune funzionalità di interesse. È possibile che tutto questo venga gestito attraverso un servizio web ma anche localmente. Volendo creare un ecosistema, è assolutamente indispensabile che ci sia un apparecchio in grado di eseguire alcuni compiti, interfacciandosi anche con il web, per poter "storicizzare" gli spostamenti, verificare le preferenze, consentire delle personalizzazioni ed anche, perché no, proporre delle configurazioni intelligenti all'utente.

PROCEDIAMO CON ORDINE

Cerchiamo, se esiste, una soluzione tecnologica pensata per il rapid prototyping, che consenta di contenere i costi e abiliti lo stand alla comunicazione NFC. Uno dei più usati tra i chip NFC-ready è l'NXP PN532. Di breakout board e reference design che lo utilizzano ne troviamo diverse a disposizione, come ad esempio la board distribuita da Adafruit.

Figura 1. Breakout board di Adafruit basata su PN532

Trovato il componente che ci consente di fare la lettura e la rilevazione del nostro smartphone, dobbiamo comprendere che tipo di specifiche tecniche ci propone, in particolare dobbiamo studiare l'effettiva distanza di rilevazione, il tempo che intercorre tra una rilevazione e la successiva, ammesso che ci sia un vincolo su questo, le interfacce di comunicazione e, ovviamente, l'alimentazione. Molte di queste specifiche potrebbero essere comuni a più esponenti della stessa categoria, ovvero è possibile che più reader basati su questa tecnologia, siano in grado di funzionare con la stessa tensione di alimentazione. Non possiamo, però, esserne sicuri quando cominciamo, per cui una buona ricerca di mercato parte dal presupposto che stiamo cercando di comprendere tutte le possibilità che il nostro sistema di rilevazione propone. Una volta che abbiamo capito quali sono i valori notevoli, possiamo passare all'elaborazione dei dati. Il nostro reader, molto probabilmente, si occupa soltanto di effettuare la lettura, ma il trattamento del segnale e le successive azioni che ne derivano non sono comprese all'interno della scheda che stiamo osservando. È necessario comprendere, dunque, quale sarà il circuito di interfaccia e quale sarà la logica del suo funzionamento. Una delle domande alle quali dobbiamo sicuramente poter rispondere è sul tipo di funzionamento che vogliamo per il nostro circuito. Vogliamo che sia sempre acceso? Una volta in funzione, il comportamento dovrà essere sempre lo stesso? Queste domande sembrano banali ma ci aiutano a comprendere se stiamo cercando di progettare un sistema che potrebbe basarsi su un microcontrollore oppure se serva un microprocessore. La differenza sta nell'intelligenza che dobbiamo mettere in campo, quella che ci serve per poter garantire che il nostro progetto svolga tutti i compiti assegnati nella migliore delle ipotesi e delle condizioni operative. Se scegliamo un microcontrollore, possiamo cominciare a studiare la famiglia Arduino, sapendo che, oltre ai componenti ufficiali di questa scheda, esistono un esercito di cloni, una serie di varianti, e che comunque possiamo sempre prototipare la nostra soluzione. L'idea di partire con Arduino semplifica moltissimo i passi della prototipazione soprattutto per chi non ha grande esperienza. Se, invece, noi abbiamo bisogno di gestire anche un database associato all'esecuzione del nostro software oppure preparare un web server locale per poter esporre dei servizi online, molto probabilmente abbiamo bisogno anche di un sistema operativo. In questo caso la scelta dovrà ricadere su una famiglia di schede che si basano su microprocessori, delle quali gli esponenti più di punta nell'ambito della prototipazione rapida sono certamente afferenti alla famiglia Raspberry Pi. Dal momento che il nostro sistema deve poter fornire anche consigli all'utente, è indispensabile superare il concetto del semplice microcontrollore e puntare direttamente con decisione ad una scheda che integri un microprocessore, che abbia una certa quantità di RAM ed una memoria all'interno della quale alloggiare tutti i dati misurati. Raspberry Pi risulta essere la scelta migliore. Proviamo, allora, a guardare il mercato e vediamo quali versioni esistono. La prima, naturalmente, che ci viene in mente è la versione 3. Semplice, potente, compatta ed assolutamente funzionale. Possiamo utilizzarla per connettere componenti alimentati a 3.3 V e abbiamo a disposizione un header pin da 40 elementi che possono essere utilizzati per interfacciare circuiti digitali. Questa però è una cosa della quale dovremmo sicuramente tenere conto: Raspberry non consente l'interfacciamento analogico, ammesso che non si preveda introdurre anche un convertitore analogico-digitale aggiuntivo. Abbiamo scelto [...]

ATTENZIONE: quello che hai appena letto è solo un estratto, l'Articolo Tecnico completo è composto da ben 2648 parole ed è riservato agli ABBONATI. Con l'Abbonamento avrai anche accesso a tutti gli altri Articoli Tecnici che potrai leggere in formato PDF per un anno. ABBONATI ORA, è semplice e sicuro.

Ti potrebbe interessare anche:

Progetto di una interfaccia robotica Arduino-ROS – Parte 1

Sensori industriali: caratterizzazione, principi di funzionamento e applicazioni

Le piattaforme SDR per applicazioni di test e misura

IPC Standard per la progettazione dei PCB

I benefici dei moduli di potenza e le proposte di Renesas Electronics

La rivoluzione delle reti LoRaWAN nelle applicazioni IoT Industriali (IIoT)