Élaboration d’un prototype bas coût d’instrumentation mobile pour l’acquisition de nuages de points géoréférencés par photogrammétrie

Élaboration d’un prototype bas coût d’instrumentation mobile pour l’acquisition de nuages de points géoréférencés par photogrammétrie

L’ordinateur de bord : Tablette (Getac)

L’ordinateur de bord est essentiel dans la conception d’un prototype de photogrammétrie mobile. En effet, c’est la pièce centrale permettant de lancer les mesures des appareils utilisés, de centraliser les données reçues et de les traiter. Il faut également que cet ordinateur soit léger et portatif afin qu’il soit facilement transportable. Ainsi, notre premier choix s’est tourné vers un Raspberry (voir Figure 6) après avoir lu un TFE sur le même thème [NIEDERBERGER G., 2021]. Ce dernier est un microordinateur de la taille d’une carte de crédit et est composé de tous les éléments nécessaires afin de faire tourner un système d’exploitation Linux. Cela a été développé par la société Eben Upton en 2006 [KUBII, 2022]. Bien que ce micro-ordinateur corresponde parfaitement aux critères énoncés précédemment, des difficultés ont été rencontrées très tôt dans la prise en main du Raspberry. En effet avec le Raspberry, il n’était pas possible de se connecter en wifi avec la caméra. De plus, la bibliothèque python utilisée  pour le contrôle de la centrale ne s’installait pas correctement nous empêchant d’avoir des données issues de cet instrument. Nous avons alors voulu trouver une autre solution concernant l’ordinateur de bord. Nous avons donc étudié la possibilité d’utiliser la tablette tactile Getac disponible à l’école. La tablette tactile est développée par Getac et est sous système d’exploitation Windows 10 (voir Figure 7). Bien que cette tablette soit nettement plus lourde que le Raspberry, elle reste tout à fait portable pour de la photogrammétrie mobile. Elle comporte également un écran avec lequel on peut interagir pendant le lever ouvrant un champ des possibles plus grand qu’avec le Raspberry. Cela ne serait pas possible avec ce dernier à moins d’y ajouter un écran servant de moyen de communication avec l’utilisateur mais cela encombrerait le prototype. En comparant les deux solutions, on comptait des avantages et des inconvénients de chaque côté. Pour le Raspberry, bien qu’il soit la solution la plus adéquate en ce qui concerne le poids, il l’est beaucoup moins pour ce qui est de la praticité lors du lever. En effet, il faudrait lancer le programme permettant de récupérer les données dès que le Raspberry est alimenté ou alors après quelques secondes mais nous n’aurions aucune mainmise sur le déroulement du programme. C’est-à-dire que nous ne saurions pas si les appareils sont bien connectés au Raspberry, si le programme se déroule sans encombre. De l’autre côté, avec la tablette, nous avons un ordinateur de bord plus lourd que le Raspberry mais avec un avantage non négligeable puisqu’il possède un écran tactile. Ce dernier permettant de voir le déroulé du programme, voir si tous les appareils sont bien connectés, mais aussi et surtout permettant d’interagir avec l’utilisateur pour s’adapter un maximum à l’objet levé. C’est cet élément qui a fait pencher la balance du côté de la tablette tactile Getac. Ainsi pour toutes les raisons évoquées, nous avons fait le choix d’utiliser la tablette tactile comme ordinateur de bord aux dépens du Raspberry. Figure 7 : Tablette tactile GETAC Source : GETAC.com 15 II Intégration des différentes composantes du prototype Pour commencer à utiliser les appareils, il faut d’abord les agencer entre eux pour former notre prototype d’instrumentation. Il faut ensuite pouvoir les contrôler et les faire fonctionner afin de lancer nos lever. La tablette servant d’ordinateur de bord est la pièce centrale de ce prototype puisqu‘elle contrôlera les instruments à distance. Cela sera possible depuis un script python qui se décompose en trois phases. La première phase concerne celle de la connexion, c’est-à-dire que l’on va s’assurer que tous les appareils soient connectés à la tablette. Nous allons ensuite initialiser les appareils et enfin commencer le lever pour l’acquisition des observations nécessaires. 

Un chariot multicapteur

