Projet capteurs : Différence entre versions

Version actuelle en date du 24 octobre 2019 à 08:25

Cette page est maintenue par les enseignants et utilisée par les élèves de la matière concernée. Vos contributions sont les bienvenues, mais merci d'en discuter avant de faire des modifications non triviales de la page, pour être sûr de ne pas perturber le déroulement du cours.

  Deuxième Année    Informatique 

Le but de ce projet est de s'initier aux problématiques de la programmation réseau sur des capteurs contraints, ici de la famille eZ430 à base de micro-controlleur très basse consommation Texas Instruments MSP430 et d'une radio CC2500.

Différents sujets pourront être abordés, comme la programmation d'une couche MAC de type CSMA/CA, des protocoles multi-sauts, de la localisation, etc.

Informations pratiques

• Informations sur le développement sous Linux, notamment le changement d'environnement et de compilateur : eZ430-RF2500 development on Linux
• De la documentation sur le site TI : eZ430-RF2500
• Documentation du chip radio : CC2500
• Documentation du micro-controller utilisé : MSP430F22x2, MSP430F22x4
• Documentation utilisateur : MSP430x2xx Family
• Les timers en détails : MSP430 Timers In-Depth et MSP430 Clock System and Timer
• Blog plein de bonnes infos techniques sur le MSP430 Scientific Instruments Using the TI MSP430

Code de démarrage

• Dépot git pour les sources TI modifiés : https://gitlab.ensimag.fr/rousfran/timsp430gcc
• Dépot git pour les sources modifiés inspirés des TP de Thomas Watteyne : https://gitlab.ensimag.fr/rousfran/ezwsn
• Dépôt git dun petit utilitaire pour flasher les adresses des eZ430 : https://gitlab.ensimag.fr/rousfran/ezaddrs !!! handle with care !!!

Lisez la partie Lab 2, qui contient les crash courses sur le MSP, le CC2500 et présente la carte eZ430-RF2500

• Programmer avec mspdebug rf2500 "prog led_steady"

Environnement de développement GNU pour les MSP430

Installation de msp430-gcc

Récupérer msp430-gcc chez TI à http://software-dl.ti.com/msp430/msp430_public_sw/mcu/msp430/MSPGCC/latest/index_FDS.html

Exemple d'installation rapide :

• Récupérer la toolchain pour votre OS,
  exemple msp430-gcc-8.3.0.16_macos.tar.bz2
• L'installer dans /opt,
  exemple /opt/msp430-gcc-8.3.0.16_macos
• Faire un lien générique /opt/msp430-gcc pour gérer facilement le changement de version,
  exemple ln -s msp430-gcc-8.3.0.16_macos msp430-gcc
• Récupérer les Header and Support Files,
  exemple msp430-gcc-support-files-1.208.zip
• Placer le répertoire include extrait dans /opt/msp430, à préciser à gcc à la compilation avec -I/opt/msp430/include -L/opt/msp430/include

Quelques pointeurs intéressants :

• MSP430 GCC User's guide
• GCC for MSP430 Microcontrollers Quick Start Guide
• Simply Embedded Lesson 2: Setting up the Toolchain

Installation de MSPDebug

Le plus simple est de cloner le dépôt git de MSPDebug puis le compiler, sinon utilisez votre gestionnaire de packages préféré, homebrew, apt, yum, etc.

Utilisation du lien série

Normalement les cartes doivent apparaitre sous quelque chose comme /dev/ttyACM0 une fois branchées, vous pouvez ensuite vous y connecter en utilisant minicom.

Premier test

• Clonez le repo ezWSN ci-dessus
• Vérifiez dans ezWSN/eZ430.mk que les paths sont corrects
• Branchez un eZ430 sur le port USB de votre machine
• Vérifiez que la LED s'allume bien

 cd ezWSN/3
 make clean
 make led_steady
 make flash_led_steady

• Vérifiez que la LEDclignote bien

 make all
 make flash_led_timer

Sujet

Présentation

Il va s'agir de développer un protocole multi-sauts économe en énergie très simplifié. Les principes de base sont les suivants :

• duty cycling afin d'économiser l'énergie dans le réseau, les noeuds s'endorment pour de longues périodes et se réveillent de manière synchronisée pour s'échanger des données ;
• beaconing pour maintenir le réseau en vie, les noeuds envoient des balises contenant des informations de maintenance, permettant notamment de maintenir la synchronisation ;
• en l'absence de réception, il créée un réseau en commençant à envoyer ses propres beacons ;
• routing le routage des paquets se fera au niveau 2, et pour cela les noeuds s'échangeront des tables de voisinage afin de connaître tout le réseau de proche en proche ;
• ainsi, un noeud désirant router vers une destination arbitraire saura quel sera le prochain saut à sélectionner parmi ses voisins pour se rapprocher de la destination.

Scénario

Le but final est que vous puissiez former un réseau interopérable avec tous les capteurs de tous les groupes, il va donc falloir vous mettre d'accord sur les formats de paquets. Le scénario de référence pour le fonctionnement d'un réseau est le suivant :

