transmission en milieu perturbe

ARNAUD MERCIER

BAPTISTE GRAND

M1EEAII G4

TRANSMISSION EN MILIEU PERTURBE

UPJV STIC EEAII – ANNEE UNIVERSITAIRE 2008/2009

Soutenance : 10 Avril 2009

Projet dans le cadre de l’IUP GEII

Institut Universitaire Professionnalisé Génie Electronique et Informatique Industriel

Rue du Moulin Neuf 80000 Amiens

PROFESSEUR ENCADRANT : M.COLLET

2/2 Transmission en milieu perturbé

SOMMAIRE

AVANT-PROPOS PAGE 3

CAHIER DES CHARGES PAGE 4

CHOIX MATERIELS PAGE 5

NOTICE D’UTILISATION PAGE 7

Configurateur Xbee

Emission

Réception

MISE EN ŒUVRE PAGE 10

Gestion de projet

Recherche d’informations et réflexion sur la conception

REALISATION PAGE 11

Cartes test

Configurateur Xbee

Carte émission

Carte réception

Programme d’acquisition

Les tests

PROBLEMES RENCONTRES PAGE 16

BILAN TECHNIQUE PAGE 16

PERSPECTIVES PAGE 17

BILAN PERSONNEL ET CONCLUSION PAGE 18


AVANT-PROPOS

Il apparait primordial de présenter dans un premier temps le contexte de ce projet. Son sujet a été

présenté par l’association Sunspeed dans le cadre de la réalisation de véhicule solaire de compétition. Le

but était alors de pouvoir obtenir des données télémétriques sur un des véhicule et de les envoyer à une

voiture suiveuse pour analyse.

Ainsi nous avons dû nous adapter à certaines technologies déjà présentes dans le véhicule et

prendre en compte certaines contraintes de robustesse, de taille et de poids. En effet, la transmission des

informations se faisant par ondes radios, de nombreuses perturbations étaient à craindre à proximité

d’équipements électriques comme un variateur ou un moteur.

Ce compte-rendu présente le cahier des charges du projet – découpé en deux parties : Emission et

Réception – ainsi que le choix du matériel utilisé. Puis nous verrons une synthèse du travail réalisé, les

problèmes rencontrés, et les bilans personnels et techniques.

De plus, il est important de noter que ce projet ne part pas de zéro. En effet, un projet similaire

avait déjà été proposé au sein de l’IUP mais il n’a jamais suffisamment fonctionné pour être utilisé en

Australie lors de la course du WSC (World Solar Chalenge). Ainsi nous avons débuté notre développement

sur les brisés et les acquis du précédent groupe, bien que n’ayant pas eu accès à leurs ressources

matérielles et logicielles.


CAHIER DES CHARGES

EMISSION

La carte d’Emission a deux fonctions principales :

� Recevoir des trames CAN.

� Envoyer les informations qu’elles contiennent via module Xbee.

Eventuellement :

� Ecrire un journal dans une carte SD/MMC.

� Utiliser un système d’exploitation temps réel

De plus, elle devra être robuste et fiable tout en consommant un minimum d’énergie pour une portée

supérieure à 150 m.

Sens de l’information

RECEPTION

La carte de Réception effectue le traitement inverse.

� Recevoir des informations envoyées via module Xbee.

� Envoyer les informations à un ordinateur via USB.

� Traiter les données en utilisant LABVIEW

De plus, elle devra être robuste et fiable tout en consommant un minimum d’énergie.

Sens de l’information

Microcontrôleur PC Xbee USB LABVIEW

Microcontrôleur CAN DRIVER Xbee

SD


CHOIX MATERIELS

Le Choix du matériel utilisé pour le projet à surtout été fait par nécessité compte tenu des technologies

employées. En effet, pour l’utilisation des bus USB ou CAN, nous devions par exemple utiliser une série

spécifique de microcontrôleurs PIC.

MODULE HAUTE FREQUENCE - XBEE PRO

Le Cœur du projet est de pouvoir transmettre des informations à proximité de milieu hautement

