IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Arduino Discussion :

Commande PWM moteur CC, lecture encodeur


Sujet :

Arduino

  1. #21
    Expert confirmé

    Homme Profil pro
    mad scientist :)
    Inscrit en
    Septembre 2019
    Messages
    2 685
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : mad scientist :)

    Informations forums :
    Inscription : Septembre 2019
    Messages : 2 685
    Points : 5 328
    Points
    5 328
    Par défaut
    Salut @Horus68

    en regardant les données
    Citation Envoyé par Horus68 Voir le message
    PWM à 128
    824 -5067
    896 -5068
    704 -5069
    940 -5070
    804 -5071
    788 -5072
    844 -5073
    880 -5074
    732 -5075
    848 -5076
    856 -5077
    772 -5078

    Avec un PWM à 255
    576 -8783
    660 -8784
    668 -8785
    604 -8786
    644 -8787
    704 -8788
    556 -8789
    744 -8790
    632 -8791
    624 -8792
    668 -8793
    700 -8794
    580 -8795
    672 -8796
    on voit qu'on ne rate aucun tick dans la loop mais ce qui est inquiétant c'est la variance de l'encodeur quadratique

    Avec un PWM à 128 on voit une période moyenne à 824µs mais l'écart type est conséquent à 68µs et à 255 on a une période moyenne à 645µs et un écart type de 54µs soit plus de 8%
    ==> ça veut dire que les pôles ne sont pas super bien répartis sur le pourtour de l'encodeur

    Essayez avec un code comme cela:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    #include <Encoder.h>
    Encoder encodeur(2, 3);          //   avoid using pins with LEDs attached
    const byte enablePin =  6;    // attention changement  Digital pin pour commande moteur
    unsigned long newTime ;
    unsigned long oldTime ;
     
    long newPosition;
    long oldPosition = -999;
     
    void setup() {
      pinMode(enablePin, OUTPUT);   // Configuration de la broche en sortie
      analogWrite(enablePin, 128);   // Commande PWM de 0 à 255 Max (de 0 à 100% de la "tension d'alimentation")
      Serial.begin(250000);
      Serial.println("Basic Encoder Test:");
      encodeur.write(0);
    }
     
    void loop() {
      delay(1000); // attente de 1s
      newPosition = encodeur.read();
      newTime = micros();
      Serial.print(F("dt:"));
      Serial.print(newTime - oldTime);
      Serial.print(F("\tdP:"));
      Serial.println(newPosition - oldPosition);
      oldPosition = newPosition ;
      oldTime = newTime;
    }
    ça vous permettra de calculer le nombre de ticks par seconde assez simplement, en lissant sur 1 seconde de mesure

  2. #22
    Membre expert
    Homme Profil pro
    Inscrit en
    Octobre 2011
    Messages
    2 872
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Octobre 2011
    Messages : 2 872
    Points : 3 716
    Points
    3 716
    Par défaut
    Salut,

    Citation Envoyé par Jay M Voir le message
    Avec un PWM à 128 on voit une période moyenne à 824µs mais l'écart type est conséquent à 68µs et à 255 on a une période moyenne à 645µs et un écart type de 54µs soit plus de 8%
    ==> ça veut dire que les pôles ne sont pas super bien répartis sur le pourtour de l'encodeur
    C'est vrai que cela n'a pas l'air très précis ce qui semble être confirmé par la doc où l'on a notamment ceci :


    Nom : encodeur.PNG
Affichages : 177
Taille : 5,8 Ko

    90° +- 1/6T cela ne semble pas très précis, non ???

  3. #23
    Nouveau Candidat au Club
    Homme Profil pro
    Enseignant
    Inscrit en
    Avril 2018
    Messages
    25
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Enseignant
    Secteur : Enseignement

    Informations forums :
    Inscription : Avril 2018
    Messages : 25
    Points : 1
    Points
    1
    Par défaut
    Salut,

    Citation Envoyé par Beginner. Voir le message
    Salut,


    90° +- 1/6T cela ne semble pas très précis, non ???
    Effectivement, 1/4 de T à + ou - 1/6 de T, c'est très très peu précis !
    Ah ben c'est pas cher aussi...

    Je me demandais si je ne pourrais pas faire un post-traitement des données brutes,
    pour calculer l'écart angulaire entre les pôles, en repérant le max, le min dans une fenêtre glissante de 12 intervalles successifs
    En faisant un calcul de vitesse moyenne sur une sec, on doit pouvoir le corriger automatiquement.
    Nous avons une demie-douzaine de ces moteurs. On va peut-être pas les jeter tout de suite.

    Il faut voir que je m'intéresse aussi (et surtout) au régime transitoire, qui dure environ 20millisec.
    Donc pour avoir des mesures pas trop "bruitées" de la montée en vitesse, il va falloir bosser dur !

    Merci pour les avis, je progresse grâce à vous !
    Cordialement
    Horus68

  4. #24
    Membre expert
    Homme Profil pro
    Inscrit en
    Octobre 2011
    Messages
    2 872
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Octobre 2011
    Messages : 2 872
    Points : 3 716
    Points
    3 716
    Par défaut
    Salut,
    Citation Envoyé par Horus68 Voir le message
    Je me demandais si je ne pourrais pas faire un post-traitement des données brutes,
    pour calculer l'écart angulaire entre les pôles, en repérant le max, le min dans une fenêtre glissante de 12 intervalles successifs
    En faisant un calcul de vitesse moyenne sur une sec, on doit pouvoir le corriger automatiquement.
    Oui mais si on fait cela ne perdons nous pas la précision à laquelle tu semblais tenir (précision qu'on obtient en exploitant les deux voies) ? Je veux dire si on veut une vitesse moyenne alors il me semble qu'on a plus besoin de connaitre avec précision la position angulaire à un instant t, non ?

    Si oui dans ce cas je me dis autant ne mesurer que le temps mis pour faire un tour complet et là peu importe les écarts angulaires car on sait que 1 tour complet cela correspond à 360°.

    Je ne sais pas si je suis clair...

  5. #25
    Expert confirmé

    Homme Profil pro
    mad scientist :)
    Inscrit en
    Septembre 2019
    Messages
    2 685
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : mad scientist :)

    Informations forums :
    Inscription : Septembre 2019
    Messages : 2 685
    Points : 5 328
    Points
    5 328
    Par défaut
    la demande d'origine
    On en déduit le gain statique et la constante de temps, en assimilant le moteur à un premier ordre
    Si ma mémoire ne me joue pas des tours (on veut la valeur de la composante de sortie à l'infini pour une entrée constante - le PWM) vous trouverez ce Gain statique en assimilant votre système à un système linéaire continu invariant stable donc la précision à la micro-seconde en utilisant tous les pôles n'a pas vraiment d'importance, comptez le nombre de ticks (sur une seule broche ou les 2) pour x secondes et vous aurez la vitesse (6 ticks ou 12 par tour suivant ce que vous comptez)

  6. #26
    Nouveau Candidat au Club
    Homme Profil pro
    Enseignant
    Inscrit en
    Avril 2018
    Messages
    25
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Enseignant
    Secteur : Enseignement

    Informations forums :
    Inscription : Avril 2018
    Messages : 25
    Points : 1
    Points
    1
    Par défaut
    Bonjour Beginner,

    Citation Envoyé par Beginner. Voir le message
    Salut,
    Oui mais si on fait cela ne perdons nous pas la précision à laquelle tu semblais tenir (précision qu'on obtient en exploitant les deux voies) ?
    Je ne sais pas si je suis clair...
    Alors, oui, je veux garder la précision, c'est pour ça que je voulais faire un post-traitement pour évaluer l'angle entre chaque pôle.
    Du coup, c'est moi qui n'ai pas été clair :
    Je ne pense pas atteindre une précision diabolique, mais compenser la faible précision du capteur :
    nominalement, pour 12 intervalles, on devrait avoir 30° et donc une période entre fronts identique, en régime permanent
    Ici, ce n'est pas le cas, donc on doit avoir des intervalles angulaires de type 28°, 32°, 35°, 25°... (valeurs parfaitement arbitraires)
    et des suites de périodes en proportion, modulo 12.

    On récupère le cycle des durées entre fronts en régime permanent, on calcule la vitesse moyenne et on en déduit les angles de chaque intervalle.
    On crée un tableau de valeurs des Théta i, i de 0 à 11
    Ensuite en remontant vers l'origine des temps, par pas de 12, on sait à chaque interruption quel intervalle angulaire vient d'être franchi, et en combien de temps, donc on peut calculer une vitesse angulaire corrigée du défaut, pour mieux observer la montée.

    Cordialement
    Horus68

  7. #27
    Nouveau Candidat au Club
    Homme Profil pro
    Enseignant
    Inscrit en
    Avril 2018
    Messages
    25
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Enseignant
    Secteur : Enseignement

    Informations forums :
    Inscription : Avril 2018
    Messages : 25
    Points : 1
    Points
    1
    Par défaut
    Bonjour Jay M,

    Citation Envoyé par Jay M Voir le message
    la demande d'origine
    Si ma mémoire ne me joue pas des tours (on veut la valeur de la composante de sortie à l'infini pour une entrée constante - le PWM) vous trouverez ce Gain statique en assimilant votre système à un système linéaire continu invariant stable donc la précision à la micro-seconde en utilisant tous les pôles n'a pas vraiment d'importance, comptez le nombre de ticks (sur une seule broche ou les 2) pour x secondes et vous aurez la vitesse (6 ticks ou 12 par tour suivant ce que vous comptez)
    Alors, oui, l'identification d'un moteur commandé en tension à un premier ordre est bien le but.
    C'est d'ailleurs le début de l'histoire, puisque l'on cherchera à calculer le comportement en boucle fermée avec une boucle d'asservissement
    et une correction soit proportionnelle, soit proportionnelle-Intégrale, mais c'est quand on sera sûr de pas faire de c... en boucle ouverte.
    Et évidemment de comparer la prévision (calcul) avec ce que l'on obtient (mesure).

    Bon, pour le gain, je n'ai besoin que de la vitesse en régime permanent, donc une moyenne sur 1 seconde est très bien...
    Mais ce n'est pas le cas pour la constante de temps, qui sera déterminée à l'aide du temps de réponse à 5%
    ou du temps de montée à 63%. Et là, j'ai besoin de rapidité et de précision de la part de mon moyen de mesure.

    Une petite précision, à l'heure actuelle, on exploite des données de vitesse en calculant la moyenne des écarts au carré entre le modèle et les mesures.
    ça permet de s'affranchir en partie des problèmes de précision du capteur,
    mais afficher des mesures aussi fluctuantes, ça ne fait pas très sérieux même (et surtout) aux yeux d'élèves novices
    De plus, ce sont des obstacles supplémentaires que l'on dresse entre la théorie bien lisse et la pratique...
    et faire le lien entre les 2 n'est jamais trivial... La preuve avec cette discussion.

    PS : j'ai utilisé le programme avec Encoder et Delay(1000). La fluctuation est effectivement bien réduite.
    Un petit récap dès que j'ai suffisamment de données. Merci encore.
    Cordialement
    Horus68

  8. #28
    Expert confirmé

    Homme Profil pro
    mad scientist :)
    Inscrit en
    Septembre 2019
    Messages
    2 685
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : mad scientist :)

    Informations forums :
    Inscription : Septembre 2019
    Messages : 2 685
    Points : 5 328
    Points
    5 328
    Par défaut
    Citation Envoyé par Horus68 Voir le message
    Mais ce n'est pas le cas pour la constante de temps, qui sera déterminée à l'aide du temps de réponse à 5%
    ou du temps de montée à 63%. Et là, j'ai besoin de rapidité et de précision de la part de mon moyen de mesure.
    Oui, j'ai bien en tête les 5% et 63%, mais c'est valable que si le système est vraiment linéaire invariant du premier ordre - ie si la réponse dans le temps est liée aux entrées par une équation différentielle linéaire à coefficients constants. ça marche pas trop mal avec un circuit RC, pour un moteur dont le enable est piloté en PWM c'est à mon avis moins vrai — ça va dépendre de la fréquence du PWM, de l'inertie et qualité du moteur, d'autant plus sans doute surtout en régime transitoire.

    Ce serait pas mal de voir ce qu'il se passe en enlevant le PWM (mettre l'alimentation du moteur sur une alimentation de labo) et en pilotant juste le enable en tout ou rien (et varier la puissance dispo pour trouver quand le moteur se comporte bien comme un système linéaire du premier ordre)

  9. #29
    Nouveau Candidat au Club
    Homme Profil pro
    Enseignant
    Inscrit en
    Avril 2018
    Messages
    25
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Enseignant
    Secteur : Enseignement

    Informations forums :
    Inscription : Avril 2018
    Messages : 25
    Points : 1
    Points
    1
    Par défaut
    Citation Envoyé par Jay M Voir le message
    Ce serait pas mal de voir ce qu'il se passe en enlevant le PWM (mettre l'alimentation du moteur sur une alimentation de labo) et en pilotant juste le enable en tout ou rien (et varier la puissance dispo pour trouver quand le moteur se comporte bien comme un système linéaire du premier ordre)
    Avec nos anciens programmes de mesure, avec un PWM à 255, en faisant varier directement la tension d'alimentation, on relevait :
    vitesse finale / tension : 8.6 °/s/V ; Tau : 17ms pour 7.5V
    8.8 ; Tau : 20ms pour 6
    8.8 ; Tau : 15ms pour 4.5
    9.0 ; Tau : 13ms pour 3
    Pas super linéaire, un ratio vitesse/V plus grand pour la tension la plus faible, là ou j'attendais le contraire !
    (importance relative plus forte des frottements)
    Une constante de temps pas super constante ... et même la tendance n'est pas monotone

    La linéarité, c'est pourtant le genre d'hypothèses que l'on prend, sans trop se poser de question, avec des moteurs CC
    (Cf. le site de 3sigma ou la carte Astrolab de chez SET)

    ça mériterait effectivement de mesurer tout ça plus précisément (alimentation : tension et intensité, vitesse),
    en alimentant directement le moteur.

    Cordialement
    Horus68

  10. #30
    Nouveau Candidat au Club
    Homme Profil pro
    Enseignant
    Inscrit en
    Avril 2018
    Messages
    25
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Enseignant
    Secteur : Enseignement

    Informations forums :
    Inscription : Avril 2018
    Messages : 25
    Points : 1
    Points
    1
    Par défaut Non linéarité vitesse/PWM
    Bonjour à tous,

    J'ai utilisé le programme de Jay M
    J'ai réglé le PWM à différentes valeurs >=64, pas de 16
    J'ai relevé la vitesse finale (Nb de fronts par sec) en faisant la moyenne sur 30 sec
    Voilà ce que ça donne :
    Nom : Encoder250-1_PWM.JPG
