1

Département d’ ElectroniqueDépartement d’ Electronique

Projets Industriels – Elec4

Année scolaire 2016-2017

Rapport Final

ROVER

Version 7

Etudiants : ARNOUX Coralie – JUILLET Matt

Encadrant : MASSON Pascal

Ecole Polytechnique Universitaire de Nice Sophia-Antipolis, Département électronique

930 route des Colles, 06410 BIOT

2

REMERCIEMENTS

Nous tenons tout d’abord à remercier Mademoiselle Maéva Manuel qui nous a permis de nous joindre à elle sur ce

projet, et pour sa confiance tout au long de cette aventure.

Nous remercions également Monsieur Pascal Masson pour sa disponibilité, ses encouragements, son soutien et ses

conseils techniques pour la réalisation de ce projet.

Nous remercions aussi l’équipe du Fab Lab de Sophia pour leurs précieux conseils, leur temps et leur disponibilité,

notamment durant la phase de conception du bras du Rover.

Enfin, nous remercions Monsieur Luc Deneire pour nous avoir permis de faire rentrer ce projet personnel dans le

cadre des projets tutorés.

3

SOMMAIRE

Introduction ........................................................................................................................... 5

I / Cahier des Charges ............................................................................................................ 6

I.1. Nos objectifs........................................................................................................................................................................ 6

I.2. Spécification du matériel ..................................................................................................................................................... 7

I.2.1 Eléments passifs ........................................................................................................................................................... 7 I.2.2 Eléments actifs ............................................................................................................................................................. 7 I.2.3 Interfaces de contrôle ................................................................................................................................................... 8 I.2.4 Transmission ................................................................................................................................................................ 8 I.2.5 Site web ........................................................................................................................................................................ 8

II / Réalisation, problèmes rencontrés et solutions ............................................................... 9

I .1. Les éléments passifs .......................................................................................................................................................... 9

I.1.1 Température et Humidité .............................................................................................................................................. 9 I.1.2 Altitude et Pression..................................................................................................................................................... 10 I.1.3 Distance ...................................................................................................................................................................... 11 I.1.4 Monoxyde de carbone ................................................................................................................................................ 11 I.1.5 Luminosité .................................................................................................................................................................. 12 I.1.6 Gyroscope ................................................................................................................................................................... 13 I.1.7 Radiations ................................................................................................................................................................... 13 I.1.8 Tous les capteurs ........................................................................................................................................................ 14

I.2. Les éléments actifs ............................................................................................................................................................ 15

I.2.1 Un servomoteur .......................................................................................................................................................... 15 I.2.2 Plusieurs servomoteurs ............................................................................................................................................... 15 I.2.3 La pince et le bras ....................................................................................................................................................... 16

I.3. La communication ............................................................................................................................................................. 20

I.3.1 Raspberry Arduino............................................................................................................................................. 20 I.3.2 Raspberry Raspberry ......................................................................................................................................... 20 I.3.3 Protocole ..................................................................................................................................................................... 22 I.3.4 Fichiers ....................................................................................................................................................................... 22 I.3.5 Mode debug ................................................................................................................................................................ 22 I.3.6 Changement de méthode de transmission ................................................................................................................... 23

I.4. Le site web ........................................................................................................................................................................ 23

I.4.1 Squelette du code ........................................................................................................................................................ 23 I.4.1 Vérification des saisies de l’utilisateur ....................................................................................................................... 24 I.4.3 Compatibilité .............................................................................................................................................................. 24 II.5. Synthèse ...................................................................................................................................................................... 26

III.1. Le planning ..................................................................................................................................................................... 28

III.2. La BOM .......................................................................................................................................................................... 30

IV / Amélioration sur notre partie du projet ........................................................................ 33

Conclusion ........................................................................................................................... 34

Bibliographie ....................................................................................................................... 35

4

Annexe A : Comment utiliser notre projet ? ....................................................................... 36

I/ Le câblage ............................................................................................................................................................................ 36

Les capteurs et servomoteurs .............................................................................................................................................. 36 Les Arduinos ....................................................................................................................................................................... 36 Les Raspberry ..................................................................................................................................................................... 37

II/ Les scripts ........................................................................................................................................................................... 37

Les Arduino ......................................................................................................................................................................... 37 Les Raspberry ..................................................................................................................................................................... 37

III/ Let’s go ! ........................................................................................................................................................................... 38

Annexe B : Quelques illustrations ....................................................................................... 39

5

Introduction

Durant le second semestre de notre 4e année d’école d’ingénieurs en électronique, nous avons acquis le bagage nous permettant

de réaliser notre projet industriel : la réplique d’un Rover Martien. Tout au long de la réalisation de notre mission, nous avons

été épaulé par notre tuteur, Pascal Masson, et par l’élève à l’origine de ce projet, Maéva Manuel. Nous avons pu mettre en

œuvre nos connaissances, mais aussi apprendre tant sur la théorie que sur la pratique de l’électronique et de la programmation.

Ce rapport de projet suit le rapport bibliographique réalisé précédemment et qui détaillait nos recherches sur le projet, nos

objectifs et leur mise en œuvre. Cette fois, nous allons détailler ce qui nous avons vraiment réalisé, ce qui est différent par

rapport à ce qui était prévu et la cause de ces différences.

Nous commencerons par rappeler notre cahier des charges établis au début du projet. Puis, nous expliquerons ce que nous

avons implémenté, les problèmes que nous avons rencontrés et comment nous les avons résolus.

Nous donnerons ensuite notre planning et notre BOM réels, et nous les comparerons avec ceux établis précédemment. Nous

expliquerons les causes des écarts potentiels.

Enfin, nous ajouterons les améliorations auxquelles nous avons pensé concernant notre implication dans le projet afin de

donner des idées aux prochaines personnes collaborant sur le projet Rover.

6

I / Cahier des Charges

Nous rappelons ici le cahier des charges fixé lors du début du projet.

I.1. Nos objectifs

Notre mission dans ce projet était principalement d’équiper le robot de capteurs et d’éléments actifs, puis de réaliser la

communication d’ordre entre le système de contrôle Terrien et le Rover Martien afin d’utiliser ces éléments. Nous devions

donc permettre de réaliser les actions suivantes :

- Effectuer des relevés dans l’environnement du robot grâce à différents capteurs ;

- Effectuer des prélèvements et des perçages ;

- Transmettre des données et des ordres entre Mars et la Terre ;

- Contrôler le robot et recevoir des informations grâce à un site Web.

Ainsi, nous souhaitions mettre en place le fonctionnement résumé par le schéma ci-dessous :

7

I.2. Spécification du matériel

Nous avons établi des spécifications techniques (chiffrées ou non) afin de choisir notre matériel.

I.2.1 Eléments passifs

En ce qui concerne les capteurs, comme nous travaillons sur une réplique, nous tenterons de respecter les gammes de valeurs

pour une utilisation sur Terre. En effet, nous ne pouvons pas trouver de capteurs compatibles avec les gammes de valeurs de

Mars à un coût raisonnable. Nous allons donc, pour chaque capteur souhaité par le cahier des charges, indiquer les gammes de

valeurs souhaitées sur Mars et sur la Terre, ainsi que la précision désirée.

Figure 1 : Définition des spécifications chiffrées pour les capteurs

I.2.2 Eléments actifs

Concernant les éléments actifs, nous nous sommes fixés des caractéristiques à respecter (comme le poids, la taille etc) afin de

rester cohérent par rapport à la taille et au poids du moteur, et pour réduire l’encombrement.

Figure 2 Définition des spéciations chiffrée pour les éléments actifs

8

I.2.3 Interfaces de contrôle

Sur Mars ou sur Terre, nous avions défini une spécification permettant de pouvoir faire l’interface avec les capteurs et le site

web.

La carte d’interface sur Mars doit pouvoir :

o Interpréter les ordres reçus (sous forme de chaine de caractères)

o Travailler avec tous les capteurs et outils

o Enregistrer des données sur un support physique ( ~ Go pour stocker des vidéos )

o Envoyer des fichiers lourds (photos, vidéo) en les découpant par paquets afin de remédier au faible débit

La carte d’interface sur Terre doit pouvoir :

o Interpréter les informations transmises par le Rover

o Transmettre les informations sur un site Web

o Envoyer des ordres (sous forme de chaine de caractère)

I.2.4 Transmission

En ce qui concerne la transmission, nous avions défini les critères suivants :

Débit

o ~ 10 Kbit/s suffit pour le transfert d’ordre (proche de la réalité sur une communication directe), mais meilleur

