Ground Station : un programme très sympathique = Serial Studio

Bonsoir,

Yohan (R2HOME) m'a indiqué un programme très sympa qui permet de créer facilement un tableau de bord de données à partir de trames reçues sur le port série (COM).
Le Github de ce projet

Je continue de découvrir ce petit logiciel. Il faut faire attention à la vitesse de transmission des trames sous peine de faire planter le logiciel (j'ignore la fréquence maximum mais à 9600 bauds, ça plante à 100Hz, ça ne plante pas à 20Hz).

Un truc très pratique : quand on envoie des données GPS, on peut faire apparaitre la carte avec la position.

Au delà du port COM, les données peuvent être reçues à  partir du protocole TCP et aussi MQTT.

Les données récoltées sont enregistrées dans un fichier csv.

Un exemple de ce que l'on obtient en moins de deux minutes : récupération de de coordonnées GPS d'une puce U blox Neo 7M et affichage des données en temps réel

Excellent
Tu peux nous mettre un lien

Salut Antoine,

Merci pour l'info.

Le widget 'Gyro' n'a pas l'air de fonctionner correctement.
A partir d'un composant donnant les accelerations, angles d'Euler, etc. on doit pouvoir récupérer le positionnement absolu de système. En réalité, le graphisme de ce widget tourne mais sans respecter les 3 angles (Yaw, pitch, roll). Cette application est pas mal, elle est encore en développement (j'ai ouvert une issue sur le plantage qui semble provenir d'un overflow sur le port série).
Le programme que j'avais commencé l'année dernière en python n'est pas aussi avancé.

C'est sympa
Nos rencontres vont être digne d'un CSG !

Antoine a écrit:Le widget 'Gyro' n'a pas l'air de fonctionner correctement.
A partir d'un composant donnant les accelerations, angles d'Euler, etc. on doit pouvoir récupérer le positionnement absolu de système. En réalité, le graphisme de ce widget tourne mais sans respecter les 3 angles (Yaw, pitch, roll). Cette application est pas mal, elle est encore en développement (j'ai ouvert une issue sur le plantage qui semble provenir d'un overflow sur le port série).
Le programme que j'avais commencé l'année dernière en python n'est pas aussi avancé.

C'est pas evident à faire car il faut initialiser la position.
Si c'est codé en utilisant des quaternions (nombres complexe avec une partie réélle et 3 parties imaginaires). Pour ceux qui se souviennent de leurs cours de maths on peut representer un angle avec un nombre complexe donc si on a 3 angles c'est un nombre complexe avec 3 parties imaginaires
Il faut de mémoire mutipler le complexe par son conjugué pour initialiser la position... c'est comme ça que je fais pour mon alti Gimbal

Il est vraiment pas mal ce logiciel.

tu dois coder pour avoir ça ou c'est juste du parametrage?

ce n'est pas du code : une fois que la trame de données est établie et arrive sur le port COM, il suffit de choisir parmi des widgets le format de sortie (graphique, gps, gyro, graphique, boussole, etc.).

Ah oui, ça a de le gueule ce truc

Antoine a écrit:

Je continue de découvrir ce petit logiciel. Il faut faire attention à la vitesse de transmission des trames sous peine de faire planter le logiciel (j'ignore la fréquence maximum mais à 9600 bauds, ça plante à 100Hz, ça ne plante pas à 20Hz).

Au delà du port COM, les données peuvent être reçues à  partir du protocole TCP et aussi MQTT.

Bonjour

Très bien la découverte. Continue de le découvrir. Il servira et donnera une impression de pro
Ne pas confondre la vitesse de transmission des octets (en bauds) avec le nombre de messages (ou nombre d'octets) reçus par seconde
(ici 100 20 Hz que j'interprète comme 100 messages par seconde ou 20 messages par seconde

En fait il faut laisser le temps au P C d'analyser chaque trame reçue, de faire les calculs et enfin de faire apparaître les résultats dans les
afficheurs et cadrans de l'interface graphique

les modes TCP MQTT sont très utiles mais je pense que seul le mode port COM sera le seul utilisé
oui les octets sont transmis en Hertzien, reçus puis retransmis au P C en mode série

Pour ma part, quand cela se fera pour moi, je rajouterais (j'inclurais) l'étape (ou la case) enregistrement
Les analyses et affichages se feront par la suite en différé. Le court temps du vol le permet
Je me souviens d'un projet nomme 'Nemesis' dans mon club d'Arras
(transmission F S K avec c i decodage xr2211 suivi d'un enregistrement pur octet dans une disquette)

Bien sûr, durant le décollage et le vol de la véritable fusée Ariane, il faut analyser et afficher à l'instant même

Patrick, tu verras que les donnees recues sont stockées dans un fichier .csv

Bonsoir

Très bien, ma lointaine expérience de télémesures m'a fait retenir qu'il faut une copie
que l'on examine plus profondément après par la suite

Pour 'Nemesis' en l'an 2000, je m'étais servi d'un PC 486 récupéré mais fonctionnant bien
avec DOS et avec un EXE fait à partir d'un programme C compilé (dont j'avais écrit le source)
Il enregistrait en fait à partir des deux ports COM, en destination d'un fichier binaire
examiné par la suite
Les deux car il y avait le récepteur VHF du CNES et le mien (construit à partir d'un kit réception bande FM)
Ils se sont en fait complémentés
Il y a eu quand même des trames bruitées

Il faudra que je saches (et vois) vos modulations en Hertzien
Est ce FSK MP MAQ OFDM (modulation F2F, modulation de phase, multiporteuses) ?
Il y aura je pense des trames incomplètes. Ce sera à découvrir

J'ai fait du VISUAL BASIC, WINDEV, LABVIEW et des fois le S E WINDOWS veut faire à sa manière, ce qui
ralentit un peu les affichages dans l'interface graphique, mais sans gêner énormément

OUi le temps d'exécution élémentaire a diminué dans un ratio de x, mais concernant l'accès au disque
(inertie mécanique pour positionnement tête), les temps ont diminués de peu

Patrick je pense qu'avec la puissance des PC ou telephone que l'on a aujourd'hui nous pouvons nous permettre le 'luxe' d'avoir un affichage en temps réél avec de beau graphiques

Oui tout a fait

néammoins je conseille dans la barre de tâches tout en bas qu'il n'y ait que son logiciel qui tourne (tout seul)
afin qu'il ait le maximum de ressources disponibles (temps machine, mémoire)

Voici une utilisation de ce logiciel lors du MDR3 (dimanche, proto SEER-Lite). L'ordinateur de bord renvoyait les infos via un APC-220, réception au sol avec une antenne quart d'onde en 433Mhz.
Ca a très bien fait le job et en plus on peut "rejouer" le lancement à tête reposée. Il n'y avait pas de filtrage de Kalman sur le baromètre.

tu devrais essayé de recalculer la vitesse et l'acceleration puisque tu as l'altitude en fonction du temps

je l'ai fait. Accélération max 20g, ça reste approximatif à cause du manque de filtrage.

tu pourrai appliquer un filtre de Kalman après vol en essayant avec different coefficients pour un filtrage optimal

J'ai un peu de mal (surtout en vacances) à comprendre le fonctionnement des filtres de Kalman. J'ai refait un travail de lissage (moyenne étendue sur 3 ou 4 valeurs) : ça lisse bien l'altitude, mais il y a des irrégularités sur la vitesse (de manière de régulière, laissant penser à un problème sur le programme).
La prochaine fois, l'ordinateur embarquera un accéléromètre et ce sera plus simple.


Il y a un phénomène lors de la phase ascensionnelle. Ce n'est pas la première fois que je le remarque (vol de 2019 et de 2021 sur du SEE ancienne version). Il y a un "saut" : erreur dans la chaine de mesure ?

tu penses l'amener pour le frm pour de nouveaux tests?

philippehuguenin a écrit:tu penses l'amener pour le frm pour de nouveaux tests?

Je ne sais pas Philippe : je dois réfléchir à un nouvel ordinateur, le fabriquer, le tester... ça me parait juste.

Pour ma part la carte avec mes accelerometres devrait etre prete