IMA4 2016/2017 P27

Cahier des charges

Présentation générale du projet

Contexte

Afin d’acquérir des mesures sur plusieurs grandeurs physiques à haute altitude (20 000m-30 000m), le ballon atmosphérique fut largement utilisé dans la météorologie jusqu’à l’avènement de moyens plus modernes pour les prévisions météo, notamment avec la mise en orbite de satellites d’observation.

La demande croissante en objetsconnectés de ces dernières années a abouti au développement d’un réseau en capacité de répondre aux nouvelles exigences de ces systèmes. Le réseau LoRA (pour Low Range transmission network) permet la transmission de données à faible bande passante et de manière moins énergivore que d’autres moyens de communications.

Notre projet aura donc pour but de développer une sonde atmosphérique utilisant le réseau LoRa.

Description du système

Ce dispositif est composé d’une enveloppe contenant de l’hélium. Ce gaz étant plus léger que l’air ambiant, il exerce une force verticale qui fera monter une nacelle jusqu’à l’altitude d’éclatement de l’enveloppe. En effet, la pression diminuant avec l’altitude, le gaz emprisonné prend de plus en plus de volume et, à terme, fait éclater le ballon. S’en suit une chute libre ralentit par un parachute jusqu’à l’atterrissage au sol.

Composition de la nacelle

Le système embarqué est autonome et doit donc emporter la bonne quantité en énergie pour être alimenté pour toute la durée du vol. De plus, il doit pouvoir faire l’acquisition ainsi que la transmission des données.

Choix techniques : matériel et logiciel

• Electronique embarquée :

Notre nacelle transmettra à minima les relevées en temps réel de températures (intérieure et extérieure) ainsi que d’altitude et de pression (les deux étant liées l’une à l’autre) via le réseau LoRa. Après discussion avec M.Redon, une solution impliquant une Arduino sera certainement écarté au profit d’une solution avec carte Raspberry Pi et module LoRa qui simplifiera la gestion de numérisation et d’envoi des données.

Idéalement une caméra reliée à une Raspberry Pi stockera des images sur une carte SD. De plus, un module GPS pourrait être ajouté en fonction des contraintes dans le but du suivi et d’une éventuelle récupération de la nacelle après retour au sol. Des batteries correctement dimensionnées et utilisant la bonne technologie assureront l’alimentation du système.

• Structure de la nacelle :

Pour protéger la partie électronique sensible aux faibles températures, la nacelle sera équipée de chaufferettes chimiques permettant de maintenir la température à un niveau convenable. De plus, une couverture réfléchissante, de type couverture de survie, enveloppera la nacelle pour mieux l’isoler thermiquement. Enfin, pour limiter le poids de l’ensemble, la structure sera faite de polystyrène.

Calendrier prévisionnel

Liste des tâches à effectuer

Afin de mener à bien, plusieurs étapes sont nécessaires, à savoir:

• l'étude des conditions de lancements (notamment auprès de la DGAC) pour un tel objet volant.
• les tests sur l'enveloppe afin de déterminer sa capacité en volume et son altitude maximum potentielle.
• le dimensionnement des batteries.
• intégration du module GPS et LoRA.
• la conception de la nacelle et le câblage de la partie électronique (capteurs, Raspberry etc).

Feuille d'heures

Tâche	Prélude	Heures S1	Heures S2	Heures S3	Heures S4	Heures S5	Heures S6	Heures S7	Heures S8	Heures S9	Heures S10	Heures Travail additionnel	Total
Définition cahier des charges	3												3
Recherche sur la législation et analyse fonctionnelle		2	2										4
Installation et configuration réseau de la Raspberry Pi 2		4	4	4									4
Conception PCB (mise en place des bibliothèques)				6									6
Conception PCB (routage)					8	8							16
Prise en main liaison I2C						4	4	4					12
Programmation des modules LoRa							4			4			8
Travail sur le module GPS									8	4		9	21
Programmation Raspberry Pi									8	8	8	9	33

Avancement du Projet

Semaine 1