débit nécessaire pour transmettre du multimédia

o La taille du paquet doit permettre d’envoyer des courtes chaines de caractères

(8 octets suffisent pour envoyer des ordres simples ou les informations des capteurs)

Portée

o > 50 m pour un minimum de réalisme et ainsi pouvoir faire évoluer le Rover de façon autonome dans un

environnement assez vaste

Sans fil

o Dans un souci de réalisme

I.2.5 Site web

Enfin, notre site web doit :

o Donner la possibilité d’envoyer des ordres (température, pression…)

o Permettre l’affichage des données reçues et/ou des messages d’erreur générés

9

II / Réalisation, problèmes rencontrés et solutions

I .1. Les éléments passifs

Nous avons commencé par étudier et faire fonctionner chaque capteur un par un, en affichant le résultat sur la console. Puis,

lorsque nous étions surs qu’ils étaient tous fonctionnels, nous les avons rassemblés afin de réaliser une unique fonction pour les

faire fonctionner ensemble.

I.1.1 Température et Humidité

Nous avons commencé par implémenter le capteur de température et d’humidité. Pour cela, nous avons importé la librairie

dht.h dans l’interface Arduino. Celle-ci contient notamment la fonction read11 (car notre composant s’appelle DHT 11), qui

prend en paramètre le numéro de la pin à laquelle le capteur est connecté et qui effectue la mesure et permet de renvoyer l’état

du capteur et de signaler si celui a rencontré un problème ou non. Elle contient aussi des variables membres permettant

simplement d’accéder aux valeurs de la température ou de l’humidité.

Nous avons décidé de ne pas nous servir de la gestion des erreurs, et de laisser la transmission s’en charger. Il aurait été tout à

fait possible de l’utiliser lors de la transmission, et cela pourrait faciliter l’implémentation du protocole en cas d’erreur.

Pour fonctionner, le programme a simplement besoin d’indiquer le baud rate à l’initialisation que nous choisissons à 9600

bauds, une valeur standard. Nous utiliserons cette valeur pour tous les capteurs.

Puis, nous définissons des fonctions pour le relevé des valeurs. Nous effectuons d’abord un read, puis nous renvoyons la

grandeur souhaitée. Le numéro de la pin est une constante définie en début de programme. Nous utilisons un passage par

paramètre.

Figure 3 Fonctions pour le relevé de la température et de l'humidité

Ce capteur a été testé grâce à un bouton poussoir. Lorsque le bouton est enfoncé, la valeur de la température et de l’humidité

sont relevés. Cela a permis de valider le fonctionnement de ce premier capteur.

Figure 4 Branchement pour le test du capteur avec bouton poussoir

10

Cependant, nous nous sommes rendus compte, grâce aux valeurs retournées, que celui-ci n’était pas très précis. Il s’agira par la

suite d’évoluer vers un capteur plus précis, comme son grand frère, le DTH12.

De plus, ce capteur ne renvoie que des nombres entiers. Il serait intéressant de savoir comment manipuler et renvoyer les

décimales, ce qui n’est pas géré ici avec la fonction read. Il s’agit d’un problème que nous n’avons pas eu le temps de régler.

Dans tous les cas, le prochain capteur permettra aussi de relever la température, de manière plus précise.

I.1.2 Altitude et Pression

Ce capteur a beaucoup de fonctionnalités. Il permet par exemple de réaliser une série de mesures à une fréquence choisie

durant 24h. Néanmoins, nous nous contenterons, pour le moment, de réaliser un relevé lorsque l’utilisateur le demande. Pour

programmer ce capteur, nous utilisons la librairie SparkFunMPL3115A2.h qui contient différentes méthodes afin d’initialiser

les registres du capteur, ainsi que pour obtenir la valeur de la grandeur souhaitée. Nous nous servons aussi de la librairie

Wire.h car les données sont envoyées grâce au bus I2C de l’Arduino.

Lors de la configuration du capteur, nous choisissons son mode, altimètre ou baromètre. Après avoir essayé différentes

librairies, nous nous sommes rapidement aperçus que ce mode ne pouvait pas être changé une fois fixé. Nous pouvons donc

relever soit l’altitude, soit la pression, mais pas les deux grandeurs en même temps ! La température est disponible en même

temps que les deux modes. Nous avons donc choisi de nous servir de ce capteur comme baromètre, et de relever l’altitude

grâce au système GPS qui sera implémenté sur le Rover.

De nouveau, nous fixons le baud rate. Puis, nous définissons une fonction qui initialise le capteur en mode baromètre et qui le

démarre, et une autre qui permet de réaliser le relevé. Cette seconde fonction est très simple, elle ne contient qu’une ligne.

Mais elle permettra de changer de capteur ou de librairie, et de seulement changer cette fonction, sans se soucier du gros

programme (switch) qui sera utilisé lors de la présence de plusieurs capteurs. Cela permet donc de rendre le code lisible et

flexible.

Figure 5 Fonctions utiles pour le capteur de pression

Lors de l’initialisation, les paramètres du capteur sont laissés par défaut (on autorise les interruptions et on choisit le sample

rate). Il pourra être utile ultérieurement de les changer selon l’utilisation souhaitée.

Nous avons rencontré un autre problème : lorsque nous réalisions une première mesure de pression, celle-ci renvoyait toujours

0. Nous n’en connaissons pas la raison, mais pour résoudre ce problème, nous demandons un relevé lors de l’initialisation des

capteurs, relevé qui n’est pas pris en compte (voir I.1.8). Ainsi, lorsqu’une mesure de la pression sera demandée, il n’y aura pas

de problème puisque ce ne sera pas la première mesure.

11

I.1.3 Distance

Pour commencer, nous nous sommes intéressés au détecteur d’obstacles IR. Celui-ci ne renvoie qu’un booléen vrai ou faux

selon qu’un obstacle est plus proche que la distance réglée par un potentiomètre ou non. Nous avons pu tester son

fonctionnement grâce à un code simple.

Figure 6 : Fonction de test pour le capteur de distance IR

Le capteur est branché sur la pin numérique numéro 2. On affiche simplement vrai ou faux selon la distance de l’obstacle. Ce

capteur est opérationnel. Il sera utilisé pour le déplacement du robot (plusieurs capteurs seront placés un peu partout sur la

caisse pour arrêter le mouvement en cas d’obstacle et pour adapter la trajectoire à adopter) ainsi que pour le bras, ce que nous

verrons par la suite.

Puis, nous nous sommes intéressés au détecteur d’obstacles ultrasons. Celui-ci nécessite l’utilisation de la librairie Ping.h, qui

permet l’utilisation de l’émetteur d’ultrasons de l’Arduino. Cette librairie contient des méthodes permettant d’obtenir le temps

de parcours de l’ultrason jusqu’au premier obstacle, ou la distance jusqu’au premier obstacle, ce qui nous intéresse. Nous nous

servirons de cette dernière qui émet une impulsion puis qui renvoie une distance en centimètres.

Nous définissons les pins relatives à ce capteur, puis on crée un objet du type NewPing, sur lequel on appliquera la fonction

ping_cm. Nous définissons aussi une fonction getDistance, toujours dans l’optique de flexibilité et de réutilisabilité du

programme.

Figure 7 : Fonctions utiles pour le capteur de distance ultrasons

Pour tester ce capteur, nous avons placé un objet (notre main) à différentes distances du capteur que nous mesurions à la règle.

Puis, nous demandions la mesure au capteur. Celle-ci est précise par rapport à la mesure faite à la règle, donc le capteur

fonctionne.

I.1.4 Monoxyde de carbone

Pour utiliser ce capteur, nous n’avons pas eu besoin de librairie particulière, mais nous avons récupérer les calculs à effectuer

fournis par les descriptif du capteur. Le capteur renvoie une valeur analogique. Cette valeur est traitée afin d’obtenir un ratio

entre deux résistances. A partir de ce ratio, nous avons une formule pour obtenir une valeur de la concentration de monoxyde

de carbone en ppm : ppm = 37143*(ratio^-3.178).

A partir de ces calculs, nous créons deux fonctions (dont le nom est mal choisi puisque c’est deux fois le même).

Figure 8 Fonctions utiles pour l'utilisation du capteur de Monoxyde de carbone

12

Il s’agira ensuite, pour obtenir la valeur en ppm, d’écrire la ligne « get_CO(GetCO()) ».

Nous obtenions d’abord des valeurs très élevées avec ce capteur. Cela était dû au fait que le capteur avait besoin de fonctionner

