Archivi tag: steam

Arduino esercizi – Base marziana ELYSIUM

Quest’anno sto supportando, con attività di sperimentazione pratica, anche classi non mie, proponendo laboratori motivanti per riaccendere curiosità e partecipazione. La prossima settimana lavorerò con una terza elettronica numerosa ed eterogenea, non semplice da gestire nei laboratori tradizionali. Per questo, insieme ai colleghi, abbiamo scelto di spostare la lezione nel Laboratorio Territoriale (LTO), uno spazio ricco di attrezzature “inusuali” per un normale laboratorio scolastico: il contesto giusto per stuzzicare l’attenzione e rendere concreti gli apprendimenti su Arduino.

Stato iniziale della classe:

  • hanno svolto le primissime prove con Arduino (blink e poco altro);
  • conoscono le variabili e hanno un’idea dei tipi di dato;
  • sanno riconoscere e usare pulsanti, interruttori, deviatori e LED.

L’obiettivo della lezione è mettere insieme questi elementi in un compito pratico, semplice ma significativo: progettare e realizzare un piccolo controller di luce che usa pulsante, interruttore/deviatore e LED, approfondendo al tempo stesso nozioni base di programmazione (lettura ingressi, gestione del tempo con millis() o delay(), piccola logica a stati AUTO/MANUALE).

Desidero che gli studenti vedano subito un risultato, si divertano a farlo funzionare e, passo dopo passo, consolidino lessico, metodo e fiducia.

Questa lezione sarà suddivisa in tre parti, due introduttive (ed ognuna con attività aggiuntive facoltative) che condurranno alla terza parte conclusiva in cui gli studenti dovranno realizzare il sistema completo.

In ogni fase viene mostrato:

  • diagramma di flusso;
  • pseudocodice;
  • schema di collegamento;

Lo studente deve realizzare lo sketch Arduino di ogni fase.

Come sempre amo introdurre il problema usando una narrazione coinvolgente e visto che mi piace la fantascienza andremo con i ragazzi su Marte. 🙂

Base marziana ELYSIUM

Siete il tecnico elettronico della base marziana. È stato inaugurato un nuovo modulo abitativo e, durante lo spostamento di carichi nel tunnel pressurizzato che collega la serra alla cupola, un carrello radiocomandato ha urtato la parete, provocando una micro-frattura con inizio di depressurizzazione. L’intervento rapido di un manutentore ha evitato il peggio. Dalle analisi emergono due cause principali: affaticamento del personale in turno e illuminazione insufficiente nel corridoio. Per prevenire incidenti e ridurre i consumi, il comando vi incarica di realizzare un controller luce “low-power”: in AUTO la luce si accende per pochi secondi quando viene rilevato il passaggio (lo simulerete con un pulsante); in MANUALE rimane attiva per la durata delle ispezioni EVA (Extra-Vehicular Activity). Il progetto deve essere affidabile, parsimonioso nei consumi e conforme agli standard di sicurezza della base, così da superare senza riserve la verifica dei consumi energetici imminente.

Per evitare che un bug in un solo componente comprometta l’intero sistema, decidete di scomporre il problema e validare separatamente i due comportamenti critici, prima di integrarli.

  1. Prima prova – “Solo PULSANTE” (sensore di passaggio)
    Nel banco di test allestito accanto al tunnel, il tecnico simula l’evento di passaggio con un pulsante. Alla pressione del pulsante la luce si accende un un determinato tempo e poi si spegne.
    (Facoltativo) Sperimentate anche la variante in cui la luce reagisca con un ping di cortesia temporizzato e che non riparta finché il pulsante resta premuto (niente retrigger). Questo serve a scongiurare illuminazioni troppo lunghe dovute a rimbalzi o pressioni involontarie: energia salva, rischio ridotto.
  2. Seconda prova – “Solo INTERRUTTORE” (modalità MANUALE)
    Il tecnico realizza il comando manuale: ON = luce stabile, OFF = buio. Qui controlla la priorità operativa.
    (Facoltativo) Sperimentate anche il feedback all’inserimento, due lampeggi rapidi. Quando si passa a ON: due lampeggi veloci e poi resta acceso.

Superate queste due verifiche, il tecnico procede alla versione finale: unendo AUTO (pulsante) e MANUALE (interruttore) nello stesso controller, con la regola d’oro: MANUALE ha sempre priorità. È così che il progetto rispetta il protocollo Zero-Disturb e arriva pronto alla verifica dei consumi energetici.


Prima prova – “Solo PULSANTE” (sensore di passaggio)

Esercizio: realizzare lo sketch Arduino che permette di realizzare questa prima prova.

Diagramma di flusso

Pseudocodice

INIZIO
  imposta PIN_LED come USCITA
  imposta PIN_PULSANTE come INGRESSO
  scrivi PIN_LED = LOW

  RIPETI PER SEMPRE
    statoPulsante ← leggi(PIN_PULSANTE)   // HIGH = premuto (pull-down esterno)

    SE statoPulsante è HIGH ALLORA
      scrivi PIN_LED = HIGH
      attesa 1500 ms
      scrivi PIN_LED = LOW
      attesa 50 ms
    FINE SE
  FINE RIPETI
FINE

Schema di collegamento

 


Prima prova – “Solo PULSANTE” (sensore di passaggio) – variante che evita il retrigger

Esercizio: realizzare lo sketch Arduino che permette di realizzare la variante della prima prova.

    • Premo > LED acceso ~1,5 s > poi spento.
    • Tenendo premuto non riparte; riparte solo dopo il rilascio.

Diagramma di flusso – versione che evita il retrigger

Pseudocodice – versione che evita il retrigger

INIZIO
  // Setup
  imposta PIN_LED come USCITA
  imposta PIN_PULSANTE come INGRESSO
  scrivi PIN_LED = LOW

  RIPETI PER SEMPRE   // loop
    statoPulsante ← leggi(PIN_PULSANTE)

    SE statoPulsante è HIGH ALLORA           // pulsante premuto
      scrivi PIN_LED = HIGH                  // accendi luce di cortesia
      attesa 1500 ms                         // delay 1,5 s
      scrivi PIN_LED = LOW                   // spegni

      // attesa rilascio per evitare retrigger continui
      MENTRE leggi(PIN_PULSANTE) è HIGH FAI
        attesa 10 ms
      FINE MENTRE

      attesa 50 ms                           // piccolo anti-rimbalzo
    FINE SE
  FINE RIPETI
FINE

Seconda prova – “Solo INTERRUTTORE” (modalità MANUALE)

Esercizio: realizzare lo sketch Arduino che permette di realizzare questa seconda prova.

  • Interruttore ON > LED acceso fisso. (1500 ms)
  • Interruttore OFF > LED spento.

Prevedere un anti-rimbalzo realizzato con un delay di 50 ms.

Diagramma di flusso

Pseudocodice

INIZIO
  imposta PIN_LED come USCITA
  imposta PIN_PULSANTE come INGRESSO
  scrivi PIN_LED = LOW

  RIPETI PER SEMPRE
    statoPulsante ← leggi(PIN_PULSANTE)   // HIGH = premuto (pull-down esterno)

    SE statoPulsante è HIGH ALLORA
      scrivi PIN_LED = HIGH
      attesa 1500 ms
      scrivi PIN_LED = LOW
      attesa 50 ms
    FINE SE
  FINE RIPETI
FINE

Diagramma di flusso

Pseudocodice

INIZIO
  // Setup
  imposta PIN_LED come USCITA
  imposta PIN_INTER come INGRESSO
  scrivi PIN_LED = LOW

  RIPETI PER SEMPRE    // loop
    statoInterruttore ← leggi(PIN_INTER)   // HIGH = MANUALE ON (con pull-down esterno)

    SE statoInterruttore è HIGH ALLORA
      scrivi PIN_LED = HIGH               // LED acceso
    ALTRIMENTI
      scrivi PIN_LED = LOW                // LED spento
    FINE SE
  FINE RIPETI
