Progettazione di PCB per schede di controllo robotizzate per elaborazione, I/O e DFM

La scheda di controllo del robot si trova al vertice della gerarchia elettronica: è l'unità di elaborazione che esegue il software applicativo, coordina gli azionamenti dei motori, legge lo stato dei sensori e comunica con il mondo esterno. Il funzionamento di un robot dipende in parte dalla corretta progettazione della scheda di controllo in termini di temporizzazione, capacità di calcolo, interfacce di comunicazione e affidabilità. Questa pagina tratta nello specifico la progettazione e la produzione di PCB per schede di controllo robotizzate: quali sono le opzioni di SoC e MCU disponibili sulle piattaforme moderne, quali interfacce deve ospitare la scheda e quali considerazioni di produzione si applicano per realizzare la scheda in modo affidabile.

Le moderne schede di controllo per robot combinano la potenza di calcolo di MCU o SoC con un ricco set di interfacce, bus ad alta velocità a impedenza controllata, memoria non volatile e, spesso, gestione dell'alimentazione integrata. La progettazione interseca diverse discipline – elaborazione embedded, controllo del movimento, comunicazione, archiviazione, alimentazione – ognuna delle quali ha le proprie specifiche metodologie. I programmi in cui la scheda di controllo è progettata tenendo conto di tutti questi aspetti realizzano prodotti affidabili; i programmi che trattano la scheda di controllo come una piattaforma embedded generica in genere riscontrano lacune specifiche della robotica in fase di integrazione o di implementazione sul campo.

Che cosa fa concretamente una scheda di controllo robot all'interno di un sistema robotico?

La scheda di controllo definisce il limite software del robot.

Capacità di calcolo, memoria, spazio di archiviazione, numero di interfacce, connettori di espansione e margine termico determinano ciò che il team di sviluppo software può realizzare durante l'intero ciclo di vita del robot. Una scheda di controllo ottimizzata solo per i requisiti della prima versione diventa spesso il collo di bottiglia quando si espandono funzionalità come percezione, registrazione dati, diagnostica, connettività o sicurezza.

Le schede di controllo dei robot eseguono il software applicativo di alto livello del robot, coordinano i sottosistemi periferici e comunicano con i sistemi esterni. Si trovano al vertice della gerarchia di controllo: inviano comandi agli azionamenti dei motori, leggono lo stato dei sensori, gestiscono la percezione e la pianificazione e si interfacciano con il mondo esterno. Ciò che distingue una scheda di controllo per robot dagli altri controller embedded è la combinazione di esigenze che deve gestire contemporaneamente:

• Coordinamento in tempo reale: La scheda di controllo invia comandi agli azionamenti dei motori e legge lo stato dei sensori a frequenze di ciclo che determinano la qualità del movimento del robot. La frequenza di ciclo tipica per il coordinamento del movimento è compresa tra 100 Hz e 1 kHz; frequenze più elevate sono necessarie per applicazioni più impegnative.
• Elaborazione a livello applicativo: Pianificazione, percezione, processo decisionale e interfaccia utente vengono eseguiti sulla stessa scheda o su una scheda di elaborazione co-ubicata. Il carico di calcolo varia da modesti carichi di lavoro MCU su robot semplici a carichi di lavoro SoC di classe Linux completi su piattaforme complesse.
• Centro di comunicazione: La scheda di controllo ospita in genere le interfacce cablate e wireless per i sistemi esterni. Ethernet, USB, Wi-Fi, CAN e spesso interfacce specializzate per protocolli specifici del robot.
• Memoria non volatile: Il software applicativo, i dati di calibrazione, la configurazione e i registri vengono memorizzati su eMMC, SD o SSD a seconda dei requisiti di capacità e affidabilità.
• Gestione energetica: Regolazione della tensione a bordo per le diverse linee di alimentazione necessarie al SoC e alle periferiche. Talvolta la scheda di controllo gestisce anche il coordinamento dello stato di attivazione/disattivazione per i sottosistemi a basso consumo.

