Nella primavera del 2021 insieme ai miei figli abbiamo iniziato il progetto di un nostro robot, piccolo, semplice ma con tutto il necessario per impare cose nuove: GiammaBOT!
Complice una lunghissima quarantena, ho avuto finalmente la possibilità di iniziare a provare la main board che avevamo montato in autunno, grazie al prezioso supporto di AM Microsystems, l'azienda dove lavoro. Nella seguente immagine potete vedere il risultato finale, non le dona tantissimo il giallo?!

Hardware

Effettuato il montaggio della scheda, le prime operazioni da fare prima di programmare il microcontrollore è controllare che non ci siano corto circuiti e che tutte le tensioni necessarie a far funzionare la scheda siano presenti. In questo primo prototipo la fortuna ci ha assistito: nessun corto circuito!
Per quanto riguarda le tensioni, i punti da controllare sulla scheda sono diversi. Innanzitutto, collegato il cavo USB, deve essere presente la +VUSB sia in ingresso al circuito integrato che gestisce di ricarica (U103, pin 6), sia all'ingresso dell'interruttore SW101; una volta chiuso l'interruttore, la stessa tensione deve essere presente all'ingresso del DC-DC (BRD102, pin 3). Agendo sul trimmer presente sulla breakout del DC-DC, la tensione di uscita misurabile al pin 5 varia: il trimmer va girato fino ad ottenere circa 7.5V, tensione che verrà utilizzata sia per creare le altre tensioni, sia per pilotare i motori.
A questo punto è possibile collegare la scheda di sviluppo NUCLEO-L476RG che contiene il microcontrollore e che si occuperà di generare i 5V ed i 3.3V necessari al funzionamento della logica. Ultimato il controllo di queste due tensioni è possibile passare alla programmazione del microcontrollore.

Durante lo sviluppo del firmware, di cui parleremo nella prossima sezione, mi sono accorto di aver fatto un grosso errore di collegamento: due dei pin utilizzati per gestire i LED RGB di destra sono i pin utilizzati dal JTAG per la programmazione del microcontrollore. Il problema non è grave, nel senso che il firmware funziona lo stesso, ma il fatto che non sarebbe posibile far fare debug ai ragazzi mi ha convinto a spostare i due collegamenti su altri pin (come si può vedere dalla foto)!

Firmware

Per poter testare la main board è necessario iniziare a scrivere un po' di firmware. Questa prima fase, dal mio punto di vista, va sempre fatta con molta cura: prevede l'organizzazione della struttura del progetto, la scelta delle librerie da utilizzare, il linguaggio da usare. In questa fase ho preferito non far partecipare in modo attivo i ragazzi, in modo tale da avere il tempo, il modo, e la lucidità mentale per pensare al progetto in maniera tale da rendere il loro successivo approccio non eccessivamente difficoltoso.
Bene, iniziamo!

Come ho ribadito più volte, l'obiettivo di questo progetto, oltre a divertirsi, è far imparare qualcosa di nuovo sul mondo dell'elettronica (ma anche dell'informatica e della meccanica) ai miei figli. Per far ciò, ho pensato di strutturare il firmware in modo tale che lo potessero utilizzare al pari (più o meno) di come utilizzano Arduino. Sulla base di questa condizione, i vincoli che mi sono dato sono:

• utilizzare il C++ in modo tale da creare una classe per ogni dispositivo presente sulla scheda;
• offrire come unica interfaccia le funzioni setup() e loop(), come negli sketch di Arduino.

L'ultimo vincolo che mi sono imposto, ma che prescinde dai due precedenti, è l'utilizzo della libohiboard, la libreria cross-microcontrollore che sto sviluppando insieme ad OHILab da circa dieci anni.

Per adempiere al primo vincolo, ho deciso di creare le seguenti classi C++:

• PWMChannel una classe creata per astrarre la gestione di un singolo canale PWM di un timer del microcontrollore. Istanze di questa classe verranno utilizzate per la gestione del driver motore.
• DRV8833 classe utile alla gestione del driver motore, il quale con un unico dispositivo riesce a gestire indipendentemente due motori DC. I motori possono avere velocità e direzioni diverse!
• TurnLight una classe ideata per gestire i quattro LED RGB posti ai quattro angoli del PCB e che hanno la funzione di simulare i dispositivi luminosi delle auto. Insieme ad Alessandro e Riccardo, abbiamo codificato le seguenti possibilità:
  • hazards i quattro LED si accendono contemporaneamente nella sequenza rosso, verde, blu; questo tipo di segnalazione verrà usata nel caso il robot si trovi in uno stato di allarme o malfunzionamento;
  • left i due LED di sinistra si accendono nella sequenza rosso, verde e blu, quando il robot deve girare a sinistra;
  • right come per il precedente stato, i due LED di destra si accendono nella sequenza rosso, verde e blu, quando il robot deve girare a destra;
  • forward in questo stato tutti i LED si accendo in modo tale da avere una luce bianca, la quale indica che il robot si sta muovendo in avanti;
  • backward in questo stato solo i LED rossi si accendo con l'obiettivo di indicare che il robot si sta muovendo in indietro.
• Robot è l'ultima delle classi create in questa prima fase. La classe si occupa di astrarre il comportamento generale del robot, integrando il comportamento dei motori e delle luci di segnalazione.

Ogni classe ha inoltre a disposizione dei comandi di debug utilizzabili tramite una porta seriale (la USB-C utilizzata anche per ricaricare la batteria). Questi comandi vengono gestiti tramite la libreria WC&DLI - Warcomeb Command & Debug Line Interface. La documentazione di ogni classe è ancora carente, ma spero di completarla a breve.
Tutto il firmware sviluppato fino ad ora è funzionante e testato e può essere visionato o scaricato al seguente link.

What's next?

Ed ecco una foto di GiammaBOT asssemblato:

I prossimi passi prevedono sicuramente l'iterazione dei ragazzi, sia per lo sviluppo di nuovo firmware, sia per la progettazione e costruzione di nuove funzionalità meccaniche: la lista dei TODO prevede già un line-follower ed una pala sollevatrice!

Articoli correlati

• GiammaBOT: il nostro primo robot
• La main-board di GiammaBOT