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 🙂

Dirimere i conflitti con il pensiero computazionale – educazione civica – Definizione del problema – lezione 01

La violenza, dai conflitti globali alla violenza verbale quotidiana, nasce spesso dal non-ascolto e dalla prevaricazione. Nel laboratorio di sistemi elettronici trasformiamo i principi di convivenza civile in processi chiari: condizioni, regole, passi verificabili. Il lavoro in gruppo e la scrittura dell’algoritmo favoriscono la riflessione e il senso di giustizia che nasce dal confronto tra pari, non dall’imposizione. In un’epoca di bombardamento continuo di notizie che rischia di normalizzare la violenza e di farci sentire impotenti, progettare insieme percorsi di dialogo è un dovere civico oltre che un’attività didattica.

Contenuto dell’attività

Obiettivi

  • Distinguere fatti da interpretazioni in un conflitto.
  • Formulare il problema in una frase chiara.
  • Definire regole minime di dialogo e condizioni di sicurezza.

Durata: 60–75 minuti
Materiali: scheda cartacea o digitale (tabella), post-it, pennarelli.

Fasi

  1. Rompighiaccio (5 minuti)
    • Brainstorm: dove incontriamo conflitti (classe, chat, famiglia, social, ambiente)?
    • Raccogli su post-it parole chiave (ascolto, rispetto, tempi, diritti, minoranze).
  2. Fatti vs interpretazioni (15 minuti)
    • Consegna una scheda con due colonne:
      • Colonna A: FATTI (osservabili, verificabili).
      • Colonna B: INTERPRETAZIONI (opinioni, giudizi, attribuzioni di intenzioni).
    • Ogni gruppo (3–4 studenti) compila la tabella su un caso realistico proposto da te.
  3. Regole minime del confronto (10 minuti)
      • Stabilire 4 regole operative: niente insulti, parlo di me non accuso te, no interruzioni, tempi uguali.
        • Cosa si intende per: “parlo di me non accuso te”
          • Esempio 01: “Io mi sento confuso quando parliamo tutti insieme, perché non capisco. Ti chiedo di alzare la mano.”
          • Esempio 02: “Io mi innervosisco quando vengo interrotto, perché perdo l’idea. Ti chiedo di farmi finire.”
      • Decidere la condizione di sicurezza: se non è un buon momento, si prevede un time-out.
  4. Definizione del problema (15 minuti)
    • Ogni gruppo formula 1 “frase problema” chiara e neutra (max 20 parole).
    • Esempio: “Nel gruppo di laboratorio c’è disaccordo sulla divisione dei compiti e sui tempi di consegna”.
  5. Condivisione e feedback (10 minuti)
    • Ogni gruppo legge la frase. Feedback degli altri: è chiara? è neutra? evita accuse?

Lista elementi per la valutazione formativa

  • Chiarezza della frase problema.
  • Distinzione corretta fatti/interpretazioni.
  • Qualità delle regole proposte.
  • Partecipazione e rispetto dei turni.
  • Sintesi finale.

Buon lavoro 🙂

Dirimere i conflitti con il pensiero computazionale – educazione civica – presentazione

Esercitazione di Educazione Civica nelle ore di Laboratorio di Sistemi Elettronici

Desidero condividere la scheda di lavoro del percorso di educazione civica che avvierò oggi con i miei studenti. Come sapete, l’educazione civica è affidata a tutti i docenti del consiglio di classe e viene insegnata con un approccio trasversale e interdisciplinare. Per quanto mi riguarda, condurrò le prime tre ore di lezione a partire da oggi, integrandole con i contenuti della disciplina che insegno: Laboratorio di Sistemi Elettronici.

Condivido la scheda così come l’ho progettata nei giorni scorsi: modificatela e adattatela liberamente dove ritenete opportuno. Vi ringrazio fin d’ora se vorrete darmi un riscontro sia sulla validità della proposta sia sull’eventuale sperimentazione nelle vostre classi. La sto testando e con ogni probabilità apporterò modifiche in itinere.

Perché fare educazione civica in laboratorio di sistemi elettronici

Perché progettare un algoritmo è progettare una convivenza: si definiscono condizioni, stati, ingressi/uscite e verifiche di esito. Nel laboratorio trasformiamo i principi di costituzione, diritti e responsabilità in procedure operative che gli studenti possono vedere, toccare e migliorare.

In più, scrivere l’algoritmo e svilupparlo in gruppo porta inevitabilmente a riflettere su questi problemi, a cercare modi concreti per affrontarli e, soprattutto, a coltivare un senso di giustizia che nasce dal confronto civile. È nella pratica del “decidere insieme” e non nell’imposizione dall’alto tipica di leadership autocratiche che si progetta la pace: solo così, con regole condivise, possiamo contribuire a rendere migliore questo mondo.