FINE

Schema di collegamento


Seconda prova (facoltativo) – “Solo INTERRUTTORE” (modalità MANUALE) – variante con feedback all’inserimento

Per il feedback prevedere un accensione e spegnimento del LED per 3 cicli da 80 ms

Diagramma di flusso

Pseudocodice – variante con feedback all’inserimento

INIZIO
  // Setup
  imposta PIN_LED come USCITA
  imposta PIN_INTER come INGRESSO    // pull-down esterno
  scrivi PIN_LED = LOW
  statoPrec ← LOW

  RIPETI PER SEMPRE
    stato ← leggi(PIN_INTER)          // HIGH = MANUALE ON

    // Rilevazione fronte di salita (OFF -> ON)
    SE (stato = HIGH) AND (statoPrec = LOW) ALLORA
      PER i da 0 a 1 FAI               // due lampeggi rapidi
        scrivi PIN_LED = HIGH
        attesa 80 ms
        scrivi PIN_LED = LOW
        attesa 80 ms
      FINE PER
    FINE SE

    // Stato stabile della modalita MANUALE
    SE (stato = HIGH) ALLORA
      scrivi PIN_LED = HIGH
    ALTRIMENTI
      scrivi PIN_LED = LOW
    FINE SE

    statoPrec ← stato
  FINE RIPETI
FINE

Realizzazione del sistema completa

Esercizio 03: realizzare lo sketch Arduino che permette di realizzare l’intero sistema.

  • manuale ON? = interruttore HIGH
  • pulsante premuto? = pulsante HIGH
  • timer attivo? = millis() prima di tScadenza (luce ancora entro i 5 s)

Diagramma di flusso

Pseudocodice

INIZIO
  // Setup
  imposta PIN_LED come USCITA
  imposta PIN_PULSANTE come INGRESSO
  imposta PIN_INTER come INGRESSO
  scrivi PIN_LED = LOW
  tScadenza ← 0
  DURATA_MS ← 5000

  RIPETI PER SEMPRE   // loop
    // Lettura ingressi
    statoInterruttore ← leggi(PIN_INTER)      // HIGH = MANUALE ON (pull-down esterno)
    statoPulsante     ← leggi(PIN_PULSANTE)   // HIGH = pulsante premuto

    // Significato applicativo
    manuale ← (statoInterruttore è HIGH)
    premuto ← (statoPulsante è HIGH)

    SE manuale ALLORA
      scrivi PIN_LED = HIGH                   // LED acceso fisso in MANUALE
    ALTRIMENTI
      SE premuto ALLORA
        tScadenza ← tempoCorrenteMs() + DURATA_MS
      FINE SE

      SE tempoCorrenteMs() < tScadenza ALLORA // timer attivo?
        scrivi PIN_LED = HIGH                 // LED acceso (luce di cortesia)
      ALTRIMENTI
        scrivi PIN_LED = LOW                  // LED spento
      FINE SE
    FINE SE
  FINE RIPETI
FINE

Schema di collegamento

 

Buon Coding a tutti 🙂

Attività STEAM con carta, cartone e coding – 5ª edizione

Sono sinceramente lusingato: il corso “Attività STEAM con carta, cartone e coding” arriva alla sua 5ª edizione. Credo che questa continuità sia merito della forte componente laboratoriale e della presenza di proposte immediatamente spendibili in classe, che i docenti possono portare ai propri studenti già dal giorno successivo.

Anche in questa nuova edizione porterò attività inedite, tutte sperimentate con studenti e insegnanti, che spaziano:

  • dal gaming (meccaniche di gioco per attivare partecipazione e feedback),
  • all’Intelligenza Artificiale (IA) per la didattica,
  • passando per il coding sia plugged sia unplugged, sempre con materiali semplici e a basso costo.

Cosa troverai nel corso

  • Laboratori guidati passo-passo e idee pronte all’uso.
  • Attività modulabili per tempi, livelli e discipline.
  • Suggerimenti per valutazione, inclusione e gestione della classe.