La scheda di controllo è il punto in cui le capacità astratte del robot incontrano la loro implementazione fisica. Il software applicativo viene eseguito lì; lo stato dei sensori viene aggregato lì; i comandi di movimento vengono generati lì. Le capacità della scheda di controllo in fase di progettazione determinano le capacità del robot durante tutto il suo ciclo di vita: una scheda di controllo con risorse insufficienti in termini di potenza di calcolo, memoria o interfacce limita il team di sviluppo software per l'intero ciclo di vita del prodotto. I programmi che specificano la scheda di controllo con un margine di sicurezza ampio consentono in genere l'espansione delle funzionalità; i programmi che la specificano in modo restrittivo di solito richiedono una riprogettazione a metà del ciclo di vita per aggiungere funzionalità non previste dalla scheda originale.

Una corretta configurazione della scheda di controllo è fondamentale per il funzionamento affidabile del robot. Una scheda di controllo che non rispetta le tempistiche produce movimenti a scatti; una scheda di controllo che si blocca periodicamente produce un comportamento inaffidabile che nessuna regolazione delle periferiche può correggere.

Selezione di SoC, MCU e unità di calcolo per schede di controllo robot

Scegliere l'architettura di calcolo in base alla latenza, allo stack software e alla durata della fornitura.

Le opzioni relative a MCU, SoC, acceleratori AI, FPGA e processori x86 embedded devono essere valutate in base a tempistiche deterministiche, supporto del sistema operativo, ecosistema software, budget energetico, limiti termici, disponibilità dei package e rischi del ciclo di vita. Il processore più economico raramente è il più economico se impone la riprogettazione della scheda o compromessi a livello software.

La scelta tra SoC e MCU è la decisione più importante su una scheda di controllo robotica. Tale scelta determina la capacità di calcolo, la disponibilità di periferiche, il consumo energetico, il costo e la disponibilità a lungo termine. Le principali categorie utilizzate nella robotica sono:

• MCU Cortex-M4/M7: Sufficiente per il coordinamento del movimento puro e per applicazioni semplici. Basso consumo energetico, temporizzazione deterministica, nessun overhead di sistema operativo. Comune nei robot industriali e di servizio semplici dove la richiesta di potenza di calcolo è modesta.
• SoC di classe Cortex-A: Esegue Linux o RTOS. Sufficiente per applicazioni di media complessità con capacità di elaborazione modeste. Interfacce Ethernet, USB e per telecamera standard. Comune sulle piattaforme di controllo industriale.
• SoC acceleratore di intelligenza artificiale: Integra CPU e NPU o GPU. Gestisce la percezione, la fusione dei sensori e il calcolo a livello applicativo. Comune su robot umanoidi, autonomi e di servizio di alta gamma. Costo e carico termico più elevati.
• Sistema integrato x86: Hardware di classe PC industriale. Massima potenza di calcolo, ampio supporto software, ma costi più elevati e ingombro maggiore sulla scheda. Utilizzato laddove gli stack software esistenti richiedono architettura x86 o dove il budget termico lo consente.
• FPGA + MCU: Combinazione specializzata per l'elaborazione del segnale in tempo reale e il controllo generale. Utilizzata laddove la precisione temporale a frequenze elevate è più importante della flessibilità del software.

La disponibilità a lungo termine è un fattore cruciale nella scelta dei componenti di calcolo, un aspetto che raramente viene considerato nell'elettronica di consumo. Un robot con una vita utile di 10 anni necessita che il SoC o l'MCU rimangano disponibili per tale periodo, o quantomeno per la durata di una strategia di inventario "ultimo acquisto" documentata. Le famiglie di SoC con impegni di supporto a lungo termine definiti (componenti di livello industriale forniti da aziende leader con garanzie di disponibilità di 10-15 anni) preservano la manutenibilità; i componenti di livello consumer con cicli di vita brevi creano problemi di manutenzione in un secondo momento. I programmi che valutano il supporto a lungo termine già in fase di selezione del SoC evitano le riprogettazioni a metà ciclo di vita imposte dai componenti con disponibilità più limitata.

