Méthode de moyenne vectorielle pour mesurer la direction du vent

Il y a un an, j'ai décrit une station météo avec un instrument de mesure pour la direction et la vitesse du vent. Sur la base de l'expérience de deux saisons d'exploitation, certains changements et améliorations y ont été apportés, qui y sont partiellement décrits dans des ajouts au texte principal.

L'un de ces changements concerne le calcul de la direction moyenne du vent. À ma grande surprise, je n'ai rien trouvé de raisonnable sur ce sujet sur le Web, seulement sur l'un des forums les gens eux-mêmes ont presque pensé à la méthode de la moyenne vectorielle (mais seulement presque, ils n'ont pas résolu le problème en termes généraux). Par conséquent, j'ai trouvé utile de mettre ce sujet dans une publication séparée - tout à coup, quelqu'un d'autre vous sera utile. La méthode peut être utilisée pour faire la moyenne de n'importe quelle quantité de vecteur, pas seulement le vent ou le courant.

Notez que la méthode canonique pour effectuer des mesures météorologiques du vent est la suivante: faire la moyenne du vecteur (c'est-à-dire à la fois la vitesse et la direction) sur 10 minutes (en Russie et dans la plupart des pays du monde, il est accepté de cette façon, disent-ils, aux États-Unis et dans certains autres pays différemment). Dans ce cas, les mesures sont prises à une hauteur de 10 m de la surface de la Terre. Assurer tout cela dans des conditions de genou est assez difficile: on ne peut pas atteindre une hauteur de 10 m dans un espace ouvert (ne pas construire de tour spéciale, loin des maisons et des arbres qui faussent le vent), et la température avec l'humidité doit, au contraire, être mesurée à l'ombre et à proximité de la surface. Le capteur portable est transformé d'un appareil compact en un système de mesure complet (voir photo du territoire d'une station météo de la ville de Kirov).



Et le résultat - en moyenne 10 minutes - sera peu informatif. Près de la surface, le vent est beaucoup plus en rafales qu'en altitude, en 10 minutes, il peut changer de vitesse et de direction vingt fois, et les informations sur ces rafales sont beaucoup plus informatives pour la personne moyenne que la valeur moyenne. Permettez-moi de vous rappeler que le capteur de vitesse montre ici la valeur maximale de quatre mesures par cycle de 8 s, et cela s'est avéré être le bon choix (en fait, nous avons obtenu un capteur d'ondulation au lieu du capteur de vitesse moyenne).

Mais la girouette s'est avérée plus morose que le capteur de vitesse. Selon l'algorithme initial de ma station météorologique (qui a été sélectionné en fonction de l'économie d'énergie maximale possible), la direction a été mesurée une fois par cycle, c'est-à-dire que même les pulsations n'ont pas fonctionné: il y avait des échantillons aléatoires du processus continu de suspension de la girouette d'avant en arrière avec une fréquence beaucoup plus grande qu'une fois tous les 8 et plus de 16 secondes.

Par conséquent, il a été décidé de faire la moyenne de la direction du vecteur vitesse par cycle, en prenant des mesures toutes les deux secondes et en calculant la moyenne. Et le problème n'est pas qu'il puisse être résolu avec un demi-coup de pied - les valeurs de direction ne forment pas un tableau pair de nombres qui peuvent être directement ajoutés et divisés (un mot est un vecteur, pas un scalaire de conneries). Habituellement, un exemple est donné avec des valeurs de 1 degré et 359 degrés: il est facile de comprendre qu'en moyenne ce sera exactement 360 (ou 0, pas de différence), mais l'arithmétique ordinaire donnera le nombre 180 degrés.

Inutile d'inventer quoi que ce soit - tout a déjà été inventé avant vous. Le problème est résolu par la méthode de la moyenne vectorielle, bien connue de ceux qui ont traité des mesures de vents ou de courants. La méthode est essentiellement très simple: comme nous ne pouvons pas faire la moyenne directe des angles, alors faisons la moyenne des projections du vecteur sur l'axe des coordonnées, qui, par définition, est une valeur scalaire, c'est-à-dire peut être soumise à une arithmétique ordinaire sans question.

Les projections du vecteur vent actuel W '(l'apostrophe joue le rôle d'un exposant) sur les axes X et Y sont wx = Wa • cos (α) et wy = Wa • sin (α), où Wa est le module du vecteur (valeur de vitesse), et α - la valeur de l'angle entre le vecteur et l'axe des coordonnées nulles. Si nous faisons la moyenne de ces valeurs des projections, puis reconvertissons les moyennes en un vecteur, alors nous obtenons la vraie valeur de la vitesse et de la direction moyennes du vent.


Cette merveilleuse méthode (appelons-la moyennage vectoriel complet) a un inconvénient cardinal d'un point de vue pratique: en l'absence d'un sujet de mesure (c'est-à-dire lorsqu'elle est complètement calme, ce qui est un cas assez courant), elle donne un résultat mathématiquement incorrect: puisque la vitesse du vent est nulle, alors et les deux projections sont égales à zéro, ce qui ne peut pas l'être (puisque sin et cos sont des fonctions complémentaires). Plus précisément, c'est possible, mais il est fondamentalement impossible d'extraire des informations d'une telle situation. Que voulez-vous montrer à l'écran? Pour être honnête, je ne connais toujours pas la bonne façon de contourner cette situation (dans les débitmètres que j'ai conçus, les cycles de calcul de la moyenne étaient des heures, et on pensait qu'au moins une certaine agitation se produirait).

Mais dans notre cas, la tâche, heureusement, est plus facile - nous n'avons pas besoin de faire la moyenne de la vitesse, et nous pouvons le faire avec des projections uniques du vecteur, sans prendre en compte l'ampleur de son module. En d'autres termes, on peut fonctionner avec des sinus et cosinus purs, qui ne prennent jamais zéro à la fois: même quand il n'y a pas de vent, une girouette gelée dans l'immobilier montre une certaine direction. Nous appelons une telle méthode un vecteur simplifié faisant la moyenne d'une direction (peut-être qu'elle a un nom officiel, mais je ne suis pas au courant).

Il n'y avait plus qu'une seule difficulté: reconvertir les valeurs de projection moyennes calculées en valeur d'angle. Pour cela, la fonction α = arctan (sin (α) / cos (α)) est généralement utilisée, mais si nous calculons à travers les fonctions trigonométriques inverses, alors il est plus simple de prendre simplement arcos (cos (α)) (ou arcsin (sin (α)), de toute façon), et pour compléter ce résultat pour obtenir un cercle complet (c'est-à-dire de 0 à 359 degrés), en analysant les signes des projections, il faut quand même le faire: toutes les fonctions inverses donnent le résultat dans un demi-cercle (de 0 à 180 ou de -90 à +90). (Voir UPD à ce sujet à la fin de l'article.)

Nous formalisons tout ce qui précède en un véritable algorithme (en référence à Arduino). Pour commencer, nous lirons les indications de direction non pas à chaque cycle, mais à chaque mesure (après la valeur de la fréquence de l'anémomètre). Nous convertirons le résultat en code Gray (dans notre pays, il a été désigné comme wind_Gray de type octet, voir cette publication ) en un code binaire normal, et, comme la fréquence de l'anémomètre, nous le placerons dans un tableau global, que nous déclarerons wDirAvr [4], où 4 est le nombre de mesures dans le cycle. Nous ne peindrons pas la conversion du code Gray à quatre chiffres en code binaire - cela peut être fait de plusieurs manières à la discrétion du programmeur et est décrit dans toute référence.

Ce code binaire prendra des valeurs de 0 à 15, et nous convenons de compter les angles, non pas comme des géographes / topographes / navigateurs décalés, mais comme des gens normaux qui ont étudié la trigonométrie à l'école - dans le sens antihoraire. Autrement dit, si le nord correspond à la valeur zéro, alors 90 degrés ne sont pas l'est, comme dans les «décalés», mais l'ouest. Comme nous avons 16 gradations de direction, nous devons multiplier la valeur de code par 22,5 (360/16) pour obtenir la direction en degrés ordinaires de l'arc.

Maintenant, l'algorithme réel de moyenne vectorielle simplifiée de la direction à partir de 4 valeurs de code:

. . . . . float wSin=0; // sin float wCos=0; // cos float wind_Rad; //   for (byte i=0; i<4; i++){ wind_Rad= ((float(wDirAvr[i])*22.5)*M_PI/180); //   wSin=wSin+sin(wind_Rad);//    sin wCos=wCos+cos(wind_Rad);//    cos } // wSin=wSin/4;// sin –    ,   wCos=wCos/4; // cos wind_Rad = acos(wCos); //     arccos if (wSin<0) wind_Rad=2*M_PI-wind_Rad; //   sin int wind_G = round ((wind_Rad*180/M_PI)/22.5); //    0-15 . . . . . 

La dernière ligne, nous convertissons la moyenne, exprimée en radians, en moyenne, exprimée dans notre code de 0 à 15. Vous pouvez ensuite la reconvertir en code Gray, puis vous n'avez même pas besoin de changer le programme dans le module principal pour afficher la direction.

Voici, en fait, tout l'algorithme. J'avais peur que le calcul des cosinus-arcsines ralentisse le contrôleur Arduino faible (par les temps 32 bits d'aujourd'hui), mais rien ne s'est passé: il a avalé le code sans même clignoter ... une LED, probablement.

UPD : Pour l'auteur, l'algorithme fonctionne sous cette forme pendant plusieurs mois sans échecs. Cependant, les commentateurs m'ont conduit à une erreur possible, quoique extrêmement improbable dans la pratique: si les données contiennent deux groupes de mesures qui sont à environ 180 degrés l'un de l'autre près de la valeur de cosinus zéro (c'est-à-dire environ 90 et 270 degrés), alors l'algorithme produira une erreur valeur. Pour l'éviter, au lieu d'acos (), utilisez la fonction atan2 (wSin, wCos), qui donne immédiatement le résultat correct en tenant compte des signes sinus et cosinus (merci aamonster pour l'aide). La ligne où la valeur moyenne de wSin est calculée ne doit pas être commentée et la ligne ajustée pour le signe wSin n'est pas nécessaire. Au lieu de cela, vous devez insérer le cast à des valeurs positives de l'angle (car atan2 donne des valeurs de pi à -pi):

 if (wind_Rad<0) wind_Rad=2*M_PI+wind_Rad;