Archivi categoria: corsi

Esercitazione 2 – Tastiera 4×4 non bloccante con codice di accesso e feedback di errore

Allenamento per l’esame di maturità
Percorso di laboratorio con Arduino per studenti di quinta ITIS

Obiettivo didattico

Scansionare una tastiera 4×4 senza usare una libreria esterna, acquisire una sequenza di tasti, confrontarla con un codice corretto e fornire un feedback di esito positivo o errore. L’attività allena gestione di matrici di pin, scansione righe/colonne, buffer di input e logica non bloccante.

Materiali suggeriti

  • Arduino UNO R3 o UNO R4;
  • tastiera 4×4;
  • LED verde;
  • LED rosso,
  • buzzer opzionale;
  • 2 resitori da 220 Ohm (per i LED);
  • breadboard;
  • cavetti jumper.

Schema di collegamento

Richiamo teorico

Una tastiera a matrice riduce il numero di fili usando righe e colonne. Il microcontrollore attiva una riga alla volta e legge le colonne. Se una colonna va a livello attivo, il tasto corrispondente a quella riga e colonna è premuto. Anche qui bisogna evitare il rimbalzo e gestire l’ingresso come sequenza di eventi.

Schema logico dell’attività

Il programma scansiona una riga alla volta. Quando rileva un tasto stabile, lo aggiunge al buffer. Se viene premuto # confronta il buffer con il codice atteso. Se il codice è corretto accende il LED verde. Se è errato accende il LED rosso, svuota il buffer e ricomincia.

Diagramma di flusso

Diagramma di flusso Mermaid