La scelta dipende dall'applicazione. Specificare un SoC sovradimensionato comporta costi e carico termico aggiuntivi per funzionalità non utilizzate dall'applicazione; specificarlo sottodimensionato costringe il team di sviluppo software a lottare con limiti di tempo e capacità. La guida alla ripartizione dei costi dei PCB per robot illustra le dimensioni di costo della scelta.

Interfacce di comunicazione: Ethernet, USB, Wi-Fi, CAN, seriale, SPI, I²C

La pianificazione dell'interfaccia dovrebbe includere la temporizzazione, la messa a terra e l'assistenza sul campo.

Le interfacce Ethernet, USB, Wi-Fi, CAN, SPI, I²C, RS-485 e per telecamere presentano diverse implicazioni elettriche e di servizio. La posizione del connettore, la protezione ESD, il percorso di ritorno, la lunghezza del cavo, la schermatura e la diagnostica sono importanti tanto quanto la semplice presenza dell'interfaccia nello schema.

Le interfacce di comunicazione su una scheda di controllo robotizzata includono in genere una combinazione di bus esterni e interni. Le interfacce esterne si connettono a reti, computer host e dispositivi utente; le interfacce interne si connettono a azionamenti per motori, sensori e schede periferiche. La configurazione tipica è la seguente:

• Ethernet: Gigabit standard per piattaforme ad alta intensità di calcolo; 100 Mbit per progetti con costi contenuti. Spesso due porte: una esterna, una interna per schede periferiche.
• USB: Porte host e device per accessori esterni, interfacce di servizio e, talvolta, periferiche di elaborazione. USB 3.x per applicazioni ad alto traffico dati.
• Wi-Fi e Bluetooth: Connettività wireless per robot mobili e robot di servizio al consumatore. Per una maggiore efficienza normativa, si prediligono moduli certificati.
• PUÒ: Comunicazione interna con azionamenti motore e schede periferiche. Robusta in ambienti elettricamente rumorosi; standard su piattaforme industriali e derivate dal settore automobilistico.
• RS-485 o RS-422: Comunicazione seriale con schede periferiche, talvolta per il supporto di sensori e attuatori preesistenti.
• SPI e I²C: Comunicazione periferica integrata con sensori locali e piccoli circuiti integrati. Non adatta per segnali trasmessi via cavo.

La scelta tra connessione cablata e wireless dipende dall'ambiente operativo del robot. I robot industriali in installazioni fisse utilizzano in genere Ethernet come interfaccia esterna principale; i robot mobili utilizzano Wi-Fi o rete cellulare; i robot per l'assistenza clienti utilizzano la soluzione più adatta alle esigenze dell'utente. I programmi spesso offrono entrambe le opzioni, cablata e wireless, sulla stessa scheda, poiché diversi scenari di implementazione richiedono interfacce differenti. Il costo della distinta base per l'aggiunta del wireless a una scheda che già dispone di Ethernet è modesto, mentre la flessibilità che ne deriva è notevole.

Interfaccia periferica: azionamento motore, sensore, I/O di sicurezza, interfaccia utente

Gli I/O periferici dovrebbero separare le funzioni di sicurezza, movimento e comodità.

I comandi di azionamento del motore, gli ingressi dell'encoder, i dispositivi di sicurezza, i pulsanti dell'interfaccia utente e i sensori ausiliari non devono essere trattati come I/O intercambiabili. I percorsi di sicurezza e di movimento richiedono un comportamento deterministico e una copertura diagnostica; le funzioni di utilità possono tollerare un maggiore livello di astrazione. Il layout del PCB e l'architettura del firmware devono riflettere questa differenza.

Le interfacce per azionamenti motore, sensori e I/O di sicurezza definiscono cosa la scheda di controllo può integrare. Spesso, durante lo sviluppo dei programmi per robot, ci si accorge in ritardo che la connettività periferica non è stata pianificata a sufficienza; adattare il set di interfacce ai requisiti delle periferiche in fase di progettazione evita modifiche successive. Le considerazioni principali sono:

