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

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

2
 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

3
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

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

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

6
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

7
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

8
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

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

10
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

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

12
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

13
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

14
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

15
 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

16
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

17
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).

18
 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é !

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

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

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

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

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

24
25
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.

26
 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

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

Coralie Matt

Figure 37 Planning prévisionnel

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

Coralie Matt

Figure 38 Planning réel

29
 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

30
 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

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

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

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

34
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

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

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

37
 - 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 : [email protected] ou [email protected]

38
Annexe B : Quelques illustrations

Figure 43 Batterie, câblage, interrupteur

Figure 44 Rover vue de face

39
 Figure 45 Capteurs

Figure 46 Bras robotisé

40