Infine, in un contesto in cui il bombardamento continuo di notizie rischia di assuefarci a una falsa normalità della violenza e di farci sentire impotenti di fronte ai problemi globali, il laboratorio offre un antidoto: riflettere e progettare insieme percorsi di dialogo e cooperazione. Farlo non è solo un’opportunità didattica: è un dovere civico, un esercizio concreto di responsabilità verso il bene comune.

Ho previsto una versione base che, secondo la mia progettazione, richiede circa tre ore. Non so se durante le prossime lezioni o più avanti proporrò una versione avanzata, che integra criteri di valutazione, punteggi: questa seconda forse la farò sviluppare quando la classe avrà acquisito maggiore dimestichezza con la programmazione, ma osservo e nel caso troverete su questo sito la proposta avanzata integrata all’interno delle tre lezioni che vi condividerò settimanalmente (credo) con lo sviluppo di una proposta di soluzione del diagramma di flusso, pseudocodice e Sketch Arduino.

Scheda di lavoro

In questa attività uniamo educazione civica e competenze tecnico-scientifiche per riflettere su conflitti che toccano la nostra società: escalation di guerre, fenomeni di apartheid e discriminazione, crisi climatica, violenza verbale online e offline. Al centro c’è un’idea semplice e credo potente: molte forme di violenza nascono dal non-ascolto e dalla prevaricazione, dal non tenere conto del pensiero altrui e dei diritti delle minoranze.
Useremo il pensiero computazionale (diagrammi di flusso, pseudocodice, automazione con Arduino) per progettare procedure di dialogo e mediazione: la logica degli algoritmi diventa un modo per rendere trasparente, equo e verificabile il percorso verso una soluzione condivisa.

Obiettivi formativi

  • Civici: sviluppare ascolto attivo, rispetto reciproco, gestione non violenta dei conflitti, attenzione ai diritti e alle minoranze.
  • Tecnici: saper rappresentare un processo con diagramma di flusso e pseudocodice; tradurre la procedura in uno sketch Arduino semplice con input da seriale e feedback visivo/sonoro.
  • Metodologici: passare da opinioni generiche a passi operativi (regole, turni di parola, verifica di comprensione, decisione).

Struttura del percorso (3 lezioni)

Lezione 1 – Definizione del problema

  • Analisi di casi: conflitti quotidiani (classe, social, famiglia) e macro-temi (discriminazione, clima, linguaggi d’odio).
  • Riconoscere attori, interessi, regole e condizioni minime per un confronto sicuro.
  • Distinguere fatti da interpretazioni e formulare il problema in una frase chiara.

Lezione 2 – Diagramma di flusso e pseudocodice

  • Costruzione di una versione base dell’algoritmo di mediazione:
    controllo sicurezza del confronto > turni di parola > parafrasi reciproca > generazione di opzioni > decisione o richiesta di mediazione.
  • Stesura del pseudocodice con variabili in italiano e commenti esplicativi.

Lezione 3 – Sketch Arduino

  • Implementazione su Arduino con input via Serial Monitor e feedback con LED integrato (e buzzer opzionale).
  • Test guidato: simulare conversazioni e verificare come l’algoritmo aiuta a ridurre ambiguità, toni aggressivi e fraintendimenti.

Competenze attese

  • Competenze civiche e sociali: ascolto, empatia, negoziazione, responsabilità.
  • STEM: modellazione di processi, astrazione, controllo di flusso (condizioni e cicli), debugging di procedure.
  • Comunicazione: parafrasi, sintesi in una frase problema, linguaggio tecnico chiaro.

Materiali essenziali

  • PC con Arduino IDE, scheda Arduino UNO (o equivalente), cavo USB.
  • Serial Monitor per l’interazione, LED integrato (pin 13) e buzzer opzionale su pin 5.
  • Fogli per diagrammi/pseudocodice; regole di dialogo condivise.

Valutazione (formativa)

  • Qualità del diagramma di flusso (chiarezza, completezza, uso corretto di bivi e cicli).
  • Aderenza del pseudocodice al diagramma.
  • Funzionamento dello sketch e qualità dei commenti.
  • Comportamenti osservabili di ascolto e rispetto durante le simulazioni.

Inclusione e clima di classe

  • Ruoli rotanti (moderatore, portavoce, time-keeper, osservatore del linguaggio).
  • Consegnare una griglia di frasi utili per “io-messaggi” e parafrasi.
  • Tempi scanditi e check-point per favorire la partecipazione di tutti.

Progettiamo la pace 🙂

Quick References per lo studio – Nomi file & versioni

Dare un nome chiaro ai file e gestire le versioni non è pignoleria: è ciò che ti fa trovare subito ciò che cercate, capire al volo quale documento è l’ultimo e collaborare senza caos. In classe e nei progetti di gruppo capita spesso di avere decine di file chiamati “Relazione definitiva (nuova)”, “Relazione_ultimissima (1)”, “prova2_bis.pdf”. Risultato: si perde tempo, si consegna il file sbagliato, si confondono revisioni e correzioni del docente.