Affichages : 162
Taille : 25,9 Ko

    Pas linéaire du tout !!
    Je m'y attendais pour les basses valeurs de PWM, puisqu'en deçà de 64, la rotation n'a plus lieu
    A noter, la singularité du PWM à 255 (à cause de l'absence de commutation ?)

    Du coup, pour un éventuel asservissement en vitesse, il faudra calculer un gain en linéarisant autour du point de fonctionnement,
    en travaillant sur des échelons de vitesse d'amplitude modeste, si on veut avoir une chance de faire matcher calculs et mesures.
    Idem pour obtenir la constante de temps.

    Comme le disait jpbbricole, il y a de nombreux phénomènes qui rendent cette linéarité caduque, sur de grandes amplitudes.
    Cordialement
    Horus68

  11. #31
    Expert confirmé

    Homme Profil pro
    mad scientist :)
    Inscrit en
    Septembre 2019
    Messages
    2 685
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : mad scientist :)

    Informations forums :
    Inscription : Septembre 2019
    Messages : 2 685
    Points : 5 328
    Points
    5 328
    Par défaut
    ah oui c'est assez parlant !

    peut-être il faudra vous limiter à un intervalle de valeur PWM où le changement de vitesse à l'air assez linéaire?
    Nom : courbe.png
Affichages : 144
Taille : 156,7 Ko

    à noter que sur un Arduino UNO les pin PWM sont les suivantes : 3, 5, 6, 9, 10, 11. La fréquence de PWM est de 490 Hz mais pour les pins 5 et 6 elle est double 980 Hz. Peut-être que cette fréquence double est génératrice aussi de souci. ça vaudrait le coup de voir si la courbe est identique sur la pin 3 par exemple.

    j'ai lu aussi votre commentaire:
    Avec nos anciens programmes de mesure, avec un PWM à 255, en faisant varier directement la tension d'alimentation
    est-ce qu'il y avait une limite en courant? Le moteur ne démarre qu'au-delà d'une tension de seuil dépendante des frottements mais le courant consommé croît avec les frottements et autres pertes qui vont dépendre non linéairement de la vitesse. De plus avec une alimentation pulsée (notre PWM) l'induit du moteur présente une self-inductance dont il faudrait tenir compte

  12. #32
    Nouveau Candidat au Club
    Homme Profil pro
    Enseignant
    Inscrit en
    Avril 2018
    Messages
    25
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Enseignant
    Secteur : Enseignement

    Informations forums :
    Inscription : Avril 2018
    Messages : 25
    Points : 1
    Points
    1
    Par défaut
    Bonjour,
    de retour après un gros break ...

    Citation Envoyé par Jay M Voir le message
    ah oui c'est assez parlant !
    peut-être il faudra vous limiter à un intervalle de valeur PWM où le changement de vitesse à l'air assez linéaire?
    Oui, j'y ai pensé, pour une identification sur la base d'un échelon de vitesse entre 2 valeurs assez élevées de PWM, c'est jouable.
    Mais le but est d'aboutir à un asservissement de position, et là, on utilisera toute la plage de vitesse, enfin, notamment la partie inférieure si on ne sature pas,
    et donc on subira la non linéarité, ce qui rend le comportement non calculable... Beurk !

    Citation Envoyé par Jay M Voir le message
    à noter que sur un Arduino UNO les pin PWM sont les suivantes : 3, 5, 6, 9, 10, 11. La fréquence de PWM est de 490 Hz mais pour les pins 5 et 6 elle est double 980 Hz. Peut-être que cette fréquence double est génératrice aussi de souci. ça vaudrait le coup de voir si la courbe est identique sur la pin 3 par exemple.
    Alors, cette fréquence n'est pas supposée poser de problème. C'est lorsqu'elle est beaucoup plus basse que le comportement change : conduction discontinue et variation d'intensité de 0 à Imax puis redescente à 0...
    Ici, doubler la PWM ne devrait pas changer le comportement (conduction dite continue) Cf. le site "Modelleisenbahn" Tension hachée et pertes Joules.
    Cela dit, je tenterai de voir si il y a une différence en changeant de broche.

    Citation Envoyé par Jay M Voir le message
    j'ai lu aussi votre commentaire:
    est-ce qu'il y avait une limite en courant? Le moteur ne démarre qu'au-delà d'une tension de seuil dépendante des frottements mais le courant consommé croît avec les frottements et autres pertes qui vont dépendre non linéairement de la vitesse. De plus avec une alimentation pulsée (notre PWM) l'induit du moteur présente une self-inductance dont il faudrait tenir compte
    Pour ce qui est du courant moteur, je me suis méfié de la petite alim que j'utilisais, et en utilisant une autre affichant le courant, on note une légère augmentation avec la vitesse, mais l'ordre de grandeur est de 0.13 ampères à 0,18A, pour une alim capable d'en délivrer 2...
    Il y a de la marge. Mon moteur tourne presque à vide, mais effectivement, les frottements secs dans le réducteur justifient la tension minimale induisant le courant mini pour que le moteur démarre.
    A noter que les modèles de calcul avec frottement sec + frottement fluide sont linéaires quand le moteur tourne.

    Mon collègue a obtenu un comportement linéaire en utilisant un pont différent et en faisant de la PWM sur la broche DIR et non sur EN (Enable)
    Il faut que je creuse la question... et je ne pense pas pouvoir faire la même chose avec mon PModHB5.

    Merci pour ces suggestions
    Cordialement
    Horus

  13. #33
    Nouveau Candidat au Club
    Homme Profil pro
    Enseignant
    Inscrit en
    Avril 2018
    Messages
    25
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Enseignant
    Secteur : Enseignement

    Informations forums :
    Inscription : Avril 2018
    Messages : 25
    Points : 1
    Points
    1
    Par défaut Comparaison de différents ponts
    Bonjour,

    Après avoir suspecté mon alim, une HQPower 2A, 0 à 12V
    et testé le comportement moteur avec une Elix 3A, 0-30V sans constater d'amélioration...

    J'ai testé différents hacheurs pour comparaison. Même programme, branchements analogues et même principe de commande :
    PWM sur la broche En (Enable) ou sur la "gate" du MosFet

    Pont en H L293D du starter kit, avec branchements du livret ;
    MosFet IRF520, diode de roue libre, résistance, conforme au schéma ci-dessous :
    Nom : MosFetL-IRF520.jpg
