Openvario Xcsoar Arduino

[Jean-Paul BERRY]

Bonjour,

En 2015 je me suis intéressé à OpenVario, j'ai approvisionné les composants y compris les circuits imprimés CMS.

Cet hiver, réflexion faite, j'ai préféré utiliser directement trois senseurs (AMS5915,MS5611,DHT12) et un Arduino (Nano) pour envoyer la vitesse air, la pression, la température, l'hygrométrie via BlueTooth (HC05) dans des trames (protocole Vega) à XCSOAR. Le logiciel que j'ai développé implémente les équations de Bernouilli (pitot), de Magnus (densité de l'air humide), un filtre de Kalman pour l'altitude (vario) et conclue les trames par CRC. Les tests au sol avec XCSOAR sont conclants et il me tarde de voir la mesure du vent en transition... Si ce soft intéresse quelqu'un, je l'enverrai bien volontier...

 

JPB

Modifié le 17 février 2016 par Jean-Paul BERRY

[Adrien]

Bonjour,

Intéressant en effet ! Le mettrais-tu sur github ?

Les pressions sont prisent en T sur les durites du planeur?

[Jean-Paul BERRY]

Bonjour,

Intéressant en effet ! Le mettrais-tu sur github ?

Les pressions sont prisent en T sur les durites du planeur?

Le capteur AMS5915 a deux tubes d'entrée comme nos "Badins": les pressions peuvent-être prises en T.

Le soft est sur ma DopBox:

 

https://www.dropbox.com/s/atqa8wkkuixr02x/Vega2.txt?dl=0

Modifié le 17 février 2016 par Jean-Paul BERRY

[rimaroc]

c'est le code à utiliser dans EDI arduino et pas du C si je ne me trompe pas.

[Jean-Paul BERRY]

J'ai cherché à simplifier mon projet "Openvario perso" avec Arduino et le code tourne dans son EDI mais c'est du C!

Il y a des perfectionnements à apporter à ma maquette, par exemple coller un petit tube sur le capteur de pression statique (MS5611) pour l'alimenter par la pression extérieure. Quant au soft, on pourrait retrancher la pression dynamique de la pression statique pour obtenir une compensation du vario. mais dans l'immédiat ce qui m'intéresse c'est surtout le vent en transition.

[rimaroc]

je ne connais pas le format pour alimenter xcsoar en info mais en séparant mieux la partie calcul de la partie envois sur le port serie, on pourrais facilement adapter le truc à d'autres format, le pense à lk8000. Voir même mettre les deux formats et sélectionner via un cavalier (il reste un bon paquet de pin dispo).

 

J'avais fait un truc dans le style mais qui s’interfaçait entre le flarm et le pda. Il récupérai le pression baro du flarm, récupérait la Ptot via un BMP085 (de mêmoire) et renvoyait vers le pda toutes les info du flarm + la vitesse air affichée et/ou réelle. on pouvait facilement rajouter toutes sortes de capteur comme toi.

 

ça marchait bien sur mon établi mais je n'ai jamais eu l'occasion de le tester en réel.

 

Javais fait tout ça sur mon ancien pc qui a rendu l’âme et je n'ai pas encore eu le courage le sortir le DD. je peux retrouver tout ça si besoin.

 

Romaric

[rimaroc]

Pour les amateurs j'ai retrouvé ça.

C'était pas la version définitive il me semble et c'est pas forcement très propre mais ça marche :-)

 

#include <Wire.h>
#include <Adafruit_BMP085.h>
/* deuxième sketch pour IAS pour LK8000 dans une forme plus rigoureuse*/
//int ptot=1013; //à supprimer quand BMP085 dispo;
Adafruit_BMP085 bmp;
void setup(){
Serial.begin (57600);
bmp.begin();
}

void loop(){
Serial.println("loop");

while (Serial.peek()!='$'){
if (Serial.available()<1){
continue;
}
Serial.print(char(Serial.read())); //penser à enlever le LN!
}
char nmea[83]={'$'};
get_nmea(nmea); //entre toute la trame dans la chaine nmea
if (get_entete(nmea)==true){ //si l'entete est celle qui donne la p_stat
Serial.println("if_loop true");
Serial.print("ptot "); Serial.print(bmp.readPressure()/100);Serial.println("hpa");
int ias=10*sqrt((2*((bmp.readPressure()/100) - get_pstat(nmea)))/1.225);
//calcul de l'IAS
Serial.print("IAS caculé est de: "); Serial.print(ias);Serial.println("dm/s");//penser à enlever le LN!
envoie_trame_ias(ias);

}else {
Serial.print("if loop false");
// Serial.print(nmea);
}
}