perturbateur. Ainsi, nous avons choisi un module haute-fréquence robuste et offrant le meilleur

compromis portée/débit.

Nous nous somme donc tourné vers des modules Xbee Pro (2.4Ghz).

En effet, grâce à une fréquence d’utilisation élevée, la transmission se trouve au-

delà des fréquences perturbées. De plus, ces modules peuvent transmettre à

plus ou moins huit cent mètres avec un débit binaire suffisant de 250kbit/sec.

Les Xbee remplissent également les contraintes d’optimisation en ne consommant qu’une cinquantaine de

milliampères en réception comme en transmission.

MICROCONTROLLEUR - PIC18F4580/4550

Les centres névralgiques des cartes sont des microcontrôleurs de la famille

PIC.

Ces produits de Microchip nous assurent un grand nombre

d’entrées/sorties et nous permettent donc une flexibilité exemplaire. Nous

les avons choisis car nous connaissions leurs caractéristiques en les ayant

déjà utilisés dans le passé.

Le choix du produit à néanmoins été décidé par leurs fonctionnalités. En

effet, seuls certains types de PIC gèrent le bus CAN – comme c’est le cas

avec le PIC18F4580 - ou le bus USB – avec le PIC18F4550.

CONNECTEUR USB B

Ce connecteur USB nous permet, d’une part de faire communiquer la carte réception

avec le PC et d’autre part d’alimenter la carte. Il est également simple à utiliser

(détrompeur) et nous offre une grande robustesse.


DRIVER CAN - MCP2551

Pour permettre la communication entre un bus CAN et un PIC, il est nécessaire

d’adapter les signaux électriques. Pour ce faire, il existe un composant

permettant de dialoguer simplement sur ce bus. En effet, il suffit de lire ou

écrire sur les entrées du driver pour qu’il effectue tout le travail.

Simple et efficace, le MCP2551 se révéla nécessaire et fortement pratique.

REGULATEUR 3.3V

Pour pouvoir alimenter le module Xbee avec sa tension nominale, nous avons dû utiliser

un régulateur de tension. Ainsi nous avons pût transformer la tension de la carte – à

savoir cinq volts – pour obtenir la tension de 3.3V.

AMPLIFICATEUR OPERATIONNEL A RAMPE – LM6142

De plus, pour relever la tension des informations transitant dans le sens Xbee – PIC, nous

avons utilisé un amplificateur opérationnel à rampe. En effet le module sans fil dialogue

dans une plage de tension égale à 0-3.3V, or l’état logique haut est de 4.2V pour le

microcontrôleur. Il était donc nécessaire de transformer ce dialogue dans une plage plus

confortable (0-5V).

LECTEUR CARTE SD

En cas de problème avec la communication, nous avons prévu d’utilisé une carte

SD comme « boite noire ». Les cartes SD sont petites, économes, robustes et

permettent d’enregistrer les informations en FAT32 et compatible Excel. Ce

format est directement exploitable sur un PC.


NOTICE D’UTILISATION

CONFIGURATEUR XBEE

Pour paramétrer un Xbee pro :

1 : Placer le Xbee sur la carte.

2 : Relier la carte au PC à l’aide d’un câble USB A-B.

3 : Lancer un « virtual monitor» comme par exemple celui de PIC C compileur.

4 : L’invite de commande -> s’affiche alors et vous donne la main (Commandes en annexe). Par

exemple si on tape ‘MY’, l’adresse courte du xbee s’affiche. Alors que si vous placez la nouvelle valeur

souhaitée après (ex : ‘MY 1234’), la valeur de MY va être changée en 1234 et un ‘OK’ confirme le

changement.

EMISSION

La seule chose à faire est de brancher la carte

au BUS CAN de la voiture. L’alimentation est

assurée via ce BUS.


RECEPTION ET ANALYSE

Pour recevoir et afficher les informations via la carte de réception il faut :

1 : Relier la carte au PC à l’aide d’un câble USB A-B.

2 : Lancer le programme «communication».

3 : Vous arrivez dans l’onglet OPTIONS, vérifiez les paramètres suivants :

