Le projet temps-réel se déroulera en coopération avec le projet de code embarqué. Vous allez analyser dans OTAWA, et ensuite chercher à optimiser, le code que vous allez développer pour le pilotage de quadcopter. L’analyse temporelle sera fait sur les parties du code qui traitent les données acquises par les capteurs pour décider à la prochaine commande à envoyer aux contrôleurs.
D’ailleurs, pendant le projet de code embarqué, il est fortement conseillé de penser à écrire du code “analysable”. L’analyse dans OTAWA est faite à la granularité d’une fonction. Il vous donc faudra séparer les parties du code qui font le traitement des données, et de mettre chacune dans une fonction séparée.
Pour piloter les quadcopter, vous aurez à réaliser une application temps-réel strict pour une application critique : les quadcopters, malgré leur petite taille, peuvent réellement faire des dégâts sur le matériel ou sur les personnes !
Pour ce faire, l'application est généralement découpée en tâches ayant les caractéristiques suivantes :
Pour appeler les tâches selon leurs périodes, le programme principal est organisé sous forme d'une boucle infinie contenant :
En général, cette boucle va à la vitesse de la période la plus courte, P. Pour que notre système temps-réel strict soit ordonnaçable et, par conséquent, qu'il assure que les échéances de chaque tâche soit respectée, il faut s'arrurer qu'à tout moment, la somme des WCET des tâches activée est inférieure à P. Quand cette condition n'est pas vérifié, on a plusieurs possibilités :
Pour ces fonctions, il faut faire attention à :
Sous Linux, il ne sera possible de faire des entrée-sorties non gérées par le noyau que par scrutation. Ceci étant, une gestion d'entrée-sortie par scrutation est une tâche comme une autre : il suffit de déterminer la période utile.
Certaines extensions de Linux permettent vraiment de faire du temps-réel strict mais ce n'est pas le cas de notre installation, Angstrom Linux, qui est surtout intéressant pour sa légèreté. Cependant, notre application n'a pas un niveau critique très élevé et les expérimentations ont montré que le noyau (si aucun autre code ne tourne en même temps) est d'une grande régularité.
De manière générale, le noyau de BeagleBone permet une fréquence minimale de 10ms qui devrait être suffisante pour nos quadcopters.
Pour la précision, il est important de travailler avec des dates constatées (plutôt que les dates prévues). Cela permet d'adapter les calculs au temps réel constaté entre deux activations et à possible “gigue” de ce temps. Pour ce faire, on peut utiliser la fonction gettimeofday(). Elle donne le temps en us (même si on peut constater que la précision est un peu moindre).
Une manière intéressante d'éviter les attentes actives peut être l'utilisation des signaux Unix. Les fonctions suivantes peuvent être intéressantes :
signal() permet d'installer un gestionnaire de signaux par exemple sur le signal SIGALRM.sigaction() est beaucoup plus intéressant et permet de mieux contrôler les gestionnaires de signaux.setitimer() permet de mettre en place un timer périodique et de déclencher un signal.Pour pouvoir calculer le temps d'exécution, vous devez au moins traiter les problèmes suivants :