STR : Sujets de travaux pratiques

Cette page présente les sujets de travaux pratiques à réaliser dans le cadre de l’option Systèmes temps-réel. Le texte de ces derniers est volontairement très bref. On se référera à la documentation pour l’API OSEK/VDX, le format des fichiers OIL et l’interface de gestion des capteurs/actionneurs du NXT.

Liens rapides :

Rendus de TP :

  • Que rendre ? Pour chacune des questions du TP, rendre les fichiers OIL et C composant le TP. Dans le cas où une question de TP comporte plusieurs sous questions, mettre l’ensemble des sous questions dans le même fichier source, en indiquant le numéro de sous question correspondant dans les commentaires.
  • Quand le rendre ? Au plus tard au début de la séance suivant celle consacrée au TP.

Créer un nouveau programme

Des scripts ont été mis en place afin de faciliter la création et la compilation de programmes pour les briques Nxt. Leur utilisation dans un terminal requiert l’initialisation de ce dernier par le biais de la commande suivante :

source /share/tr_m1_esir2/env_setup

Pour créer un nouveau programme, le compiler et l’envoyer sur une brique Nxt:

  • nxt_create [project]
  • cd [project]
  • nxt_goil [project].oil
  • make
  • (Under Linux) nxt_send [project]_exe.rxe

nxt_create permet de créer un dossier contenant un fichier source prêt à l’emploi et le oil correspondant. nxt_goil fournit le fichier oil à trampoline pour générer un makefile et d’autres fichiers de l’application. nxt_send envoie un fichier sur une brique branchée en USB, en l’occurrence un exécutable.

Nota Bene: la commande source /share/tr_m1_esir2/env_setup ne fonctionne que pour des shells bash. Si vous utilisez tcsh par exemple, il faudra initialiser votre environnement différemment.

TP 1 – Prise en main : gestion de tâches et ordonnancement – 1 séance

L’objectif de ce premier TP est de prendre en main le système d’exploitation OSEK/VDX. Plus particulièrement, il vise à vous familiariser avec l’édition simultanée de la description du système, dans le fichier OIL, et son implémentation dans le fichier source correspondant. À cette fin, vous allez manipuler les fonctions de gestion de tâches d’OSEK/VDX (ordonnancement, gestion de priorité, démarrage…) et les Hooks OSEK/VDX.

Il est conseillé de profiter de ce premier TP pour préparer une petite librairie facilitant l’affichage de messages successifs sur des lignes différentes. L’interface de gestion de l’écran de la brique ne fournit en effet de base que le positionnement du curseur et l’ajout de texte ou de valeurs entières après ce dernier.

API OSEK/VDX utilisée (voir documentation OSEK/VDX) : PreTaskHook, PostTaskHook, GetTaskID, ActivateTask, ChainTask

Question 1 : bonjour le monde

En utilisant PreTaskHook, PostTaskHook, et GetTaskID, lancer au démarrage du système une tâche qui affiche son TaskID et indique sur l’écran du Nxt qu’elle s’exécute. Les fonctions PreTaskHook et PostTaskHook afficheront un message sur l’écran, respectivement au démarrage et terminaison de la tâche.

Tache 0 : PreTaskHook
Tache 0 : bonjour !
Tache 0 : PostTaskHook

Certains évènements PreTaskHook et PostTaskHook sont déclenchés par la tâche idle du système, dans ces cas, GetTaskID fournit la valeur -1.

Question 2 : lancement et ordonnancement de tâches

  • 2.1. Ecrire le code une tâche Task0 qui lance, par appel à ActivateTask, une tâche Task1 plus prioritaire. Les tâches seront exécutées en mode préemptif (voir documentation OIL). Afficher sur l’écran (via PreTaskHook, PostTaskHook, et GetTaskID) l’ordre d’exécution des tâches. Il est conseillé d’afficher un message avant et après le ActivateTask.
  • 2.2. Reprendre la question 2.1 en utilisant ChainTask() à la place d’ActivateTask().
  • 2.3. Reprendre la question 2.1 en associant une priorité moins élevée à Task1.
  • 2.4. Reprendre la question 2.1 en utilisant un ordonnancement non préemptif pour toutes les tâches.

TP 2 – Application d’affichage (programmation de tâches périodiques et apériodiques) – 2 séances

Dans ce second TP, vous allez manipuler les alarmes OSEK/VDX, ainsi que les notions de date absolues et relatives qui y sont liées. L’utilisation de la notion d’évènement OSEK ainsi que les différents modes de lancement de tâches périodiques ou apériodiques sont aussi explorés. Alarmes et évènements, tout comme les tâches, doivent être déclarées et configurées dans le fichier OIL avant utilisation dans le fichier source correspondant.

API OSEK/VDX utilisée (voir documentation OSEK/VDX) : SetRelAlarm, SetAbsAlarm, CancelAlarm, WaitEvent, SetEvent