Affichages : 142
Taille : 45,9 Ko

    Et ça donne ça :
    Nom : Encoder250-1_ComparPonts.JPG
Affichages : 137
Taille : 34,8 Ko

    On peut observer une certaine constance des résultats (non linéarité), et des différences importantes...
    Aucune idée des causes probables...

    Cordialement
    Horus68

  14. #34
    Expert confirmé

    Homme Profil pro
    mad scientist :)
    Inscrit en
    Septembre 2019
    Messages
    2 685
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : mad scientist :)

    Informations forums :
    Inscription : Septembre 2019
    Messages : 2 685
    Points : 5 328
    Points
    5 328
    Par défaut
    c'est frustrant.... peut-être une déficience du PModHB5?

  15. #35
    Nouveau Candidat au Club
    Homme Profil pro
    Enseignant
    Inscrit en
    Avril 2018
    Messages
    25
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Enseignant
    Secteur : Enseignement

    Informations forums :
    Inscription : Avril 2018
    Messages : 25
    Points : 1
    Points
    1
    Par défaut Correction des imprécisions du codeur par post-traitement
    Re,

    J'avais dit que je ferai un petit programme python pour voir si on pouvait améliorer les mesures, le voilà
    (les puristes y trouveront sans doute beaucoup à redire)
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    ## Repérage des différents poles et calcul des angles entre chaque
    # En régime permanent, la vitesse est constante, la durée entre deux poles n'est pas exactement la même
    # On importe le fichier texte contenant les intervalles de temps en microsecondes entre 2 ticks
    # On prend la moyenne des intervalles sur n tours consécutifs en partant de la fin
    # On en déduit une succession d'intervalles angulaires pour faire un tour
    # On calcule la vitesse en prenant angle calculé/durée mesurée
     
    import numpy as np
    import matplotlib.pyplot as plt
     
    poles = 6                   # fronts par voie (paires de poles)
    voies = 2                   # voies codeur
    nbtours = 1                 # nb de tours sur lesquels est calculée la moyenne
    cycle = poles*voies         # nb de fronts sur un tour
     
    fichier = open("essai.csv","r",encoding="utf8")
     
    # temps en millisecondes entre deux fronts
    temps = [float(x) for x in fichier.read().split()]
    # vitesse en tours par seconde, sachant qu'un tour est fait en "cycle"s fronts
    # en supposant que l'écart angulaire entre 2 fronts est absolument régulier
    vitesse = np.array([1000/(t*cycle) for t in temps])
    # Echelle des temps
    T=np.array([sum(temps[:i]) for i in range(len(temps))])/1000
     
    # Ici, on a exclu le dernier tour (ralentissement) du fichier csv
    def moyenne(temps) :
        """ Moyenne des périodes de chaque "pole", à vitesse supposée constante, appliquée à un fichier 'propre', sans valeur exceptionnelle en fin de colonne"""
        temps_sum = temps[-cycle:]      # somme des valeurs en vue d'une moyenne, initialisation
        for i in range(nbtours-1) :
            for j in range(cycle) :
                temps_sum[j] += temps[-(2*(i+1)*cycle)+j]
        return np.array(temps_sum)/nbtours            # Calcul et renvoi de la moyenne
     
    DeltaT_moy = moyenne(temps)             # Période moyenne de chaque "pole" en ms
    Theta_moy = DeltaT_moy/sum(DeltaT_moy)  # angle moyen entre chaque pole (en fraction de tour)
     
    def vitesse_corr(temps) :
        """ Vitesse corrigée des variations angulaires des poles"""
        i0 = cycle - len(temps)%cycle
        return np.array([Theta_moy[(i0+j)%cycle]*1000/temps[j] for j in range(len(temps))])
     
    vitesse2 = vitesse_corr(temps)
     
    plt.plot(T,vitesse,label = "vitesse brute (tr/s)")
    plt.plot(T,vitesse2,label = "vitesse corrigee (tr/s)")
    plt.legend()
    plt.show()
    Mais bon, ça tourne.
    On obtient ça sur un fichier test, extrait de mesures en millisecondes, la durée étant un peu courte pour assurer être en régime permanent sur plus d'un tour (le dernier), mais la comparaison est sans équivoque (sauf le premier point qui est une singularité due à une mauvaise maitrise de la communication série, sans doute)
    Nom : VitesseCorrigee.png
