ENSTA Paris

Shell Eco-Marathon

Rapport final de PIE

Groupe P16
Table des matières
1 Introduction 3

2 Dossier de conception 4
2.1 Organisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Pôle motopropulseur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.1 Exigences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.2 Risques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.3 Principaux tests envisagés . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.4 Livrables matériels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.5 Livrables documentaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.6 Choix du moteur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.7 Conception du contrôleur du moteur . . . . . . . . . . . . . . . . . . . . . . 9
2.2.8 Montage électronique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3 Pôle châssis/carosserie/direction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3.1 Exigences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3.2 Risques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3.3 Livrables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3.4 Tests envisagés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.4 Pôle systèmes embarqués . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.4.1 Exigences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.4.2 Risques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.4.3 Livrables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.4.4 Tests envisagés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.5 Livrables globaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3 Dossier de réalisation 14
3.1 Pôle motopropulseur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2 Pôle châssis/carrosserie/direction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2.1 Coque/châssis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2.2 Roues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2.3 Choix du siège . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.3 Pôle systèmes embarqués . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.3.1 L’interface graphique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.3.2 Affichage de la trajectoire . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.3.3 Calcul de la trajectoire optimale . . . . . . . . . . . . . . . . . . . . . . . . 20

4 Principales difficultés rencontrées 21

4.1 Pôle motopropulseur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.2 Pôle châssis/carrosserie/direction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.3 Pôle systèmes embarqués . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.4 Sponsors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

5 Documents et conseils pour la prochaine équipe 23

5.1 Pôle motopropulseur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5.2 Pôle châssis/carrosserie/direction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5.3 Pôle systèmes embarqués . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5.4 Communication du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Références 25
Figure 1 – Équipe 2019-2020

2
1 Introduction
Le Shell Eco-marathon est une compétition étudiante internationale où les équipes construisent
la voiture la plus économe en énergie possible. Des étudiants de l’ENSTA Paris se préparent à cette
compétition depuis désormais 4 ans, sans compter de participation à ce jour.

Ce projet promeut l’ingénierie, l’économie des ressources et la cohésion d’équipe et s’inscrit donc
parfaitement dans le cadre de la formation dispensée à l’ENSTA Paris.

L’équipe est divisée en trois pôles (châssis/carrosserie/direction, systèmes embarqués et moto-

propulseur), chacun en charge d’une partie différente du prototype.
— Pôle motopropulseur : il est chargé d’assurer la propulsion du véhicule. Plus précisément,
il est chargé d’assurer la transmission entre la roue et le moteur, de faire tourner ce dernier à
la vitesse souhaitée par le pilote grâce au contrôleur, tout en minimisant la quantité d’énergie
utilisée. Enfin il est chargé de récupérer l’énergie obtenue lors du freinage et de la stoker
et/ou la réinjecter directement dans le moteur ;
— Pôle châssis/carrosserie/direction : c’est lui qui se charge de la création d’une nouvelle
coque pour le prototype. Il lui incombe donc la modification de la géométrie du véhicule, et
l’adaptation du châssis en conséquence. En parallèle, le pôle est également chargé d’améliorer
tous les aspects en rapport avec la direction (roues, pneus, volant, ...) ;
— Pôle systèmes embarqués : il possède deux missions principales : Créer une interface
graphique utilisateur sur un écran de 7 pouces pour indiquer au pilote la meilleure trajectoire
à adopter en temps réel, et calculer la trajectoire idéale en fonction du circuit puis corriger
celle-ci en fonction des écarts.

3
2 Dossier de conception
2.1 Organisation
Comme présenté en introduction, le projet est divisé en trois pôles, ce qui permet une paral-
lélisation des tâches et ainsi un travail plus efficace. Cependant, cette séparation peut causer un
effet tunnel si une communication suffisante n’est pas assurée entre les pôles. Pour éviter cela, nous
avons commencé par réaliser un calendrier commun sous forme de diagramme de Gantt. Celui-ci
comporte des étapes clés nécessitant le travail de plusieurs pôles. Il permet également à chaque
pôle de connaître l’avancement des autres membres de l’équipe.

Figure 2 – Diagramme de Gantt

De plus, des membres de l’équipe ont été sélectionnés pour réaliser le lien entre les différents
pôles afin de conserver un contact permanent.
Enfin, des réunions étaient organisées à la fin de chaque séance entre tous les membres afin de faire
le point sur le travail réalisé et de définir les prochains objectifs.

Une matrice SWOT a également été réalisée afin de cerner les forces et les faiblesses de l’équipe.

Figure 3 – Matrice SWOT

4
2.2 Pôle motopropulseur
Nous avons commencé cette année scolaire 2019/2020 par étudier le dossier fixant les règles du
concours, rédigé par les organisateurs. Ceci nous a été fort utile pour notre démarche d’ingénierie
système car cela nous a conduit à définir nos exigences, nos risques... Par ailleurs le règlement de
l’année 2019/2020 stipule que le contrôleur du moteur doit être créé par les étudiants. Or le mo-
teur que l’équipe de l’ENSTA Paris utilisait jusqu’à présent (Magic Pie 4) possédait un contrôleur
directement intégré. D’après les rapports des années précédentes, le moteur était surdimentionné
et bien trop lourd pour l’utilisation prévue. Par conséquent nous avons décidé quit à créer un
contrôleur de moteur de repartir sur de bonnes bases et ainsi de choisir un nouveau moteur.

2.2.1 Exigences
Nous avions initialement dégagé le différentes exigences suivantes :

— Savoir quand est-ce que le moteur est actif. Utilisation d’une diode qui clignote quand le
moteur est actif.
— Couper la liaison entre la batterie et le moteur en cas d’accident. Après une certaine valeur
d’accélération, un interrupteur ouvre le circuit.
— Surveiller la température de la batterie. Utilisation de capteurs de température.
— Manipuler la batterie sans se blesser. Utiliser des gants en caoutchouc.
— Pouvoir recharger les batteries facilement. En lien avec le pôle carrosserie, position des
batteries accessible ou présence d’un câble reliant les batteries à l’extérieur permettant de
recharger en sécurité.
— Avoir un isolement entre le châssis et le système de traction. Ne laisser aucune fil ou
connexion non-protégé, éviter le frottement entre plusieurs composants
— Sécuriser le système de récupération d’énergie. Adapter le courant récupéré par freinage en
terme d’intensité/tension aux caractéristiques du moteur
— Les circuits et boîtiers doivent pouvoir être vérifiés par les organisateurs. Utilisations de
boîtiers transparents.
— Séparer le Moteur et la batterie du compartiment du pilote. Bulkhead.
— La voiture doit avoir une vitesse moyenne sur la piste de 25km/h.
— Obtenir un temps de réponse du moteur soumis à une commande du contrôleur de moins
de 1.5s.

2.2.2 Risques
Les risques que nous avons établis sont inscrits dans le tableau suivant :

