IMA5 2018/2019 P16 : Différence entre versions
(→Verification) |
(→Documents Rendus) |
||
| (4 révisions intermédiaires par le même utilisateur non affichées) | |||
| Ligne 314 : | Ligne 314 : | ||
jet, notamment sur la programmation des cartes (en utilisants les NUCLEOs) | jet, notamment sur la programmation des cartes (en utilisants les NUCLEOs) | ||
et la mise en place des trames Xbee | et la mise en place des trames Xbee | ||
| + | |||
| + | |||
| + | === Creation SHIELD pour NUCLEOS === | ||
| + | |||
| + | L'objectif est de permettre de pouvoir connecter les Nucleos aux modules Xbee et de proposer une certaine solidité de l'ensemble : | ||
| + | |||
| + | L’avantage des NUCLEOS est qu’elles respectent le écartement standard, et que les convention de placement des broches sont les mêmes sur que les Arduinos (Uno pour la NUCLEO L152RE et Nano pour la L031K6). Il est donc assez aisé de créer des boucliers. | ||
| + | |||
| + | [[Fichier:Photo_shields.jpg|400px]] | ||
| + | |||
| + | [[Fichier:Appairage_nucleo.mp4]] | ||
| + | |||
| + | La connectique minimale nécessaire aux modules Xbee dans un usage UART classique ne se limite qu'à l'alimentation (3V3) du module, ainsi que la connexion des broches TX/RX. Afin de permettre un certain contrôle du module en cas de problème j'ai également relié la broche de Reset à une sortie digitale. Je relie également trois autres sorties digitales à des LEDs afin de proposer un affichage visuel du fonctionnement des cartes | ||
| + | |||
| + | === Redefinition des trames Xbee === | ||
| + | |||
| + | [[Fichier:TramesXbee.jpg||600px]] | ||
| + | |||
| + | Un octet de start et un de stop permettent de délimiter les trames pour vérifier que la chaîne est bien arrivée en entière. Un octet pour l'ID de la source et de la destination du message (Le nombres d'élément par canal Xbee ne devrait pas être aberrant, un seul octet suffit amplement). | ||
| + | |||
| + | La taille de la trame qui permettra aussi de vérifier qu'aucune données n'a été perdu en route. Il s'agit du même usage pour le CRC. | ||
| + | |||
| + | Puis vient la commande indiquant la raison du message, suivie des données l'accompagnant. voici la liste possible des commandes : | ||
| + | *0 Envoi d’un ACK | ||
| + | *1Initialisation d’une base mobile | ||
| + | *2 Déclaration d’un nouveau module | ||
| + | *3 Fin d’initialisation d’une base mobile | ||
| + | *4 Rendre une base mobile active | ||
| + | *5 Rendre une base mobile inactive | ||
| + | *6. Initialisation d’un module | ||
| + | *7. Demande de données | ||
| + | *8. Réponse à une demande de données | ||
| + | *9. Fin d’initialisation d’un module | ||
| + | *10. Déclaration des types de données au moniteur | ||
| + | *11. Envoi des données au moniteur | ||
=Documents Rendus= | =Documents Rendus= | ||
| Ligne 322 : | Ligne 357 : | ||
[[Fichier:CR_PFE16_2019_Final.pdf]] | [[Fichier:CR_PFE16_2019_Final.pdf]] | ||
| + | |||
| + | |||
| + | Liens vers le [https://archives.plil.fr/mdelobel/Programme_PFE gitlab] | ||
Version actuelle datée du 7 mars 2019 à 00:04
Sommaire
- 1 Présentation générale
- 2 Préparation du projet
- 3 Réalisation du Projet
- 4 Documents Rendus
Présentation générale
Description
Le sportif amateur ne dispose que de peu de retour quant à ses performances, notamment lors des entraînements. Dans les sports collectifs, le seul retour possible provient des entraîneurs, qui eux-même ne disposent pas de données chiffrées.
Nous proposons de réaliser un ensemble de capteurs permettant de :
- Mesurer différents paramètres du sportif ; - Collecter ces informations au niveau d\'une base (portée par le sportif) ; - Transmettre ces informations à une base posée sur le bord du terrain.
Une version légèrement modifiée des capteurs pourra être disposée sur le terrain, voire dans les ballons.
Objectifs
Concevoir et réaliser des objets connectés permettant de mesurer les performances sportives et d'adapter l'entraînement
Il sera necessaire de mettre en place differents système pour y parvenir :
- Un réseau de capteur placés sur le sportif, connectés à une base plus puissante accrochée sur son dos/sa ceinture : Base Portable (BP) - Un réseau de capteur placés sur le terrain (plots/cerceaux/balises) afin de verifier la bonne réalisation des exercices - Une base posée sur le bord du terrain (PC/Tablette) qui récuperera les données et permettra un affichage : Unité de controle (UC) - Une communication entre la BP sur le sportif et l'UC
Préparation du projet
État de l'art
Analyse des concurrents : FitBit
Fitbit est une société américaine fondée en 2006 qui conçoit et vend des équipements connectés. La force de leur produit est leur facilité d’utilisation en plus de leur grande inter-compatibilité avec différents moniteurs grâce à la technologie ANT+. Cependant ces produits coûtent une certaine somme, et ne propose qu’un panel réduit de données récoltables. En général ces derniers ne mesurent que la température, le rythme cardiaque ou les calories dépensées de l’utilisateur, mais en aucun ne permettent de monitorer ses performances
Analyse des concurrents : Strava
Strava est un réseau social de fitness, utilisant des données GPS dans le cadre de la course à pied, du cyclisme et de la natation afin de récolter les performances des utilisateurs. Ainsi chaque utilisateur peut, grâce aux cartes mis en place sur le site/l'application mobile, voir les trajets parcourus, l'evolution des performances au fil du temps et se comparer avec les autres utilisateurs parmis une selection
Ces données sont recoltées à partir de dispositifs tiers, tels que les bracelets/montres FitBit mais également parmis une plus grande liste de devices
Cahier des charges
- Concevoir une architecture réseau permettant la récolte des données jusqu’au PC
- Définition de la typologie du(es) réseau(x) utilisé(s)
- Définition des technologies utilisées
- Définition du protocole de communication et des trames
- Réaliser les différentes cartes nécessaires au fonctionnement de l’architecture réseau
- Cartes de prototypage afin de valider le modèle et faire fonctionner les différents modules de communication
- Conception des PCB intégrant les modules
- Fabrication des packagings
- Proposer une application sur PC afin de pouvoir visualiser les données
Choix techniques : matériel et logiciel
Choix de techno de communication sur le sportif
Afin de mettre en place la recolte de données issues des performances du sportif, il sera necessaire de mettre en place un système de communication a courte portée (environ 2 mètres) afin d'envoyer les données récoltées par les différents capteurs (acceleromètres, ECG, thermomètre, giroscope...) avec la base qui sera portée par le joueur dans son dos, ou à la ceinture (afin de ne pas trop le gener). Pour ce faire, plusieures technologies sont disponibles et pourraient permettre la mise en place d'une telle communication, il faut donc en choisir une pour se fixer..
802.15.6 : Body Area Network
Nouveau standard pour les communications à courte portée (echelle humaine), beaucoup de recherche encore sur le protocole, très peu de board de developpement, et certaines assez cher. Plusieur techno possibles : extra, over et intra body.
- Extra : Communication RF via des protocoles de com a 2,4Ghz a faible consommation de courant - Over : Communication filaire placée directement sur l'utilisateur ou sur/dans ces vêtements - Intra : Communication en utilisant le corps humain comme couche physique, encore très expérimental mais beaucoup de recherche sur le sujet
802.15.4 : Zigbee
L'avantage du reseau Zigbee est qu'il est très facile a utiliser (et que j'ai deja utilisé plusieur fois la technologie), cependant il est assez consommateur d'energie (environ 50mA à la transmission), ce qui dans notre cas ne pourra pas etre envisagé, car l'autonomie du système sera un point très important du projet
BLE
Le BLE est tout a fait envisageable car il propose - comme son nom l'indique - une communication basse consommation d'energie.
ANT
ANT+ est un protocole de communication sans fil, similaire au BLE, designé specifiquement pour l'envoi de données issues de capteur mais également pour monitorer certain systèmes (notamment en domotique). Il a l'avantage d'être specifiquement désigné pour les équipements sportifs, à tel point que beaucoup de dispositifs fonctionnent aujourd'hui avec. On retrouve notamment les bracelets et montre du style FitBit, mais également plusieurs applications comme des cardiogrammes...
Radio 'simple'
On peut également partir sur de petites radios proposant un courrant d'emission tres faible (2mA), mais il refaudra faire tout l'étage de modulation, de démodulation et d'encodage de l'information, ce qui peut rajouter un travail de conception non négligeable. Cela pourra etre interessant pour un modele final, afin d'optimiser le systeme
Choix retenu
Je me focaliserai sur le protocole ANT en essayant de mettre en place un support a differents device disponible sur le marché, afin que le système global puisse être utilisés avec des produits déjà existant. Je dispose d'ailleurs déjà d'une ceinture Cardiofrequencemetre de la marque Polar (Il ne s'agit pas d'une communication avec ANT mais d'une "simple" communication via un champ magnétique)
Faute de matériel, de documentation et de soucis de commande avec DigiKey... je passe sur du BLE
Choix de techno de communication sur le terrain
802.15.4 : Zigbee longue portée (~100m)
Le Zigbee permet également une communication assez longue portée lorsqu'il est utilisé en espace ouvert (~100m), et propose un consommation
Wi-Fi
L'utilisation du Wi-fi est envisageable de par l'utilisation du signal en espace ouvert (stade/salle de sports) permettant ainsi de limiter les absorptions/reflections dues aux murs. Cependant le Wifi est très consommateur d'energie de part le fait que ce protocole propose un très grand débit, que l'on ne pourrait pas exploiter complètement
Choix retenu
Je partirai sur des modules Xbee pour la communication longue portée, ils ont l'avantage d'etre assez simple d'utilisation, et permettront de ne pas perdre de temps. (J'ai pu deja travailler avec lors de mon projet IMA4)
Reseau global
Deux réseaux en étoile, un sur le joueur entre la base et les différents capteurs, un autre du PC aux différents joueurs.
Réalisation du Projet
Semaine 1
essais fonctionnement shield arduino olimex + Electrodes
Semaine 2
recherches sur le protocole ANT+ et son implem via un atmega328P / MSP430
Il sera interessant d'obtenir un module du style : [1] pour les tests
Il est possible de se procurer directement le [2] RF (datasheet) a embarqué sur un PCB apres coup, mais cela sera plus complexe a mettre en place pour le prototype puisqu'il faut remettre en place l'antenne comme le montre la figure 6 de la datasheet :
Recherches de modules compatibles Ant+ https://www.digikey.com/product-detail/en/garmin-canada-inc/ANTAP281M5IB/1094-1004-ND/2748494
Info sur la ceintures :
http://arduino-projects4u.com/rmcm01/
https://www.reddit.com/r/electronics/comments/10oct3/polar_heart_rate_monitor_chest_strap_arduino_cant/ (Champ magnétique 5Khz Oo" ?)
Datasheet du rmcm01 permettant d'interfacer avec la ceinture (selon le constructeur)
Sur Adafruit : kit de dev de test de la ceinture T34 https://www.adafruit.com/product/1077
Apres beaucoup de recherche, en vain, afin d'obtenir des informations sur des modules compatibles avec la ceinture T31 de polar, une information a illuminé l’intérêt de mon PFE, comme le dit les avis - très - positifs sur le composant, qui n'est plus disponible, permettant d'interfacer la ceinture à une arduino :
"In addition to working on humans, the Polar T31 transmitter can be strapped to a cow." @Member #322613, Source
====> Problem solved avec la seconde partie du kit de test de la ceinture !! :D
Datasheet du receiver compatible avec la ceinture
Suite du travail
https://www.digikey.com/en/product-highlight/s/stmicroelectronics/stm32-overview
recherches circuit embarqué (capteur): STM32L0 / F0 ? (Cortex M0) : https://www.digikey.com/product-detail/en/stmicroelectronics/STM32L031K6T7/497-16269-ND/5805501 (L : low power // F : fast ==> On s'interesse principalement a une faible conso, on prendra donc le modele L)
24 MHz Quartz (+ capa) Le STM32L0 embarque un oscillateur RC (HSI) de 16 MHz (source : page 23 de la datasheet
https://www.sciencezero.org/index.php?title=STM32L031K6_Microcontroller
Depuis le schéma de la carte NUCLEO-L031K6 (carte de developpement qui embarque un STM32L0) on défini l'environnement passif minimal necessaire au MCU.
- Capa 100 nF sur le reset pour stabilité du signal (eviter des resets intempestifs) - Capa 200 nF sur VDD (Capa decouplage sur l'alim) - Capa 100 nF sur AVDD (Tension reference a l'ADC) - 10K resistor entre le pin BOOT0 et la masse afin de set le PIN à l'etat 0 afin de choisir un boot depuis la flash
Afin de reprogrammer le STM32L0 : "The boot loader is located in System memory. It is used to reprogram the Flash memory by using SPI1 (PA4, PA5, PA6, PA7), USART2 (PA2, PA3) or USART2 (PA9, PA10). See STM32™ microcontroller system memory boot mode AN2606 for details"
recherches base embarquée : La base recevra les données de tous les capteurs embarqués sur le sportif, et devra decoder les différentes trames, afin d'en reconstruire une globale après. Il sera donc necessaire d'avoir un MCU un peu plus puissant.
STM32L1 (Cortex M3 : datasheet) : https://www.digikey.com/product-detail/en/stmicroelectronics/STM32L100RBT6/497-13631-ND/3973519
Selon la carte NUCLEO-L152, l'environnement passif du MCU est similaire a celui du STM32L0, cependant la capacités de découplages est un peu plus grande : elle passe a 400nF.
Commande matos farnell/mouser
Suite a un probleme de commande sur digikey.. voila les composants commandées mais chez farnell, avec quelques ajouts
LED RVB * 5
Xbee Module *2
BLE Module *4 (ou ce module plus petit mais plus cher) Il sera pas possible de les souder au four, mais ca devrait pas trop poser de probleme a la main, pads a 0.7mm pour le plus grand)
Module protection USB (pour faire une carte de programmation)
Resistance 22 Ohm (Adaptation USB) *10 (qtt mini)
Connecteur USB B Micro Femelle a souder *2
Changement de techno
Ayant pas mal de difficulté a trouver de bon module ANT utilisable rapidement, et quelques problemes de livraison de matériel, je décide donc de changer de techno de communication courte portée. Voulant respecter l'objectif de la basse consommation en energie du systeme, je m'oriente vers le BLE.
Avec un peu de recherche, on se rend compte que le BLE propose plusieur typologie de réseau, dont un réseau en étoile, qui pourrait être compatible avec notre objectif. En effet, on souhaite connecter la base portable (centre de l'étoile) aux differents capteurs (extremités) placés sur le joueur
https://blog.groupe-sii.com/le-ble-bluetooth-low-energy/
Trames
Trame capteur vers base
Le BLE propose un débit de 1Mbps, vu la taille de la trame, on pourrait proposer plus de 1000 mesures par secondes.. A voir cependant l'implementation logicielle et le temps de traitement
Correction : BLE a une trame de max 20 octets dans la norme 4.1.. Il faudra supprimer une donnée max afin que cela tienne
Trame base vers PC
Le Xbee imposant des trames d'une taille inférieure à 80 octets, cela pourrait donc correspondre.
Librairie Altium pour module BLE
Creation de la librairie sur Altium afin de pouvoir travailler avec les modules BLE
Essais de fonctionnement des modules
Les modules BLE fonctionnent (je les detecte grace à mon telephone) Cependant pas moyen encore via l'appli CypressSmart de changer leur config (Ils sont en mode GATT server par défaut, il faut pouvoir en passer un en client afin qu'ils communiquent entre eux)
Programmation des NUCLEOS
Galere a reprogrammer... stm32flash ne répond pas, incapable d'écrire sur le port. Essais d'utilisation de plusieur toolchain trouvée sur github en vain..
En fait y'a un gestionnaire de fichier... (trouvé par hasard en ouvrant Dolphin..) il suffit de monter la NUCLEO comme une clé USB et d'y coller le *.bin du programme
Utilisation de mbed OS
mbed OS est un projet open-source géré par ARM, permettant de reprogrammer des cortex-M plus facilement. Appli IDE windows only, mais il existe une version navigateur.. => permet d'extraire un projet avec la toolchain et un makefile !! :D
Realisation premier PCB
Je réalise dans un premier temps une carte prototype permettant de vérifier que l'environnement passif du STM32L0 (Cortex M0+) que j'ai défini suffit. Si j'arrive a reprogrammer le MCU, je pourrais donc réaliser des cartes plus complexes.
Schematics / PCB sous ALTIUM
Dans un premier temps, je réalise le schematics de la carte sous Altium. Pour se faire, je me suis grandement inspiré des schematics open source de la NumWorks et de la carte de prototypage NUCLEO-L031K6 (qui embarque le même MCU que moi)
J'ai pu en déduire un environnement "minimal" pour le controlleur :
Comme indiqué dans la datasheet du composant. Il n'est pas possible de brancher une horloge HSE (du style 16MHz), il faut donc brancher un cristal 32.768KHz qui servira de clock de reference au multiplicateur d'horloge interne au MCU.
Un découplage de 100nF au borne des deux pins VDD et du pin VDDA (c'est ce qui est fait sur la NUCLEO.
Le BOOT_0 relié à la masse via une résistance 10kOhm (on utilisera ici un header 2*1 afin de changer permettre de changer l'état du BOOT_0 si necessaire..)
La programmation du MCU se fait en SWD (Serial Wire Debug), car le MCU n'integre pas les fonctionnalités JTAG. Il faut donc ressortir les pins d'alimentation, le NRST et SWDIO/SWCLK vers des broches afin de pouvoir programmer le composant.
Erratum : Les pins VSS du composant doivent être à la masse --> corrigé sur la carte envoyée pour tirage.
J'ai pu donc réaliser le PCB de ce schematic.
Globalement la carte est assez petite, il n'y a pas grand chose dessus. J'ai connecté tous les ports inutilisés du MCU a des broches afin de pouvoir réaliser des tests si la carte fonctionne... et peut être comprendre quelque chose si elle ne marche pas !
Erratum : Les pins VSS du composant doivent être à la masse --> corrigé sur la carte envoyée pour tirage.
Fabrication
Apres verification par M. Boé et vérification par Thierry, la carte a été envoyée en tirage. Comme prévue, elle est assez petite (USB-A pour echelle)
Il semble y avoir eu un petit soucis au niveau du tirage. Si l'on regarde bien, les pistes en haut a gauche du composant (broches 30 et 31) sont plus fines que les autres pistes... Cela n'entache pas le fonctionnement de la carte. Mais il faudra faire attention lors des soudures de ne pas arracher une piste malencontreusement...
Premiere étape : le passage au four à refusion !
J'ai fait l'erreur de mettre un peu trop de pate aux bornes du MCU et sur une des capa du quartz. Pour le MCU, j'ai du repassé à la main avec un fer et de la tresse afin de rectifier les connectiques en enlevant le surplus d'étain. Concernant la capa, après vérification au multimètre, le surplus d'étain n'a pas entrainé de court-jus : pas de problème donc !
J'avais oublié une capa au niveau du reset.. (on peut le voir a gauche) : j'ai donc du la faire moi même, rien de bien compliqué. On met en place la capa, on la tient correctement avec une pince brucelle inverse, un peu de pate d'étain sur les pins de la capa, et on chauffe avec le soudeur à air chaud.
Apres cela, je peux donc souder toutes les barretes de pins à leur emplacement, tout en faisant attention aux pistes qui ont été fragilisées.
Connecteur JTAG -> SWD
Afin d'éviter d'avoir a mettre un port de connectique JTAG (necessaire afin d'utiliser les programmateurs STLINK-V2) alors que je n'ai besoin que de 5 broches, je réalise un circuit annexe permettant de récuperer les 5 pins que j'ai besoin, tout en reliant les autres pins a la masses (ou en les laissant non connectés) comme indiqué dans la datasheet (page 12) du STLINK-V2
Verification
Malgré des contacts électriques assurés, et les essais d’utilisation de la carte en utilisant un JTAG STLINK-V2 ouun JLINK de chez Segger, je n’ai réussi a détecter ma carte afin de la programmer. Elle a donc été confiée a M. BOE pour qu’il l’expertise.
En attendant je me suis donc concentré sur la partie informatique du pro-
jet, notamment sur la programmation des cartes (en utilisants les NUCLEOs)
et la mise en place des trames Xbee
Creation SHIELD pour NUCLEOS
L'objectif est de permettre de pouvoir connecter les Nucleos aux modules Xbee et de proposer une certaine solidité de l'ensemble :
L’avantage des NUCLEOS est qu’elles respectent le écartement standard, et que les convention de placement des broches sont les mêmes sur que les Arduinos (Uno pour la NUCLEO L152RE et Nano pour la L031K6). Il est donc assez aisé de créer des boucliers.
La connectique minimale nécessaire aux modules Xbee dans un usage UART classique ne se limite qu'à l'alimentation (3V3) du module, ainsi que la connexion des broches TX/RX. Afin de permettre un certain contrôle du module en cas de problème j'ai également relié la broche de Reset à une sortie digitale. Je relie également trois autres sorties digitales à des LEDs afin de proposer un affichage visuel du fonctionnement des cartes
Redefinition des trames Xbee
Un octet de start et un de stop permettent de délimiter les trames pour vérifier que la chaîne est bien arrivée en entière. Un octet pour l'ID de la source et de la destination du message (Le nombres d'élément par canal Xbee ne devrait pas être aberrant, un seul octet suffit amplement).
La taille de la trame qui permettra aussi de vérifier qu'aucune données n'a été perdu en route. Il s'agit du même usage pour le CRC.
Puis vient la commande indiquant la raison du message, suivie des données l'accompagnant. voici la liste possible des commandes :
- 0 Envoi d’un ACK
- 1Initialisation d’une base mobile
- 2 Déclaration d’un nouveau module
- 3 Fin d’initialisation d’une base mobile
- 4 Rendre une base mobile active
- 5 Rendre une base mobile inactive
- 6. Initialisation d’un module
- 7. Demande de données
- 8. Réponse à une demande de données
- 9. Fin d’initialisation d’un module
- 10. Déclaration des types de données au moniteur
- 11. Envoi des données au moniteur
Documents Rendus
Fichier:CR PFE Intermediaire.pdf
Fichier:Presentation PFE Intermediaire.pdf
Fichier:CR PFE16 2019 Final.pdf
Liens vers le gitlab