A chi si rivolge

Docenti della scuola primaria e secondaria, educatori e formatori che desiderano introdurre o potenziare attività STEAM con un approccio concreto, creativo e sostenibile.

Iscrizioni e dettagli

Tutte le informazioni (programma, calendario e iscrizione) sono disponibili qui:

Pagina ufficiale del corso su Tecnica della Scuola

Ti aspetto per costruire insieme percorsi STEAM efficaci, coinvolgenti e subito applicabili in aula e in laboratorio.

Buon Making a tutti 🙂

BBC micro:bit – Capire il significato di “beat” in MakeCode

In questi giorni ho risposto ad alcune domande di una collega che sta preparando lezioni sull’uso del BBC micro:bit per l’inizio del prossimo anno scolastico. Mi chiedeva chiarimenti sull’oggetto play e, in particolare, sul significato di beat, con l’obiettivo di spiegarlo in modo semplice e chiaro ai propri studenti. Poiché la questione è ricorrente anche tra i miei allievi, condivido qui la spiegazione completa.

Che cosa significa “beat”?

Nel blocco music.playTone o quando compare l’indicazione Middle C 1 beat, il termine beat indica l’unità di tempo musicale: il battito base, cioè la durata di una nota in funzione del tempo espresso in BPM (battiti per minuto).

Il micro:bit prende come riferimento il tempo corrente (default: 120 BPM).

In pratica:

  • Se il tempo è 120 BPM, 1 beat dura 500 ms (0,5 s).
  • Se il tempo è 60 BPM, 1 beat dura 1000 ms (1 s).

Da qui si deduce che:

  • play tone Middle C for 1 beat → riproduce il Do centrale per la durata di un battito.
  • 2 beats dura il doppio;
  • 1/2 beat dura la metà.

Quanto dura “Middle C 1 beat”?

La domanda tipica degli studenti è: “Quanti millisecondi dura questa nota?”

Dipende dal tempo (BPM) impostato: il micro:bit usa il tempo corrente (default: 120 BPM).

  • A 120 BPM → 1 beat = 500 ms → la nota dura mezzo secondo.
  • A 60 BPM → 1 beat = 1000 ms → la nota dura 1 secondo.
  • A 180 BPM → 1 beat ≈ 333 ms → la nota dura circa un terzo di secondo.

Possiamo adottare la seguente formula generale per dedurre il numero di ms (millisecondi) partendo dai BPM:

Per rendere più immediata la comprensione in classe, di seguito una tabella di corrispondenza e il grafico delle durate:

Durata in beat 60 BPM (1 beat = 1000 ms) 90 BPM (1 beat = 667 ms) 120 BPM (1 beat = 500 ms) 180 BPM (1 beat = 333 ms)
1 beat 1000 ms (1,0 s) 667 ms (0,67 s) 500 ms (0,5 s) 333 ms (0,33 s)
1/2 beat 500 ms 333 ms 250 ms 167 ms
1/4 beat 250 ms 167 ms 125 ms 83 ms
1/16 beat 62,5 ms 42 ms 31 ms 21 ms
2 beat 2000 ms (2 s) 1333 ms (1,33 s) 1000 ms (1 s) 667 ms (0,67 s)
4 beat 4000 ms (4 s) 2667 ms (2,67 s) 2000 ms (2 s) 1333 ms (1,33 s)

Il concetto di beat in MakeCode è un ponte naturale tra programmazione e musica: mostra come il tempo (BPM) determini la durata delle note e come la matematica entri nei calcoli temporali. È un chiaro esempio di integrazione STEAM. Grazie alla collega per lo spunto: la sua domanda mi ha dato l’occasione di chiarire ancora meglio l’uso dei blocchi “Music”.

Buon Coding a tutti 🙂

Corso di Processing – lezione 10

Variabili in Processing: dichiarazione, tipi e utilizzo

