Comunicação entre processadores para braço robótico


13

Estou construindo um braço robótico hobby de 6 DOF e estou pensando qual é a melhor maneira de se comunicar entre os processadores (3-4 AVRs, separação máxima de 18 polegadas). Eu gostaria que o loop de controle fosse executado no computador, que envia comandos aos microprocessadores por meio de um Atmega32u4 USB-to - ??? ponte.

Algumas idéias que estou considerando:

  1. RS485
    • Prós: todos os processadores no mesmo fio, sinal diferencial mais robusto
    • Contras: requer chips adicionais, precisa escrever (ou encontrar?) Protocolo para impedir que os processadores transmitam ao mesmo tempo
  2. Loop UART (ou seja, TX de um processador está conectado ao RX do próximo)
    • Prós: firmware simples, os processadores têm o UART embutido
    • Contras: a última conexão precisa percorrer o comprimento do robô, cada processador precisa gastar ciclos retransmitindo mensagens
  3. CANbus (sei muito pouco sobre isso)

Minhas principais considerações são a complexidade de hardware e firmware, desempenho e preço (não consigo comprar um sistema pronto para uso).

Respostas:


13

Você deseja usar o USB para comunicação com o computador. Se você possui vários microcontroladores, provavelmente conectará apenas um dos microcontroladores diretamente ao computador. Os outros microcontroladores precisarão obter seus comandos do microcontrolador principal.

A comunicação que você escolher dependerá de vários fatores:

  • largura de banda necessária (assumiremos que você as esteja executando a 16 MHz)
  • complexidade (fiação e codificação)
  • bidirecional ou escravo mestre

Quase todas as opções têm suporte embutido no microcontrolador AVR. Não há opção que você possa razoavelmente preferir às opções internas que exigiriam hardware adicional. Como eles têm suporte embutido, a complexidade do software é semelhante, basta configurar a porta (usando registros), colocar os dados para transmitir em outro registro e acionar a transmissão, definindo um pouco em outro registro. Todos os dados recebidos são encontrados em outro registro e uma interrupção é acionada para que você possa lidar com isso. Qualquer que seja a opção escolhida, a única diferença é a alteração nos locais dos registros e algumas alterações nos registros de configuração.


Um loop USART possui os seguintes recursos:

  • Taxa de transmissão máxima de CLK / 16 = 1MHz (no relógio de 16MHz), que é uma taxa de transferência de cerca de 90KB / s
  • comunicações totalmente bidirecionais (sem designação de mestre ou escravo)
  • requer fios separados entre cada par de microcontroladores - o Atmega32u4 suporta duas portas USART de forma nativa, limitando o número de microcontroladores que você pode conectar em uma rede na prática (ou você acaba com uma longa série de microcontroladores - ou seja, conectado em uma lista vinculada maneira)

Nota: isto também é o que você usaria para obter a comunicação RS232, exceto que, como o RS232 requer 10V, é necessário um driver para obter esses níveis de tensão. Para comunicação entre microcontroladores, isso não é útil (apenas os níveis de tensão são alterados).

RS485:

  • Essencialmente, você usa a porta USART em um modo diferente - não há vantagem na largura de banda, e isso pode simplificar apenas ligeiramente a fiação, mas também a complica. Isto não é recomendado.

Interface de dois fios:

  • Isso também é conhecido como I2C. Isso significa que todos os dispositivos compartilham os mesmos dois fios.

  • Você precisa de um resistor pull-up nos dois fios

  • É lento (porque os resistores de pull-up são limitados em valor, e há capacitância crescente à medida que o número de dispositivos aumenta e o comprimento do fio aumenta). Para este microcontrolador AVR, a velocidade é de até 400 kHz - mais lenta que o USART (mas essa velocidade depende da limitação de sua capacitância). O motivo é que, embora um dispositivo reduza o fio de dados, a transição oposta é realizada deixando o fio flutuar alto novamente (o resistor de pull-up).

  • É ainda mais lento quando você considera que TODA a comunicação compartilha a mesma largura de banda limitada. Como toda comunicação compartilha a mesma largura de banda limitada, pode haver atrasos na comunicação em que os dados devem esperar até que a rede esteja ociosa antes de poder ser enviada. Se outros dados estiverem sendo enviados constantemente, também poderá impedir que eles sejam enviados.

  • Ele depende de um protocolo mestre-escravo, em que um mestre endereça um escravo, envia um comando / solicitação e o escravo responde posteriormente. Somente um dispositivo pode se comunicar por vez, portanto, o escravo deve aguardar a conclusão do mestre.

  • Qualquer dispositivo pode atuar como mestre e / ou escravo, tornando-o bastante flexível.