void get_nmea(char nmea[]){
// Serial.println("get_nmea");
for (int i=0; i<83; i++){
while (Serial.available()<1); // attente de 1 caractères dispo dans le buffer
nmea=Serial.read(); //replissage de la chaine nmea avec les caratcères dispo
if (nmea==10){ //si le caractère est <LF> on arrête de remplir
// Serial.print("caractere LF trouvé");
break; // et on quitte la boucle
}
}
Serial.println(nmea); // on renvoie la trame sur la sortie serie //penser à enlever le LN!
return;

}
boolean get_entete(char nmea[]){
// Serial.print(nmea);
char entete_alti[8]="$PGRMZ,";
for (int i=0;i<6;i++){
if(entete_alti!=nmea){
// Serial.print("condition fausse");
return false;
}
}
return true;
}

int get_pstat(char nmea[]){
char char_pstat[7]={'\0'};
int pstat;
for (int i=7 ; nmea!=',' ; i++){
char_pstat[i-7]=nmea;
}
// Serial.print(char_pstat);Serial.println("pieds");
pstat= atoi(char_pstat);
// Serial.print(pstat);Serial.println("pieds");
pstat=1013.25 * pow((288-(0.0065*pstat*0.3028))/288,5.255); //formule de conversion pieds en hpa
// Serial.print("pstat "); Serial.print(pstat); Serial.println("hPa");
return pstat;
}

void envoie_trame_ias(int ias){
// Serial.println("envoie trame ias");
char char_ias[4]={'\0'};
char char_nmea_ias[15]="$PLKAS,";
int n;
itoa (ias,char_ias,10);
// Serial.print("char_ias: "); Serial.println(char_ias);

for (int i=7; char_ias[i-7]!='\0';i++){
char_nmea_ias=char_ias[i-7];
n=i;
// Serial.print("i= "); Serial.println(i);
}
char_nmea_ias[n+1]=',';
/* char XOR=0;
for (int i=0; char_nmea_ias!='\0';i++){
XOR^=char_nmea_ias;
}*/
char_nmea_ias[n+2]=get_XOR(char_nmea_ias);
char_nmea_ias[n+3]=13;
char_nmea_ias[n+4]=10;
Serial.print (char_nmea_ias);
return;
}

char get_XOR(char trame[]){
// Serial.println("get_XOR");
char XOR='\0';
for (int i=0; trame!='\0';i++){
XOR^=trame;
}
return XOR;
}

[Jean-Paul BERRY]

Pour mesurer précisément une vitesse air, on a besoin d'un capteur différentiel unidirectionnel dans la gamme de pression dynamique 0-50mb (AMS5915).

Quant à l'altimétrie avec une résolution de 10cm, on a besoin d'un capteur de pression à conversion 24 bits (MS5611-01) et de réduire le bruit par filtrage de Kalman.

Je doute des résultats de ta manip avec BMP085, remplacé par BMP180 mais encore pas assez précis et pour pitot et alti-vario...

Je suis en train de créer un "fork" dans GitHub ou nous pourrions nous retrouver.

Enfin sachez que j'ai été bien inspiré par les parapentistes, modèlistes et autres "dronistes".

Le cout de ma manip n'excède pas 100 Euros, désolé pour les pros de l'instrumentation planeur.

[Jean-Paul BERRY]

 

 

 

Intéressant en effet ! Le mettrais-tu sur github ?

 

 

 

https://github.com/JPBLX/OpenVario-XCSOAR-Arduino

 

Les deux trames envoyées par BT à XCSOAR sont au protocole Vega $PDVDV et $PDVVT

Modifié le 18 février 2016 par Jean-Paul BERRY

[Godzilla]

Vivement la retraite !

 

Ces capteurs sont magnifiques et ils ne coutent rien.

 

Plus qu'à rajouter quelques accéléros et autres gyros et ça fait un vario terrible !

 

Jean Paul, je suppose qu'à l'arrivée XCSOAR tempère les données "vent" par un savant calcul à partir des données GPS.