pendant 24h non stop pour effectuer un « burn in ». Après cela, les valeurs ont été cohérentes (entre 0.5 et 5ppm), bien qu’à

chaque mise en marche du capteur, il faut toujours attendre quelques temps (10min environ) afin que le capteur soit prêt (sinon

les valeurs sont trop importantes, mais la diminution progressive des valeurs retournée commence moins haut).

Il ne faudra pas s’occuper du message « ATTENTION : faux .mytools dossier dans la librairie MySensor » s’il se produit (cela

est dû à un essai de nouvelles librairies qui ont été abandonnées).

Après vérification, il sera simple et rapide d’ajouter de nouveaux capteurs de la même famille pour d’autres éléments.

I.1.5 Luminosité

Nous avons rencontré un contretemps au sujet du capteur de luminosité. En effet, nous pensions que la valeur analogique

renvoyée par le capteur serait utilisable. Or, cette valeur n’a aucun sens physique !

Nous avons donc passé une séance à faire de nombreux relevés, en laissant le composant refroidir pour ne pas altérer les

données, afin de trouver la caractéristique valeur/lux du capteur, à l’aide d’un luxmètre sur un smartphone. Malheureusement,

la courbe obtenue était très complexe et a du être séparée en trois caractéristiques. Nous avons créé une fonction de conversion

avec ces caractéristiques :

Figure 9 : Caractéristique du premier capteur de luminosité pour la conversion valeur vers lux

Comme cette méthode était très approximative, nous avons décidé de commander un nouveau composant, le BH1750, qui

possède sa propre librairie du même nom et qui renvoie directement une valeur en lux. Il s’est avéré que c’était un bon choix,

puisqu’en comparant la valeur obtenue avec ce composant, la caractéristique de l’autre composant et le luxmètre, le composant

était très proche de la valeur du luxmètre, tandis que l’ancien composant ne fonctionnait pas (au moins 20% d’erreur, ce qui

n’est pas précis du tout). Ceci est dû à nos relevés pour tracer la caractéristique qui peuvent être faux, ou au composant en lui-

même que nous ne pouvons vraiment pas caractériser ainsi.

Comme nous avions ce nouveau composant, il a été simple de le programmer. Il s’agit d’activer le bus I2C, de démarrer le

composant (initialisation) puis de réaliser la mesure.

Figure 10 Fonctions utiles pour l'utilisation du nouveau capteur de luminosité

Notre capteur de luminosité est finalement opérationnel.

13

I.1.6 Gyroscope

Nous avons décidé d’ajouter un gyroscope à la liste des capteurs prévue par le cahier des charges car celui-ci fournit des

informations très importantes pour le déplacement. Comme, à termes, le Rover devra se déplacer, ou comme nous devrons

commander la position du bras, la gestion de ce capteur sera nécessaire.

Le modèle que nous possédons permet d’obtenir des valeurs d’accélération, de vitesse et de position. Ici, nous ne nous

intéresserons qu’aux angles définissant la position du capteur. Il utilise de nouveau la librairie Wire.h.

Nous définissons donc l’initialisation du gyroscope, en indiquant notamment l’adresse à laquelle aller chercher la première

information, c’est-à-dire l’adresse du bus I2C, stockée dans la variable MPU. On y écrit 0 afin de démarrer le composant.

Nous avons une seconde fonction effectuant les calculs nécessaires à l’obtention des grandeurs souhaitées (ici la position, 3

angles). Des valeurs d’accélération sont récupérées dans différents registres et sont traitées afin d’obtenir les angles désirés.

Figure 11 : Fonctions utiles pour l'utilisation du gyroscope

Lorsqu’on l’on bouge le capteur, la variation des angles est cohérente donc le gyroscope fonctionne.

I.1.7 Radiations

Nous souhaitions mettre en place un compteur Geiger dans notre système, mais le premier modèle que nous avions trouvé était

coûteux, encombrant, et nécessitait une alimentation très importante.

Nous avons finalement trouvé un modèle destiné à être branché à un smartphone pour afficher le taux de radiation en temps

réel. Nous avons décidé de l’utiliser en ne conservant que la partie qui nous intéressait (exit la prise jack pour relier au

téléphone et le support pour les piles par exemple).

Ce composant est programmable grâce à une bibliothèque, RadiationWatch.h, qui contient une méthode renvoyant la quantité

de uSvh reçu par le capteur. Ayant étudié de près cette librairie, le code est très complexe puisqu’il s’agit d’un compteur de

particule émise, qui est lié au temps d’exposition entre deux mesures.

Pour l’utiliser, il suffit d’appeler la fonction setup après avoir réglé le baud rate, puis d’appeler la fonction uSvh.

Figure 12 : Lignes utiles pour l'utilisation du compteur Geiger

14

Nous avons mis du temps à comprendre le principe d’interruption. Dans notre cas, celles-ci n’étaient pas utilisables, nous

avons donc décidé de les retirer et donc ne pas les définir afin de demander la valeur seulement lorsqu’on le souhaite. Il faut

veiller à ce que, à chaque tour de boucle, la fonction loop de la librairie soit appelée afin de mettre à jour le compteur et de ne

pas avoir d’incohérence lors du relevé de valeur.

Figure 13 ATTENTION : A ne pas oublier pour le bon fonctionnement du capteur

Pour tester son bon fonctionnement, et comme nous n’avions pas d’élément radioactif sur nous, nous avons reçu l’aide de Mr

Lorenzini qui nous a laissé utiliser le générateur à rayons X. Ainsi, nous avons pu observer que, plus on injectait de particules,

plus la valeur en uSvh était importante, et inversement. Bien que nous n’ayons pas de comparaison chiffrée, nous pouvons dire

que le capteur fonctionne, en tout cas en termes de variations.

I.1.8 Tous les capteurs

Finalement, nous avons réussi à implémenter tous les capteurs inscrits dans le cahier des charges, sauf l’altitude qui sera

fournie plus tard. Nous avons même pu en intégrer un supplémentaire : le gyroscope.

Afin de les faire fonctionner ensemble, nous utilisons une structure de switch qui teste un entier. Chaque capteur est associé à

un entier. Ainsi, lorsqu’un entier est tapé à la console, le switch va tester cet entier, et effectuer la mesure demandée et

l’afficher sur la console. Si l’entier ne correspond à aucun capteur, rien ne se passe.

Par la suite, ce nombre tapé par l’utilisateur dans la console a été remplacé par un entier transmis par le port série, mais le

principe reste le même.

Dans le setup, toutes les initialisations sont réalisées. Puis, le code fonctionne bien. Il a pu être intégré à la chaine de

communication.

Figure 14 : Branchement avec tous les capteurs sur une seule Arduino

…

Figure 15 Extrait du switch de la fonction principale des capteurs

15

I.2. Les éléments actifs Les éléments actifs sont des composants qui réalisent une action dans leur environnement, et non pas une simple mesure. Pour

les contrôler, nous avons besoin de servomoteurs. Nous avons décidé de réaliser la commande d’un servomoteur, puis une

fonction qui contrôlera le nombre total de servomoteurs dont nous avons besoin pour le moment.

I.2.1 Un servomoteur

Pour contrôler un servomoteur, nous utilisons la librairie Servo.h. Celle-ci contient principalement les méthodes :

- Attach, pour lier une pin à un servomoteur (commande) ;

- Read, pour récupérer la position courante du servomoteur ;

- Write, pour modifier la position du servomoteur.

Nous utilisons aussi la librairie Wire.h.

Afin de préparer le contrôle de plusieurs servomoteurs, nous utilisons des variables globales, notamment pour le numéro de la

pin et l’offset. Pour le premier test, nous avons utilisé un servomoteur Hitec HS 311. La prise en main a été rapide, et nous

avons constaté qu’il faudrait surement interdire par la suite des plages de valeurs d’angles, selon les mouvements qui seront

possibles ou non.

I.2.2 Plusieurs servomoteurs

Afin de contrôler les 6 servomoteurs dont nous aurons besoin pour notre partie de la réalisation du Rover, nous utilisons

notamment des tableaux contenant les servos, les numéros de pin associés et leur valeur initiale.

Nous utilisons aussi des constantes afin de définir, par exemple, leur nom (le numéro associé est la place dans le tableau des

servo), de manière arbitraire, pour que le programme soit plus lisible et que le futur programmeur n’ait pas à connaître la place