Risques Fréquence Gravité Criticité

Gros Délais de livraison du moteur 2 10 20
Couple insuffisant pour faire avancer le véhicule 3 8 24
La vitesse moyenne de 25 km/h n’est pas atteinte 3 8 24
Destruction du moteur lors des phases de tests 1 10 10
Batterie au lithium qui ne fonctionne plus 3 5 15
Échec dans la création du contrôleur 1 10 10
Le banc d’essai ne donne que des mesures imprécises 5 2 10
Le système d’arrêt d’urgence ne fonctionne pas 1 10 10
La batterie prend feu 4 10 40

Nous avons établit des mesures de prévention ainsi que des mesures d’action dans le cas où ces
risques deviennent réalité.

5
 — Pour augmenter le couple, on compte si nécessaire utiliser un réducteur mais le contre-coup
est une diminution de la vitesse.

— Pour éviter une destruction du moteur, nous liront avec attention la fiche d’utilisation livrée
avec le moteur et nous le manipulerons avec le plus grand soin.

— Pour éviter qu’une batterie cesse de fonctionner à des moments critiques du projet comme
lors de la participation au concours, nous achèterons plusieurs batteries.

— Pour avoir un banc d’essai procurant des mesures précises des performances de notre moteur,
nous prendrons soin d’étudier le banc d’essai réalisé les années précédentes, d’en comprendre
les forces et les faiblesses grâce au rapport de passation.

— Pour éviter que la batterie ne prenne feu, nous comptons ne jamais laisser la batterie reliée
au secteur pour la recharger sans surveillance, ne pas la laisser branchée au moteur en dehors
des essais réalisés et stocker la batterie dans un sac ignifugé.
— Pour être sûr de pouvoir atteindre la vitesse moyenne voulue, nous allons modéliser le com-
portement de la voiture avec un logiciel et comparer les performances du moteur avec celles
des moteurs utilisés par d’autres équipes.

2.2.3 Principaux tests envisagés

Après les achats et la conception de tous les composants dont le pôle était responsable, une
étape fondamentale aurait été la mise en place de différents tests pour évaluer les performances
de chaque sous-système et celles du système dans son ensemble. Nous avions donc prévu de tester
les performances du moteur, l’efficacité du système de transmission, le bon fonctionnement du
système de freinage d’urgence mais aussi la stabilité et la précision des commandes envoyées par
le contrôleur pour permettre au pilote d’avoir un véhicule ayant une bonne réactivité.

Plus précisément nous avions prévu de réaliser un banc d’essai du moteur. Celui ci devra
permettre de maintenir le moteur de manière stable et de pouvoir obtenir des données relatives
principalement à la vitesse angulaire, au couple du moteur, simuler la vitesse atteinte par la voiture
équipée du moteur... Pour le moteur utilisé les années précédentes, le banc d’essai était bancal donc
fournissait des meures imprécises. Ci-dessous une photo du banc d’essai qui était utilisé :

Figure 4

6
 La vitesse et l’accélération étaient mesurés grâce à une carte Phidget et un codeur incrémen-
tal(DC 5V, type ISC3004-001E–360B–5F). Le codeur incrémental était relié à la roue grâce à deux
engrenages ; attention ces engrenages ne seront plus adaptés à la nouvelle roue et au nouveau
moteur. La vitesse du codeur ne devait pas dépasser (3000 RPM) Toutes les caractéristiques du
programme utilisé, des propriétés de la carte et du protocole réalisé sont détaillés dans le rapport de
passation 2017/2018. Les étudiants des années précédentes sont arrivés aux conclusions suivantes :
un couplemètre est une solution chère et difficile à mettre en place. Pour l’intensité, il est facile
d’utiliser un ampèremètre en sortie de la batterie.

Il faut vérifier que l’intensité des courants créés par la batterie ne soit pas trop faible ni trop
élevé par rapport à au courant nominal du moteur.

A bloc, la tension nominale de la batterie est de 48V mais il faut faire des tests lorsque la
batterie n’est pas à bloc pour étudier son fonctionnement lorsqu’elle se décharge. Les caractéris-
tiques des batteries sont également dans le rapport de passation moteur de 2017/2018. Il faut faire
particulièrement attention à ne pas imposer une tension de moins de 39V sous peine d’endommager
la batterie, de plus la sortie du chargeur de la batterie est de 54.6V. Visiblement la batterie se
décharge plus rapidement à 10% de la charge. Les batteries que nous possédons ont un système
BMS (Battery Management system) directement intégré (Le règlement insiste sur le fait que le
batteries doivent posséder un système BMS). Ces tests ont déjà été réalisé mais étant donné que
les batteries n’ont pas été utilisées depuis longtemps et que l’on change le moteur il semble impor-
tant de les refaire.

Nous avions prévu de tester le contrôleur du moteur seul puis intégré avec le système global
en étudiant la tension aux bornes du moteur à l’aide d’un oscilloscope. Normalement le schéma
électronique présenté dans le document annexe sur les moteurs électriques est correct. Ce qui peut
survenir est un sous-dimensionnement ou un sur-dimensionnement des composants électroniques.
Il faudra faire attention à réaliser un nombre suffisant d’essais pour vérifier que les composants ne
grillent pas et ne prennent pas feu. Il faudra veiller à tester le système en cas d’arrêt d’urgence du
système car cela créera une discontinuité forte de tension qui pourrait impacter les composants. Il
faudra veiller à avoir un temps de réponse du moteur convenable (t<1.5s). Si cette exigence n’est pas
atteinte, s’interroger sur le bien fondé de cette exigence, est ce que 2 secondes de temps de réponse
est vraiment pénalisant ?... Il faudra prévoir des torchons et des extincteurs en cas de départ de feu.

Il faudra veiller à faire les tests en installant le contrôleur du moteur, les batteries... dans le
compartiment de la voiture prévu à cet effet. Il faudra surveiller les interférences électromagné-
tiques (EMI) créées par le moteur. En particulier il faudra vérifier que cela n’endommage pas le
circuit électronique ou les systèmes embarqués du véhicule.

Il faudra tester le système de transmission, vérifier qu’il est solide s’il se prend quelques chocs
(ce qui peut arriver si la route n’est pas totalement plate), vérifier qu’il est bien solidaire du mo-
teur et de la roue. Il faudra le tester conjointement avec le moteur et le contrôleur du moteur, cela
pourra avoir un impact notamment sur le temps de réponse de la roue par rapport aux consignes
du contrôleur.

Au niveau de la sécurité il faudra essayer d’allumer un feu dans notre sac ignifugé (pour simuler
une batterie qui prend feu par exemple) dans un endroit qui ne craint rien, en ayant prévenu le
PC sécurité et avec des extincteurs à porté de main.

Si le système de récupération d’énergie par freinage est réalisé, il faudra vérifier que celui-ci
fonctionne et que cela ne porte pas préjudice au système complet.

