Apport d’un ordonnancement WRR dans le cas de la commande d’un drone

2.3.2.1. Présentation du drone

Le drone est un véhicule aérien contrôlé par les vitesses de rotation de quatre pales, pour cela le drone dispose de quatre moteurs électriques (figure 2.9). Sur ce drone, il est possible d’embarquer une caméra afin d’envoyer des images via le réseau sans fil sur une station terrestre.

Figure 2.9. Benchmark du drone (Diouri et al., 2008)

Le développement des équations a été fait en utilisant deux repères : le repère inertiel R(ex, ey, e_z) et le repère propre au drone B(e₁, e₂, e₃) ayant pour origine le centre de gravité de celui-ci.

L’attitude du drone est décrite par les 3 angles de rotation roulis (φ), tangage (θ) et lacet (ψ) qui sont représentés dans le repère B (figure 2.9).

Le drone est contrôlé en faisant varier indépendamment les vitesses de rotation de chaque moteur électrique. La description complète du modèle mécanique a été donnée dans (Tanwani et al., 2007). La figure 2.10 représente l’architecture du drone après avoir embarqué un réseau. Les réseaux qui ont été étudiés dans (Diouri et al., 2008) sont CAN et Ethernet commuté. Le but de l'étude suivante va alors être de montrer qu'un ordonnancement WRR peut permettre à Ethernet de remplacer un réseau de terrain déterministe et conventionnel comme le réseau CAN.

Figure 2.10. Architecture du drone incluant le réseau embarqué (Diouri et al., 2008)

Les capteurs envoient 9 mesures de manière périodique avec une période d’échantillonnage . Par contre, l’envoi des commandes est événementiel et le contrôleur attend de recevoir toutes les mesures avant de procéder au calcul de la commande (Berbra et al., 2007). Le contrôleur envoie quatre signaux de commande (une pour chaque moteur local) aussitôt qu’il achève le calcul de celle-ci. Le débit du réseau CAN est de 1 Mb/s et celui du réseau Ethernet commuté est de 10 Mb/s. Pour le réseau CAN, la taille des paquets qui rentre dans la commande du drone est de 59 bits tandis que pour le réseau Ethernet la taille des paquets du même type est de 72 octets (taille minimale d’une trame Ethernet). Ici, le réseau Ethernet commuté s'apparente à une architecture centralisée où tous les équipements sont interconnectés sur un même commutateur.

2.3. Exemples illustrant l’impact des délais sur le comportement d’un SCR utilisant le réseau Ethernet 43

Dans les deux cas, le réseau devra supporter le transport d’un trafic assimilable à une vidéo qui transmettrait 256 niveaux de gris à l’unité de commande principale « Main control unit ». Dans le cas du réseau CAN, le flux relatif à la transmission vidéo est le moins prioritaire. Tandis que pour le réseau Ethernet commuté il existe deux classes de services : la première concerne tous les paquets de commande et de mesure et la seconde concerne tous les paquets du trafic de fond.

2.3.2.2. Impact des délais sur la commande du drone

Dans les expérimentations qui ont été menées, la consigne a été fixée à (0, 0, 0) pour les angles (φ, θ, ψ) et l’état initial de ces derniers est (-25, -30, -10). Les figures 2.11.a, 2.11.c et 2.11.e montrent le comportement du réseau CAN. Dans le cas d’un trafic non-synchronisé (quand le flux vidéo est envoyé juste avant les autres flux), on remarque qu’il y a une dégradation au niveau de la phase transitoire. Ceci peut s’expliquer par le fait qu’un paquet du flux de commande doit attendre que le paquet du flux vidéo ait été transmis avant d’être transmis à son tour. D’un autre côté, les figures 2.11.b, 2.11.d et 2.11.f montrent que dans le cas de l’Ethernet standard et dans le cas de l’Ethernet commuté sans classification de service, l’introduction du flux vidéo dégrade dramatiquement la commande du système. Ces résultats montrent clairement que le débit n’apporte pas toujours une réponse satisfaisante pour contrôler un SCR puisque le réseau CAN à 1Mb/s donne de meilleurs résultats qu’un réseau Ethernet à 10Mb/s.

2.3. Exemples illustrant l’impact des délais sur le comportement d’un SCR utilisant le réseau Ethernet 45

Ainsi, dans le cas de l’Ethernet commuté, il a fallu implémenter un protocole d’ordonnancement équitable adéquat et cela afin de stabiliser le système et de maximiser la bande passante allouée au flux vidéo (chapitre 3).

Comme signalé, le comportement du drone a été simulé en utilisant le logiciel Matlab/Simulink et les différents réseaux ont été simulés à l’aide du logiciel TrueTime (Andersson et al., 2005). Cependant, dans la boîte à outils TrueTime, il est impossible d’évaluer les performances d’un réseau Ethernet commuté implémentant la CdS et le protocole d’ordonnancement WRR. De ce fait, il a fallu développer un module WRR sur le logiciel TrueTime.

2.3.2.3. Extension du bloc réseau TrueTime pour la simulation d’un ordonnancement WRR

Dans un premier temps, le comportement du WRR sur le réseau Ethernet commuté est apporté à TrueTime. Les parties entourées sur la figure 2.12 montrent les paramètres du bloc réseau de TrueTime que nous avons ajoutés ainsi que le paramétrage du réseau Ethernet commuté implémentant le protocole d’ordonnancement WRR « Switched Ethernet (WRR) ». Le champ « Switch initial weights priorities » permet d’affecter les poids initiaux pour chaque classe de trafic en commençant par celle qui a la plus haute priorité. Dans la figure 2.12, on distingue deux classes de trafic : celle ayant la plus haute priorité peut émettre une trame par cycle et la deuxième peut émettre 255 trames par cycle.

Figure 2.12. Les paramètres du bloc réseau étendu de TrueTime (Diouri et al., 2008)

2.3.2.4. Apport du WRR dans le cas du drone (Diouri et al., 2008)

La figure 2.13 montre le comportement du drone (qui a été présenté dans le paragraphe 2.3.2.1) dans le cas d’une architecture Ethernet commutée à 10 Mb/s implémentant le protocole d’ordonnancement WRR et soumise à un trafic de fond qui perturbe la commande. Pour la figure 2.13, le poids du trafic temps-réel a été fixé à 9 et celui du trafic de fond a été fixé à 3.

2.3. Exemples illustrant l’impact des délais sur le comportement d’un SCR utilisant le réseau Ethernet 47

Figure 2.13. Ethernet commuté à 10 Mb/s, avec une CdS WRR et avec un trafic de fond non synchronisé (Diouri et al., 2008)

Une comparaison entre les figures 2.11.f et 2.13 montre que grâce au WRR, on arrive à stabiliser la commande du drone même en présence d’un trafic de fond (figure 2.13). En effet, les angles (φ, θ, ψ) atteignent bien la consigne qui a été fixée à (0, 0, 0) (à noter que sur la figure 2.13 : « Roll » correspond à φ, « Pitch » correspond à θ et « Yaw » correspond à ψ). D’autre part, on remarque d’après la figure 2.13 que le réseau Ethernet commuté implémentant le WRR nous a permis de réduire l’impact de la charge sur la commande du système (figures 2.11.d et 2.11.f) et nous a permis d’avoir un comportement du système similaire à celui obtenu en utilisant le réseau CAN (figure 2.11.e). Les valeurs des poids appliquées pour cette simulation seront discutées dans la suite de ce mémoire (paragraphe 3.7.1)