Si j'ai bien compris, il est aussi capable d'utiliser une valeur "vent" issue d'un instrument externe. c'est ton objectif final ?

Modifié le 18 février 2016 par Godzilla

[Adrien]

Par curiosité (et non par critique), est-il bien réglementaire de couper un durite pour y mettre un capteur de pression ?

 

Merci pour la dépose sur github.

[Jean-Paul BERRY]

Par curiosité (et non par critique), est-il bien réglementaire de couper un durite pour y mettre un capteur de pression ?

 

Merci pour la dépose sur github.

 

"Ach so" cela fait des décennies que les dites durites sont coupées pontées, sinon redistribuées dans nombre de planeurs pour alimenter calculateurs et autre, ne serait que la statique de XPDR. Alors me direz-vous le XPDR est réglementaire et se porte mieux avec la statique externe qu'interne. Mais les calculateurs, le Zander SR940 dans mon Ventus, sont-ils autorisés à inter-connexion hydraulique?

 

OK Adrien, il est bien connu qu'une LNMA est nécessaire pour déposer un anémomètre si c'est là que tu veux en venir. En ce qui me concerne, j'ai cette LNMA mais à terme je remplace mon SR940+GP940 sans même couper des durites, je gagne des centaines de grammes et de mA! Qui serait "administrativement" contre?

Modifié le 18 février 2016 par Jean-Paul BERRY

[Neulat 31]

Bonjour J-P

 

il y avait aussi un post sur http://www.parapentiste.info/forum/bons-plans/variometre-maison-a-base-darduino-t33538.125.html

mais ils n'avaient pas fait les mêmes choix (BMP 180 qui semble moins précis) + il n'est pas question non plus de filtre de Kalman pour le filtrage du bruit sur l'altitude. Peux-tu développer ce point ?

[Jean-Paul BERRY]

Bonjour Neulat 31,

 

 

 

https://fr.wikipedia.org/wiki/Filtre_de_Kalman

 

et son implémentation en librairie Arduino:

 

https://www.dropbox.com/sh/tw29a4awwoffrus/AADtSGKBQ63f-4kOPTnoCe-ma?dl=0

 

après une période d'initialisation-mémorisation (et ça demande un peu de mémoire) le filtre numérique ne retient que les "tirs groupés" dans le bruit "Gaussien"...

[Robert Ehrlich]

Pour les amateurs j'ai retrouvé ça.

C'était pas la version définitive il me semble et c'est pas forcement très propre mais ça marche :-)

dans la ligne suivante :

 

pstat=1013.25 * pow((288-(0.0065*pstat*0.3028))/288,5.255); //formule de conversion pieds en hpa

 

la valeur du pied en mètres est prise à 0.3028 alors que c'est 0.3048, erreur mineure, mais ça n'a pas de sens de mettre 4 chiffes significatifs si le 3ème est faux.

[rimaroc]

merci pour l'erreur, j'avoue que je ne sais plus si j'ai mal recopié ou trouvé une source erronée.

et pour le reste? :-D

 

si vraiment vous êtes sympa et que vous les ouhaitez je retrouve le sketch "finalisé" (erreur de conversion de ft/m comprise)

 

Romaric

Modifié le 23 février 2016 par rimaroc

[Robert Ehrlich]

Intéressant en effet ! Le mettrais-tu sur github ?

 

https://github.com/JPBLX/OpenVario-XCSOAR-Arduino

J'ai jeté un coup d'oeil sur ce code, ce qui m'a inspiré les quelques réflexions qui suivent, concernant la façon dont est obtenue la Vz

 

En fait elle est tout simplement la différence des 2 dernières altitudes, supposées être obtenues à 1 seconde d'intervalle, ce dont semble témoigner le delay(1000) en fin de boucle, qui si je ne m'abuse néglige le temps de calcul et de transmission.

 

L'altitude elle-même est obtenue par appel à une méthode externe :

//Altitude en m
	float a = ms5611.getAltitude(p); 

qui convertit la pression en altitude (le ms5611 ne fournissant que la pression), en considérant je suppose que la relation entre les deux est celle de l'atmosphère standard, ce qui semble confirmé par le code de cette méthode que je crois avoir trouvé ici :

    float getAltitude(int presssure = 0) {
        return toAltitude(presssure ? presssure : (int) getPressure());
    }
 
float toAltitude(int pressure) {
        // Ref. 29124-AltimeterAppNote1.pdf
        const float R = 287.052; // specific gas constant R*/M0
        const float g = 9.80665; // standard gravity 
        const float t_grad = 0.0065; // gradient of temperature
        const float t0 = 273.15 + 15; // temperature at 0 altitude
        const float p0 = 101325; // pressure at 0 altitude
 
        return t0 / t_grad * (1 - exp((t_grad * R / g) * log(pressure / p0)));
    }

Or les conditions dans lesquelles nous volons, en tout cas en plaine, ne sont pratiquement jamais celle de l'atmosphère standard. La température à l'altitude zéro est quasiment toujours supérieure à 15°, la pression à cette altitude presque toujours supérieure à 1013,25 hPa et surtout, dès que nous volons en thermique et hors des nuages, la décroissance de température n'est pas de 6,5 ° par 1000 m mais de 10 ° par 1000 m (adiabatique sèche) sauf tout près du sol où elle est légèrement supérieure (sur-adiabatisme). Il ne s'agit pas d'erreurs aléatoires dont on pourrait penser qu'elles se compensent plus ou moins, mais d'erreurs systématiques dues à un écart entre un modèle arbitraire de la réalité et cette réalité même.

 

Le calcul de l'altitude compte tenu de cet écart pourrait être fait, en modifiant ce modèle, exactement de la même façon que pour l'atmosphère standard en prenant en compte le gradient vertical de température réel, mis il nécessiterait de connaître pression et température à une altitude de référence, si possible au dessus de la couche sur-adiabatique.

 

Fort heureusement on n'a pas besoin de ce calcul pour calculer la Vz. En effet la formule utilisée dans ce calcul résulte de l'intégration de l'équation différentielle qui exprime l'équilibre "hydrostatique" (poids d'une tranche = poussée d'Archimède) :

dp = -rho*g*dz

Il suffit d'utiliser directement cette relation en l'inversant :

dz = -dp/(rho*g)

et de confondre différentielles et différence finies entre deux mesures, en prenant pour rho la moyenne des deux dernière valeurs calculées. Dans cette hypothèse c'est probablement la pression qu'il faudra filtrer.

 

Par ailleurs je m'interroge sur l'utilisation de la même méthode Serial.print aussi bien pour envoyer des données à XCSoar que pour afficher des messages d'erreur ou d'information destinés au pilote/programmeur, il doit y avoir là une subtilité de XCSoar ou de C++ qui m'échappe, je ne suis que fort peu familier avec ce langage.

Modifié le 23 février 2016 par Robert Ehrlich

[Jean-Paul BERRY]

Le but de cette interface, c'est:

 

1/ la mesure de la vitesse air, de la température de l'humidité pour le ratio de densité , afin d'obtenir la TAS et le vent en transition.

 

2/ l'obtention une sensibilité du vario de l'ordre de 0,1m/s.

 

Ce n'est pas un altimètre de précision.

 

D'autres informations (GPS) sont traitées dans XCSOAR ...

[Robert Ehrlich]

Le but de cette interface, c'est:

 

1/ la mesure de la vitesse air, de la température de l'humidité pour le ratio de densité , afin d'obtenir la TAS et le vent en transition.

 

2/ l'obtention une sensibilité du vario de l'ordre de 0,1m/s.

 

Ce n'est pas un altimètre de précision.

 

D'autres informations (GPS) sont traitées dans XCSOAR ...

C'est bien ce que j'avais compris. Mais un vario qui calcule la Vz par différence d'altitudes entachées d'erreurs sera entaché des mêmes erreurs. Certaines vont s'éliminer dans la différence, d'autres non. Du point de vue du résultat du calcul, à partir de l'altitude déduite de la pression en atmosphère standard, on obtient le même résultat qu'on obtiendrait par la méthode que je suggère en utilisant comme densité de l'air rho celle qu'aurait l'atmosphère standard pour cette pression au lieu de celle qu'on connait pour l'avoir calculée avec le maximum de précision en vue d'obtenir la TAS.

[Robert Ehrlich]

merci pour l'erreur, j'avoue que je ne sais plus si j'ai mal recopié ou trouvé une source erronée.

et pour le reste? :-D

Pour le reste il faut que je regarde de plus près. L'affichage dans le forum en italique avec couleurs a des effets bizarres au moins avec mon navigateur : les deux derniers nmea de la fonction get_pstat ont perdu leur à l'affichage bien qu'il soit toujours présent dans le texte source. Il vaut toujours mieux mettre tout ce qui est programme en police à espacement constant, Courier New par exemple

si vraiment vous êtes sympa et que vous les souhaitez je retrouve le sketch "finalisé" (erreur de conversion de ft/m comprise)

Sur le fait d'être sympa je me garderai bien de porter un jugement de cet ordre sur moi-même qui ne saurait être objectif

Pour ce qui est de la recherche de ce sketch est-ce que ça en vaut la peine ? La encore ce n'est pas moi qui peut en juger.

A part ça il m'a toujours semblé qu'entre vélivoles et en particulier sur ce forum, on se tutoie.

[Jean-Paul BERRY]

.Mais un vario qui calcule la Vz par différence d'altitudes entachées d'erreurs sera entaché des mêmes erreurs. Certaines vont s'éliminer dans la différence, d'autres non.

D'ou l'usage d'un filtre de Kalman.

Mais en planeur ne s'intéresse-t-on pas surtout à la tendance d'une mesure vario plus ou moins intégrée qu'à une valeur précise dans l'absolu, d'autant qu'en spirale ça fluctue?

 

La question du recalage altimétrique est abordée de facon exhaustive dans cette thèse:

 

https://www.dropbox.com/s/9y2e2ga05w0p8fs/document.pdf?dl=0

 

Il est nécessaire d'hybrider les mesures, pression, inertielles, GPS. Or avec notre smartphone, le flarm et quelques petits modules à qq Euros, nous pouvons disposer de ces mesures...de quoi s'occuper à la retraite!

[Jean-Paul BERRY]

Enregistrement du vario sans filtre (rouge) et avec deux sortes de filtre de Kalman (vert).

 

https://www.dropbox.com/sh/1fao8s871wsr1aw/AAA-tQQ2MLoZMNcvJWY0YbF0a?dl=0

 

Le premier est plus efficace mais s'initialise en plus de 10s.

[Adrien]

As-tu testé, pour comparer, un passe-bas du premier ordre avec une seconde de constante de temps sur ta mesure?

D'autre part il me semble qu'il faut fixer une variance estimée au début de ton algo, et non ajouter un bruit aléatoirement à chaque pas de temps.

Un exemple avec deux états : KalmanFilter1d

[Robert Ehrlich]

 

Mais un vario qui calcule la Vz par différence d'altitudes entachées d'erreurs sera entaché des mêmes erreurs. Certaines vont s'éliminer dans la différence, d'autres non.

D'ou l'usage d'un filtre de Kalman.

Je parlais des erreurs systématiques dues à ce que l'atmosphère n'est en général pas l'atmosphère standard, contre celles-là aucun filtre ne peut rien. Ce qui va s'éliminer dans la soustraction, c'est l'erreur de calage due à ce qu'en général la pression au niveau de la mer est supérieure au standard.

Il me semble curieux de filtrer l'altitude, qui n'est qu'un résultat de calcul fonction de la pression uniquement, et pas cette pression elle-même qui est forcément aussi bruitée que l'altitude qu'on en déduit, et qui sert pour le calcul de TAS, dont le résultat devrait refléter ce bruit.

[Jean-Paul BERRY]

OK Robert tu t'intéresses à l'atmosphère...atmosphère, est-ce que j'ai une gueule d'atmosphère? non car je m'intéresse au bruit du capteur. que l'on filtre l'altitude ou la pression qui se trouve dans son calcul, je ne vois pas la pénalité.

 

Le tracé de la Vz avec Scilab (INRIA) me montre que le filtre de Kalman diminue ce bruit d'un facteur 3 en-dessous de 0,1m/s.

 

Adrien parle d'une autre solution de filtrage passe-bas du premier ordre. Je crois me souvenir que l'on doit distinguer le temps continu et le temps discret.

 

Dore et déjà, la maquette en photo:

 

https://www.dropbox.com/sh/aqxyw2toi6do4xc/AADKUmtsdxihJ6tLOkUGobT7a?dl=0

 

est embarquée dans mon planeur et vivement les Cumulus!...

Modifié le 27 février 2016 par Jean-Paul BERRY