Quelle est la maturité de la programmation en temps réel en robotique? [fermé]

20

Edit: je ne sais pas pourquoi, mais cette question semble dérouter beaucoup de gens. Je sais quand / où / pourquoi / comment utiliser en temps réel. Je souhaite savoir si les personnes qui ont une tâche en temps réel se soucieraient réellement de la mettre en œuvre en temps réel ou non.

Il n'est pas nécessaire de mentionner pourquoi les opérations en temps réel sont importantes pour un robot. Ma question est cependant, combien est-il réellement utilisé en robotique?

Prenez cette question par exemple. Une seule réponse mentionne n'importe quelle plate-forme avec des capacités en temps réel, et elle est également loin du sommet. ROS apparemment, étant une plate-forme très populaire qui n'est pas en temps réel.

Cependant, dans le monde en temps réel, RTAI 1 semble être la seule plate-forme d'utilisation gratuite en temps réel. Il est cependant limité à Linux (pas de problème), mal documenté et peu développé.

Alors, quel est le comportement en temps réel recherché chez les développeurs de robotique?La question est, dans quelle mesure les développeurs sont-ils enclins à écrire des applications en temps réel lorsqu'un comportement en temps réel est réellement nécessaire? Sinon, pourquoi?

Par exemple, un comportement réflexif basé sur des données tactiles ne peut pas passer par ROS car il perdrait sa propriété en temps réel. Mais les gens trouvent-ils vraiment une solution en temps réel ou utilisent-ils de toute façon ROS, ignorant la propriété en temps réel?

1 ou similaire Xenomai

Shahbaz
la source
1
Je pense que c'est une excellente question. Pensez à le diviser en deux et à clarifier votre question principale. "Peut-on utiliser ROS en temps réel?" ou 'Est-ce que ROS est utilisé en temps réel?' (2 questions différentes) sont distinctes de votre question principale.
hauptmech
@hauptmech, eh bien ROS ne peut certainement pas être utilisé en temps réel, car ce n'est pas le cas!
Shahbaz
Je suis d'accord avec @hauptmech. Les questions sont déroutantes. En haut, vous demandez combien de personnes / à quelle fréquence les systèmes en temps réel sont utilisés et plus tard, vous demandez quand / dans quel cas . Les deux sont de bonnes questions, alors veuillez le diviser en deux ou réduire à un. Merci!
Bit-pirate
@ bit-pirate, je ne comprends pas pourquoi tu dis que j'ai demandé quand / dans quel cas . Je n'ai jamais demandé une telle chose. Comme je l'ai dit, la question est de savoir dans quelle mesure les développeurs sont enclins à écrire des applications en temps réel lorsqu'un comportement en temps réel est réellement nécessaire? En d' autres termes, quel est le pourcentage d'applications qui font appel aux pratiques en temps réel, sont effectivement mises en œuvre en temps réel? Je sais personnellement quand et dans quel cas un comportement en temps réel est nécessaire et je n'ai absolument aucune question à ce sujet. En fait, je suis surpris de voir des réponses expliquer cela .
Shahbaz
Merci pour la clarification! Pour moi, le titre était déroutant. La programmation + l'implémentation en temps réel de l'OMI est mature en robotique, mais elle implique plus d'efforts (temps, argent, compétences, etc.), donc la plupart des gens l'évitent, quand ce n'est pas vraiment nécessaire.
bit-pirate

Réponses:

10

N'oubliez pas qu'il y a du temps réel et du temps réel .

Le temps réel dur est difficile à réaliser sans support matériel ou support logiciel de bas niveau, mais vous n'avez souvent pas besoin de tout pour être capable en temps réel dur . La réponse en temps réel douce et ferme est beaucoup plus facile à réaliser et est souvent plus que suffisante pour de nombreuses applications.

