Envoyer des micro-contrôleurs dans l’espace proche pour prendre des mesures ? Fait ! Envoyer un Raspberry Pi avec une caméra dans l’espace proche ? Fait ! Envoyer plusieurs GoPros dans l’espace proche ? Fait ! Prendre des photos de la terre depuis l’espace proche ? Fait ! Bon alors, qu’est ce qui n’a pas été fait ? A cette question, François Dion et son équipe ont répondu de façon étonnante, ils ont décidé d’envoyer 7 Raspberry Pi équipés de caméras à la frontière de notre atmosphère…

NSCO1, un ballon et 7 Raspberry Pi

Genèse de NSC01

On pourrait penser qu’il ne reste plus rien à faire et que tout a déjà été réalisé. C’est vrai que le lancement de ballons météorologiques chargés de recueillir des données et de prendre des photos à haute altitude a été fait plusieurs milliers de fois auparavant, et même bien avant l’ère de l’appareil photo numérique 😉

En fait, c’est un mémorandum de la NASA (TM X-2208 publié en 1971, qui couvre les vols effectués dans la dernière partie de 1969 depuis le Centre de recherche de Langley en Virginie) qui a servi de source d’inspiration pour une partie de la charge utile du ballon de l’équipe de François… Une sorte d’hommage si vous voulez. Dans ce vol, ils ont utilisé les caméras de cinéma de moyen format, à la fois dans le spectre visible et dans l’infrarouge.

C’est donc avec ce concept que l’équipe a démarré son projet. Un Raspberry Pi avec une  caméra infrarouge (type Pinoir), et un autre avec une caméra classique connectée qu bus CSI

Et rapidement ils ont réalisé qu’ils avaient ouvert la boîte de Pandore… L’innovation était possible dans tous les domaines concernés !

Des yeux dans le ciel

Dans sa « collection » de Raspberry Pi et d’accessoires, François avait déjà plusieurs caméras, dont une infrarouge avec une monture et un objectif de type S. Pour un premier vol, ça aurait pu convenir en ajoutant une caméra classique de Raspberry Pi (avec son objectif « normal » d’origine dont la qualité est tout à fait convenable – les objectifs « normaux » sont relativement facile à fabriquer par rapport aux grands angles et aux téléobjectifs). Mais ils voulaient faire mieux, d’autant que la vidéo 1080p est rognée et donne une couverture moindre.

Pas question de détruire les autres caméras Pi pour leur ajouter la monture S (couramment utilisé sur les caméras de vidéosurveillance), donc c’est une monture magnétique avec une lentille additive qui a été retenue.  De cette façon, la caméra peut être utilisée sans objectif de conversion, ou avec un téléobjectif, ou même une lentille additive de type fish-eye.

 

Bien sûr, la plupart des gens rejettent les lentilles additives qu’ils considèrent comme étant de mauvaise qualité. Et c’est vrai qu’optiquement, elles sont terribles, avec beaucoup de distorsion en barillet et d’autres problèmes. En fait, la distorsion en barillet est facile à observer sur les vidéos youtube prises avec un grand angle (qui est l’objectif livré d’origine) des caméras « sports extrêmes » qui sont si populaires. Plus on se rapproche du bord, plus l’image est déformée…

Mais cela n’a pas été un obstacle car avec le bon logiciel François était convaincu qu’il était possible d’obtenir des images décentes. Donc il a monté une lentille grand angle sur une caméra de Raspberry Pi, alimenté le RasPi avec une batterie de secours de téléphone (avec un câble micro USB) et pris des photos pour calibrer son logiciel (écrit en Python). Il s’est ensuite rendu au centre Winston Salem pour prendre des photos de bâtiments avec beaucoup de lignes horizontales et verticales. Dans ce cas, la distorsion est facile à observer. Et finalement les résultats après correction de l’image étaient assez satisfaisants :

Les défauts qui restent sont dus à la déformation normale en raison de la perspective, mais on distingue à peine la distorsion causée par l’objectif. Super ! Au tour des ordinateurs maintenant…

Comme une épicerie

En fait, construire un HAB (ballon de haute altitude) avec plusieurs ordinateurs, c’est comme acheter des provisions pour une famille 😉 Plus il y a d’enfants et… plus la note est élevée. Un seul Raspberry Pi modèle A + coûte seulement 25€ plus les frais de port. Et dès le début, l’équipe savait qu’il en faudrait deux. Au minimum.

