L’accès à certaines fonctionnalités embarqués sur un avion de combat (navigation, systèmes d’armes, désignateur, …) passe par un écran multifonctions (MultiFunction Display). Bien que certains simulateurs proposent un cockpit cliquable, il est toujours embêtant de devoir orienter le champ de vision à chaque fois que l’on souhaite effectuer une action. Du coup, l’utilisation d’un périphérique matériel augmente l’immersion et améliore l’expérience de jeu.

Les solutions commerciales existantes (ThrustMaster Cougar Pack) ne m’ayant pas impressionné, j’ai décidé de concevoir un écran multifonction fonctionnant sur USB.

Le projet que je présente est conçu pour fonctionner avec DCS. Cependant, comme il utilise un écran HDMI et des contrôles type joystick, il n’y a pas de raisons pour que ça ne marche pas avec d’autres simulateurs.

Principes de fonctionnement

L’idée consiste à configurer DCS pour envoyer l’image des MFD gauche et droite sur deux écrans supplémentaires. Pour ce faire, il faut créer un fichier de configuration dans le dossier MonitorSetup du jeu et ajouter ces deux paramètres (il faut bien évidemment ajuster les offsets pour tomber dans les bons écrans) :

_  = function(p) return p; end;
name = _('MFD_Display');
Description = 'Config maison'
Viewports =
{
     Center =
     {
          x = 1920;
          y = 0;
          width  = 1920;
          height = 1080;
          viewDx = 0;
          viewDy = 0;
          aspect = 1.6;
     }
}

LEFT_MFCD =
{
    x = 1920*2+(1024/2-768/2);
    y = 0;
    width  = 768;
    height = 768;
}

RIGHT_MFCD =
{
    x = 1920*2+1024+(1024/2-768/2);
    y = 0;
    width  = 768;
    height = 768;
}

UIMainView = Viewports.Center
GU_MAIN_VIEWPORT = Viewports.Center

L’assignation des touches se fait simplement dans DCS, comme n’importe quel autre périphérique d’entrée.

Pour l’affichage, j’ai choisi un écran LCD 4:3 de 8 pouces. Il a une résolution de 1024×768 :

​​

Son prix et sa taille en font une solution intéressante : https://fr.aliexpress.com/item/32325920866.html?spm=a2g0s.9042311.0.0.d0dd6c37EdzyS4​

L’électronique

Conception

Pour simplifier l’intégration matérielle, j’ai choisi d’utiliser un petit microcontrôleur de chez Microchip capable de faire de l’USB et de l’I2C : le PIC18F25K50. Il communique avec 4 cartes filles qui s’occupent chacune de 7 boutons.

La séparation en plusieurs cartes répond à deux impératifs :

1. Rentrer dans une conception Autodesk EAGLE version gratuite
2. Diminuer les coûts de fabrication en réduisant la surface de circuit imprimé

La carte mère sera montée au dos du MFD :

Deux cartes en angle et deux cartes droites permettent de former un cadre autour de l’écran LCD :

​ ​

La carte mère

La carte mère du MFD se contente de faire le lien entre les différentes cartes filles (I2C) et le PC (USB). Le schéma est donc des plus simples, il reprend celui de la boite à boutons ou de l’interface HID, mais avec un composant différent :

​On retrouve une horloge, un circuit de reset, le connecteur USB, un connecteur pour l’I2C et un connecteur de programmation. Pour changer mes habitudes, j’ai réalisé mes cartes avec des composants à montage en surface (CMS) :

Les cartes filles

Bien que 2 formes différentes soient nécessaires, elles ont toutes le même schéma (à la différence de l’adresse). Il s’agit d’un multiplexeur 8 entrées tout ou rien vers I2C MCP23008. Les résistances de tirages sont intégrées dans la puce. Les cartes sont adressées par un pont à souder pour le bit de poids faible et câblé en dur à 1 pour les cartes en L (0 pour les cartes en I).

Deux connecteurs I2C permettent de former une chaine avec les 4 cartes. Un troisième permet de relier la carte mère sur l’une des cartes filles.

La configuration des boutons à bascules présents aux 4 coins du MFD oblige à avoir deux formes de cartes:

​

​

Les dimensions sont adaptées à la taille de l’écran de 8 pouces et au boitier imprimé en 3D dessiné tout spécialement.

Réalisation

J’ai sous-traité la fabrication des PCB (double couches) à NextPCB.

Les soudures des composants CMS sont réalisées au fer à souder, avec une panne fine. Pour rendre cela possible, j’ai choisi des boitiers SOIC (gros composants CMS, pas de 1.27mm) et des formats 0805 pour les résistances et condensateurs. Finalement, le composant le plus petit et le plus difficile à souder est la LED indiquant la mise sous tension.

NB : une bonne pince brucelles est nécessaire !

Intégration mécanique