- Communication : Port, parité, débit, …

- Warning : seuils de tolérances et activation de l’alarme sonore.

- Save : Nom du fichier et bouton de sauvegarde.


4 : Cliquer sur l’onglet VIEWER

²

1. Alarme générale, si une alarme est active, alors l’indicateur d’alarme général s’allume et reste

visible sur tous les onglets.

2. Date et heure système.

3. Navigateur d’onglets.

4. Alarme à seuil, si le seuil est dépassé l’alarme de ce seuil est activée.

5. Indicateur, affiche les informations sous forme textuel ou sous forme de thermomètre et autres

instruments.

6. Détecteur, signal la détection ou non du matériel.

Les autres onglets et options font parties du projet global de Sunspeed dans lequel notre projet s’intègre.


MISE EN OEUVRE

GESTION DE PROJET

Avant même de rechercher les composants pour notre projet, il nous a paru important de réaliser un calendrier

prévisionnel sous forme d’un tableau de Gant. Cela nous a permis de prendre conscience de la charge de travail et des délais qui

nous ont été fixés. Le tableau de Gant ci-dessous nous a également permis de découper notre projet en sous partie et de

répartir les taches.

Tableau de gant réalisé sous MS project.


RECHERCHE D’INFORMATIONS ET REFLEXION SUR LA CONCEPTION

La plus grande partie de la phase de prise d’informations fût le choix des technologies à employées

pour répondre au cahier des charges. Et ce, notamment pour la transmission sans fil robuste. Il était clair

qu’utiliser des hautes fréquences classiques ne suffirait pas à améliorer la robustesse face aux

perturbations.

Or, ayant déjà eu connaissance de la technologie Xbee, nous nous sommes documenté sur le sujet

auprès de forums d’électroniques, de revues spécialisées, de revendeurs et de Mr Pegard qui est un grand

spécialiste de cette technologie. Plus nous avancions, plus ce choix nous apparaissait correct - et en

définitive, le fût.

En ce qui concerne le BUS CAN, nous l’avons choisi car il était déjà utilisé par les autres équipes

Sunspeed. C’est également un BUS très utilisé dans le milieu de l’automobile pour son agilité et sa

robustesse.

Nous voulions faire du matériel simple à utiliser pour éviter des complications lors de la course.

C’est pour cela que nous avons décidé de relier la carte réception au PC via un câble USB. En effet un câble

USB est simple à brancher et comporte un détrompeur. De plus cela nous permet d’alimenter la carte

directement via le port USB, ce qui nous évite d’avoir des piles à changer.

Pour le logiciel d’acquisition nous avons très vite penché pour LABView car il permet de faire

rapidement et simplement une interface utilisateur agréable. De plus nous avons étudié cet outil en cours.

La partie réflexions et recherche a été pour nous une partie très importante, nous avons pris le temps de

bien définir le projet et les questions auxquelles nous devions répondre. En effet, savoir où l’on allait nous

permettrait de gagner un temps précieux dans les phases de conceptions et réalisation. Cette démarche

nous pris environ quatre semaines.

Néanmoins, de nombreuses questions restèrent en suspens :

• L’interfaçage du microcontrôleur et du Xbee - sachant qu’ils n’utilisaient pas la même plaque

de tensions.

• L’écriture dans une carte SD via le bus SPI

• Quel système utiliser pour la carte d’émission : temps réel ou non ?


REALISATION

CARTES DE TEST

Concevoir des petites cartes de test a été pour nous l’occasion de se familiariser avec chacune des

technologies présentes dans notre projet de manière indépendante.

PICOS18

Nous avons donc réalisé une carte pour tester et apprendre à utiliser le système d’exploitation

temps réel PICoS18. Cette carte comportait simplement un PIC 18F4580, 3 leds et 2 boutons. Cela nous a

permis de bien maitriser PICoS18 mais nous avons également remarqué que l’utilisation d’un noyau temps

réel était peut-être un peu trop lourde pour l’utilisation que nous allions en faire.

Puis nous avons réalisé trois autres cartes tests pour maitriser les technologies suivantes.