Ensuite, ils ont commencé à regarder les options pour monter 4 caméras sur la charge utile. Pour des photos panoramiques à 360°… Eh bien, avec l’objectif grand angle utilisé il en fallait 5 ! Mais, bon, 6 est un beau chiffre tout rond, et en raison de la réduction de l’image en mode 1080p, ça fait juste 360 ​​degrés. Mais… Comment se connecter 6 caméras CSI à 2 Raspberry Pi?

Une première approche a été de construire ou d’acheter un multiplexeur. Mais le temps a manqué pour la construction, et il était impossible d’acheter un véritable multiplexeur. Des essais ont été faits avec un commutateur de bus CSI (fait pour 4 caméras par carte) commandé en Turquie. Il est bien arrivé mais il n’a jamais fonctionné. Un remplacement a été demandé, mais le vendeur n’a jamais donné signe de vie 🙁 Caveat emptor.

Le plan B était de de mettre un Raspberry Pi par caméra. Et nous avions 6 caméras ordinaires pour la vue panoramique à 360 degrés, et une caméra infrarouge vers le bas. Donc il fallait… 7 Raspberry Pi

Imaginez votre facture d’épicerie avec 7 enfants …

Donc pour le projet il fallait 7 RasPi, 7 caméras, 7 cartes mémoires SD (un mélange de cartes 32Go et 64Go), une batterie assez puissante pour alimenter tout ça. Ah oui, l’alimentation…

12V! = 5V

Pour alimenter tout le matériel qui serait embarqué (7 Raspberry Pi, 7 caméras CSI, une caméra USB, 2 GPS, des capteurs, 1 balise APRS émettant avec une puissance de 10W toutes les 2 minutes),  il fut décidé d’utiliser des batteries au lithium polymère 3S (3 cellules en série), couramment utilisés dans les applications RC (radio-commande) et les drones.

Pour faciliter la répartition du poids et assurer la redondance, ce sont deux éléments qui seront utilisés. Mais cela signifiait de les relier en parallèle. Ce serait parfait pour la balise APRS (transmission de la position, de la tension batterie et de la température toutes les deux minutes) car elle fonctionne sous 12V.

Mais le Raspberry Pi, lui fonctionne sous 5v, pas sous 12V. Donc, l’alimentation a été équipée de deux UBECs. Ce sont des régulateurs de tension à découpage. Ils ne sont pas vraiment conçus pour fonctionner en parallèle, mais ils ont été testés 12 heures d’affilée de nombreuses fois sans aucun problème. Regardez sur les forums RC, les gens disent que ce n’est pas possible… Eh bien si, vous pouvez. Ils perdent juste une partie de leur efficacité de cette façon, car ils utilisent le PWM pour réguler la tension de sortie en mesurant sa valeur. Lorsque 2 UBECs sont en parallèle, la sortie de l’un interfère avec la boucle de contre-réaction de l’autre. Pourtant, nous étions prêts à perdre un peu de rendement pour assurer la redondance.

Il fallait aussi réaliser une pieuvre à 7 pattes avec 7 microUSB pour distribuer le 5V aux 7 Raspberry Pi. Son poids devait être aussi faible que possible… L’idée de départ était de le connecter aux bornes GND et 5V du connecteur GPIO, mais quand les 7 RasPi ont été reliés ensemble, cet élément a causé quelques problèmes comme nous le verrons par la suite.

Et le réseau?

Plan A : 2 RasPi dans un Pod …

Le plan initial était de relier 2 Raspberry Pi en utilisant un protocole de communication série. Le modèle A + ne possédant pas de port Ethernet.

Bien sûr, un Raspberry Pi 2 a un, et est plus puissant, mais il consomme aussi beaucoup plus de puissance que le A +. La capacité de la batterie aurait dû être beaucoup plus importante si cette voie avait été choisie, et cela signifiait aussi qu’elle aurait été beaucoup plus lourde.

La limite était fixée à 2 kg pour la charge utile elle-même, et on n’en était pas loin, donc ce serait de la communication série…

Le connecteur du GPIO

Le Raspberry Pi n’a pas un connecteur RS232 (DB9 ou DB25). Mais si vous regardez le brochage du connecteur GPIO à 40 broches, vous remarquerez sur la rangée du haut, les 4^ème et 5^ème broches : Elles sont notées TXD et RXD.

C’est bien un port série, mais il n’est *pas* compatible RS-232 en ce qui concerne les tensions (en RS232 : un 1 est une tension négative comprise entre -3 V et -15V, et un 0 est une tension positive dans la plage + 3V à 15V), comme c’est une interface TTL un 1 est une tension positive de 3V3 et un 0 est indiqué par du 0V). Mais pour le connecter à un autre Raspberry Pi ça ne pose aucun problème.

