Présentation de l'interface homme-machine¶

L’interface homme – machine est celle qui commande toutes les fonctionnalités de la lanterne. En effet elle permet de commander l’arduino via une communication USB série.
Selon le cahier des charges, l’interface homme – machine est une tablette tactile sous Windows ou iOs, étant donné le coût, nous avons opté pour une tablette hybride Windows.
L’interface homme – machine utilisera une application créé avec Qt. L’installation de cette application et son utilisation est expliqué dans le fichier :

1) Commandes principales¶

Les différentes commandes possibles ont au préalable été définies dans un code implémenté dans le microcontrôleur de l’arduino.
En effet, en fonction du caractère envoyé, on définit la commande du moteur de positionnement de la roue ainsi que pour chaque lumière la commande de couleur d'éclairage.

Commande moteur¶

La commande moteur permet de définir l’ouverture et donc la taille de la tâche projetée.
Cette commande se fait grâce à la fonction commandeMoteur() suivante :

void FenetrePrincipale::commandeMoteur(int ouv)
{
    port->open(QIODevice::ReadWrite);
    switch(ouv)
    {
    case 1 :
        port->write("1");   // Commande ouverture taille 1
    break;
    case 2 :
        port->write("2");   // Commande ouverture taille 2
    break;
    case 3 :
        port->write("3");   // Commande ouverture taille 3
    break;
    case 4 :
        port->write("4");   // Commande ouverture taille 4
    break;
    case 5 :
        port->write("5");   // Commande ouverture taille 5
    break;
    case 6 :
        port->write("6");   // Commande ouverture taille 6
    break;
    }
}

Commande d'éclairage¶

La commande des diodes électroluminescentes (DEL ou LED en anglais) est plus complexe que celle du moteur.
En effet, les lumières doivent s’allumer en suivant les contraintes de scénario soit :

• En fonction du type de test :

Type confusion : Pour les couleurs rouge ou verte il est possible d’allumer en même temps un lumière de confusion rouge, verte ou blanche en fonction de la lumière de référence.
Ce type de test permet de vérifier qu'il n'y a pas de confusion entre les couleurs les plus critiques.

Type DEL unique : Dans ce test seule la lumière centrale s'allume quelque soit le corps d'armée.
Ce type de test permet de vérifier le daltonisme par détection de couleur seule.

• En fonction du corps d’armée du candidat :

Marine : Les lumières sont positionnées l’une à côté de l’autre.
Aviation : Les lumières sont positionnés l’une au dessus de l’autre.

C’est pour cela que j’ai choisi de créer une classe lumière associée à l’élément lumière.
Cette classe possède différentes fonctions (voir code du header de la classe Lumiere) permettant de réaliser les commandes en lumière unique
ou en lumière verticale ou horizontale en fonction du corps d’armée.

#ifndef LUMIERE_H
#define LUMIERE_H
#include "librairies.h" 
class Lumiere
{
public:
    Lumiere(QSerialPort *&port, QLabel *&image, QLabel *&image2);

    QSerialPort *port_en_cours;
    QLabel *image_Centrale, *image_AviationMarine;
    QString couleurDemandee = "";

        // Variables des adresses des images de lumière à afficher
    QString addRouge;
    QString addBlanc;
    QString addVert;
    QString addBleu;
    QString addOrange;

       // Commande Del par Del 
    void commandeLedCentrale(QString couleur);
    void commandeLedAviation(QString couleur2);
    void commandeLedMarine(QString couleur2);

       // Commande globale
    void commandeOff();
    void commande(int cpt);    // Test DEL unique complet
    void commandeConfusion(QString typeArmee, int cpt);   // Test de confusion complet

    void setCouleur(QString nouvelleCouleur);
    QString getCouleur();
private:
        // Compteur de couleurs car chaque lumière s'allume trois fois par scénario
    int cptRouge = 0;
    int cptVert = 0;
    int cptBleu = 0;
    int cptOrange = 0;
    int cptBlanc = 0;