L’USB

L’utilisation du protocole USB était pour nous la meilleure alternative à nos besoins. Mais très vite

cette idée nous a paru beaucoup moins évidente car le protocole USB est très compliqué. Par chance nous

avons trouvé un driveur pour PC qui émule un port COM série à partir de l’USB. Quant au programme du

PIC nous n’avons pas eu à redévelopper les driveurs. En effet le PIC 18F4550 comporte un port USB et PIC C

compileur possède des driveurs adaptés pour ce type de microcontrôleur. Pour finir, nous nous sommes

retrouvés confrontés à un problème d’alimentation via le port USB. En effet un port USB ne peut fournir

que 100mA de base. Malheureusement notre carte consomme presque 100mA, ce qui peut représenter un

danger. Mais il est possible de configurer un port USB en High speed, ce qui nous confère alors un débit de

500mA sur le port.

Cette carte de test nous a permis de faire une communication dans les deux sens entre le PIC et le

Virtual Terminal de pic c compileur.

LE BUS CAN

Le premier problème que nous avons eu avec le BUS CAN est qu’il nous a fallu adapter les

caractéristiques physiques du BUS et du PIC. Très vite Mr Collet, expert en CAN, nous a conseillé un module

driveur CAN. Ce module est très simple à mettre en place sur une carte à microcontrôleur et nous simplifie

grandement le travail.

Puis nous avons eu le problème du driveur logiciel pour le CAN, mais encore une fois nous sommes

parvenus à trouver des driveurs tout fait dans PIC c compileur.


Ainsi, nous avons pu, grâce au prêt d’un analyseur réseau CAN par Mr Collet, simuler la présence de

divers équipements dialoguant via le bus CAN auquel était raccordée notre carte.

De là, gérer le bus s’est révélé moins complexe et nous avons pu réussir après une semaine de

travail logiciel, à allumer une diode quand la trame souhaitée était capturée. Puis quand cette trame avait

la taille souhaitée, puis quand elle contenait les données voulues.

LE XBEE

Vint ensuite l’heure de module Xbee. La communication fonctionnant sur le principe d’une liaison

série, là n’était vraiment pas le problème, il se situait plutôt du côté de l’électronique et de la

configuration.

En effet, le module Xbee fonctionne sur une plage d’alimentation de 0 – 3.3V alors que le reste de

la carte fonctionnait en 0 – 5V. Cela souleva de nombreuses questions pour alimenter le Xbee.

Dans un premier temps nous avons pensé à utiliser un PIC alimenté à 3,3v ce qui aurait éliminé

tous nos problèmes. Mais nous avons sur la carte réception une communication USB qui nécessite une

alimentation 5v. Quant à la carte réception elle comporte une communication CAN qui elle aussi nécessite

du 5v. La seule solution qui s’offrait alors à nous était de réaliser un montage pour adapter ces tensions.

A l’aide de nos base en électronique nous avons pensé a utilisé un amplificateur en comparateur

pour passer de 3,3v à 5v.

Mais nous avons très vite observé que les amplificateurs ne sont pas parfaits contrairement à ceux

que l’on voyait en cours. En effet nous n’avions pas 5v en sortie mais 3,9v. Cette différence est due au fait

que l’amplificateur comporte des pertes. Toutefois nous avons réglé notre problème avec l’aide de Mr

Collet et Mr Detail qui nous ont présenté des amplificateurs à faibles pertes.


En ce qui concerne le passage de 5v à 3,3v cela a été beaucoup plus difficile pour nous. En effet

nous avons commencé par utiliser un pont diviseur. Cela est très efficace pour la transmission de données

entre le Xbee et le PIC, mais en ce qui concerne l’alimentation du Xbee nous avons constaté une sérieuse

chute de tension aux bornes de celui-ci. Encore une fois Mr collet nous a apporté une grande aide, il nous a

fait un petit cour particulier sur ce sujet. Cela nous a permis de nous orienté vers un régulateur 3,3v pour

alimenter notre Xbee.

Pour tester notre carte avec le Xbee, nous avons emprunté le kit pro de développement pour Xbee