• Comando di azionamento del motore: Comunicazione tramite CAN, EtherCAT o seriale proprietaria verso ciascuna unità. La scelta del bus è determinata dalla frequenza di loop e dai requisiti di latenza.
• Feedback dell'encoder: A volte il segnale viene inviato direttamente sulla scheda di controllo, altre volte viene instradato tramite azionamenti per motori. La scelta dipende dalla frequenza di ripetizione e dai requisiti di precisione.
• Lettura del sensore: Lettura analogica per sensori di base; lettura digitale per sensori intelligenti. La scheda di interfaccia del sensore alleggerisce notevolmente il carico di lavoro su piattaforme complesse.
• I/O di sicurezza: Arresto di emergenza, input di sicurezza da dispositivi esterni. Doppio canale laddove l'architettura di sicurezza lo richieda.
• Interfaccia utente: Pulsanti, indicatori e connessioni per display per l'interazione locale con l'utente. Talvolta integrati sulla scheda di controllo, talvolta su una scheda UI separata.

La distinzione tra l'insieme di interfacce della scheda di controllo e quello delle schede periferiche è fondamentale sia in fase di progettazione che di produzione. La scheda di controllo ospita le interfacce principali; le schede periferiche convertono tali interfacce nel formato richiesto dalla loro specifica funzione. Questa suddivisione permette alla scheda di controllo di concentrarsi sul coordinamento e sull'elaborazione, consentendo al contempo alle schede periferiche di specializzarsi in base alle proprie funzioni. I programmi che concentrano troppe funzioni sulla scheda di controllo finiscono in genere per generare una scheda eccessivamente complessa e difficile da riprogettare; al contrario, una buona suddivisione produce schede in cui ogni scheda ha una chiara funzione.

Archiviazione, avvio, aggiornamento del firmware e avvio protetto

La strategia di aggiornamento del firmware influisce sui requisiti hardware del PCB.

Avvio protetto, archiviazione a doppia immagine, modalità di ripristino, accesso di debug, programmazione del numero di serie e archiviazione della calibrazione richiedono tutti decisioni hardware. I team che rimandano la strategia di aggiornamento all'integrazione del software spesso scoprono che il PCB non dispone della memoria, dei pin, dell'accesso per i test o della sequenza di alimentazione necessari per aggiornamenti sul campo affidabili.

Le meccaniche di archiviazione, avvio e aggiornamento del firmware influiscono sulla manutenibilità del robot durante l'intero ciclo di vita del prodotto. I robot commercializzati senza un'architettura di archiviazione adeguata incontrano difficoltà nell'aggiornamento del firmware durante il servizio. Le considerazioni principali sono:

• eMMC o SD: Memoria comune per piattaforme SoC di classe Linux. eMMC integrata per una maggiore affidabilità; SD utilizzata per progetti con costi contenuti e requisiti di affidabilità modesti.
• SSD esterno: Maggiore capacità e velocità. Comune nelle piattaforme autonome ad alto traffico dati, dove la registrazione e la mappatura richiedono un'elevata velocità di trasmissione.
• Firmware a doppia immagine: Due immagini firmware con commutazione automatica in caso di errore all'avvio. Procedura standard per i robot aggiornabili sul campo per evitare il blocco del sistema durante l'aggiornamento OTA.
• Avvio sicuro: Verifica crittografica della firma del firmware all'avvio. Standard sui prodotti regolamentati e sempre più comune sui prodotti commerciali per motivi di sicurezza.
• Configurazione persistente: Memoria non volatile per la configurazione del robot, la calibrazione e i dati per unità. EEPROM standard o regione flash riservata.

Il ripristino da aggiornamenti firmware non riusciti è una delle aree meno studiate nell'elettronica robotica. Un robot che si blocca durante un aggiornamento OTA si traduce in un costoso intervento di assistenza. La memoria flash a doppia immagine con commutazione predefinita in caso di errore di avvio previene questo tipo di guasto a un costo hardware contenuto: una seconda partizione flash e il codice di avvio per gestire la selezione dell'immagine. I programmi che integrano questa soluzione fin dalla fase di progettazione proteggono da questa modalità di guasto che altrimenti si verificherebbe durante campagne OTA su larga scala.

Considerazioni di progettazione specifiche per le schede di controllo dei robot

La disposizione della scheda di controllo deve bilanciare alta velocità, potenza e facilità di manutenzione.