    int coul = 0, coul2 = 0, prec = 0, prec2 = 0;
    int tempsOff, tempsOn;
};
#endif // LUMIERE_H@

Les fonctions commandeLed--(QString couleur) sont similaires et servent à allumer la lumière défini grâce aux valeurs définies dans le code arduino.

Figure 3.1 : Caractère associé aux commandes de couleur

2) Les données¶

Enfin l’interface doit aussi permettre l’enregistrement des données de chaque examen dans un fichier tableur.
N’ayant pas de contrainte, le choix de tableur est un fichier corpsArmee_nom-prenom.csv qui est plus facile pour le traitement.
Le fichier résultant est comme suit :

Figure 3.2 : Tableur CSV sauvergarde des données

Comme le montre la figure précédente, on peut séparer un fichier candidat en quatre parties :

1. Date du jour de l'examen (Rouge)
2. Zone de données personnelles du candidat (Bleu)
3. Zone de données personnelles de l'examinateur (Violet)
4. Zone de résultats du scénario (Orange)

Pour définir la date de l'examen il suffit d'utiliser la classe existante QDate.

Cependant, pour les trois points suivants, j'ai créé deux classes pour chaque élément pour faciliter et améliorer la lisibilité du code.
La première classe définit l'élément principal (le candidat, l'examinateur ou le test).
La deuxième classe définit la création d'une fenêtre pour la collection des données (voir le visuel en partie 3) ).

Les classes candidat, examinateur et fenêtre associé sont très similaire car les données nécessaires sont les mêmes à l'exception de la date de naissance.
Pour ce qui est du scénario, pour la classe test permet d'associer à chaque test du scénario les données d'ouverture, de temps d'exposition et d'extinction
des lumières ainsi que le type (confusion ou non).

Pour conserver les données de l'examinateur même en cas de fermeture de l'application, elles sont sauvegardées dans un fichier examinateur.txt tel que :

Figure 3.3 : Fichier des données examinateur

On retrouve dans ce fichier les données de l'examinateur de la figure3.2.

Examinateur : RYMLAND Solange, personnel navigant de l'aviation.

3) Le visuel¶

La fenêtre principale permettra le visuel de chaque scénario et sert de lien entre toutes les classes créées et utilisées.

Aspect général¶

La fenêtre principale de l'application est composée d'une barre de menu séparée en cinq parties :