flowchart TD
    A[Inizio] --> B[Configura righe, colonne e LED]
    B --> C[Scansione tastiera]
    C --> D{Tasto valido trovato?}
    D -- No --> C
    D -- Sì --> E{Tasto uguale a # ?}
    E -- No --> F[Aggiungi carattere al buffer]
    F --> C
    E -- Sì --> G[Confronta buffer con codice]
    G --> H{Codice corretto?}
    H -- Sì --> I[Feedback verde e reset buffer]
    H -- No --> J[Feedback rosso e reset buffer]
    I --> C
    J --> C

Programma

/*
  Prof. Maffucci Michele
  Esercizio 2: Tastiera 4x4 non bloccante con codice di accesso e feedback di errore
*/

// ---------------------------
// Pin delle 4 righe
// ---------------------------
const int righe[4] = { 2, 3, 4, 5 };

// ---------------------------
// Pin delle 4 colonne
// ---------------------------
const int colonne[4] = { 6, 7, 8, 9 };

// ---------------------------
// Mappa dei tasti
// ---------------------------
char mappaTasti[4][4] = {
  { '1', '2', '3', 'A' },
  { '4', '5', '6', 'B' },
  { '7', '8', '9', 'C' },
  { '*', '0', '#', 'D' }
};

// ---------------------------
// LED di feedback
// ---------------------------
const int PIN_LED_VERDE = 10;
const int PIN_LED_ROSSO = 11;

// ---------------------------
// Codice corretto da inserire
// ---------------------------
char codiceCorretto[] = "2580";

// ---------------------------
// Buffer di ingresso utente
// ---------------------------
char bufferInput[8];
int indiceInput = 0;

// ---------------------------
// Variabili per antirimbalzo
// ---------------------------
char ultimoTastoLetto = '\0';
char ultimoTastoConfermato = '\0';
unsigned long istanteCambio = 0;
const unsigned long TEMPO_DEBOUNCE = 40;

void setup() {
  // Le righe vengono pilotate in uscita.
  for (int i = 0; i < 4; i = i + 1) {
    pinMode(righe[i], OUTPUT);
    digitalWrite(righe[i], HIGH);
  }

  // Le colonne sono ingressi con pull-up.
  for (int i = 0; i < 4; i = i + 1) {
    pinMode(colonne[i], INPUT_PULLUP);
  }

  pinMode(PIN_LED_VERDE, OUTPUT);
  pinMode(PIN_LED_ROSSO, OUTPUT);

  Serial.begin(9600);
  svuotaBuffer();
}

void loop() {
  // Leggo il tasto corrente tramite scansione.
  char tastoCorrente = leggiTastiera();

  // Se è cambiato il valore grezzo, aggiorno il tempo.
  if (tastoCorrente != ultimoTastoLetto) {
    ultimoTastoLetto = tastoCorrente;
    istanteCambio = millis();
  }

  // Se il valore è stabile da abbastanza tempo, lo confermo.
  if ((millis() - istanteCambio) >= TEMPO_DEBOUNCE) {
    if (tastoCorrente != ultimoTastoConfermato) {
      ultimoTastoConfermato = tastoCorrente;

      // Elaboro il tasto solo quando è reale e non nullo.
      if (ultimoTastoConfermato != '\0') {
        gestisciTasto(ultimoTastoConfermato);
      }
    }
  }
}

// ----------------------------------------------------------
// Scansione manuale della tastiera.
// Attivo una riga alla volta e leggo tutte le colonne.
// ----------------------------------------------------------
char leggiTastiera() {
  for (int r = 0; r < 4; r = r + 1) {

    // Prima porto tutte le righe alte.
    for (int i = 0; i < 4; i = i + 1) {
      digitalWrite(righe[i], HIGH);
    }

    // Poi attivo solo la riga corrente.
    digitalWrite(righe[r], LOW);

    // Leggo tutte le colonne.
    for (int c = 0; c < 4; c = c + 1) {
      if (digitalRead(colonne[c]) == LOW) {
        return mappaTasti[r][c];
      }
    }
  }

  // Se non trovo alcun tasto, restituisco nullo.
  return '\0';
}

// ----------------------------------------------------------
// Gestione del carattere ricevuto.
// * cancella, # conferma, altri tasti vengono memorizzati.
// ----------------------------------------------------------
void gestisciTasto(char tasto) {
  Serial.print("Tasto ricevuto: ");
  Serial.println(tasto);

  if (tasto == '*') {
    svuotaBuffer();
    Serial.println("Buffer cancellato");
  } else if (tasto == '#') {
    verificaCodice();
  } else {
    if (indiceInput < 7) {
      bufferInput[indiceInput] = tasto;
      indiceInput = indiceInput + 1;
      bufferInput[indiceInput] = '\0';
    }
  }
}

// ----------------------------------------------------------
// Confronto del buffer con il codice corretto.
// ----------------------------------------------------------
void verificaCodice() {
  bool corretto = true;

  for (int i = 0; codiceCorretto[i] != '\0'; i = i + 1) {
    if (bufferInput[i] != codiceCorretto[i]) {
      corretto = false;
    }
  }

  // Verifico anche la lunghezza.
  if (indiceInput != 4) {
    corretto = false;
  }

  if (corretto == true) {
    Serial.println("CODICE CORRETTO");
    digitalWrite(PIN_LED_VERDE, HIGH);
    delay(500);
    digitalWrite(PIN_LED_VERDE, LOW);
  } else {
    Serial.println("CODICE ERRATO");
    digitalWrite(PIN_LED_ROSSO, HIGH);
    delay(500);
    digitalWrite(PIN_LED_ROSSO, LOW);
  }

  svuotaBuffer();
}

// ----------------------------------------------------------
// Ripulisce il buffer e rimette l'indice a zero.
// ----------------------------------------------------------
void svuotaBuffer() {
  for (int i = 0; i < 8; i = i + 1) {
    bufferInput[i] = '\0';
  }
  indiceInput = 0;
}

Continua a leggere

Allenamento alla maturità con Arduino

Esercitazioni progressive di laboratorio per studenti di quinta ITIS e professionale

Nota importante: questa pagina è in continuo aggiornamento. I link alle diverse esercitazioni saranno aggiunti progressivamente nell’indice, man mano che i contenuti verranno pubblicati.

La preparazione alla seconda prova dell’Esame di Stato passa anche attraverso l’attività pratica in laboratorio in modo che l’azione possa essere utile per focalizzare lo studio teorico e lo svolgimento delle tracce degli anni precedenti.

Per affrontare bene la maturità serve allenamento operativo, metodo e continuità.
Per questo motivo ho deciso di proporre una serie di esercitazioni pratiche con Arduino, pensate per studenti del quinto anno dell’ITIS – Elettronica e Automazione, utilizzabili sia a scuola in laboratorio con il supporto dei docenti sia a casa in autonomia come attività di ripasso e consolidamento.

Sono in realtà attività pratiche che possono essere svolte in circa 90 minuti di lavoro e che prendono in considerazione argomenti del triennio dell’ITIS che ritengo possano servire per lo svolgimento di problemi che potrebbero essere presenti nel tema d’esame di TPSEE.

Quindi questa raccolta nasce con un obiettivo molto preciso:

aiutare gli studenti a prendere confidenza con quelle strutture di programmazione che, molto spesso, risultano più difficili da capire e da usare in modo corretto, ad esempio:

  • temporizzazioni non bloccanti con millis()
  • multitasking cooperativo
  • array e matrici
  • interrupt
  • puntatori
  • macchine a stati
  • gestione ordinata degli eventi

Due percorsi distinti ma complementari

All’interno del lavoro di preparazione alla maturità sto sviluppando due percorsi paralleli.

Il primo è questa serie di esercitazioni trasversali di programmazione, focalizzate sulle strutture software più importanti e spesso più ostiche.

Il secondo, invece, è già in corso con un mia classe e nel breve pubblicherò le attività di laboratorio, si tratta di una reinterpretazione per il laboratorio di Sistemi elettronici e TPSEE della prova di maturità della sessione ordinaria 2018 di TPSEE, che richiede di affrontare un processo articolato con preallarme, attuatori ON/OFF, acquisizione di sensori, scelta dell’intervallo di campionamento, progettazione delle interfacce e descrizione dell’algoritmo di gestione.

Partiamo però dalle 20 attività.

Come sono costruite le esercitazioni

La struttura delle schede di lavoro rispecchia quelle che in genere consegno ai miei studenti.

Ogni attività sarà presentata con una struttura costante, così da aiutare anche gli studenti che hanno competenze di programmazione ancora deboli.

In ogni post troverete:

  • richiamo teorico iniziale delle istruzioni usate
  • analisi semplificata del problema
  • materiali necessari
  • schema logico di funzionamento
  • diagramma di flusso
  • codice Arduino completo e commentato nel dettaglio
  • spiegazione guidata del programma
  • errori tipici
  • possibili estensioni

Attività 0: prima di programmare, capire bene il testo

Prima ancora di partire con la costruzione del circuito e la programmazione iniziamo con l’Attività 0: la comprensione del testo tecnico, è un problema che si riscontra sempre, soprattutto nella comprensione del testo dell’esame di maturità.

Molto spesso gli studenti si bloccano non perché non sanno programmare, ma perché il testo della prova appare lungo, denso e complesso.
Per questo motivo, prima di scrivere codice, è fondamentale allenarsi a:

  • riconoscere ingressi, uscite, sensori e attuatori
  • distinguere dati misurati e condizioni logiche
  • individuare la sequenza del processo
  • separare la parte hardware dalla parte software
  • … e non ultimo progettare in modo ordinato

Pubblicazione delle soluzioni

Le attività saranno pubblicate progressivamente e in ogni attività lo studente troverà un esercizio aggiuntivo di complessità leggermente superiore rispetto a quello proposto.

Ogni esercizio sarà corredato da diagramma di flusso e codice Mermaid per replicare il diagramma di flusso.

Per favorire il ragionamento autonomo, la soluzione completa verrà resa disponibile dopo qualche giorno dalla pubblicazione dell’esercizio, così da lasciare agli studenti il tempo di provare davvero.

Nota importante

Questa serie di attività è attualmente in costruzione. Nel momento stesso in cui pubblico questo post sto ancora sviluppando e affinando le singole esercitazioni; per questo vi chiedo un po’ di pazienza e comprensione se dovessero essere presenti alcune imprecisioni o aspetti da migliorare. Ogni segnalazione, osservazione o suggerimento sarà quindi molto utile per rendere le schede di lavoro più chiare, efficaci e funzionali.

Naturalmente, quanto propongo non ha la pretesa di esaurire tutti i contenuti necessari per affrontare l’Esame di Stato. Si tratta di una mia selezione di attività, costruita a partire dagli argomenti ricorrenti nelle prove degli anni passati e pensata soprattutto per studenti con competenze di livello medio-base. Per questo motivo le esercitazioni possono essere integrate, adattate o modificate in base alle esigenze della classe, al livello di preparazione degli studenti e alle scelte didattiche del docente.

Di seguito trovate l’indice della serie, che al momento può essere considerato una versione beta, anche se con ogni probabilità resterà molto vicino alla struttura definitiva.
Questa pagina verrà aggiornata progressivamente, aggiungendo di volta in volta i link diretti alle singole esercitazioni.

Indice delle esercitazioni che verranno pubblicate

  • Esercitazione 1 – Pulsante singolo con antirimbalzo, doppio clic, pressione lunga e timeout
  • Esercitazione 2 – Tastiera 4×4 non bloccante con codice di accesso e feedback di errore
  • Esercitazione 3 – Scheduler cooperativo con tre task e supervisione dei tempi
  • Esercitazione 4 – Macchina a stati per un ciclo automatico con START, pausa, allarme e reset
  • Esercitazione 5 – Acquisizione analogica calibrata, filtrata e convertita in grandezza fisica
  • Esercitazione 6 – Controllo a finestra con isteresi, allarme latched e reset
  • Esercitazione 7 – Confronto tra filtro a media mobile e filtro esponenziale
  • Esercitazione 8 – Campionamento temporizzato con array di struct: tempo, valore e stato
  • Esercitazione 9 – Analisi statistica di una sequenza con rilevamento anomalie
  • Esercitazione 10 – Buffer circolare con trend, velocità di variazione e soglia dinamica
  • Esercitazione 11 – Matrice bidimensionale per organizzare campioni di più sensori nel tempo
  • Esercitazione 12 – Frame buffer per matrice LED: icone, animazioni e scorrimento testo
  • Esercitazione 13 – Conteggio impulsi con interrupt e validazione evento
  • Esercitazione 14 – Misura di periodo, frequenza, duty cycle e tempo alto di un segnale PWM
  • Esercitazione 15 – Encoder rotativo con menù parametrico semplificato
  • Esercitazione 16 – Funzioni con parametri passati per indirizzo e restituzione di più risultati
  • Esercitazione 17 – Ordinamento di misure e scambio di valori tramite puntatori
  • Esercitazione 18 – Macchina a stati per un menù su display LCD
  • Esercitazione 19 – Parser di comandi seriali con parametri e risposta strutturata
  • Esercitazione 20 – Mini progetto finale: stazione di monitoraggio completa

Quale sarà la periodicità delle attività? Probabilmente giornaliera, da domani o lunedì prossimo.

Siete pronti per ripassare? 🙂

Domande dagli utenti: “puoi chiarire il concetto di negativo in comune?”

Continuo con la serie delle domande che mi sono giunte sul gruppo Facebook BBC micro:bit Italy, questa volta dall’amico: Davide

ciao Michele Maffucci, uno degli altri “problemi” che ho notato che non capiscono, quando alimenti separatamente, il “negativo in comune”
Magari un giorno affronta l’argomento 🙂

Quando si alimenta separatamente (micro:bit o Arduino da una fonte e motori/driver da un’altra), molti si bloccano sul concetto di “negativo in comune”. Un modo semplice per capirlo è l’esempio dell’ascensore che spesso faccio durante le mie lezioni.

Immagina due persone che vogliono incontrarsi in un edificio:

  • la prima usa come riferimento il piano terra e dice: “sono al 2° piano”;
  • la seconda, però, considera “piano terra” il 1° piano (ha spostato lo zero): anche lei dice “sono al 2° piano”, ma in realtà si trova su un livello diverso.

Risultato: usano numeri uguali, ma riferiti a zeri diversi, quindi non riescono a coordinarsi e incontrarsi.

In elettronica succede la stessa cosa: un segnale “alto” (ad esempio 3,3 V) significa 3,3 V rispetto a un riferimento, cioè rispetto alla massa (GND). Se micro:bit e driver/servo non condividono la stessa massa, quel “3,3 V” può non essere interpretato correttamente perché lo “zero” dell’uno non coincide con lo “zero” dell’altro.

Nota importante: massa e terra non sono la stessa cosa (anche se a volte coincidono)

  • Massa / GND (0 V di riferimento): è il potenziale comune di riferimento del circuito, spesso chiamato anche 0 V. È il “piano terra” della nostra analogia: lo zero rispetto a cui misuriamo e capiamo i segnali.
  • Terra / PE (Protective Earth – protezione): è il collegamento all’impianto di terra, usato soprattutto per sicurezza elettrica (scariche, guasti, schermature).

In molti dispositivi alimentati da rete, la massa del circuito può essere collegata alla terra, e in quel caso massa e terra finiscono per trovarsi allo stesso potenziale e spesso si parla di “0 V”.

In sistemi a batteria (micro:bit, driver, servo, pacchi AA/AAA) come ad esempio i nostri robot didattici, non esiste una “terra” fisica collegata all’impianto: esiste solo la massa come riferimento comune.

Quindi, quando diciamo “mettere il negativo in comune”, intendiamo:

“Rendere comune il riferimento (GND) tra i dispositivi che devono scambiarsi segnali.”

in altro modo:

GND micro:bit < - > GND driver/servo < - > GND batteria motori

In breve: potete tenere alimentazioni separate, ma dovete rendere comune il riferimento (GND), altrimenti i segnali non hanno un “piano zero” condiviso e il controllo diventa instabile.

Schema pratico

GND micro:bit ─────────┐
GND driver/motor board ├──> punto massa comune
GND batteria motori ───┘

Il concetto è: micro:bit invia il segnale, il driver lo interpreta, ma entrambi devono riferirsi allo stesso “0 V”.

Schema di collegamento – casi tipici

A. micro:bit + driver motori DC (ponte H / Motor driver)

  • Batteria motori + (positivo) > Vmot / +VIN driver
  • Batteria motori (negativo) > GND driver
  • micro:bit pin (PWM/direzione) > IN1/IN2/ENA… (driver)
  • micro:bit GND > GND driver (fondamentale)

IMPORTANTE: non serve collegare i “positivi” tra loro; serve collegare i GND.

B. micro:bit + servo (alimentazione servo separata)

  • Batteria servo + (positivo) > V+ servo
  • Batteria servo (negativo) > GND servo
  • micro:bit pin segnale > SIG servo
  • micro:bit GND > GND servo

Senza GND in comune il servo può tremare, non rispondere o muoversi in modo erratico.

C. micro:bit alimentata e motori sullo stesso pacco batterie (solo se il pacco è adeguato)

  • Stesso pacco batterie > micro:bit (tramite regolazione corretta) + driver;
  • GND è già comune per costruzione;
  • è pratico, ma attenzione ai disturbi: spesso conviene comunque separare la potenza motori.

Accorgimenti costruttivi utili

  • collegare “a stella” le masse, ovvero un punto comune su cui colleghiamo tutte le masse vicino al driver/alimentazione motori, evitare se possibile collegamenti di masse in cascata;
  • mantenere i cavi motore e quelli di segnale separati quando possibile;
  • aggiungere condensatori di disaccoppiamento vicino al driver/servi (se il kit non li integra già).

Per approfondimenti consiglio la lettura del post: Sensori e attuatori lontani da Arduino: guida pratica al cablaggio corretto i consigli che vengono forniti possono essere adottati anche per la costruzione dei nostri robot didattici.

Questi concetti verranno approfonditi in modo pratico durante il mio prossimo corso di robotica.

Buon Making a tutti.

Domande dagli utenti: perché micro:bit non pilota i motori direttamente?


Nella giornata di ieri mi è arrivata una domanda molto sensata, una di quelle che prima o poi ci si pone tutti quando si prova a far muovere un robot con micro:bit o con Arduino.

“Se micro:bit riuscisse a passare da 3V a 5V si risparmierebbero i costi della scheda di espansione, nonché l’ottimizzazione degli spazi. Lei è d’accordo? Chissà perché non lo fanno: ormai tutti abbiamo bisogno di motorini.”

La risposta breve è questa:

Capisco il ragionamento, ma il vero ostacolo non è 3 V vs 5 V. Il punto è che un pin di micro:bit non è uno stadio di potenza.
Anche se la scheda fosse “a 5 V”, non potresti comunque collegare un motore direttamente ai pin in modo sicuro e affidabile.

Vediamo perché, con esempi concreti e riferimenti ai due kit che uso spesso nei corsi: Ring:bit V2 board e Kitronik :MOVE mini.

La spiegazione che segue è volutamente semplificata in quanto non necessariamente i colleghi che seguono i miei corsi sono docenti di materie di indirizzo tecnico.

Perché “alzare la tensione” non risolve il problema

Corrente: il motore chiede molta più energia di quella che un pin può dare

Un motore (anche piccolo) non “vuole solo tensione”: vuole soprattutto corrente, e ne vuole parecchia quando parte (corrente di spunto) e quando è sotto sforzo (ruote che spingono, attrito, urti).

Un pin GPIO di una scheda a microcontrollore è progettato per segnali e piccoli carichi, non per alimentare carichi elettromeccanici. Se provate a farlo, i sintomi tipici sono:

  • reset improvvisi della scheda,
  • comportamenti instabili,
  • surriscaldamento,
  • nel peggiore dei casi danni ai pin o al microcontrollore.

Disturbi e picchi: il motore “sporca” l’alimentazione e genera back-EMF

Il motore è un carico induttivo: quando viene acceso/spento o se ne cambia la velocità, può generare picchi di tensione (back-EMF) e disturbi elettrici che:

  • mandano in crisi la logica,
  • creano interferenze (anche sulla radio/BT),
  • degradano l’affidabilità nel tempo.

Serve un driver: lo “stadio di potenza” che separa logica e motore.

Per pilotare un motore DC, ad esempio quelli gialli che tipicamente vengono usati nei progetti didattici di robotica, serve uno stadio di potenza, cioè un driver motore, per esempio:

  • ponte H (per andare avanti/indietro e fare PWM in modo robusto),
  • oppure MOSFET + protezioni (se serve solo on/off o un verso).

Il driver fa tre cose fondamentali:

  • regge la corrente (anche i picchi),
  • gestisce la direzione e la velocità (PWM),
  • protegge micro:bit dai disturbi e dai picchi del motore.

Citando la richiesta dell’utente: “Ma allora perché micro:bit non è a 5V?”

In realtà molte schede “vivono” già in ambienti dove esistono 5 V (ad esempio USB), ma l’elettronica interna e i pin di I/O lavorano a bassa tensione (tipicamente 3,3 V) perché:

  • si riducono consumi e riscaldamento,
  • si protegge meglio la scheda,
  • si mantiene compatibilità con sensori moderni a bassa tensione,
  • e soprattutto (punto chiave): anche a 5 V i pin non diventerebbero “pilotamotori”.

Quindi: passare a 5 V non eliminerebbe la necessità di un driver. Cambierebbe solo alcuni dettagli di alimentazione/compatibilità, ma non la sostanza.

Il caso reale nei kit: Ring:bit V2 board e Kitronik :MOVE mini

Ring:bit V2 board: non è “la scheda che pilota motori”

La Ring:bit V2 board è principalmente una scheda di espansione/breakout:

  • rende più comodi alcuni collegamenti (ad esempio porte tipo GVS su P0/P1/P2),
  • integra un portabatterie (3×AAA) per alimentare il sistema/il robot,
  • fornisce un’interfaccia pratica per prototipare.

Va interpretata come interfaccia e distribuzione di alimentazione/connessioni, non come “micro:bit che pilota motori direttamente”.

Ring:bit V2

Kitronik :MOVE mini: usa servomotori, non motori DC senza elettronica di controllo integrata

La scheda Kitronik :MOVE mini può controllare due servomotori a rotazione continua. Questa scelta è utile per la didattica, perché un servo:

  • contiene già la propria elettronica di pilotaggio,
  • si controlla con un semplice segnale PWM (impulsi “stile servo”),
  • prende l’energia dal pacco batterie/board del kit, non dai pin di micro:bit.

In pratica:

  • micro:bit invia il comando (PWM),
  • il servo esegue, usando la sua alimentazione dedicata.

Questo è il motivo per cui, con :MOVE mini, si riesce ad avere un robot “semplice” e robusto senza introdurre subito il tema dei ponti H per motori DC.

:MOVE mini

Cosa vedremo nel corso: motori DC “veri” e driver dedicati

Durante il corso mostrerò anche l’altro scenario, quello tipico quando si usano i classici motori gialli da 6 V (motori DC con riduttore), dove il driver è obbligatorio.

motore TT

Lavoreremo in particolare con:

  • L298N (ottimo per capire il concetto di ponte H e cablaggi, anche se non è la soluzione più efficiente in assoluto),
  • Motor:bit di ELECFREAKS (più compatta e didattica, comoda per micro:bit).

Obiettivo: far capire chiaramente la differenza tra:

  • “motore DC” (serve driver + alimentazione adeguata),
  • “servo” (driver interno, controllo PWM più diretto).

Regola utile sempre: alimentazione separata e masse in comune

Quando si entra nel mondo motori/attuatori, una buona pratica è:

  • alimentare i motori/servi con una linea robusta (batterie/pack dedicato),
  • e mantenere massa (GND) in comune tra microcontrollore e driver/attuatori (quando richiesto), così i segnali di controllo hanno un riferimento corretto.

Questa singola regola elimina moltissimi “misteri” (reset, comportamenti casuali, servo che impazziscono).

Qualche precisazione in più sui motori DC o motori senza elettronica di controllo integrata

Troverete spesso la dicitura motori bare DC motor in pratica sono motori che hanno solo due terminali (o due fili):

  • fornite tensione > girano
  • togliete tensione > si fermano
  • invertite la polarità > invertono il verso di rotazione (se lo permettete elettricamente)

In ambito tecnico anglofono è abbastanza comune parlare di “bare DC motor” per indicare un motore senza elettronica di controllo integrata (cioè “il solo motore”, tipicamente a due fili) e spesso anche senza riduttore/struttura accessoria.

Esempi tipici:

  • i classici motori gialli TT 3–6 V usati nei robot economici
  • motorini DC “a spazzole” da modellismo o recuperati da giocattoli

I bare DC motor non hanno al loro interno:

  • driver di potenza
  • protezioni contro i picchi (back-EMF)
  • logica per interpretare un segnale di controllo

Quindi, per farli funzionare con micro:bit, serve aggiungere elettronica esterna:

  • un ponte H (es. L298N, TB6612, DRV8833) se vuoi avanti/indietro + PWM
  • oppure un MOSFET + diodo se ti basta on/off (e magari un solo verso)

L298N

TB6612

DRV8833

Differenza con un servo (o un motoriduttore “intelligente”)

Un servomotore (anche a rotazione continua) invece non è senza elettronica di controllo perché contiene già:

  • elettronica di pilotaggio
  • circuito di potenza
  • logica che interpreta il comando (impulsi PWM stile servo)

Per questo il micro:bit può “comandare” un servo con un semplice segnale, mentre con un motore DC senza elettronica di controllo deve essere gestito da un driver.

Buon Making a tutti 🙂

Dietro le quinte del corso “Robotica educativa a basso costo”: da DotBot:bit a Codino

In questi giorni sto lavorando alla preparazione della 6ª edizione del corso di robotica a basso costo ed ho rimesso mano a uno dei “classici” del mio laboratorio: DotBot:bit. Chi segue il sito da tempo lo conosce: nasceva come robottino essenziale per portare in classe micro:bit con un approccio pratico, replicabile e sostenibile.

Perché ripartire da DotBot:bit e perché aggiornarlo

DotBot:bit era nato con un obiettivo molto chiaro: fare robotica con materiali semplici, valorizzando la didattica laboratoriale e la possibilità di iterare rapidamente tra:

idea > prototipo > test > miglioramento.

Oggi lo scenario in classe è ancora più vario: c’è chi lavora con schede e moduli differenti, chi ha la stampa 3D, chi invece preferisce (o deve) restare sul cartone e su soluzioni ultra-economiche. Per questo ho progettato un’evoluzione concreta e “da corso”.

Nasce Codino: una struttura, due piattaforme

La novità si chiama Codino: una struttura aggiornata (derivata da DotBot:bit) pensata per ospitare in alternativa due setup molto diffusi in ambito micro:bit:

  • Ring:bit V2
  • Kitronik :MOVE mini

entrambe le schede hanno form factor compatto.

L’idea è semplice ma didatticamente potente: stessa “scocca” di progetto, due piattaforme, così il corso (e le attività in classe) si adattano ai vincoli reali: disponibilità di materiali, budget, tempi, livello della classe.

Cosa sto preparando per il corso

Durante la preparazione sto lavorando su tre fronti, tutti pensati per diventare attività trasferibili in classe:

  • Adattamento meccanico e modularità
    Montaggi rapidi, sostituzione della scheda senza rifare tutto da capo, riduzione delle parti “critiche” mi riferisco a quelle che si rompono o richiedono manutenzione.
  • Percorsi di prova “a difficoltà crescente”
    Dal primo movimento controllato fino a micro-sfide: traiettorie, correzioni, test su attrito e peso, ragionamento su stabilità e distribuzione delle masse.
  • Codino è pensato per arrivare senza frizioni alle attività che introdurrò in questa edizione più lunga:
    • controllo con gesture recognition via webcam (ML addestrato su gesti)
    • mini-progetti di Sumo
    • primi prototipi di braccio robot (meccanica essenziale + attuazione)
    • Robot semplici realizzati con Arduino

Tutti questi sono i contenuti extra resi possibili dall’estensione a 4 lezioni della 6ª edizione.

Stampa 3D o cartone: stesso progetto, due strade

Come nel DNA di DotBot:bit, anche Codino resta coerente con l’impostazione “basso costo”:

  • per chi ha una stampante 3D: struttura stampabile e facilmente iterabile;
  • per chi non ce l’ha: template e sagome in cartone, per costruire comunque un robot completo e funzionante.

Questo approccio “doppio” è ciò che rende il kit davvero spendibile: non è un modello unico, è un format replicabile.

Se volete seguire l’evoluzione e portarla in classe

Se vi interessa vedere Codino in azione e, soprattutto, costruire un percorso completo da replicare con i tuoi studenti, la 6ª edizione del corso “Creare un kit di robotica educativa a basso costo” parte il 16 gennaio 2026 e prosegue fino al 3 febbraio 2026 (4 incontri).

Nei prossimi giorni pubblicherò anche qualche foto “work in progress” della struttura Codino ed altri robot.

Buon Making a tutti 🙂