Le ROS (Robot Operating System) est-il obligatoire?
10
Faut-il construire ROS pour la recherche / application robotique? Quel est le principal avantage? Quand ou dans quelles situations le ROS est-il obligatoire?
J'aurais écrit une réponse, mais je tape sur un téléphone. Généralement, ROS n'est pas obligatoire. À mon avis, dépendre de ROS est même mauvais. Quel que soit le composant dont vous disposez, créez-en une bibliothèque portable, puis écrivez un module ROS à l'aide de celui-ci. Lorsque ROS meurt ou que vos besoins changent, vous apprécierez de l'avoir fait.
Shahbaz
Réponses:
18
Je suis de retour à un ordinateur!
Comme je l'ai dit dans ce commentaire , ROS n'est généralement pas obligatoire. ROS est une plate-forme parmi tant d'autres, célèbre principalement parce que Willow Garage a donné des robots gratuits à un moment donné à celui qui a écrit le plus de modules ROS. Cela dit, ce n'est pas la meilleure plateforme possible, et ce n'est certainement pas trop spécial. En particulier, ledit concours a abouti à de nombreux modules de faible qualité juste pour augmenter les nombres.
Au fil du temps, la qualité des modules ROS s'est améliorée et il y en a aussi beaucoup. Par conséquent, en utilisant ROS, vous avez l'avantage de réutiliser une grande partie de ce qui a déjà été fait. Vous pouvez lire ici quelques raisons pour lesquelles vous voudrez peut-être utiliser ROS.
Dans cet esprit, vous devez également rechercher les effets secondaires.
Contrôle distribué
Avec ROS, vous disposez de nombreux nœuds qui communiquent entre eux via le réseau. C'est parfois bon et facile, mais cela entraîne généralement un retard très variable dans la réception des messages. En conséquence, vous devriez avoir un délai de contrôle important pour vous assurer que tous les messages arrivent, ce qui signifie que vous ne pouvez pas réagir rapidement aux événements, ce qui signifie que vous devez déplacer votre robot à des vitesses plus lentes afin de ne pas manquer ces événements.
Croyez-le ou non, les gens contrôlent réellement le robot via ROS ( MoveIt! Est le nom de l'ensemble de composants correspondant). Lent. Peu sûr. Mais facile!
Non temps réel
Même lorsqu'il n'est pas distribué, ROS n'est pas une plateforme en temps réel. Cela signifie que vous êtes à l'entière discrétion du noyau Linux pour planifier vos tâches à tout moment. C'est ok pour certaines applications, mais pas ok pour d'autres. Vous devez donc examiner vos propres exigences. Avez-vous besoin d'une garantie que votre tâche se terminera dans un délai connu? Si oui, vous avez besoin d'un système en temps réel.
Environnement d'exécution hébergé
Un autre point à considérer est que, bien que ROS soit un protocole général de communication, il n'est essentiellement pris en charge que pour les environnements hébergés. Hébergé signifie que le code s'exécute au-dessus d'un noyau, par opposition à autonome, ce qui signifie que le code contrôle directement le matériel (par exemple, sur un microcontrôleur).
Si votre application robotique est exécutée à proximité du matériel, et donc vous auriez besoin d'un programme qui s'exécute sur un microcontrôleur, ROS ne vous est d'aucune aide.
Verrouillage de la plateforme
Enfin, le développement pour ROS entraîne un verrouillage de la plate-forme. Cela signifie que si à l'avenir, pour une raison ou une autre, vous décidez de baser votre travail sur une autre plate-forme robotique, comme OROCOS, YARP, etc., ce serait atroce.
Vous seriez également quelque peu bloqué sur Linux. Linux est sans aucun doute le meilleur, mais un jour, vous pourriez devoir supporter un autre système, tel que QNX, VxWorks, etc., et vous auriez également des problèmes.
Si vous écrivez pour les microcontrôleurs, alors oubliez ROS. Si vous écrivez des modules de haut niveau, je recommande fortement d'écrire du code portable. Par exemple, supposons que vous ayez développé un nouveau capteur et que vous souhaitiez écrire un module qui acquiert des données de ce capteur, qui est connecté à votre ordinateur via le bus CAN.
Dans ce cas, vous pourriez écrire une bibliothèque indépendante, avec des fonctions capables de travailler avec votre capteur et d'acquérir des données. Vous pourriez même penser à générer un thread dans la bibliothèque qui acquiert et met en file d'attente des données périodiquement.
Une fois que vous avez cette bibliothèque d'aide, vous êtes libre d'écrire une CLI, une GUI, un module ROS, un module OROCOS, un module YARP, de vous connecter à Matlab ou tout ce que vous souhaitez utiliser pour interagir avec votre capteur.
Remarque finale: ce que j'ai dit ici est généralement applicable à toutes les plates-formes robotiques et pas seulement à ROS.
Les commentaires ne sont pas pour une discussion approfondie; cette conversation a été déplacée vers le chat .
Mark Booth
2
"ROS" est un terme relatif, l'APM exécute un code personnalisé complet spécialement conçu pour le contrôle des quadricoptères où un ROS personnalisé peut être souhaitable pour éviter de se bloquer, d'un autre côté, Navio + fonctionne sur un noyau Linux et exécute du code autre que le pilote automatique, et parvient toujours à éviter de s'écraser. La plupart des ROS sont en réalité un ensemble de fonctions au-dessus d'un système d'exploitation existant, par opposition à l'écriture d'un système d'exploitation à partir de zéro. Comme pour tout, cela dépend.
Il parle du RobotOperatingsystem, pas du RealtimeOperatingSystem ...
FooTheBar
2
Avertissement: Cette réponse est en quelque sorte une réaction au message de Shahbaz, donc elle a un biais pro-ROS.
Je ne pense pas que ROS soit obligatoire, mais c'est un excellent point de départ et vaut le temps d'investir. Cela a commencé au sein de Willow Garage, mais cette entreprise a disparu et ROS est toujours en vie, utilisé et développé. La plupart de ROS est entièrement open source et également utilisable commercialement, il n'y a donc aucun moyen que ROS disparaisse si une entreprise ne l'intéresse plus. La qualité du code diffère bien sûr entre les modules de base et les implémentations d'algorithmes de pointe que certains doctorants ont publiés avec son article.
ROS prend de plus en plus de vitesse dans les milieux industriels (je serais surpris s'il y ait une part importante de startups en robotique dans le monde qui n'utilisent pas ROS). Certains algorithmes seront maintenus et développés par le consortium ros-industrial et si vous regardez les membres, il y a fort à parier que ROS va devenir une norme dans l'industrie:
La façon distribuée d'utiliser ROS aide beaucoup à créer et à maintenir de nouveaux packages, en particulier au sein des équipes. Les définitions de message et d'action aident beaucoup à définir des interfaces afin que le matériel et les algorithmes puissent être échangés rapidement. Cela aide également à intégrer les nouveaux membres de l'équipe, car un nouveau nœud fera tomber les autres nœuds s'il tombe en panne (tant qu'il ne mange pas toute la RAM ..), il est donc plutôt sûr d'intégrer des nœuds fonctionnant partiellement dans le système en cours d'exécution en tant que leur l'effet est limité. La communication utilise TCP qui est fiable et rapide (sur une machine locale), de sorte que le passage des messages est très rapide (plusieurs centaines de Hz pour une boucle de contrôle est possible).
Non temps réel
ROS n'est actuellement pas en temps réel car la grande majorité des algorithmes n'ont pas besoin de temps réel. La détection ou la planification n'a pas de contraintes en temps réel dans la plupart des cas (combien de personnes construisent des voitures à grande vitesse autonomes?). Il suffit que la boucle de contrôle finale fonctionne en temps réel et cela peut dans de nombreux cas se faire directement sur le moteur (auquel la position finale est envoyée, par exemple via CAN). Le temps réel est cependant l'un des principaux objectifs de ROS2 ( https://github.com/ros2/ros2/wiki/Real-Time-Programming ), donc même si vous en avez besoin à l'avenir pour l'ensemble du système, ROS vous couvre .
Si vous voulez vraiment exécuter des trucs intégrés, il y a bien sûr une connexion à arduino, de sorte que vous pouvez écrire des messages ROS directement sur l'arduino qui sont ensuite envoyés via une connexion série.
Exécuter ROS sur Windows est actuellement plutôt pénible, mais comme Windows se rapproche de Linux (même en commençant à avoir quelque chose de bash), ce n'est qu'une question de temps jusqu'à ce que ce soit possible. (Mais qui veut faire fonctionner un robot avec des fenêtres de toute façon?)
Interfaces matérielles et algorithmes:
Je pense que c'est vraiment un point fort pour ROS. De nombreux robots disponibles dans le commerce sont déjà livrés avec une interface ROS ou quelqu'un a déjà investi du temps pour mettre en œuvre l'interface. La plupart des bras commerciaux peuvent être utilisés dans MoveIt, donc une grande partie du travail pour faire fonctionner une application avec un bras spécifique peut être réutilisée avec un autre matériel.
Communauté:
Un autre point fort pour ROS. Les nouveaux algorithmes obtiennent une interface ROS très rapidement et beaucoup de gens ont eu les mêmes problèmes que vous, vous trouverez donc quelqu'un pour vous aider.
La dernière chose que je voudrais voir, c'est regarder en arrière dans 20 ans, où tout est construit autour de ROS, et réaliser que, oups, nous avons besoin de robots pour fonctionner à une vitesse comparable à celle des humains, mais nous ne pouvons pas, car il y a 20 ans, nous pensions combien de personnes construisent des voitures à grande vitesse autonomes de toute façon ?
Shahbaz
2
Je pense que je dois me ranger du côté de @Shahbaz sur celui-ci. Ce n'est pas que ROS n'a pas sa place, c'est que vous ne devriez pas utiliser ROS au lieu de bonnes pratiques de codage. Le protocole ROS que vous créez doit être dérivé d'une bibliothèque d'interface, et non l'inverse.
Réponses:
Je suis de retour à un ordinateur!
Comme je l'ai dit dans ce commentaire , ROS n'est généralement pas obligatoire. ROS est une plate-forme parmi tant d'autres, célèbre principalement parce que Willow Garage a donné des robots gratuits à un moment donné à celui qui a écrit le plus de modules ROS. Cela dit, ce n'est pas la meilleure plateforme possible, et ce n'est certainement pas trop spécial. En particulier, ledit concours a abouti à de nombreux modules de faible qualité juste pour augmenter les nombres.
Au fil du temps, la qualité des modules ROS s'est améliorée et il y en a aussi beaucoup. Par conséquent, en utilisant ROS, vous avez l'avantage de réutiliser une grande partie de ce qui a déjà été fait. Vous pouvez lire ici quelques raisons pour lesquelles vous voudrez peut-être utiliser ROS.
Dans cet esprit, vous devez également rechercher les effets secondaires.
Contrôle distribué
Avec ROS, vous disposez de nombreux nœuds qui communiquent entre eux via le réseau. C'est parfois bon et facile, mais cela entraîne généralement un retard très variable dans la réception des messages. En conséquence, vous devriez avoir un délai de contrôle important pour vous assurer que tous les messages arrivent, ce qui signifie que vous ne pouvez pas réagir rapidement aux événements, ce qui signifie que vous devez déplacer votre robot à des vitesses plus lentes afin de ne pas manquer ces événements.
Croyez-le ou non, les gens contrôlent réellement le robot via ROS ( MoveIt! Est le nom de l'ensemble de composants correspondant). Lent. Peu sûr. Mais facile!
Non temps réel
Même lorsqu'il n'est pas distribué, ROS n'est pas une plateforme en temps réel. Cela signifie que vous êtes à l'entière discrétion du noyau Linux pour planifier vos tâches à tout moment. C'est ok pour certaines applications, mais pas ok pour d'autres. Vous devez donc examiner vos propres exigences. Avez-vous besoin d'une garantie que votre tâche se terminera dans un délai connu? Si oui, vous avez besoin d'un système en temps réel.
Environnement d'exécution hébergé
Un autre point à considérer est que, bien que ROS soit un protocole général de communication, il n'est essentiellement pris en charge que pour les environnements hébergés. Hébergé signifie que le code s'exécute au-dessus d'un noyau, par opposition à autonome, ce qui signifie que le code contrôle directement le matériel (par exemple, sur un microcontrôleur).
Si votre application robotique est exécutée à proximité du matériel, et donc vous auriez besoin d'un programme qui s'exécute sur un microcontrôleur, ROS ne vous est d'aucune aide.
Verrouillage de la plateforme
Enfin, le développement pour ROS entraîne un verrouillage de la plate-forme. Cela signifie que si à l'avenir, pour une raison ou une autre, vous décidez de baser votre travail sur une autre plate-forme robotique, comme OROCOS, YARP, etc., ce serait atroce.
Vous seriez également quelque peu bloqué sur Linux. Linux est sans aucun doute le meilleur, mais un jour, vous pourriez devoir supporter un autre système, tel que QNX, VxWorks, etc., et vous auriez également des problèmes.
Si vous écrivez pour les microcontrôleurs, alors oubliez ROS. Si vous écrivez des modules de haut niveau, je recommande fortement d'écrire du code portable. Par exemple, supposons que vous ayez développé un nouveau capteur et que vous souhaitiez écrire un module qui acquiert des données de ce capteur, qui est connecté à votre ordinateur via le bus CAN.
Dans ce cas, vous pourriez écrire une bibliothèque indépendante, avec des fonctions capables de travailler avec votre capteur et d'acquérir des données. Vous pourriez même penser à générer un thread dans la bibliothèque qui acquiert et met en file d'attente des données périodiquement.
Une fois que vous avez cette bibliothèque d'aide, vous êtes libre d'écrire une CLI, une GUI, un module ROS, un module OROCOS, un module YARP, de vous connecter à Matlab ou tout ce que vous souhaitez utiliser pour interagir avec votre capteur.
Remarque finale: ce que j'ai dit ici est généralement applicable à toutes les plates-formes robotiques et pas seulement à ROS.
la source
"ROS" est un terme relatif, l'APM exécute un code personnalisé complet spécialement conçu pour le contrôle des quadricoptères où un ROS personnalisé peut être souhaitable pour éviter de se bloquer, d'un autre côté, Navio + fonctionne sur un noyau Linux et exécute du code autre que le pilote automatique, et parvient toujours à éviter de s'écraser. La plupart des ROS sont en réalité un ensemble de fonctions au-dessus d'un système d'exploitation existant, par opposition à l'écriture d'un système d'exploitation à partir de zéro. Comme pour tout, cela dépend.
la source
Avertissement: Cette réponse est en quelque sorte une réaction au message de Shahbaz, donc elle a un biais pro-ROS.
Je ne pense pas que ROS soit obligatoire, mais c'est un excellent point de départ et vaut le temps d'investir. Cela a commencé au sein de Willow Garage, mais cette entreprise a disparu et ROS est toujours en vie, utilisé et développé. La plupart de ROS est entièrement open source et également utilisable commercialement, il n'y a donc aucun moyen que ROS disparaisse si une entreprise ne l'intéresse plus. La qualité du code diffère bien sûr entre les modules de base et les implémentations d'algorithmes de pointe que certains doctorants ont publiés avec son article.
ROS prend de plus en plus de vitesse dans les milieux industriels (je serais surpris s'il y ait une part importante de startups en robotique dans le monde qui n'utilisent pas ROS). Certains algorithmes seront maintenus et développés par le consortium ros-industrial et si vous regardez les membres, il y a fort à parier que ROS va devenir une norme dans l'industrie:
http://rosindustrial.org/ric/current-members/
La façon distribuée d'utiliser ROS aide beaucoup à créer et à maintenir de nouveaux packages, en particulier au sein des équipes. Les définitions de message et d'action aident beaucoup à définir des interfaces afin que le matériel et les algorithmes puissent être échangés rapidement. Cela aide également à intégrer les nouveaux membres de l'équipe, car un nouveau nœud fera tomber les autres nœuds s'il tombe en panne (tant qu'il ne mange pas toute la RAM ..), il est donc plutôt sûr d'intégrer des nœuds fonctionnant partiellement dans le système en cours d'exécution en tant que leur l'effet est limité. La communication utilise TCP qui est fiable et rapide (sur une machine locale), de sorte que le passage des messages est très rapide (plusieurs centaines de Hz pour une boucle de contrôle est possible).
Non temps réel
ROS n'est actuellement pas en temps réel car la grande majorité des algorithmes n'ont pas besoin de temps réel. La détection ou la planification n'a pas de contraintes en temps réel dans la plupart des cas (combien de personnes construisent des voitures à grande vitesse autonomes?). Il suffit que la boucle de contrôle finale fonctionne en temps réel et cela peut dans de nombreux cas se faire directement sur le moteur (auquel la position finale est envoyée, par exemple via CAN). Le temps réel est cependant l'un des principaux objectifs de ROS2 ( https://github.com/ros2/ros2/wiki/Real-Time-Programming ), donc même si vous en avez besoin à l'avenir pour l'ensemble du système, ROS vous couvre .
Si vous voulez vraiment exécuter des trucs intégrés, il y a bien sûr une connexion à arduino, de sorte que vous pouvez écrire des messages ROS directement sur l'arduino qui sont ensuite envoyés via une connexion série.
Exécuter ROS sur Windows est actuellement plutôt pénible, mais comme Windows se rapproche de Linux (même en commençant à avoir quelque chose de bash), ce n'est qu'une question de temps jusqu'à ce que ce soit possible. (Mais qui veut faire fonctionner un robot avec des fenêtres de toute façon?)
Interfaces matérielles et algorithmes:
Je pense que c'est vraiment un point fort pour ROS. De nombreux robots disponibles dans le commerce sont déjà livrés avec une interface ROS ou quelqu'un a déjà investi du temps pour mettre en œuvre l'interface. La plupart des bras commerciaux peuvent être utilisés dans MoveIt, donc une grande partie du travail pour faire fonctionner une application avec un bras spécifique peut être réutilisée avec un autre matériel.
Communauté:
Un autre point fort pour ROS. Les nouveaux algorithmes obtiennent une interface ROS très rapidement et beaucoup de gens ont eu les mêmes problèmes que vous, vous trouverez donc quelqu'un pour vous aider.
http://download.ros.org/downloads/metrics/metrics-report-2016-07.pdf
la source