Question 1 : premier pas

  • 1.1. Programmer une tâche périodique de période 1 seconde qui affiche à l’écran qu’elle est en cours d’exécution. Pour cela, une tâche peu prioritaire Task0, activée au démarrage, appellera SetAbsAlarm pour déclencher un nombre infini d’exécutions d’une tâche Task1, plus prioritaire. Task1 affichera son TaskID et le temps système à chacune de ses exécutions.
  • 1.2. Reprendre la question 1.1 en programmation directement le déclenchement de l’alarme dans le fichier OIL.
  • 1.3. Reprendre la question 1.1 en déclenchant l’activation suivante de la tâche dans la tâche elle-même. On utilisera indifféremment SetAbsAlarm ou SetRelAlarm, mais on veillera à ce que le code assure la stricte périodicité des activations même si la tâche s’exécutait en présence de tâches plus prioritaires qu’elle.

Expérimenter les fonctions SetAbsAlarm et SetRelAlarm pour comprendre leurs différences et le lien entre la valeur de démarrage fournie, le compteur sous-jacent et le temps système.

Question 2 : une application d’affichage de l’état du robot

Programmer une application d’affichage de l’état de votre robot, composée des tâches périodiques suivantes :

  • Affichage du temps système (toutes les secondes)
  • Affichage de la valeur retournée par un capteur de pression (toutes les 3 secondes)
  • Affichage de la valeur retournée par le détecteur de distance (toutes les 2 secondes)

Question 3 : lancement de tâche apériodique

Ajouter une tâche supplémentaire qui arrête le programme d’affichage, après affichage d’un dernier message, quand on appuie sur le bouton droit. Cette fonctionnalité sera réalisée par une tâche en attente d’un événement OSEK/VDX. L’événement sera signalé par une routine de gestion d’interruptions associée au bouton droit de la brique Nxt.

TP 3 – Détection d’obstacles (tâches périodiques et partage de ressources) – 2 séances

Ce troisième TP a pour objectif de vous faire découvrir la notion de resources OSEK et quelques uns des problèmes liés comme l’inversion de priorité. Une ressource, utilisée à l’aide des primitives GetResource et ReleaseResource, autorise la définition de sections critiques dans des tâches concurrentes. Cela permet par exemple de protéger l’accès à une variable partagée. Comme les alarmes, les ressources doivent être déclarées dans le fichier OIL avant leur utilisation dans le fichier source.

Construire une application composée des trois tâches suivantes et une ressource partagée distance. La variable liée à distance indiquera la distance du pare-chocs du robot aux obstacles l’entourant.

  • Détection_contact : tâche périodique de période 400 ms mettant distance à 0 quand le pare-chocs est en contact avec un obstacle
  • Détection_distance : tâche périodique de période 800 ms mettant distance à jour à partir du résultat du capteur ultrason
  • Navigation : tâche périodique de période 600 ms qui selon la valeur de distance entreprend les actions suivantes :
    • Distance = 0 : marche arrière du robot
    • Distance < 50 : faire tourner le robot (pour éviter l’obstacle)
    • Par défaut : toutes les 10 périodes, changement du cap du robot (virage à droite ou à gauche d’un angle aléatoire avant de continuer tout droit)

Que se passe-t-il si les pare-chocs détectent un obstacle à ras de terre mais que le capteur ultrason est interrogé avant que la tâche de navigation ne s’exécute ? Proposer une modification du système pour pallier à ce problème.

TP 4 – Suivi dynamique d’objets – 1 séance

Ce dernier TP vise à vous faire manipuler les différentes notions et principes OSEK appréhendés dans les travaux précédents..

Question 1 : Suivi dynamique d’objets

Construire une application qui utilise le capteur ultrason pour localiser un objet, et s’en approche à 20cm. Cela implique que le robot se rapproche de l’objet s’il en est trop loin, et s’en éloigne s’il en est trop près. Quelques remarques :

  • Vous vous êtes déjà rendus compte que le capteur ultrason n’était pas très précis. Utilisez un livre ou une feuille de carton pour tester vos programmes, cela devrait stabiliser les résultats.
  • Vous pouvez expérimenter différentes périodicités ou priorités pour améliorer la nervosité des diverses tâches. Notez cependant qu’il faut un temps minimum au capteur ultrason pour stabiliser ses résultats. L’expérience montre que des lectures espacées de moins de 100ms dégradent la qualité des résultats.
  • Une stratégie élégante pour choisir la vitesse du robot consiste à choisir une valeur proportionnelle à la différence entre la distance mesurée et la distance souhaitée. En théorie du contrôle, on appelle ça un contrôleur proportionnel (ou “P-contrôleur”). Les élèves intéressés par approfondir cet aspect pourront essayer d’implémenter un PID complet.

Pour aller plus loin

Les applications développées dans le cadre de ces travaux ne font qu’effleurer les mécanismes proposés dans la spécification OSEK/VDX avec notamment les alarmes, les tâches, les resources et les évènements. Vous pouvez expérimenter d’autres outils de base comme les points d’ordonnancement (avec la fonction Schedule en mode non-préemptif), la notion de messages et de boîte aux lettres, les AlarmCallbacks ou les extensions comme les tables d’ordonnancement.

Comments are closed.