En fait le principal problème avec ce port série est que le système d’exploitation Raspbian dispose d’une console (TTY) qui lui est associée. Ce qui signifie que vous pouvez vous connecter à un ordinateur, avec le câble qui va bien, et observer le processus de démarrage puis obtenir une invite sur la console, et même taper des commandes, comme si vous aviez un clavier et un  moniteur raccordé directement au Raspberry Pi.

Dans le cas présent, cependant, le port doit être utilisé pour autre chose, le réseau de communication de NSC01, et il faut donc désactiver cette fonctionnalité. C’est parti…

Configuration

Raspi-config dispose maintenant d’une option (dans les options avancées) pour désactiver la console du port série, afin de pouvoir l’utiliser directement :

Une fois que le port série est reconfiguré, nous pouvons sortir de Raspi-config redémarrer le RasPi. Pour chaque Raspberry Pi du réseau, en plus de la désactivation de la console du port série, il faut également activer dans les options avancées les bus SPI et I2C, et sur la page principale configurer le fuseau horaire, autoriser la caméra et étendre le système de fichiers. Les RasPi 1 à 3 ont été overclockés à 800 MHz tandis que les RasPi 4 à 6 restent à 700 MHz (afin de mesurer l’impact de l’overclocking).

Plan B : Un cluster de Raspberry Pi

En utilisant une paire de Raspberry Pi, le processus de communication est assez simple. Avec deux nœuds, nous pouvons utiliser SLIP ou protocole point à point (PPP). Initialement, c’est ce qui avait été choisi pour NSC-01 pour ne pas avoir à écrire le code pour la couche réseau.

Mais sans commutateur de caméra, la seule option était d’utiliser un nœud par caméra (chaque Raspberry Pi a 1 seul connecteur CSI, même si le SoC Broadcom peut en gérer 2 – la plupart des téléphones cellulaires ont un appareil photo avant et arrière). Avec 7 caméras CSI au total, cela signifiait qu’il fallait faire communiquer 7 Raspberry Pi.

Il fallait trouver autre choise…

Token Ring

Parmi les options possibles, il y avait ce bon vieux IBM Token Ring (et FDDI). Conceptuellement, au moins. Il ne s’agissait pas de faire quelque chose de compatible avec 802.5, mais plutôt de réutiliser le concept en série avec l’UART, pour transmettre et recevoir d’un nœud à l’autre.

Conceptuellement, un nœud est toujours à l’écoute sur le port série. Est-ce que les données sont pour moi? (est-ce un broadcast ou est-ce que ces données sont pour moi?) Si ce n’est pas le cas, ou si c’est un broadcast, j’envoie tout de suite les données au noeud suivant. Je les traite si elles me sont adressées. Voyons cela dans les détails.

Le schéma

Au début de l’article, l’une des photos montre clairement 7 Raspberry Pi reliés ensemble à l’intérieur de la charge utile. Le schéma Fritzing ci-dessus peut vous aider à détailler comment les choses se passent.

Dans le schéma ci-dessus, c’est un mod-èle B+ qui est représenté car le modèle A+ n’était pas disponible dans Fritzing. Tous les deux ont un connecteur 40 broches GPIO. La première rangée en haut, comporte de gauche à droite les broches 5V, 5V, GND, TxD et RxD. Nous nous arrêterons là pour le moment.

Ici, la broche TxD du nœud 1 a été connectée au RxD du nœud 2 (fil bleu), la broche TxD du nœud 2 a été connectée au RxD du nœud 3 (rose), la broche TxD du nœud 3 a été connectée au RxD du nœud 4 (brun), TxD nœud 4 au RxD nœud 5 (cyan) , TxD nœud 5 au RxD nœud 6 (orange), TxD nœud 6 au RxD nœud 7 (jaune) et enfin TxD nœud 7 au RxD nœud 1 (vert), dans un joli mode circulaire (ou en anneau).

Les GND ne sont pas connectés en guirlande d’un RasPi à l’autre, car ils sont tous alimentés par la même source, via leurs prises microUSB.