de chaque servo dans le tableau (ce qui n’est pas utile du tout !). Les servos ont été étiquetés au préalable.

Un servomoteur pourra être facilement ajouté, en augmentant la constante « NB_SERVO », en ajoutant tous les paramètres

nécessaires (nom, numéro de pin et valeur initiale), et en les ajoutant aux tableaux Pin et init_s. L’initialisation se fera

automatiquement, il n’y aura plus qu’à ajouter du code à la fonction principale pour contrôler ces nouveaux servomoteurs.

Pour choisir l’action à réaliser sur les servomoteurs, nous utilisons de nouveau un switch. Dans la fonction principale, nous

récupérons l’angle choisi, puis nous testons le numéro du servomoteur à contrôler. Nous verrons par la suite que certains ordres

correspondront à des fonctions déjà prédéfinies, et non à du contrôle de moteur un à un.

Figure 16 Début de la fonction de gestion de plusieurs servomoteurs

16

Figure 17 Fonction de motion pour modifier l'angle d'un servomoteur

Dans cette fonction, l’entier servo pourra être remplacé par SERVO_A, SERVO_B etc lors de l’appel de la fonction.

Figure 18 Fonction qui place chaque servomoteur dans sa position initiale donnée

Nous n’avons pas pu tester rapidement ce code puisque nous devions alimenter tous les servomoteurs, ce qui n’était pas

possible avec uniquement l’Arduino. Nous avons aussi dû résoudre un problème : lorsque nous avons introduit la batterie, les

servomoteurs ne répondaient plus correctement aux instructions, mais de façon complètement aléatoire. Cela était dû au fait

que l’Arduino était alimentée séparément. Nous avons donc trouvé un connecteur permettant d’alimenter l’Arduino avec la

batterie et les convertisseurs 12V->5V. Le problème était alors résolu. Il s’agit d’un problème qui pourra de nouveau être

rencontré, il est donc intéressant de le signaler, afin de ne pas passer autant de temps que nous sur ce problème.

Nous avons donc testé un ou deux servomoteurs à la fois avec cette fonction, puis, dès que la batterie a été utilisable, nous

avons pu commander tous les servomoteurs d’un coup, sans difficulté particulière.

I.2.3 La pince et le bras

La pince que nous avons commandée correspond totalement aux spécifications du cahier des charges. Elle a été rapidement

contrôlable avec notre fonction à plusieurs servomoteurs puisque celle-ci est composée de deux servomoteurs : une pour la

rotation de la pince, et l’autre qui transforme une rotation en translation pour ouvrir et fermer la pince. Nous avons d’ailleurs

défini deux fonctions, pour ouvrir et fermer la pince, pour que ce soit plus « user-friendly » :

Figure 19 Pince et ses deux servomoteurs

Figure 20 : Fonctions définies pour ouvrir et fermer la pince

17

Puis, nous avons modifié nos priorités par rapport au cahier des charges en choisissant de ne pas intégrer une perceuse, mais

plutôt de construire le bras, composé de 4 servomoteurs, afin qu’il tienne la pince (plus cohérent). Pour comprendre le montage

à réaliser, nous avons regardé des vidéos et fait quelques recherches. Nous nous sommes surtout basés sur cette image :

Figure 21 Photo d'un bras robotique

Nous avons donc réalisé ensuite des dessins de pièces sur LibreCad pour le lien entre les servomoteurs. Ceux-ci sont en bois.

Nous avions commencé par cette forme la :

Figure 22 Première pièce dessinée sur LibreCad

Sur les conseils du FabLab, nous l’avons modifiée pour cette forme :

Figure 23 Seconde pièce dessinée sur LibreCad, et choisie pour la conception

18

Celle-ci a un axe de symétrie sur sa longueur, donc elle sera plus résistante. De plus, les vis ne sont pas proches des bords de la

pièce, notamment grâce à l’arrondi pour celles du haut, ce qui diminue le risque de casse. Nous pouvons la découper grâce à la

découpe LASER dans une planche de contreplaqué.

Nous avons décidé d’utiliser deux pièces pour un lien entre deux servomoteurs afin de renforcer le bras sans trop l’alourdir

puisqu’il n’y a que de l’air entre les deux. Finalement, nous avons obtenu la forme voulue :

Figure 24 : Bras obtenu, position replié

Nous avons souhaité ajouter les capteurs et la pince grâce à une pièce en forme de disque en bois au bout du bras.

Malheureusement, le tout était bien trop lourd pour les servomoteurs. Nous avons donc décidé de ne laisser que la pince au

bout du bras, et de placer les capteurs sur la caisse, ce qui aurait de toute façon été le cas. Si nous souhaitons ajouter d’autres

éléments au bout du bras, il s’agira de changer les servomoteurs pour des plus gros, et donc de redessiner les pièces.

Pour terminer, nous avons souhaité ralentir le mouvement du bras car, malgré les pauses entre chaque rotation de moteur, le

déplacement était bien trop brusque. Nous avons donc créé la fonction go_to, qui permet de faire avancer le servomoteur degré

par degré, avec une pause entre chaque degré parcouru. La durée de cette pause dépend du poids du bras, et du mouvement

souhaité (plus ou moins lent). A terme, nous pourrons ajouter à cette fonction un test de détection d’obstacle, et décider

d’arrêter le déplacement en cas de présence d’un obstacle.

Figure 25 Fonction Go_To pour ralentir le mouvement des servomoteurs

Cette fonction utilise la méthode read pour connaître le nombre de degrés à parcourir. Or, cette méthode renvoie la dernière

valeur passée en paramètre de la fonction write. Nous ne pouvons donc pas utiliser cette fonction lors de l’initialisation,

puisqu’aucun write n’a encore eu lieu à ce moment-là. C’est pourquoi nous définissons une position initiale « naturelle » qui

permet, lorsque le bras est mis sous tension et que l’initialisation est effectuée, que les servomoteurs n’aient pas à beaucoup

changer de position et donc que les mouvements brusques ne cassent pas le bras.

Grâce à cette fonction, nous avons défini des fonctions pour plier et déplier le bras. Les valeurs des angles pour ces positions

ont été choisies de manière arbitraire et peuvent facilement être changées (tout comme celles de la position de repos, les

valeurs des servos à l’initialisation).

19

Figure 26 Fonctions pour plier et replier le bras

L’ordre des servomoteurs à changer de position a été étudié afin de réduire l’effort du bras, notamment lorsqu’il y a la pince au

bout. Il est en effet plus simple de relever le bras lorsqu’il est plié, plutôt que tendu avec du poids au bout par exemple.

Il aurait été intéressant de pouvoir offrir à l’utilisateur une fonction à laquelle nous passerions seulement la position souhaitée

du bras, au lieu de modifier les servomoteurs un par un, mais malheureusement, le temps a manqué pour réfléchir à cette

fonction.

Notre bras est opérationnel et peut être contrôlé !

20

I.3. La communication

La problématique est la suivante : comment envoyer depuis le site Web une requête à un capteur/outil en particulier ? Comme

nous l’avions déjà expliqué dans le premier rapport, nous utilisons une Raspberry sur Terre qui va recevoir les ordres du

serveur pour les communiquer à une seconde Raspberry sur Mars qui s’adressera à l’Arduino concernée. Il va maintenant

falloir réfléchir sur comment faire pour le réaliser en Python.

I.3.1 Raspberry Arduino

Tout d’abord, lors de la conception nous nous sommes intéressés à faire remonter les informations “d’un étage” : des capteurs

vers l’Arduino. Pour cela, nous avions repéré plusieurs protocoles possibles mais celui qui nous a convaincu c’est l’USB : il

permet à la fois de faire passer des informations et de l’énergie dans le même câble. Nous verrons plus tard que cette technique

a ses limites. La communication entre ces deux cartes s’est faite très rapidement : il suffit d’utiliser les fonctions read(), write()

et inWaiting() pour envoyer et recevoir des chaînes de caractères.

Dans le sens Arduino Raspberry, on envoie simplement le résultat du capteur pour l’instant donc il n’y a pas de mise en

forme spécifique. En revanche, dans le sens Raspberry Arduino, nous avons mis en place un système spécifique pour

pouvoir intégrer des arguments. Dans notre cas il s’agit uniquement d’un angle. Le premier caractère qu’on envoie est un

chiffre qui correspond au numéro de l’action que l’on veut utiliser sur l’Arduino (donc 10 actions maximum). Ensuite, tous les

caractères jusqu’au « # » forment l’angle désiré. Par exemple :

- 1# déclenche l’action n°1

