Ballon Captif

Transcription

Ballon Captif

Projet d’étude promotion 2009
Projet d’étude N° 078
Noms des élèves :
Maxime STORN
Boris CHABILAN
Clément CHASTAGNOL
Baptiste JOALLAND
Damien OCTEAU
Guixi ZOU
Commanditaire :
Equipe d'enseignement
Tuteur(s) scientifique(s) :
Alexandre SAÏDI
Fabien MIEYEVILLE
Conseiller en communication :
Merwane DAOUZLI
Conseiller en gestion de projet :
François SIDOROFF
Département d’accueil :
MI - EEA
Date du rapport :
18/04/2007
Rapport intermédiaire.
Projet d'Etude 78
Ballon Captif
(suite)
Résumé.
Notre projet consiste à réaliser un système autonome de prise de vue aérienne.
Pour cela, nous utilisons un système embarqué de transmission vidéo à distance en
temps réel qui a été réalisé par un groupe de projet d'étude précédent.
Il s'appuie sur une carte embarquée équipée d'un système d'exploitation Linux
adapté aux microcontrôleurs, et sur un ensemble logiciel assurant l'acquisition et la
transmission des images sur un réseau sans fil.
Nous intégrons ce système dans la nacelle d'un ballon captif en lui permettant
d'être autonome en énergie et commandé à distance. Un exemple d'application d'un
tel appareil est la retransmission en direct de vues aériennes lors d'un évènement
sportif.
PE 78 – Rapport intermédiaire – page 2 / 36
Table des matières
Introduction............................................................................................. .......................4
1. Contexte et objectifs du projet...................................................................................5
2. Cahier des charges..................................................................................... ................6
3. Matériel existant............................................................................................... ..........7
3.1. Introduction.................................................................................... .....................7
3.2. Carte embarquée............................................................................................... ..7
3.3. Caméra..................................................................................................... ...........8
3.4. Acquisition des données de la caméra................................................................8
3.5. Module WiFi.........................................................................................................9
3.6. Alimentation.................................................................................... ....................9
4. Partie conception mécanique...................................................................................10
4.1. Présentation......................................................................................................10
4.2. Choix et achat du ballon....................................................................................10
4.3. Rôle de la nacelle..............................................................................................11
4.4. Mesures des dimensions et masses des composants électroniques présents.. .11
4.5. Schéma de principe du système d’orientation de la caméra.............................11
4.6. Modélisation de la nacelle à l'aide du logiciel CATIA..........................................12
4.7. Suite de la réalisation........................................................................................14
5. Choix de la motorisation................................................................................... ........15
5.1. Choix du type de moteurs.................................................................................15
5.2. Qu'est-ce qu'un moteur pas à pas?...................................................................15
5.3. Classification du moteur pas à pas....................................................................15
5.4. Paramètres caractéristiques..............................................................................16
5.5. Moteurs retenus................................................................................................16
6. Amélioration des performances vidéo......................................................................17
6.1. Introduction.................................................................................. .....................17
6.2. Augmentation de la définition...........................................................................17
6.3. Question de l'angle de champ...........................................................................17
6.4. Augmentation de la cadence d'images..............................................................18
7. Traitement de l'image..................................................................................... ..........20
8. Stockage et diffusion des images.............................................................................22
8.1. Stockage des images.................................................................................... .....22
8.2. Diffusion des images.........................................................................................22
9. Conclusion et perspectives.......................................................................................23
Analyse du processus de projet....................................................................................24
1. L’équipe.......................................................................................................... ......24
2. Présentation personnelle de chaque membre et de ses motivations..................24
3. Organisation du projet..........................................................................................26
4. Budget...................................................................................................... ............27
Outils de gestion de projets.............................................................................. ............28
Diagramme PERT........................................................................................ ..............28
Diagramme GANTT.................................................................................... ...............29
Conclusion générale............................................................................. ........................30
Annexes............................................................................................................ ............31
ANNEXE 1 : Budget détaillé..................................................................................31
ANNEXE 2 : Caméra numérique (extraits)............................................................32
ANNEXE 3 : PPM Format Specification..................................................................33
Bibliographie.............................................................................. ..................................35
Table des figures................................................................................................... ........36
Introduction
Ce rapport a pour but de faire le point sur le travail que nous avons effectué au
cours des 6 derniers mois sur le projet d'étude n°781 intitulé "Ballon Captif". Ce projet
consiste en la réalisation d'un système autonome de prise de vues aériennes, son
intérêt principal étant d'ordre pédagogique. Il basé sur un dispositif d'acquisition et de
transmission de vidéos sans fil qui a été réalisé par un groupe de projet d'étude de
l'année précédente (PE98). Leur projet était également intitulé "Ballon Captif",
cependant leur travail s'est concentré sur la conception du système vidéo
uniquement. La réalisation du ballon proprement dit était facultative et n'a pas été
réalisée faute de temps, nous en sommes donc chargés afin d'obtenir un système de
prise de vue aérienne complet.
Un grand nombre de défis sont à relever pour ce projet, non seulement d'ordre
scientifique et technique, mais également concernant l'organisation du travail en
groupe. Il nous a pour cela fallu nous adapter aux différentes attentes et motivations
de chacun, faire face à de nombreuses contraintes de disponibilités et rendre compte
de notre travail de façon pertinente. Une difficulté supplémentaire venait du fait que
nous devions commencer notre projet avant que le groupe de PE98 n'ait fini le sien, il
nous a donc fallu suivre leur avancement et travailler en coopération avec eux
pendant plusieurs mois.
Nous vous présentons ici notre travail en deux parties : la première concernera
la partie scientifique du projet, elle décrira les étapes de la réalisation du projet,
montrera les problèmes rencontrés et explicitera leur solution. Nous présenterons
notamment le système qui a été réalisé par le groupe précédent et que nous
utiliserons pour la transmission des vidéos, puis nos propres recherches et travaux
concernant l'ajout du ballon, la conception de la nacelle et la programmation de
fonctions supplémentaires.
La seconde partie sera une analyse du processus de projet. Elle présentera
l'équipe, son organisation, les méthodes employées pour réaliser nos objectifs et les
relations avec les personnes extérieures au projet. Elle décrira également l'évolution
des objectifs du projet et les outils mis en place.
1 Boris JEULAND, Guillaume GRENET, Olivier LEON, Pierre FROUGE et Stéphane MONFORT.
1. Contexte et objectifs du projet
Le projet dont nous prenons la suite n'était initialement pas parmis la liste de
projets proposés. Le tuteur Alexandre Saïdi du département MI l'a proposé suite à la
lecture d'un article de Linux Magazine2 concernant la réalisation par une association
nommée projet Aurore d’ un ballon captif permettant la vidéo aérienne, et a formé un
co-tutorat avec Fabien Mieyeville du département EEA. Cela explique pourquoi le
projet a été proposé par l'équipe d'enseignement et possède avant tout un intérêt
pédagogique, mais également que la partie informatique a été privilégiée au départ.
Puisqu'elle a été réalisée avec succès par le groupe de PE98, un nouveau projet a été
lancé afin d'aboutir au système final de prise de vue aérienne.
Ce projet est également motivé par l'intérêt pédagogique et n'a pas été
commandé pour répondre à un besoin particulier (en particulier car il existe de tels
systèmes dans le commerce), néanmoins une fois réalisé il pourra être utilisé lors
d'évènements se déroulant à l'Ecole (rencontres sportives, célébrations) ou pour
obtenir des vues aériennes du campus et éviter ainsi le recours à un prestataire
extérieur.
Comme il a déjà été dit, notre projet se base sur un système mécatronique
existant et consiste en son amélioration ainsi que son intégration dans un ensemble
mécanique permettant la prise de vue en altitude. De façon plus précise, ses objectifs
sont tout d'abord de récupérer le système d'acquisition d'images autonome réalisé par
le PE 98 de la promotion 2009. Ce dispositif se compose d'une caméra numérique
CMOS basse résolution, d'une carte de développement pour système embarqué, d'un
adaptateur ethernet-wifi permettant de transmettre les images sans fil, d'une batterie
assurant l'autonomie énergétique de l'ensemble et enfin des deux logiciels s'exécutant
sur la carte et sur la station au sol permettant l'acquisition des images.
Le gros de notre travail consiste ensuite à réaliser un ensemble ballon et nacelle
(conception et fabrication) contenant ce matériel et permettant de maintenir ce
système dans les airs à l'altitude et la position souhaitée, le seul lien avec le sol étant
une corde d'amarrage. La caméra utilisée sera fixée sur un support articulé sur deux
axes et son orientation pourra être commandée depuis le sol. Etant donné la nature
aéroportée de notre système, nous devons en permanence gérer des contraintes de
poids. Enfin, les logiciels existants seront complétés par des fonctions d'amélioration
de la qualité des images obtenues et de diffusion en temps réel des images sur le
réseau de l'école.
Concernant la partie budgétaire, la somme de 300 euros disponible initialement
est insuffisante, aussi nous avons du réaliser une demande de BQP pour couvrir les
dépenses supplémentaires, et nous l'avons partiellement obtenu. Cette contrainte
budgétaire nous amènera probablement à faire des concessions sur les améliorations
apportées au système vidéo. Enfin, notre appareil devra être livré en décembre 2007
et nous comptons réaliser une démonstration en situation réelle pour montrer la
réalisation de nos objectifs.
2 Voir bibliographie
2. Cahier des charges
Après avoir formé le groupe, et une fois que nous avons pris connaissance des
objectifs de ce projet, nous avons établi le cahier des charges de notre système. Pour
cela, nous avons considéré les besoins liés à une utilisation particulière de notre ballon
captif qui est la retransmission d'un évènement sportif se déroulant sur le campus.
D'autre part et à l'aide des conseils des tuteurs, nous avons pris garde de nous fixer
des objectifs qui nous semblaient réalisables, tant en termes de ressources techniques
et finanières que de compétences et de temps disponible.
La première étape fut de choisir la nature du ballon, c'est à dire de savoir si
nous allions nous en tenir à un ballon captif comme le dit le titre de notre projet ou s'il
était possible de réaliser un dirigeable libre.
Un dirigeable aurait l'avantage de pouvoir se déplacer dans les airs sans liaison
physique avec le sol, ce qui permet de modifier l'angle de vue à volonté. Cependant
les difficultés liées à la réalisation d'un dirigeable sont grandes. Premièrement, la force
d'ascension générée par l'enveloppe doit parfaitement équilibrer le poids de tout
l'ensemble, et la nécessité de cet équilibre le rend très sensible au vent. D'autre part,
pour qu'il puisse se mouvoir dans les airs il est nécessaire de l'équiper de moteurs
comportant des hélices avec des axes aussi bien horizontaux que verticaux, ce qui les
rend plus complexes à concevoir. Enfin, et c'est particulièrement important dans un
projet comme le nôtre, l'absence de câble le reliant au sol empêche la récupération
rapide du ballon en cas de problème technique ou de modification des conditions
vidéo. Il serait en effet bien dommage de voir notre matériel s'envoler à cause d'une
erreur ou d'un problème technique sans avoir de contrôle dessus. Pour toutes ces
raisons, nous avons décidé de nous tenir à un ballon captif, relié physiquement au sol.
Nous avons ensuite défini des critères de performance à atteindre afin de
réaliser de façon satisfaisante la retransmission d'un évènement se déroulant sur le
campus. Le cahier des charges que nous avons établi est donc le suivant :
•
La prise de vue devra se faire depuis une position fixe, à une altitude inférieure
à 100m.
•
Le système devra être autonome en énergie et avoir une autonomie d'au moins
30 minutes.
•
Le ballon devra avoir une taille raisonnable (aucune dimension supérieure à
5m), il faudra donc respecter des contraintes en terme de masse que l'on peut
soulever.
•
La caméra devra être orientable selon 2 axes, avec un débattement d'au moins
45° sur chaque et une précision d'au moins 1°. La commande de l'orientation
devra se faire à distance depuis la station au sol.
•
La vidéo transmise devra avoir une résolution VGA ou proche, à une cadence
d'au moins 10 images par seconde.
•
L'angle de couverture de la caméra devra être réglable pour s'adapter à la taille
du champ que l'on veut filmer et à la distance à laquelle se trouve le ballon. La
plage de couverture devra s'étaler autour de 45°.
Enfin, le logiciel chargé de la réception des images et de leur diffusion aura des
fonctions d'amélioration de l'image comme une augmentation de la netteté, ainsi
qu'une correction de la luminosité et du contraste.
3. Matériel existant
3.1. Introduction
Notre projet se base sur le travail effectué par le groupe de PE 98, qui a réalisé
un système de capture et transmission de vidéos sans fil que nous allons utiliser. Des
contacts réguliers avec leur groupe ainsi qu'un accès à leurs documents nous ont
permis de nous familiariser avec le matériel utilisé et leurs réalisations. Ce dispositif se
compose d'une carte de développement pour système embarqué, d'une caméra
numérique CMOS basse résolution, d'un adaptateur ethernet-wifi permettant de
transmettre les images sans fil, d'une batterie assurant l'autonomie énergétique de
l'ensemble et enfin des deux logiciels (sous environnement Linux) s'exécutant sur la
carte et sur la station au sol permettant l'acquisition et la transmission des images.
3.2. Carte embarquée
Pour son travail, le groupe de PE 98 a porté son choix sur le kit de
développement DNP/SK16L avec microcontrôleur DNP5280 de la société SSV
Embedded à base de processeur Motorola Coldfire (Motorola 32-bit MCF528x) à 66
Mhz. Leur choix a été motivé par plusieurs raisons.
Fig 1: La carte DNP/SK16L
Tout d'abord, elle est facilement programmable de part l'utilisation d'un noyau
Linux spécialement adapté aux microcontrôleurs3. Cette méthode a l'avantage de
disposer d'un micro-système d'exploitation fonctionnant à la manière d'une station de
travail : il existe en effet des distributions Linux spécialement codées pour être
utilisées dans des systèmes embarqués temps-réel. D'autre part, la carte doit être
connectée à une caméra. Cela se fait en utilisant directement le bus de données du
microcontrôleur, la rapidité de transfert étant largement supérieure à celle de liaisons
séries par exemple, et cette carte permet un accès facile à ce bus. Enfin, son port
ethernet permet la connexion d'un module WiFi nécessaire à la réalisation du réseau
sans fil.
Enfin, le coût raisonnable du kit (292€) et la documentation abondante issue du
projet Aurore qui utilise une carte semblable ont définitivement confirmé leur choix.
3 La distribution utilisée pour ce projet est µClinux, (C pour Contrôleur), qui est, comme son
nom l’indique, une distribution spécialisée dans l’exploitation de systèmes embarqués. Elle a
été conçue à partir de la version 2.0 de Linux pour les microcontrôleurs qui ne possédaient
pas de MMU ( Memory Management Units ), ce qui assure un système le plus près possible
de la couche matérielle, et une occupation mémoire optimisée.
3.3. Caméra
Après plusieurs tentatives infructueuses pour utiliser une webcam (QuickCam
VC), le groupe de PE 98 s'est orienté vers une caméra numérique de technologie
CMOS. Le modèle retenu est le capteur CMOS OV6620 de Omnivision, directement
monté sur circuit imprimé et équipé d’une optique chez Lextronic sous la
dénomination CA88 [voir annexe 2].
Fig 2: Caméra CA88
Ses caractéristiques principales sont les suivantes :
Résolution
356x292
Taille du capteur
1/4"
Couleur
4, 8 ou 16 bits
Alimentation
5V ou 3.3V
Images / secondes
60 max
Réglages depuis le PC
Protocole I²C
Objectif
f=4,9mm
Fig 3: Caractéristiques de la caméra CA88
Le ColdFire utilisant du 3.3V et ne pouvant supporter le 5V de la caméra, il est
nécessaire de convertir les sorties logiques de la caméra en 3.3V. Pour ce faire, le
groupe de PE98 a utilisé des composants Philips 74HCT244. Ces composants servent à
la base de buffer, mais on utilise surtout leur capacité à prendre des entrées en 5V et
de sortir un signal logique en 3.3V.
3.4. Acquisition des données de la caméra
Le programme réalisé par le groupe de PE98 possède plusieurs caractéristiques
que nous allons présenter ici.
Pour lire les données transmises par la caméra, il lit les valeur des broches de la
carte d’évaluation auxquelles sont connecté les sorties la caméra. Pour accéder aux
valeurs des registres correspondants, un module spécifique pour le noyau de Linux a
été développé afin de contourner les restrictions d'accès imposées aux programmes
executés en espace utilisateur.
D'autre part, en raison de la méthode de lecture utilisée (detection logicielle des
fronts montants des signaux de synchronisation) la fréquence à laquelle fonctionne la
caméra a dû être abaissée, ce qui a pour conséquence de limiter la cadence d'image a
1 ou 2 images par seconde.
3.5. Module WiFi
Pour réaliser la liaison sans fil entre la carte et la station au sol, le groupe de PE
98 a choisi la technologie WiFi car elle correspond le mieux aux besoins en terme de
portée et de matériel disponible. Le mode de fonctionnement choisi est le mode AdHoc dans lequel deux équipements WiFi sont directement reliés entre eux sans passer
par une borne, on peut comparer cela à un câble les reliant directement.
Après prise en compte des contraintes de fonctionnement, d'alimentation,
d'encombrement et de masse, le module qui a été acheté est le LINKSYS WET11.
Fig 4: Module WiFi Linksys WET11
3.6. Alimentation
Bien que leur système n'a pour l'instant été utilisé qu'au sol, le groupe de PE 98
lui a ajouté une autonomie énergétique grâce à l'emploi de batteries d'accumulateurs
Lithium Polymère fournissant une tension nominale de 7,4V et ayant une capacité de
2000mAh. Elles ont l’avantage d’avoir un rapport énergie/poids très élevé (par rapport
aux autres types de batteries), de présenter un faible encombrement et un courant de
sortie relativement élevé ce qui en font les batteries idéales pour les engins volants.
Elles présentent quelques inconvénients puisqu’elles nécessitent un chargeur adapté
car elles craignent la surcharge. De plus comme elles craignent aussi la surdécharge, il
faut prévoir un dispositif qui coupe l’alimentation en cas de besoin afin de ne pas
endommager la batterie. En se basant sur la consommation annoncée pour les
différents composants, notre cahier des charges en terme d'autonomie (30min)
devrait être respecté.
Entre la batterie et l'ensemble des composants se trouve un circuit
d'alimentation utilisant des petits régulateurs (convertisseurs DC-DC) de type LM2940
qui permettent d'assurer une tension de fonctionnement constante de 5V.
Fig 5: Batterie LiPo 2000mAh
4. Partie conception mécanique
4.1. Présentation
La partie de conception mécanique de ce projet est indépendante de la partie
électronique et informatique. Elle consiste à réaliser une nacelle destinée à accueillir
les différents composants électroniques récupérés du PE98 ainsi qu'à permettre
l'orientation de la caméra. Les contraintes dont nous devons tenir compte pour
réaliser ce travail sont tout d’abord une contrainte de poids, la masse totale de la
nacelle ne devant pas excéder 2,5kg afin de pouvoir être portée par le ballon et
d’assurer une tension suffisante du fil la reliant au sol, des contraintes de résistance
mécanique afin de pallier à d'éventuelles mauvaises conditions climatiques, des
contraintes de réalisabilité des pièces, et enfin des contraintes de budget.
4.2. Choix et achat du ballon
Le PE 98 avait obtenu un budget BQP pour l'achat du ballon, cependant il
s'agissait d'un élément facultatif de leur projet. L'achat du ballon a été effectué par
leur groupe suite à une étude menée par notre équipe prenant en compte le budget
disponible et le type d'application auxquelles il est destiné.
Plusieurs caractéristiques sont à prendre en compte pour le choix du ballon. La
première et la plus évident est la capacité d'emport, ou force de traction. Celle-ci est
liée à deux paramètres : le volume et le type de gaz contenus dans l'enveloppe, et la
masse de celle-ci. Nous avons choisi d'utiliser un ballon à hélium, qui est la solution
majoritairement employée. La forme du ballon est également importante, en cela
qu'elle conditionne sa résistance au vent mais aussi ses possibilités de transport.
Une commande a donc été passée auprès de la société PHODIA4 concernant un
modèle gélule de 4,5m de long accueillant un volume de 15m3 permettant une charge
théorique de 5kg. L'écart avec la masse réelle de la nacelle s'explique par la nécessité
d'une assez grande tension de fil entre le sol et la nacelle, de manière à garantir une
plus grande stabilité de celle-ci. Cette stabilité est requise pour des applications vidéo.
Le coût initial de ce modèle dépassait le budget disponible, mais le fournisseur a
consenti à nous accorder une remise de 30% en contrepartie de la présence de son
logo sur les flancs du ballon. Le prix a donc été rapporté à 498 euros et le ballon a
donc été commandé. Malheureusement, à cause d'erreurs dans la gestion de la
commande, il ne nous est pas encore parvenu.
Fig 6: Ballon de marque Phodia
4 http://www.phodia.com
4.3. Rôle de la nacelle
La nacelle a plusieurs fonctions qui découlent de la fonction principale, explicitées ciaprès.
Supporter les
différents
composants
électroniques
sous le ballon
Accueillir en sécurité les
différents composants
Prévoir une bonne fixation
sur le bâti
Vis et entretoises
Prévoir une sécurité en
cas de décrochage
Couvercle
Permettre l’orientation
de la caméra
Autoriser deux axes de
rotation pour la caméra
Support mobile et deux
moteurs à vis sans fin
Fixer la nacelle au ballon
Prévoir un système
d’accrochage résistant
4 pièces fixées sur le bâti
4.4. Mesures des dimensions et masses des composants
électroniques présents
Afin de prévoir l'architecture de la nacelle, nous avons effectué un listage des
différents composants à insérer en y indiquant les dimensions et les masses. Voici
donc un tableau récapitulatif des composants dont nous disposons.
Composants
Dimensions
1. Carte microcontrôleur
Poids
120x140mm
2. Carte d'interface caméra
43x100mm
3. Carte supplémentaire
43x100mm
255g
4. Caméra
40x27x40mm
5. Batterie
40x75mm
105g
6. Module Wifi
120x95mm
175g5
7. Carte Batterie
103x60mm
50g
8. Câble Ethernet
30cm
40g
Fig 7: Masse des composants électroniques
4.5. Schéma de principe du système d’orientation de la
caméra
Le cahier des charges du projet demandait à ce que l’orientation de la caméra soit
possible, afin de suivre une cible en mouvement ou d’orienter correctement la caméra
en cas de rotation du ballon. Nous avons donc choisi un système permettant une
rotation de l’ensemble caméra suivant les axes vertical et horizontal comme le montre
le schéma cinématique suivant :
5 Un peu moins si l'on arrive à retirer la coque plastique.
Caméra
Fig 8: Schéma cinématique de l'articulation de caméra
La rotation suivant chaque axe est assuré par un moteur muni d’une vis sans fin
qui entraîne un engrenage fixé sur l’axe. Cela permet d’avoir un rapport de réduction
important et de moins solliciter le moteur.
4.6. Modélisation de la nacelle à l'aide du logiciel CATIA
Avant d'envisager la fabrication des pièces, nous avons réalisé une maquette en
3D à l'aide du logiciel Catia afin d'obtenir un premier aperçu de ce à quoi ressemblera
le produit final, mais également pour obtenir par la suite des résultats numériques sur
les caractéristiques mécaniques des pièces et vérifier qu'elles sont adaptées à notre
besoin. La maquette qui vient d'être terminée se présente de la manière suivante :
Fig 9: Vue de la nacelle sans couvercle Fig 10: Vue de la nacelle avec
couvercle
Les différentes pièces présentes dans cette structure et qui doivent être fabriquées ou
achetées sont présentées dans le tableau suivant.
Les pièces pouvant être achetées sont les axes, les engrenages, les moteurs et vis
sans fin. Elles peuvent être achetées chez Conrad6 ou Gotronic7.
6 www.conrad.fr
7 www.gotronic.fr
Plaque 1
Dimensions : 400x250mm
Type de matériau : Aluminium ou plastique
Masse : 400g
Poignées x4
Type de matériau : Aluminium
Masse : 30g
Axe x2
Dimensions : Φ3mm x 150mm
Poids : 25g
Plaque 1
Masse : 50g
Plaque 2 x2
Masse : 50g
Moteur et vis sans fin
Masse : 75g
Roue dentée 6-42
Dimensions : Φ60mm
Type de matériau : plastique
Masse : 10g
Roue dentée 6-43
Dimensions : Φ80mm
Type de matériau : plastique
Masse : 15g
Fig 11: Tableau des pièces composant la nacelle
Il faut enfin rajouter les petits éléments : vis, circlips, roulement à billes et support qui
représentent une masse d’environ 50g au total.
4.7. Suite de la réalisation
La suite du projet dans la partie mécanique va consister à mieux définir les
pièces que nous avons à réaliser pour pouvoir les usiner rapidement. Ensuite nous
pourrons effectuer quelques essais pour vérifier la validité du système que nous avons
conçu en particulier au niveau de la résistance afin d’éviter tout risque de chute de
composants. Cette dernière partie prendra sans doute un temps important car il
faudra sûrement apporter quelques améliorations au système.
5. Choix de la motorisation
5.1. Choix du type de moteurs
Pour orienter la caméra, nous avons besoin d'une grande précision et pouvons
nous satisfaire d'une faible vitesse. De plus, il est important que la caméra soit
maintenue en position et que la technologie du moteur soit adaptée à notre méthode
de commande. Pour cette raison nous avons choisi des moteurs pas à pas pour
l'orientation de la caméra.
5.2. Qu'est-ce qu'un moteur pas à pas?
Les moteurs pas à pas permettent de couvertir directement un signal électrique
numérique
en un positionnement angulaire de caractére incrémental. Chaque impulsion envoyée
par le
system de commande au module de puissance se traduit par la rotation d'un pas du
moteur. la résolution angulaire d'un moteur pas à pas va de 4 à 400 pas.
5.3. Classification du moteur pas à pas
On peut distinguer trois catégories technologiques :
● Moteur à reluctance variable. Le noyau de fer doux se positionne dans l'axe du
flux crée par les enroulements alimentés, afin de réduire l'entrefer (loi du flux
maximal). La réluctance du circuit magnétique varie pendant le mouvement du
noyau. La polarité du courant est sans importance. Le nombre de pas par tour
est relativement élevé.
● Moteur à aimants permanents. L'aimant permanent se positionne dans l'axe du
flux crée par les enroulements. Ce type de moteur possède hors tension, un
couple résiduel appelé "couple de détente". Le couple moteur est relativement
important.
● Moteur hybride. Ce sont des moteurs à réluctance variable dont le rotor est
aimanté. En général, en tenant compte de la précision et du coût, la plupart des
applications utilisent un moteur hybride.
Fig 12: Comparaison des 3 types de moteurs pas à pas
5.4. Paramètres caractéristiques
Couple d'arrêt ou couple de maintien
Le couple maximum de rotation avec lequel on peut solliciter l'arbre d'un moteur pas à
pas excité statiquement, sans qu'il ne se produise de modification de son angle de
rotation.
Plage de démarrage
Plage dans laquelle un moteur pas à pas peut être actionné en synchronisation avec la
fréquence de travail sans rampe d'accélération ou de décélération.
Fréquence limite de démarrage
Fréquence maximale avec laquelle un moteur pas à pas ne peut démarrer à la charge
indiquée, sans perdre de pas.
Plage d'accélération
Plage de travail dans laquelle un moteur pas à pas peut être actionné en
synchronisation avec la fréquence de travail, sans qu'il ne se produise d'erreur de pas.
Il faut cependant qu'il soit actionné avec une rampe d'accélération et de décélération.
Couple limite de travail
Le couple de rotation maximale avec lequel on peut solliciter un arbre de rotation
avant qu'il ne sorte de la cadence.
Fréquence maximale des pas
La fréquence maximale admise avec laquelle un moteur pas à pas est actionné à vide
sans perte de pas. Cependant, le moteur ne peut être démarré ou stoppé avec cette
fréquence sans perte de pas.
5.5. Moteurs retenus
Notre cachiers des charges:
● précision angulaire importante (rotation de la caméra par pas <1°)
● vitesse peu élevée
● bon maintien en position
Nous avons finalement choisi le moteur pas à pas de marque Tamagawa
disponible chez le fournisseur Conrad. Pour l'alimenter en énergie, une interface de
puissance devra être placée entre la carte embarqué et le moteur, de plus, des
composants dédiés aux moteurs pas à pas permettent de faciliter leur contrôle.
Command numérique
Interface
Actionneur de caméra
Fig 13: Design logique de la chaine d'action
Carte de contrôle
MCF5272
Contrôleur de
moteur pas à pas
LMC6001
L297
Moteur pas a pas
TAMAGAWA
Fig 14: Design physique de la chaine d'action
Fig 15: Moteur pas à pas Tamagawa
6. Amélioration des performances vidéo
6.1. Introduction
Les objectifs que nous nous sommes donnés concernant l'utilisation de notre
système imposent des performances vidéo suffisantes pour filmer un évènement
sportif. Comme les parties précédentes le montrent, le dispositif réalisé par le groupe
de PE 98 n'avait pas d'exigeances précises de ce côté, par conséquent ses
performances sont faibles et ne nous suffisent pas. C'est pourquoi l'un des objectifs
donnés à notre projet consistait à améliorer ces performances pour les mettre au
niveau de notre cahier des charges. Malheureusement, nous n'avons pas obtenu le
budget nécessaire à l'achat des nouveaux composants qui étaient requis, néanmoins
nous allons présenter les études et choix qui avaient été faits.
6.2. Augmentation de la définition
Comme spécifié dans le cahier des charges, nous souhaitions pouvoir capturer
des vidéos à une résolution proche du VGA (640x480). La caméra actuelle ayant une
définition plus faible, nous n'avions pas d'autre choix que de la remplacer par un
modèle supérieur. Notre choix s'était porté sur le module C38a fourni par Lextronics (le
même que pour la caméra actuelle) qui a pour avantage d'être en tous points
identique au module actuel, excepté le capteur plus grand8 et la résolution supérieure.
L'adaptation à ce nouveau module aurait donc été très rapide.
6.3. Question de l'angle de champ
Etant donné l'application envisagée de notre appareil, nous nous sommes
interrogés sur l'angle de vision que proposent ces caméras. En effet, elles sont livrées
avec un objectif à focale fixe, la scène capturée est donc uniquement dépendante de
la distance de la caméra. Les focales des objectifs sont données, nous avons donc pu
calculer l'angle de vision et voir comment cela se traduisait dans une situation
concrète. De plus, nous avons également calculé la dimension d'un objet représenté
par un pixel.
Pour cela, on utilise les résultats suivants, dans le cas d'une scène à l'infini :
C
d
D∗d
α=2∗arctan   et C=
2f
f
où l'on a les grandeurs suivantes :
α : angle de champ
d : taille du capteur9
D : distance de la scène
C : champ couvert
f : focale de l'objectif
α
D
f
d
Fig 16: Figure pour calcul de l'angle de
champ
8 1/3" de diagonale au lieu de 1/4"
9 taille horizontale ou verticale suivant l'ange de champ que l'on souhaite calculer
Les calculs, effectués pour les deux caméras équipées chacune de leur objectif
donnent les résultats suivants :
Modèles
CA88
C38a
Taille du capteur (horizontal)
3,1mm
4,9mm
Focale de l'objectif
4,9mm
6mm
Focale équivalente en 24x36
53mm
41mm
Nombre de pixels (horizontal)
356
664
Angle de champ (horizontal)
35°
44°
Champ couvert à 20m
12,6m
16,2m
Champ couvert à 100m
63m
81m
Taille pixel à 20m
3,5cm
2,4cm
Taille pixel à 100m
17cm
12,2cm
Fig 17: Comparaison des caméras
Le module C38a aurait donc permi d'avoir à la fois un champ couvert plus large
et une meilleurse définition des détails. Pour s'en rendre compte, deux photographies
ont été réalisées avec un appareil photo numérique réglé de manière à reproduire les
résultats ci-dessus.
CA88
C38a
Fig 18: Simulation de la vue des deux caméras
Ici l'angle de champ est fixe, pour pouvoir le changer il faudrait remplacer
l'objectif des deux caméras par un objectif zoom. Des focales de 3,5 à 8mm sont
facilement disponibles, mais à cause de la limitation de budget nous n'avons pu
considérer leur achat.
6.4. Augmentation de la cadence d'images
Le dispositif du PE98 est limité à 1 ou 2 images par seconde à cause de la
méthode d'acquisition utilisée. La caméra produit deux types de signaux, les signaux
de données et ceux de synchronisation. Les premiers correspondent aux valeurs des
composantes de pixels et les seconds indiquent le début d'une nouvelle trame ou
d'une nouvelle ligne, mais servent également à indiquer la cadence de sortie des
pixels. Les sorties correspondant à ces différents signaux sont toutes reliées aux
broches de la carte embarquée, par conséquent il est nécessaire de réaliser une
dectection logiciel des différents fronts mis en jeu, et on est ici limité par les capacités
de la carte.
Pour contourner cette limitation, on peut utiliser la méthode qui a été appliquée
par le projet Aurore : il s'agit d'intercaler entre la carte et la caméra un circuit
électronique (réalisé avec un EPLD10 qui est un composant électronique
reconfigurable) qui sera chargé de traiter matériellement les différents signaux et de
remplir un mémoire avec les données issues de la caméra pour une image entière.
Une fois cette opération réalisée, la carte embarquée peut lire le contenu de la
mémoire en une seule fois et de façon rapide. Cette méthode permet d'atteindre des
vitesses supérieures, malheureusement nous n'avons pas obtenu le budget nécessaire
à l'achat des nouveaux composants.
Ordres de marche
Signaux de contrôle
EPLD
Adresses mémoire
Carte
DNP5280
Données
RAM
Données
Caméra
Fig 19: Schéma de principe de l'interface
d'acquisition d'image
10 Electrically Erasable Programmable Logic Device, circuit logique programmable effaçable
électriquement
7. Traitement de l'image.
La qualité des images en sortie de la caméra peut nécessiter une amélioration.
C’est pour répondre à ce besoin qu’une partie du projet est dédiée à cette tâche.
En effet, nous utilisons une webcam de Lextronics, modèle CA88 à basse résolution
(352x288). D’après de ce que nous avons pu voir lors des tests dirigés par l’équipe du
projet 98, les images nous semblaient de piètre qualité. En particulier, elles étaient
floues, peu contrastées et trop lumineuses. Il a donc fallu chercher une solution
logicielle notamment pour l’augmentation de la netteté.
La partie de programmation propre a commencé en février, après une phase
assez longue de documentation, le traitement de l’image étant une discipline
relativement nouvelle pour l’équipe du projet.
Le format des images générées par la caméra est le ppm11 (acronyme de
Portable PixMap). C’est un format simple, sans compression. Le fichier commence par
un mot-clé, dans notre cas « P3 » pour une image en couleur. Après un saut de ligne,
on a la possibilité de laisser une ligne de commentaire, précédée par le signe « # ».
Puis viennent après un saut de ligne la largeur et la hauteur (entiers), séparés par un
espace. Après un nouveau saut de ligne, on trouve un entier désignant le nombre
maximum utilisé pour coder les couleurs (255 pour 256 nuances de chaque
composante de rouge, vert et bleu). Ensuite, on a le corps de l’image, c'est-à-dire une
suite de pixels représentés par leurs composantes rouge, vert et bleu séparées par des
espaces.
Exemple de fichier ppm.
Le programme réalisé comporte tout d’abord deux fonctions de bases :
l’ouverture d’une image en spécifiant son nom et la sauvegarde d’une image. La
fonction d’ouverture vient lire les informations dans le fichier image et les stocke dans
une structure de matrice de pixels, où un pixel est un triplet de trois entiers
représentants les composantes RGB (Red, Green, Blue). La fonction de sauvegarde
permet de créer un fichier image au format ppm à partir d’une matrice de pixels.
NB : se référer au code source pour de plus amples informations.
La fonction principale réalisée par le programme est l’augmentation de la
netteté. La méthode utilisée est la suivante (Unsharp Mask en anglais) :
- on charge une image, que l’on garde en mémoire et on la « floute » à l’aide
d’une première fonction ;
- on soustrait ensuite l’image « floutée » à l’image originale ; on obtient alors
un masque avec tous les détails de l’image ;
- on ajoute le masque précédemment obtenu à l’image originale ; tous les
détails sont donc rehaussés et on obtient une image plus nette.
11 cf Annexe 3
Image originale
Image « floutée »
Masque avec les détails
Résultat final
Fig 20: Résultats du traitement anti-flou
Le principal inconvénient de cette méthode est d’introduire du bruit dans
l’image, ou plutôt d’accentuer le bruit déjà existant. Cependant elle a l’avantage
certain d’être rapide et facile à mettre en œuvre.
D’autre part, le résultat peut varier en fonction de la méthode de flou utilisée. Ici, on
utilise une méthode par moyenne (Box-filtrer 2D). Cependant d’autres méthodes
peuvent donner de meilleurs résultats, notamment les méthodes de flou gaussien ou
par sélection, qui permet par exemple de « flouter » certaines zones en gardant
d’autres nettes. Il faut analyser les images et la manière dont elles sont bruitées pour
déterminer la méthode optimale, des échantillons d’images de la caméra sont donc
nécessaires pour mettre ces nouveaux algorithmes en place.
Le programme réalisé comprend de plus une fonction d’augmentation ou de
diminution de la luminosité, mais son intérêt peut être discuté car la caméra utilisée
comprend déjà un réglage de la luminosité.
En ce qui concerne le réglage du contraste, il paraît difficile de l’automatiser
dans le programme, l’analyse des histogrammes de couleurs pouvant s’avérer ardue à
programmer. La programmation de fonctions aidant l’utilisateur dans cette analyse et
permettant ensuite de régler le contraste directement sur le capteur de la caméra est
cependant prévue.
Enfin, des outils d’analyse interne et de débogage sont présents, notamment
une fonction qui permet d’afficher les entiers correspondant aux différentes
composantes de couleur et une fonction calculant le « pixel moyen » d’une image,
c’est-à-dire qui réalise la moyenne des trois composantes de couleur de l’image.
D’autres fonctions ont également été programmées d’après la documentation
fournie par M. Saïdi, mais étant une application directe de la théorie, elles se révèlent
totalement sans intérêt dans la pratique (fonction de calcul de convolution et de « flou
diffusif »
8. Stockage et diffusion des images
8.1. Stockage des images
Tel qu’il a été réalisé par le PE 98 promotion 2008, le programme client
sauvegarde déjà toutes les images au fur et à mesure qu’elles sont reçues. Après cela,
elles peuvent être par exemple assemblées en vidéo ou rester stockées en l’état. La
question du stockage est déjà résolue, nous pouvons donc nous concentrer sur la
diffusion des images.
8.2. Diffusion des images
Pour la diffusion des images vers l’extérieur, plusieurs possibilités s’offrent à
nous : nous pouvons mettre les vidéos à disposition en téléchargement complet ou les
proposer en streaming (lecture en continu). La solution du téléchargement complet est
la plus aisée à mettre en place, mais le streaming permet à l’utilisateur de ne pas
avoir à télécharger complètement le fichier avant de pouvoir commencer à regarder la
vidéo.
Techniquement, le principe du streaming est le suivant : le programme de
lecture en continu, sur l’ordinateur client, va récupérer une partie du contenu, qu'il
place dans une mémoire tampon (dite buffer). Lorsqu'il y a suffisamment de données
dans cette mémoire pour permettre de lire le début du fichier audio ou vidéo sans
accroche, et cela même en cas de petits ralentissements réseau, la lecture démarre.
En arrière-plan, le téléchargement du flux se poursuit afin d'alimenter sans cesse la
mémoire tampon avec la suite du fichier.
Théoriquement, pour chaque connexion à un serveur de streaming vidéo en
temps réel, l'intégralité du flux doit être envoyée, la consommation de la bande
passante sera donc proportionnelle au nombre de clients, la connexion risquerait donc
de saturer rapidement. C'est pourquoi nous allons nous appuyer sur un protocole
multicast (multidiffusion) qui n'envoie qu'une fois la vidéo sur un réseau, et c'est
ensuite le réseau lui-même qui permet la distribution du flux aux clients qui s'y
inscrivent. Cela est bien plus efficace et est déjà présent sur le campus de l’Ecole : en
effet, c’est par ce moyen que le club audiovisuel diffuse les chaines de la télévision
numérique terrestre (TNT) sur le réseau de l’Ecole. Des solutions gratuites pour
effectuer cette diffusion existent déjà : l’exemple le plus connu est sans aucun doute
VLC media player, logiciel faisant partie du Projet VideoLAN12. La réception peut aussi
se faire avec le même logiciel utilisé en tant que client.
Si la vidéo est déjà complète, ce type de diffusion (en différé) ne pose pas de
problème particulier : la vidéo peut être envoyée directement sur le réseau en
choisissant simplement le fichier à envoyer dans le programme de multidiffusion. Par
contre, si l’on veut diffuser les images au fur et à mesure qu’elles arrivent sur le PC
client (en direct ou avec un écart de temps très faible), il nous faut les convertir en un
flux interprétable par le logiciel de multidiffusion. Dans le programme client du groupe
de PE 98 promotion 2008, une fonction renvoie ce qui est reçu sur la sortie standard.
Sous cette forme, on ne peut pas en faire de multicast, il nous faut donc rediriger ou
convertir cette sortie de manière à obtenir un format reconnu par le logiciel multicast.
C’est ce travail que nous allons prochainement réaliser, sachant que nous en sommes
pour l’instant à la documentation, d’une part sur la multidiffusion et d’autre part sur
les programmes existants réalisés par le groupe précédent.
12 www.videolan.org
9. Conclusion et perspectives
Malgré une certaine lenteur au démarrage, dûe au fait qu'il était difficile de
prendre la suite d'un projet qui était encore en cours de réalisation, notre projet
avance maintenant à un rythme satisfaisant et nous pensons pouvoir respecter le
planning.
Cependant, plusieurs difficultés se sont présentées. Tout d'abord, à cause d'une
erreur dans la gestion de la commande, le ballon que nous avons choisi il y a plusieurs
mois ne nous est pas encore parvenu. Par chance, il nous reste encore quelques mois
avant qu'il ne nous soit vraiment nécessaire pour l'assemblage de l'ensemble. Nous
espérons le réceptionner prochainement. L'autre partie importante du projet, la
réalisation de la nacelle, est en progrès. Sa conception est terminée et sa construction
pourra bientot commencer.
Le fait que nous n'avons pas obtenu le budget nécessaire à l'amélioration de la
qualité vidéo nous contraint à laisser de côté cet aspect, mais ne nous empêchera pas
d'obtenir un système opérationnel et nous laisse le temps de nous concentrer sur les
autres aspects du projet.
Ces six mois de travail nous on apporté plus que de simples réalisations
techniques : nous avons également appris à travailler en équipe, à prendre des
décisions en groupe et à rendre compte de notre travail. Ces différents aspects de la
conduite de notre projet vont être présentés dans la deuxième partie de ce rapport.
Analyse du processus de projet
1. L’équipe
L’équipe
-
se compose de six membres :
Maxime STORN, chef de projet
Boris CHABILAN, responsable budget
Clément CHASTAGNOL, responsable comptes-rendus
Baptiste JOALLAND, responsable documents
Damien OCTEAU, responsable site Web
Guixi ZOU13, responsable planning
L’initiative de la constitution de l’équipe revient à Maxime, qui a été nommé chef
de projet à l’unanimité. Il n’a pas eu de grande difficulté à trouver des membres, ce
qui s’explique par la grande diversité des domaines mis en jeu dans le projet.
2. Présentation personnelle de chaque membre et de ses
motivations
Maxime STORN
Je viens d'une classe préparatoire PSI*, après un bac S option SI, et je suis
particulièrement interessé par l'aspect "système embarqué" de ce projet d'étude.
J'ai déjà eu une expérience de ce genre il y a quelques temps avec mon TPE de
terminale, qui impliquait tous les domaines m'intéressant : du logiciel de commande à
la maquette, en passant par l'électronique que l'on trouve nécessairement entre les
deux. J'ai donc choisi ce PE pour poursuivre sur ce profil polyvalent qui correspond au
travail de l'ingénieur généraliste, qui doit assurer le lien entre les différents aspects
d'un système. Je souhaite également accroître mes compétences en informatique et
électronique dans le domaine des systèmes embarqués.
D'autre part, le rôle de chef de projet que j'occupe me permet de me familiariser
avec l'organisation d'un projet et la gestion d'une équipe. J'ai déjà découvert
l'importance d'une bonne communication et d'une répartition des tâches sans
ambiguité, et la difficulté à concilier les disponibilités d'une dizaines d'acteurs pour le
projet.
Boris CHABILAN
J'ai choisi ce projet car il fait intervenir différents domaines pour lesquels j'ai des
connaissances de base que je souhaite mettre à profit. Je me suis plus
particulièrement investi dans la partie mécanique du projet, et j'ai également pris le
poste de trésorier.
De plus, lors de l'achat du ballon j'ai pu me confronter aux contraintes imposées
par la présence de plusieurs interlocuteurs différents, mais également me rendre
compte qu'un bon sens de la négociation peut s'avérer utile pour la réussite d'un
projet.
13 élève chinois présent uniquement lors de la première année
Clément CHASTAGNOL
J'ai fait une première et une terminale option SI, puis une MPSI et une PSI*. J'ai
des quelques compétences en électronique, informatique et technologie mécanique, je
suis donc assez polyvalent.
Ce sujet m'a particulièrement plu car il fait intervenir divers domaines
scientifiques. De plus mon intérêt pour le modélisme m'a poussé à m'engager dans ce
projet.
La partie qui m'intéresse particulièrement est plus orientée informatique : il
s'agit du traitement de l'image. Mon TIPE portait sur la compression de données,
notamment des images, je souhaite donc m'investir dans cette voie.
Baptiste JOALLAND
Etant ancien étudiant de classe prépa filière PT, j'ai pu étudier les différentes
étapes permettant la réalisation d'un système mécanique. C'est pourquoi je me suis
orienté vers ce projet qui comprend la réalisation complète de la nacelle. J'essaye ainsi
d'apporter mes connaissances dans la partie mécanique du projet pour la concevoir et
la réaliser dans les meilleurs conditions.
De plus ce projet m'a permis d'encore mieux appréhender l'approche qu'on doit
avoir face à la conception du système afin de concilier respect du cahier des charges
et les contraintes de temps et de budget inhérentes.
Damien OCTEAU
J'ai fait une classe préparatoire section MP (option SI) et je suis intéressé par les
technologies de l'information et de la communication, plus particulièrement par
l'informatique.
Bien que n’ayant pas de compétence dominante, j'ai une forte volonté de me
former dans le domaine de l'informatique, ce qui me pousse habituellement à choisir
pour mes projets des sujets qui s'y prêtent (par exemple mon TIPE concernait la
cryptographie). C'est pourquoi j'ai choisi ce sujet, la partie informatique étant très
importante. L'autre aspect du projet qui m'a intéressé est le fait qu'il ne se limite pas à
la réalisation d'un ou plusieurs logiciels, le but étant de réaliser un système
physiquement concret.
Guixi ZOU
Je viens de Chine. Avant de venir à l’Ecole centrale de Lyon, j’ai déjà eu 4
années de formation supérieure en électronique en Chine. Pendant ces quatre années,
j’ai acquis des connaissances en électronique et en informatique.
Cette projet m’intéresse parce qu’il présente un aspect temps réel embarqué et
qu’il combine la mécanique, l'électronique et l'informatique. La partie qui m'intéresse
particulièrement est plus orientée électronique, il s'agit du contrôle du moteur. Je
souhaite donc m'investir dans cet aspect.
3. Organisation du projet
Il est apparu très rapidement que l’on pouvait diviser le projet en deux grandes
parties : une partie mécanique/électronique qui a pour but de faire voler le système
embarqué et une partie informatique qui reprend et améliore le système existant.
Chacune de ces deux parties peut suivre une évolution relativement autonome,
comme cela apparait sur l’organigramme des tâches suivant :
Projet d'Etudes 78 – Ballon Captif
Organigramme des tâches
Nacelle :
Système
mécanique
et électronique
Conception et réalisation du
carter de protection et
système d'accrochage,
et du support articulé de caméra.
Boris
Baptiste
Choix des actionneurs du
support de caméra et
électronique associée
Guixi
Traitement et amélioration
des images
Clément
Stockage et diffusion
des images
Damien
Commande à distance
de la caméra
Maxime
Ballon
Captif
Logiciel client :
Logiciel de
traitement des
images et
de commande
Fig 21: Organigramme des tâches
Il est important de noter que, bien que les deux parties puissent être dans une
certaines mesure menées indépendamment l’une de l’autre, elles gardent quand
même une certaine cohésion. En effet, la tâche de Maxime est la conception de la
commande à distance de la caméra, ce qui fait le lien entre les deux grands domaines
de notre projet. De plus, sa fonction de chef de projet lui permet de faire le lien entre
les deux parties lorsque c’est nécessaire. Cela permet de garder une bonne
cohérence, ce qui est impératif dans un projet qui touche à un grand nombre de
disciplines.
4. Budget
La gestion du budget accordé au projet est très importante et il est vite apparu
que la somme de 300€ qui est accordé par défaut à tous les projets nous serait
insuffisante, bien que la grosse dépense représentée par l'achat du ballon a été
effectuée par le groupe de PE98. Nous avons donc décidé de postuler pour un BQP
comme l'avait fait leur groupe avant nous14.
Nous avons demandé une somme de 664€ afin de couvrir les dépenses
nécessaires à la réalisation de la nacelle et à l'amélioration de la qualité vidéo. Nous
avons également tenté d'obtenir un supplément pour d'éventuelles réalisations
dépassant notre cahier des charges. Après délibération, le jury a considéré qu'il était
préférable de se concentrer sur la réalisation d'un système opérationnel avant
d'embarquer du matériel plus coûteux. Nous avons donc obtenu une partie de la
somme demandée, à savoir 205€.
Comme il a été dit, cette somme nous permettra de réaliser la partie ballon et
nacelle en conservant le système vidéo actuel.
14 voir annexe 1
Outils de gestion de projets
Diagramme PERT
Choix du ballon
Achat du ballon
Structure nacelle
Conception de l'architecture
Dessin technique
des pièces
Conception de
l'interface
Choix du moteur
Debut
Réalisation
Codage
Documentation sur
la diffusion d'images
Optimisation
Assemblage de
la nacelle
Définition du Cdc
Documentation sur
le traitement d'images
Fin
Réalisation
des pièces
Essai
Debuggage, tests
Codage
Choix materiel
et achat
Etude du système actuel.
Debuggage, tests
Réalisation et adaptation
du programme
Tests
PE98
Fig 22: Diagramme PERT du projet
Integration dans
le logiciel final
Diagramme GANTT
Définition du cahier des charges
Choix et achat ballon
Réunions avec le PE98
Structure nacelle
Conception de l'architecture
Dessin technique
des pièces
Réalisation
des pièces
Choix du moteur
Conception de
l'interface
Réalisation
Assemblage de
la nacelle
Documentation sur
le traitement d'images
Codage
Debuggage, tests
Documentation sur
la diffusion d'images
Codage
Debuggage, tests
Etude du système actuel.
Choix materiel
et achat
Réalisation et adaptati on
du programme
Tests
Integration dans
le logiciel final
Exploitation
et optimisation
RVP1
RVP2 BQP
RVP3
Sept 06 Oct 06 Nov 06 Dec 06 Jan 07 Fevr 07 Mars 07 Avril 07 Mai 07 Juin 07 Sept 07 Oct 07 Nov 07 Dec 07 Jan 08
Fig 23: Diagramme GANTT du projet
Conclusion générale
Dès le départ, nous avons été confrontés aux deux spécificités de ce projet. La
première est qu'il recouvre de nombreux domaines scientifiques, et que par
conséquent les compétences de chacun allaient se montrer complémentaires. La
second, et peut-être la plus contraignante, est qu'il s'agissait de prendre la suite d'un
projet qui n'était pas encore terminé.
En effet, il fut difficile pour nous au départ de commencer notre projet quand
nous sachions que le système sur lequel nous devions nous baser était encore en
cours de développement, et que par conséquent nous n'avion pas toutes les
informations que nous voulions. Heureusement, le fait que notre projet présente une
partie mécanique relativement indépendante de la partie électronique et informatique
nous a permis de démarrer tout de même.
Nous sommes confiants dans l'avancement du projet et pensons obtenir un
système opérationnel à temps, bien que ses performance devraient être inférieures à
celles que nous souhaitions à cause de la limitation du budget. Nous espérons que,
une fois notre système terminé, il pourra encore être l'objet d'un nouveau projet
d'étude chargé d'apporter encore de nombreuses améliorations auxquelles nous avons
pensé mais avons renoncé à réaliser faute de moyens et de temps.
Nous tenos également à remercier les différents intervenants qui nous ont aidé
jusque là, particulièrement nos deux tuteurs scientifiques et nos conseillers en
communication et gestion de projet. Remercions également le groupe de PE 98 dont le
système nous sert de base et donc les efforts pour faciliter le passage de relais ont été
grandement appréciés.
Annexes
ANNEXE 1 : Budget détaillé
Budget PE 78
Libellé
Référence
(1) Moteurs pas à pas (x2)
0161339-62
(1) Pièces simples pour nacelle
(1) Fabrication pièces à Centrale
(1) Plein hélium 18m^3
(2) Caméra numérique
C38A
(2) Objectif zoom
750527-62
(2) Mémoire 8Mb + composants
(3) Capteurs gyroscopiques
(3) Servomoteur
(4) Frais divers
Fournisseur
Conrad
Conrad
Phodia
Lextronics
Conrad
Conrad
Prix (TTC)
40,00
75,00
30,00
360,00
69,01
85,00
30,00
130,00
45,00
100,00
Total dépenses
Budget accordé
Différence
Seul le budget nécessaire à la partie (1) a été accordé, soit 205 euros.
€
€
€
€
€
€
€
€
€
€
964,01 €
300,00 €
-664,01 €
ANNEXE 2 : Caméra numérique (extraits)
ANNEXE 3 : PPM Format Specification
PPM - Netpbm color image format
This program is part of Netpbm(1). The PPM format is a lowest common denominator color image
file format. It should be noted that this format is egregiously inefficient. It is highly redundant, while
containing a lot of information that the human eye can't even discern. Furthermore, the format
allows very little information about the image besides basic color, which means you may have to
couple a file in this format with other independent information to get any decent use out of it.
However, it is very easy to write and analyze programs to process this format, and that is the point.
It should also be noted that files often conform to this format in every respect except the precise
semantics of the sample values. These files are useful because of the way PPM is used as an
intermediary format. They are informally called PPM files, but to be absolutely precise, you should
indicate the variation from true PPM. For example, 'PPM using the red, green, and blue colors that
the scanner in question uses.' The name "PPM" is an acronym derived from "Portable Pixel Map."
Images in this format (or a precursor of it) were once also called "portable pixmaps." The format
definition is as follows. You can use the libnetpbm(1)Csubroutinelibrarytoreadand interpret the
format conveniently and accurately. A PPM file consists of a sequence of one or more PPM
images. There are no data, delimiters, or padding before, after, or between images. Each PPM
image consists of the following:
A 'magic number' for identifying the file type. A ppm image's magic number is the two characters
'P6'. .IP â€¢
Whitespace (blanks, TABs, CRs, LFs).
A width, formatted as ASCII characters in decimal.
Whitespace.
A height, again in ASCII decimal.
Whitespace.
The maximum color value (Maxval), again in ASCII decimal. Must be less than 65536 and more
than zero.
Newline or other single whitespace character.
A raster of Height rows, in order from top to bottom. Each row consists of Width pixels, in order
from left to right. Each pixel is a triplet of red, green, and blue samples, in that order. Each sample
is represented in pure binary by either 1 or 2 bytes. If the Maxval is less than 256, it is 1 byte.
Otherwise, it is 2 bytes. The most significant byte is first. A row of an image is horizontal. A column
is vertical. The pixels in the image are square and contiguous.
In the raster, the sample values are 'nonlinear.' They are proportional to the intensity of the ITU-R
Recommendation BT.709 red, green, and blue in the pixel, adjusted by the BT.709 gamma transfer
function. (That transfer function specifies a gamma number of 2.2 and has a linear section for
small intensities). A value of Maxval for all three samples represents CIE D65 white and the most
intense color in the color universe of which the image is part (the color universe is all the colors in
all images to which this image might be compared). ITU-R Recommendation BT.709 is a renaming
of the former CCIR Recommendation 709. When CCIR was absorbed into its parent organization,
the ITU, ca. 2000, the standard was renamed. This document once referred to the standard as CIE
Rec. 709, but it isn't clear now that CIE ever sponsored such a standard. Note that another popular
color space is the newer sRGB. A common variation on PPM is to subsitute this color space for the
one specified.
Note that a common variation on the PPM format is to have the sample values be 'linear,' i.e. as
specified above except without the gamma adjustment. pnmgamma takes such a PPM variant as
input and produces a true PPM as output.
Characters from a '#' to the next end-of-line, before the maxval line, are comments and are
ignored.
Note that you can use pamdepth to convert between a the format with 1 byte per sample and the
one with 2 bytes per sample. There is actually another version of the PPM format that is fairly rare:
'plain' PPM format. The format above, which generally considered the normal one, is known as the
'raw' PPM format. See pbm(1)forsomecommentaryonhowplain and raw formats relate to one
another. The difference in the plain format is:
There is exactly one image in a file.
The magic number is P3 instead of P6.
Each sample in the raster is represented as an ASCII decimal number (of arbitrary size).
Each sample in the raster has white space before and after it. There must be at least one
character of white space between any two samples, but there is no maximum. There is no
particular separation of one pixel from another -- just the required separation between the blue
sample of one pixel from the red sample of the next pixel.
No line should be longer than 70 characters.
Here is an example of a small pixmap in this format.
P3
# feep.ppm
44
15
0 0 0 0 0 0 0 0 0 15 0 15
0 0 0 0 15 7 0 0 0 0 0 0
0 0 0 0 0 0 0 15 7 0 0 0
15 0 15 0 0 0 0 0 0 0 0 0
There is a newline character at the end of each of these lines. Programs that read this format
should be as lenient as possible, accepting anything that looks remotely like a pixmap.
.SH COMPATIBILITY Before April 2000, a raw format PPM file could not have a maxval greater
than 255. Hence, it could not have more than one byte per sample. Old programs may depend on
this. Before July 2000, there could be at most one image in a PPM file. As a result, most tools to
process PPM files ignore (and don't read) any data after the first image.
Copyright (C) 1989, 1991 by Jef Poskanzer.
Bibliographie
[1] GNU/Linux Magazine France HS n°23 (02/06), « Electronique et Linux »
[2] GNU/Linux Magazine France HS n°24 (04/06), « Linux embarqué »
[3] Friedt J-M, Site personnel : http://jmfriedt.free.fr/
[4] Association Sequanux (2006), « Projet Aurore », http://www.sequanux.org
[5] SSV Embedded (2006), Site web de la société, http://www.ssv-embedded.de
[6] B. Jaehne, Design and Graphics - Digital image processing, université d'Heidelberg
[7] Université de France-Compté, « Projet Aurore », http://projetaurore.assos.univ-fcomte.fr/
Table des figures
Fig
Fig
Fig
Fig
Fig
Fig
Fig
Fig
Fig
Fig
Fig
Fig
Fig
Fig
Fig
Fig
Fig
Fig
Fig
Fig
Fig
Fig
Fig
1: La carte DNP/SK16L..............................................................................................7
2: Caméra CA88...................................................................................... ..................8
3: Caractéristiques de la caméra CA88.....................................................................8
4: Module WiFi Linksys WET11..................................................................................9
5: Batterie LiPo 2000mAh........................................................................................ ..9
6: Ballon de marque Phodia....................................................................................10
7: Masse des composants électroniques.................................................................11
8: Schéma cinématique de l'articulation de caméra...............................................12
9: Vue de la nacelle sans couvercle........................................................................12
10: Vue de la nacelle avec couvercle......................................................................12
11: Tableau des pièces composant la nacelle.........................................................14
12: Comparaison des 3 types de moteurs pas à pas...............................................15
13: Design logique de la chaine d'action.................................................................16
14: Design physique de la chaine d'action..............................................................16
15: Moteur pas à pas Tamagawa.............................................................................16
16: Figure pour calcul de l'angle de champ.............................................................17
17: Comparaison des caméras................................................................................18
18: Simulation de la vue des deux caméras............................................................18
19: Schéma de principe de l'interface d'acquisition d'image..................................19
20: Résultats du traitement anti-flou......................................................................21
21: Organigramme des tâches................................................................................26
22: Diagramme PERT du projet...............................................................................28
23: Diagramme GANTT du projet............................................................................29

Ballon Captif

Transcription

Documents pareils

A B E D C SITUER UN POINT C A D E F B SUR UNE FEUILLE

une démonstration ludique de l`effet joule

Panasonic nouvelle caméra d`épaule : AG-HPX600

CONVERTISSEUR FILM 8 MM EN VIDEO PAL Réf : ELMO 8

Interphone video exterieur - couleur mains libres

Forme d`un ballon de BoPET

Mise à l heure et date de la caméra espion Mettre une carte micro

Smart Nav 4.

Nouveau Document Microsoft Word (2)