Affichages : 135
Taille : 39,0 Ko

    C'est pour le moment le travail le plus satisfaisant que j'ai pu effectuer sur ce thème.
    Il parait que la démarche d'investigation c'est pédagogiquement super, mais c'est un peu chronophage quand on est pas doué !!

    Cordialement
    Horus68

  16. #36
    Expert confirmé

    Homme Profil pro
    Directeur de projet
    Inscrit en
    Mai 2013
    Messages
    1 317
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Directeur de projet
    Secteur : Service public

    Informations forums :
    Inscription : Mai 2013
    Messages : 1 317
    Points : 4 124
    Points
    4 124
    Par défaut Encodeur & PWM
    Bonjour,

    Est-ce que vous savez comment fonctionne l'encodeur (électrique, magnétique, optique...) ? Je fais l'hypothèse non optique car la précision serait a priori bien meilleure.

    Si la détection est très économique, elle peut se baser sur la détection directe (ie sans roue) de la rotation du moteur (retour électrique ou détection des pôles tournant). Si c'est le cas bien que le moteur soit un passe bas, cela ne se manifeste qu'au travers de l'inertie mécanique. Mais si nous sommes en amont (avec la détection directe sur les champs tournant) nous risquons d'avoir un joyeux mélange entre le retour moteur vers les détecteurs et le PWM.

    Un test de cette hypothèse serait de changer la période de base du PWM et de regarder comment évolue la situation. Si rien ne se passe : rejet d'hypothèse. Sinon…

    Hors sujet : je me demande à quoi sert ici une détection en quadrature puisque nous commandons le sens de rotation du moteur.

    Salutations
    Ever tried. Ever failed. No matter. Try Again. Fail again. Fail better. (Samuel Beckett)

  17. #37
    Nouveau Candidat au Club
    Homme Profil pro
    Enseignant
    Inscrit en
    Avril 2018
    Messages
    25
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Enseignant
    Secteur : Enseignement

    Informations forums :
    Inscription : Avril 2018
    Messages : 25
    Points : 1
    Points
    1
    Par défaut Encodeur
    Bonjour Guesset,

    Capteur à effet hall à 3 paires de pôles. La précision annoncée dans la doc est très mauvaise. C'est confirmé par l'expérience.
    Le post-traitement est satisfaisant, d'autant que mon fichier exemple est plutôt mal choisi : on n'est pas vraiment arrivé en régime permanent sur le dernier tour.
    D'où la petite discontinuité (mini rampe) en début de tour.

    Le changement de fréquence PWM ne semble pas influente : en passant de la broche 5 (490Hz) à la 9 (980Hz), pas de changement.

    L'utilisation des 2 voies et de tous les fronts a pour but d'augmenter la précision.

    Pour la quadrature, ne peut-on pas envisager un cas de figure avec un système mécanique très inerte, qui continue à tourner dans le sens + longtemps après que l'on l'ait commandé pour le sens - ? Du coup, il est nécessaire de faire le test a ET b, après front sur a ou sur b pour savoir si il faut effectivement incrémenter ou décrémenter.
    Je me place là dans le cadre d'un asservissement en position, par exemple.

    Cordialement

  18. #38
    Expert confirmé

    Homme Profil pro
    Directeur de projet
    Inscrit en
    Mai 2013
    Messages
    1 317
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Directeur de projet
    Secteur : Service public

    Informations forums :
    Inscription : Mai 2013
    Messages : 1 317
    Points : 4 124
    Points
    4 124
    Par défaut Vitesse et précipitation
    Bonjour Horus,

    Citation Envoyé par Horus68 Voir le message
    ...Le changement de fréquence PWM ne semble pas influente : en passant de la broche 5 (490Hz) à la 9 (980Hz), pas de changement.
    L'utilisation des 2 voies et de tous les fronts a pour but d'augmenter la précision.
    Pour la quadrature, ne peut-on pas envisager un cas de figure avec un système mécanique très inerte, qui continue à tourner dans le sens + longtemps après que l'on l'ait commandé pour le sens - ? ...
    Ok, Hypothèse out.

    L'argument selon lequel on peut passer en marche arrière alors que le moteur est lancé à pleine vitesse en marche avant me laisse très dubitatif. On peut essayer. Une fois

    Salut
    Ever tried. Ever failed. No matter. Try Again. Fail again. Fail better. (Samuel Beckett)

  19. #39
    Nouveau Candidat au Club
    Homme Profil pro
    Enseignant
    Inscrit en
    Avril 2018
    Messages
    25
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Enseignant
    Secteur : Enseignement

    Informations forums :
    Inscription : Avril 2018
    Messages : 25
    Points : 1
    Points
    1
    Par défaut
    Salut Guesset,

    Citation Envoyé par Guesset Voir le message
    L'argument selon lequel on peut passer en marche arrière alors que le moteur est lancé à pleine vitesse en marche avant me laisse très dubitatif. On peut essayer. Une fois

    Salut
    Ah oui, on risque un appel d'intensité destructeur, c'est ça ? J'avoue, je n'ai jamais essayé, du coup, j'ai rien cramé
    L'intensité max est censée traverser le moteur pour un rotor bloqué, du coup, j'imagine que c'est pire dans ce cas de figure.
    Certains shield sont équipés d'une broche "break" qui est censée freiner le moteur efficacement. Comment est gérée l'intensité dans ce cas ?

    J'ai lu que le PMod était équipé d'un composant permettant d'éviter le court-circuit dans le pont dû à un différentiel de temps de commutation à la montée et à la descente. Donc, ça a l'air matériellement possible.
    D'autre part, l'intensité serait, a priori "seulement" le double de ce qu'elle est au démarrage quand je balance un échelon de tension, et ça, on le fait depuis fort longtemps sans dégat

    Il est vrai que dans le cadre d'un asservissement en position, la commande sera progressive, a moins d'avoir réglé le correcteur comme une brute.

    Quand au calcul du sens de rotation, c'est sans doute une précaution inutile. "Ceinture et bretelles"... ou juste un entêtement à visée didactique
    "puisqu'on vous a expliqué comment on faisait pour détecter le sens de rotation, et ben on va le programmer"
    Si on ne fait pas ça, si je te suis bien, on pourrait incrémenter ou décrémenter le compteur de position en fonction d'une sortie (commande de sens) plutôt qu'à partir d'entrées (état des voies A et B). Qu'en pensent les puristes ?

    Cordialement

  20. #40
    Nouveau Candidat au Club
    Homme Profil pro
    Enseignant
    Inscrit en
    Avril 2018
    Messages
    25
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Enseignant
    Secteur : Enseignement

    Informations forums :
    Inscription : Avril 2018
    Messages : 25
    Points : 1
    Points
    1
    Par défaut Vitesse et précipitation : Au temps pour moi !!
    Salut Guesset,

    Finalement, la différence entre 980Hz et 490Hz existe, mais elle n'était pas transcendante à mes yeux.
    J'ai essayé de pousser la logique jusqu'au bout, puisque sur la notice du PmodHB5, ils parlaient de 2 kHz,
    en modifiant la fréquence PWM, ça donne :
    Nom : Vitesse-PWM-Frequence.JPG