de Mr Pegard. Ce kit coûte très cher mais comporte un émetteur/récepteur Xbee avec son programme de

gestion ainsi qu’un configurateur Xbee avec lui aussi son programme.

Pourquoi un configurateur ? En fait un xbee est un module complexe, il comporte beaucoup de

paramètres permettant de le configurer pour nos besoins. Prenons pour exemple nos Xbees, ils sont

configurés en mode point à point, cela permet aux Xbees de communiquer seulement entre eux car ils

connaissent seulement leur propre adresse et celle de leur interlocuteur. Nous empêchons ainsi

d’éventuelles perturbations. De plus ce mode met automatiquement en place un protocole

d’acquittement. Plus simplement, le Xbee émetteur renvoi jusque 10 fois le message si le récepteur n’a pas

acquitté la réception. Beaucoup d’autres paramètres permettent d’adapter nos Xbee à nos besoins,

comme la puissance d’émission. (Voir annexe)

Nous avons donc pu paramétrer nos Xbee et tester notre carte avec le Kit de développement. Les

résultats ont étés très positifs. Mais un problème de plus s’est présenté à nous. Nous ne pouvions

emprunter indéfiniment le configurateur Xbee de Mr Pegard et nous ne pouvions pas en acheter un. C’est

comme cela que notre 1ère

carte définitive a été créée.

CONFIGURATEUR XBEE

Nos cartes de test pour le Xbee et l’USB ont donnée de très bons résultats. Nous avons alors pu

développer une carte de configuration de Xbee. La carte comporte un Pic 18F4550 un Xbee avec son

montage de régulation et pour finir un port USB B. A l’aide d’un programme que nous avons développé sur

notre PIC, il nous était alors possible de reconfigurer nos Xbee par invite de commande sur un Virtual

terminal (voir NOTICE D’UTILISATION). Cela nous a fait economiser près de 120€ et nous permet d’avoir un

configurateur Xbee lors de notre depart en Australie.

CARTE EMISSION

Une fois encore nous avions plus qu’à assembler nos différentes cartes tests pour réaliser celle-ci à

l’exception de la partie optionnelle de la SD boite noir. Nous avons dans un premier temps cherché si notre

PIC 18f4580 comportait un port dédié à la lecture/écriture sur SD. Nous avons trouvé un port, non dédié

mais, permettant tout de même la gestion de cartes SD : le port SPI. Comme toujours des pilotes sont

disponibles dans PIC C compileur. Malheureusement les pilotes ne gèrent pas la SD mais seulement le SPI


qui est un protocole de communication. Par manque de temps nous n’avons pas pu finir le code de gestion

de la SD. (voir NOTICE D’UTILISATION).

CARTE RECEPTION

Une fois n’est pas coutume nos cartes tests ont bien aidé, mais il y a eu des difficultés qui se sont

ajoutées. Toujours dans le but de faire du matériel simple et robuste à utiliser, nous avons décidé

d’intégrer notre carte réception dans une boite avec des ventouses pour la fixer sur le pare-brise de la

voiture suiveuse en Australie. Nous avons donc trouvé une boite sur Radiospares et le temps de la recevoir

nous avons tiré la carte réceptrice en respectant les dimensions de la boite. Mais Radiospares ne nous a

pas envoyé la bonne boite, cela passe encore car la nouvelle boite est juste un peu plus grande. Au finale

nous avons réalisé une belle boite,robuste et très simple à utiliser. (voir NOTICE D’UTILISATION)

PROGRAMME D’ACQUISITON

Nous avons, comme pour la partie électronique de notre projet, divisés les problèmes en sous

ensemble. Nous avons donc réalisé des petits programmes qui réalisaient chacun une petite taches,

comme par exemple la lecture sur un port COM. L’une des grosses difficultés, fût que ce programme devait

permettre non seulement d’accomplir les taches fixées par notre cahier des charges mais aussi d’intégrer

d’autres projets de Sunspeed. Des lors nous avons remarqué que labview demande beaucoup de

