Raspberry Pi

Che cos’è

Il Raspberry Pi è un computer completo delle dimensioni di una carta di credito. Mentre un Arduino Uno è un microcontrollore che esegue per sempre un solo programma, un Pi esegue Linux e può quindi pilotare una telecamera, comunicare con la rete, eseguire ROS 2 e far girare contemporaneamente il codice del robot. È il cervello a cui ricorrere quando un robot deve pensare, non soltanto reagire.

Questa potenza è anche il suo compromesso: il multitasking di Linux rende il Pi meno adatto alla temporizzazione precisa al microsecondo che un microcontrollore ottiene senza alcuno sforzo. I due sono partner, non rivali.

Come funziona

Il Pi avvia un sistema operativo, di solito Raspberry Pi OS, da una scheda microSD, poi si comporta come qualsiasi macchina Linux. Per la robotica, la parte importante è l’header GPIO a 40 pin: ingressi e uscite digitali, più i bus I²C, SPI e UART, che permettono al Pi di leggere sensori e comandare hardware. A tutto ciò si aggiungono le parti di computer — USB, Ethernet, Wi-Fi e interfaccia per telecamera — che un microcontrollore semplicemente non possiede.

Un’architettura comune è il robot a due cervelli: il Pi gestisce percezione e pianificazione (visione, SLAM, nodi ROS) e inoltra i comandi dei motori a un Arduino che esegue il controllo in tempo reale.

Quando usarlo

Scegli un Pi quando il robot necessita delle capacità di un computer:

• Visione artificiale — una telecamera più OpenCV per rilevare marcatori, oggetti o linee.
• ROS 2 — esecuzione di nodi, topic e stack di navigazione.
• Mappatura / SLAM — costruzione di una mappa e localizzazione al suo interno.
• Rete — cruscotto web, controllo remoto o telemetria.

Per attività puramente di controllo in tempo reale, resta con un Arduino o uno ESP32: sono più economici, più semplici e migliori per la temporizzazione precisa.

Cablaggio e aspetti critici

• Logica a 3.3 V e non tollerante ai 5 V. Fornire 5 V a un pin GPIO può danneggiare il Pi. Trasforma il livello dei segnali provenienti da componenti a 5 V, per esempio la linea TX di un HC-05.
• Non può comunque alimentare motori. Il GPIO pilota segnali; la corrente dei motori passa da un driver come L298N.
• L’alimentazione è esigente. Fornisci 5 V stabili con corrente sufficiente: i cali di tensione corrompono la scheda SD e causano riavvii casuali.
• Spegnilo in modo pulito. Sottrarre alimentazione a un sistema Linux in esecuzione può corrompere la scheda: progetta uno spegnimento sicuro oppure usa un file system in sola lettura.

L’header a 40 pin e quali pin si possono usare

L’header ha 40 pin, ma solo 26 sono utilizzabili come GPIO. Gli altri sono alimentazione e terra.

Due di queste righe costano regolarmente una serata a molte persone.

L’UART è la console. Appena acceso, GPIO 14/15 trasportano una richiesta di login Linux. Se vi colleghi un modulo GPS o Arduino, riceverai rumore di login anziché dati. Liberali con sudo raspi-config → Interface Options → Serial Port → login shell: no, hardware serial: yes. Su Pi 3 e successivi c’è un’ulteriore complicazione: l’UART migliore è usato per impostazione predefinita da Bluetooth, mentre quello sull’header è una “mini UART” inferiore, la cui frequenza di baud deriva dal clock della CPU. Aggiungi dtoverlay=disable-bt a /boot/config.txt per scambiarli.

Il PWM software oscilla. Solo quattro pin hanno PWM hardware. Tutto il resto è generato dal kernel e lo scheduler Linux può interromperlo, il che su un servomotore si manifesta come scatti visibili. È l’illustrazione più chiara di ciò che il Pi fa male.

Il problema della temporizzazione, in modo diretto