2.2.4 Livrables matériels

Nous devons livrer à la fin de l’année un système de propulsion fonctionnel mais pas forcément
optimal en terme de performances. Nous nous occupons ainsi du moteur, du contrôleur du moteur,
de la liaison entre la roue et le moteur, du système d’isolement du moteur et de la batterie pour

7
protéger le pilote et le véhicule en cas de départ de feu, du système d’arrêt d’urgence et du sys-
tème de récupération d’énergie par freinage. Néanmoins le système de récupération d’énergie par
freinage ne sera pas une priorité cette année.

2.2.5 Livrables documentaires

Fournir un rapport complet sur le fonctionnement et les caractéristiques du moteur, du contrô-
leur... avec pour objectif de pouvoir donner une base solide du travail réalisé cette année et des
connaissances acquises à nos successeurs.

2.2.6 Choix du moteur

Comme évoqué plus tôt, nous avons décidé de changer de moteur étant donné que le moteur
utilisé précédemment était surdimensionné et possédait un contrôleur intégré (ce qui n’était plus
permis par le règlement de l’année 2019/2020). De plus, dans un soucis de pouvoir optimiser la
consommation du moteur dans un futur plus ou moins proche, il est intéressant de pouvoir choisir
les composants du contrôleur, de pouvoir choisir de modifier le code...

Nous n’avions initialement que des connaissances sommaires sur les moteurs électriques et de
façon général en électronique. Par conséquent nous avons fait beaucoup de recherches sur internet
pour comprendre comment fonctionne un moteur électrique, comment choisir un moteur électrique
en fonction de son application...

Deux des membres du pôles motopropulseur ont pu assister au cours de Conversion Electro-
Mécanique (ES206) qui nous a permis d’avoir une vision globale sur l’ensemble des moteurs élec-
triques existant et sur la façon de les contrôler.

Pour choisir le moteur nous avons également regardé les moteurs utilisés par les équipes ayant
concouru les années précédentes et ayant eu des bons résultats.

Le moteur qui a été retenu est le moteur RE 65 Ø65 mm, Graphite Brushes, 250 Watt 48V
(Part Number : 353297) pour un prix de 759.36 euros. (Le moteur précédent Magic Pie coutait
1600 euros).

Figure 5

Il présente l’avantage de fonctionner avec une tension nominale de 48V ce qui correspond à la
tension nominale des batteries. L’intensité nominale du courant est de 6.8A ce qui est compatible
avec les batteries que nous possédons déjà. Il faudra néanmoins avant de les utiliser veiller à ce
que l’intensité du courant envoyé par la batterie ne soit pas trop faible sous peine d’endommager
le moteur ! Il est très léger (comparativement à d’autres moteurs) à savoir 2.1 kg. Il possède une
efficacité (rapport entre la puissance mécanique en sortie du moteur et la puissance électrique
injectée dans le moteur) très importante de 88%. Ce moteur peut tourner très vite, 3420 rpm
et possède un couple acceptable, 800mNm. Néanmoins il sera peut être nécessaire d’ajuster les
rapports de transmission en fonction de la masse finale du véhicule (conducteur compris). Toute

8
ses caractéristiques se trouvent sur le drive du Shell Eco-Marathon dossier motopropulseur de
l’année 2019/2020 ou sur le site du constructeur.
C’est un moteur à courant continu ce qui permet de pouvoir le contrôler en vitesse de façon
très précise tout en utilisant très peu d’électronique de puissance (cf partie contrôleur du moteur).

Les inconvénients de ces types de moteur sont les suivants : une puissance modérée et surtout
la présence de ballais qui s’usent avec le temps. Par conséquent il faudra veiller à ne pas utiliser
le moteur en dehors des phases de tests et de compétitions et ne pas le faire tourner inutilement
pour ne pas l’endommager. Néanmoins Maxon fabrique des systèmes de qualité donc sauf gros
problème, ce moteur devrait pouvoir être utilisé pendant plusieurs années.

2.2.7 Conception du contrôleur du moteur

Le PWM est une technique utilisée pour créer un signal à partir de deux états binaires (par
exemple une tension à +5V et une tension nulle à 0V). En choisissant les intervalles de temps
pendant lesquels la tension est égale à la tension maximale et ceux où la tension est égale à la
tension minimale, on peut obtenir une tension moyenne ayant la valeur désirée entre la tension
minimale et la tension maximale. Étant donné que la vitesse de rotation du moteur est liée à la
tension qui s’applique à ses bornes, cette technique permet de choisir la vitesse du moteur.

Nous allons réaliser le contrôleur du moteur avec une carte arduino. Il faudra voir l’année
suivante si il est plus intéressant d’utiliser une carte raspberry pi ou de faire faire notre propre
carte électronique. Il faudra également voir avec le pôle système-embarqués si il est préférable de
n’utiliser qu’une seule carte électronique pour tous les capteurs et le contrôleur du moteur ou si il
est préférable de séparer les deux. L’avantage d’utiliser l’arduino est que le code informatique est
très simple.

2.2.8 Montage électronique

Le schéma électronique du contrôleur du moteur est le suivant :

Figure 6 – Schéma électronique du contrôleur d’un moteur DC d’après le e-book du blog d’Eski-
mon (Référence [1])

Il provient du cours (Référence [1]) qui donne des bases sur le fonctionnement de l’arduino.
Les futurs membres du pôle motopropulseur ne devront pas hésiter à utiliser ce document, surtout
la partie qui traite les moteurs.

9
 Le circuit électronique est composé des éléments suivants :

— La carte arduino
— Le moteur (symbole M)
— La source d’alimentation (dans notre cas la batterie lithium ion 48V.)
— Un transistor MOFSET N.
— Une diode de roue libre
— Une résistance
— Un condensateur de déparasitage (optionnel à voir si ça a un réel intérêt pour notre cas
dans les tests).
Attention avec ce montage le moteur ne peut fonctionner que dans un sens. Cette année nous
avons convenu qu’il n’y avais pas besoin d’une marche arrière, si les années suivantes le règlement
l’impose, le schéma électronique n’est pas beaucoup plus compliqué mais il est néanmoins différent.

Pour essayer le code arduino rapidement même sans avoir de carte arduino sous la main, il
existe un outil en ligne (le site tinkercad) qui permet de simuler le comportement d’une circuit
électronique programmable sous arduino. L’interface graphique est très intuitive et compréhen-
sible. Le seul bémol pour notre application est l’absence de générateur de tensions de plus de 30V.
Néanmoins cela permet de bien comprendre le fonctionnement de la PWM et de pouvoir modifier
le code très facilement pour voir ce que ça provoque.

On trouve ci-dessous le code arduino permettant d’effectuer la PWM et ainsi de contrôler la