• Etude des différents moyens électroniques de mesure et de communications (modules LoRa, capteurs, microcontrôleurs).
• Prise de contact avec la DGAC (direction générale de l'aviation civile) pour renseignement sur les autorisations d'envol.
• Analyse fonctionnelle du système global afin d'avoir une vision d'ensemble du système.

Semaine 2

• Après avoir contacté l'association Planète Science, nous en savons plus sur la partie administrative:

Les autorisations d'envol doivent être demandés au minimum 30 jours avant l'envol auprès de la DGAC et de l'aviation civile Belge. De plus, il faut pouvoir nous couvrir en cas d'incident (à l’atterrissage de la nacelle par exemple). L'association pourrait nous couvrir mais il faudrait se conformer à leur propre système et leur propre cahier des charges. Après concertation avec les tuteurs, nous continuons notre travail mais plutôt dans l'optique d'un test (avec la nacelle embarquée dans un drone ou dans une voiture) que d'un lancé réel engageant notre responsabilité.

• Fin de la liste du matériel

Semaine 3

• Une Raspberry 2 nous a été donné et après quelques difficultés, le système Raspbian est installé sur la carte SD. Nous commençons la prise en main du système (prise de photo, gestion de la liaison I2C...)
• Étude approfondie de la datasheet du capteur de température, prise en main d'Altium et création de la bibliothèque pour notre composant dans le but de créer une plaque où l'on pourra souder ce composant cms.
• Ci-dessous le composant de bibliotheque cree

.

Semaine 4

• Définition des règles de dessin et routage de la carte PCB pour notre capteur de température, envoi du fichier à la rentrée pour sa création physique. Début de la création du fichier Altium pour réaliser le PCB de nos modules LoRa.

• Schéma de notre circuit pour le capteur de temperature

Semaine 5

• Activation de la communication i2c qui nous permettra l'échange de données entre les capteurs et la carte Raspberry. Prise en main à l'aide d'un capteur de lumière en attendant l'usinage des PCB.
• Probleme de routage du PCB et revision des contraintes de routage, rétrécissement des pistes.
• Recherche sur le protocole LoRa et prise en main des deux modules Lora "Feather" qui sont préférés à d'autres solutions pour leur modularité (microprocesseur et liaison série intégrés) et leur simplicité de programmation (par arduino IDE).

Semaine 6

• Premier échange de données entre les deux modules Feather avec un exemple de code de type émission/réception donné dans la documentation. Ci dessous, le moniteur série montrant la réception de la chaîne "Hello World" avec le nombre d'envoi qu'il y a déjà eu:

.

Modification du code afin de lire sur la liaison série du module Lora embarqué les données provenant de la carte Raspberry. Elles sont ensuite envoyées au module Lora de réception.

Semaine 7

• Réception des capteurs de pression, lecture de la datasheet pour mise en fonctionnement de la liaison I2C.
• Problème rencontré lors de la recherche des registres pour la communication I2C : la commande système affiche les registres disponibles et notamment le registre de lecture dont nous avons besoin. Cependant, de nombreux registres sont disponibles mais aucune information n'est présente dans la datasheet pour le choix du bon registre. De plus, à chaque appel de la commande système, les registres changent de manière aléatoire.

Solutions envisagées : choisir un registre selon une plage (infructueux), trouver l'identifiant du composant et réaliser nos communications avec celui-ci ou alors passer la liaison en liaison SPI. Nous retenons la mise en place d'une liaison SPI plus simple.

Semaine 8

• Travail sur le GPS: Initialement, nous avions récupéré un PCB comportant un GPS déjà utilisé lors d'un précédent PFE d'un binôme de la filière IMA. Cependant, après plusieurs heures de tentatives de communication via le port série, il nous est impossible de l'utiliser et envisageons un autre modèle. L'Ultimate GPS Breakout de chez Adafruit est alors pris en main: il communique, comme le précédent, par liaison série différentes données telles que l'altitude, la vitesse, l'heure exacte et bien sûr, les coordonnées géographiques. Nous le connectons donc à un des ports USB de la Raspberry Pi et mettons en place un code en C pour récupérer ce qu'il nous envoie. Cette fois ci, le GPS fonctionne parfaitement.

Semaine 9

• Réflexion et travail sur les communications. Le code du module Lora restant "au sol" évolue afin de permettre l'envoi de requêtes à la nacelle. Ceci dans l'objectif de commander à distance le passage de la nacelle dans un mode d'émission de données différent. Par exemple, n'envoyer que les données GPS, changer l'intervalle de temps entre deux transmissions (dans une optique de gestion de la batterie) etc. Du côté de la nacelle, le code à l'intérieur de la Raspberry est travaillé afin de gérer la réception des requêtes et l'envoi des données.

Lecture des trames GPS suite à la réception de la chaîne de caractère "GPS"

Semaine 10

• Configuration de la liaison série entre la Raspberry Pi et le module Lora ainsi que le module GPS. Nous avions précédemment utilisé la commande "stty" pour fixer la vitesse de communication pour chaque port. Cela s'avère être un mauvais moyen de configuration au vu des nouveaux tests fait cette semaine. Nous réutilisons donc le code vu au semestre précédent et l'intégrons dans le programme en C de la Raspberry Pi. La configuration est faite avec la fonction "init_serial"et "fdopen".

Travail additionnel

• Etant donné le caractère bloquant des fonctions fscanf et fprintf servant à lire sur les liaisons séries de la Raspberry Pi, nous les remplaçons par les fonctions read et write qui se passent de buffer pour fonctionner. Le paramètre O_NONBLOCK est donc ajouté à la liste des drapeaux lors de la configuration des ports. Cela permet maintenant à la Raspberry présente dans la nacelle de dérouler son programme en l'absence de requêtes venant du sol.