De plus, différentes parties d'un système peuvent avoir des exigences en temps réel très différentes . Si vous exécutez des boucles PID logicielles, elles devraient vraiment avoir une réponse difficile en temps réel (vous ne voulez vraiment pas avoir à choisir entre le réglage progressif de vos PID ou le réglage dur et leur perte occasionnelle, par exemple). Un système de vision peut avoir des exigences fermes de réponse en temps réel , les performances se dégradent si vous ne pouvez pas traiter l'image à temps pour la prochaine décision, mais cela ne doit pas empêcher le système de fonctionner, dans ce cas si vous ne pouvez pas la traiter à temps. il vaut mieux jeter les résultats partiels et ne pas perdre de temps à démarrer l'analyse sur la trame suivante. Enfin votre planification et coordination globales (probablement les plus complexespartie de votre système robotique) peuvent souvent rester fermement dans le domaine du temps réel doux .

Même dans le domaine des PC Windows, vous pouvez obtenir des performances en temps réel , vous avez juste besoin du bon logiciel avec les bons crochets dans le noyau. Le PLC souple TwinCat de Beckhoff a très heureusement exécuté un PLC à taux de balayage élevé en découpant la moitié des cycles de la machine d'un Pentium, donnant l'autre moitié à Windows NT, et c'était il y a plus de dix ans. Même les systèmes de contrôle modernes comme certaines options de la gamme A3200 d'Aerotech font le gros travail sur le PC hôte, le noyau de bas niveau prenant autant de temps CPU qu'il en a besoin pour les exigences en temps réel et laissant le reste des cycles CPU pour Windows 7 utiliser!

Mark Booth
la source
La distinction ici est tout à fait pertinente ... même dans les systèmes de bas niveau "du monde réel", le bit en temps réel est assez petit (basé sur une interruption de minuterie) alors que la plupart du système est nominalement en temps réel (mais + / - quelques nano-secondes ici et là est tolérable). Je souris quand je vois des gens parler d'applications en temps réel construites sur WindowsCE ou Linux ...
Andrew
1
Comme je l'ai dit @Andrew avec le bon logiciel, même Windows 7 peut être rendu difficile en temps réel avec un RTX . Je ne sais pas pourquoi vous ne considérez pas Windows CE comme étant en temps réel, il a eu une planification déterministe des tâches en temps réel puisque la version 2 et Linux peuvent être créés en temps réel avec un noyau comme RTLinux .
Mark Booth
Salut à nouveau Mark (je ne sais pas qui traque qui ici ...) - Je suis d'accord que vous pouvez le faire, mais une dure expérience a montré que dans de nombreux (? La plupart?) Cas, les utilisateurs (gestionnaires) ignorent les modules complémentaires requis et supposent que le système vanille fera.
Andrew
@Andrew - D'après mon expérience avec RTX, cela a juste fonctionné . Au Pentium 4 jours, vous deviez faire attention à ne pas utiliser de graphiques ou audio intégrés qui saturaient le bus PCI, mais cela ne devrait pas être un problème de nos jours.
Mark Booth
Cela fait longtemps, mais en relisant cette page, en particulier en ce qui concerne les fenêtres, je voudrais juste dire que vous ne mentionnez qu'une partie de la façon dont un système est créé en temps réel. La planification en temps réel est importante bien sûr, mais il y a toutes sortes de choses qui peuvent générer des pics qui doivent également être gérés pour créer un système en temps réel. Les interruptions sont l'exemple courant, SMI, les caches et la bande passante mémoire sont d'autres exemples. Tout simplement parce qu'il existe un planificateur en temps réel ne fait pas un système en temps réel.
Shahbaz
8

Un système en temps réel n'est pas vraiment nécessaire pour de nombreux (la plupart?) Systèmes de contrôle robotique. Tant que vous avez une boucle de contrôle qui fonctionne assez rapidement, avec une gigue suffisamment faible et ne manque pas trop de cycles, cela est tout à fait suffisant pour le contrôle robotique et l'asservissement.

Pour preuve, permettez-moi de vous présenter le PR2 et le Shadow Robot Hand:

PR2

Ce robot a environ 20 degrés de liberté, qui sont tous asservis via la boucle principale de ROS. Ou que diriez-vous de la main du robot fantôme, qui dispose également de 20 DOF, ainsi que d'une gamme de capteurs tactiles et autres, et est également asservie via la boucle principale de ROS.

La boucle principale du ROS souffre d'un peu de gigue, parfois jusqu'à 100us, et parfois même manque complètement de cycles. Mais peu importe si 99,9% des cycles sont exécutés avec succès.

L'utilisation de nombreux cœurs au sein des PC hôtes signifie qu'un cœur entier est dédié à l'exécution de la boucle principale et qu'il est donc très rarement retardé par d'autres tâches.

La principale raison d'utiliser un système d'exploitation en temps réel pour un système robotique est la sécurité. Si le robot fonctionne dans une situation critique pour la sécurité, il est de votre responsabilité de garantir une disponibilité à 100% du contrôle, et une partie de cela garantit la nature en temps réel de celui-ci.

Que vous utilisiez un système d'exploitation en temps réel ou non, vos servos devraient faire quelque chose de sûr au cas où la boucle de contrôle mourrait entièrement. Ce système de sécurité serait également utile dans les rares cas où votre système d'exploitation en temps non réel saute plus d'un cycle. Par exemple, sur la Shadow Hand, les moteurs sont arrêtés si la boucle de contrôle manque plus de 20 cycles (20 ms). Je n'ai cependant jamais vu cela se produire.


Ajoutée

Une autre façon de penser est la suivante: quel taux de mise à jour votre système d'asservissement a-t-il réellement besoin? S'il s'agit d'un bras de grande taille et qu'il n'a pas besoin d'un positionnement à très haute performance et à grande vitesse, alors 500 Hz peut être suffisant. Pour se déplacer, 200 Hz est probablement suffisant. Dans les deux cas, si votre boucle fonctionne réellement à 1000 Hz, un cycle tardif ou manquant ne pose vraiment aucun problème, tant que votre algorithme de contrôle prend en compte le temps réel écoulé entre les boucles.

Rocketmagnet
la source
Donc en bref, vous dites que le temps réel n'est souvent pas utilisé, car les logiciels non temps réel fonctionnent "assez bien"?
Shahbaz
@Shahbaz - Je ne peux pas dire exactement à quelle fréquence il est réellement utilisé, mais je peux dire que s'il est utilisé, cela pourrait bien être inutile. Nous avions l'habitude d'utiliser RTAI, puis nous l'avons abandonné car il gênait en fait plus que d'aider.
Rocketmagnet
1
Je voudrais souligner un point: vous avez tellement de puissance de traitement sur le PR2 que vous pourriez obtenir quelque chose de "assez bon". J'ai travaillé sur un robot avec "seulement" un Core2 Duo. Ce n'est pas une option: la pile complète prend chaque cœur à 100% la plupart du temps. Ici, Rock (Orocos) et RT-Linux étaient nécessaires pour maintenir ensemble la boucle de contrôle de 1 kHz.
sylvain.joyeux
@ sylvain.joyeux - Je suis d'accord. ROS fonctionne assez mal pour le contrôle lorsque vous n'avez que 2 cœurs.
Rocketmagnet
@Rocketmagnet Je suis désolé d'avoir à voter contre celui-ci, mais la partie PR2 est erronée. Sur le PR2, il existe une seule boucle en temps réel fonctionnant à 1000 Hz parallèlement à ROS (sur Linux + RT PREEMPT), qui communique via Ethercat avec les cartes de contrôleur de moteur, effectuant le contrôle moteur réel de chaque DOF. Vous devez être prudent lors de la programmation des contrôleurs (par exemple un contrôleur de trajectoire conjoint) afin de ne pas casser en temps réel et ils ont également des outils spéciaux pour les gérer (par exemple, les charger / décharger). Regardez ici pour plus de détails.
Bit-pirate
4

Le but du logiciel détermine s'il doit être strictement en temps réel.

Lorsque le but est la planification ou la localisation de chemin, une fréquence basse est souvent suffisante, par exemple 10 Hz. Dans ces cas, une configuration de joueur / scène fonctionnant sous Linux est très bien. Nous pouvons voir qu'il y a peu de problèmes si un pas de temps est un peu plus long ou plus court.

Un comportement strictement en temps réel est requis si la dynamique du robot est rapide. Par exemple, déplacer un bras robotisé pour suivre une position ou pour manipuler / saisir des objets et les déplacer. Si un pas de temps est manqué, la position peut dépasser de manière indésirable et nous pouvons souhaiter un comportement plus prévisible. Dans ce cas, nous pouvons avoir une fréquence allant jusqu'à 1 kHz ou plus. Si un système d'exploitation est utilisé, nous voulons un système d'exploitation en temps réel.

Le comportement en temps réel peut être accompli dans des applications embarquées, en utilisant des temporisateurs et des interruptions (code C compilé sur un microcontrôleur). Dans ce cas, nous devons nous assurer que la charge de traitement n'est pas trop élevée pour qu'une fréquence d'échantillonnage régulière puisse être maintenue.

Les robots utilisant des ordinateurs / microprocesseurs (car plus de puissance de traitement est nécessaire), devront utiliser un système d'exploitation en temps réel pour garantir des taux d'échantillonnage élevés.


Par conséquent, si un comportement en temps réel est requis dépend de ce que le développeur a l'intention de l'utiliser.

ronalchn
la source
Merci pour la réponse. Peut-être que ma question a besoin d'une meilleure formulation, mais je ne voulais pas demander "quand utiliser en temps réel", mais "à quelle fréquence les gens utilisent-ils réellement le temps réel quand le temps réel est nécessaire". Néanmoins, votre comportement en temps réel sur les microcontrôleurs, sans avoir besoin d'une plate-forme en temps réel, était un bon point que je n'avais pas considéré.
Shahbaz
D'un côté, en temps réel et rapide sont deux concepts orthogonaux. Si un planificateur de chemin doit décider strictement en une minute, il s'agit d'une application en temps réel. Bien que je comprenne pourquoi vous mentionnez un robot rapide.
Shahbaz
2

Notre entreprise construit des robots utilisant FreeRTOS fonctionnant sur des microcontrôleurs PIC. Pour nous, les principales raisons d'utiliser FreeRTOS sont la facilité de réorganisation des priorités sur les tâches, la gestion simultanée de plusieurs lignes de communication et la communication facile entre les gestionnaires d'interruption et les tâches principales. Les microcontrôleurs sont bien moins chers que d'installer une machine Linux complète dans chaque robot que nous produisons également.

Crake
la source
2

Si vous avez réellement besoin en temps réel, vous utilisez un système d'exploitation en temps réel. La surveillance de la sécurité, l'acquisition de données et les boucles de contrôle de fréquence d'échantillonnage constantes sont des sous-systèmes courants qui utilisent une planification en temps réel.

La partie en temps réel de la programmation est généralement aussi petite que possible, car elle est plus difficile à déboguer et moins de code est plus facile à vérifier pour l'exactitude. La documentation sur les systèmes d'exploitation en temps réel est généralement assez bonne (y compris RTAI / Xenomai).

J'ai utilisé QNX et RTAI-> Xenomai dans différents projets réels de robotique. J'ai préféré QNX mais Xenomai était tout aussi efficace.

hauptmech
la source
2

Orocos est un cadre logiciel de contrôle robotique en temps réel mature. Je l'ai vu utilisé pour contrôler avec succès des manipulateurs robotiques à grande vitesse avec des exigences difficiles en temps réel. Il possède bon nombre des mêmes composants de niveau cadre que ROS, les communications, la configuration, la sérialisation et le conditionnement basé sur les composants.

Joe
la source
2

Commencez à penser à votre robot en termes de plusieurs processeurs et de questions en temps réel. Si vous avez un algorithme qui a besoin d'une rétroaction fiable à haute vitesse, comme un équilibreur à deux roues ou un stabilisateur quad-copter ou une impulsion d'asservissement, le temps réel est extrêmement important, mais la tâche est également très contrainte.

Vous pouvez décharger une boucle de contrôle comme celle-ci vers un processeur dédié en temps réel tel que l'AVR 8 bits bon marché ou les ARM bas de gamme 32 bits que l'on trouve dans la classe d'appareils Arduino. Rien ne vous empêche d'ajouter des dizaines de ces petits microcontrôleurs exécutant des boucles de contrôle dédiées, l'énumération des périphériques USB facilite même les choses.

Maintenant que les boucles de contrôle sensibles au timing sont gérées par un processeur dédié, vous pouvez assouplir les besoins en temps réel du `` cerveau '' du robot qui peut exécuter une logique haut de gamme à l'aide de composants tels que ROS sur Linux ou Kinect pour Windows.

Jay Beavers
la source
0

En réponse à "quand / dans quel cas" des systèmes en temps réel sont utilisés:

D'après mon expérience, le contrôle de mouvement est la principale application des systèmes en temps réel. Pour contrôler les moteurs, une fréquence élevée (100 Hz, 1000 Hz et plus) et une faible gigue (variations de temps) sont importantes. La sécurité est un gros point ici. Considérez un robot parmi les humains: Par exemple, vous voulez / devez vous assurer que le robot (bras) s'arrête dans un laps de temps / une distance spécifique.

Pour d'autres tâches telles que la planification de chemin, le traitement de la vision et le raisonnement du système en temps réel ne sont pas si importants et souvent évités en raison des frais généraux liés au temps de développement et aux coûts matériels.

De nos jours, les gros robots tels que le PR2 combinent les deux mondes. Dans le contexte en temps réel du système d'exploitation compatible RT (par exemple Linux + Xenomai), le contrôle de mouvement se produit et dans la partie non en temps réel (espace utilisateur), le traitement et la planification de la vision sont intégrés dans des systèmes comme ROS. Les deux peuvent fonctionner sur le même ordinateur.

Je suis heureux de modifier cette réponse, une fois la question clarifiée. :-)

pirate
la source
0

Oui, en supposant que les ressources matérielles peuvent répondre aux exigences de synchronisation (puissance de traitement suffisante, latence suffisamment faible), lorsque le planificateur ne peut pas séquencer les processus et les threads de manière appropriée, alors on utilise un planificateur en temps réel, généralement attaché à un noyau spécifiquement optimisé pour le défis de cela. Les pilotes matériels peuvent également être optimisés pour les conditions en temps réel.

Oui, si un logiciel ne peut être garanti pour faire son travail dans les contraintes de temps requises, alors on utilise des approches en temps réel.

hauptmech
la source
0

Une bonne solution consiste à faire les deux. Un design que j'utilise place des fonctions "dures" en temps réel sur un petit micro contrôleur, des boucles de servocommande serrées et autres. Ensuite, il y a un autre processeur plus grand, exécutant Linux et ROS. Je laisse ROS gérer les tâches de niveau supérieur et l'UP gérer des choses comme le contrôle d'un moteur pas à pas ou l'exécution d'une boucle PID.

Comme indiqué ci-dessus par d'autres, vous POUVEZ autoriser un système d'exploitation en temps non réel à exécuter des boucles de contrôle de 1 kHz, mais pour que cela fonctionne, vous avez besoin d'un ordinateur de taille excessive qui passe la plupart de son temps dans une boucle inactive. Si vous exécutez l'ordinateur Linux / ROS à près de 100% d'utilisation du processeur, les performances en temps réel sont médiocres. L'utilisation d'une conception à deux niveaux vous permet d'obtenir toujours de très bonnes performances RT et d'utiliser également un ordinateur plus petit et moins gourmand en énergie (peut-être une tâche de niveau supérieur Pi2). Mon uP actuellement ne exécute aucun système d'exploitation, mais je passe à FreeRTOS

user3150208
la source