Le moderne schede di controllo combinano memoria DDR, interfacce seriali ad alta velocità, regolatori di commutazione, moduli wireless, sensori, connettori e accesso per il debug. Una buona progettazione mantiene brevi i percorsi di ritorno, separa i segnali rumorosi da quelli sensibili, lascia punti di test accessibili e facilita la riparazione o la diagnostica quando il robot è in servizio.

Le considerazioni di progettazione specifiche per le schede di controllo dei robot combinano le pratiche generali dell'informatica embedded con i requisiti specifici della robotica. I programmi che seguono entrambe le categorie producono schede affidabili; i programmi che trattano i robot come sistemi embedded generici trascurano le problematiche specifiche della robotica. Le considerazioni chiave sono:

• Sequenziamento di potenza: È necessario definire un ordine preciso per l'alimentazione del SoC e delle periferiche durante le fasi di accensione e spegnimento. Errori di sequenza possono causare blocchi all'avvio o blocchi del sistema.
• Immunità EMI: La scheda di controllo deve respingere il rumore proveniente dagli azionamenti dei motori e dagli alimentatori switching adiacenti. Il filtraggio, la suddivisione del layout e la schermatura contribuiscono tutti a questo scopo.
• Design termico: La dissipazione del calore del SoC deve raggiungere un raffreddamento efficace senza surriscaldamento. Il fissaggio del dissipatore o il percorso del flusso d'aria devono essere progettati in concomitanza con il layout elettrico.
• Accesso di debug: Accesso di debug tramite JTAG, console UART o Ethernet per lo sviluppo e l'assistenza sul campo. Famiglie di connettori standard tra i prodotti per garantire uniformità.
• Rilevamento guasti: Timer watchdog, rilevatore di cali di tensione e monitoraggio dello stato di salute sulla scheda di controllo stessa. La scheda che gestisce il robot deve anche rilevare eventuali guasti.

I programmi che considerano la scheda di controllo come l'ultima scheda progettata spesso non tengono conto di problematiche di integrazione che sarebbero state facili da risolvere in precedenza. L'insieme delle interfacce della scheda di controllo limita le funzionalità delle altre schede. Le dimensioni meccaniche della scheda di controllo ne limitano l'alloggiamento nel robot. Il carico termico della scheda di controllo vincola la progettazione del sistema di raffreddamento. Progettare la scheda di controllo per prima, o almeno nelle prime fasi del ciclo di progettazione del sistema, fornisce alle altre schede un target di interfaccia stabile e previene riprogettazioni in fase avanzata.

Requisiti per la produzione, la programmazione e il collaudo delle schede di controllo dei robot

La produzione deve verificare l'avvio, la comunicazione e l'identità programmata.

Il test della scheda di controllo non è completo quando le saldature appaiono corrette. La produzione deve verificare le linee di alimentazione, la sequenza di avvio, l'accesso alla memoria, la versione del firmware, l'identità univoca, le interfacce principali e qualsiasi calibrazione a livello di scheda. Ciò garantisce che la scheda di controllo sia pronta per l'integrazione nel sistema.

Le considerazioni di produzione per le schede di controllo dei robot sono commisurate all'elevato mix di calcolo che esse gestiscono. Fanout BGA a passo fine, costruzione HDI, impedenza controllata su interfacce di memoria e comunicazione e programmazione del firmware in fase di assemblaggio sono tutti elementi presenti nella produzione delle schede di controllo. Le capacità di Highleap per la produzione di schede di controllo includono:

• Costruzione HDI: Multistrato con accumulo di microvia dove richiesto il fanout BGA. Capacità 1-N-1 attraverso qualsiasi strato. Descritto nella pagina della guida alla progettazione di PCB HDI per la robotica.
• Impedenza controllata: ±10% di tolleranza standard, tolleranza più precisa su richiesta. Verifica dell'impedenza per lotto in fase di produzione.
• SMT a passo fine: Supporto per BGA da 0.4 mm e componenti passivi 01005. Discipline di processo che includono SPI, AOI e ispezione a raggi X.
• Programmazione del firmware: Caricamento del firmware del cliente in fase di assemblaggio. Supporto per numero di serie e dati di calibrazione per singola unità.
• Test funzionale: con firmware e dispositivi forniti dal cliente. Copertura di test specifica per la scheda, adattata al progetto.
• tracciabilità: Dati di prova per unità e registri dei lotti dei componenti a supporto delle richieste di certificazione del cliente.

