Publicité
+ Répondre à la discussion
Affichage des résultats 1 à 4 sur 4
  1. #1
    Membre chevronné
    Homme Profil pro Jean-Charles
    Doctorant automatique
    Inscrit en
    janvier 2012
    Messages
    392
    Détails du profil
    Informations personnelles :
    Nom : Homme Jean-Charles
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Doctorant automatique
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : janvier 2012
    Messages : 392
    Points : 626
    Points
    626

    Par défaut [bode] Erreur de calcul dans bode Phase

    Bonjour,

    J'ai exactement le même problème que ce thread. Je le re-expose ici.

    Lors du tracé du diagramme de bode-phase de la fonction de transfert (s²+100)/(s²+121):

    Code :
    bode([1 0 100],[1 0 121])
    ...on obtient un signal avec une avance de phase de 180° entre 10 et 11 rad/s. Par contre sur le signal suivant (s² + 100)/(s^4+121s²):

    Code :
    bode([1 0 100],[1 0 121 0 0])
    ...on n'observe plus l'avance de phase, mais un retard à la place ! Alors qu'on devrait observer la même chose que le précédent signal, juste déphasé de 180° !

    J'ai l'impression que le déphasage est bien effectué aux basses et hautes fréquences... alors pourquoi le calcul serait-il différent aux fréquences intermédiaires ?

    Ce qui est inacceptable pour mon application... car même si le signal est défini à 2pi près, si je cherche une fréquence de coupure tel qu'on est une marge de phase par rapport -180° bien spécifique, selon la forme du signal, le résultat au final ne sera pas du tout le même... Ici c'est un cas simple, mais je travaille sur des modèles bien plus complexes, et je ne peux pas deviner à l'avance où est la véritable fréquence de coupure.

    Quelqu'un aurait-il une idée d'où vient cette aberration ? Je suis d'accord sur le fait que le déphasage est défini à 2*pi près... du moins mathématiquement... parce que physiquement, entre un signal déphasé de 0° et un autre déphasé de 360°, eh bien il y a un retard d'une période entre ces deux signaux... en clair, en commande, cela peut se traduire de la manière suivante : imaginons qu'on commande un ascenseur en position au cours du temps. Imaginons qu'on veuille que cet ascenseur fasse deux aller retour entre le rez-de-chaussée et le dernier étage... avec un déphasage de 0°, l'ascenseur suivra la commande instantanément... par contre avec 2pi, cela voudra dire par exemple que l'ascenseur ne démarrera que lorsqu'on aura déjà commencé à lui demander d'entamer son deuxième aller-retour... alors qu'il n'a même pas entamé le premier ! Si l'immeuble fait 300 étages, cela pourrait vouloir dire que l'ascenseur a 1/2 heure de retard... inacceptable bien évidemment...

    Je suis preneur de toute aide me permettant soit d'utiliser une autre fonction qui calcule correctement la phase, soit qui me permette d'apporter une correction qui soit juste.

    L'explication donnée sur le thread ne me convient pas : je suis sur un modèle d'un cas d'application concret qu'on retrouve dans la réalité... et ce cas intervient à plusieurs points de linéarisation de mon modèle (je dirais même sur une large bande d'application), pas un seul.

    [EDIT] Solution "provisoire" : je fais une étude fréquentielle de A à Z, mais j'ai peur que le calcul soit bien plus long qu'un simple bode. Je dois de toutes façons passer par là pour les calculs en non linéaire, mais j'aimerais tout de même avoir un calcul rapide mais restant un minimum "fiable" en linéaire, pour pouvoir effectuer des réglages "à la volée".

    [EDIT2] J'ai la version 7.1 de matlab... il semblerait que l'erreur aie été corrigée à partir de la version 7.3.

    Cordialement,

  2. #2
    Membre chevronné
    Homme Profil pro Jean-Charles
    Doctorant automatique
    Inscrit en
    janvier 2012
    Messages
    392
    Détails du profil
    Informations personnelles :
    Nom : Homme Jean-Charles
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Doctorant automatique
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : janvier 2012
    Messages : 392
    Points : 626
    Points
    626

    Par défaut

    Salut,

    Je me doute que ce que je demande est assez pointilleux.

    Je voudrais tout de même vous demander un service : pourriez-vous tester les deux codes ci-dessus chez vous et me dire si vous obtenez la même chose ? Pouvez-vous également me dire votre version de Matlab ?

    Cela pourra me permettre d'avoir une vue d'ensemble en fonction des différentes versions de matlab, et me donnera peut-être une indication sur une piste à suivre pour corriger l'erreur sur la version que j'ai.

    Merci d'avance.

  3. #3
    Invité régulier
    Homme Profil pro Brice Gauthier
    Inscrit en
    mai 2012
    Messages
    11
    Détails du profil
    Informations personnelles :
    Nom : Homme Brice Gauthier
    Localisation : France, Drôme (Rhône Alpes)

    Informations forums :
    Inscription : mai 2012
    Messages : 11
    Points : 5
    Points
    5

    Par défaut

    Salut,

    Je viens de tester.
    J'ai une phase de 0° partout sauf entre 10 et 11 rad où j'ai 180° pour le premier bode.
    Pour le second, j'ai -180° de partout sauf entre 10 et 11 rad où j'ai 0°.

    Donc si j'ai bien compris ce tu mentionnais, moi j'ai pas de bug ! J'ai la version R2011b.

  4. #4
    Membre chevronné
    Homme Profil pro Jean-Charles
    Doctorant automatique
    Inscrit en
    janvier 2012
    Messages
    392
    Détails du profil
    Informations personnelles :
    Nom : Homme Jean-Charles
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Doctorant automatique
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : janvier 2012
    Messages : 392
    Points : 626
    Points
    626

    Par défaut

    Salut,

    Tu as tout juste. Merci de ton aide.

    Ils ont donc corrigé l'erreur à partir d'une certaine version. Et j'aimerai bien savoir comment ils ont fait, parce que c'est vrai que mathématiquement, si on prend la définition pure et dure, les deux résultats sont justes... mais pas physiquement.

    J'invite d'autres personnes avec d'autres versions à tester si possible.

    Merci.

    Cordialement,
    Je ne réponds pas aux MP techniques. Le forum est là pour ça.
    La raison est simple : il est ennuyeux de répondre à une seule personne, alors que la réponse peut servir à tout le monde.
    Conclusion : n'hésitez pas à utiliser le forum pour poser vos questions.
    Matlab 2005 - ver.7.1.0.183 (R14) Service Pack 3

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •