Version du 15 avril 2014 à 13:19

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

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

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

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

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 GSM

Partie GPS

Semaine 7

Semaine 8

Semaine 9

Semaine 10

La transmission radio

Le développement de la liaison radio, a démarré lors de la 7e semaine de projet. N'ayant reçu les modules radio qu'à cette période. Fort de nptre expérience des TPs de codage de l'information. La liaison radio s'est établie rapidement, ainsi lors de la 8e semaine j'ai pu transmettre des informations en utilisant des modules radio 433MHz.

Shield DS GPM

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

Cette trame est une communication plutôt classique dans le protocole I2C. Il fallait alors utiliser les registres de l'Arduino pour qu'il envoie les bonnes données dans le bon ordre, et aux bonnes adresses.

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é cuelques unes de mes fonctions sur le shield. Je n'ai, à cet instant, pas pu recevoir d'informations venant du module.

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 certains registres.

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

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