- 282# déclenche l’action n°2 (supposée être sur un moteur) avec un angle de 82° en argument

Ce système suffit dans notre cas mais avec du recul on s’aperçoit qu’il n’est pas très optimisé : il fonctionne uniquement avec

des nombres, avec un seul argument et ne permet de faire que 10 actions différentes par Arduino. Pour remédier à cela tout en

utilisant un protocole toujours très proche, il faudrait utiliser des séparateurs. Par exemple : 2$82#. Cela voudrait dire la même

chose mais permettrait d’utiliser 13$82# si on ne veut plus de l’action n°2 mais de l’action n°13, ce qui n’aurait pas été

possible dans le cas précédent.

I.3.2 Raspberry Raspberry

Nous utilisons les dongles USB Era Connect2-Pi vu dans le rapport bibliographique. Ces dongles USB sont censés être « easy-

to-use » et permettre de communiquer facilement ensemble. Cependant, nous nous sommes aperçus dès les premières heures

passées à les utiliser que le script qui était fourni n’est pas fonctionnel et ne satisfait pas notre application. Pour mieux

comprendre comment l’utiliser, nous nous sommes inspirés de quelques lignes et nous les avons réutilisés dans des scripts que

j’ai faits moi-même : un pour chaque Raspberry.

La phase la plus compliquée a été de réfléchir à la machine à état de chaque Raspberry. Dans un premier temps, nous avons

essayé de réaliser une machine à états complexe qui vérifiait à chaque fois qu’une donnée était envoyée si elle était bien reçue.

Ceci complexifiait énormément le script qui attendait en permanence la vérification que le message soit bien reçu par l’autre

partie. En théorie, ceci était censé garantir que le message arrive bien mais en pratique le comportement était très chaotique car

les messages d’acquittement (envoyés pour confirmer la bonne réception de la requête par exemple) arrivaient parfois trop tard

et donc la machine à état s’était remise dans l’état initial et interprétait donc le message d’acquittement comme une requête.

Cette « requête » n’étant pas conforme, on envoyait alors un message d’erreur à Mars pour dire de renvoyer une requête

conforme mais ce message était « inattendu » pour la Raspberry sur Mars qui va donc mal interprété ce message etc…

Pour éviter ces problèmes, nous avons donc décidé de ne pas se charger des vérifications : on envoie un message sans être sûr

qu’il ait bien été reçu. La seule vérification qu’on fait est temporelle : si on au bout d’un certain temps nous n’avons toujours

pas de réponse, on considère la requête perdue. Cela est plus cohérent avec la réalité car avec des communications

interplanétaires, si on attend la confirmation de la bonne réception du message avant de continuer on risque de perdre

énormément de temps. On verra dans les améliorations possibles qu’il y a moyen de contourner ce problème.

21

Finalement, nos scripts suivent les pseudo-algorithmes suivants :

Figure 27: Pseudo algorithme sur Terre

Figure 28: Pseudo-algorithme sur Mars

On voit dans ces algorithmes qu’on différencie deux types de requête : les requêtes de données et les requêtes

d’action. Les requêtes d’actions sont les « Do » : on demande de bouger un servomoteur ou de faire une nouvelle mesure sur

un capteur. Les requêtes de données sont les « Get » : on demande le résultat d’un capteur qui a été enregistré après le « Do ».

Ce choix a été fait car pour un servomoteur par exemple, on n’attend pas de valeur de retour. Pas besoin de requête de données.

De plus, pour un capteur, si on fait un « Do » puis un « Get », mais que la transmission échoue, on peut refaire uniquement le

« Get » sans avoir à refaire une nouvelle mesure, ce qui parait plus logique. Nous verrons que cette méthode fonctionne, mais

qu’il peut être amélioré.

22

I.3.3 Protocole

Il a fallu choisir comment transmettre l’ordre et au moins un argument (l’angle du moteur qu’on souhaite). C’est

pourquoi nous avons défini notre propre protocole :

Figure 29: Protocole de requête

Ce protocole permet de faire la distinction entre requête de données ou d’action. On juxtapose simplement les différents

champs, qu’on peut extraire facilement par division par 10 et modulo. Cette manière de faire a l’avantage d’être facile

d’utilisation. Par exemple :

- 167028 signifie qu’on veut mettre un angle de 167° sur le moteur n°8 de l’Arduino n°2

Cependant, on voit que le n° de l’action est compris entre 0 et 9, ce qui signifie qu’on ne peut pas en faire plus de 10

différentes. Pour plus de flexibilité, il faudrait utiliser des séparateurs entre chaque champ (comme une virgule : 167,0,2,8).

I.3.4 Fichiers

Pour pouvoir faire le lien entre la requête d’action et le requête de données, il faut pouvoir sauvegarder le résultat en

mémoire. Dans un premier temps nous utilisions une simple liste mais nous utilisons désormais un système de fichiers afin de

pouvoir garder un historique des données. A chaque capteur on associe un petit fichier sur la Raspberry du Rover qui

ressemble à celui-ci :

Figure 30: Sensor file

On peut voir que chaque ligne correspond à une nouvelle valeur. On définit une ligne par une date séparée de la valeur relevée

par un ‘$’. Ainsi, dans une version ultérieure on pourrait facilement proposer à l’utilisateur la date du relevé en plus de la

valeur.

I.3.5 Mode debug

Enfin, pour facilement debugger le programme, nous utilisons une variable globale booléenne qui permet de savoir si

on veut faire passer les messages dans la console ou les faire arriver du site web. La première option est beaucoup plus pratique

pour pouvoir envoyer des instructions qui permettent de faire des « corner simulation » afin de s’assurer de la robustesse du

système.

23

I.3.6 Changement de méthode de transmission

Toute notre structure fonctionnait parfaitement jusqu’à ce qu’on l’alimente avec une batterie. En effet, nous avons

remarqué que lorsque le système était alimenté par une batterie, les mouvements des moteurs n’étaient plus « lisses » mais

saccadés. Après avoir passé du temps à essayer d’y remédier, nous avons détecté le problème : l’Arduino qui contrôle les

moteurs est à la fois alimentée par la batterie (pour résoudre le problème de masse) et par la Raspberry via le câble USB qui

alimente en plus d’envoyer des données. C’est surement cette double alimentation qui pose problème. Pour éviter cela, il faut

changer le protocole de communication entre la Raspberry et l’Arduino.

Sur conseil du FabLab, nous utilisons désormais la librairie SoftwareSerial d’Arduino qui permet d’utiliser les pins

digitales pour simuler une communication UART. On a juste à changer quelques lignes dans le code et à utiliser le câble

suivant :

Figure 31: Câble USB/Tx-Rx

En veillant bien à croiser Tx et Rx, on a rapidement pu observer que notre problème était résolu ! On voit bien dans ce

cas la force de notre structure qui est facilement modulable et qui permet de changer un lien ou un outil sans avoir à modifier

l’ensemble de la structure.

I.4. Le site web

Maintenant que la communication est opérationnelle, il faut donner la possibilité à l’utilisateur d’envoyer des ordres. Pour

cela, nous avons songé à faire soit un site web, soit une application mobile. Notre choix s’est porté vers le site web car ce

dernier peut fonctionner sur mobile alors qu’une application ne peut pas fonctionner sur ordinateur. De plus, on peut réutiliser

nos connaissances de Peip et donc aller plus vite au résultat.

I.4.1 Squelette du code

On peut faire facilement un site web depuis une Raspberry, c’est pourquoi on avait choisi d’utiliser cette carte à l’origine.

Nous utilisons dans notre cas la librairie « Webpy » car nous nous inspirons d’un tutoriel qui utilise un système similaire (lien

dans la bibliographie). Cette librairie nous permet de gérer les requêtes POST et GET nécessaires au fonctionnement du site

Web. On veut pouvoir envoyer des ordres en appuyant sur des boutons, rentrer des valeurs des champs adéquats et pouvoir lire

les résultats. Rapidement, nous avons pu obtenir un premier résultat :

Figure 32: Site web v0

Le plus difficile c’est de gérer les requêtes. En effet, il faut pouvoir savoir quand on clique sur un bouton sur quel bouton on a

appuyé afin de pouvoir envoyer le bon code à la Raspberry Martienne. L’avantage de l’interface, c’est que le protocole est

complètement transparent pour l’utilisateur.

24

I.4.1 Vérification des saisies de l’utilisateur

Etant donnée qu’on offre à l’utilisateur la possibilité de saisir un angle d’un moteur dans une boite de saisie, il a fallu s’assurer

que l’information saisie est correcte, c’est-à-dire un nombre compris entre 0 et 180 (ou une autre plage, dépendant du

servomoteur).

Figure 33 Boite de saisie

Pour faire cela, nous pouvons vérifier “à la main” ou alors utiliser les outils de HTML5. En effet, en HTML, on peut imposer

que l’utilisateur ne puisse saisir que des chiffres et vérifier que la valeur soit correcte avant de valider :

Figure 34 Boite de saisie, avec vérification

Avec cette précaution, impossible d’envoyer une requête invalide.

I.4.3 Compatibilité

Désormais nous avons un site web fonctionnel, mais qui est plutôt austère et qui ne s’affiche pas très bien sur

smartphone. Pour pouvoir utiliser notre site web depuis n’importe quel périphérique, il faut pouvoir le rendre responsive, c’est-

à-dire qu’il s’adapte à la taille de l’écran afin d’avoir toujours un site utilisable et plaisant à regarder.

N’ayant pas une grande expérience en CSS, nous avons utilisé un template que nous avons adapté à notre système. Ce

template s’adapte parfaitement à la taille de la fenêtre et permet même d’avoir une petite interface plaisante (menu déroulant

etc…). Il nous a donc suffit de rajouter nos items (textarea, label et boutons) pour pouvoir obtenir un résultat satisfaisant. Voici

le résultat sur ordinateur et sur téléphone :

25

26

On voit bien ici que l’on peut utiliser notre système de façon identique sur les deux plateformes.

II.5. Synthèse

Une fois le système de communication mis en place et relié aux capteurs et outils, on peut enfin tester notre système

dans son intégralité avant de l’intégrer sur la « vraie » maquette du Rover :

Figure 35 Système de transmission entier et opérationnel reliant le site Web aux capteurs et outils

Notre système est fonctionnel : on peut envoyer des ordres depuis le site Web et les voir s’exécuter en temps réel.

Chaque partie de notre projet peut être optimisée : meilleurs capteurs, meilleur protocole de communication, meilleur site web

etc… Mais la force du projet réside en son squelette qui lui offre une certaine modularité : on peut changer un capteur

facilement, on peut changer de méthode transmission facilement etc. Notre objectif que nous nous étions fixé pour ce projet

était de faire fonctionner la chaine d’information décrite plus haut qui est le squelette du projet. Cet objectif est atteint et nous

sommes donc satisfaits. Nous avons même pu implémenter d’autres fonctionnalités.

27

La base du projet étant désormais fonctionnelle, nous avons essayé de permettre aux futurs utilisateurs du projet de

pouvoir facilement l’utiliser et d’y intégrer des nouvelles fonctionnalités. Pour cela, nous avons détaillé au maximum notre

code, nous avons fait une notice explicative que vous trouvez en annexes et nous avons annotés les différents fils pour pouvoir

facilement rebrancher un fil qui se serait débranché.

Finalement, la dernière étape du projet a été de monter notre système sur la maquette qu’a conçu Maéva. Le résultat est

fonctionnel et très satisfaisant :

Figure 36 Montage final

28

III / Comparatif entre le planning et la BOM prévisionnels et réels

III.1. Le planning

Commençons par rappeler notre planning prévisionnel, avec nos principales étapes de conception à valider.

Figure 37 Planning prévisionnel

Coralie Matt

29

Grâce à notre cahier de laboratoire sur Moodle dans lequel nous avons consigné toutes nos avancées et le déroulement de nos

séances de travail, nous pouvons dresser le planning réel que nous avons finalement suivi lors de la conception du Rover.

Figure 38 Planning réel

Matt

Coralie

30

Concernant la partie des capteurs et des servomoteurs, le retard n’en est pas vraiment un, notamment pour les deux

premiers points de passage. En effet, nous avons mélangé ces deux objectifs puisque nous n’avions pas encore le script

fonctionnel pour chaque capteur en standalone que nous commencions déjà à programmer avec plusieurs capteurs (deux pour

commencer, réactif à une saisie dans la console). Cela est dû au fait que nous avons dû attendre certains capteurs plus

longtemps que prévu (Geiger, luminosité), donc nous voulions tout de même avancer. Nous avons rapidement commandé un

servomoteur seul, mais nous avons dû atteindre la réception des servomoteurs du bras et de la pince pour tester le code avec

plusieurs moteurs (pas tous, car il a fallu la batterie pour les alimenter).

Le temps restant du projet a été mis à profit pour construire le bras, ce qui a pris beaucoup de temps, et pour

l’optimiser au maximum dans le temps imparti. Malgré ces décalages, les objectifs ont été atteints.

Concernant la partie transmission et site Web, le timing a été respecté sur les premiers objectifs car la communication

Arduino / Raspberry a été facilement mise en place. De plus, malgré le retard pris à refaire un script fonctionnel pour

communiquer entre les deux Raspberry, cette partie a tout de même été finie en avance par rapport au planning. Cependant, la

suite du projet a été retardée (site web et assemblage) car nous avons voulu optimiser les scripts de transmission (même s’ils

étaient déjà fonctionnels) pour avoir une base plus simple et tout autant fonctionnelle avant de continuer.

III.2. La BOM

Tout comme le planning, nous avions estimé le coût de notre projet. Nous n’avions pas estimé le nombre d’heures de travail à

fournir et donc le coût de main d’œuvre, ce que nous allons ajouter maintenant.

Voici la BOM prévisionnelle que nous avions réalisé (653 euros):

Matériel Quantité Coût total estimé (en euros)

Raspberry Pi 3B + Carte micro-SD avec Raspbian 2 100

Ecran tactile pour Raspberry 2 131.6

Support pour écran tactile 2 75.6

Clavier sans fil 2 60

Alimentation 5V 2 12.1

Carte d’extension Raspberry GertBoard 1 30.7

Arduino Uno 2 30

Jumper femelle/femelle 30 1.28

Jumper mâle/femelle 20 1.35

LPRS ERA Connect2 Pi 868MHz 2 84

DHT 11 (température et humidité) 1 4.7

MPL3115A2 (pression et altitude) 1 14

MQ-7 (Monoxyde de carbone) 1 6.8

FC-51 (proximité IR) 1 1.4

SFR05 (proximité Ultrasons) 1 20.5

Uugear light sensor module (luminosité) 1 3.3

31

MG955 (servomoteurs pince) 2 39

Pince 1 25

Perceuse 1 11.4

Figure 39 : BOM Prévisionnelle

Voici maintenant la BOM réelle du matériel que nous avons utilisé. Certains éléments ont été rajoutés, puisque certaines

réalisations n’étaient pas prévues.

Matériel Quantité Coût total estimé (en euros)

Raspberry Pi 3B + Carte micro-SD avec Raspbian 2 100

Ecran tactile pour Raspberry 2 131.6

Support pour écran tactile 2 75.6

Clavier sans fil 2 60

Alimentation 5V 2 12.1

Carte d’extension Raspberry GertBoard 1 30.7

Arduino Uno 2 30

Jumper femelle/femelle 30 1.28

Jumper mâle/femelle 20 1.35

Adaptateur DC femelle / Jack 1 3.71

Cable Adaptateur USB / UART RS 232 1 9.99

LPRS ERA Connect2 Pi 868MHz 2 84

DHT 11 (température et humidité) 1 4.7

MPL3115A2 (pression et altitude) 1 14

MQ-7 (Monoxyde de carbone) 1 6.8

SFR05 (proximité Ultrasons) 1 20.5

BH1750 FVI (luminosité) 1 3.18

Compteur Geiger 1 82.2

Sperkfun mpu-9250 sen-13762 (Gyroscope) 1 18.4

Hitec HS-422 (servomoteurs pince) 2 19.9

Hitec HS-755HB (servomoteurs bras) 2 49.8

Hitec HS-805HB (servomoteur bras) 1 43.95

32

MG-995(servomoteur bras) 1 14.33

Pince Lynxmotion 1 34.21

RB-Sct-164 (bloc porteur servomoteur bras) 1 156

Rallonge câbles servomoteur 1 12.42

Vis et écrous 30 7

Scotch double face mousse 1 10,18

Batterie 12V 6Ah 1 30

Chargeur 1 50

Plaque contreplaqué 80*40 cm ep. 5mm 2 10.5

Figure 40 : BOM réelle

Le coût du matériel s’élève donc à 1128.4 euros. Ce montant est supérieur à celui estimé en début de projet. Cela est

notamment dû au changement de direction prise pour la conception : la perceuse a été remplacé par le bras robotisé, qui

contient 6 servomoteurs, dont certains très puissants, ainsi qu’une alimentation externe et son chargeur, ce qui coûte plus cher.

Nous avons aussi ajouté le compteur Geiger dont le prix n’est pas négligeable. Cette différence aurait pu être encore plus

grande si nous avions eu l’occasion d’ajouter d’autres capteurs (comme le spectromètre). Pour la communication et le site web,

aucun matériel supplémentaire n’a été nécessaire mise à part l’adaptateur USB pour mettre en place le port série software.

Nous avons maintenant estimé notre nombre d’heures de travail, et le coût correspondant en choisissant un salaire d’ingénieur

à l’heure de 15 euros. En effet, nous avons fait des recherches internet et choisi de prendre comme valeur de référence 2500

euros brut par mois pour un ingénieur débutant. Nous avons ensuite considéré 4 semaines dans le mois, et 40 heures de travail

par semaine. Soit 2500/(4*40) = 15,6 ~ 15 euros.

Les 59 et 64 heures de conception correspondent aux heures encadrées prévues dans l’emploi du temps (Coralie a 5h de moins

car elle a raté une séance pour maladie). Les 30h supplémentaires correspondent à une estimation des heures effectués en

dehors des créneaux affectés.

Les heures de réunion sont celles de la présentation intermédiaire, deux fois 3h.

Enfin, nous avons estimé notre temps de rédaction du rapport et de préparation de la présentation orale en anglais réalisée.

Nom Tâche Nombre d’heures Salaire / heure Coût total de la tâche

Coralie Arnoux Conception 59h + 30h 15 € 1335 €

Matt Juillet Conception 64h + 30h 15 € 1410 €

Coralie Arnoux Réunion 6h 15 € 90 €

Matt Juillet Réunion 6h 15 € 90 €

Coralie Arnoux Rapport 20h 15 € 300€

Matt Juillet Rapport 20h 15 € 300€

Figure 41 Estimation du coût de main d'œuvre

Soit un coût total de 3525 € (sans considérer un écart de salaire entre homme ou femme !).

Dans l’ensemble, nous estimons le coût total du projet (matériel + main d’œuvre) à 4653.4 €. A ceci devrait s’ajouter, dans une

vraie entreprise, le coût de l’électricité et le loyer des locaux par exemple.

33

IV / Amélioration sur notre partie du projet

Nous aurions aimé ajouter d’autres éléments comme le spectromètre, mais celui-ci n’a jamais été disponible sur les sites de

vente. Si l’occasion se présente, l’intégration de cet appareil devrait être facilitée par notre code qui se veut générique,

modulable et modifiable facilement, notamment avec l’instruction « switch » et nos commentaires.

Comme nous n’avons pas intégré de perceuse, puisque nous avons remplacé cette charge de travail par la conception du bras, il

s’agira certainement d’en intégrer une sur le bras. Néanmoins, il faudra trouver un moyen de diminuer la charge du bras, car

rien que la pince exerce un poids important. Il faudra peut-être changer les servomoteurs pour des plus puissants, et donc

redécouper des pièces adaptées (changer les dimensions dans le fichier source de la pièce actuelle que nous fournissons).

Pour plus de facilité d’utilisation du bras par l’utilisateur, nous aurions aimé pour le diriger en indiquant simplement une

position comme objectif, et donc ne pas avoir à manipuler les moteurs un par un. Nous n’avons malheureusement pas eu le

temps de mettre au point cet algorithme.

Nous avions décidé avec Mr Lorenzini de caractériser le compteur Geiger grâce générateur rayons X de la salle de TP. Nous

avons vérifié sa cohérence (augmentation de la valeur lorsque les particules injectées sont plus nombreuses) mais nous n’avons

pas eu le temps d’aller plus loin. Il serait intéressant de fournir à Mr Lorenzini, qui s’est proposé de nous aider en faisant des

relevés, un code permettant de faire des relevés à intervalle de temps régulier et avec une certaine dose de particules afin

d’obtenir des courbes de réponse du capteur puisqu’il était tout à fait d’accord pour le faire.

Nous aurions aimé, à l’aide des données recueillies par les capteurs, afficher sur le site web des graphiques montrant

l’évolution des données ou des statistiques. Ceci est faisable étant donné qu’on stocke déjà en mémoire l’ensemble des valeurs.

De plus, nous avons mis en place dans le fichier lié au Rover une date. Or, pour le moment, nous ne renvoyons que la dernière

valeur enregistrée. Il pourrait être intéressant d’offrir à l’utilisateur la possibilité de choisir quelle valeur il veut recevoir en

fonction de la date.

Le système étant fonctionnel, il aurait fallu tester la portée des modules RF pour vérifier la différence entre la donnée

constructeur (200m) et la réalité. On pourrait aussi vérifier la robustesse de ces modules aux obstacles.

Le protocole qu’on utilise aujourd’hui pour la transmission Terre/Mars fonctionne mais pour plus de flexibilité, il serait

intéressant de le changer pour le suivant :

- Depuis la Terre, on envoie un ordre, sans attendre la réponse

- En permanence, sur Terre, le module RF écoute les messages en provenance de Mars (ce que fait déjà le module USB,

qui agit comme une FIFO qui attend qu’on vienne lire les données reçues avant de les effacer). Quand on lit le

message, on sait de quoi il s’agit car on indique sa provenance (le code de l’Arduino + capteur par exemple).

- On actualise le site Web avec la valeur obtenue.

Ce changement permettrait de mieux travailler en parallèle : quand on lance une requête, on peut tout de suite en envoyer une

autre sans attendre. De plus, il éviterait la procédure « Do / Get » : on fait juste le « Do », le « Get » se fait automatiquement

quand la réponse est reçue.

Un protocole similaire sur la liaison Raspberry/Arduino serait judicieux car à l’heure actuelle on ne peut pas travailler en

parallèle sur plusieurs Arduino étant donné qu’on attend que la première action soit finie avant de passer à la suivante.

Nous avions utilisé des cartes Arduino/Raspberry dans notre première version du projet afin de pouvoir obtenir un système

fonctionne rapidement, ce qui a été le cas. Cependant, pour plus de professionnalisme mais aussi une meilleure utilisation des

ressources il serait intéressant de faire évoluer ces cartes pour d’autres plus adaptées comme des STM32.

Enfin, nous aurions aimé traiter le cas de la transmission de fichier lourds comme des photos ou vidéos : la taille étant plus

importantes, il aurait sûrement fallu découper la photo en petits morceaux pour la reconstruire une fois entière sur Terre.

34

Conclusion

Nous avons atteint les objectifs que nous nous étions fixés et nous avons réussi à aller au-delà de certains. Nous

sommes conscients que de nombreux points peuvent être optimisés mais nous sommes satisfaits d’avoir construit une base qui

fonctionne et qui va pouvoir être utilisée par la suite.

Le site web que nous avons conçu est fonctionnel et permet bien, à l’aide des protocoles de communication mis en

place d’avoir accès aux données des capteurs et de contrôler les servomoteurs.

Grâce à ce projet nous avons pu travailler sur notre autonomie et notre capacité à réagir aux problèmes. Nous avons

désormais des compétences plus complètes en électronique, en informatique et en gestion de projet. Nous nous sommes

aperçus que la majorité de travail n’était pas tant dans la phase de réalisation mais dans la phase de réflexion durant laquelle on

choisit l’architecture du projet.

Notre participation à ce projet dans le cadre des projets industriels est terminée, mais nous espérons pouvoir continuer

de nous impliquer dans ce travail qui a bien avancé mais qui n’est pas encore achevé.

35

Bibliographie

https://www.ingenieurs.com/infos/salaire-ingenieur-1535.php

https://github.com/MonsieurV/ArduinoPocketGeiger

https://github.com/claws/BH1750

https://www.arduino.cc/en/reference/wire

http://playground.arduino.cc/Code/NewPing

http://playground.arduino.cc/Main/DHTLib

https://github.com/sparkfun/MPL3115A2_Breakout/tree/V_H1.1_L1.2.0/Libraries/Arduino

https://playground.arduino.cc/ComponentLib/Servo

https://www.youtube.com/watch?v=EboS66RUk5o

https://www.youtube.com/watch?v=4MbcqUL4FfM

http://eduscol.education.fr/sti/sites/eduscol.education.fr.sti/files/ressources/pedagogiques/4346/4346-7-rpi-serveur-web.pdf

