Comment contrôler un système en temps réel rapide (200 Hz) avec un système lent (30 Hz)?

Nous concevons actuellement un robot mobile + bras monté avec plusieurs degrés de liberté contrôlés et des capteurs.

J'envisage une architecture en deux parties:

1. Un ensemble de contrôleurs en temps réel (Raspeberry Pis exécutant un RTOS tel que Xenomai ou des microcontrôleurs en métal nu) pour contrôler les moteurs de bras et les encodeurs. Appelons ces machines RTx, avec x = 1,2,3… en fonction du nombre de microcontrôleurs. Cette boucle de contrôle fonctionnera à 200 Hz.

2. Une puissante machine Linux vanilla exécutant ROS pour calculer SLAM, mocap et exécuter une logique de haut niveau (décider de la tâche du robot et calculer la position et la vitesse souhaitées des moteurs). Cette boucle de contrôle fonctionnera à 30 Hz.

Je sais que mon framework doit être évolutif pour prendre en compte plus de moteurs, plus de capteurs, plus de PC (par exemple pour une mocap externe).

Mon principal problème est de décider comment faire communiquer les différents RTx avec PC1. J'ai regardé des articles liés à l'architecture des robots (par exemple HRP2 ), le plus souvent ils décrivent l'architecture de contrôle de haut niveau mais je n'ai pas encore trouvé d'informations sur la façon de faire communiquer le bas niveau avec le haut niveau et de manière évolutive. Ai-je oublié quelque chose?

Afin de connecter les machines RT rapides assurant la commande du moteur avec PC1, j'ai considéré TCP / IP, CAN et UART:

