Mise en place d'un réseau de capteurs sans fil (2019)

Introduction

Le "Réseau de capteur sans fil" est un projet que l'on peut considérer comme "fil rouge" dans le contexte de ce projet Réseaux Mobiles et Avancés. Si le but de la manipulation, établir une communication entre un groupe de capteurs, est commun, une liberté sur le contexte d'exécution, ainsi que sur le protocole mis en place, est laissé aux élèves, permettant une multitude de réponse pour ce qui pourrait être considéré comme un problème unique.

Dans le cadre de ce projet, nous avons essayé de mettre au point une communication permettant l'entrée et la sortie de capteurs du réseau crée. Plutôt que les performances, une des priorités du projet est d'essayer de consommer le moins d'énergie possible, à notre sens une des motivations principales pour ne pas simplement utiliser une connection Internet "normale".

Les grandes étapes du développement sont alors de mettre en place l'environnement, de théoriser le protocole, et enfin d'implanter une PoC tendant vers notre solution théorique.

Mise en place de l'environnement

S'appuyant sur le travail des précédents projets, la mise en place de l'environnement était censée être rapide et facile.

Seulement voilà. N'ayant pas nos stations personnelles de disponibles, nous nous sommes attelés à faire fonctionner cet environnement sur les PCs de l'Ensimag .

Cette étape rapide et facile s'est alors rapidement transformée en une chasse à la fonctionnalité pour trouver un moyen de passer par delà les contraintes imposées sur ces stations, transformant alors cette trivialité en véritable sous-projet.

Dans la suite de cette section, les contraintes et essais seront détaillés, afin de faciliter le travail pour de potentiels prochains groupes. Si vous ne cherchez que à faire fontionner l'environnement, vous pouvez aller direction à la solution.

Les besoins

Pour que l'environnement fonctionne, il y a en réalité besoin que d'assez peu de conditions:

• Les droits super utilisateur
• L'accès aux ports USB de la machine (physiquement et logiquement)

Les droits super utilisateur nous permettent d'installer les logiciels requis, ainsi que de "réserver" un port USB pour le flash/debug. Des droits corrects sur les utilisateurs normaux pourraient aussi nous le permettre, mais il ne sont pas accordés aux élèves.

L'accès au port USB, pour des capteurs USB, paraît probablement être une évidence. Puisqu'en effet, ça l'est. Est-ce pourtant une garantie ? Non, nous allons le voir.

Les essais

La première idée que nous avons eu est d'essayer de simplement faire une installation utilisateur des logiciels requis. Après tout, de nombreux logiciels sous Linux ne requièrent des droits privilégiés que dans l'unique but de s'installer dans un répertoire système. Changer le répertoire d'installation pourrait alors être une solution simple. Mais mspdebug et l'installation du compilateur ne vont pas dans ce sens, impossible de tout installer/exécuter sans les droits su, y compris en changeant les paramètres.

Bien entendu, il n'y avait que peu d'espoirs que cette première solution naïve fonctionne. Mais, si ce n'est qu'un problème d'accès, des solutions de virtualisation comme Vagrant ou Docker sont idéales. Docker n'étant pas (encore ?) installé sur les stations de l'école, nous essayons alors Vagrant.

Un Vagrantfile est alors crée avec toutes les dispositions nécessaires. Tous les logiciels n'installent correctement, droits de super-utilisateur obligent. Seulement, le logiciel de flashing des cartes ne détecte aucune cartes. En effet, le backend du Vagrant installé est VirualBox. Ce dernier ne partage pas par défaut les périphériques USBs avec la VM. Dans une installation normale, il s'agit juste d'un setting à changer, pour autoriser le passthrough d'un périphérique.

Mais, probablement pour des raisons obscures de sécurité et de normes, ce réglage ne peut pas être modifié par un utilisateur normal. Cette seconde version disposait alors d'un environnement parfaitement fonctionnel... Mais qui ne pouvait pas être utilisé sur les capteurs.

Reste Docker, un conteneur n'étant pas une VM, ce blocage induit par VirtualBox ne devrait pas s'appliquer. Seulement, comme dit précédemment, Docker n'est pas installé sur les PCs, et son accès passe par une commande "lance-vm-5MMSSI.sh". C'est à dire par une VM. Lancée par VirtualBox. Cette troisième solution a donc également été un échec.

Abandonnant l'idée de faire fonctionner la solution sur CentOS, nous nous sommes ensuite dirigés vers FreeBSD, un système d'exploitation alternatif préinstallé sur les stations. Les outils de développement n'étant pas prévus pour ce système, nous essayons de contourner ce problème avec Docker ou Vagrant. Mais ces outils ne sont pas non plus nativement compatibles avec cet OS, et après quelques essais, il est devenu évident que cette quatrième solution n'était pas non plus la bonne.

Il restait alors encore un système d'exploitation alternatif : Windows. En effet, sur Windows (7, Windows 10 plante au démarrage), nous disposons des droits d'administrateurs. Nous pouvons alors installer les outils. Nous avons également accès aux ports USB. Il semble, dans la version utilisée de mspdebug, qu'il y ait une présence d'un bug sur certaines méthodes. Si ce n'est pas confirmé cette fois, nous sommes directement passé par la virtualisation.

Or, à ce stade du développement, nous utilisions un conteneur Docker pour travailler sur nos machines (fixes) personnelles. Nous avons donc voulu utiliser Docker sur Windows pour avoir un environnement cohérent. Pour avoir accès aux ports USB de la machine physique, un conteneur a besoin d'être privilégié. C'est une option accessible dans docker run. Malheureusement, sous Windows, à cause de la manière dont Docker est implémenté (via une machine virtuelle), cette option n'est pas disponble. Cette sixième tentative a néanmoins ouvert la voie pour la solution trouvée.