Initialement, Il était prévu d’alimenter les RasPi directement sur la broche 5V du connecteur GPIO, mais le signal n’était décodé que partiellement. En alimentant entre 3.3V (c’était la solution, l’UART fonctionne à 3V3 de sorte que le signal HIGH n’était pas détecté de façon fiable lorsque l’alimentation était seulement faite en 5 V) et GND, le fonctionnement était plus fiable, mais c’était aussi plus compliqué. Finalement les 7 nœuds ont été alimentés à l’aide de connecteurs microUSB (comme indiqué plus haut).

Python

Ce qui est formidable à propos de Raspbian est que non seulement Python est installé, mais que Python 2.x et 3.x sont présents, ainsi que beaucoup de choses qui sont normalement en option, comme pygame, pyserial, RPi.GPIO etc.

Pourtant, pour créer le logiciel de mise en réseau, il a fallu installer deux modules de pypi utilisant pip3 (c’est Python 3 qui est utilisé) : docopt et sh.

La majeure partie du développement a été réalisée sur un Raspberry Pi modèle B + connecté à un ordinateur portable et à un second Raspberry Pi en utilisant le port série et un switch Ethernet. De cette façon, l’ordinateur portable pouvait voir les deux Raspberry Pi et il était possible de charger de nouvelles versions du logiciel en utilisant scp.

L’homme mort

Un dispositif de sécurité ferroviaire, la pédale de l’homme mort permet d’arrêter un train en cas de malaise du conducteur. La nacelle a été munie d’un dispositif identique

Pour la participation de l’équipe de Near Space Circus au  Global Space Balloon Challenge avec le NSC-01, il fallait qu’une fois le système mis sous tension, et la nacelle fermée, l’équipe garde le contrôle de la grappe d’ordinateurs et de la chronologie des événements. Comme le système comporte un réseau de 7 nœuds pilotés par un contrôleur maître et de nombreux nœuds esclaves, il fallait trouver un moyen pour que le système puisse recevoir une information de l’extérieur.

Un commutateur classique aurait pu faire l’affaire, bien sûr. Mais que faire si le ballon décolle et que personne n’ait appuyé sur l’interrupteur ? Ou si quelqu’un trébuche et laisser échapper le ballon ?

Et puis le contrôleur maître serait resté en mode veille, envoyant simplement des trames vers les autres nœuds et il n’y aurait eu aucune image, aucune vidéo, aucune donnée GPS etc. Pas bon tout ça !

Interrupteur captif

Si vous avez déjà utilisé un tapis de marche, vous avez sans doute rencontré un commutateur captif. Habituellement, c’est un système magnétique, avec une chaîne terminée par un clip. Vous l’accrocherez sur vous et si jamais vous tombez vous arrachez le lien de sécurité, ce qui arrête instantanément la machine.

Comme le Raspberry Pi a de nombreuses broches GPIO, tout ce que nous avions à faire était de créer un circuit simple entre deux d’entre elles qui, une fois interrompu, serait le signe qu’il était temps pour le contrôleur maître de se mettre au travail.

Ce sont les broches GPIO17 et 27 qui ont été choisies.
Pourquoi deux GPIOs ? Il aurait été possible de connecter une broche GPIO au 3V3 et à la masse par des résistances (pour la protéger / limite de courant), afin d’indiquer les modes veille et travail. Mais, si on veut garder les choses aussi simples que possible d’un point de vue matériel (le logiciel ne pèse rien, le matériel si !), l’utilisation de GPIOs est beaucoup plus correcte. Un GPIO est défini en entrée, l’autre en sortie, la sortie est mise à l’état HAUT, l’entrée voit maintenant une valeur de 1. Si on ouvre le circuit (en tirant sur le fil), l’entrée ne voit plus le niveau HAUT et elle lit maintenant 0.

Une corde est attachée à une extrémité du fil qui sort du côté de la charge utile et à l’autre extrémité à un mousqueton. C’est tout ce qu’il fallait.

Le vol

Tout est prêt… Le vol sera un succès. Dès que les courbes seront publiées, ainsi que les photos prises pendant le vol, vous les retrouverez ci dessous…

Pour l’instant seules ces 3 photos sont disponibles :

Sources

• http://raspberry-python.blogspot.co.uk/2015/04/the-computer-network-in-space-part-1.html
• http://raspberry-python.blogspot.co.uk/2015/04/the-computer-network-in-space-part-2.html
• http://raspberry-python.blogspot.fr/2015/04/excellent-mission-debrief-tonight.html
• http://raspberry-python.blogspot.fr/2015/04/deadmans-switch.html
• http://physicslogos.blogspot.fr/2015/05/near-space-balloon-launch-nsc01-by-team.html
• https://balloonchallenge.org/