J’ai fait découper au LASER des tôles d’inox pour réaliser les faces avant (https://www.metal-laser.com/). Le boitier plastique qui accueille ​les cartes filles ainsi que les différentes touches sont imprimés en 3D. La conception mécanique et l’intégration des cartes électroniques a été réalisée à l’aide Fusion 360. Cet outil permet de facilement faire converger les CAO électroniques et mécaniques.

Il est important de pouvoir vérifier la profondeur du boitier plastique, notamment pour que les boutons poussoirs tombent en dessous des touches plastiques.
​

L’écran LCD est fixé (scotché ou collé) à l’arrière du cadre. La face avant est également collée au boitier plastique.

Le logiciel

Une fois n’est pas coutume, le code du microcontrôleur a été écrit en C à l’aide de MikroC. Outre l’initialisation de la puce et le driver des multiplexeurs, la boucle principale se contente de lire les 4 ports d’entré sur l’I2C et d’envoyer le rapport USB HID.

/**
* Version IO Expander MCP23018
**/

#include "MCP23008.h"

#define USB_BUFFER_LEN       4
#define NB_MCP               4

unsigned char readbuff[USB_BUFFER_LEN] absolute 0x500;
unsigned char writebuff[USB_BUFFER_LEN] absolute 0x540;

int reset_mcp23017 = 1;

void interrupt() {
    USB_Interrupt_Proc();        // USB servicing is done inside the interrupt
    USBIF_bit = 0;
}

// define callback function
void I2C1_TimeoutCallback(char errorCode) {
   if (errorCode == _I2C_TIMEOUT_RD) {
     //LED0 = 1;
     // do something if timeout is caused during read
   }

   if (errorCode == _I2C_TIMEOUT_WR) {
     //LED1 = 1;
     // do something if timeout is caused during write
   }

   if (errorCode == _I2C_TIMEOUT_START) {
     //LED0 = 1;
     // do something if timeout is caused during start
   }

   if (errorCode == _I2C_TIMEOUT_REPEATED_START) {
     //LED1 = 1;
     // do something if timeout is caused during repeated start
   }
   
   reset_mcp23017 = 1;
}
          
void main() {
    int i = 0;
    int cpt = 0;
    
    uint16_t temp;

    ANSELA = 0;
    ANSELB = 0;
    ANSELC = 0;
    SLRCON = 0;

    ADCON1 |= 0x0F;                         // Configure all ports with analog function as digital
    CM1CON0 |= 7;                           // Disable comparators

    TRISB = 0xff;
    TRISB.f2 = 0;
    LATB.f2 = 1;

    I2C1_Init(400000);         // initialize I2C communication
    
    // set timeout period and callback function
    I2C1_SetTimeoutCallback(40000, I2C1_TimeoutCallback);

    reset_mcp23017 = 1;

    FSEN_bit = 1;
    UPUEN_bit = 1;
    HID_Enable(&readbuff,&writebuff);
    
    // Enable USB device interrupt
    IPEN_bit = 1;
    USBIP_bit = 1;
    USBIE_bit = 1;
    GIEH_bit = 1;

    while (1) {
        if (reset_mcp23017) {
           LATB.f2 = 0;       //RESET MCP23017
           Delay_ms(250);
           LATB.f2 = 1;
           Delay_ms(250);

           for (i=0; i<NB_MCP; i++) {
            MCPreset(i);
            Delay_ms(5);
           }
          reset_mcp23017 = 0;
        }

        memset(writebuff, 0x00, USB_BUFFER_LEN);
    
        for (i=0; i<NB_MCP; i++) {
          temp = MCPread(i, GPIO);
          writebuff[i] = ~temp;
          Delay_ms(5);
          if(reset_mcp23017) break;
        }
        
        HID_Write(writebuff, USB_BUFFER_LEN);
        Delay_ms(5);
    }
}

Le premier test

Un dock USB 3.1 peut servir pour gérer le HDMI et l’USB simultanément, ce qui permet d’avoir une unique prise USB occupée sur le PC. Si la configuration de DCS est correcte et que l’écran est bien détecté, voici le résultat que l’on peut obtenir :

La même chose en vidéo :

Conclusion

Il me reste encore à imprimer des touches propres et à finir l’état de surface de la face avant. Pour le reste, le rendu est vraiment sympa. Reste à tester réellement sur une session de pilotage plus longue.

Cet article Écran multifonction pour simulateur de vol (MFD) est apparu en premier sur Electronique et Informatique.

Le retour de l’interface USB HID !

Introduction

Quand les potes disent vouloir jouer à DCS World en multijoueurs, l’électronicien qui sommeil en moi se dit « Il me faut plus de boutons ! ». En effet, les périphériques de jeux habituels sont relativement peu pourvus en boutons, et démarrer un avion de chasse est un peu plus complexe que démarrer une Twingo. L’idée a donc germée de concevoir une électronique vue comme un joystick et proposant des entrées tout ou rien et/ou analogiques. Il est ainsi possible de réaliser son tableau de bord, avec de vrais boutons, des étiquettes… Bref, on s’y croirait.

Conception de la carte

Spécifications

Comme on ne change pas une équipe qui gagne, je suis reparti de ma première version de l’interface USB HID. Voici quelques éléments en vrac:

• Alimentation par le bus USB
• MCU : PIC18F4550 cadencé à 48MHz par un quartz 24MHz
• Carte compacte
• pas de composants additionnels à prévoir pour les entrées tout ou rien
• 16 entrées ToR
• 8 entrées analogiques 10 bits

Il me fallait écouler un vieux stock de PIC18F4550 en format DIP40, donc le CMS sera pour une prochaine réalisation. Les entrées se font sur des borniers à vis au pas de 2.54mm. Les résistances de pull-up internes au PIC permettent d’exploiter directement les ports B et D en tout ou rien. Le port A est utilisé en entrées analogiques.

Schéma et PCB

Le schéma de la carte ne constitue en rien une révolution. On retrouve presque à l’identique celui de ma première interface.

L’implantation est par contre beaucoup plus compacte.

Réalisation

Pour une fois, j’ai décidé de sous traiter la fabrication des circuits (au-delà d’un exemplaire, la gravure à la fraiseuse n’est pas franchement efficace). J’ai donc envoyé tout ça chez les chinois (NextPCB pour ne pas les citer). Le résultat est impeccable, pour un prix de revient d’1.60€/pièce, port compris :

Seul petit bémol : la durée de livraison pour l’expédition économique : compter plusieurs semaines. Place à la soudure !

Programmation

Là encore, rien de révolutionnaire : le code est écrit en C avec MikroC for PIC. Les PIC sont ensuite flashés en série grâce à un PicKit et MPLAB IPE.

Le descripteur HID déclare donc 16 entrées switch et 8 axes analogiques:

hid_rpt_desc =
  {
    0x05, 0x01,                    // USAGE_PAGE (Generic Desktop)
    0x15, 0x00,                    // LOGICAL_MINIMUM (0)
    0x09, 0x04,                    // USAGE (Joystick)
    0xa1, 0x01,                    // COLLECTION (Application)
    0x05, 0x02,                    //   USAGE_PAGE (Simulation Controls)
    0x09, 0xbb,                    //   USAGE (Throttle)
    0x09, 0xc5,                    //   USAGE (Brake)
    0x15, 0x00,                    //   LOGICAL_MINIMUM (0)
    0x26, 0xff, 0x00,              //   LOGICAL_MAXIMUM (255)
    0x75, 0x08,                    //   REPORT_SIZE (8)
    0x95, 0x02,                    //   REPORT_COUNT (2)
    0x81, 0x02,                    //   INPUT (Data,Var,Abs)
    0x05, 0x01,                    //   USAGE_PAGE (Generic Desktop)
    0x09, 0x01,                    //   USAGE (Pointer)
    0xa1, 0x00,                    //   COLLECTION (Physical)
    0x09, 0x30,                    //     USAGE (X)
    0x09, 0x31,                    //     USAGE (Y)
    0x09, 0x32,                    //     USAGE (Z)
    0x09, 0x33,                    //     USAGE (Rx)
    0x09, 0x34,                    //     USAGE (Ry)
    0x09, 0x35,                    //     USAGE (Rz)
    0x95, 0x06,                    //     REPORT_COUNT (6)
    0x81, 0x02,                    //     INPUT (Data,Var,Abs)
    0xc0,                          //   END_COLLECTION
    0x05, 0x09,                    //   USAGE_PAGE (Button)
    0x19, 0x01,                    //   USAGE_MINIMUM (Button 1)
    0x29, 0x10,                    //   USAGE_MAXIMUM (Button 16)
    0x15, 0x00,                    //   LOGICAL_MINIMUM (0)
    0x25, 0x01,                    //   LOGICAL_MAXIMUM (1)
    0x75, 0x01,                    //   REPORT_SIZE (1)
    0x95, 0x10,                    //   REPORT_COUNT (16)
    0x55, 0x00,                    //   UNIT_EXPONENT (0)
    0x65, 0x00,                    //   UNIT (None)
    0x81, 0x02,                    //   INPUT (Data,Var,Abs)
    0xc0                           // END_COLLECTION
  };

Le rapport USB associé est le suivant:

Utilisation

Le câblage des entrées analogiques peut exploiter l’alimentation de la carte (5V sur USB) pour utiliser des potentiomètres:

Le câblage des boutons se fait entre la broche d’entrée et la masse. La résistance de pull-up interne s’occupe de polariser l’entrée quand le bouton est ouvert.

Une fois le tout branché et l’USB relié au PC, Windows devrait voir un nouveau périphérique de jeu:

Conclusion

Il ne reste qu’à faire la mécanique !

Cet article Boite à boutons pour simulateurs est apparu en premier sur Electronique et Informatique.

Si vous aussi êtes fan de Mass Effect et avez investi dans l’édition collector de Mass Effect Andromeda, vous vous retrouvez sans doute avec un Nomad ND1 télécommandé par smartphone. Comme l’application Android est toute nulle perfectible et peu stable, il parait intéressant de piloter ce petit drone roulant à partir d’un PC ou, pourquoi pas, d’une radio commande conventionnelle.

Pour ce faire, je vais décortiquer la communication mise en place entre le Nomad et le smart phone.

Deux types de communication

Le Nomad est télécommandé (vitesse, direction, allumage des feux) mais dispose également d’une caméra afin de fournir un retour vidéo temps réel. Du coup, deux communications différentes sont utilisées.

Connexion WiFi

Tout d’abord, il est bon de préciser que la communication radio entre le smartphone et le Nomad est basée sur une liaison WiFi 2.4GHz. Le Nomad est un point d’accès avec serveur DHCP. Quand on connecte un périphérique réseau sur le Nomad, on obtient automatiquement une adresse IP.

Le Nomad sera toujours accessible à l’adresse 192.168.0.1.

Retour Vidéo

Je commence par exposer le fonctionnement du retour vidéo puisqu’il s’agit du moins complexe et qu’il peut être solutionné avec des logiciels comme VLC.

Le Nomad se comporte comme une caméra IP. Il héberge un serveur de streaming RTSP. Le point d’accès vidéo est vs1. Il est donc possible d’ouvrir le flux vidéo en accédant à l’adresse:

rtsp://192.168.0.1/vs1

Télécommande

L’envoie des commandes au Nomad est un peu plus artisanal. En effet, la messagerie entre le smartphone et le Nomad exploite une communication UDP sans protocole standard particulier. Les informations qui vont suivre sont issues de mes observations et d’analyses réseaux faites avec WireShark. N’ayant qu’un seul Nomad sous la main, il est possible que le comportement décrit ne soit pas identique pour tous les modèles.

Première connexion

La communication UDP bidirectionnelle s’établit sur le port 8234. Comme l’UDP n’est pas un protocole en mode connecté, il est nécessaire de pouvoir vérifier la présence d’un interlocuteur de l’autre côté de la liaison. Pour ce faire, le Nomad propose une commande de ping.

Il est possible d’envoyer la chaine MAKO_CONNECT et le Nomad répond CONNECT_OK.

On notera au passage l’amalgame entre le mako et le nomade qui laisse supposé l’existence d’un mako radiocommandé?

Récupération du statut

Il est possible de récupérer l’état général du Nomad (niveau de batterie et allumage des feux). Pour ce faire, il faut envoyer la chaine MAKO_READ_BATT. Le Nomad va alors répondre trois lignes:

BATT=%d
LED1=%b
LED2=%b

On obtient le niveau de batterie entre 0 et 100%, ainsi que l’état des deux groupes de feux avant (0=éteint, 1=allumé)

Allumage des feux

Pour gérer les feux avant du Nomad, il y a les commande MAKO_LED%d_ON et MAKO_LED%d_OFF. Il est nécessaire de préciser dans la commande le numéro des feux à allumer ou éteindre (par exemple MAKO_LED1_ON ou MAKO_LED2_OFF). Le Nomad ne répond pas à ces commandes. Le statut des LED peut être récupérer par la commande précédente MAKO_READ_BATT.

Envoie des consignes

L’envoie des consignes est un peu plus problématique. En effet, une seule commande binaire est utilisée pour envoyer les consignes de vitesse avant, de vitesse arrière et de direction. En outre, la commande semble contenir un numéro unique qui, s’il est mal renseigné, bloque l’interprétation de la commande complète.

Voici la structure de la trame binaire envoyée. Les valeurs sont données en hexadécimal:

Les consignes de vitesse  sont données en 0-255, soit en marche avant, soit en marche arrière.

La consignes de direction est également en 0-255, avec la valeur 128 pour aller tout droit. 0 tourne à gauche, 255 tourne à droite.

La réponse du Nomad à cette commande est assez impénétrable:

On y retrouve le même code qu’à la commande. Ensuite, il y a deux octets à 0, deux octets qui sembles avoir une valeur proche de 0x66, les recopies des deux consignes de vitesse et encore deux octets à 0.

Conclusion

Même s’il reste quelques octets inexpliqués dans les trames d’envoie de consigne et de réponse, il est tout à fait possible de piloter le Nomad depuis n’importe quel périphérique WiFi. Voici d’ailleurs un driver LabVIEW permettant le pilotage du Nomad:

NomadND1_LV2019.zip

En outre, j’envisage le développement d’une interface Radio <-> WiFi à base d’ESP32. L’idée est de récupérer les signaux d’écolage radio, voir les PWM de pilotage servo issues d’un récepteurs modélisme et de générer les trames UDP « qui vont bien » afin de piloter le Nomad comme il se doit!

Si une âme charitable et possédant un Nomad peut tester le pilotage par UDP afin de s’assurer que la trame C0A8 0101 0000 0421 XXXX XX fonctionne sans modifications, le retour d’expérience sera intéressant pour compléter cette petite introduction au pilotage du Nomad 🙂

Cet article Nomad ND1 – Sous le capot est apparu en premier sur Electronique et Informatique.

Les bruiteurs pour avion de modélisme disponibles dans le commerce sont relativement chers (150€ pour ce modèle de MotionRC). Aujourd’hui, avec les modules disponibles pour la bricole autour des arduinos, il doit être possible de fabriquer un bruiteur à moindre frais. C’est ce que je vais essayer de faire dans cette article.

Le matériel

Pour construire mon bruiteur, j’ai choisi de partir sur un arduino nano (ou sa copie chinoise) et un module lecteur MP3-TF-16P.

Le matériel le plus chers sera donc la carte SD pour stocker les fichiers sons.

L’arduino nano sera utilisé pour acquérir le signal PPM de pilotage moteur et envoyer les informations de lecture fichiers au module MP3 via l’UART.

Le module MP3-TF-16P est un codec audio associé à un amplificateur capable de décoder des fichiers MP3 et WAV et de les jouer sur un haut parleur de 3W.

Principe de fonctionnement

Le signal PPM issu du récepteur radio de l’avion est un pulse de 1 à 2ms émis toutes les 22ms ou 11ms (DSMX). Pour plus de détail, rendez-vous sur la page Récepteur radio-modélisme sur USB. L’arduino doit donc mesurer la durée de l’état haut du pulse. Cela tombe bien, une fonction native s’en occupe: pulseIn(). Elle renvoie la durée des pulses reçus sur une broche d’entrée en µs.

La plage de 1000µs à 2000µs est découpée en 6 plages réparties comme suis:

1000 — OFF— 1100 — RPM1 — 1280 — RPM2 — 1460 — RPM3 —1640 — RPM4 — 1820 — RPM5 — 2000

Chaque plage est associée à un fichier son sur la carte SD. Exception faite de la plage MotorOff qui donne lieu à la lecteur d’un fichier de démarrage moteur et d’une fichier d’arrêt moteur quand la consigne sort ou entre dans la plage.

Les fichiers sons sont téléchargeables sur le site Simviation par exemple.

Câblage

Le câblage du système est très simple:

1. Récupérer une prise servo 3 points
2. Alimenter l’arduino entre noir et rouge (5V issu du BEC du récepteur)
3. Alimenter le module MP3-TF-16P avec le même 5V (pin 1 : Vcc, pin 7 et pin 10 : Gnd)
4. Connecter le signal (fil orange) sur une entrée de l’arduino (j’utilise D2)
5. Connecter l’UART du module MP3-TF-16P (pin 2 : Rx, pin 3 : Tx) sur les broches Rx et Tx de l’arduino (pensez bien à croiser Rx->Tx et Tx->Rx)
6. Connecter le haut parleur sur le module MP3-TF-16P (pin 8 : Spk- et pin 6 : Spk+)

C’est tout!

[EDIT] Voici un schéma de la version amplifiée:

La spécification du module MP3-TF-16P est disponible ici.

Programmation de l’arduino

Le programme de l’arduino est assez simple. Il est basé sur une machine à états qui gère les différents régimes moteurs et les transitions de l’un à l’autre.

Le code source de l’arduino est disponible ici. La version que je propose utilise 7 fichiers son au total. Pour des raisons de simplicité d’intégration je n’ai pas utilisé la bibliothèque DFPlayer-Mini, préférant écrire ma propre implémentation. En effet, le protocole de communication mise en place sur le MP3-TF-16P est relativement simple. Il est très bien décrit dans la spécification du module:

Le même format de trame est utilisée en réception et en émission.

La carte SD

Les fichier sons doivent être rangés et nommés d’une certaine manière pour que le module puisse les lire. Voici l’arborescence que j’utilise:

• 01
  • 001.wav
  • 002.wav
  • 003.wav
  • 004.wav
  • 005.wav
  • 006.wav
  • 007.wav

Les fichier 001 et 007 sont les fichier startup et shutdown. Les fichiers 002 à 006 sont les régimes moteurs établis.

[EDIT] Ajout d’un amplificateur et utilisation d’un haut parleur vibrant (exciter)

Comme prévu, les haut parleurs de 3W ne donne pas satisfaction dans un avion RC: il faudrait percer le fuselage pour sortir le son. Un solution proposée entre autre par MotionRC est d’utiliser des excitateur vibrants. Ils fonctionnent comme un haut-parleur électroacoustique, mais sans membrane. Au lieux de la membrane, il y a juste un adhésif double faces collé sur la bobine. En montant ce type de matériel sur un avion, tout le fuselage devient haut-parleur!

Le modèle que j’ai retenu est un Dayton Audio DAEX25FHE-4 de 24W. Je l’ai couplé à un amplificateur TPA3110 sur carte de développement :

J’ai récupéré l’une des deux sorties DAC_L ou DAC_R du module MP3-TF-16P pour attaquer l’ampli. J’alimente ce dernier avec une batterie 2S auxiliaire afin de ne pas endommager le circuit électrique principal de mon avion en cas de défaillance.

Voici le résultat en images (et surtout en musique…):

Conclusion

Voici donc un petit bruiteur sans prétentions qui semble donner des résultats satisfaisants pour un budget contenu. Je n’ai pas encore pu essayer avec un haut parleur de 3W, mais une chose est sûre: avec mon petit haut parleur de 0.1W, on n’entend pas le bruiteur à cause du bruit de l’hélice de l’avion. Dans le pire des cas, j’ajouterais un amplificateur de 3W additionnel sur la sortie non amplifiée du module pour mettre deux HP en stéréo sur l’avion.

J’envisage d’équiper un su29mm de chez ParkZone.

Cet article Bruiteur pour avion de modélisme est apparu en premier sur Electronique et Informatique.

• lvrt-schroot : pour LabVIEW 2014, la version initiale
• lvrt20-schroot : pour la future LabVIEW 2020 ?
• lvrt19-schroot : pour LabVIEW 2019 ?

Si l’on essayait ensemble d’installer lvrt19-schroot sur un Raspberry Pi 4 tout neuf ?

Introduction

Avant de commencer, il nous faut un Raspberry Pi (>2) fonctionnel avec la dernière version de Raspbian (Buster à l’heure où ce test a été mené). Pour ma part, je profite de la sortie du Raspberry Pi 4 pour le prendre en main et profité de la connexion WiFi (enfin!).

Installation de LINX 3 pour LabVIEW 2019

Nous sommes prêts? Allons-y !

Tout se passe en ligne de commande. Ouvrez un terminal SSH et connectez-vous sur le Raspberry Pi.

Commençons par mettre à jour notre installation:

• sudo apt-get update
• sudo apt-get dist-upgrade -y

Ensuite activons les modules i2c et spi:

• sudo raspi-config nonint do_i2c 0
• sudo raspi-config nonint do_spi 0

Ajoutons le dépôt d’installation de LINX:

• sudo sh -c ‘echo « deb [trusted=yes] http://feeds.labviewmakerhub.com/debian/ binary/ » >> /etc/apt/sources.list’
• sudo apt-get update

A ce stade, la magie n’a pas encore opéré. Installons donc le paquet lvrt19 (tuto extrait du forum NI, modifié pour LabVIEW 2019) :

• sudo apt-get install -y lvrt19-schroot
• sudo mv /etc/systemd/system/multi-user.target.wants/nisysserver.service /lib/systemd/system
• sudo mv /etc/systemd/system/multi-user.target.wants/labview.service /lib/systemd/system
• sudo schroot -c labview -d /usr/lib — ln -s liblinxdevice_rpi2.so liblinxdevice.so
• sudo systemctl enable nisysserver.service
• sudo systemctl enable labview.service
• sudo systemctl start nisysserver.service
• sudo systemctl start labview.service

Vérification de l’installation avec LabVIEW 2019

Avant d’aller plus loin, nous allons vérifier la bonne installation du runtime 2019 sur le Raspberry Pi.

Créons un nouveau projet LabVIEW vide et ajoutons une cible temps réelle compatible (cRIO 9039 au hasard) en spécifiant l’adresse IP du Raspberry Pi.

Ensuite, nous connectons le projet à la cible: clic droit sur la cible -> Connect.

LabVIEW déploie le projet et vérifie la connexion à la cible.

Comme nous avons défini la cible comme étant un compact RIO, LabVIEW cherche automatiquement à détecter les modules d’acquisitions présents dans el châssis. Nous avons un Raspberry Pi, donc LabVIEW échoue à détecter les modules, mais pas de panique, tout est normal.On continue la procédure en écrivant un petit code de test qui renvoie la version de LabVIEW et la version du système :

Confirmation du fonctionnement (ctrl + R), après déploiement et exécution, nous voyons la version 2019 et la version de l’OS (ici Linux raspberry 1.19.97) :

Vous trouverez le projet de test ici : test.zip

Ajout de la cible Raspberry Pi dans LabVIEW 2019

Pour ajouter le Raspberry Pi comme cible de déploiement dans LabVIEW, il faut ajouter des Providers. Ils sont fournis dans le paquet d’installation VIPM de LINX. Il est possible de récupérer l’archive zip intéressante en décompressant le fichier .vip ou en la téléchargeant ici : InstallProviders.zip

Quittez LabVIEW, décompressez cette archive et lancez la commande suivante :

• UpdateLinxProvider.bat « C:\Program Files (x86)\National Instruments\LabVIEW 2019 »

Une fois installé, le Raspberry Pi apparait dans la liste des cibles disponibles :

Conclusion

En attendant la sortie officielle de LabVIEW 2020 avec le support LINX inclus, il est possible de profiter d’un runtime 2019 sur un Raspberry Pi. Pour preuve, voici un pilotage moteur en CanOpen utilisant CanOpenSocket:

Cet article Le Raspberry Pi se propulse vers LabVIEW 2019 (et 2020) ! est apparu en premier sur Electronique et Informatique.

Avertissements

Cette manipulation pourrait rendre votre LattePanda disfonctionnel. Pour le restaurer dans la version Windows 10 d’origine, référez-vous à la page d’explication du forum LattePanda.

En outre, l’installation de NI Real-Time et la programmation du LattePanda avec LabVIEW RT ne sont pas supportés officiellement, ni par National Instruments, ni par moi-même. Cet article expose la possibilité d’utiliser le LattePanda avec LabVIEW RT à titre purement expérimental et non professionnel. En effet, le LattePanda n’offre pas les mêmes caractéristiques techniques qu’un compact RIO en terme de robustesse, fiabilité ou déterminisme. Il ne saurait en aucun cas remplacer un contrôleur industriel certifié et testé.

Prérequis

Pour commencer, il vous faut réunir les pièces suivantes:

• Un LattePanda première génération
• Son écran 7 » (facultatif, mais alors il faudra un écran HDMI)
• Un clavier USB pour le LattePanda
• Une clés USB d’au moins 128Mo
• Un PC installé avec LabVIEW, LabVIEW RT et MAX (Measurement and Automation eXplorer)
• La possibilité de brancher sur le même réseau le PC et le LattePanda (la carte WiFi ne sera pas utilisable)
• L’image d’installation via NIPM ou ici : standard_x64_recovery.iso

Récupération de l’image via NIPM

Lancer NIPM et faire la recherche « Linux ». Le résultat doit être le suivant :

Sélectionner le produit « Image Système NI Linux RT PXI » et cliquer sur installer.

MAX doit être mis à jour pour permettre la création de la clé USB. Dans tous les cas l’image se trouvera dans « ..\National Instruments\RT Images\Utilities\Linux RT PXI Safemode\7.0 ».

Création de la clé USB d’installation

Depuis peu (version 19.0), MAX est doté de la possibilité de générer une clé USB de restauration pour NI Linux RT.

Pour ce faire, passer par le menu Outils -> Créer une clé de restauration NI Linux RT

Ensuite, choisissez votre clé USB et le fichier standard_x64_recovery.iso

Cliquer sur Formater et laisser MAX générer la clé d’installation.

Installation de NI Linux RT

ATTENTION : pour fonctionner correctement, le LattePanda doit avoir un BIOS configuré en UEFI.

Pour installer NI Linux RT sur le LattePanda, il faut amorcer la clé USB générée par MAX. Pour ce faire, appuyer sur F12 pendant l’écran d’amorçage et sélectionner la clés USB. Normalement, un shell Linux devrait démarrer vous demandant si vous souhaitez formater votre cible et installer NI Linux RT. Répondez oui (‘Y’ puis Entrer).

L’installation dure quelques secondes, puis un message de confirmation apparait.

Il reste à retirer la clé USB et appuyer sur Entrer pour redémarrer le LattePanda. L’écran d’accueil est le suivant:

L’identifiant par défaut est :

login : admin
mot de passe : aucun

Installation des logiciels

Maintenant que le LattePanda fonctionne sous NI Linux RT, la suite des opérations se déroule dans MAX. Logiquement, le LattePanda doit apparaitre dans la section systèmes déportés. S’il n’apparait pas, il est possible que le pare-feu Windows fasse obstruction…

Pour ajouter des logiciels au LattePanda, faire un clic droit sur sa section « Logiciels » et choisir « Ajouter/Supprimer des logiciels » :

Valider les droits admin :

En fonction des paquets logiciels disponibles sur votre pc hôte, l’interface suivante vous proposera différents paquets à installer.

De base, , en choisissant une installation personnalisée, il est possible d’installer le run-time LabVIEW RT ainsi que VISA, les web services, les Network Streams… :

Voici un exemple de paquets que vous pouvez installer :

Il peut cependant être utile d’installer des paquets supplémentaires cette fois-ci dans LabVIEW. Pour ce faire, on utilise le VI Package Manager. Voici une liste des paquets intéressants:

• NI Linux RT Inter-Process Communication
• NI Linux RT Utilities
• NI Linux RT Errno
• Digilent LINX
• RTI DDS Toolkit

Activation de l’Embedded UI

L’introduction de NI Linux RT a permis de tirer parti d’un écran connecté sur la cible RT. Cela permet de concevoir des applications autonomes équipées d’une interface graphique.

Il est possible que le serveur graphique ne démarre pas automatiquement. Pour palier à ce problème il faut éditer le fichier de configuration ni-rt.ini à l’emplacement /etc/natinst/share.

Ajouter la clé ui.enabled=True dans la section SYSTEMSETTINGS :

Installation d’un serveur VNC

Avec un serveur graphique fonctionnel, il est possible d’installer un serveur VNC pour prendre la main à distance sur le LattePanda.

Pour ce faire, il faut installer manuellement X11VNC. Sur NI Linux RT, le gestionnaire de paquets est opkg. Pour installer VNC, commencer par mettre à jour la liste des paquets:

$ opkg update

Puis installer VNC:

$ opkg  install x11vnc

Pour la configuration et le lancement manuel (je n’ai pas réussi à le rendre automatique), se référer à la page de LinuxTricks suivante:

https://www.linuxtricks.fr/wiki/vnc-x11vnc-pour-prendre-le-controle-du-bureau-a-distance

Installation de l’Arduino

Installation de l’IDE

A partir de votre PC, télécharger la version d’Arduino pour Linux 64 bits. Pour envoyer le paquet tar.xz sur le LattePanda, il est possible de monter un disque réseau Windows sur le système WebDAV du LattePanda. Il est autrement possible de passer en SCP ou en SSHFS (par exemple avec WinSCP). Une dernière solution consiste à installer le serveur FTP (legacy mode) avec MAX.

Pour le WebDAV, voici les informations de connexions:

• adresse : http://ip_panda/files
• login : admin
• mot de passe : vide

Placer l’archive tar.xz dans le dossier /home/lvuser

Pour décompacter l’archive .tar.xz, il faut les utilitaires tar et xz:

$ opkg intall tar xz

$ tar -xJf arduino-x.x.x-linux64.tar.xz

Aller dans le dossier Arduino et faire un chmod +x sur le fichier arduino.

Pour lancer l’IDE, un simple ./arduino devrait faire l’affaire.

Compilation et téléchargement de LINX

Pour charger LINX dans l’Arduino, il est nécessaire de le compiler à partir des sources du firmware. Il est possible de les récupérer à partir du GITHUB de MakerHub ou de les récupérer à partir de LabVIEW:

Il faut ensuite recompiler l’exemple Arduino_Leonardo_Serial.ino et le téléverser sur l’arduino du LattePanda. Une fois cette opération faite, il est possible d’utiliser LabVIEW pour accéder à l’arduino.

Utilisation sous LabVIEW

L’arduino devrait apparaitre dans MAX comme alias VISA (il est possible de le renommer :

LINX utilisera cet alias pour se connecter à l’arduino :

En cas de problèmes, n’hésitez à pas à me contacter 🙂

Cet article LabVIEW RT & LattePanda est apparu en premier sur Electronique et Informatique.

Avant de commercer cet article, je tiens à remercier Amaury qui m’a permis de publier cet article sur son site. 🙂

Je découvre actuellement l’électronique et la programmation entre  LabVIEW et Arduino et je tiens à partager certains résultats avec vous. Certaines notions abordées ne seront pas forcément poussées ou assez détaillées pour des lectures ou lectrices plus expérimenté(e)s.

Théorie de mesure de distance Lidar

Lidar est l’acronyme anglais de light detection and ranging qui est une technique qui permet de mesurer des distances allant de quelques centimètres à la distance Terre-Lune. Le lidar Garmin utilisé ici, génère un train d’onde électromagnétique cohérente (un faisceau laser InfraRouge) de longueur d’onde λ de 905 nm. Les trains d’onde sont envoyés à une fréquence comprise entre 10 à 20 kHz (à ne pas confondre avec la fréquence propre de l’onde du laser IR) d’après les datasheet. Les trains d’ondes se réfléchissent sur la cible visée par le capteur. Une partie de la lumière du laser revient sur le capteur. Une photodiode placée dans le Lidar et sensible dans la plage de longueur d’onde des IR reçoit l’onde réfléchie. L’écart de temps entre le départ d’un train d’onde et son retour est mesuré par le capteur. Cet écart de temps est proportionnel à la distance parcourue par l’onde. Cette technologie de mesure est communément appelée Time of Flight.

Le matériel utilisé pour la réalisation

Nota : un clavier et une souris seront très certainement nécessaires pour naviguer sur LattePanda.

Le Montage global

Le schéma suivant a été réalisé sur le logiciel libre Fritzing. N’ayant pas trouvé de modèle de LattePanda dans la librairie Fritzing, il a donc été représenté par sa carte Arduino qu’il intègre. Un schéma du LattePanda est donné après.

Figure 1 Schéma Global de la mesure Lidar (à l’aide du logiciel gratuit Fritzing)

L’intégration des différents éléments a été faite à l’aide d’un vieux jeu mécanos.

LattePanda

Le modèle de  LattePanda utilisé est le 4 GB/64 GB sous Windows 10. Ce modèle suffit pour faire tourner un LabVIEW 2014 (https://www.gotronic.fr/art-carte-lattepanda-4-gb-64-gb-dfr0419-24792.htm ). LattePanda sera très utile car il intègre une carte Arduino Leonardo et ses E/S associées. A l’aide des entrées et sorties numériques (0-5V), il sera possible de piloter le moteur pas à pas, le laser et d’acquérir le signal du Lidar. Le LattePanda est enfaîte un petit ordinateur d’instrumentation très compacte et assez puissant. Le projet n’utilise ici qu’une petite partie de sa capacité. Pour plus de détails sur LattePanda, le lecteur pourra se référer à l’article : LattePanda – Première mise en route

Le schéma ci-dessous reprend les principales E/S :

Figure 2 E/S LattePanda 4GB/64GB (https://www.lattepanda.com)

Le moteur Pas à Pas

Le moteur Pas à Pas bipolaire est contrôlé par un Driver Pololu (A4988). Le schéma ci-après (d’après le site Pololu qui commercialise le Driver) permet de connecter le moteur et le Driver. La puce du Driver est alimentée en 5 V par la carte Arduino du LattePanda. Ce driver a été choisi car il est facilement pilotable à partir des E/S digitales du Arduino, qui seront contrôlées par le logiciel ; lequel qui sera abordé après.

Figure 3 Schéma de fonctionnement du Drive couplé au moteur Pas à Pas (bipolaire)

Pour connecter correctement le moteur pas à pas au driver on pourra suivre le tableau suivant :

Figure 4 Schéma du moteur Pas à Pas (14HM11-0404S) d’après datasheet Go Tronic

Il est conseillé de relier la masse de l’alimentation du moteur à la masse du circuit afin d’éviter de le moteur ne grésille. Un petit régulateur LM7815 (15 V) permet de limiter la tension en entrée. Pour ma part j’ai utilisé deux piles de 9 V. En sortie du régulateur il vaut mieux ne pas oublier de limiter le courant à l’aide d’une résistance de charge. Le moteur consomme 400 mA par phase. Pour limiter le courant j’ai choisi de mettre en parallèle 4 résistances de 2 kΩ de 1/4 W qui forment une résistance 500 Ω supportant 1 W. Avec ce montage, le moteur ne chauffe et a assez de puissance pour réaliser ses pas. Un potentiomètre présent sur le driver permet de réguler la tension. Le réglage du courant limite est disponible dans la vidéo disponible en suivant de lien (https://www.youtube.com/watch?v=89BHS9hfSUk). Pololu préconise de régler le courant limite à l’aide du réglage du VREF et non en entrée comme cela a été fait ici.

• Une fois le montage du moteur réalisé, un test du moteur peut être réalise. Pour cela, la Pin STEP du driver peut être connecté au 5V délivré par l’Arduino. Le moteur est censé faire un pas. Sinon, revérifier le schéma de montage.

Les entrées MS1, MS2 et MS3 permettent de réduire le Pas, c’est-à-dire de gagner en précision angulaire. Le tableau ci-dessous affiche les niveaux à utiliser sur les pins en fonctions de la résolution du pas.

Figure 5 Tableau de résolution des pas d’après le site Pololu

Dans le cas présent, un pas complet est de 0,9°, un demi-pas en vaudra la moitié et ainsi de suite. Dans le présent projet, il n’est pas possible de descendre en dessous du demi-pas.

Nota important: il est fortement déconseillé de déconnecter le moteur du driver quand le moteur est en fonctionnement car le Driver peut-être endommagé. Il faudra couper l’alimentation du moteur pour effectuer des changements de postions (si besoin) sur les 4 fils du moteur pas à pas.

Le Lidar

Pour fonctionner le Lidar doit être alimenté en 5 V. L’alimentation 5 V de l’Arduino du LattePanda convient parfaitement. L’acquisition de la mesure de distance est lue en largeur d’impulsion (PWM) sur le fil jaune. Les datasheet préconisent l’utilisation d’une résistance de 1KΩ qui est reliée entre le fil de sortie de la mesure et la masse comme ci-dessous :

Figure 6 Schéma de câblage du lidar en acquisition de mesure en PWM (d’après datasheet Gramin)

Concernant les aspects métrologiques du capteur, la portée maximale du Lidar est de 40 mètres. Sa résolution est de 1 cm.

L’incertitude de mesure du Lidar Lite V3,  entre 0 et 5m est de ± 2.5cm et ± 10 cm au delà.

En sortie de mesure en largeur d’impulsion, la sensibilité est de 10 µs/cm. Cette valeur est à retenir pour comprendre la partie acquisition du signal du logiciel.

Le Laser de visée

Le laser est utile ici afin d’avoir un repère visuel sur l’orientation du Lidar. Le laser est du même type qu’utilisé pour les pointeurs laser de présentation (diode laser). Dans le cas présent, un laser d’alignement de 1 mW (λ = 650 nm) de couleur rouge a été utilisé. Il est alimenté en 5V par une entrée digitale de carte Arduino activable à partir du logiciel.

Attention aux yeux ! Le laser concentre l’énergie sur une surface très petite et a pour conséquence d’être nocif pour l’œil.

L’utilisateur est responsable de sa sécurité mais également celle des personnes autour !

Le logiciel/programme

Pour piloter les instruments (Lidar, moteur, laser) le logiciel LabVIEW 2014 est utilisé. Le but n’est pas de faire la présentation ni la promotion de ce logiciel mais de tenter d’expliquer comment utiliser certaines briques LINX. Si LabVIEW n’est pas utilisé, il sera quand même possible de piloter les instruments via un programme développé sur l’IDE Arduino. La suite de l’article pourra paraître obscure pour les personnes non initiées à LabVIEW; je m’en excuse par avance. Cependant, un petit effort a été fait pour que le code soit compris des personnes non initiées à LabVIEW.

Des briques (ou VI) de code LabVIEW ont été développées afin de faciliter grandement la compatibilité entre des cartes Arduino et LabVIEW. Pour utiliser les briques de codes LINX, la bibliothèque LINX côté LabVIEW doit avoir été installée préalablement dans VI Pack Manager (logiciel qui permet de charger des ToolKit ou librairies de programme).

Chargement des librairies

Avant de compiler le code, il faut charger les bibliothèques. Pour charger les bibliothèques, aller sur l’onglet Tool\MakerHub\LINX\Generate Firmware Librairies :

Et mettre en cible : C:\Program Files\Arduino\Libraries

Les librairies sont donc maintenant chargées et opérationnelles.

Configuration du type de carte

Avant de compiler le code, il faudra configurer le type de carte (Mega, Leonardo) et le type de liaison. Dans ce projet avec LattePanda, la carte Arduino Leonardo est utilisée sur le port COM 4. Dans LabVIEW cliquez dans l’onglet Tool puis \MakerHub\LINX\LINX Firmware Wizard… il faut configurer les champs à l’aide des informations mentionnées plus haut.

TEST simple avec une LED

Pour vérifier que la carte fonctionne correctement, l’exemple du pilotage d’une LED pourra être réalisé (onglet HELP/Find Example…). L’exemple est prêt à être utilisé et ne nécessite que la mise en place d’une LED en série avec une résistance de 220 Ω reliées au LattePanda.

Mettre le port COM 4 (normalement) et configurer la pin du Arduino sur laquelle est reliée l’anode de la LED (la patte la plus longue) et ne pas oublier la résistance de 220 Ω en série 😉 . Puis relier la résistance à la masse et lancer le programme (flèche blanche).

Si la LED clignote quand le bouton est pressé, c’est gagné. Passer aux étapes suivantes. Sinon, il faut trouver la raison de cette malchance.

Ne pas hésiter à reconfigurer la carte car il arrive (trop) souvent que cela saute au bout de 3 à 4 compilations. Par exemple, il vaut mieux arrêter proprement la boucle avec un bouton « stop » placé dans la boucle While plutôt que de stopper le programme avec le bouton rouge de LabVIEW.

L’IHM (côté « Face Avant » de LabVIEW)

L’IHM qui permet à l’utilisateur de contrôler les instruments pourra ressembler fortement à celle présentée ci-dessous.

Les configurations des Pins et du port sont situées à gauche.

Le bouton « Motor ON » permet d’activer le driver sur la Pin ENABLE (Driver).

Le bouton « Left » permet d’activer la Pin STEP (Driver)  et faire faire un pas au moteur.

Le bouton « Right »agit comme le bouton « Left » mais active la pin DIR (Driver) à l’état haut et permet de changer de sens de rotation.

Un bouton « Laser » permet d’activer le laser de visée.

Un bouton STOP permet d’arrêter l’exécution proprement et d’arrêter le moteur (ENABLE) et le Laser.

Trois types d’indicateurs sont présents : numérique (format chaîne de caractère), une barre de remplissage, et un graphe déroulant.

Un contrôleur barre graphe permet de passer au pilotage Pas par Pas (un clique sur LEFT ou RGTH = 0,9°) ou active la vitesse constante (comme sur la vidéo du début de l’article).

Pour le lecteur non initié à LabVIEW, la « face avant » est la partie visible finale du programme disponible pour l’utilisateur.

Le code est développé dans une seconde fenêtre appelée « Diagramme ». Et c’est la partie de développement du Diagramme que nous allons maintenant aborder.

Nota : un Crtl+E permet de permuter rapidement rentre la face avant et le diagramme.

La structure (côté diagramme)

La structure générale du programme est la suivante :

Figure 7 Structure générale du programme dans un boucle While

Le code source ne sera pas disponible dans cet article mais les principales briques seront détaillées pour arriver facilement au résultat. 🙂

Lecture de la valeur de la distance du Lidar

Le Lidar Garmin Lite V3 admet deux sorties de données pour la lecture des mesures : I2C ou PWM. La lecture en modulation de largeur d’impulsion est apparue comme le plus simple du point de vue du soft. Un VI LINX permet de réaliser cette mesure rapidement contre plusieurs VI pour la communication en I2C.

Dans la boucle While cadencée à 50 ms, la mesure du Lidar est effectuée à l’aide du VI « Lecture de la largueur d’impulsion » :

L’entrée DO Channel est connectée et la valeur de la Pin 0 de la carte Arduino est rentrée (cf Figure 8 ci-dessous).

Un tableau général de configuration des Pins d’E/S pourra être créé en amont de la boucle While comme ceci :

La valeur en sortie du VI n’est pas en cm mais en largeur d’une impulsion (µs), qui est proportionnelle à la distance mesurée en cm par le lidar. Afin de lire et d’afficher une valeur en cm, il faut diviser les valeurs en sortie du VI par une constante valant 10 pour obtenir une mesure de longueur (en cm). Cette constante est la sensibilité (en µs/cm) du capteur abordé précédemment que l’on peut retrouver dans la documentation du Lidar Lite V3 (page 4, §Mode Pin Control).

Une moyenne glissante pourra être développée afin d’obtenir une mesure plus stable et plus juste à l’aide des registres à décalage (flèches oranges sur les bords de la boucle While). L’inconvénient de cette technique est qu’il faudra attendre n fois le nombre de points moyennés, pour obtenir le résultat. Si l’on choisit de moyenner sur 10 points et que le temps du cadencement est de 500 ms, alors le résultat sera juste au bout de 5 secondes. Ne pas oublier d’initialiser les registres à décalage à zéro. Différents types d’indicateurs pourront être placés en face avant comme ci-dessous :

Figure 9 Moyenne glissante (côté diagramme/code) et exemples d’indicateurs en face avant

Comme le Lidar affiche une incertitude de ± 2.5 cm et une résolution de 1 cm, il a été choisi de n’afficher que des valeurs entières arrondies au centimètre.

VI de contrôle du Driver et du moteur

Un VI « écrire sur des E/S digitales » permet d’activer les sorties de l’Arduino du LattePanda afin de piloter le Driver.

La fonction suivante a été construite comme ci-après :

Cette fonctionnalité permet de prendre, en entrée, un tableau de booléens (ordres des boutons pressés en face avant) et d’activer les E/S correspondantes.

• La première entrée (en partant du haut) de la fonction « Construire un tableau» est reliée au bouton « MOTOR ON » et agit sur la Pin « ENABLE » du Driver. Ce bouton permet vraisemblablement d’activer l’alimentation du driver et du moteur.
• La seconde entrée permet de gérer la direction du moteur. Le fil (vert) est relié au bouton « RIGHT » de mon interface afin d’active la Pin « DIR » du driver. Le moteur tourne ainsi dans le sens horaire.
• La troisième entrée active la pin « STEP » du driver et permet d’effectuer un Pas de 0,9° (avec les entrées du driver MS1=MS2=MS3=0=GND). Le moteur effectue un pas par changement de niveau de l’état bas à l’état haut. Cette entrée est active si le bouton « LEFT » OU le bouton « RIGHT » est activé. Nous verrons ensuite comment faire tourner le moteur à vitesse constante.
• La quatrième entrée active le laser. Un laser de visée peut fonctionner qu’avec une tension de 5V et ne consomme que quelques milliampères. Il est souhaitable pour la sécurité des personnes, que le bouton « STOP » qui arrête le programme, puisse stopper l’émission du laser à la fin de la manip en même temps. Pour cela on pourra mettre une boucle conditions comme ci-dessous :

Il pourra être fait de même avec l’arrêt du moteur (« MOTOR ON ») à la fin de l’exécution du programme.

• Les cinquième, sixième et septième entrées activent les Pins MS1, MS2 et MS3 du driver et permettent de gagner en précision d’angle (jusqu’au demi pas ici).

Afin de faire fonctionner le moteur à vitesse constante, la fonctionnalité suivante a été développée :

Lorsqu’un booléen (bouton) active la structure « Cas », le VI « écrire un signal carré » est activé avec une fréquence nulle et d’une durée nulle sur la pin STEP. Cette fonctionnalité m’a permis de faire fonctionner le moteur à vitesse constante. Dans ce cas, la vitesse est fonction du temps de cadencement de la boucle (réglée à 50 ms). A l’heure où est écrit cet article, il existe surement de meilleures solutions, notamment avec le VI « PWM Set Duty Cycle »:

Mais cela n’a pas fonctionné comme il était souhaité lors du test.

A la suite de ces nombreux réglages et bidouillages, le programme doit pouvoir se lancer (flèche blanche non brisée). Si cela n’est pas le cas, résoudre les erreurs unes à unes.

Il fortement probable que rien ne fonctionne du premier coup, ou qu’à moitié, il est alors conseillé, dans un premier temps, de vérifier les branchements (alimentation) des organes dysfonctionnant.

L’utilisateur pourra jouer avec les différents types d’actions mécaniques pour contrôler le moteur (clique droit sur un bouton) :

Résultats en images :

Figure 10 Interface de la mesure de distance (Windows n’est pas à l’heure ^_^ )

J’espère que ce projet a pu continuer d’éveiller votre curiosité et a pu vous aider dans vos futurs développements !

Sources :

• Site Pololu (https://www.pololu.com/product/1182 )
• Site GO Tronic
• https://www.lattepanda.com
• Ressources LINX : http://sine.ni.com/nips/cds/view/p/lang/fr/nid/212478
• Forum LINX : https://www.labviewmakerhub.com/doku.php?id=libraries:linx:start
• Datasheet Lidar Garmin lite V3 : https://static.garmin.com/pumac/LIDAR_Lite_v3_Operation_Manual_and_Technical_Specifications.pdf
• LabVIEW – 4e édition – Programmation et applications – Introduction à LabVIEW NXG, Collection : Technique et ingénierie, Dunod, Parution : août 2018,Francis Cottet, Luc Desruelle, Michel Pinard

• The Art of electronic, Third edition, Paul Horowitz et Winfield Hill

Cet article Mesure Lidar rotatif embarqué sur LattePanda et piloté par LabVIEW (LINX) est apparu en premier sur Electronique et Informatique.

Après une longue gestation, j’ai enfin migré mon outil de calcul de résistance vers WordPress.

Voir la page ici

Cet article Code couleur résistance est apparu en premier sur Electronique et Informatique.

Introduction

Rappelons rapidement le principe de fonctionnement d’un circuit imprimé.

Un circuit électronique consiste en l’interconnexion de différents composants (résistances, condensateurs, circuits intégrés, …). Ces connexions électriques doivent être réalisées avec un matériau conducteur d’électricité; habituellement le cuivre. Sur un circuit imprimé, on appelle ces connexions des pistes. Pour tenir ces pistes, on fait appel à un substrat isolant: l’époxy ou la bakélite (bien que d’autres matériaux soient également utilisés). Chaque piste relie donc différents composants via leurs broches. Les broches des composants sont reliées aux pistes par des pastilles de cuivre: c’est une zone plus large que la piste (afin de pouvoir y percer un trou) qui permet à l’étain de soudure d’adhérer et offre une meilleure résistance mécanique. Un circuit imprimé peut avoir une ou deux (voir plus) couches de cuivre afin d’augmenter la complexité du circuit. Enfin, il est possible de conserver de grandes étendues de cuivre reliées à une masse d’alimentation (ou à un autre potentiel); on parle alors de plan de masse. Ils ont plusieurs avantages, parmi lesquels une meilleure immunité du circuit au bruit électromagnétique, une meilleure dissipation thermique, …

La réalisation de circuits imprimés peut s’appuyer sur deux principes différents, mais à la finalité identique : enlever le cuivre autour des pistes afin d’isoler celles-ci les unes envers les autres. Je vais citer deux principes largement répandus:

• L’attaque chimique
• La gravure à l’anglaise (ou gravure mécanique)

L’attaque chimique

Cette méthode ancienne et fiable repose sur l’utilisation d’un composé chimique capable d’attaquer et dissoudre le cuivre.

On commence par prendre une plaque d’époxy recouverte d’une couche de cuivre et d’une couche photosensible.

Pour éviter de ronger tout le cuivre du circuit imprimé, on imprime un typon (représentation physique des pistes imprimées en noir sur une feuille transparent). Ce typon est utilisé pour insoler le vernis photosensible. Ensuite, comme pour la photographie argentique, il faut plonger la plaque dans un bain de révélateur. A ce moment, le dessin des pistes devrait apparaitre sur la plaque. On enlève les résidus de vernis photosensible et on plonge la plaque dans un bain d’attaque chimique (perchlorure de fer ou acide chlorique + peroxyde d’hydrogène).

ATTENTION : ces produits sont agressifs (voir très agressifs) et très salissant pour le perchlorure de fer.

On enlève la plaque du bain d’attaque dès que le cuivre est complètement dissout. Il ne reste alors plus qu’à percer les trous dans les pastilles et souder les composants.

Cette méthode a fait ses preuves. Elle est relativement bon marché, nécessite un peu de matériel spécifique (banc à insoler et bain de gravure) et de produits chimiques. Par contre, elle nécessiter une très bonne maitrise du temps (insolation, révélation, gravure) qui ne peut s’obtenir qu’après moult essais et échecs. En outre, elle est très salissante et s’accommode mal des espaces clos (dégagements gazeux).

La gravure à l’anglaise

Cette méthode repose elle sur l’utilisation d’une fraiseuse pour usiner la couche de cuivre. En usinant les contours des pistes, on obtient un résultat similaire à la méthode chimique: les pistes sont isolées entre-elles. C’est cette méthode que je vais détailler dans cet article.

Du logiciel de CAO au module de FAO

La Conception Assistée par Ordinateur (CAO) nous permet de concevoir un circuit électronique en toute quiétude. Le lien est fort entre le schéma et le circuit imprimé: les logiciels de CAO actuels sont capables de rendre bien des services : contrôle électriques, contrôles dimensionnels, auto-routage, …

Cependant, la concrétisation d’une conception en un circuit imprimé fonctionnel reste encore une opération assez complexe. Voici ma chaine logicielle complète pour la réalisation de circuits imprimés:

NB : PERCIVAL et LANCELOT font tous les deux partie de l’environnement de FAO GALAAD.

On distingue trois grandes phases:

1. La conception du circuit proprement dite avec un logiciel de CAO, dans mon cas, EAGLE
2. La préparation à l’usinage avec PERCIVAL
3. L’usinage avec LANCELOT

Ces phases sont toujours reliées par un fichier descriptif du circuit imprimé : PERCIVAL attend un fichier Gerber en entrée et délivre un fichier PCB ou GCODE directement interprétable par le module d’usinage (LANCELOT).

Exportation du fichier Gerber avec EAGLE

ASTUCES :

• Il convient de ne pas définir de plan de masse dans EAGLE, la suite du processus en sera simplifiée. Le plan de masse sera géré par PERCIVAL.
• L’ajout de quatre repères en croix aux quatre coins du circuit va simplifier le réglage de la fraiseuse.

EAGLE comporte un module appelé CAM (Computer Aided Machining – équivalent anglo-saxon de FAO). Il est accessible depuis la fenêtre d’édition du circuit:

Ce module permet d’exporter différents types de fichiers d’usinage. On peut symétriser le circuit imprimé, le faire tourner, … Il est également possible de choisir les couches à exporter. La configuration du module CAM est appelée un job. Il est possible d’enregistrer ses jobs au format .cam pour les rappeler plus facilement et ne pas oublier d’étape.

Voici les grandes lignes à respecter pour l’export vers PERCIVAL d’un circuit simple face:

• Device: GERBER_RS274X
• Mirror
• pos. Coord
• Optimize
• Layers 16, 17, 18:
  • Bottom
  • Pads
  • Vias

Par extension, voici les grandes lignes à respecter pour l’export vers PERCIVAL de la face supérieure d’un circuit double face:

• Device: GERBER_RS274X
• pos. Coord
• Optimize
• Layers 1, 17, 18:
  • Top
  • Pads
  • Vias

Voici les deux fichiers .cam que j’utilise:

• percival_bottom.cam
• percival_top.cam

Pour générer le fichier Gerber, cliquer simplement sur « Process Job » et le tour est joué.

Importation du fichier Gerber dans PERCIVAL

Pour importer le fichier Gerber dans PERCIVAL, il faut passer par le menu Fichier -> Ouvrir -> Nouveau Circuit (Ctrl + O). Pointer ensuite sur le fichier .grb généré par EAGLE. Une incompatibilité du format Gerber généré par EAGLE va causer l’apparition de ce message d’erreur:

Rien de grave cependant: PERCIVAL nous informe simplement que le fichier Gerber ne contient pas les définitions des pastilles. D’une certaine façon, cela nous arrange puisque nous allons reconfigurer toutes les pastilles du circuit pour optimiser l’usinage. Après validation du message, un assistant de configuration des pastilles s’ouvre:

Les pastilles concernées s’allument en rouge sur le circuit. Il est alors possible de modifier leur forme, leurs dimensions, le diamètre de perçage, …

Il faut passer en revue toutes les pastilles de la carte (en navigant avec les boutons « < » et « >« ) pour définir tous ces paramètres. Il est facile de voir quelle taille de pastille va causer un court-circuit ou bien sera trop petite par rapport au diamètre de perçage.

Une fois cette tâche effectuée, on se rend compte que certaines pastilles n’ont pas été traitées:

Le problème provient de la manière utilisée par EAGLE pour exporter les pastilles oblongues: elles sont définies comme des pistes dans le fichier. Pour convertir ces « pistes » en pastille, il faut simplement faire un clic droit sur l’une d’elle et choisir définir comme pastille. PERCIVAL propose alors gentiment de transformer toutes les autres pastilles équivalentes. A vous de voir si PERCIVAL ne fait pas un excès de zèle en convertissant en pastille des pistes bien réelles.

Une fois les torts rétablis et les fausses pistes transformées en pastilles, il convient de refaire l’étape précédente en rouvrant l’assistant de configuration de pastilles (clic droit sur la pastille a configurer -> Editer les pastilles identiques).

Gestion des plans de masse

Avec la gravure à l’anglaise, le plan de masse est quasiment intrinsèque. En effet, à moins de faire en sorte que la fraiseuse retire tout le cuivre inutile, celle-ci na va faire qu’un simple détourage. Il va donc demeurer de grandes zones cuivrées autour des pistes. Il convient alors de les relier à la masse. Cette opération s’effectue dans PERCIVAL et requiert un peu d’attention. En effet, il faut identifier sur le circuit quelles sont les broches et pistes reliées à la masse. Ensuite, il faudra passer chaque piste une par une en faisant un Clic droit -> Définir comme plan-masse. Les pistes appartenant au plan de masse sont symbolisées en marron.

Il est également possible de convertir les pastilles reliées au plan de masse en pastilles thermiques. Cela va grandement simplifier le repérage et la soudure desdites pastilles. Pour ce faire, activer l’outil Pastille thermique (en choisissant l’orientation de la pastille) et cliquer les pastilles à convertir.

Cette fois-ci quand PERCIVAL propose de convertir les pastilles identiques, il est recommandé de ne pas le faire. Une croix apparait en légère surimpression sur les pastilles thermiques.

Réglage de l’origine du circuit

Pour usiner le circuit imprimé, le module d’usinage va nécessiter la prise d’origine de la pièce. Cette origine sera d’autant plus simple à régler si elle se situe sur le bord de la carte. Dans PERCIVAL, il est possible de positionner deux croix: une rouge et une bleue.

Ces croix pourront servir d’origine pièce au module d’usinage. Pour positionner précisément ces croix, il convient au préalable d’avoir prévu des repères dans EAGLE (une petite croix dans chaque angle dessinée avec des pistes sur chacune des faces à usiner). Une fois l’outil activé en mode « Pointage manuel », il suffit de cliquer sur l’extrémité d’une piste ou une pastille pour y positionner la croix.

Le circuit est maintenant prêt pour le calcul des contours d’isolation.

Calcul des contours d’isolation

Les contours d’isolation sont les chemins que suivra la fraise afin d’isoler électriquement les pistes du circuit. Le calcul des contours dépend principalement de deux facteurs:

• La forme de l’outil
• La largeur d’isolation entre la piste et le plan de masse

Le premier facteur se règle dans le menu Paramètres -> Bibliothèque d’outils.

Ce menu permet de déclarer les différents outils en votre disposition. Ainsi, PERCIVAL adapteras les calculs d’isolation et de perçage à la forme et au diamètre des outils disponibles. En outre, le module d’usinage sera à même de vous demander d’installer le bon outil avant chaque phase de gravure ou de perçage.

J’utilise personnellement ces outils:

• Un stylet conique à 60° pour l’isolation (soie de 3.17mm)
• Un foret de 0.8mm pour les perçages (soie de 3.17mm)
• Une fraise à rainurer de 2mm pour le détourage

Il est possible de remplir le nombre de dents et la vitesse de la broche pour chaque outil. PERCIVAL calcul ainsi les vitesses avance optimales pour l’usinage.

Pour calculer les contours d’isolation, il faut utiliser le menu Usinage -> Contours d’isolation -> Calculer les contours. Il est possible de choisir le nombre de passes à réaliser autour des pistes et des pastilles. Plus ce nombre est élevé, plus large sera le contour d’isolation, mais plus long sera l’usinage. Pour ma part, je me contente de deux contours successifs et d’un contour supplémentaire autour des pastilles. Quand le calcul est terminé, PERCIVAL affiche un rendu du résultat final. Les contours affichés en rouges sont ceux qui ont été « forcés » par le logiciel, les pastilles ou pistes adjacentes étant trop proches.

Il est également possible de gérer le détourage de la carte (découpe du circuit à la fraise) en ajoutant ou non pontets de maintien.

Usinage du circuit

Positionner la carte à usiner

Pour fixer la carte à usiner sur la table de la fraiseuse, j’utilise pour ma part du Scotch double faces transparent « extra-fort »:

https://www.leroymerlin.fr/v3/p/produits/adhesif-scotch-fixation-double-face-interieur-exterieur-l1-5mxl19mm-transparent-e1400097015

Il présente l’avantage d’avoir une épaisseur suffisante pour ne pas usiner la table de la fraiseuse. Il est en outre assez simple à décoller.

Un petit carré d’adhésif dans chaque coin et un au centre de la carte suffisent à maintenir le circuit en place pendant tout l’usinage.

Lancer l’usinage

L’usinage du circuit n’est alors plus qu’une « simple » formalité. Il suffit de choisir le menu Usinage -> Fraisage, et de choisir Chainer automatiquement au module d’usinage. Le fichier GCODE est automatiquement généré et passé à LANCELOT pour la gravure.

ATTENTION : Si le circuit a été inversé à la génération du fichier GERBER (mirror activé pour la face du dessous dans EAGLE), il convient de ne pas activer l’inversion horizontale à ce moment du processus.

LANCELOT est lancé automatiquement.

La première page permet de configurer l’usinage. Le tableau en haut à gauche récapitule les différentes phases de la réalisation. Il est possible de les activer (entouré en vert) ou de les désactiver (barré de rouge) à volonté. Chaque phase est associée à un outil et repérée par le numéro de l’outil dans le magasin. Il est également possible de surcharger les paramètres d’usinage (profondeur des passes, vitesse d’avance, …). Enfin, il est possible de tourner ou symétriser le circuit, au cas où une erreur se serait glissé dans le processus précédent.

La deuxième page permet de positionner la carte sur la table d’usinage. Il faut prendre l’origine de la carte (croix rouge, croix bleue ou bien un coin du circuit) en X et Y. Pour le réglage de la hauteur d’outil, deux méthodes sont disponibles:

• La machine est équipée d’un capteur de hauteur d’outil mobile
• Le positionnement de l’outil à fleur de la carte

Pour la première méthode, il convient de se référer à la notice d’utilisation du logiciel LANCELOT. Pour la seconde, je préconise une astuce à base d’Ohmmètre. ATTENTION : toute cette manipulation devra être effectuée broche hors tension, vous allez entrer en contact avec l’outil.

• Installer l’outil dans la broche
• Amener l’outil à quelques millimètres de la surface de la carte
• Passer le pilotage en mode 1mm ou 1/10mm selon la distance entre l’outil et la carte
• Mettre l’Ohmmètre en mode continuité (bip quand les pointes de touche se touchent)
• Mettre une pointe sur la carte (partie cuivrée) l’autre sur le mandrin de la broche (ou directement l’outil si le mandrin est en plastique)
• Descendre l’outil progressivement et doucement jusqu’au bip de l’Ohmmètre
• Cliquer sur Z – ok

ATTENTION : avec un foret de 0.8mm, cette manipulation peut s’avérer destructrice pour l’outil sir la vitesse de descente est trop élevée.

Une fois l’origine réglée, il est alors possible de lancer l’Usinage Automatique (ou de faire une simulation avant d’ouvrir les hostilités).

Si tout fonctionne comme prévu, LANCELOT devrait aller au bout de la première phase avant de demander un changement d’outil. Il convient alors de refaire la prise d’origine en Z.

Voici le résultat pour un circuit simple face basé autour d’un PIC18F4550 :

[metaslider id=910]

Voici deux petites vidéos de l’outil en action (Attention, le volume sonore est un peu élevé…):

Conclusion

Avec le bon outillage, il est aisé de passer d’une conception virtuelle à un circuit bien réel. Il est tout a fait normal d’éprouver une certaine appréhension lors des premiers mouvement de la broche. J’ai cassé quelques outils et gâché un certain nombre de cartes avant de pleinement prendre en main les différents modules logiciels du processus. Il est important d’être méthodique de bout en bout. Le processus que je présente ici n’est bien sûr pas parole d’évangiles, cependant, il fonctionne à merveille chez moi.

Bonnes réalisations !

Cet article Exporter un Circuit Imprimé depuis EAGLE vers GALAAD/PERCIVAL est apparu en premier sur Electronique et Informatique.

Du coup, la version 8 marque un tournant dans l’évolution d’Eagle, notamment avec l’arrivée de nouvelles fonctionnalités et une certaine évolution de l’ergonomie générale. Le routage des pistes simplifie le contournement des pastilles, il y a un router spécifique pour les composants en boitier BGA, ou encore il est possible de faire des Design Blocks.

Mais qu’est-ce qu’un Design Block ?

L’une des nouveautés qui m’apparait bien utile est la gestion de Design Blocks. Il s’agit ni plus ni moins de la possibilité de créer des sous-schémas élémentaires avec le routage du PCB (Printed Circuit Board) associé, afin de construire un schéma plus évolué en assemblant ces briques de base.

Les intérêts sont multiples:

1. Prototyper les Design Blocks et les tester unitairement
2. Faciliter la réplication en limitant au maximum les erreurs
3. Partager plus facilement ses réalisations

Mise en pratique

Dans la fenêtre principale d’Eagle, on notera l’apparition d’une nouvelle catégorie dans l’explorateur de projet. Cette section est nommé Design Blocks…

Voici les grandes étapes de la mise en œuvre des Design Blocks.

Création d’un Design Block

Pour créer un nouveau Design Block, il faut passer par la barre d’Outils File -> New -> Designblock.

La fenêtre qui s’ouvre alors est identique à celle d’édition de schéma habituelle. On saisi le schéma dans l’éditeur habituel, et on route le PCB dans l’autre partie. Le passage d’une fenêtre à l’autre est assuré par le bouton  « Switch to board » (respectivement  « Switch to Schematic »).

Voici par exemple un régulateur linéaire 5V à base de 7805:

Ainsi que le routage associé:

On remarque que l’anode de la diode D1 n’est pas reliée, de même que la sortie régulée du 7805. C’est tout à fait normal, du fait que le 12V sera amené par une tierce partie d’un schéma plus complexe et que le 5V va aller alimenter d’autres composants.

Sauvegarder le Design Block

Quand le Design Block est terminé, on peut l’enregistrer dans un fichier .dbl. Un assistant permet de saisir des informations de documentation adjointes au fichier.

NB: la documentation du Design Block est au format HTML. Il est tout à fait possible de structurer celle-ci avec des balises <h1>, <ul> ou autres.

Intégration du Design Block dans un schéma plus complexe

Pour tirer pleinement parti des Design Block, il est intéressant les ajouter au schéma à partir de la carte. Dans l’éditeur de carte, cliquer sur le bouton « Add Design Block » :

Dès que le Design Block est positionné sur la carte, Eagle ouvre automatiquement l’éditeur de schéma pour faire de même:

Une fois l’ajout du Design Block effectué sur la carte et le schéma, un popup apparait permettant d’assigner les signaux du Design Block aux signaux du schéma en cours d’édition:

Si les signaux sont cohérents avec ceux du schéma, ils apparaissent en jaune. Sinon, il est possible de les réaffecter à la volée. Il se peut également que des signaux ne soient pas pertinents (par exemple N$2 et N$4). Dans ce cas, il convient de les laisser tranquilles.

NB: le nommage des signaux, soit en utilisant les composants des bibliothèques Supply1 et Supply2, soit en nommant manuellement les fils, permet de s’y retrouver beaucoup plus facilement.

Une fois ce popup validé, les liens électriques sont automatiquement rétablis:

Le reste de l’édition du schéma et de la carte se fait de manière conventionnelle. Vous trouverez dans un précédent article quelques concepts de base sur l’utilisation d’Eagle: Conception d’un circuit imprimé avec Eagle

Bien que rédigé pour la version 7, ce tutoriel reste parfaitement applicable sur la version 8.

Conclusion

Les Design Blocks peuvent offrir une meilleure expérience de conception avec Eagle, tout en limitant les risques liés à la duplication manuelle. Il est en effet facile d’imaginer des Design Blocks pour les fonctions récurrentes telles que:

• les alimentations régulées
• les circuits d’horloge à quartz
• les conditionneurs de capteurs
• un microcontrôleur tout prêt alimenté et cadencé, avec le RESET en prime
• …

Pour la curiosité, je joins le DBL de mon régulateur 5V linéaire: 7805.dbl

Cet article Création de Design Blocks avec Eagle 8 est apparu en premier sur Electronique et Informatique.