ressources et que par conséquent la taille important de notre programme entrainait de petits

ralentissements de l’ordinateur. Mais nous avons trouvé un moyen d’améliorer les performances de notre

programme. En plus de l’optimisation de celui-ci nous pouvons produire un « pseudo exécutable » qui

double les performances du programme.

LES TESTS

Il était inconcevable pour nous de qualifier notre travail comme fini sans avoir fait subir une

batterie de tests à notre projet. Nous avons commencé par faire des tests dans une salle de TP. Puis nous

avons testé, en extérieur, la portée des modules. Nous avons dépassé sans problèmes les 150m du cahier

des charges, alors que les deux modules étaient séparés par des voitures et des immeubles. Pour finir nous

avons placé l’émetteur sur le variateur de la voiture solaire. Le variateur et le moteur sont très proches l’un

de l’autre et sont la principale source de perturbations dans la voiture. De plus notre carte d’émission était

alimentée directement sur l’électronique de la voiture. Le récepteur, quant à lui, était placé sur le pare-

brise d’une voiture ordinaire. Nous avons alors fait tourner le moteur de la Jules Verne 2 en donnant de

grands coups d’accélérateur, ce qui augmente les perturbations. Pendant ce temps l’autre voiture a fait le

tour du quartier, autour du véhicule solaire. Les résultats ont été très satisfaisants puisque sur 2 minutes

d’enregistrement et sous des perturbations extrêmes, nous avons récolté 100% de l’information envoyée.


PROBLEMES RENCONTRES

Au delà des problèmes énoncés ci-dessus, l’un des premiers fût de trouver les bons composants

pour remplir le cahier des charges et de pouvoir les commander. En effet, il nous fallu beaucoup de temps

pour trouver un revendeur pour le Xbee. Mais une fois trouvé nous avons appris que les commandes pour

ce fournisseur n’étaient plus possibles par l’IUP avant plusieurs mois. Nous avons finalement commandé

les Xbee PRO en passant par l’association Sunspeed.

Toujours avec les commandes, nous avons eu beaucoup de mal à obtenir certains composants chez

Radiospares. En effet pendant quelques temps, plus aucunes commandes n’étaient possibles par

l’intermédiaire de l’IUP. Malheureusement l’association rencontrait de gros problèmes de trésorerie. Par

chance Pierre DETAILLE nous a avancé ces composants.

Nous avons également rencontré des problèmes dans la définition des protocoles de

communication et normes des parties communes des différents projets, comme par exemple les

connecteurs à utiliser pour le BUS CAN.

Le plus gros problème que nous avons rencontré a été la précipitation dans la réalisation des cartes.

En effet nous nous sommes très vite rendu compte de la charge de travail que représente ce projet ce qui

nous a conduit à tirer des cartes trop rapidement. Ceci était une erreur car les cartes n’étaient pas bonnes

et nous avons donc perdu du temps à les refaire.

Pour finir nous devions nous inspirer du travail déjà réalisé sur ce projet par les anciens membres

de l’association. Malheureusement nous n’avons pas trouvé de traces de leur travail. C’est pour cela que

nous avons décidé de réaliser une documentation technique, en plus du rapport de projet (annexe).

BILAN TECHNIQUE

Après des débuts assez brouillons et hésitants, nous avons sût dépasser nos problèmes et nous

adapter aux conditions de travail. Nous avons sût acquérir les connaissances requises pour réaliser ce

projet.

Grâce à ce projet, nous avons pu réaliser toutes les étapes de la réalisation en commençant par l’étude du

projet, la réflexion nécessaire, l’achat des composants, la création des circuits imprimés, la soudure des

composants, le codage et l’assemblage de toutes ces parties.

Grâce à cela, nous sommes devenus polyvalents et autonomes, ce projet nous a permis de nous « auto-

former » sur beaucoup d’outils aussi bien physiques que sur certains logiciels.

Pour finir, nous dirons que ce projet a été techniquement difficile mais très enrichissant et nous a montré

ce dont nous étions capables.


PERSPECTIVES

Pour ce projet nous avons beaucoup de perspectives :