vitesse du moteur. Ce code provient de la vidéo youtube (référence [2]). Cette vidéo est très claire
et il ne faudra pas hésiter à la consulter les années suivantes pour avoir une piqûre de rappel sur le
fonctionnement concret du contrôleur du moteur. Leur schéma électronique est relativement simi-
laire au notre, l’absence de diode de roue libre en particulier peut néanmoins être problématique
lors du blocage du transistor et de l’accumulation de la tension aux bornes du moteur mais c’est
le code qui nous intéresse ici.

Figure 7 – Code arduino du contrôleur du moteur muni d’un potentiomètre.

Par rapport au schéma électronique présenté précédemment, un potentiomètre a été rajouté.

Il est relié à l’alimentation de la carte arduino +5V, à la masse et à une entrée analogique de la
carte arduino (ici A0). Le potentiomètre sera à terme notre pédale d’accélération et notre pédale
de frein. La résistance de notre montage électronique est reliée à la broche 3 de l’arduino, dans le
montage électronique qui correspond à ce code arduino, la résistance est connectée à la broche 9.
L’important est de connecter la résistance à une broche possédant la petite inscription PWM.

Choix du transistor MOFSET

Le moteur est alimenté par une batterie lithium ion de 48V. Sans surtensions la tension VDS du
transistor doit donc être au moins égale à V DS = 2 ∗ 48 = 96V . En prenant une marge de 30
à 40 pourcents, un transistor avec pour tension drain/source V DS = 150V semble donc adapté
(cf Référence [3]). Les batteries Lithium ion que nous utilisons ont un courant maximal de 8A.
En surdimenssionant un peu notre transistor ont peut choisir un transistor avec un courant maxi-
mum de 15A. Attention il faut faire attention aux caractéristiques du transistor liant l’intensité et

10
la température pour éviter que la température ne soit trop importante et endommage le composant.

Choix de la diode
Nous ne pouvons pas choisir une diode Schottky comme proposé Référence [1] car elles ne sup-
portent pas des tensions supérieures à la cinquantaine de Volt. En revanche il faut choisir une
diode rapide ! Pour la choisir il faut choisir la diode la plus rapide possible avec des caractéristiques
(tensions nominale, courant nominal) qui s’accordent à celles de notre circuit. Il faut prendre une
certaine marge de manière à ce que la tension maximale n’atteignent jamais la tension maximale de
la diode (sous peine de la voir chauffer). Ainsi comme la tension de notre batterie est typiquement
de l’ordre de 48V un diode de tension maximale égale à 90V semble adaptée à notre système.

Choix du condensateur
Ce condensateur a pour but de supprimer les bruits parasites. Certains montages électroniques de
contrôleurs de moteur sur internet en possèdent un et d’autres pas. Il faudra donc tester si il y
a un réel apport dans notre cas. D’après les sites internet visités il faut une capacité entre 10 et
100nF et des caractéristiques (tension nominale, courant nominal) proches des caractéristiques de
notre système.

Choix de la résistance
Il faut choisir une résistance très élevée, typiquement de l’ordre de 10 kΩ.

Attention nous ne sommes pas des experts en électronique et il serait dommage d’endommager
le moteur pour une erreur bête. Les préconisations ci-dessus sont le le fruit de notre travail mais
ne sont pas gage de vérité à 100%. Par conséquent il semble nécessaire de demander à un membre
de l’U2IS ce qu’il en pense. Par ailleurs les futurs étudiants travaillant au pôle motopropulsion
pourront certainement trouver certains des composants électronique à l’U2IS, ne pas hésiter à leur
demander.

2.3 Pôle châssis/carosserie/direction

Au début de l’année l’équipe a récupéré un châssis à nu puisque l’ancienne coque en fibre de
lin était hors d’usage et avait été jetée par l’ancienne équipe. En parallèle, la construction d’une
nouvelle coque en fibre de verre n’avait pas aboutie. Cependant, l’ancienne équipe a laissé derrière
elle des CAO presque terminées de la nouvelle coque.
Du côté de la direction, seules les roues n’ont pas été changées l’an dernier : l’équipe est passée
d’une direction par câble à une direction par biellettes type karting et a remplacé le volant. Cette
direction est optimale et ne doit pas être modifiée cette année, seules les roues (en plastique,
provenant d’une poussette) sont à repenser.

2.3.1 Exigences
Le principal objectif cette année est de construire la nouvelle coque. Pour cela, nous avons fixé
un certain nombre d’objectifs :
— La coque doit respecter les dimensions minimales définies par le règlement ;
— La coque doit pouvoir résister aux efforts exercés lors des vérifications techniques de la
compétition ;
— Le pilote doit avoir une position de conduite confortable ;
— Les roues doivent supporter le poids du véhicule.

11
2.3.2 Risques
Un bilan des risques a été réalisé avant de commencer toute activité :

Risques F requence Gravite Criticite

Pas de fournisseur trouvé à temps ou délai de livraison trop élevé 3 10 30
Coque pas assez résistante 2 7 14
Un élément structurel casse 3 8 24
Crevaison lors des essais 1 5 5
Le pilote n’arrive pas à s’extraire en 10 secondes 1 10 10
La position de conduite est intenable pendant 50 minutes 2 6 12
Un membre se blesse en travaillant sur le véhicule 2 6 12

Le risque le plus critique est donc lié à l’externalisation de la fabrication de la coque.

Des solutions ont été réfléchies au cas où l’un des évènements se produirait :
— Si aucun fournisseur n’est trouvé début mars, ou si aucun n’est capable de nous livrer à
temps, nous entameront la construction d’une coque en fibre de verre. La technique a été
expérimentée l’an dernier et des locaux à l’écart seraient disponibles à l’Yvette pour éviter
les problèmes rencontrés par l’ancienne équipe.

— Des renforts prenant appui sur le châssis peuvent être installés rapidement si la coque n’est
pas assez résistante.

— Des matériaux pour fabriquer une pièce de remplacement peuvent être trouvés facilement
dans un magasin de bricolage.

— De même, des pneus peuvent être achetés facilement dans un magasin de sport. Dans le cas
où la taille nécessaire n’est pas disponible, il est possible de prendre des roues de rechange
avec un diamètre plus grand, bien que cela impactera les performances.

— Des aides pour s’extraire (poignées) peuvent être installées sur le châssis.

— Il est possible de rouler plus vite afin de couvrir la distance requise en un temps plus court,
même si cela impactera la consommation.
— Port des équipements de sécurité obligatoire lors de la manipulation d’outils dangereux.

2.3.3 Livrables
Le pôle devait, cette année, être capable de fournir la CAO et la coque fabriquée par une en-
treprise. De plus, des roues fonctionnelles et un nouveau siège devaient être installés sur la voiture.
D’autre part, une explication des fonctions utiles sur SolidWorks sera réalisée aux prochains
membres du pôle.

2.3.4 Tests envisagés

