Bonjour à tous,
Alors voilà. J’aimerais fabriquer un drone de toutes pièces, mais je ne sais quoi utiliser comme carte mère. Je me demandais alors si un rasperry pi ferait l’affaire ou s’il fallait autre chose ?
Salut,
En effet, le Raspberry Pi, avec une distribution GNU/Linux comme Raspbian, n’est pas conçu pour du temps-réel. C’est un OS dit à temps partagé.
Il est tout à fait possible d’installer une version du noyau Linux modifié pour avoir un véritable OS temps-réel (Xenomai), mais c’est plutôt particulier et techniquement plus lourd.
La solution qui est adoptée dans de nombreux domaines : recourir à une électronique annexe, sans OS, et donc plus facile pour répondre à des contraintes temps-réel, par conception.
Le domaine du temps-réel même est un perpétuel et vaste sujet (voire débat) et en soi, il n’est pas caractérisé par une technologie plutôt qu’une autre (OS temps réel, sans OS, OS temps partagé) mais plutôt par des principes, dont le déterminisme temporel fait partie, et c’est surtout ce qui nous intéresse ici : l’aptitude à garantir un temps de réaction.
C’est pour cela que même avec un vieil OS à peine multitâche, il est possible de réagir techniquement en temps réel, selon les contraintes qu’on a (une régulation de température approximative d’un local, par exemple). Alors qu’il faut absolument un OS temps réel pour des processus critiques qui demandent un temps de réaction bien défini (commande moteur, process de sécurité/sûreté, etc…).
Dans un OS à temps partagé, on ne peut imposer l’exécution d’une action en un temps précis donné, on demande tout au plus au système d’essayer d’exécuter une action en un temps donné.
L’OS à temps partagé, comme son nom l’indique, partage le temps d’exécution de tous les processus qui tournent, et essaie au mieux de répondre à la contrainte de temps imposée, sans garantir d’y parvenir.
Cela dépend d’un OS à l’autre (d’un version du noyau Linux à l’autre et de sa config).
Par exemple, une boucle infinie contenant une temporisation d’une milliseconde pourra en faire 1, mais pourra aussi en faire 2, 3 voire 10 selon la charge système. Ca peut même être pire.
Dès lors, une boucle de régulation qui est censée faire 10ms entre l’échantillonnage d’une valeur et la réaction, pourra en réalité faire 20ms, et la réponse en réaction à l’échantillonnage qui précède n’est alors plus valable.
Dans notre exemple de quadricoptère, une carte électronique type Arduino (ou autre carte à microcontrôleur) pourrait avoir la boucle de régulation implémentée, qui échantillonne avec une régularité parfaite un gyroscope pour avoir la position sur chaque axe, et réagir en fonction de la position demandée. Cette carte ayant un lien avec le Raspberry Pi pour récupérer les consignes de position, et échanger quelques paramètres et informations.
D’ailleurs excellent exemple pour parler de temps réel “dur” et “mou” (soft vs hard real time).
Une action sur un joystick qui mène à la réaction associée du quadcoptère ne sera pas temps réel du tout si la réaction intervient 10 secondes après (crash assuré). Mais heureusement on est pas dans ce cas.
Cette réaction sera catégorisée dans le “temps réel mou” si elle intervient, disons quelques centaines de ms +/- 100ms, après.
Cette réaction sera “temps réel dur” si elle intervient 20ms +/- 1ms après.
On remarque que pour guider le quadricoptère, un temps réel mou est parfaitement acceptable, par contre, c’est moins sûr concernant la boucle qui maintient stable le quadricoptère, indépendamment de la consigne.
Enfin, il faut savoir qu’il y a des sujets qui montrent qu’il est parfaitement possible d’avoir un vol stable avec uniquement le Rapsberry Pi, sans carte additionnelle.
Si la démarche expérimentale est intéressante, la question est de savoir comment se comportera l’engin après quelques mises à jour de l’OS (changement de kernel ?), si on rajoute une clef WiFi, le module caméra, d’autres traitements logiciels, etc… en d’autres termes : si on rajoute de la charge système.