Dans un premier temps, nous avions à notre disposition un chariot (voir Figure 8) pouvant être déplacé à notre guise. Le récepteur GNSS devait être positionné en hauteur de manière à ce qu’aucun objet ou personne puisse gêner la réception des signaux et ainsi ne pas avoir de données à cet instant t. Cet appareil doit donc être le plus haut possible. De plus, la caméra devait être au plus près de l’objet à lever pour qu’aucun élément du chariot ne puisse créer un cache ou même assombrir la vidéo. Enfin, la centrale étant reliée par câble USB à la tablette, il faut qu’elle ne soit pas trop loin de cette dernière pour qu’elle puisse être branchée. La Figure 8 montre la configuration que nous avons choisie en fonction des paramètres énoncés précédemment. A noter que d’autres dispositions sont possibles tant qu’elles respectent ces mêmes contraintes. II.2 Connexion et utilisation des appareils Cette phase va nous permettre de connecter chaque instrument à la tablette afin qu’ils puissent, in fine, envoyer les données à l’ordinateur de bord. Figure 8 : Montage de tous les appareils sur un chariot 

Pour le récepteur GNSS

La connexion au récepteur GNSS peut se faire de deux façons différentes : soit par câble USB ou soit par bluetooth. Dans le premier cas, cela impliquerait d’ajouter des ports USB à la tablette puisque celle-ci n’en est équipée que d’un seul (ce port USB étant utilisé par la centrale). Il faudrait alors avoir un HUB USB pouvant accepter au moins deux ports USB (un pour le GNSS et un pour la centrale). Cependant, ce prototype a pour vocation d’être le plus portatif possible et donc, par définition, à être le plus léger possible afin de permettre une utilisation plus facile de ce dernier. Ainsi, pour éviter d’ajouter un appareil non essentiel au prototype, il est plus judicieux de se connecter au GNSS par bluetooth. La connexion bluetooth de la tablette vers le GNSS va se faire avec un code python (la Figure 9 illustre ce code) et plus particulièrement grâce à la bibliothèque pybluez [Albert Haung & contributors, 2022]. Cette dernière permet de détecter les appareils bluetooth à proximité, de s’y connecter afin de pouvoir recevoir des informations. Dans un premier temps, il est nécessaire de connaître les appareils bluetooth présents dans l’environnement proche de la tablette afin d’y trouver notre récepteur GNSS. Pour cela, nous utiliserons la fonction bluetooth.discover_devices() qui permet d’avoir le nom ainsi que l’adresse de connexion de tous les appareils détectés par la tablette. Après avoir choisi notre GNSS parmi ceux trouvés, nous devons apparier notre tablette au GNSS. C’est ce que la fonction bluetooth.find_service() nous permet de faire en lui indiquant une adresse de connexion. Il faut à présent créer un socket, c’est-à-dire une « maison » qui permet de stocker les données envoyées par le GNSS avant qu’elles soient enregistrées dans la tablette. Ainsi, nous utiliserons bluetooth.BluetoothSocket() afin de créer ce socket puis .connect() pour permettre au serveur (ici le Reach) d’envoyer ses données au client (ici la tablette) par l’intermédiaire de la « maison » (le socket). Le GNSS est connecté à la tablette et il est maintenant possible de prendre les données présentes dans ce socket grâce à .recv() et de les enregistrer dans un fichier texte. On peut alors résumer les trois dernières fonctions avec le schéma suivant : Une fois la tablette connectée au GNSS il faut pouvoir récupérer et traiter les données envoyées par le Reach toutes les secondes. Pour ce faire, deux solutions ont été envisagées. La première consiste à utiliser une boucle while infinie avec à l’intérieur la fonction .recv() qui permet de prendre les données présentes dans le socket dès qu’une donnée arrive donc toutes les secondes. L’avantage de cette méthode : peu importe le nombre d’octets entrés dans la fonction .recv(), toutes les données seront récoltées. Cependant, il faut utiliser une boucle infinie qui peut être contraignante pour la suite du programme. La deuxième consiste à faire appel à la fonction .recv() à la fin du programme, dès que toutes les données ont été enregistrées dans le socket. Cette manière est la plus pratique puisqu’on n’utilise pas de boucle infinie cependant le choix du nombre d’octets entrés dans la fonction est indispensable si l’on veut récolter l’entièreté des données du GNSS. On verra par la suite que les deux manières peuvent être utilisées avec plus ou moins de succès.