SPI

  • É isso que eu recomendaria / utilizaria para a comunicação geral entre microcontroladores.

  • É alta velocidade - até CLK / 2 = 8MHz (para CLK a 16MHz), tornando-o o método mais rápido. Isso é possível devido ao seu fio separado exclusivamente para o relógio.

  • Os fios MOSI, MISO, dados e SCK clock são compartilhados em toda a rede, o que significa que possui uma fiação mais simples.

  • É um formato mestre-escravo, mas qualquer dispositivo pode ser um mestre e / ou escravo. No entanto, devido às complicações de seleção do escravo, para a fiação compartilhada (dentro da rede), você deve usá-lo apenas de maneira hierárquica (ao contrário da interface de dois fios). IE. se você organizar todos os dispositivos em uma árvore, um dispositivo deve ser mestre apenas para seus filhos e apenas um escravo para seus pais. Isso significa que, no modo escravo, um dispositivo sempre terá o mesmo mestre. Além disso, para fazer isso corretamente, você precisa adicionar resistores ao MISO / MOSI / SCK ao mestre upstream, para que, se o dispositivo estiver se comunicando a jusante (quando não selecionado como escravo), as comunicações não afetarão as comunicações em outras partes do a rede (observe que o número de níveis que você pode fazer isso usando resistores é limitado; veja abaixo a melhor solução usando as duas portas SPI).

    O microcontrolador AVR pode tri-state automaticamente o sinal MOSI quando é selecionado como escravo e alternar para o modo escravo (se estiver no mestre).

    Embora possa exigir uma rede hierárquica, a maioria das redes pode ser organizada de maneira semelhante a uma árvore, portanto, geralmente não é uma limitação importante

  • O item acima pode ser relaxado um pouco, porque cada microcontrolador AVR suporta duas portas SPI separadas, para que cada dispositivo possa ter posições diferentes em duas redes diferentes.

    Dito isto, se você precisar de muitos níveis em sua árvore / hierarquia (mais de 2), a solução acima usando resistores fica muito complicada para funcionar. Nesse caso, você deve alterar a rede SPI entre cada camada da árvore. Isso significa que cada dispositivo se conectará a seus filhos em uma rede SPI e a seus pais na outra rede SPI. Embora isso signifique que você tenha apenas uma única árvore de conexões, a vantagem é que um dispositivo pode se comunicar com um de seus filhos e seu pai ao mesmo tempo e você não possui resistores complicados (sempre é difícil escolher os valores certos) .

  • Por possuir fios MOSI e MISO separados, o mestre e o escravo podem se comunicar ao mesmo tempo, proporcionando um fator potencial de dois aumentos na velocidade. Um pino extra é necessário para a seleção de escravos para cada escravo adicional, mas isso não é um fardo pesado, mesmo 10 escravos diferentes requerem apenas 10 pinos extras, que podem ser facilmente acomodados em um microcontrolador AVR típico.

O CAN não é suportado pelo microcontrolador AVR que você especificou. Como existem outras boas opções, provavelmente não é importante neste caso.


A recomendação é SPI , porque é rápida, a fiação não é muito complexa e não requer resistores de pull-up complicados. No raro caso em que o SPI não atende totalmente às suas necessidades (provavelmente em redes mais complicadas), você pode usar várias opções (por exemplo, usar as duas portas SPI, juntamente com a interface de dois fios, além de emparelhar alguns dos microcontroladores usando um loop USART!)

No seu caso, usar SPI significa que, naturalmente, o microcontrolador com a conexão USB ao computador pode ser o mestre e pode apenas encaminhar os comandos relevantes do computador para cada dispositivo escravo. Ele também pode ler as atualizações / medidas de cada escravo e enviá-las ao computador.

Com 8MHz e 0,5m de comprimento de fio, não acho que isso se tornará um problema. Mas, se for, tente ter mais cuidado com a capacitância (mantenha os fios de aterramento e de sinal muito próximos e também com as conexões entre os diferentes condutores) e também a terminação do sinal. No caso improvável de continuar sendo um problema, você pode reduzir a taxa de clock, mas não acho que seja necessário.


Thumbs up for SPI from me
georgebrindeiro

2
Também sou fã de SPI, apesar de talvez também valha a pena considerar o I2C (evita a necessidade de linhas CS separadas para cada dispositivo). Mas o CAN não deve ser tão facilmente descartado - afinal, é o ônibus automotivo preferido, então eu não descartaria isso na robótica por hobby!
Andrew

O barramento SPI realmente exige linhas CS separadas do mestre para cada escravo? Nesse caso, como você chamaria esse outro barramento que exige exatamente 4 conexões com o mestre, não importa quantos escravos estejam conectados, isso é mencionado no artigo da Wikipedia sobre barramento SPI ?
David Cary

