9.2
Simulation HIL et respect des contraintes
Nous allons dans un premier temps illustrer les conséquences possibles d’un non respect des Contraintes temporelles fixées via des résultats de simulation Hardware-in-the-Loop. Il s’agit là d’une version plus détaillée de l’exemple proposé dans [LRP+15]. Il nous faut préciser que dans
[LRP+15] notre Atome P ID avait été remplacé par un autre Atome qui réalisait un contrôle
de type P D avec les coefficients choisis. Cela souligne l’évolutivité et la modularité de notre approche. Nous avons par contre choisi, dans cet exemple, d’illustrer l’exemple de l’Atome P ID, à la fois car le terme intégrateur était nécessaire du point de vue expérimental et car il permettait de mieux mettre en évidence certains aspects de conception liés aux Alternatives notamment au niveau des Entités Composables de jonction.
Comme le simulateur ne nous impose pas de contraintes temporelles au niveau des capteurs (puisqu’il s’agit de capteurs virtuels), nous avons choisi de faire fonctionner les deux parties temporellement indépendantes à des périodes différentes. En effet, lors des expérimentations de la prochaine section et du chapitre suivant, les contraintes de fonctionnement de nos capteurs matériels (IMU, Loch Doppler et capteur de profondeur) ne nous permettront pas de faire cela et toutes les entités de la Composition devront fonctionner à une période identique même si elles ne sont pas temporellement couplées.
Nous avons ainsi choisi de faire fonctionner les Atomes des Molécules Navigation et Actuation à une période de 25ms. Les autres entités (Alternative contenant l’asservissement et changement de repère) fonctionneront à une période de 50ms.
9.2.1
Simulation Hardware-in-the-Loop, non respect des contraintes
La Figure 9.8 présente une de nos premières simulations de l’asservissement en cap effectuée avec le simulateur HIL. Dans cette simulation, notre PID avait pour paramètres Kp = 10, Kd = 10 et KI = 0. Comme nous pouvons le constater, après s’être stabilisé à une valeur proche du cap désiré, le comportement du robot devient instable et il commence à osciller avec de plus en plus d’amplitude. Il effectue ensuite deux tours sur lui-même avant de se stabliser à nouveau à sa valeur de consigne.
La cause de cette instabilité se trouve dans un non respect temporaire des Contraintes temporelles que nous nous sommes fixées.
La Figure 9.9 illustre l’occurrence du phénomène sur un des modules ContrACT utilisés (celui qui contient les Atomes effectuant l’asservissement en cap). Comme nous pouvons le constater, durant une grande partie de l’exécution, l’écart oscille autour de la période no- minale du module (50ms). Mais, à trois reprises, la durée entre deux cycles successifs viole
Figure 9.8 – A cause du non respect des Contraintes temporelles, l’asservissement en cap perd sa stabilité
les contraintes fixées avec des deltas respectifs de 482ms, 218ms et 518.2ms. Si la première violation ne provoque pas d’instabilité, les deux suivantes entraînent le comportement observé Figure 9.8. La raison de ce comportement est à trouver dans la manière dont nous réalisions les logs de données jusque là. En effet, les données d’exécution des modules (entrées, sorties, durées d’exécution) étaient stockées dans des fichiers dans la mémoire de la BeagleBone. En outre, le module ordonnanceur de ContrACT loggait lui aussi ses données d’exécution (date d’activation des différents modules, date d’arrêt de leur exécution, apparition de retards, pré- emptions).
Lorsque les données doivent être écrites dans un fichier (en utilisant la fonction fprintf ), elles sont d’abord bufferisées avant d’être effectivement écrites dans le fichier une fois le buffer plein. Or, c’est cette écriture mémoire qui, sur la BeagleBone, pose problème. En effet, sa mémoire utilisée pour stocker les données est une mémoire eMMC. L’écriture dans une mémoire de ce type est non préemptible, c’est-à-dire qu’une fois démarrée, nos modules doivent attendre que l’écriture soit terminée avant de pouvoir reprendre leur exécution.
Nous avons donc décidé de changer notre manière d’effectuer les logs de données afin d’éviter ce problème. Pour tous les modules applicatifs, nous avons choisi d’utiliser un module dédié, chargé de collecter les données d’exécution des autres modules puis de les transmettre au PC de supervision où elles seront stockées dans un fichier. Nous avons également désactivé le log réalisé par le module ordonnanceur afin qu’il ne perturbe pas l’exécution nominale de notre application tout en nous autorisant sa réactivation si besoin est.
9.2. Simulation HIL et respect des contraintes
Figure9.9 – Délais entre deux cycles d’exécution consécutifs du module d’asservissement en cap
9.2.2
Simulation avec contraintes respectées
Une fois ces modifications réalisées, l’exécution de notre application va respecter les Contraintes temporelles fixées. Un exemple de simulation est proposé Figure 9.10.
Nous avions pour coefficients Kp = 10, Kd = 10 et KI = 0 avec un bruit de 0.1 rad sur la mesure de cap et de 0.05 rad.s−1 sur la mesure de vitesse angulaire.
Figure9.10 – Asservissement en cap avec Contraintes temporelles respectées.
Pour implémenter notre Composition, nous avons utilisé 6 modules ContrACT. Le premier Sensors regroupe la réception des données capteurs (IMU, Loch Doppler et capteur de profon-
deur) provenant du simulateur et le second Actuators gère l’envoi des consignes actionneurs au simulateur. Le module MDynamic contient le modèle dynamique et enfin Navigation contient la navigation du robot (ici simplifiée puisqu’elle ne contient que la partie relative à l’asservissement en cap). Ces quatre modules sont regroupés dans un schéma, nommé C1, fonctionnant à une période de 25ms. L’asservissement en cap est mis en œuvre dans le module Control et le changement de repère est effectué dans le module F rameShif t, les deux étant regroupés dans un schéma, nommé C2, fonctionnant à une période de 50ms. Nous présentons dans les deux figures suivantes, les écarts entre le début effectif de chaque cycle et le début théorique de celui-ci basé sur la période d’exécution de chaque module. Ainsi, le délai, pour un cycle i, est calculé comme :
delaii = tstart_thei − tstart_reali (9.29)
avec :
tstart_thei = tstart_real0 + i ∗ period (9.30)
Nous voyons clairement l’apparition de délais dûs aux temps de calculs variables au sein des modules et à l’exécution de schémas à des périodes différentes (nous verrons plus loin que, lorsque tous les modules s’exécutent à la même période, l’évolution de ces retards est beaucoup plus régulière). Néanmoins, l’ordonnanceur arrive à le compenser afin de les garder dans une proportion acceptable vis à vis des périodes d’exécution, comme le montre le Tableau 9.1. Le module le plus affecté par les erreurs est le modèle dynamique. En effet, il s’agit d’un des plus lourds du point de vue calculatoire, ce qui le rend plus délicat à placer pour l’ordonnanceur.