La solution

Après tous ces essais, nous avons finalement décidé d'installer VirtualBox sur Windows et d'installer Ubuntu sur une VM (Vagrant ou autre). Ayant les droits d'administrateur sur Windows, il nous a été possible de simplement configurer le passthrough USB pour que la machine virtuelle Ubuntu ait accès aux capteurs. Installant ensuite Docker sur cette machine virtuelle, nous avons enfin pu faire fonctionner le conteneur en mode privilégié et pu programmer les capteurs.

Voici le Dockerfile utilisé. Le dépot Gitlab contenant les différentes archives utilisées est disponible dans les sources

Dockerfile

FROM debian:stretch
MAINTAINER Lucas Peirone, Valderane Potong, Michel Yoeung, Jean Charles 

#Installation de make, openssh et lsusb
RUN apt update && apt install -y build-essential openssh-server usbutils nano minicom

# Copie du compilateur et des fichiers de support (depuis le drive)
COPY msp430-gcc-full-linux-x64-installer-8.3.0.0.run /root/msp430.run
COPY support.tar.gz /root/support.tar.gz


#Installation du compilateur gcc msp430
RUN chmod u+x /root/msp430.run
RUN yes | /root/msp430.run --mode text
RUN mv y /opt/msp430-gcc

## Ajout des fichiers de support
RUN tar -C /root -xzvf /root/support.tar.gz
RUN cp -r /root/msp430-gcc-support-files /opt/msp430

## Creation d'alias en console 
RUN ln -s /opt/msp430-gcc/bin/* /bin/

#Installation du debugger
RUN apt install -y mspdebug

# Mfri && BSP
COPY timsp430gcc.tar.gz /root/timsp430gcc.tar.gz
RUN tar -C /opt -xzvf /root/timsp430gcc.tar.gz --strip-components=1

#Installation des projets d'exemples
COPY ezwsn.tar.gz /root/ezwsn.tar.gz
RUN tar -C /root -xzvf /root/ezwsn.tar.gz

#Nettoyage de l'image
RUN rm -rf /var/lib/apt/lists/* /root/support.tar.gz /root/msp430-gcc-support-files /root/msp430.run /root/ezwsn.tar.gz /root/timsp430gcc.tar.gz

RUN mkdir /var/run/sshd
WORKDIR /root/ezwsn/4
EXPOSE 22
CMD ["/usr/sbin/sshd", "-D"]

La méthode suivie par ce DockerFile est celle-ci. Les dépendances sont pré-récupérées sous forme d'archive pour fixer les versions et être certain d'avoir un environnement stable (certains logiciels ne sont pas versionnés au téléchargement). La seule section vraiment remarquable est l'installation du compilateur.

En effet, l'installation est par défaut graphique, ce qui est très embêtant dans notre contexte. Même en mode "textuel", avec l'option --text, des interactions utilisateurs sont demandées. Ce problème est contourné par l'utilisateur de yes, une commande qui répond y à chaque question (beaucoup de questions demandées sont des questions fermées). Cela nous permet d'installer le logiciel, mais avec un effet de bord : une des questions est le chemin d'installation. Le logiciel est donc installé dans le répertoire "y". La ligne suivante corrige donc ce problème.

L'implémentation

Pour pouvoir identifier les capteurs entre eux, nous avions besoin de récupérer un identifiant unique. Dans un réseau classique, c'est une adresse unique à un matériel et attribué par le fabricant. Nous pouvons émuler ce fonctionnement en allant chercher une valeur pré-flashée dans chaque capteur à l'adresse 0x10F0. Il est possible que certains capteurs n'aient pas d'adresse Mac directement associée, dans ce cas, il est possible de d'utiliser cet utilitaire pour flasher les cartes.

Récupération de l'adresse Mac

Méthode

#include <mrfi.h>
#include <bsp_leds.h>

uint8_t *Flash_Addr = (uint8_t *)0x10F0;
static uint8_t Mac_Address[MRFI_ADDR_SIZE];

/**
    Actually retrieve Device unique identifier written on Flash
    @see rousfran/ezaddrs
**/
void retrieve_mac_address(){
    uint8_t *dst = Mac_Address;
	uint8_t *src = Flash_Addr;
	uint8_t len = sizeof(Mac_Address);
	while(len--) {
		*dst++ = *src++;
	}
}

/**
    Affiche une chaîne de caractère sur le port série
    @param string : la chaîne à afficher
    @param length : la longueur de la chaîne
**/
void TXString(char *string, int length)
{
    int pointer;
    for (pointer = 0; pointer < length; pointer++)
    {
        UCA0TXBUF = string[pointer];
        while (!(IFG2 & UCA0TXIFG))
            ;
    }
}
void main(){
    
    //Initilisation du port série pour l'entrée sortie
    P3SEL    |= 0x30;     // P3.4,5 = USCI_A0 TXD/RXD
    UCA0CTL1  = UCSSEL_2; // SMCLK
    UCA0BR0   = 0x41;     // 9600 from 8Mhz
    UCA0BR1   = 0x3;
    UCA0MCTL  = UCBRS_2;                     
    UCA0CTL1 &= ~UCSWRST; // Initialize USCI state machine
    //Interuption pour les entrées sur le terminal
    // A activer pour mettre des inputs si besoin
    //IE2      |= UCA0RXIE; // Enable USCI_A0 RX interrupt
    //Affiche l'adresse mac sur le port série (à écouter avec Minicom !)
    retrieve_mac_address();
    TXString((char*)Mac_Address, MRFI_ADDR_SIZE);
}

Sources

• Le dépot gitlab: Environnement de travail
• TP de Thomas Watteyne: Véritable bible de développement sur les capteurs
• Page principale du projet capteur: Contient tous les liens utiles pour le développement