Nous avons rajouté à ce projet une carte SD « boite noir », pour le moment il n’y a que le câblage

qui a été effectué et un début de code. Nous voudrions que le code soit fini pour notre départ en Savoie le

27 juin.

Il est clair que simplement afficher les informations de la voiture en temps réel n’est pas suffisant

pour être compétitif au WSC. C’est pour cela que nous avons commencé à développer avec l’aide de

Jeremy HUET et André DESJARDIN un onglet Analyse. Cet onglet a pour but, en fonction des

caractéristiques de la voiture, des conditions météo du lendemain et d’autres paramètres, de prévoir notre

consommation et la vitesse à laquelle nous devrons rouler. Tout cela devrait nous permettre d’optimiser

notre consommation et ainsi arriver à la fin de la course avec les batteries au minimum, mais bien sur sans

avoir eu les batteries à plats pendant la course.

Pour réaliser cet onglet nous avons également besoins de l’onglet météo qui donne en temps réel

les éléments physiques qui interviennent dans les pertes d’énergies sur le véhicule. Cela va nous permettre

non seulement d’affiner l’estimation pour le lendemain mais aussi de vérifier, par rapport aux relevés

avant la course, que la voiture a un fonctionnement optimal.

Nous ne savons pas encore si nous allons faire une station météo sur une autre carte et la relier elle

aussi en USB au soft ou bien refaire une carte de réception avec une station météo intégrée.


Pour finir nous voudrions regrouper tous les projets liés à Sunspeed et les faire communiquer en

CAN, avec la voiture en marche, pour ainsi vérifier la robustesse de nos systèmes.

BILAN PERSONNEL ET CONCLUSION

En conclusion nous pouvons dire que le projet est fini et abouti, le cahier des charges est respecté

mais nous avons encore beaucoup de travail sur le projet global et les tests collectifs.

Pour nous, ce projet fût le premier de la sorte, les études que nous avions faites jusqu’à présent

nous avaient donné l’occasion de faire aussi de grands projets mais pas aussi complets.

En effet, ce projet est le premier à demander autant de travail car, pour celui-ci, nous avons dû

travailler sur tous les terrains en même temps, aussi bien sur la conception physique et électrique que sur

la partie informatique et programmation.

Pour ce projet, nous avons dû approfondir toutes nos connaissances dans les domaines vus en cours, en

plus, il nous a obligé à prendre en main d’autres notions qui relèvent d’avantages du domaine du monde

du travail comme la gestion du travail en équipe ou encore la gestion d’un budget.

Ce projet nous à aussi permis d’apprendre à acquérir de nouvelles compétences et de maitriser de

nouveaux outils que nous ne connaissions que très peu comme le logiciel ARES pour créer nos circuits

imprimés ou encore le module Xbee PRO pour la communication HF.

Au final, nous sommes plutôt satisfaits du travail réalisé en si peu de temps. Nous avons appris

énormément de choses sur les technologies des bus CAN et USB, et sur la difficulté des systèmes

d’exploitation.

Nous avons pu établir et tester une démarche, à mi-chemin entre la gestion de projet et l’auto-

formation, qui a permis de nous faire la main sur de nombreuses ressources et composants. Ceci nous a

permis de passer toutes les étapes de développement (i.e. gestion de projet, conception, achat des

composants, réalisation, débugage, tests) avec succès et ce, selon le calendrier au préalablement défini.

Ce n’est pas un simple projet d’école. En effet il va être utilisé par l’équipe Sunspeed lors de la

grande course du WSC en Australie.

Pour conclure, nous dirons que ce projet a été très bénéfique pour nous car il nous a aidé à mieux

comprendre le métier vers lequel nous nous dirigeons en nous montrant les problèmes que peut poser un

projet de cette envergure et la somme de travail qu’il demande. Mais cela nous a aussi montré la

satisfaction que l’on éprouve à la bonne réalisation d’un tel projet.

L’annexe du compte rendu ce trouve sur un document à part, pour un souci de clarté et confort de lecture.

transmission en milieu perturbe

Documents