La fabrication de la coque étant un processus long et coûteux, nous n’avions pas le droit à
l’erreur. Ainsi, un certain nombre de tests devaient être réalisés sur SolidWorks afin de s’assurer
de son bon dimensionnement. Parmi eux on peut noter : l’application d’efforts sur la structure
afin de vérifier sa résistance, un calcul de mécanique des fluides dans le but d’avoir une coque
aérodynamique, et la création d’un mannequin aux dimensions du pilote afin de vérifier que les
dimensions réglementaires de la coque sont respectées.

2.4 Pôle systèmes embarqués

L’équipe a pu récupérer de l’année précédente, un ensemble de capteurs (centrale inertielle, GPS,
thermomètre) ainsi qu’une carte Raspberry Pi utilisée en tant que calculateur. Le rôle principal du
pôle Systèmes embarqués a été d’implémenter en langage C une interface graphique pour le pilote.

12
L’objectif a été de faire remonter les données des différents capteurs et afficher la trajectoire idéale
à suivre pour le pilote.

2.4.1 Exigences
Le pôle systèmes embarqués possède deux missions principales. En premier lieu, il s’agissait
de créer une interface graphique utilisateur sur un écran de 7 pouces pour indiquer au pilote la
meilleure trajectoire à adopter en temps réel.
— créer une vue à la troisième personne pour que le pilote puisse facilement faire correspondre
les informations à l’écran et celles en vision directe.
— fixer un format de données pour décrire la carte
— donner en entrée la carte, et la position du véhicule sur celle-ci
— changer la vue en temps réel après modification de la position
— faire communiquer les capteurs et l’interface pour mettre à jour les données

Ensuite nous devions trouver une méthode de calcul de trajectoire et tester si les performances
du calculateur permettaient de recalculer en temps réel la trajectoire optimale en fonction des
variations de trajectoire du pilote.

2.4.2 Risques
La livraison de cette interface est indispensable pour la réussite du projet. Sans cela les solutions
optimisées trouvées par les autres pôles ne serviront pas. Ce point critique nous a donc incité à
livrer une première solution fonctionnelle qui ne prend pas encore compte les écarts de route que
pourrait réaliser le pilote.
Les risques présents sont aussi d’ordre technique. Il est en effet important de prévoir les situa-
tions dans lesquelles un ou plusieurs capteurs présentent un dysfonctionnement. Pour savoir quels
capteurs doivent être doublés, il faut étudier leur criticité dans l’affichage de la trajectoire. Il en
ressort que l’information dont ne nous pouvons nous séparer est la position. Ainsi nous disposons
d’un GPS et d’une centrale inertielle qui peuvent toutes les deux donner une image de la position
du véhicule.

2.4.3 Livrables
Le pôle Systèmes embarqués a finalement pour objectif de livrer une interface intuitive et claire
pour le pilote livrant les données récupérées par les capteurs et la trajectoire optimale à suivre,
ainsi qu’un rapport de passation expliquant son fonctionnement afin de faciliter la prise en main
de la prochaine équipe.

2.4.4 Tests envisagés

Les tests à mettre en place sont de deux catégories : développement et production. Il s’agit
d’abord de voir si le rendu graphique sur nos machines de développement est correct. On regarde
également si le programme réalise un traitement correct de données simulées. Ensuite il s’agit de
réaliser ces mêmes vérifications sur l’écran réel et avec de vraies données issues des capteurs.

2.5 Livrables globaux

— Livrable matériel : A la fin de l’année, l’équipe devait avoir livrée le prototype en état de
fonctionnement et prêt pour participer à la compétition.
— Livrable documentaire : Ce présent document ayant pour but de récapituler notre travail
et de donner des idées d’améliorations permettra aux prochains membres de comprendre le
fonctionnement du projet. Il était ainsi essentiel à la poursuite du projet.

13
3 Dossier de réalisation
3.1 Pôle motopropulseur
Pour la réalisation du projet, nous avons commencé par utiliser le logiciel OptimumLap pour
simuler les temps de piste et les vitesses moyennes du véhicule sur un circuit similaire à celui
de la compétition. Ce logiciel permet de modifier des paramètres tels que la masse, le coefficient
de traînée, l’empattement, la puissance, etc. du véhicule pour l’adapter à différents projets. Les
simulations tournées dans ce logiciel ont permis de définir la puissance du moteur et le rapport de
transmission final de la voiture.

Figure 8 – Choix de la piste pour la simulation dans le logiciel OptimumLap

Après avoir construit un benchmark pour le choix du moteur en utilisant les données des équipes
les mieux placées lors des dernières éditions de la compétition, nous avons pu choisir le moteur le
plus compétitif en fonction de nos objectifs qui correspondait à notre budget.

Comme le règlement détermine que la vitesse moyenne pendant la course est 25 km/h, nous
avons choisi cette valeur comme une critère de sélection pour le rapport de transmission. Ensuite,
nous avons utilisé un outil disponible par ce logiciel qui permet de simuler la vitesse du véhicule
quel que soit sa position sur le tracé de la course. Le rapport qui a atteint le critère a été 13 :1.

Puis, après avoir choisi le rapport de transmission, nous avons commencé à modéliser le système
de transmission et à concevoir un contrôleur pour celui-ci. Il est rapidement devenu évident que le
système de transmission le plus approprié pour notre projet est la transmission par chaîne, puisque
le coût, la complexité de fabrication et le poids de ce système sont inférieurs aux autres options
disponibles. Nous avons ensuite procédé à la conception des pièces à l’aide d’un logiciel de CAO
(SOLIDWORKS). Nous avons choisi de réaliser un système proche de celui des motocyclettes de
manière à trouver facilement les pièces pour le fabriquer.

14
 Dès le début, il était clair qu’il faudrait mettre en place des procédés d’usinage à la fois pour la
fabrication des pièces de transmission et pour l’adaptation du moteur choisi. Nous avons contacté
l’U2IS pour demander l’autorisation d’utiliser leur fraiseuse automatique. Il est bien possible d’uti-
liser leurs appareils mais il faut réaliser une petite formation un petit peu avant. Les étudiants des
années suivantes ne devront pas hésiter à aller les voir. Nous avons également contacté le fabricant
de notre futur moteur qui nous a assuré qu’il était possible d’utiliser une fraiseuse sur l’axe du mo-
teur sans l’endommager. Malheureusement, l’arrivée de la pandémie nous a empêché de fabriquer
les pièces et de donner continuation au projet.

3.2 Pôle châssis/carrosserie/direction

3.2.1 Coque/châssis
Nous avons d’abord utilisé les CAO des années précédentes pour trouver une position plus
confortable et adaptée pour le pilote. En effet, connaissant la taille du pilote (environ 1m60), nous
avons utilisé la CAO d’un mannequin articulé, que l’on plaçait dans diverse positions dans la CAO
du véhicule (voir figure 9).

Figure 9 – CAO du mannequin articulé et du véhicule

Premièrement, nous avons pu en conclure qu’il était préférable de refaire un nouveau sup-
port vertical pour le siège (voir figure 11), toujours en aluminium mais légèrement incliné afin de
l’adapter à la taille du pilote.

Figure 10 – Support vertical sur lequel doit s’appuyer le siège

Afin de réaliser ce nouveau support, nous avons décidé de souder des morceaux en aluminium
pour ainsi obtenir le même type de structure en forme de polygone. Nous avons donc passé une

15
commande d’une barre d’alumnium de dimensions 3.5cm*2cm*2,6m que l’on avait prévu de décou-
per en morceaux pour après les souder. Malheureusement, nous n’avons pas pu recevoir la barre
d’aluminium en raison de la crise du Covid-19.

Ensuite, nous avons déduit qu’il fallait allonger la coque pour gagner de la place, sinon elle allait
être trop juste notamment au niveau des pieds du pilote. Nous avons d’abord pensé qu’il nous suffi-
rait de modifier les esquisses de Solidworks de l’ancienne CAO, or cela conduisait systématiquement
à des erreurs de reconstruction.
Nous avons donc rapidement conclu qu’il fallait refaire entièrement nous-même une CAO de la
coque. Il a donc fallu s’inspirer de la CAO précédente (qui était malheureusement en chinois) pour
comprendre comment elle avait été réalisé pour faire la nôtre. Notre objectif était de sauvegarder
différentes versions de CAO (une première avec seulement les esquisses 2D, une autre avec le début
des éléments 3D etc...) afin que pour les années suivantes il ne faille pas repartir de zéro à chaque
fois qu’un changement de dimension était décidé. Nous avions également prévu de réaliser des
tutoriels écrits et de préparer une formation pour l’année prochaine, pour que nos successeurs
puisse facilement refaire/modifier les esquisses et les éléments 3D.
Lors des dernières séances de PIE, nous étions en bonne voie pour terminer totalement la
nouvelle CAO mais la pandémie actuelle nous a coupé et nous n’avons pas pu avancer davantage
car ne nous disposions pas de Solidworks sur nos ordinateurs personnels.

Figure 11 – La nouvelle CAO en cours de réalisation

L’objectif suivant, qui n’a donc pas pu être atteint, était de réaliser des simulations de char-
gements statiques et d’aérodynamique sur Solidworks pour valider les nouvelles dimensions de la
coque, afin de finalement la faire réaliser par une entreprise.

3.2.2 Roues
Nous avons confié l’étude et l’achat des roues à des élèves de 3ème année participant au projet
dans le cadre du cours MIV304b. Durant un mois, ils ont donc réalisé des CAO des roues sur
SolidWorks et Abaqus afin, d’une part, de tester leur capacité à supporter le poids du prototype,
et d’autre part, d’essayer de réduire les pertes dues au frottement sur la route.

Figure 12 – Anciennes roues avant

16
 Figure 13 – Calcul mécanique

A la fin de cette étude, il a été décidé d’utiliser des roues de vélo à bâtons, que l’on recouvrira de
plaques en nid d’abeille afin d’assurer un profil aérodynamique tout en gardant un poids minimal.
C’est cette solution qui est utilisé par l’équipe de Polytechnique, et cela permet d’obtenir des
performances proches de celles de roues lenticulaires, tout en restant sur un budget raisonnable
(moins de 200epour l’ensemble).

Figure 14 – Roue du prototype de Polytechnique

Bien que les éléments nécessaires avaient été listés, l’achat n’a pas été réalisé faute d’accès au
local suite à la fermeture de l’école.

3.2.3 Choix du siège

Différentes pièces du véhicules manquaient ou devaient être modifiées. Le siège du véhicule en
faisait partie. Le choix de ce siège devait répondre à plusieurs exigences :
— le confort : le conducteur va devoir passer plusieurs heures dans le véhicule, il est donc
important qu’il soit à l’aise.
— la sécurité :la présence d’un appui au niveau de la nuque et de la tête pour éviter des
accidents graves.
— le budget : le siège, bien qu’indispensable, représente une faible part du budget établi en
début d’année. En effet, l’achat d’une coque, le changements des roues pour respecter les
nouvelles exigences du concours et l’achat du moteur passait largement avant le siège. Le
budget maximal défini après avoir fait une première recherche est : 80e.
— les dimensions de la coques sont déjà définies, il faut que le siège rentre à l’intérieur
— un poids inférieur à 2 kg
Nous avons pu respecter ces critères en choisissant le siège suivant : Siège Karting OMP Fibre Plat
38cm 1.60kg chez GT2I.

17
 Figure 15 – Modèle du siège retenu

Le choix de la fibre du verre comme matériau nous permettait d’avoir un siège suffisament léger
et peu cher.
Nous pourrons ajouter plus tard un rembourrage afin d’améliorer le confort du pilote.

3.3 Pôle systèmes embarqués

3.3.1 L’interface graphique
Avant de commencer à implémenter la projection, sur un écran, de la route, nous avons décidé
du format du fichier en entrée, fichier qui sert à décrire celle-ci. Pour simplifier la lecture et le trai-
tement des données – et ainsi fournir une version minimale de notre interface le plus rapidement
possible – nous avons choisi de discrétiser la route en une suite de segments, quitte à déformer
relativement les courbes.

Ensuite, pour réaliser notre vue à la 3ème personne, nous avons choisi une méthode de projec-
tion de la route aussi utilisée dans des jeux vidéos de course automobile. L’objectif est de fournir
au pilote une immersion optimale.

Figure 16 – jeu de course automobile

L’algorithme de projection a donc été repris d’un tutoriel servant à implémenter un jeu de
course de voitures dans un navigateur Web en JavaScript (Référence [4]). Il a donc fallu implé-
menter les équations présentées en langage C. Le résultat obtenu est illustré à la figure suivante.

18
 Figure 17 – Interface Graphique du pilote

Une fois en mesure de projeter la route sur notre écran, il a fallu améliorer notre programme
pour que celui-ci mette à jour le canvas principal au fur et à mesure de l’arrivée de nouvelles don-
nées. De la même manière, il a fallu mettre à jour les données affichées (vitesse et température).

Notre interface est aujourd’hui capable de rendre une vue à la troisième personne et de répondre
en temps réel à un flux de données entrant. Le flux comporte les positions et orientations de la
voiture permettant de simuler un déplacement sur la piste.

L’objectif suivant – qui était l’intégration des capteurs – n’a pas pu être réalisé. La fermeture de
l’école nous a en effet empêché d’avoir à disposition ces dits capteurs et donc de pouvoir les tester.
Nous avons tout de même réfléchi à une intégration minimale avec les librairies ROS [5]. Nous
souhaitons que notre programme d’interface graphique puisse être réutilisé l’année prochaine, sans
avoir à refondre le code que nous avons produit. C’est pourquoi le choix de ROS nous paraissait
pertinent afin de coder dans des programmes indépendants la remontée des données des capteurs.
Cela donne en effet la possibilité de les moduler facilement, de les changer, de les doubler ou d’en
ajouter de nouveaux de manière fluide et sans avoir à coder ou recoder la communication entre les
différents programmes.

3.3.2 Affichage de la trajectoire

La modélisation de la trajectoire est similaire à celle du circuit exposé précédemment : la trajec-
toire se modélise par un ensemble de segment. Chaque segment de cet ensemble possède un attribut
de couleur qui varie en fonction de la vitesse idéale de parcours. Comme le calcul la trajectoire est
dissocié du circuit, les données sont sauvegardées dans un fichier différent de celui contenant les
données du circuit. Le gradient de couleur permet un meilleur suivi de la courbe par le conducteur
en l’informant sur la vitesse optimale.

À cause des circonstances exceptionnelles liées au confinement, nous n’avons pas pu tester la
précision maximale atteinte par notre système. Nous espérons avoir suffisamment de puissance de
calcul pour que la trajectoire puisse être affichée avec suffisamment de précision et d’anticipation
afin de permettre au conducteur de la suivre ; en somme que la trajectoire affichée ne soit pas trop
éloignée de la trajectoire calculée.

19
3.3.3 Calcul de la trajectoire optimale
L’annulation de la compétition et la fermeture de l’école, nous ont empêché de réaliser notre
objectif de calcul de la trajectoire optimale faute d’outils, de méthodes de calcul et de temps.

20
4 Principales difficultés rencontrées
4.1 Pôle motopropulseur
Le pôle motopropulseur a rencontré beaucoup de difficultés pour respecter les exigences du
règlement de la compétition, surtout à cause du manque de connaissances de certains aspects
techniques. La principale de ces difficultés était liée à la conception du contrôleur du moteur. En
effet, le règlement du Shell Eco-Marathon 2019/2020, contrairement aux années précédentes, sti-
pule que ce sous-système de la voiture doit être fabriqué par les étudiants, de sorte qu’il n’était
plus possible d’utiliser le moteur des années précédentes où le contrôleur était directement intégré.
Ce changement a mené les membres de l’équipe a élargir leurs connaissances en électronique, en
programmation et sur le fonctionnement des moteurs électriques.

Le renouvellement complet des membres du pôle motopropulseur par rapport à l’année précé-
dente a aussi été un problème. En effet la passation a été quasiment inexistante et nous avons du
apprendre sur le tas, essayer de comprendre ce qui avait été fait les années précédentes... Il n’y
avait qu’un seul étudiant de 3ème année qui était dans l’association Shell Eco-Marathon au pôle
motopropulseur l’année précédente mais son emplois du temps chargé ne lui a pas permis de s’in-
vestir beaucoup et de nous aider. Dans un projet de cette envergure, il faut avoir une continuité du
travail pour que le savoir-faire soit transmis entre les différentes générations. c’est ce qui a manqué
notre année et c’est pourquoi la rédaction de ce rapport permettra, nous l’espérons aux étudiants
des années futur de construire sur de bonnes bases. Par ailleurs, nous accompagnerons les élèves
du pôle moto propulsion l’année prochaine surtout au début pour ne pas perdre de temps inutile
et que pour enfin on puisse participer à la compétition.

Une autre difficulté rencontrée est le manque de clarté sur le budget affecté aux équipes dans
le cadre du PIE ce qui a impacté notre décision sur le choix du moteur. Nous avons en effet eu
différents sons de cloche ce qui nous a freiné dans la procédure d’achat du moteur. Par ailleurs une
fois le moteur choisi, nous n’avons pas pu le commander car le site sur lequel on désirait l’acheter
ne correspondait pas à un partenaire de l’école, chose que l’on ignorait. Cela nous a retardé et par
conséquent il serait bien pour les années suivantes d’avoir accès dès le début de l’année aux sites
sur lesquels on peut et sur lesquels on ne peut pas acheter.

Le dernier point qui nous a posé problème est le choix du moteur le plus approprié. Il a fallu
considérer deux différents points principaux : le budget disponible et l’objectif de l’équipe pour
cette année et les années suivantes. L’objectif de cette année était surtout de participer. Néanmoins
il n’est pas envisageable que l’équipe achète un nouveau moteur chaque année donc le choix du
moteur devait être un bon compromis. Pour faire ce choix nous avons cherché à savoir quels étaient
en général les moteurs les plus utilisés par les équipes au Shell EcoMarathon et nous avons aussi
discuté avec un membre de l’équipe de l’École Polytechnique qui nous a indiqué quel moteur ils
utilisaient eux et quelles devaient être les caractéristiques minimales du moteur. Cela nous a permis
d’avoir une vision globale sur les moteurs mais les avis souvent divergent à savoir selon certaines
équipes, un moteur à 400 W peut être sous-dimensionné ou sur dimensionné... il n’est donc pas
facile de choisir un moteur. L’un des projets de cette année était également de racheter une coque
en carbone, le coût du moule étant très important il a fallu discuter avec tous les membres de
l’équipe du Shell EcoMarathon sur la façon de gérer notre budget, quelles sont les priorités. . .

4.2 Pôle châssis/carrosserie/direction

Une des principales difficultés qui est apparue durant la phase de réalisation a été de prendre en
main le logiciel Solidworks. En effet, aucun membre du pôle n’avait une grande maîtrise du logiciel,
quelques notions de base tout au plus. Le principal problème était de se former sachant que les
3ème années ayant participé/participant au projet était rarement disponible au même moment que
nous. Il a fallu donc apprendre par nous-même via des tutoriels sur internet.
Ce manque de formation s’est particulièrement fait ressentir lorsque l’on a dû refaire une CAO
de la coque en partant de rien, à part l’ancienne où le nom des pièces était en chinois, ce qui ne
facilitait pas la tâche. Par conséquent, la phase de CAO a duré beaucoup plus de temps que prévu.

21
 Il y avait également un problème au niveau du matériel informatique disponible dans le local :
seul un ordinateur disposant de Solidworks était présent, ce qui nous a ralenti davantage.

4.3 Pôle systèmes embarqués

Les difficultés pour le pôle systèmes embarqués ont été de plusieurs natures : la récupération
des réalisations passés, la récupération du matériel et le confinement .
Nous avons eu tout d’abord des difficultés à savoir ce que l’ancienne équipe avait laissé, où et
dans quel état. Ce problème vient notamment du fait qu’il n’y ait pas eu de membre de l’ancienne
équipe des systèmes embarqués lors de la présentation du groupe. Par ailleurs, aucun logiciel de
versionning n’avait été mis en place pour les différents projets informatiques. Les codes sources se
trouvaient sur le drive de l’association sans autre documentation que le code lui-même. Retrouver
les logiciels et les bibliothèques utilisés nous a pris plus de temps qu’escompter sans documentation
de la part de l’ancienne équipe.
Comme les autres pôles, les délais des commandes et de réception ont fortement pénalisé l’avan-
cement de projet. Sans le matériel il nous était impossible de tester les différents logiciels dans leur
globalité, nous avancions sans visibilité sur l’état réelle du projet.
La période de confinement et de fermeture de l’établissement scolaire nous a bloqué totalement
dans le développement de certains projets. Comme nous n’avions plus accès au local, nous n’avions
plus accès au peu de matériel qui était à notre disposition. L’intégration des capteurs n’a pu être
faite.

4.4 Sponsors
Cette année, la recherche de sponsors a été très compliquée. Après une trentaine d’entreprises
contactées et relancées par mail, téléphone et au forum Trium, aucune n’a voulu nous sponsoriser
avec un don d’argent ou de matériel. L’absence de prototype fonctionnel et la situation du coro-
navirus nous ont pas aidé.

La recherche de sponsors l’année prochaine sera encore plus dure à cause des répercussions
du COVID-19, il faudra prendre très peu en compte la part des sponsors potentiels dans le bilan
provisionnel.

22
5 Documents et conseils pour la prochaine équipe
5.1 Pôle motopropulseur
Conseils de progression :
— Faire des formations solidworks au début de l’année pour avoir de suite une bonne prise en
main et pour ne pas passer du temps inutilement sur des tutoriels youtube.
— Vérifier que le codeur incrémental et la carte Phidget marchent toujours pour faire les
mesures sur le moteur.
— Fabriquer le banc d’essai du moteur.
— Les batteries en Lithium-Ion n’ayant pas été utilisées cette année, il faudra veiller à ce
qu’elles soient toujours opérationnelles.
— Essayer de vendre l’ancien moteur pour gagner de l’argent. Il y a normalement possibilité
d’en tirer un bon prix.
— Faire un modèle sur Simulink ou Modelica du moteur avec contrôleur. . .cf le rapport de
l’année 2017/2018 où un tel modèle a été réalisé pour l’ancien moteur.
— Re contacter des entreprises pour leur proposer un sponsoring.

5.2 Pôle châssis/carrosserie/direction

Un point à améliorer en priorité serait les connaissances techniques. En effet, les élèves en STICS
pouvaient rapidement mettre à profit leur connaissance pour faire avancer le projet. Cependant,
pour les étudiants en mécanique et en mathématiques appliqués, cela était plus délicat car les cours
sont en deuxième année encore très académiques. Plusieurs solutions sont alors envisageables pour
palier à ce problème de formation :
— suivre une formation Solidworks : on pourrait faire suivre aux élèves de mécanique une
formation en ligne (MOOC par exemple) pour prendre en main l’outil au plus vite (on a
passé trop de séances à se familiariser avec l’outil avec de simples tutoriels Youtube et cela
s’est avéré insuffisant.
— avoir un contact privilégié avec un intervenant extérieur ou un professeur de l’ENSTA qui
seraient familié du domaine automobile. Pouvoir le rencontrer un à deux fois par mois
permettrait de savoir rapidement si on va dans la mauvaise direction et éviter des investis-
sements inutiles grâce à des conseils techniques. De plus, cela représenterait aussi une source
de motivation.
— faciliter la communication avec les élèves de troisième année : ces élèves avaient bien souvent
une bonne connaissance du projet et connaissaient les logiciels en mécaniques dont on avait
besoin. Malheureusement, ces élèves avaient cours pendant nos créneaux PIE, il était donc
difficile de coordonner une équipe d’élèves qui se retrouvaient tous à ce moment-là. Il serait
donc souhaitable de leur libérer ce créneau l’année prochaine.
— suivre une formation en trésorerie pour la personne en charge du budget afin d’avoir une
pression moins importante sur les épaules.

5.3 Pôle systèmes embarqués

À cause des circonstances exceptionnelles, le projet n’a pu avancer comme espéré. Pour aider
l’équipe suivante à mieux prendre en main les différents projets une documentation a été proposée
dans chaque projet. Mais du à la nature évolutive et à l’avancement de certains projets la docu-
mentation peut sembler lacunaire. Les codes sources des différents projets se trouvent sur le gitlab
maintenu par DaTA, l’association d’informatique de l’école.
Pour ce qui est des conseils, propositions et piste d’amélioration, nous donnons les suivantes :
— Nous conseillons à la prochaine équipe de continuer à versionner le code sous git soit sur
gitlab soit sur github.
— Nous proposons de mettre en place ROS pour la communication entre les différents pro-
grammes.
— Continuer le développements de l’interface graphique.
— Une piste d’amélioration possible est la récupération des données générées par les capteurs
pour une analyse ultérieur et un possible feedback.
— Recalculer la trajectoire à chaque fois que le véhicule dévie de la trajectoire initiale, si la
puissance de calcul le et la précision le permettent.

23
5.4 Communication du projet
Il faut faire connaître le projet auprès des premières années au plus vite. En effet, une des
raisons pour lequel le projet a mis du temps à se mettre en route est la présence de personnes
qui y étaient déjà l’année précédente. Nous avions la chance d’avoir déjà notre chef d’équipe, Loïc
Maquis, avec nous en septembre. Mais avoir des chefs de pôles qui connaissent déjà le projet serait
un atout précieux. Pour cela, plusieurs pistes sont envisageables :
— venir présenter le projet avant un cours magistral (si possible un cours de mécanique)
— faire quelques affiches en mettant en valeur le véhicule : ainsi, avant l’amphi associatif, les
élèves intéréssés par ce domaine seraient plus facilement motivés pour nous rejoindre.
— organiser un mini stand sur le même modèle que celui réalisé avec RISE avec la voiture.
Cela permettait d’échanger facilement dans un cadre non conventionnel avec les membres
de l’équipe qui pouvaient présenter individuellement le projet.
— faire savoir assez tôt les différents profils qu’on recherche : en particulier le poste de pilote
qui requiert une petite taille avec éventuellement un mini parcourt test pour les étudiants
remplissant ce critère.

24
Références
[1] ebook blog d’Eskimon. Premiers pas en informatique embarquée.
[2] Vidéo explicative du fonctionnement de la PWM sous arduino.
https://www.youtube.com/watch ?v=UJWNOBeLNus.
[3] site internet décrivant le fonctionnement des transistors. https://www.astuces-
pratiques.fr/electronique/les-transistors-mosfet-de-puissance.
[4] Tutoriel d’implémentation d’un jeu de course automobile en javascript.
https://codeincomplete.com/articles/javascript-racer/.
[5] Libraries ros, robot operating system. https://www.ros.org/.
[6] Site internet orientant le choix de l’électronique de puissance en fonction des applications.
https://www.astuces-pratiques.fr/electronique/schema-ampli-classe-d-300w-simple.
[7] Site internet orientant le choix de l’électronique de puissance en fonction des applications.
http://vehiculeelectriqueduf.com/articlev ehiculee lectrique.php?billet = 6.

25