• les noeuds sont démarrés, rien ne se passe ;
• on actionne le bouton sur l'un des capteurs, il commence à scruter les beacons, au bout d'un certain délai il décide de créer son propre réseau qu'il identifie à l'aide d'un identifiant numérique ;
• les autres noeuds sont alors démarrés de la même manière, et ceux en zone de portée reçoivent le beacon, ils s'associent alors à ce nouveau réseau ;
• les nouveaux membres du réseau synchronisent leur duty cycle sur celui en place et propagent à leur tour les beacons ;
• si deux réseaux différents collisionnent on gardera celui ayant le plus petit identifiant, un réseau sera donc absorbé par l'autre ;
• on peut alors générer l'envoi de paquets à des destinations arbitraires et vérifier que le paquet est acheminé, éventuellement en plusieurs sauts ;
• afin de se laisser du temps pour observer les envois et réceptions, un paquet reçu génèrera l'envoi d'un autre paquet dans le cycle suivant et non immédiatement.

Consignes

• il n'y a pas vraiment de doc pour MRFI, il faut donc regarder les sources, commencez par timsp430gcc/mrfi/mrfi.h par exemple ;
• vous pouvez commencer le projet en utilisant uniquement le broadcast, mais il faudra ensuite régler le problème des adresses MAC pour faire de l'unicast (nous allons vous proposer une solution, ça n'a pas l'air si trivial pour faire ça sans s'embêter de trop);
• choisissez des canaux distincts et éloignés, un par groupe (MRFI_SetLogicalChannel) ;
• changez la puissance d'émission pour réussir à faire du multi-sauts (MRFI_SetRFPwr) ;
• utilisez les LED pour "voir" ce qu'il se passe dans le réseau, vous pouvez changer la sémantique au cours du projet, par exemple au début rouge = TX vert = RX, puis lorsque vous ferez le routage rouge = TX initial ou RX final et vert = RX/TX du relayage du paquet ;
• en cas d'ambigüité, discutez entre vous et proposez une solution ou faites-nous en part, il faut une spécification unique pour avoir l'interopérabilité finale ;
• pour envoyer des paquets à des destinations arbitraires, accordez-vous entre tous les groupes et assignez une lettre du clavier à chacun des noeuds, comme cela vous pourrez facilement générer l'envoi de paquet à une destination donnée à partir d'une entrée clavier sur la ligne série.

Éléments de spécification

• durée d'un cycle
• durée d'un scan
• durée de la période active
• durée d'un slot : les beacons seront envoyés dans dans des slots temporels situés au début de la période d'activité
• nombre de slots de beaconing : l'envoi des beacons se fera sans directement à l'instant prévu (MRFI_TX_TYPE_FORCED)
• carrier sense : l'envoi des autres paquets se fera dans le reste de la période active (MRFI_TX_TYPE_CCA)
• adressage : pour simplifier les choses, nous allons allouer des adresses séquentielles à tous vos capteurs, de 1 à n, chaque capteur enverra son beacon dans le slot correspondant à son adresse, sauf pour l'initiateur du réseau qui utilisera le slot 0

Conduite du projet

Quelques directions pour vous guider dans le déroulement du projet :

• vous accorder sur les formats de paquets et les divers paramètres (beacons, voisinage, routage, etc.)
• utiliser les timers pour gérer le duty cycle et les slots
• gérer la synchronisation entre deux noeuds à l'aide des beacons envoyés en broadcast
• gérer l'envoi de paquet d'information de voisinage en broadcast
• gérer l'envoi de paquets unicast entre voisins à un saut
• mettre en place le routage multi-sauts de niveau 2

Protocole

Plus d'infos sur l'intranet : KIOSK

Format de trames

Pistes de réflexion sur le format des trames. L'idée est de partir du format donné par MRFI :

Avec payload de taille maximale 53 Bytes.

On ajoute un octet de flags.

Flags

• 0x1 = BEACON BIT : Si à 1 il s'agit d'une trame beacon.
• ...

Beacon frame

Les trames dont le BEACON BIT est positionné à 1 auront un format strict et spécial. La trame devra contenir :

• 8 bits : Un numéro de réseau
• 8 bits : Le numéro du slot actuel

Remarques

Il est important que la durée de scan soit importante (minimum 2 duty cycles) afin d'être sûr de ne manquer aucun beacon.

Header Commun

#ifndef __COMMON_DEFINES_H__
#define __COMMON_DEFINES_H__
#include <mrfi.h>
// Definition des adresses
#define ET_1 0x1
#define ET_2 0x2
#define ET_3 0x3
#define ET_4 0x4
#define ET_5 0x5
#define ET_6 0x6
#define KH_1 0x7
#define KH_2 0x8
#define KH_3 0x9
#define KH_4 0xA
#define VB_1 0xB
#define VB_2 0xC
#define VB_3 0xD
#define VB_4 0xE

// Definition des flags
#define FDATA 0x0
#define FBEACON 0x1

// en ms
#define DUREE_CYCLE 500
// en ms
#define DUREE_SCAN 1000
// en ms
#define DUREE_ACTIVE 200
// en ms
#define DUREE_SLOT 2
// 32 slots ?
#define N_SLOT 32

typedef struct
{
	uint8_t length;
	uint8_t src[4];
	uint8_t dst[4];
	uint8_t flags;
	uint8_t data[MRFI_MAX_FRAME_SIZE-10];
} mPacket;

typedef struct
{
	uint8_t network_num;
	uint8_t slot_num;
	uint8_t slot_total;
} mBeacon;

#endif

Groupes 2011

• Romain BITSCHENÉ et Philippe VIROULEAU
• Hervé EBLOHOUE et Tuan Hiep TRAN
• Yongkan HUANG et Mohamad KANJ

Enseignant

Franck Rousseau