Affichages : 107
Taille : 35,0 Ko
    Seuls les 31250 Hz donnent un résultat avec une linéarité jusqu'à 0,
    celle à 3906 ayant une cassure, comme les autres...

    L'inconvénient majeur, c'est la faible plage de valeurs permettant de faire tourner le moteur : de 130 à 255,
    la moitié de la plage de réglage totale a priori disponible.

    Je vais pouvoir essayer de mesurer le transitoire pour différentes valeurs de PWM en échelon,
    pour voir si on obtient une vraie constante de temps, ce qui n'est absolument pas le cas avec des fréquences PWM standard.

    Cordialement

Discussions similaires

  1. Programme Arduino de commande de moteur+encodeur.
    Par loquet38 dans le forum Arduino
    Réponses: 7
    Dernier message: 15/03/2018, 21h20
  2. Commander un moteur (virtuellement)
    Par soft001 dans le forum LabVIEW
    Réponses: 0
    Dernier message: 12/04/2012, 11h06
  3. Commander un Moteur Electrique via une Interface Web
    Par felops dans le forum Entrée/Sortie
    Réponses: 4
    Dernier message: 05/03/2008, 15h00
  4. Installation d'un module en ligne de commande sur moteur 9i
    Par Arakil dans le forum Installation
    Réponses: 0
    Dernier message: 10/09/2007, 13h47
  5. Commander plusieurs moteurs par un seul port USB
    Par wolfjeremy dans le forum Windows
    Réponses: 6
    Dernier message: 11/06/2006, 15h52

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo