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

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 ¹ 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?

¹ ou similaire Xenomai

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!

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:

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.

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.

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.

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.

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.

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.

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. :-)

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.

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