Communication entre processeurs pour bras robotique

Je construis un bras robotique hobby 6 DOF et je me demande quelle est la meilleure façon de communiquer entre les processeurs (3-4 AVR, séparation maximale de 18 pouces). J'aimerais que la boucle de contrôle s'exécute sur l'ordinateur, qui envoie des commandes aux microprocesseurs via une clé USB Atmega32u4 - ??? pont.

Quelques idées que j'envisage:

1. RS485
   • Avantages: tous les processeurs sur le même fil, signal différentiel plus robuste
   • Inconvénients: nécessite des puces supplémentaires, besoin d'écrire (ou de trouver?) Un protocole pour empêcher les processeurs de transmettre en même temps
2. Boucle UART (c'est-à-dire que le TX d'un processeur est connecté au RX du suivant)
   • Avantages: firmware simple, les processeurs ont UART intégré
   • Inconvénients: la dernière connexion doit parcourir la longueur du robot, chaque processeur doit passer des cycles à retransmettre les messages
3. CANbus (j'en sais très peu à ce sujet)

Mes principales considérations sont la complexité du matériel et du micrologiciel, les performances et le prix (je ne peux pas acheter un système prêt à l'emploi coûteux).

Vous souhaitez utiliser l'USB pour les communications avec l'ordinateur. Si vous disposez d'un certain nombre de microcontrôleurs, vous ne connecterez probablement qu'un seul des microcontrôleurs directement à l'ordinateur. Les autres microcontrôleurs devront obtenir leurs commandes du microcontrôleur principal.

La communication que vous choisissez dépendra d'un certain nombre de facteurs:

• bande passante requise (nous supposerons que vous les exécutez à 16 MHz)
• complexité (câblage et codage)
• bidirectionnel ou maître-esclave

Presque toutes les options ont un support intégré sur le microcontrôleur AVR. Il n'y a aucune option que vous pourriez raisonnablement préférer aux options intégrées qui nécessiteraient du matériel supplémentaire. Parce qu'ils ont un support intégré, la complexité du logiciel est similaire, en ce sens que vous configurez simplement le port (à l'aide de registres), placez les données à transmettre dans un autre registre, puis déclenchez la transmission en définissant un bit dans un autre registre. Toutes les données reçues se trouvent dans un autre registre et une interruption est déclenchée pour que vous puissiez les gérer. Quelle que soit l'option que vous choisissez, la seule différence est la modification de l'emplacement des registres et certaines modifications des registres de configuration.

Une boucle USART présente les caractéristiques suivantes:

• Débit en bauds maximal de CLK / 16 = 1 MHz (à une horloge de 16 MHz), ce qui correspond à un taux de transfert d'environ 90 Ko / s
• communications entièrement bidirectionnelles (pas de désignation maître ou esclave)
• nécessite des fils séparés entre chaque paire de microcontrôleurs - l'Atmega32u4 prend en charge deux ports USART nativement, limitant le nombre de microcontrôleurs que vous pouvez connecter dans un réseau en pratique (ou bien vous vous retrouvez avec une longue chaîne de microcontrôleurs - c'est-à-dire connectés dans une liste liée manière)

Remarque: c'est également ce que vous utiliseriez pour obtenir une communication RS232, sauf que parce que RS232 nécessite 10 V, il nécessite un pilote pour obtenir ces niveaux de tension. Pour la communication entre microcontrôleurs, cela n'est pas utile (seuls les niveaux de tension sont modifiés).

RS485:

• Essentiellement, vous utilisez le port USART dans un mode différent - il n'y a aucun avantage dans la bande passante, et cela peut seulement simplifier légèrement le câblage, mais cela le complique également. Ce n'est pas recommandé.

Interface à deux fils:

• Ceci est également appelé I2C. Cela signifie que tous les appareils partagent les deux mêmes fils.

• Vous avez besoin d'une résistance de rappel sur les deux fils

• Il est lent (car les résistances de rappel sont de valeur limitée et la capacité augmente à mesure que le nombre d'appareils augmente et que la longueur du fil augmente). Pour ce microcontrôleur AVR, la vitesse est jusqu'à 400 kHz - plus lente que USART (mais cette vitesse dépend de la limitation de votre capacité). La raison en est que, bien qu'un appareil entraîne le fil de données à un niveau bas, la transition inverse est accomplie en laissant le fil flotter à nouveau haut (la résistance de rappel).

• Il est encore plus lent si l'on considère que TOUTES les communications partagent la même bande passante limitée. Étant donné que toutes les communications partagent la même bande passante limitée, il peut y avoir des retards de communication où les données doivent attendre que le réseau soit inactif avant de pouvoir être envoyées. Si d'autres données sont constamment envoyées, cela peut également empêcher leur envoi.

• Il repose sur un protocole maître-esclave, où un maître s'adresse à un esclave, puis envoie une commande / demande, et l'esclave répond ensuite. Un seul appareil peut communiquer à la fois, l'esclave doit donc attendre la fin du maître.

• Tout appareil peut agir à la fois comme maître et / ou esclave, ce qui le rend assez flexible.

SPI

• C'est ce que je recommanderais / utiliserais pour la communication générale entre les microcontrôleurs.

• C'est une vitesse élevée - jusqu'à CLK / 2 = 8 MHz (pour CLK à 16 MHz), ce qui en fait la méthode la plus rapide. Ceci est réalisable en raison de son fil séparé uniquement pour l'horloge.

• Les fils d'horloge MOSI, MISO et SCK sont partagés sur l'ensemble du réseau, ce qui signifie qu'il a un câblage plus simple.

• Il s'agit d'un format maître-esclave, mais tout appareil peut être maître et / ou esclave. Cependant, en raison des complications de sélection de l'esclave, pour le câblage partagé (au sein du réseau), vous ne devez l'utiliser que de manière hiérarchique (contrairement à l'interface à deux fils). C'EST À DIRE. si vous organisez tous les périphériques dans une arborescence, un périphérique ne doit être maître que pour ses enfants et uniquement esclave pour son parent. Cela signifie qu'en mode esclave, un appareil aura toujours le même maître. De plus, pour le faire correctement, vous devez ajouter des résistances à MISO / MOSI / SCK au maître en amont, de sorte que si l'appareil communique en aval (lorsqu'il n'est pas sélectionné comme esclave), les communications n'affecteront pas les communications dans d'autres parties de le réseau (notez que le nombre de niveaux que vous pouvez faire en utilisant des résistances est limité, voir ci-dessous pour une meilleure solution en utilisant les deux ports SPI).

  Le microcontrôleur AVR peut automatiquement tri-état le signal MOSI quand il est sélectionné esclave, et passer en mode esclave (s'il est en maître).

  Même si cela peut nécessiter un réseau hiérarchique, la plupart des réseaux peuvent être organisés de manière arborescente, donc ce n'est généralement pas une limitation importante

• Ce qui précède peut être légèrement assoupli, car chaque microcontrôleur AVR prend en charge deux ports SPI distincts, de sorte que chaque appareil peut avoir des positions différentes dans deux réseaux différents.

  Cela dit, si vous avez besoin de plusieurs niveaux dans votre arborescence / hiérarchie (plus de 2), la solution ci-dessus utilisant des résistances devient trop fastidieuse pour fonctionner. Dans ce cas, vous devez modifier le réseau SPI entre chaque couche de l'arborescence. Cela signifie que chaque appareil se connectera à ses enfants sur un réseau SPI et à son parent sur l'autre réseau SPI. Bien que cela signifie que vous n'avez qu'une seule arborescence de connexions, l'avantage est qu'un appareil peut communiquer à la fois avec l'un de ses enfants et son parent en même temps et vous n'avez pas de résistances fastidieuses (toujours difficile de choisir les bonnes valeurs) .

• Parce qu'il a des fils MOSI et MISO séparés, le maître et l'esclave peuvent communiquer en même temps, ce qui lui donne un facteur potentiel de deux augmentations de vitesse. Une broche supplémentaire est requise pour la sélection d'esclaves pour chaque esclave supplémentaire, mais ce n'est pas une lourde charge, même 10 esclaves différents ne nécessitent que 10 broches supplémentaires, qui peuvent être facilement hébergées sur un microcontrôleur AVR typique.

CAN n'est pas pris en charge par le microcontrôleur AVR que vous avez spécifié. Comme il existe d'autres bonnes options, ce n'est probablement pas important dans ce cas de toute façon.

La recommandation est SPI , car elle est rapide, le câblage n'est pas trop complexe et ne nécessite pas de résistances de tirage fastidieuses. Dans les rares cas où SPI ne répond pas entièrement à vos besoins (probablement dans des réseaux plus compliqués), vous pouvez utiliser plusieurs options (par exemple, utiliser les deux ports SPI, ainsi que l'interface à deux fils, ainsi que le couplage de certains microcontrôleurs). en utilisant une boucle USART!)

Dans votre cas, l'utilisation de SPI signifie que naturellement, le microcontrôleur avec la connexion USB à l'ordinateur peut être le maître, et il peut simplement transmettre les commandes pertinentes de l'ordinateur à chaque périphérique esclave. Il peut également lire les mises à jour / mesures de chaque esclave et les envoyer à l'ordinateur.

À 8 MHz et une longueur de fil de 0,5 m, je ne pense pas que cela deviendra un problème. Mais si c'est le cas, essayez de faire plus attention à la capacité (gardez les fils de terre et de signal trop proches, et faites également attention aux connexions entre les différents conducteurs), ainsi qu'à la terminaison du signal. Dans le cas peu probable où cela resterait un problème, vous pouvez réduire la fréquence d'horloge, mais je ne pense pas que ce soit nécessaire.

Je peux fortement recommander CAN pour les communications entre processeurs. Nous l'utilisons dans nos robots, avec jusqu'à 22 processeurs sur le même bus. Avec une bonne conception de protocole, vous pouvez utiliser jusqu'à environ 90% de la bande passante disponible (environ 640 kbps lorsque vous prenez en compte tous les contrôles d'erreur et l'espacement entre les trames). Nous pouvons asservir 10 moteurs à 1000 Hz sur un bus CAN. Cela approche la limite. Vous pourriez probablement le réduire à 20 moteurs si vous empaquetez les données très soigneusement.

Généralement, CAN doit avoir une puce d'émetteur-récepteur pour chaque processeur (c'est juste un petit appareil à 8 broches). L'émetteur-récepteur vous donne le joli signal différentiel qui émet très peu d'interférences, et le rend également insensible aux interférences si vous travaillez dans un environnement électriquement bruyant (moteurs, solénoïdes et émetteurs radio).

Cependant, dans des circonstances limitées, il est en fait possible d'utiliser CAN sans émetteur-récepteur .

Si jamais vous avez envie d'implémenter un bus avec une bande passante sérieuse, je vous suggère d'essayer EtherCAT . Il s'agit d'un bus de 100 Mo, qui peut être connecté au port Ethernet de votre PC. Le bus comporte deux parties importantes:

• Le pont. Cela convertit la couche physique Ethernet en une couche physique LVDS plus simple et moins coûteuse, qui ne nécessite pas les gros connecteurs, la puce Phy et de nombreux composants qu'Ethernet lui-même fait.
• Les nœuds. Chaque nœud n'a besoin que d'une puce ET1200 et d'un microcontrôleur.

Le PC peut transmettre et recevoir de gros morceaux de données vers et depuis les nœuds à 1 kHz ou plus. Vous pouvez contrôler beaucoup de choses sur un seul bus EtherCAT.

Ajoutée:

Shadow Robot Company vend maintenant un système de bus EtherCAT utile appelé Ronex . Cela vous permet d'ajouter beaucoup d'E / S, et ils vont bientôt introduire de nombreux autres types de cartes, comme des contrôleurs de moteur et des ADC de haute qualité.

Je sais que je déterre un vieux fil et c'est en quelque sorte hors sujet, mais je ne pense pas que vous puissiez simplement vous procurer les puces ET1200 de Beckhoff. Je leur ai envoyé un e-mail il y a quelque temps et on m'a informé que je devais rejoindre le groupe Ethercat. Pour ce faire, je devais démontrer que j'allais contribuer au groupe, c'est-à-dire en construisant et en vendant des appareils qui utilisaient le matériel Ethercat. À ce moment-là (et ce moment), je suis encore en train de prototyper mon appareil (un contrôleur de moteur sans balais pour les applications de robot - actuellement en utilisant CAN) donc je ne pouvais rien offrir (je ne peux pas donner un temps solide pour l'achèvement - Je travaille toujours sur mon premier cycle). Je leur ai fait part de ma déception. Ils ont dit de ne pas être déçus !! Des trucs assez drôles! Je voudrais vraimentaiment entrer dans Ethercat, mais les ASIC semblent être intouchables aux amateurs ou à ceux sans entreprise. Aussi, c'est mon premier post, donc excuses si j'ai mis en colère les dieux en déterrant un vieux post!