1
+1 Para a grande resposta, sou da velha escola e amo os 485 e geralmente os ônibus com endereço de software, mas, neste caso, componentes de velocidade e consumo de recursos, escolheria o SPI. Embora você teria muita atenção a distância e ruído elétrico, especialmente se o seu ônibus coesisten outro IC, com diferentes velocidades de transmissão: memórias, NIC, etc., que poderia sofrer quedas e amplitude perda relógio
RTOSkit

3
Seus comentários sobre o CAN não são precisos. O CAN não é apenas um barramento de 2 fios. Eu acho que você está confundindo com o I2C, que tem uma velocidade máxima de 400kbps. A velocidade máxima da CAN é de 1 Mbps.
Rocketmagnet

5

Eu recomendo o CAN para comunicações entre processadores. Nós o usamos em nossos robôs, com até 22 processadores no mesmo barramento. Com um bom design de protocolo, você pode usar cerca de 90% da largura de banda disponível (cerca de 640kbps quando leva em consideração toda a verificação de erros e espaçamento entre quadros). Somos capazes de servir 10 motores a 1000Hz em um barramento CAN. Isso está se aproximando do limite. Você provavelmente poderia comprimir para 20 motores se você compactar os dados com muito cuidado.

Geralmente, a CAN precisa ter um chip transceptor para cada processador (é apenas um pequeno dispositivo de 8 pinos). O transceptor fornece o bom sinal diferencial que emite muito pouca interferência e também o torna imune a interferências se você estiver trabalhando em um ambiente eletricamente barulhento (motores, solenóides e transmissores de rádio).

Conexões de barramento CAN

No entanto, em circunstâncias limitadas, é realmente possível usar o CAN sem transceptores .


EtherCAT

Se você quiser implementar um barramento com largura de banda séria, sugiro que tente o EtherCAT . É um barramento de 100Mb, que pode ser conectado à porta Ethernet do seu PC. Existem duas partes importantes no ônibus:

  • A Ponte. Isso converte a camada física da Ethernet em uma camada física LVDS mais simples e de baixo custo, que não requer conectores grandes, chip Phy e muitos componentes que a própria Ethernet exige.
  • Os nós. Cada nó precisa apenas de um chip ET1200 e de um microcontrolador.

O PC pode transmitir e receber grandes quantidades de dados de e para os nós a 1kHz ou mais rápido. Você pode controlar várias coisas em um único barramento EtherCAT.

Adicionado:

A Shadow Robot Company agora vende um sistema EtherCAT Bus útil chamado Ronex . Permite adicionar bastante E / S e, em breve, eles apresentarão muitos outros tipos de placas, como controladores de motor e ADCs de alta qualidade.


Qual é a fonte dessa imagem? Tem CAN Highpara fios vermelhos e azuis.
31413 Ian

1

Eu sei que estou desenterrando um tópico antigo e isso é meio fora de tópico, mas acho que você não pode simplesmente pegar os chips ET1200 da Beckhoff. Enviei-lhes um e-mail há um tempo e fui avisado de que precisava ingressar no grupo Ethercat. Para fazer isso, tive que demonstrar que iria contribuir de volta para o grupo - ou seja, construindo e vendendo dispositivos que usavam o material Ethercat. Nesse momento (e neste), ainda estou fazendo a prototipagem do meu dispositivo (um controlador de motor sem escovas para aplicações de robôs - atualmente usando CAN), então não pude oferecer nada (não posso dar um tempo sólido para a conclusão - ainda estou trabalhando no meu graduação). Expressei a eles minha decepção. Eles disseram para não ficar desapontado !! Coisas bem engraçadas! Eu gostaria realmentegostaria de entrar no Ethercat, mas os ASICs parecem intocáveis ​​para os entusiastas ou aqueles sem uma empresa. Além disso, este é o meu primeiro post, então peço desculpas se eu irritei os deuses desenterrando um post antigo!


Bem-vinda. Ressuscitar uma postagem antiga é bom, se a resposta for relevante. E seu comentário parece relevante para mim ...
Andrew

Obrigado companheiro. Este é um ótimo forúm! Por interesse, você tem alguma experiência com o Ethercat? Você conhece outros métodos para obter um dispositivo escravo adequado para prototipagem em PCBs? Estou disposto a pagar, mas no momento simplesmente não atendo aos requisitos para ingressar no grupo e comprar os ASICs da Bechoff. Frustrante!
lei

Não EtherCat, não. Eu uso CAN (uma boa opção), LIN (não tão bom IMHO) e certamente pode recomendar SPI ou I2C
Andrew

Você conseguiu segurar o chip ET1100 ou ET1200? Se você não tiver outra opção disponível agora: o microchip LAN9252, é compatível com o ET1100 e funciona muito bem. Use os cumprimentos da biblioteca SOES
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.