• Maintenance (Permet d'effectuer une maintenance manuelle ou automatique)
• Examinateur (Permet de gérer les données de l'examinateur)
• Candidat (Permet de gérer les données du candidat)
• Scénario (Permet de définir un scénario exécuter test par test ou chaque test aléatoirement)
• Exporter données (Permet d'exporter les données dans le fichier vu figure 3.2)

Figure 3.4 : Application visuel global

Maintenance¶

Le menu de maintenance permet de faire la maintenance des lumières en les allumant toutes de la couleur définie de façon manuelle
(cinq premiers choix du menu, couleur par couleur) ou de façon automatique en sélectionnant le mode automatique.

Figure 3.5 : Phase de maintenance (automatique/manuelle)

Dans le premier cas, l'écran affiche simplement une image centrale avec la couleur supposée des lumières en maintenances (Orange sur la figure 3.5).
Dans le second cas, l'écran affiche en plus un message de vérification de la maintenance (Blanc sur la figure 3.5)

Figure 3.6 : Résultat de la maintenance automatique

Lors du choix de la maintenance automatique, il y a deux résultats possibles :

• Toutes les lumières sont fonctionnelles, la maintenance est terminée
• Une des couleurs possèdent au moins une lumière non fonctionnelle, dans ces cas-là un message de demande de changement de lumière.

Données¶

Pour définir/modifier les données concernant l'examinateur, le candidat ou bien les variables de test,
on utilise des fenêtres comme le montre la figure3.7.

figure 3.7 : Fenêtres de collecte des données

Sur les fenêtres précédentes, on retrouve les données du fichier en figure3.2. En effet:

Candidat : PROJET polytech, né le 6 mars 1992, personnel non navigant de l'aviation.
Conditions du test 1 : Test de confusion avec un temps d'affichage 400 ms, un temps d'extinction 1000 ms et l'ouverture 1.

Phase de test¶

En phase de test, il y a 4 affichages différents possibles.

Boutons seuls : phase d'extinction des lumières, permet de sélectionner la réponse du candidat.
Images superposées : phase de test de type confusion pour l'aviation.
Images cote a cote : phase de test de type confusion pour la marine.
Image seule : phase de test lumière unique ou test de confusion.

figure 3.7 : Exemple de tests

Pour les phases de test de type confusion :

la lumière de référence est verte ou rouge.
la lumière de confusion est verte, rouge ou blanche.

Pour les phases de test de type classique :

la lumière de référence est verte, rouge, blanche, orangé ou bleu.

Quel que soit le type de test, il y a trois types d'erreurs:

erreur inacceptable : pas de confusion autorisée entre le rouge et le vert
erreur critique : confusion du rouge ou du vert avec une autre couleur
erreur acceptable : toute confusion entre deux couleurs autre que rouge et vert

3) Ce qu'il reste à faire¶

Pour terminer le projet, il reste des améliorations à faire ainsi que quelques contraintes à respecter :

• Sauvegarde de l'examinateur

Idée : Enregistrer dans un fichier texte les données de l'examinateur qui deviendront référence et resteront sauvegarder en cas de fermeture de l'application
Le fichier texte enregistrant les données de l'examinateur ne fonctionne pas lorsque le lien est relatif et non absolue.
Il faut donc trouver une solution à ce problème ou trouver un autre système de sauvegarde

• Créer un scénario aléatoire

Idée : Sélectionner le nombre de tests choisis pour le scénario.
Afficher autant de fenêtre de sélection de donné des tests qu'il y a de test.
Réaliser aléatoirement chacun des tests définis.

• Créer un scénario type

Idée : Ajouter dans le menu scénario une action "scénario type".
Conserver les données dans un fichier texte pour pouvoir les conserver en cas de fermeture de l'application qui est lu par l'action précédente.
Ajouter dans le menu scénario une action "modifier scénario type" qui permet d'enregistrer dans le fichier texte.

• Définir les paramètres de la machine

Idée : Conserver les données dans un fichier à modifier que lors de changement lanterne.
Les paramètres sont : nom, numéro de série, lieu.
Il faut récupérer ces données dans le fichier en enregistrant.

• Prendre en compte la maintenance

Idée : Il faut réaliser un test entre chaque candidat et donc mettre un message d'erreur si non réalisé.
Bien enregistrer sur le fichier candidat que la maintenance a été réalisé.

• Prendre en compte la connexion USB

Idée : Détecter si le port est débrancher et arrêter le test dans ce cas-là.
Il faut aussi détecter avec quel port communiquer et le prendre en compte dans l’application.
Idée : Sélectionner le port de communication via l’interface

• Visuel

Idée : Améliorer le rendu visuel.

• Enregistrement

Idée : créer un fichier de plusieurs page ou revoir l'organisation des données pour une meilleure lisibilité.

• Autres

Vérifier avec les clients si il n'y a pas de contraintes supplémentaires.

Les codes utilisés pour l'interface sont accessibles à ce lien :
https://forge.clermont-universite.fr/projects/p18ab08/repository/show/application_Lanterne-2
L'utilisation de Qt est expliqué dans la note d'application à ce lien :
https://forge.clermont-universite.fr/documents/1162

<<Choix Techniques / Conclusion>>

couleur_code.JPG - Corresponde couleur _ valeur

fichierExaminateur.PNG - fichier examinateur associé

application.gif - application : visuel global

fenetres.gif - Affichage des différentes fenêtres

maintenance.gif - Phase de maintenance

fichierCSV.PNG - exemple fichier candidat

resultatMaintenance.gif - résultat de maintenance

test.gif