Comunicazione tra processori per braccio robotico


13

Sto costruendo un braccio robotico 6-DOF per hobby e mi chiedo quale sia il modo migliore per comunicare tra i processori (3-4 AVR, separazione massima di 18 pollici). Mi piacerebbe avere il ciclo di controllo eseguito sul computer, che invia comandi ai microprocessori tramite un USB Atmega32u4 a - ??? ponte.

Alcune idee che sto prendendo in considerazione:

  1. RS485
    • Pro: tutti i processori sullo stesso filo, segnale differenziale più robusto
    • Contro: richiede chip aggiuntivi, è necessario scrivere (o trovare?) Protocollo per impedire la trasmissione simultanea dei processori
  2. UART loop (ovvero, TX di un processore è collegato a RX del successivo)
    • Pro: firmware semplice, i processori hanno UART integrato
    • Contro: l'ultima connessione deve percorrere la lunghezza del robot, ogni processore deve impiegare cicli a ritrasmettere i messaggi
  3. CANbus (ne so molto poco)

Le mie considerazioni principali sono la complessità, le prestazioni e il prezzo dell'hardware e del firmware (non riesco a comprare un costoso sistema pronto all'uso).

Risposte:


13

Si desidera utilizzare USB per le comunicazioni con il computer. Se si dispone di un numero di microcontrollori, probabilmente si collegherà solo uno dei microcontrollori direttamente al computer. Gli altri microcontrollori dovranno ottenere i loro comandi dal microcontrollore principale.

La comunicazione scelta dipenderà da una serie di fattori:

  • larghezza di banda richiesta (supponiamo che tu li stia eseguendo a 16 MHz)
  • complessità (cablaggio e codifica)
  • bidirezionale o master-slave

Quasi tutte le opzioni hanno il supporto integrato sul microcontrollore AVR. Non esiste alcuna opzione che potresti ragionevolmente preferire rispetto alle opzioni integrate che richiederebbero hardware aggiuntivo. Poiché hanno il supporto integrato, la complessità del software è simile, in quanto basta configurare la porta (usando i registri), mettere i dati per trasmettere in un altro registro, quindi innescare la trasmissione impostando un bit in un altro registro. Tutti i dati ricevuti vengono trovati in un altro registro e viene attivato un interrupt in modo da poterli gestire. Qualunque opzione scegliate, l'unica differenza è la modifica delle posizioni dei registri e alcune modifiche ai registri di configurazione.


Un loop USART ha le seguenti caratteristiche:

  • Baud rate massimo di CLK / 16 = 1MHz (con clock a 16MHz) che è una velocità di trasferimento di circa 90KB / s
  • comunicazioni completamente bidirezionali (nessuna designazione master o slave)
  • richiede fili separati tra ciascuna coppia di microcontrollori: Atmega32u4 supporta due porte USART in modo nativo, limitando il numero di microcontrollori che è possibile collegare in una rete in pratica (oppure si finisce con una lunga serie di microcontrollori - ovvero collegati in un elenco collegato maniera)

Nota: questo è anche ciò che useresti per ottenere la comunicazione RS232, tranne per il fatto che RS232 richiede 10 V, richiede un driver per ottenere quei livelli di tensione. Per la comunicazione tra microcontrollori, questo non è utile (vengono modificati solo i livelli di tensione).

RS485:

  • In sostanza, si utilizza la porta USART in una modalità diversa: non vi è alcun vantaggio in termini di larghezza di banda e può solo semplificare leggermente il cablaggio, ma anche complicarlo. Questo non è raccomandato