Un buon naming (come chiami il file) e un semplice versioning (come tenete traccia delle versioni) risolvono questi problemi perché:

  • i file sono ordinabili in modo naturale (per data, per progetto, per autore);
  • il nome racconta cosa contiene e a che punto è (v1.0, v1.1, v2.0…);
  • lavorare in gruppo diventa più semplice (ognuno segue la stessa convenzione);
  • la consegna è pulita: il docente vede subito cosa aprire, senza dubbi.

Non serve un software complicato: basta una regola condivisa e costante. Con una convenzione semplice, in 1 secondo capisci versione, tema e autore; in 2 clic trovi tutto ciò che ti serve.

Esempio sintetico:

  • Nomi coerenti = cercare e condividere senza perdersi.
  • Regola: AAAA-MM-GG_progetto-parole-chiave_vX.Y_autore.ext.
    Ordinabile per data, leggibile da tutti, facile da versionare. Evita spazi e caratteri strani; usa trattini.
  • Cartelle consigliate: /classe/materia/progetto/gruppo/.

Scarica PDF A4 della guida operativaApri il sorgente Markdown su GitHub

Se non sai cos’è il Markdown segui il link

---
title: "QR – Nomi file & versioni come i pro"
version: "1.1"
autore: "<Classe/Studente>"
licenza: "CC BY 4.0"
ultimo_aggiornamento: "2025-10-05"
---

# Perché una convenzione aiuta
- Trovi i file subito (ordinamento per data e nome).
- Capisci a colpo d’occhio contenuto e versione.
- Meno conflitti/doppioni nei lavori di gruppo.
- Consegne pulite e professionali.

## Convenzione base (da usare)
`AAAA-MM-GG_progetto-parole-chiave_vX.Y_autore.ext`

**Spiegazione**
- `AAAA-MM-GG` = data (es. 2025-10-05)
- `progetto-parole-chiave` = tema + 1–3 parole utili (senza spazi; usa trattini)
- `vX.Y` = versione (X=major, Y=minor: v1.0, v1.1, v2.0…)
- `autore` = cognome o nome-cognome / nome del team
- `ext` = estensione (.pdf, .docx, .ino, .csv, .pptx…)

## Struttura cartelle consigliata
/classe/materia/progetto/gruppo/{dati,codice,relazione,media}

## Regole d’oro
- Usa trattini `-` o underscore `_` (no spazi, accenti, emoji).
- Minuscole coerenti; nomi descrittivi.
- Incrementa solo la parte necessaria della versione.
- Esporta un PDF finale per le consegne.

## Versioning semplice
- Inizio: v1.0 (prima consegna “completa”)
- Piccole correzioni: v1.1, v1.2 …
- Cambio sostanziale: v2.0
- Se arrivano commenti del docente: crea una nuova versione (non sovrascrivere)

## Modelli pronti (copia e incolla)
- Relazione (PDF): `AAAA-MM-GG_relazione-_vX.Y_.pdf`
- Codice Arduino: `AAAA-MM-GG__vX.Y_.ino`
- Dataset CSV: `AAAA-MM-GG_dati--_vX.Y_.csv`
- Presentazione: `AAAA-MM-GG_presentazione-_vX.Y_.pptx`
- Immagine/Figura: `AAAA-MM-GG_fig--_vX.Y_.png`

## Esempi rapidi (solo nomi, da imitare)
- 2025-10-05_relazione-arduino_stazione-ambientale_v1.0_rossi.pdf
- 2025-10-05_codice-sensore-luce_v1.3_rossi.ino
- 2025-10-05_dati-luce-umidita-aula3_v0.3_teamB.csv

## Checklist finale
- [ ] Stesso formato per tutti i file del progetto
- [ ] Versione aggiornata (vX.Y) coerente
- [ ] Niente duplicati “finale_definitivo(3).docx”
- [ ] PDF esportato per la consegna

Esempio 01 – Consegna di gruppo (Arduino)

  • Cartella: /3B/info/stazione-ambientale/teamB/
  • File:
    2025-11-12_relazione-stazione-ambientale_v1.2_teamB.pdf
    2025-11-12_dati-luce-umidita-aula3_v1.0_teamB.csv
    2025-11-12_codice-lettura-sensori_v1.3_teamB.ino
    2025-11-12_fig-01-schema-cablaggio_v1.0_teamB.png

Esempio 02 – Correzioni del docente > nuova versione

  • Prima: 2025-11-12_relazione-stazione-ambientale_v1.2_teamB.pdf
  • Dopo correzioni: 2025-11-15_relazione-stazione-ambientale_v1.3_teamB.pdf
  • Changelog (facoltativo): “2025-11-15 v1.3: aggiunte unità SI; rigenerato grafico con etichette leggibili.”

