Save the Rhino
Sommaire
Cahier des charges - Système d’alerte SMS contre le braconnage des rhinocéros
Présentation
Ce projet consiste à concevoir un dispositif capable d'alerter un centre de secours si un animal est reconnu mort. Il sera utilisé en Afrique du Sud pour prévoir la diminution rapide du nombre de rhinocéros dans le pays, victimes du braconnage. On créera donc un système défini en deux parties :
- L'une située à l'oreille de l'animal, ayant comme rôle de détecter l'état (vivant ou mort) de l'animal.
- L'autre accrochée à la jambe de l'animal doit recevoir cette donnée, l'analyser et agir en conséquence. Cette balise devra également transmettre une fois par jour et en cas de mort envoyer la position du rhinocéros.
Les différents modules sont représentés ci-dessous :
Cahier des charges
Les différents modules auront pour rôle de :
- Détecter l'état de l'animal à l'aide d'un capteur de vie
- Analyser les données du capteur et les transmettre par liaison radio
- Réceptionner la liaison radio
- Détecter la position GPS du rhinocéros
- Envoyer l'état de l'animal ainsi que sa position GPS en temps voulu (une fois par jour et si le capteur de vie indique la mort du rhinocéros), et ce par émission GSM
Dans un sens plus général, le système devra :
- Se réveiller au moins une fois par jour et lorsque le capteur change d'état. On pourra agir par interruption ou par scrutation.
- Assurer une durée de vie de deux ans minimum
- Peser moins de 50kg
- Résister à une forte pression correspondant au poids d'un rhinocéros
Si les contraintes essentielles sont respectées et que nous disposons du temps nécessaire, nous nous intéresserons aux options suivantes :
- La fiabilité de la transmission pourra se vérifier grâce à un acknowledge ou un code correcteur
- Un détecteur de brouilleur pourra être mis en place.
- Un système d’alimentation du capteur de vie devra être proposé.
- Un système de détection de batterie faible pourra s’avérer utile pour prévenir de l'arrêt du système. Une batterie de secours pourra également être intégrée pour continuer à émettre en cas de dysfonctionnement de la batterie principale, ou retard dans le processus de changement de celle-ci.
Ressources nécessaires
Pour répondre aux besoins principaux du projet, nous devrons disposer de :
- Carte Arduino Uno ou Méga en fonction des besoins en liaisons d'entrées sorties des modules : GPS... -reçu
- Module GPS (compatible Arduino) -reçu
- Module GSM (compatible Arduino) -reçu
- Real Time Clock -reçue
- Emetteur, Récepteur 433MHz (TR3000 (RFM)) -reçu
- Voltmètre - disponible
Ressources optionnel
Si nous pouvons entretenir le projet jusqu'au bout, nous pourrons utiliser :
- Capteur de vie
- Panneau solaire
- Batterie capteur
- Batterie Arduino (grosse capacité)
- Accéléromètre
- Coque de protection (test de qualité de transmission et de pression)
Méthodologie envisagée
Afin de répondre à ce cahier des charges, nous avons opté pour une séparation des différents modules. Nous travaillerons donc chacun d'entre eux séparément, puis nous adapterons les modules les uns par rapport aux autres. Il existe 5 parties différentes du système à traiter :
- Le capteur de vie (dont nous ne disposerons peut être pas avant la fin du projet)
- La transmission radio
- La détection de la position GPS
- L'envoi de messages
- Le réveil du système sur interruption de la RTC
Suivi du projet
Semaine 1
Lors de cette semaine, nous avons étudié le sujet et rédigé le cahier des charges. Nous avons également travaillé à découper le projet en sous projet, comme on peut le voir ci-dessus.
De ce découpage, nous avons travaillé à établir un algorithme par bloc du programme afin d'établir les spécifications et limites de notre système, ainsi que les points critiques qu'il faudra prendre en compte dans notre programme. Comme la contrainte de consommation qui impose d'utiliser les fonctionnalités de l'arduino au minimum (exemple :mettre placer les pins digitaux en pull up, afin que ceux-ci ne consomme pas d'énergie.
Nous avons également lu les documents (datasheet, code) concernant les modules que nous avons reçu peu de temps plus tard. afin de pouvoir commencer le développement le plus rapidement possible.
Semaine 2
Nous avons reçu le matérielle nécessaire pour commencer le projet :
- L'arduino
- Le shield GSM
- Le shield GPS
Fabien Violier s'est chargé de l'étude et le développement du shield GSM. Mélanie Hautecoeur s'est chargé de l'étude et le développement du shield GPS.
Partie GSM
Lors de cette semaine, j'ai continué d'étudier les codes de Bastien Challo (précédent IMA4 ayant travaillé sur un shield GSM similaire), ainsi que la liste des commandes AT disponible ici :
Et j'ai réécris le code Arduino de cet ancien projet en C. Malheureusement, ceci ne fonctionnait pas, le shield ne répondant pas du tout aux appels de mes instructions.
Partie GPS
Pour la détection de la position GPS, nous avons disposé du shield GPS DS_GPM. La première partie du travail sur ce module a consisté à bien lire la datasheet. Etape triviale, mais très importante quant à la façon de programmer ce dernier. J'ai donc pu m'apercevoir que la communication avec le shield s'effectuait par liaison I2C. N'ayant jamais utilisé ce protocole, je me suis beaucoup documenté sur ce dernier. Afin de limiter la place ainsi que la consommation énergétique de l'Arduino, j'ai décidé de programmer l'accès aux registres en C.
J'ai alors commencé par chercher si un tel code existait déjà, afin d'éviter une perte de temps inutile, en vain. La programmation en I2C de ce genre de shield s'effectue généralement en langage Arduino.
Semaine 3
Partie GSM
Lors de cette semaine, j'ai essayé déboguer mon programme de gestion du shield. Cependant, je me confronte toujours au même problème, le shield ne répond toujours pas aux instructions envoyées.
Afin de corriger le problème, je continue d'étudier le code Arduino. Mais les nombres de librairies utilisées rendent la compréhension du code très complexe.
Partie GPS
La programmation ne s'est alors pas avérer si facile. J'ai alors pris connaissance du protocole utilisée pour la lecture de registre sur le DS_GPM :
J'ai alors récupérer les quelques instructions fournies dans la documentation de l'ATMega328p concernant les registres de la communication I2C. Après avoir analysé chacune d'entre elles, je les ai fonctionnalisées afin de les rendre plus faciles d'utilisation. J'ai, par exemple créer la fonction d'envoi d'adresse, de registre, la fonction d'envoi de start, etc... J'ai ensuite testé quelques unes de mes fonctions sur le shield. Je n'ai, à cet instant, pas pu recevoir d'informations venant du module.
Semaine 4
Partie GSM
Lors de cette semaine, J'ai testé le bon fonctionnement du shield GSM, j'ai donc compilé et chargé le code constructeur sur l'arduino.
Résultat :
Le shield fonctionne correctement. c'est donc bien la communication qui posait problème.
J'ai donc continué d'étudier la documentation fourni par le constructeur Quectel du module de gestion du shield GSM sur les commandes AT.
A la fin de cette semaine, nous commençons à envisager d'utiliser le code arduino car le temps passe et d'autre module du système doivent être développé.
Partie GPS
J'ai décidé d'insérer dans mon code les modifications nécessaires pour le débogage. Pour cela, j'ai envoyé sur le port série les différentes étapes et les erreurs rencontrées. La première erreur venait de l'adresse, dans laquelle je m'étais trompée. Une fois la bonne adresse trouvée, je pouvais envoyer l'adresse et le registre d'accès mais la programme indiquait une erreur lorsque j'essayais de lire ou d'écrire. J'ai alors étudié le registre de statut étape par étape afin de comprendre le problème. Pour cela, j'ai consulté la documentation de l'ATMega328p sans oublier d'ôter les bits de prescaler du registre. En effet, lors de l'envoi du deuxième start, celui-ci n'est pas un vrai start mais un restart, ce qui ne correspond pas à la même réponse du shield. J'ai alors réussi à écrire dans les registres inscriptibles.
Semaine 5
Partie GSM
Lors de cette semaine, nous avons reçu un Arduino Mega afin d'utiliser le code Arduino fourni avec le shield GSM. Dans le même temps un camarade nous a passé un dongle USB permettant de sortir des pins Rx et Tx du port USB et ainsi de communiquer avec le shield directement sans passé par l'Arduino. J'ai également pu voir le protocole de communication du programme Arduino livré avec le shield et compléter le protocole de configuration de mon code C.
J'ai donc repris le protocole de communication de mon programme précèdent, fort de ma réussite dans la configuration du shield via minicom.
A la fin de cette semaine j'ai pu envoyer un SMS par l’intermédiaire de minicom, ainsi que par mon code écrit en C.
Partie GPS
J'ai alors pu m'intéresser à la lecture des registres, qui ne fonctionnait pas encore. Cette procédure m'a d'abord posé problème car la réponse du GPS avant de commencer l'accès aux registres de latitude et de longitude ne correspondait pas à celle que j'attendais. Cette réponse provoquait donc une erreur dans mon code. J'ai alors recherché ce qu'indiquait le registre de statut, qui montrait en fait un changement de mode du GPS de l'écriture vers la lecture. La réponse du shield était donc normale, mais mon code nécessitait quelques modifications, et j'ai pu adapter toutes les valeurs de réponse du module. L'accès aux registres devenait donc possible, cependant ceux-ci ne contenait que des zéros, mon code devait alors être erroné.
Semaine 6
Partie Annexes
Lors de cette semaine, j'ai étudié la fonctionnalité du watch dog sur l'Arduino. Cette fonctionnalité permettant de mettre en veille le microprocesseur pendant un temps donnée. J'ai ainsi pu développer des fonctions qui seront utilisé plus tard dans le programme principal.
J'ai également étudié un système permettant de mesurer le niveau de charge de la batterie afin de détecter une éventuelle décharge de la batterie ou dysfonctionnement et dans notre cas d'envoyer une alerte par SMS pour prévenir la fin de vie de notre système. Cependant, le code de test de l'état de la batterie n'a pas été testé.
Partie GPS
Après avoir vérifié mon code plusieurs fois et effectué quelques tests, j'ai décidé de tester un code Arduino afin de vérifier que le problème n'était pas matériel, et le résultat indiquait bien que les registres de positions ne contenaient que des valeurs nulles. J'ai ensuite réutilisé mon code afin de pouvoir regarder l'ensemble des registres. Tous était nuls sauf deux : celui des milliers d'années contenant 2, et celui de l'état du GPS indiquant 1. Le premier m'a d'abord fait penser à une configuration par défaut. Mais j'ai pensé que, dans ce cas, les registres des jours et mois devraient eux contenir 1. Mais le second registre non vide indiquait alors que le GPS ne captait aucun satellite. En consultant la datasheet, j'ai pu confirmer l'état du GPS car la led STATUT situé sur le shield clignote lorsque celui-ci détecte la position. Or, elle était allumée de façon constante.
Semaine 7
Partie GSM
Lors de cette semaine, j'ai intégré une fonctionnalité de détection des erreurs dans mes fonctions de gestion du shield GSM. Ainsi je peux détecter, si une instruction s'est mal déroulé à cause d'un problème de démarrage de la carte Sim ou d'établissement du réseau par exemple.
Pour cela, j'ai créé une fonction qui recherche les mots clés "READY" et "OK" qui indique la bonne mise en place de l'instruction, et "ERROR" qui renvoie sur une fonction récupérant le code erreur.
Cette fonction peut être utile car si la balise ne capte pas de réseau GSM, il est possible de retarder l'envoi du SMS quotidien concernant les coordonnées GPS du rhinocéros.
Partie GPS
Je pensais donc avoir résolu le problème. Cependant, j'ai tout de même étudié le code réalisé par le groupe de l'année précédente avec le shield GPS. Celui-ci ne présentait pas de différences notables avec le code Arduino essayé précédemment (en tout cas concernant la gestion du module). J'ai également cherché si une configuration préalable était nécessaire, ce qui n'était pas le cas. J'ai ensuite essayé d'emporter le shield à l'extérieur dans le but d'augmenter ces chances de détecter un satellite. J'y suis resté une petite demi-heure, sans succès.
Semaine 8
Nous avons récupéré les modules radio TR3000 RFM. Ceux-ci ont été intégrés sur carte par un thésard, afin d'optimiser son utilisation.
Partie Radio
Lors de cette semaine, j'ai étudié le fonctionnement des modules radios. Ceux-ci fonctionnent à 433 MHz et ont 2 modes de transmissions de données :
- Le mode OOK, ce mode est économe en puissance mais est plus sensible au bruit. Le principe du mode est d'envoyer un signal en puissance haute pour envoyer un 1 et aucun signal pour envoyer un zéro. Ce mode est activé lorsque qu'on place les PINS CTRL0 et CTRL1 à "10"
- Le mode ASK, consomme d'avantage que le mode OOK mais est plus robuste au bruit à la transmission du message, il permet également un plus grand débit de transmission de données. Le principe du mode ASK, est d'envoyer un signal en puissance haute pour un 1 et en puissance basse pour un 0. Pour se placé dans ce mode il faut placer les PINS CTRL0 et CTRL1 à "01"
Pour éteindre les transmetteurs on place les PINS CTRL0 et 1 à '0'.
Après un test des modules en branchant les transmetteurs radio sur mon dongle USB, j'ai obtenu un taux de transmission de 25% avec erreur, et taux de réception du bon caractère de 15%. Dans les autres cas j'ai reçu soit rien, soit un caractère inconnu. J'ai donc décidé de recréer une liaison série et d'utiliser un autre protocole de transmission. A noté que la transmission se fait à 1200 bauds. Le taux d'erreur étant nettement plus grand au dessus de ce baud rate.
Ainsi pour envoyer un caractère codé sur 8 bits, j'envoie d'abord un préambule de 8 bits, puis mes datas. Cette trame de données est envoyée suivant le code Manchester. Un 1 étant codé par un front montant et un 0 par un front descendant.
Exemple pour l'envoie du caractère ' ' code ascii 32 (=0x20 en hexadécimal) on a donc comme donnée 0020 0000 on envoi les bits de poids faible en premier donc notre data devient 0000 0200 on ajoute le préambule, 1010 1011 0000 0200 on passe on code de Manchester 01 10 01 10 01 10 01 01 (préambule) 10 10 10 10 10 01 10 10 (data)
Partie GPS
J'ai alors effectué une dernière vérification des trames envoyées entre le shield et l'Arduino en les observant à l'analyseur logique. Voici l'extrait de l'une d'elle, contenant l'adresse ainsi qu'un bit acknowledge :
Les trames étant vérifiée, j'en ai conclu que le problème venait effectivement du matériel.
Partie RTC
Nous avions alors décidé de réveiller la partie balise du GPS sur interruption de la RTC. J'ai donc commencé à me documenter sur cette dernière qui communiquait, tout comme le module GPS, en I2C.
Semaine 9
Partie Radio
Lors de cette semaine, j'ai terminé la liaison radio, je peux ainsi envoyer certains caractères par radio. J'utilise cependant mes propres transmetteurs radio ayant des difficultés à faire fonctionner ceux fourni par Alexandre Boé. De plus la Deadline du rendu de projet, j'ai préféré avancer sur d'autre sujet plutôt que de chercher à faire fonctionner les transmetteurs RFM.
J'ai remarqué que même avec un préambule et le code de Manchester, il m'arrive de récupérer des informations émanant du bruit. Il arrive aussi que le caractère transmis ne soit pas reçu.
J'ai donc décidé de faire un code redondant pour diminuer l'impact du bruit. Ainsi le code d'émission envoie un caractère 30 fois. Le code de réception lui détecte 10 caractères puis renvoie le caractère le plus récurant. Ce code est lourd mais est suffisamment robuste au bruit en zone urbaine, pour assurer la transmission de certains caractères.
En effet, malgré les tests concluant de transmission par câble, j'ai remarqué que certains caractère lors de la transmission radio se transformait, ainsi le caractère 'a' se transforme en '}', de façon constante.
Dans un souci de sécurité j'ai donc choisi 2 caractères qui ne subissait pas de transformation et qui possédaient une distance binaire suffisante. C'est à dire, 2 caractères ayant le plus de bits de différence. J'ai choisi le caractère 'j' et 'm' pour envoyer l'état vivant ou mort du rhinocéros. L'envoie de l'état vivant n'est pas obligatoire mais permet d'assurer la sécurité de la transmission et de pouvoir détecter une anomalie si la balise ne reçoit plus de message. L'anomalie pouvant provenir d'un brouilleur. Cependant si on poursuit dans cette voie il faudra prévoir une alimentation suffisante du capteur. Il faudra donc faire un choix entre simplicité de l'alimentation du capteur ou sécurité du système.
Partie GPS
Après quelques recherches, il s'est avéré que le DS_GPM pouvait mettre un temps non négligeable (de l'ordre de l'heure) pour capter lorsqu'il n'avait pas détecté de satellite depuis longtemps. N'étant pas sûre et certaine de l'avoir déjà laissé alimenter en continu aussi longtemps, j'ai alors décidé de lui laisser le temps nécessaire. Après 4 heures d'alimentation, j'ai alors admis que le shield ne fonctionnerait pas.
Partie RTC
J'ai pu commencer à programmer la RTC, cependant celle-ci ne répondait pas à son adresse, qui est indiquée dans la datasheet. Cependant, elle répondait bien au start. Alors que je commençais à chercher le problème, nous avons décidé que le watchdog pourrait suffire à savoir quand envoyer le SMS quotidien, car l'heure d'envoi n'a pas besoin d'être très précise. J'ai alors arrêté de programmer la RTC.
Programme principal
Maintenant que chaque module a été traité, et qu'une librairie de fonction a été développée, il faut assembler chaque module pour former le programme principal.
La structure du programme principal a été faite et est disponible en annexes cependant il n'est pas fonctionnel en l'état.
Pour le module émetteur, l'arduino se réveille, récupère la valeur du capteur envoie l'état du rhinocéros par liaison radio 30 fois, puis se rendort pendant 8 secondes.
Pour la balise, la structure est plus complexe :
Après réveil, l'Arduino récupère l'état du rhinocéros.
- en cas de mort, récupération des coordonnées GPS puis envois du message d'alerte.
- en cas de non réception de données dans les 16 secondes impartit, revérification de la liaison puis au bout d'un nombre de fois paramétrable envois d'un message d'alerte pour prévenir de la possible présence d'un brouilleur.
- vérification de du nombre interruption watchdog, pour calculer approximativement l'heure (interruption toute les 8 secondes). Si on se trouve à la bonne heure, on récupère les coordonnées GPS puis on envoie le SMS quotidien.
On replonge ensuite l'arduino en veille.
Semaine 10
Durant la dernière semaine, nous nous sommes beaucoup consacré à l'écriture du rapport, la rédaction du wiki, la préparation de la soutenance ainsi que la mise au point de la vidéo de présentation. Nous nous sommes partagés la rédaction des différents rendus ainsi que la préparation de la soutenance, et nous avons chacun prévu des codes de démonstrations afin de pouvoir réaliser la vidéo.
Résumé
Positionnement dans le projet
Dans ce projet, nous avons développé des fonctions pour chaque module indispensable au système. Cependant la structure principale du système n'a pas pu être terminée.
Il faut donc maintenant utiliser les librairies de fonction pour rassembler et faire fonctionner ensemble tous les modules du système.
Proposition
Afin d'aider au mieux à la mise en place du projet, nous avons décidé de faire plusieurs propositions sur le projet.
- Pour alimenter le système nous proposons l'utilisation d'une batterie aux lithium-ion comme celle sur présente sur la photo si contre. Il est possible d'en trouver pour une somme modique et possèderai une capacité suffisante pour alimenter le système pendant 2 ans.
Le lien vers la batterie se trouve ici.
- Pour sécuriser d'avantage le système, tant sur la fiabilité, que le temps de réponse, et la sécurisation du système contre les braconniers, on propose de placer le capteur de vie directement sur la cuisse au niveau de la balise.
Bilan
Ce projet a été très bénéfique pour nous, il nous a permis d'élaborer un système par nous-mêmes, en étant autonomes. Nous avons pu acquérir beaucoup de nouvelles connaissances sur les différents protocoles dont nous nous sommes servis et ceux présent sur les documentations que nous avons utilisés. Nous avons également pu réaliser le temps que peuvent prendre de petites tâches lorsque l'on rencontre des difficultés, ce qui peut bouleverser tout le déroulement du projet. Cette expérience nous permettra de mieux anticiper les désagréments que l'on peut rencontrer lors de la réalisation d'un projet.
Rapport
Fichier:Rapport Save The Rhino.pdf
Matériel récupéré
- 1 Arduino ADK
- 1 shield GPS
- 1 shield GSM
- 2 modules radio
- 4 led+resistance
- 1 breadboard
- 1 cordon alim
