Version du 15 avril 2014 à 20:10

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. Ils sera utiliser 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 principals 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, Recepteur 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 opter 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érents du système à traiter :

1. Le capteur de vie (dont nous ne disposerons peut être pas avant la fin du projet)
2. La transmission radio
3. La détection de la position GPS
4. L'envoi de messages
5. 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 travailler à é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é 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 consister à 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 utiliser 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 language 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 rend la compréhension du code très complexes.

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 analyser 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évelopper.

Partie GPS

J'ai décidé d'insérer dans mon code les modifications nécessaires pour le debogage. Pour cela, j'ai envoyer 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 étudier 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 donc repris le protocole de communication de mon programme précèdent.

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 rechercher 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 micro processeur pendant un temps donnée. J'ai ainsi pu développer des fonctions qui seront utiliser 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 le 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éutiliser 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 confirmé l'état du GPS car la led STATUT situé sur le shield clignote lorsque celui-ci détecte la position. Or, elle était allumé 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 instructions 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éer 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 notable avec le code Arduino essayé précedemment (en tout cas concernant la gestion du module). J'ai également chercher 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 rester 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é sur carte par un thésard, afin d'optimiser son utilisation.

Partie Radio

schéma des I/O du TR3000

• 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ébits 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"

photo des cartes utilisant le module radio TR3000

Pour éteindre les transmetteurs on place les PINS CTRL0 et 1 à '0'.

Après un test des modules en branchant les transmetteur 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.

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é suivant le code Manchester. Un 1 étant codé par un front montant et un 0 par un front descendant.

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 terminer la liaison radio, je peux ainsi envoyer certains caractères par radio. J'utilise cependant mes propres transmetteur 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 transmetteur 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écider 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ère 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ère.

En effet, malgré les test 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 soucis 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ère 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 lorqu'il n'avait pas détecter de satellite depuis longtemps. N'étant pas sûre et certaine de l'avoir déjà laisser alimenter en continu aussi longtemps, j'ai alors décidé de lui laisser le temps nécessaire. Après 4 heure 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 commencais à 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êter de programmer la RTC.

Programme principal

Maintenant que chaque module a été traité, et qu'une librairie de fonction a été développé, il faut assembler chaque module pour former le programme principal.

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.

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 peu 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.

Shield GSM Arduino

Le développement de la librairie lié au shield arduino a pris une très grande part du temps alloué au projet. La développement a pris fin lors de la 7e semaine de projet.

Pour son développement, j'ai d'abord étudié les codes développés par Bastien Challo lors de son projet "Site Web par SMS". Cependant, ce code étant écrit en code Arduino. J'ai choisi de réécrire ce code en C.

Après avoir écris un code équivalent en C, je me suis heurté à un problème de communication avec le shield. En effet, celui-ci ne répondait pas à mes instructions.

Un Code Arduino était disponible avec le shield, mais celui-ci nécessité 15Ko de mémoire pour son implantation. Ce qui n'était pas envisageable pour notre projet, le shield GSM étant une fonctionnalité parmi d'autre, sacrifier 15ko de mémoire dés le début du projet n'était pas envisageable.

J'ai donc, à partir de la essayé de comprendre le fonctionnement du code Arduino, pour le retranscrire en C, et économiser de l'espace mémoire. Les très nombreuses librairies utilisé pour la gestion du shield ne m'ont pas facilité la tâche.

lors de la 5e semaine Après de nombreuses heures de rechercher et d'étude du code, et le temps avant le rendu du projet s'écoulant très rapidement. Il nous a été fourni un Arduino Méga, ainsi nous n'avions plus de problème d'espace mémoire, et pouvions coder en Arduino.

Dans le même temps, un camarade m'a proposé d'utiliser son Dongle USB permettant d'extraire la liaison série du port USB. Cet outil m'a permis de communiquer directement avec le shield GSM, mais aussi de récupérer les instructions écrite par le shield arduino sur le port de communication du shield. Grâce à cela, j'ai pu continuer à développer sur un Arduino Uno, et écrire un code en C.

Une semaine après j'envoyais des sms avec mon arduino.

lors de la 7e semaine j'ai intégrer des fonctions pour récupérer les informations renvoyer par le shield GSM, afin de récupérer le code d'erreur potentiel, ou l'état READY ou OK si l'instruction s'est bien passée. Une fois ces fonctions intégrer, j'ai considéré le développement du shield GSM terminé.