Interfaccia a due fili:

  • Questo è anche indicato come I2C. Ciò significa che tutti i dispositivi condividono gli stessi due fili.

  • È necessaria una resistenza di pull-up su entrambi i fili

  • È lento (poiché i resistori di pull-up hanno un valore limitato e vi è una capacità crescente all'aumentare del numero di dispositivi e alla lunghezza del filo). Per questo microcontrollore AVR, la velocità è fino a 400 kHz - più lenta di USART (ma questa velocità dipende dalla limitazione della capacità). Il motivo è che sebbene un dispositivo spinga il filo dati in basso, la transizione opposta si ottiene lasciando il filo fluttuare nuovamente in alto (la resistenza di pull-up).

  • È ancora più lento se si considera che TUTTE le comunicazioni condividono la stessa larghezza di banda limitata. Poiché tutte le comunicazioni condividono la stessa larghezza di banda limitata, potrebbero esserci ritardi nella comunicazione in cui i dati devono attendere fino a quando la rete non è inattiva prima di poter essere inviata. Se altri dati vengono costantemente inviati, è possibile che i dati non vengano mai inviati.

  • Si basa su un protocollo master-slave, in cui un master si rivolge a uno slave, quindi invia un comando / richiesta e lo slave risponde in seguito. Solo un dispositivo può comunicare alla volta, quindi lo slave deve attendere il completamento del master.

  • Qualsiasi dispositivo può agire sia come master che / o come slave, rendendolo abbastanza flessibile.

SPI

  • Questo è ciò che consiglierei / utilizzerei per la comunicazione generale tra i microcontrollori.

  • È ad alta velocità - fino a CLK / 2 = 8 MHz (per CLK a 16 MHz), rendendolo il metodo più veloce. Ciò è possibile grazie al suo filo separato esclusivamente per l'orologio.

  • I fili MOSI, MISO e clock SCK sono condivisi su tutta la rete, il che significa che ha un cablaggio più semplice.

  • È un formato master-slave, ma qualsiasi dispositivo può essere un master e / o uno slave. Tuttavia, a causa delle complicazioni della selezione dello slave, per il cablaggio condiviso (all'interno della rete), è necessario utilizzarlo solo in modo gerarchico (a differenza dell'interfaccia a due fili). IE. se organizzi tutti i dispositivi in ​​un albero, un dispositivo dovrebbe essere solo padrone dei suoi figli e solo uno schiavo del suo genitore. Ciò significa che in modalità slave, un dispositivo avrà sempre lo stesso master. Inoltre, per farlo correttamente, è necessario aggiungere resistori a MISO / MOSI / SCK al master upstream, in modo che se il dispositivo sta comunicando a valle (quando non è selezionato come slave), le comunicazioni non influenzeranno le comunicazioni in altre parti di la rete (notare che il numero di livelli che è possibile eseguire utilizzando resistori è limitato, vedere di seguito per una soluzione migliore utilizzando entrambe le porte SPI).

    Il microcontrollore AVR può automaticamente tri-state il segnale MOSI quando è selezionato slave e passare alla modalità slave (se nel master).

    Anche se potrebbe richiedere una rete gerarchica, la maggior parte delle reti può essere organizzata in modo ad albero, quindi di solito non è una limitazione importante

  • Quanto sopra può essere leggermente rilassato, poiché ciascun microcontrollore AVR supporta due porte SPI separate, quindi ogni dispositivo può avere posizioni diverse in due reti diverse.

    Detto questo, se hai bisogno di molti livelli nel tuo albero / gerarchia (più di 2), la soluzione sopra usando i resistori diventa troppo complicata per funzionare. In questo caso, è necessario modificare la rete SPI tra ciascun livello dell'albero. Ciò significa che ogni dispositivo si connetterà ai propri figli su una rete SPI e ai suoi genitori sull'altra rete SPI. Sebbene significhi che hai solo un singolo albero di connessioni, il vantaggio è che un dispositivo può comunicare sia con uno dei suoi figli che con il suo genitore allo stesso tempo e non hai resistori complicati (sempre difficile scegliere i giusti valori) .

  • Poiché ha fili MOSI e MISO separati, sia il master che lo slave possono comunicare contemporaneamente, dando un potenziale fattore di due aumenti di velocità. È necessario un pin aggiuntivo per la selezione slave per ogni slave aggiuntivo, ma questo non è un grosso carico, anche 10 diversi slave richiedono solo 10 pin extra, che possono essere facilmente alloggiati su un tipico microcontrollore AVR.

CAN non è supportato dal microcontrollore AVR specificato. Dato che ci sono altre buone opzioni, probabilmente non è comunque importante in questo caso.


La raccomandazione è SPI , perché è veloce, il cablaggio non è troppo complesso e non richiede resistenze pull-up complicate. Nel raro caso in cui SPI non soddisfi pienamente le tue esigenze (probabilmente in reti più complicate), puoi utilizzare più opzioni (ad es. Utilizzare entrambe le porte SPI, insieme all'interfaccia a due fili, nonché accoppiare alcuni dei microcontrollori usando un loop USART!)

Nel tuo caso, l'utilizzo di SPI significa che, naturalmente, il microcontrollore con la connessione USB al computer può essere il master e può semplicemente inoltrare i comandi pertinenti dal computer a ciascun dispositivo slave. Può anche leggere gli aggiornamenti / misurazioni da ogni slave e inviarli al computer.

A 8 MHz e 0,5 m di lunghezza del filo, non credo che diventerà un problema. In tal caso, provare a prestare maggiore attenzione alla capacità (tenere troppo vicini i fili di terra e del segnale e prestare attenzione anche ai collegamenti tra conduttori diversi), nonché alla terminazione del segnale. Nel caso improbabile che rimanga un problema, è possibile ridurre la frequenza di clock, ma non credo sia necessario.



2
Sono anche un fan di SPI, anche se forse vale la pena considerare anche I2C (evita la necessità di linee CS separate per ciascun dispositivo). Ma CAN non dovrebbe essere facilmente liquidato - dopo tutto, è l'autobus automobilistico preferito, quindi non lo escluderei per la robotica per hobby!
Andrew

Il bus SPI richiede davvero linee CS separate dal master a ogni slave? In tal caso, come chiameresti quell'altro bus che richiede esattamente 4 connessioni al master, indipendentemente dal numero di slave collegati, menzionato nell'articolo di Wikipedia sul bus SPI ?
David Cary,

1
+1 Per l'enorme risposta, sono vecchia scuola e adoro la 485 e generalmente gli autobus con indirizzo software, ma in questo caso, componenti di velocità e consumo di risorse, sceglierei SPI. Anche se avresti molta attenzione alla distanza e al rumore elettrico, specialmente se il tuo bus coesisten altri circuiti integrati, con velocità di trasmissione diverse: memorie, scheda di rete, ecc., Che potrebbero subire perdite di tempo e ampiezze di perdita di clock
RTOSkit

3
I tuoi commenti su CAN non sono accurati. CAN non è solo un bus a 2 fili. Penso che tu lo stia confondendo con I2C, che ha una velocità massima di 400kbps. La velocità massima di CAN è di 1 Mbps.
Rocketmagnet,

5

Consiglio vivamente CAN per le comunicazioni tra processori. Lo usiamo nei nostri robot, con un massimo di 22 processori sullo stesso bus. Con una buona progettazione del protocollo, è possibile utilizzare circa il 90% della larghezza di banda disponibile (circa 640 kbps quando si tiene conto di tutti i controlli degli errori e della spaziatura tra i frame). Siamo in grado di servo 10 motori a 1000Hz su un bus CAN. Questo si avvicina al limite. Probabilmente potresti comprimerlo su 20 motori se impacchi i dati con molta attenzione.

In genere CAN deve disporre di un chip ricetrasmettitore per ciascun processore (è solo un piccolo dispositivo a 8 pin). Il ricetrasmettitore fornisce il piacevole segnale differenziale che emette pochissime interferenze e lo rende immune alle interferenze se si lavora in un ambiente elettricamente rumoroso (motori, solenoidi e trasmettitori radio).

Collegamenti CAN Bus

Tuttavia, in circostanze limitate, è effettivamente possibile utilizzare CAN senza ricetrasmettitori .


EtherCAT

Se hai mai voglia di implementare un bus con una grande larghezza di banda, ti suggerisco di provare EtherCAT . È un bus da 100 Mb, che può essere collegato alla porta Ethernet del tuo PC. Ci sono due parti importanti per l'autobus:

  • Il ponte. Ciò converte il livello fisico Ethernet in un livello fisico LVDS più semplice ea basso costo, che non richiede connettori di grandi dimensioni, chip Phy e molti componenti che Ethernet stesso fa.
  • I nodi. Ogni nodo richiede solo un chip ET1200 e un microcontrollore.

Il PC può trasmettere e ricevere grandi quantità di dati da e verso i nodi a 1kHz o più velocemente. Puoi controllare molte cose su un singolo bus EtherCAT.

Inserito il:

Shadow Robot Company ora vende un utile sistema EtherCAT Bus chiamato Ronex . Ti consente di aggiungere un sacco di I / O e presto introdurranno molti altri tipi di schede, come i controller dei motori e gli ADC di alta qualità.


Qual è la fonte per quell'immagine? Ha sia CAN Highper i fili rossi che blu.
Ian

1

So che sto scavando un vecchio thread e questo è un po 'fuori tema, ma non penso che tu possa semplicemente ottenere chip ET1200 da Beckhoff. Li ho inviati un po 'di tempo fa e mi è stato consigliato di unirmi al gruppo Ethercat. Per fare questo ho dovuto dimostrare che avrei contribuito al gruppo, ovvero creando e vendendo dispositivi che utilizzavano gli Ethercat. A quel punto (e questo) nel tempo, sto ancora prototipando il mio dispositivo (un controller di motore brushless per applicazioni robot - attualmente sto usando CAN) quindi non potevo offrire nulla (non posso dare un tempo solido per il completamento - Sto ancora lavorando sul mio undergrad). Ho espresso loro la mia delusione. Hanno detto di non essere delusi !! Roba abbastanza divertente! Lo farei davveropiace entrare in Ethercat, ma gli ASIC sembrano intoccabili per gli hobbisti o per quelli senza compagnia. Inoltre, questo è il mio primo post, quindi mi scuso se ho fatto arrabbiare gli dei scavando un vecchio post!


Benvenuto. Risuscitare un vecchio post va bene, se la risposta è pertinente. E il tuo commento mi sembra rilevante ...
Andrew

Grazie compagno. Questo è un grande forum! Per interesse, hai qualche esperienza con Ethercat? Conosci qualche altro metodo per ottenere un dispositivo slave adatto alla prototipazione su PCB? Sono disposto a pagare, ma al momento semplicemente non ho i requisiti per unirmi al gruppo per acquistare gli ASIC Bechoff. Frustrante!
legge

Non EtherCat, no. Uso CAN (una buona opzione), LIN (non così buono IMHO) e posso sicuramente raccomandare SPI o I2C
Andrew

Sei riuscito a mettere in attesa il chip ET1100 o ET1200? Se non è disponibile ora un'altra opzione: microchip LAN9252, è compatibile con ET1100 e funziona abbastanza bene. Usa i saluti della libreria SOES
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.