Una variabile è uno spazio di memoria con un nome, in cui possiamo memorizzare dati da usare e modificare nel corso del nostro programma. In Processing, le variabili sono fondamentali per personalizzare il comportamento degli oggetti grafici, mantenere lo stato del programma, contare, animare, verificare condizioni e molto altro.

1. Cos’è una variabile?

Potete immaginare una variabile come una scatola etichettata in cui potete inserire (e cambiare) un valore. Ogni scatola ha:

  • un nome
  • un tipo di dato
  • un valore (che può cambiare)

Sintassi base:

tipo nome = valore;

Esempio:

int lato = 50; // dichiara una variabile intera chiamata "lato" e le assegna il valore 50

2. Tipi principali di variabili in Processing

Numeri interi – int

Valori numerici senza decimali.

int x = 100;

Numeri con virgola – float

Numeri decimali.

float trasparenza = 127.5;

Valori logici – boolean

Può essere solo true (vero) o false (falso).

boolean attivo = true;

Testi – String

Sequenze di caratteri tra virgolette.

String saluto = "Ciao mondo!";

3. Usare variabili per disegnare

Possiamo usare le variabili per controllare dimensioni, posizione, colore, e altri aspetti grafici.

Esempio: dimensione variabile per un cerchio

int diametro = 100;

void setup() {
  size(400, 400);
  background(255);
  fill(0, 150, 255);
  ellipse(width/2, height/2, diametro, diametro);
}

Modifica il valore di diametro per vedere come cambia il disegno.

4. Variabili e animazioni

Le variabili possono essere aggiornate nel tempo per creare un movimento.

Esempio: far muovere un cerchio

float x = 0;

void setup() {
  size(400, 400);
}

void draw() {
  background(255);
  fill(255, 0, 0);
  ellipse(x, 200, 50, 50);
  x = x + 2; // ogni frame aumenta la posizione
}


Continua a leggere

Corso di Processing – lezione 09

Cosa sono gli eventi?

Rilevare eventi con mousePressed() e keyPressed() in Processing

Durante l’esecuzione di un programma, possono verificarsi azioni che non dipendono direttamente dal flusso continuo del codice, ma da interazioni esterne, come un clic del mouse, la pressione di un tasto o altri cambiamenti. Queste azioni prendono il nome di eventi.

In Processing, gli eventi che gestiamo più frequentemente sono quelli legati al mouse e alla tastiera. Per rispondere a questi eventi, il linguaggio ci mette a disposizione blocchi di codice speciali, simili a setup() e draw(), ma con una differenza fondamentale: il loro contenuto non viene eseguito automaticamente all’avvio del programma, né ripetuto in loop.

Le funzioni evento, come mousePressed() o keyPressed(), vengono eseguite una sola volta, solo quando si verifica una specifica azione dell’utente, come ad esempio un clic o la pressione di un tasto. Questo permette di rendere i nostri sketch interattivi e reattivi, eseguendo istruzioni solo al momento giusto.

1. La funzione mousePressed()

Questa funzione si attiva ogni volta che l’utente preme un tasto del mouse.

Esempio 1: disegnare un quadrato dove si fa clic

void setup() {
size(400, 400);
background(255);
}

void draw() {
// Vuoto, perché disegniamo solo quando si clicca
}

void mousePressed() {
fill(0, 200, 100);
noStroke();
rect(mouseX, mouseY, 40, 40);
}

Ogni clic del mouse disegna un nuovo quadrato verde nella posizione del puntatore.

2. La funzione keyPressed()

Viene eseguita ogni volta che si preme un tasto sulla tastiera.

Esempio 2: aumentare la dimensione di un cerchio premendo i tasti “+” o “-“

int diametro = 50;
void setup() {
  size(400, 400);
}

void draw() {
  background(255);
  fill(100, 100, 255);
  ellipse(width/2, height/2, diametro, diametro);
}

void keyPressed() {
  if (key == '+') {
    diametro += 10;
  } else if (key == '-') {
    diametro = max(10, diametro - 10);
  }
}

Premi + per ingrandire il cerchio e - per rimpicciolirlo, con un limite minimo.

Continua a leggere