Home Assistant a scuola: la guida “a puntate” per elettronica & automazione – 02


Prima di iniziare con l’installazione del software procediamo con la configurazione base dell’hardware, nel mio caso dispongo a scuola di un Raspberry Pi 4 Model B – 4 GB RAM e su questa versione opereranno gli studenti, ovviamente la scelta di un modello superiore con maggior memoria è consigliabile, ciò che ho fatto per la mia versione casalinga con un un Raspberry Pi 5 – 8 GB RAM.

Questa prima parte è estremamente semplice e richiede pochissime competenze tecniche, installeremo le alette di raffreddamento e la ventola di raffreddamento collegandola ai pin di alimentazione che troviamo sulla GPIO.

Note per chi inizia: Cos’è la GPIO del Raspberry Pi

GPIO = General Purpose Input/Output: è il pettine a 40 pin sulla scheda che vi permette di leggere/scrivere segnali digitali e, quando necessario, usare funzioni: come I²C, SPI, UART, PWM ecc. Sulla Pi 4 solo 28 sono utilizzabili per la programmazione. La GPIO del Pi 4 è identica, per posizione e funzioni base, a quello dei modelli precedenti con header a 40 vie: quindi HAT e cablaggi restano compatibili. Al termine della guida è indicato la piedinatura della GPIO ed i pin a cui connettere la ventola di raffreddamento.

Raspberry Pi 4 offre molta più potenza dei modelli precedenti e, sotto carico sintetico (cioè durante test artificiali che stressano intenzionalmente CPU/GPU per misurare il “la situazione peggiore di utilizzo”), può scaldare rapidamente fino a innescare il throttling (taglio automatico della frequenza per protezione termica). Le misure ufficiali con il firmware iniziale mostrano picchi fino a 72,1 °C in 60 s e l’avvio del throttling dopo circa 65 s; gli aggiornamenti firmware successivi hanno ridotto consumi/temperature e posticipato il momento in cui il taglio di frequenza interviene, ma in carichi intensi il rischio resta. Per chi usa il Pi 4 in modo continuativo (es. Home Assistant), aggiungere alette di raffreddamento + ventola aiuta a mantenere la CPU sotto soglia, evitando cali di prestazioni e migliorando stabilità e longevità del sistema.

Di seguito due immagini della scheda realizzate con la termocamera in fase di test.

Per maggiori informazioni vi rimando all’articolo tecnico che trovate sul sito Rapberrypi.org

Situazione in fase di riposo

Raspberry Pi 4 VLI, SDRAM (idle)

Situazione in fase di load

Raspberry Pi 4 VLI, SDRAM (load)

Di cosa abbiamo bisogno

  • Kit dissipatore in alluminio per Raspberry Pi 4 (molti includono doppia ventola + thermal pad + viteria).
  • Cacciavite a croce di piccole dimensioni.
  • Alcol isopropilico + panno morbido (per pulire i chip prima del fissaggio delle alette).
  • Facoltativo: fascette/clip per gestire i cavi.

Sicurezza e prevenzione

Sembra banale, ma meglio specificarlo, soprattutto per i giovani studenti che iniziano attività laboratoriali:

  1. Scollegare l’alimentazione del Raspberry Pi.
  2. Lavorare su superficie pulita; toccate una parte metallica messa a terra per scaricare l’elettricità statica (se disponete di un braccialetto antistatico meglio).
  3. Pulire delicatamente CPU/RAM/controller USB con un panno leggermente inumidito di alcol isopropilico e lascia asciugare.

Applicare le alette di raffreddamento

Sono acquistabili su qualsiasi store online, andranno montate sulla CPU, sulla RAM e sul Bridge PCI e USB 3.0. Incollate, come indicato nelle foto che seguono, le alette di raffreddamento, ogni aletta è dotata di nastro biadesivo.

Serraggio e alimentazione della ventola

In funzione del kit che avete acquistato o stampato in 3D la ventola di raffreddamento, alimentata a 5V è da fissare sulla struttura mediante 4 viti autofilettanti.

L’alimentazione della ventola avviene direttamente connettendo direttamente i pin di alimentazione della GPIO secondo quanto indicato dall’immagine che segue.

Poiché potrebbe servire in altre applicazioni condivido la mappa della GPIO del Raspberry Pi 4.

Per alimentare la ventola utilizzerò il +5V, preso sul pin 2 ed il pin 6 per il GND, come indicato nell’immagine che segue (datasheet Raspberry Pi 4)

Nell’immagine che segue è ben evidente il collegamento:

Procedere al servaggio della ventola al vetro supporto.

Buon Making a tutti 🙂