• TCP / IP: pas déterministe mais facile à mettre en place. Le non-déterminisme est-il un vrai problème (car il ne sera utilisé qu'à une vitesse lente de 30 Hz de toute façon)?
• CAN: lent, très fiable, ciblé sur les voitures (j'ai vu qu'il y a quelques exemples d'utilisation de CAN avec des robots mais ça avait l'air exotique)
• UART: si je n'avais eu qu'une seule machine RT pour le contrôle du moteur, j'aurais considéré UART mais je suppose que ce port ne s'adapte pas bien avec beaucoup de RTx. TCP / IP est-il vraiment un no go en raison de ses caractéristiques non déterministes? C'est tellement simple à utiliser…

Pour le moment, aucune solution ne me semble vraiment évidente. Et comme je ne trouve aucun exemple de robot sérieux utilisant une solution spécifique fiable et évolutive, je ne suis pas confiant de faire un choix.

Quelqu'un a-t-il une vision claire de ce point ou de la littérature à signaler? Existe-t-il des solutions de communication typiques ou grand public utilisées sur les robots?

Je pense que vous avez fait un bon premier pas; vous avez divisé le problème en une plate-forme mobile (qui a une incertitude de position et doit naviguer) et le bras (qui a une assez bonne certitude de position en temps réel, via des encodeurs).

J'ai regardé des articles liés à l'architecture des robots [...] mais je n'ai pas encore trouvé d'informations sur la façon de faire communiquer le bas niveau avec le haut niveau et de manière évolutive. Ai-je oublié quelque chose?

D'après votre description, il semble que vous essayez de lier chaque contrôleur RTx directement au PC1, qui exécute ROS. Ce que vous avez manqué, c'est que ROS est conçu pour gérer un groupe d'applications qui peuvent produire et consommer des données à des taux différents.

Ce dont votre application a besoin, c'est d'un pont de communication - une interface unique entre votre boucle de 200 Hz et votre environnement ROS. En d'autres termes, au lieu de lier chaque contrôleur RTx à PC1, reliez tous les contrôleurs RTx ensemble et connectez -les à PC1.

Par exemple, utilisez un bus I2C pour relier les systèmes RTx ensemble et ajoutez un autre contrôleur RTx pour être le "Arm Master" (AM). Le travail de l'AM serait d'accepter les commandes entrantes dans un format et un protocole compatibles PC1, et de convertir ces commandes en messages I2C. Ensuite, vous écririez une application ROS pour envoyer des commandes à l'AM.

Une autre façon de le faire avec I2C serait de placer un contrôleur I2C directement sur PC1 et d'écrire toute la logique de contrôle des bras dans une application ROS. Cela peut sembler une manière plus rationalisée d'atteindre votre objectif, mais cela peut rendre le débogage plus difficile lorsque vous supprimez la modularité du système - vous devrez le dépanner comme un grand système complexe au lieu de deux composants facilement testables.

Je dirais que toute application nécessitant un grand nombre de nœuds de communication (capteurs ou actionneurs) gagnerait à être mise en œuvre en tant que bus système (contrairement aux liaisons point à point telles que UART ou Ethernet), en raison de la complexité du câblage, du déterminisme et modularité.

Tout système de contrôle nécessite un degré élevé de déterminisme, sur lequel les canaux à large bande passante (tels que Ethernet) sont généralement pauvres (en particulier lorsqu'ils sont utilisés avec un système d'exploitation à usage général qui introduit de grandes quantités de gigue de planification, voir le lien suivant pour une discussion sur le déterminisme de planification ). Les processeurs d'application (tels que l'ARM11 du Raspberry Pi) sont également probablement mal adaptés aux systèmes en temps réel (en raison d'effets tels que la latence des interruptions et le doublage des instructions). Voir la discussion digikey suivante comparant le comportement en temps réel d'un cœur d'application ARM par rapport à un microcontrôleur .

C'est dommage que la disponibilité du CAN intégré ne soit pas aussi répandue que l'UART (RS-485) ou I2C (pour l'instant), car je pense que cela simplifie vraiment le problème de la détection et de l'actionnement distribués. Et bien que les 1 Mbps habituels puissent sembler lents, ils sont généralement plus que suffisants après le calcul des taux de rafraîchissement de tous les membres du bus (et le taux de transmission peut toujours être augmenté, selon la longueur du bus, l'impédance et si vos émetteurs-récepteurs le permettront). Il existe également un logiciel de simulation génial, qui garantit essentiellement les temps de réponse dans le pire des cas (par exemple, RealTime-at-work a un analyseur de bus CAN gratuit appelé RTaW-Sim). Et enfin, il semblerait que la disponibilité des capteurs MEMS avec CAN intégré soit plutôt faible.

Un autre exemple où les actionneurs sont configurés en bus (ou en anneau), est les séries Dynamixels AX et MX, où chaque moteur est connecté en guirlande au suivant via une liaison UART. Cela simplifie considérablement la conception du système si vous avez une grande quantité d'actionneurs.

Mais, pour revenir à la vraie question, je pense que si vous décrivez votre système comme des points de consigne en temps réel, au lieu de commandes (par exemple, diffusez plutôt en continu un angle de moteur plutôt que d'ordonner une commande telle que goto angle), cela simplifie le couplage entre la boucle 200 Hz et 30 Hz.

Vous semblez avoir deux problèmes distincts (mais liés) que vous essayez de résoudre en même temps. Décomposons votre énigme en petits morceaux:

1. Comment puis-je communiquer des commandes d'un système lent (30 Hz) à un contrôleur rapide (200 Hz), et comment puis-je communiquer les données reçues à 200 Hz à mon thinktank 30 Hz?
2. Comment puis-je contrôler ce qui se passe à 200 Hz, alors que je ne peux que dire au robot quoi faire à 30 Hz?

L'élément 1 peut être résolu dans le matériel, comme votre question d'origine semble l'indiquer: vous pouvez mettre les données en file d'attente à 200 Hz et envoyer le paquet à 30 Hz à votre système de niveau supérieur. Vous pouvez le faire avec TCP / IP, ou éventuellement CAN selon la quantité de données que vous souhaitez envoyer. Différents matériels ont différents débits max. L'ajout d'un niveau d'architecture comme ROS pour agir comme pont / arbitre de communication comme suggéré dans d'autres articles peut également aider.

Le point 2 est un problème de théorie de contrôle qui ne peut pas être résolu avec du matériel seul. Le SLAM, les déterminations de position et de vitesse et la détermination des tâches que vous souhaitez devront être plus intelligents car ils envoient et reçoivent des informations moins souvent. Vous voudrez probablement 2 boucles de contrôle : 1 à 200 Hz et 1 à 30 Hz.

Il y a beaucoup d'autres questions qui couvrent les boucles de contrôle de rétroaction, de rétroaction et de PID, mais vous avez spécifiquement posé des questions sur l'évolutivité - la façon dont la plupart des systèmes géants évoluent est en superposant les boucles de contrôle et la logique de sorte que les informations nécessaires minimales traversent le matériel vous vous retrouvez avec. Par exemple, votre contrôleur de niveau supérieur peut uniquement attribuer des points de position de but et une vitesse de but moyenne au niveau inférieur, sans modifier la vitesse 30 fois par seconde.