36

Annexe A : Comment utiliser notre projet ?

Notre partie du projet Rover permet de récupérer les données des capteurs sur le Rover et de contrôler ses moteurs (pour

l’instant, ceux du bras). Pour pouvoir mieux comprendre, et pour faciliter la suite pour les prochaines personnes qui

travailleront sur le Rover, voici une petite notice !

I/ Le câblage

Les capteurs et servomoteurs

En théorie, rien à faire ! Les fils de commande des servomoteurs sont branchés à une Arduino dédiée, tandis que les

capteurs sont branchés à une seconde Arduino (en passant par une breadboard). Les fils sont annotés de façon à ce que l’on

puisse facilement refaire le montage en cas de débranchement. Il y a aussi un code couleurs : rouge et blanc pour le 5V, violet

pour le 3.3V et marron, noir ou gris pour la masse.

Les servomoteurs sont alimentés par la batterie au travers des 4 cartes d’adaptation

12V -> 5V. Attention, si jamais vous souhaitez rajouter des servomoteurs ou d’autres outils, il faudra veiller à bien répartir

ceux-ci : nous nous sommes aperçus que si nous mettions le « gros » servomoteur sur le même contrôleur qu’un « petit »

servomoteur, cela posait problème quand le « gros » servomoteur avait besoin de faire un gros effort (il perd sa position).

Figure 42 Montage des câbles

Les Arduinos

Toujours rien à faire ! L’Arduino des capteurs est alimentée directement par le câble USB qui fait aussi office de

canal de transmission avec la Raspberry « Martienne ». L’Arduino des moteurs quant à elle est alimentée par la batterie, pour

les raisons vues dans le compte-rendu final. Elle communique avec la Raspberry via le câble USB/Tx-Rx qui lui aussi est

annoté. On ne se sert pas du fil rouge de ce même câble car on n’alimente pas l’Arduino ainsi.

37

Les Raspberry

Il va falloir commencer à travailler :

- Etape 1 : Alimentation. Pour l’instant, les Raspberry sont alimentée sur secteur mais à terme elles seront

alimentées elles aussi par la batterie. Branchez les deux Raspberry, elles démarrent !

- Etape 2 : Canaux de communication. Attention, car si cette étape est mal faite (ou si vous n’avez juste pas de

chance), il faudra faire des modifications par la suite.

o Avant (ou après bien sûr) que les Raspberry démarrent, vous pouvez déjà brancher sur chaque Raspberry

les dongle USB Connect-2-Pi 868MHz qui servent de transmetteurs radio. Ils se brancheront si tout va

bien aux ports « /dev/ttyUSB0 » de chaque Arduino

o Avant (ou après, ici aussi, ce n’est pas gênant), vous pouvez brancher par USB l’Arduino qui gère les

capteurs à la Raspberry « Martienne ». Si tout va bien, elle se connectera au port « /dev/ttyACM0 ».

o Une fois que la Raspberry Martienne est démarrée, et seulement à cette condition, vous pouvez branchez

l’Arduino qui gère les servomoteurs via le câble USB/Tx-Rx. Cette opération doit être faite

obligatoirement après le démarrage pour être sûr (ou presque) qu’elle se connecte au port

« /dev/ttyUSB1 » et non pas « /dev/ttyUSB0 ». En effet, si c’était le cas, aucun message d’erreur

n’empêcherait l’exécution mais le système ne fonctionnera pas. Cette erreur est difficilement détectable,

donc mieux vaut l’éviter !

Attention : Si, pendant qu’une Raspberry est allumée, vous débranchez un câble pour le rebrancher, il y a de

très grandes chances qu’il change de port ! Dans ce cas, il faudra soit redémarrer la Raspberry pour que

l’affectation se refasse correctement, soit modifier manuellement le port dans le script (en essayant avec

USB2 par exemple). On a aussi remarqué que, au cours de l’exécution, il y a eu un changement de port. Cela

est peut-être dû au démarrage et redémarrage avec l’interrupteur. Il doit sûrement exister un moyen

d’automatiser cette procédure d’affectation de façon à ce qu’il n’y ait plus d’erreur mais à l’heure où j’écris

ces lignes c’est le meilleur moyen que j’ai trouvé.

II/ Les scripts

Le câblage terminé, on va pouvoir maintenant démarrer les scripts.

Les Arduino

Rien à faire ! Les Arduino sont déjà programmées. Si cependant vous souhaitez modifier le programme propre à

chaque Arduino, il faudra bien sûr simplement le téléverser à nouveau via les câbles USB.

Les Raspberry

Ici, un peu de travail :

- Etape 3 : lancement du script « Martien ». Il suffit d’aller dans l’explorateur de la Raspberry. Le script

se trouve à l’emplacement /home/pi/Rover/Current-VXX/Mars. Un simple double-clique ouvre le

fichier et ensuite F5 lance l’exécution.

Remarque:

A ce moment, si vous avez bien travaillé, vous devriez voir apparaitre :

……………………………………………………….

………………………. MARS ………………..….

……………………………………………………….

Si en revanche, une erreur apparait, il y a 99% de chance à ce qu’il y ait un problème de câblage : un

câble n’est pas branché ou alors est mis sur le mauvais port. Dans la deuxième hypothèse, il faut identifier le

port qui fait défaut et tenter de le modifier à la main (remplacer ACM0 par ACM1, ou USB1 par USB2 dans

la définition du port série dans le script).

- Etape 4 : lancement du script « Terrien ». Idem que le script Martien ! Le chemin est le même, il suffit de

remplacer « Mars » par « Terre », évidemment. De plus, il y a quasi aucune chance qu’il y ait de problème de

câble. Attention néanmoins, la Raspberry Terrienne doit être connectée au même réseau que le PC, la tablette ou

le smartphone depuis lequel vous voulez contrôler le Rover ! En effet, c’est par ce biais qu’on va communiquer

avec le site Web. Un simple téléphone en mode routeur fera l’affaire (ça n’utilise pas de data, c’est en local !). Il

pourra être intéressant par la suite de donner accès au Rover depuis la Terre entière, mais il faudra penser au

problème de piratage.

38

- Etape 5 : identifier l’adresse IP. Pour l’instant, on fonctionne en local donc il faut connaitre l’adresse sur laquelle

se connecter. Il suffit d’utiliser la console de la Raspberry et de taper « ifconfig ». Dans le dernier paragraphe

(wlan0), vous devriez voir l’adresse IP après « inet addr : » qui doit être sous la forme 192.168.XXX.XXX ou

10.212.XXX.XXX généralement (ça peut être autre chose, bien entendu). Retenez la bien, on s’en sert tout de

suite !

III/ Let’s go !

- Etape 6 : S’amuser.

Les câblages sont parfaits, le script sont démarrés, l’adresse IP est connue : il ne reste plus qu’à jouer ! Allez sur votre

navigateur préféré depuis votre périphérique préféré. Saisissez l’adresse IP trouvée plus haut, suivi de « :8080 ». Pour ma part

par exemple, ça donne : 192.168.0.25:8080.

Vous êtes connecté ! (J’espère pour vous en tout cas). Pour l’instant, sur le site Web, tout ne fonctionne pas. Il y a une interface

« fictive » qui avec un menu déroulant et des liens mais ils sont tous inactifs ou presque. Les seules fonctionnalités que sont

utilisables pour le moment sont les suivantes :

- Les boites de saisie qui vous permettent de choisir l’angle des 5 moteurs du bras. Ils sont numérotés de 1 à 5, du

plus proche de la caisse au plus éloigné. Le 1 correspond par exemple à la rotation du bras autour de l’axe des Z

(qui pointe vers le ciel), qui porte l’étiquette « Servo A ». Ces boites de saisie sont « intelligentes » : vous ne

pouvez saisir que des nombres qui sont dans un intervalle bien défini (et que vous pourrez changer à votre

convenance dans le code index.html).

- Les boutons, qui déclenchent des actions ou des demandes d’informations. Initialement le résultat est « Empty »

mais il suffit de faire « Get » pour obtenir la dernière valeur à ce jour, ou alors « Do » puis « Get » pour avoir une

nouvelle valeur !

Si vous avez un souci, contactez-nous : matt.juillet@gmail.com ou arnoux.coralie@gmail.com

39

Annexe B : Quelques illustrations

Figure 43 Batterie, câblage, interrupteur

Figure 44 Rover vue de face

40

Figure 45 Capteurs

Figure 46 Bras robotisé