Questa è la cosa più importante da capire su un Pi in un robot e non è un difetto: è il modo in cui funziona un sistema operativo.

Un microcontrollore che esegue loop() esegue il tuo codice e nient’altro, quindi un intervallo di 1 ms è 1 ms. Linux suddivide il tempo: il kernel può sottrarre tempo al processo per gestire un pacchetto di rete, svuotare una scrittura su disco o eseguire una qualsiasi tra cento attività in background.

La conseguenza è l’architettura a due cervelli, che non è un compromesso ma il normale progetto per un robot serio:

Raspberry Pi                        Microcontroller
- camera, vision                    - encoder counting
- SLAM, path planning       <-->    - PID motor control
- ROS 2 nodes                       - servo timing
- networking, dashboard             - emergency stop
        high-level goals                  hard real time

Comunicano tramite seriale USB, UART o I²C e ciascuno fa ciò per cui è più adatto. Un Pi che tenta di contare i fronti di un encoder li perderà; un Arduino che tenta di eseguire OpenCV non può.

Alimentazione e problema della scheda SD

L’alimentazione è il punto in cui falliscono i robot basati su Pi e la modalità di guasto è insolitamente costosa: un calo di tensione durante una scrittura corrompe la scheda SD e si perde l’intera immagine di sistema.

Da ciò seguono queste regole:

• Non alimentare mai motori e Pi dalla stessa linea. La corrente di spunto del motore è esattamente il transitorio che corrompe una scheda.
• Usare un regolatore a commutazione, non lineare, quando si riduce la tensione di una batteria. Un regolatore lineare che porta 11.1 V a 5 V a 1 A dissipa 6 W.
• Fare attenzione al fulmine. Il Pi mostra e registra un’icona di avviso per sottotensione; anche vcgencmd get_throttled la segnala. Un valore diverso da zero significa che l’alimentatore è inadeguato e prima o poi corromperà una scheda.
• Spegnere in modo pulito. sudo shutdown -h now prima di togliere l’alimentazione. Un robot spento con un interruttore deve avere un pulsante di spegnimento collegato a un GPIO oppure un file system radice in sola lettura.

Per un robot impiegato sul campo, vale la pena valutare seriamente il file system in sola lettura: con overlayfs attivo, durante il funzionamento non viene mai scritto nulla sulla scheda e l’alimentazione può essere tolta in qualsiasi momento senza conseguenze. Si perde la possibilità di salvare dati localmente, che è solitamente un compromesso accettabile.

Quale modello scegliere per un robot

Per ROS 2 con una telecamera, 4 GB è il punto in cui le cose smettono di essere frustranti. RViz, un nodo di visione e uno stack di navigazione insieme useranno più di 1 GB e un Pi che inizia a usare la scheda SD per lo swap diventa inutilizzabilmente lento, consumando anche la scheda.

Due accessori che in pratica non sono opzionali: un dissipatore o ventilatore (un Pi 4 sotto carico costante riduce la frequenza della CPU quando raggiunge gli 80 °C, e un Pi sotto limitazione termica perde fotogrammi) e una buona scheda microSD di classe A2 o, meglio, l’avvio da SSD USB. Il collo di bottiglia è la velocità della scheda molto più spesso della CPU.

Risoluzione dei problemi

Pi o microcontrollore?

Il modo corretto di inquadrarlo è questo: non sono concorrenti. Un Pi non può contare in modo affidabile i fronti di un encoder e un microcontrollore non può eseguire OpenCV. Quasi ogni robot hobbistico capace finisce per usare entrambi e riconoscerlo fin dall’inizio evita di perdere tempo tentando di far svolgere a uno il lavoro dell’altro.

Se l’intero comportamento del robot rientra in un solo anello di controllo — un robot seguilinea, un robot che evita ostacoli, un risolutore di labirinto — non hai bisogno di un Pi; aggiungerlo rende il robot più lento ad avviarsi, più fragile e più difficile da eseguire il debug.