La produzione di schede di controllo presso Highleap copre il mix tecnologico utilizzato nelle moderne schede di controllo per robot: costruzione HDI per il fanout BGA, impedenza controllata per le interfacce di memoria e comunicazione, piani di alimentazione su scala SoC per l'elaborazione e SMT a passo fine per i piccoli componenti passivi che una moderna scheda di controllo ospita a centinaia. La programmazione del firmware in fase di assemblaggio con supporto per i dati di calibrazione per unità mantiene la linea di assemblaggio come punto di integrazione naturale per la personalizzazione a livello di unità.

Domande frequenti sulla scheda di controllo del robot (PCB).

Che cos'è una scheda di controllo per robot (PCB)?

La scheda di controllo PCB di un robot è la principale scheda elettronica che esegue il software applicativo, coordina gli azionamenti dei motori, legge i sensori, gestisce la comunicazione, memorizza la configurazione e supervisiona il comportamento del sistema.

Una scheda di controllo per robot dovrebbe utilizzare un microcontrollore (MCU) o un SoC?

Utilizzate un MCU quando sono sufficienti il ​​controllo deterministico, il basso consumo energetico e un software più semplice. Utilizzate un SoC quando il robot necessita di software di livello Linux, percezione, rete, interfaccia utente, registrazione dati o maggiore potenza di calcolo. Alcuni robot utilizzano entrambi: un MCU per il controllo in tempo reale e un SoC per l'elaborazione delle applicazioni.

Quali interfacce sono comuni sulle schede di controllo dei robot?

Le interfacce comuni includono Ethernet, USB, Wi-Fi, Bluetooth, CAN, RS-485, SPI, I²C, UART, telecamera MIPI, LVDS, GPIO, ingressi encoder, I/O di sicurezza, porte di debug e connettori di espansione. La combinazione esatta dipende dall'architettura del robot.

Perché le schede di controllo dei robot necessitano di impedenza controllata?

L'impedenza controllata è necessaria per le memorie ad alta velocità, Ethernet, USB, PCIe, i collegamenti delle telecamere, LVDS e altre interfacce veloci. Essa mantiene le riflessioni del segnale e gli errori di temporizzazione entro limiti accettabili e deve essere specificata per ciascuna interfaccia.

Quali sono gli errori più comuni nella progettazione della scheda di controllo del robot?

Tra gli errori più comuni si annoverano percorsi di ritorno inadeguati, masse miste rumorose e sensibili, pianificazione insufficiente del piano di alimentazione, punti di debug inaccessibili, protezione ESD debole, posizionamento dei connettori in conflitto con i cavi e percorsi termici inadeguati per SoC o regolatori di potenza.

Come si dovrebbe gestire la programmazione del firmware durante l'assemblaggio di schede a circuito stampato (PCBA)?

La programmazione del firmware deve includere l'immagine corretta, il record di versione, la verifica della programmazione, il numero di serie univoco o l'indirizzo MAC ove necessario, l'acquisizione dei dati di calibrazione e un metodo di ripristino in caso di errore di programmazione.

Le schede di controllo dei robot necessitano di un avvio protetto?

L'avvio protetto è prezioso quando il robot è connesso in rete, ha funzioni di sicurezza, può essere aggiornato sul campo o è impiegato commercialmente. Contribuisce a impedire l'esecuzione di firmware non autorizzato, ma richiede hardware compatibile, una gestione delle chiavi e un processo di aggiornamento pianificato.

Quali test sono importanti per la produzione di schede di controllo per robot?

Tra i test più importanti figurano la verifica dell'alimentazione, il test di avvio, il test della memoria, la verifica del firmware, i controlli dell'interfaccia di comunicazione, i registri di programmazione, l'ispezione dell'interfaccia sensibile alle scariche elettrostatiche (ESD) e i test funzionali con periferiche rappresentative.