Réponse très courte: 2
Capteurs
Qu'il s'agisse de lire à partir de capteurs tous dans un nœud ou chacun séparément, vous devriez vous poser cette question:
Les capteurs n'ont-ils aucun sens l'un sans l'autre?
Cette question demande si les capteurs sont étroitement couplés ou non. Par exemple, supposons que vous ayez un capteur sensible à la température (et que vous devez le compenser). Vous ajoutez un capteur de température principalement pour fixer la valeur de l'autre capteur. Dans ce scénario, il est logique de lire les deux valeurs en même temps, car elles sont étroitement couplées. En fait, sans les lectures du capteur de température, les lectures du capteur d'origine sont inutiles.
D'un autre côté, si les capteurs sont utiles individuellement, gardez-les certainement dans des nœuds séparés. Cela présente de nombreux avantages:
- Les nœuds peuvent être exécutés sur des processeurs séparés
- Les nœuds peuvent être réutilisés dans de futurs robots
- L'échec de la communication avec un nœud ne fait pas tomber tout le système
- Le redémarrage de l'acquisition à partir d'une carte de capteur défectueuse peut être effectué séparément des autres
En fait, si vous avez besoin de l' un des avantages ci-dessus, vous devrez utiliser des nœuds séparés, même si les capteurs sont étroitement couplés, mais cela ne se produit généralement pas.
Actionneurs
C'est analogue.
Les actionneurs sont-ils dénués de sens l'un sans l'autre?
Par exemple, si vous concevez un poignet avec des tendons robotisés où pour chaque tendon (pour une raison quelconque) deux moteurs sont chargés de travailler simultanément pour déplacer une articulation dans l'une ou l'autre direction, alors les avoir servis dans le même nœud fait beaucoup plus sens que séparé.
D'un autre côté, lorsque les actionneurs sont indépendants (cas courant), il est logique d'avoir un nœud pour chaque actionneur. Dans ce cas, chacun pourrait être placé dans un nœud différent. Outre les mêmes avantages que les capteurs, il y a cet avantage supplémentaire:
- Si un actionneur est bloqué (pour une raison quelconque), les autres actionneurs fonctionnent toujours. S'il y a des degrés de liberté redondants, ils pourraient même le compenser complètement.
Cela a une implication. Si vous avez besoin que les actionneurs fonctionnent en harmonie, placez-les dans le même nœud. Ce n'est pas seulement à cause d'une défaillance de communication, mais parce que différents nœuds signifient des retards différents; sur un système distribué, chaque nœud se trouve sur une partie différente du réseau et donc la différence de retards, sur un système centralisé, différents retards se produisent sur des charges CPU élevées en raison de la chance de chaque processus dans la planification.
Devrait-il y avoir un gestionnaire?
Même si la réponse est "cela dépend", il existe une approche commune avec de nombreux avantages. Modifions le nom et appelons-le "contrôleur". L'approche est "oui, il devrait y avoir un contrôleur".
Les avantages d'avoir un contrôleur sont (parmi beaucoup):
- Traitement découplé: chaque nœud est responsable d'une chose qui signifie:
- Simplicité: ce qui implique
- Développement facilité
- Débogage simplifié
- Moins d'erreurs
- Moins de risques d'échec
- Réutilisation: car le même contrôleur peut être utilisé avec différents nœuds de capteurs s'ils ont la même fonctionnalité (c'est-à-dire les formats de message et de service).
- Exécution sur un matériel séparé: chaque nœud peut être déplacé dans le réseau. Par exemple, les nœuds de capteur et d'actionneur peuvent être déplacés vers un microcontrôleur dédié ( Arduino par exemple (pas que je recommande)) et le contrôleur sur un PC.
- Évitez la laideur extrême: si les capteurs voulaient influencer directement les actionneurs, le résultat est tout simplement un gâchis. En supposant qu'il n'y ait pas de contrôleur, regardons chaque cas:
- Un nœud de capteur: cela signifie que le nœud de capteur et le contrôleur sont regroupés dans le même nœud. Pas trop mal, mais très inutile.
- De nombreux nœuds capteurs: c'est le bordel. Cela signifie que le contrôleur est réparti entre les nœuds de capteur. Par conséquent, tous les nœuds de capteur doivent se parler pour que chacun sache comment contrôler son ou ses actionneurs associés. Imaginez un échec de communication ou divers types de retards et vous verrez à quel point cela devient difficile. Étant donné que cela est totalement inutile, il n'y a aucune raison de le faire!
Cela dit, il y a aussi des inconvénients. Avoir plus de nœuds (tous les nœuds, pas seulement le contrôleur) signifie:
- Plus de communication gaspillée: les données doivent se déplacer dans des formats standard (donc sérialisés et désérialisés) via le réseau ou la mémoire partagée, le noyau ROS doit les regarder et décider à qui les livrer, etc. En bref, certaines ressources système sont gaspillées en communication. Si tous les nœuds étaient dans un, ce coût aurait pu être nul.
- Risque d'échec plus élevé: si, pour une raison quelconque, une liaison réseau tombe en panne ou si un nœud meurt, il y a une défaillance du système. Si vous n'y êtes pas préparé, cela peut détruire tout le système. Maintenant, c'est en fait une bonne chose en général de pouvoir perdre une partie du système mais pas tout ( dégradation gracieuse ), mais il existe également des applications où cela devrait être évité autant que possible. Couper la communication et mettre tout le code dans un nœud contribue en fait à la stabilité du système. L'inconvénient est bien sûr, le système fonctionne bien ou meurt soudainement complètement.
- Timings chaotiques: chaque nœud fonctionne de manière autonome. Le temps qu'il faut pour que ses messages parviennent aux autres n'est pas déterministe et varie au fil du temps. Sauf si vos nœuds horodatent chaque message (en remarque: vous devez avoir des horloges synchronisées à un bon degré, ce que ROS ne fait pas) et à moins que chaque nœud récepteur ne puisse prendre en compte le retard et le contrôler en conséquence (ce qui est une tâche très difficile seule), le fait d'avoir plusieurs nœuds signifie une grande incertitude sur l'âge des données. C'est en fait l'une des raisons (parmi tant d'autres) que la plupart des robots se déplacent si lentement; leur boucle de contrôle doit être suffisamment lente pour s'assurer que toutes les données correspondent à la période en cours. Plus les retards sont importants, plus la boucle de contrôle est lente.
Dans tous les inconvénients ci-dessus, la solution consiste à réduire le nombre de nœuds, de préférence à un seul nœud. Attendez une minute, cela n'utilise plus ROS! Exactement.
Résumer:
- Utilisez ROS pour les systèmes non en temps réel où les retards peuvent devenir sporadiquement élevés. Dans ce cas, n'hésitez pas à avoir autant de nœuds ROS que vous le souhaitez. En fait, c'est une très bonne pratique que chaque nœud ROS fasse une et une seule chose. De cette façon, ils deviennent très simples et deviennent hautement réutilisables.
- D'un autre côté, pour les systèmes en temps réel, évitez absolument les ROS. Pour cela, il existe des orocos et des technologies comme EtherCAT et le plus souvent, des solutions ad-hoc.
Enfin, dans la pratique, ROS se porte bien. Pas génial, mais bien. Très souvent, le système n'est pas critique et les risques de défaillance sont si faibles que de temps en temps un redémarrage n'est pas un gros problème. Ceci est l' algorithme d'autruche !
