P15 Réseau de capteurs temps réel : Différence entre versions
(→Deuxième semaine (25/09/17 : 01/10/17)) |
(→Server/Client UDP) |
||
(61 révisions intermédiaires par le même utilisateur non affichées) | |||
Ligne 21 : | Ligne 21 : | ||
====Description du projet==== | ====Description du projet==== | ||
+ | Ce projet consiste à la mise en place d'un réseau sans fil de capteurs temps réel, afin de pouvoir envoyer/recevoir des commandes/informations d'un serveur vers la cible (un robot dans ce cas). Le réseau qu'on va mettre en place va devoir être capable d’effectuer le chemin le plus court vers le nœud cible dans le but de diminuer le temps de propagation de l'information. Comme montre la figure ci-après: | ||
[[Fichier:iot.png|800px|thumb|center|Architecture matérielle]] | [[Fichier:iot.png|800px|thumb|center|Architecture matérielle]] | ||
Ligne 39 : | Ligne 40 : | ||
*Initiation à la recherche bibliographique (RIOT OS, Réseau temps réel, microcontrôleurs ARM (stm32), MAC protocol, RPL, etc.) | *Initiation à la recherche bibliographique (RIOT OS, Réseau temps réel, microcontrôleurs ARM (stm32), MAC protocol, RPL, etc.) | ||
− | == | + | ====Calendrier prévisionnel==== |
+ | [[Fichier:Previsionnel.png|1000px]] | ||
+ | |||
+ | ==Travail réalisé== | ||
+ | ====Récupération du code et installation des outils de compilation==== | ||
+ | Avant de commencer à programmer une application, il faut tout d'abord cloner le code source de RIOT OS depuis GitHub: | ||
+ | |||
+ | git clone https://github.com/RIOT-OS/RIOT.git RIOT | ||
+ | |||
+ | Il faudra aussi installer les outils nécessaires à la compilation et au débogage de la famille de microcontrôleurs ARM: | ||
+ | |||
+ | sudo apt-get install build-essential g++-multilib gtkterm openocd | ||
+ | |||
+ | Le paquetage g++-multilib est uniquement nécessaire si le système hôte est 64bits. | ||
+ | |||
+ | Installation des compilateurs et ses outils associés: | ||
+ | |||
+ | sudo apt-get install gcc-arm-none-eabi gdb-arm-none-eabi binutils-arm-linux-gnueabi | ||
+ | |||
+ | ====Prise en main de RIOT OS et STM32F4discovery==== | ||
+ | |||
+ | RIOT est un système d'exploitation construit autour d'un micro-noyau temps-réel, développé pour les besoins de l'Internet des objets et des réseaux sans fil. Initialement lancé en Europe par INRIA, Freie Universität Berlin, et l'Université de Hambourg en 2013, RIOT est actuellement développé par une large communauté du logiciel libre rassemblant des développeurs du monde entier. | ||
+ | |||
+ | Pour prendre à main RIOT et la carte STM32, On a commencé par réaliser une application basé sur l'exemple "hello_world" de RIOT: cette simple application "gpio_to_serial" est capable d'allumer/éteindre une led dès qu'une interruptions est générée lors qu'on appuie sur le bouton "user" et affiche l'état de la led au terminal: | ||
+ | |||
+ | 2017-10-22 19:02:26,692 - INFO # GPIO Callback | ||
+ | 2017-10-22 19:02:26,693 - INFO # Message received, LED is ON | ||
+ | 2017-10-22 19:02:34,944 - INFO # GPIO Callback | ||
+ | 2017-10-22 19:02:34,945 - INFO # Message received, LED is OFF | ||
+ | 2017-10-22 19:02:35,040 - INFO # GPIO Callback | ||
+ | 2017-10-22 19:02:35,041 - INFO # Message received, LED is ON | ||
+ | 2017-10-22 19:02:38,184 - INFO # GPIO Callback | ||
+ | 2017-10-22 19:02:38,186 - INFO # Message received, LED is OFF | ||
+ | 2017-10-22 19:02:38,280 - INFO # GPIO Callback | ||
+ | 2017-10-22 19:02:38,281 - INFO # Message received, LED is ON | ||
+ | 2017-10-22 19:02:40,578 - INFO # GPIO Callback | ||
+ | 2017-10-22 19:02:40,580 - INFO # Message received, LED is OFF | ||
+ | |||
+ | Cette application m'a permit de comprendre comment fonctionne le système riot et de passer à la mise en place d'un premier réseau. | ||
+ | |||
+ | ====Mise en place d'un réseau statique==== | ||
+ | |||
+ | Maintenant on vais réaliser la mise en place d'un réseau multi-point avec 3 nœuds (2 sauts); Pour que cela soit possible chaque carte ayant un module radio doit avoir son adresse ipv6 global qui va permettre d'échanger des paquets entre elles. On a défini une adresse global du type '''baad:a555::Hwaddr'''. | ||
+ | |||
+ | Le réseau statique à 3 nœuds se comporte comme un réseau linéaire avec un nœud central se chargeant uniquement de router les paquets vers la destination: | ||
+ | |||
+ | [[Fichier:Static_network.png | center]] | ||
+ | |||
+ | Pour mettre en place cette structure réseau, RIOT OS dispose des nombreuses fonctions telles quelles: | ||
+ | |||
+ | *'''ifconfig''': permet configurer l'interface réseau. | ||
+ | *'''fibroute''': table dynamique qui lie les adresses MAC aux ports | ||
+ | *'''pingv6''': permet de tester l'accessibilité d'une autre machine à travers un réseau IP en envoyant de paquet ICMPv6 | ||
+ | *''' udp''': permet de démarrer un serveur udp et d'envoyer des paquets via le protocole udp sur un port prédéfini | ||
+ | |||
+ | L'exemple '''gnrc_networking''' de RIOT, permet de mettre en place la pile réseau GNRC IPv6/6LoWPAN qui est dédié à l'internet des objets. Cet exemple agit comme un routeur et permet de définir des routes statiques ainsi que d'utiliser RPL. On va donc utiliser cet exemple afin de mettre en place le réseau, il suffira de rajouter le module '''at86rf231''' dans le Makefile. | ||
+ | |||
+ | Le node1/client, enverra des paquets avec des ordres de commande vers le node3/serveur (qui correspond au robot avec des moteurs). Ces informations vont tout d'abord passer par le node2 qui est responsable au routage de ces paquets vers le node2. Le node2 va aussi pouvoir retourner des informations vers le node1, par exemple la vitesse de rotation des roues. | ||
+ | |||
+ | ====Test, communication réseau==== | ||
+ | |||
+ | Une fois le réseau mis en place, on a fait des tests afin de voir si les cartes arrivaient à communiquer entre-elles. Les résultats ont étés satisfaisants comme le montre les figures ci-dessous: | ||
+ | |||
+ | [[Fichier:Ping term1 1.png|thumb|center|700px|ping node1 vers node3]] | ||
+ | |||
+ | |||
+ | [[Fichier:Ping term2 1.png|thumb|center|700px|ping node3 vers node1]] | ||
+ | |||
+ | Après on a éteint node2 et on a essayé de faire un ping à nouveau afin de tester si les paquets ne passaient pas directement du node1 vers node3, sans passer par le deuxième. D'après l'image on voit bien qu'il maintenant impossible de faire un ping: | ||
+ | |||
+ | |||
+ | [[Fichier:Ping_fail.png|thumb|center|700px|ping node1 vers node3]] | ||
+ | |||
+ | =====Server/Client UDP===== | ||
+ | |||
+ | Tout d'abord on a démarré un serveur upd au node3: | ||
+ | |||
+ | > udp server start 12345 | ||
+ | 2017-10-22 18:30:34,250 - INFO # udp server start 12345 | ||
+ | 2017-10-22 18:30:34,252 - INFO # Success: started UDP server on port 12345 | ||
+ | |||
+ | Ensuite on a envoyé un message ("test") UDP du node1 vers le node3: | ||
+ | |||
+ | udp send baad:a555::1736 12345 test | ||
+ | 2017-10-22 18:31:30,696 - INFO # udp send baad:a555::1736 12345 test | ||
+ | 2017-10-22 18:31:30,699 - INFO # Success: sent 4 byte(s) to [baad:a555::1736]:12345 | ||
+ | |||
+ | Le message a été bien reçu par le node3, cela montre que le réseau a été bien mis en place: | ||
+ | |||
+ | > 2017-10-22 18:31:30,728 - INFO # PKTDUMP: data received: | ||
+ | 2017-10-22 18:31:30,730 - INFO # ~~ SNIP 0 - size: 4 byte, type: NETTYPE_UNDEF (0) | ||
+ | 2017-10-22 18:31:30,731 - INFO # 00000000 74 65 73 74 | ||
+ | 2017-10-22 18:31:30,732 - INFO # ~~ SNIP 1 - size: 8 byte, type: NETTYPE_UDP (4) | ||
+ | 2017-10-22 18:31:30,733 - INFO # src-port: 12345 dst-port: 12345 | ||
+ | 2017-10-22 18:31:30,734 - INFO # length: 12 cksum: 0xc94b | ||
+ | 2017-10-22 18:31:30,736 - INFO # ~~ SNIP 2 - size: 40 byte, type: NETTYPE_IPV6 (2) | ||
+ | 2017-10-22 18:31:30,737 - INFO # traffic class: 0x00 (ECN: 0x0, DSCP: 0x00) | ||
+ | 2017-10-22 18:31:30,738 - INFO # flow label: 0x00000 | ||
+ | 2017-10-22 18:31:30,739 - INFO # length: 12 next header: 17 hop limit: 63 | ||
+ | 2017-10-22 18:31:30,740 - INFO # source address: baad:a555::1702 | ||
+ | 2017-10-22 18:31:30,741 - INFO # destination address: baad:a555::1736 | ||
+ | 2017-10-22 18:31:30,754 - INFO # ~~ SNIP 3 - size: 24 byte, type: NETTYPE_NETIF (-1) | ||
+ | 2017-10-22 18:31:30,755 - INFO # if_pid: 7 rssi: 21 lqi: 255 | ||
+ | 2017-10-22 18:31:30,756 - INFO # flags: 0x0 | ||
+ | 2017-10-22 18:31:30,757 - INFO # src_l2addr: 10:10:64:32:14:0f:17:32 | ||
+ | 2017-10-22 18:31:30,758 - INFO # dst_l2addr: 10:10:64:2d:14:39:17:36 | ||
+ | 2017-10-22 18:31:30,760 - INFO # ~~ PKT - 4 snips, total size: 76 byte | ||
+ | |||
+ | ==Conclusion== | ||
+ | |||
+ | ==Archive Git== | ||
+ | |||
+ | https://archives.plil.fr/elopes/PFE15.git |
Version actuelle datée du 26 octobre 2017 à 20:46
- Etudiant : Edmur Lopes
- Encadrants : Alexandre Boé / Xavier Redon / Thomas Vantroys
Sommaire
Cahier des charges
Présentation générale du projet
Le projet réseau de capteurs temps réel consiste à développer et évaluer la possibilité de contrôler en temps réel un moteur par liaison sans fil.
Contexte
L'industrie 4.0 propose d'organiser les moyens de production de façon agile et autonome. Pour cela, on peut envisager de créer des ilots de travail interconnectés. Chaque ilot pourrait être déplacé pour optimiser soit l'utilisation des ressources soit la production. Dans le cas d'ilots identiques, pour faciliter la mise à jour des systèmes et le contrôle des machines, il peut être intéressant de faire la régulation sur un système "serveur". Les ilots deviennent alors les clients et envoient leurs données au serveur qui renvoie par la suite la commande.
Objectif du projet
L'objectif du projet consiste à mettre en place un réseau radio multi-saut classique (temps réel). Pour cela il va falloir:
- Développer un réseau non temps réel basé sur des cartes STM32 et des radios à 868 MHz, embarquant un système d'exploitation Riot OS,
- Évaluer les temps de propagation de l'information en fonction de l'environnement (perturbations, distance, ...),
- Modifier la partie MAC de Riot OS pour garantir les temps de latence.
Description du projet
Ce projet consiste à la mise en place d'un réseau sans fil de capteurs temps réel, afin de pouvoir envoyer/recevoir des commandes/informations d'un serveur vers la cible (un robot dans ce cas). Le réseau qu'on va mettre en place va devoir être capable d’effectuer le chemin le plus court vers le nœud cible dans le but de diminuer le temps de propagation de l'information. Comme montre la figure ci-après:
Liste des tâches à effectuer
- Faire des recherches bibliographiques: temps réel, MAC, RIOT OS...
- Prise en main de RIOT OS et de la carte STM32F4
- Mettre en Place un réseau non temps réel
- Étudier les caractéristiques de ce réseau non temps réel: le temps de latence, des éventuels erreurs lors de l'émission...
- Rendre le réseau non temps réel en réseau temps réel
- Mise en place d'une commande automatique en cas de défaut sur le réseau
Première semaine (18/09/17 : 24/09/17)
- Premier Rendez-vous de présentation du projet avec les encadrants
- Analyse du besoin et élaboration du cahier des charges
Deuxième semaine (25/09/17 : 01/10/17)
- Élaboration de la page wiki (présentation du projet)
- Initiation à la recherche bibliographique (RIOT OS, Réseau temps réel, microcontrôleurs ARM (stm32), MAC protocol, RPL, etc.)
Calendrier prévisionnel
Travail réalisé
Récupération du code et installation des outils de compilation
Avant de commencer à programmer une application, il faut tout d'abord cloner le code source de RIOT OS depuis GitHub:
git clone https://github.com/RIOT-OS/RIOT.git RIOT
Il faudra aussi installer les outils nécessaires à la compilation et au débogage de la famille de microcontrôleurs ARM:
sudo apt-get install build-essential g++-multilib gtkterm openocd
Le paquetage g++-multilib est uniquement nécessaire si le système hôte est 64bits.
Installation des compilateurs et ses outils associés:
sudo apt-get install gcc-arm-none-eabi gdb-arm-none-eabi binutils-arm-linux-gnueabi
Prise en main de RIOT OS et STM32F4discovery
RIOT est un système d'exploitation construit autour d'un micro-noyau temps-réel, développé pour les besoins de l'Internet des objets et des réseaux sans fil. Initialement lancé en Europe par INRIA, Freie Universität Berlin, et l'Université de Hambourg en 2013, RIOT est actuellement développé par une large communauté du logiciel libre rassemblant des développeurs du monde entier.
Pour prendre à main RIOT et la carte STM32, On a commencé par réaliser une application basé sur l'exemple "hello_world" de RIOT: cette simple application "gpio_to_serial" est capable d'allumer/éteindre une led dès qu'une interruptions est générée lors qu'on appuie sur le bouton "user" et affiche l'état de la led au terminal:
2017-10-22 19:02:26,692 - INFO # GPIO Callback 2017-10-22 19:02:26,693 - INFO # Message received, LED is ON 2017-10-22 19:02:34,944 - INFO # GPIO Callback 2017-10-22 19:02:34,945 - INFO # Message received, LED is OFF 2017-10-22 19:02:35,040 - INFO # GPIO Callback 2017-10-22 19:02:35,041 - INFO # Message received, LED is ON 2017-10-22 19:02:38,184 - INFO # GPIO Callback 2017-10-22 19:02:38,186 - INFO # Message received, LED is OFF 2017-10-22 19:02:38,280 - INFO # GPIO Callback 2017-10-22 19:02:38,281 - INFO # Message received, LED is ON 2017-10-22 19:02:40,578 - INFO # GPIO Callback 2017-10-22 19:02:40,580 - INFO # Message received, LED is OFF
Cette application m'a permit de comprendre comment fonctionne le système riot et de passer à la mise en place d'un premier réseau.
Mise en place d'un réseau statique
Maintenant on vais réaliser la mise en place d'un réseau multi-point avec 3 nœuds (2 sauts); Pour que cela soit possible chaque carte ayant un module radio doit avoir son adresse ipv6 global qui va permettre d'échanger des paquets entre elles. On a défini une adresse global du type baad:a555::Hwaddr.
Le réseau statique à 3 nœuds se comporte comme un réseau linéaire avec un nœud central se chargeant uniquement de router les paquets vers la destination:
Pour mettre en place cette structure réseau, RIOT OS dispose des nombreuses fonctions telles quelles:
- ifconfig: permet configurer l'interface réseau.
- fibroute: table dynamique qui lie les adresses MAC aux ports
- pingv6: permet de tester l'accessibilité d'une autre machine à travers un réseau IP en envoyant de paquet ICMPv6
- udp: permet de démarrer un serveur udp et d'envoyer des paquets via le protocole udp sur un port prédéfini
L'exemple gnrc_networking de RIOT, permet de mettre en place la pile réseau GNRC IPv6/6LoWPAN qui est dédié à l'internet des objets. Cet exemple agit comme un routeur et permet de définir des routes statiques ainsi que d'utiliser RPL. On va donc utiliser cet exemple afin de mettre en place le réseau, il suffira de rajouter le module at86rf231 dans le Makefile.
Le node1/client, enverra des paquets avec des ordres de commande vers le node3/serveur (qui correspond au robot avec des moteurs). Ces informations vont tout d'abord passer par le node2 qui est responsable au routage de ces paquets vers le node2. Le node2 va aussi pouvoir retourner des informations vers le node1, par exemple la vitesse de rotation des roues.
Test, communication réseau
Une fois le réseau mis en place, on a fait des tests afin de voir si les cartes arrivaient à communiquer entre-elles. Les résultats ont étés satisfaisants comme le montre les figures ci-dessous:
Après on a éteint node2 et on a essayé de faire un ping à nouveau afin de tester si les paquets ne passaient pas directement du node1 vers node3, sans passer par le deuxième. D'après l'image on voit bien qu'il maintenant impossible de faire un ping:
Server/Client UDP
Tout d'abord on a démarré un serveur upd au node3:
> udp server start 12345 2017-10-22 18:30:34,250 - INFO # udp server start 12345 2017-10-22 18:30:34,252 - INFO # Success: started UDP server on port 12345
Ensuite on a envoyé un message ("test") UDP du node1 vers le node3:
udp send baad:a555::1736 12345 test 2017-10-22 18:31:30,696 - INFO # udp send baad:a555::1736 12345 test 2017-10-22 18:31:30,699 - INFO # Success: sent 4 byte(s) to [baad:a555::1736]:12345
Le message a été bien reçu par le node3, cela montre que le réseau a été bien mis en place:
> 2017-10-22 18:31:30,728 - INFO # PKTDUMP: data received: 2017-10-22 18:31:30,730 - INFO # ~~ SNIP 0 - size: 4 byte, type: NETTYPE_UNDEF (0) 2017-10-22 18:31:30,731 - INFO # 00000000 74 65 73 74 2017-10-22 18:31:30,732 - INFO # ~~ SNIP 1 - size: 8 byte, type: NETTYPE_UDP (4) 2017-10-22 18:31:30,733 - INFO # src-port: 12345 dst-port: 12345 2017-10-22 18:31:30,734 - INFO # length: 12 cksum: 0xc94b 2017-10-22 18:31:30,736 - INFO # ~~ SNIP 2 - size: 40 byte, type: NETTYPE_IPV6 (2) 2017-10-22 18:31:30,737 - INFO # traffic class: 0x00 (ECN: 0x0, DSCP: 0x00) 2017-10-22 18:31:30,738 - INFO # flow label: 0x00000 2017-10-22 18:31:30,739 - INFO # length: 12 next header: 17 hop limit: 63 2017-10-22 18:31:30,740 - INFO # source address: baad:a555::1702 2017-10-22 18:31:30,741 - INFO # destination address: baad:a555::1736 2017-10-22 18:31:30,754 - INFO # ~~ SNIP 3 - size: 24 byte, type: NETTYPE_NETIF (-1) 2017-10-22 18:31:30,755 - INFO # if_pid: 7 rssi: 21 lqi: 255 2017-10-22 18:31:30,756 - INFO # flags: 0x0 2017-10-22 18:31:30,757 - INFO # src_l2addr: 10:10:64:32:14:0f:17:32 2017-10-22 18:31:30,758 - INFO # dst_l2addr: 10:10:64:2d:14:39:17:36 2017-10-22 18:31:30,760 - INFO # ~~ PKT - 4 snips, total size: 76 byte