DOCUMENT DE CONCEPTION

Département informatique
DOCUMENT DE CONCEPTION
Version 1.0
* photo non contractuelle
Projet d’architecture
Enseignants responsables et
clients :
Auguste LE VAN SUU
François TOUCHARD
SIGNATURE*
SIGNATURE*
* Le présent document devra être signé à réception par l’un des clients, au moins.
Maîtres d’œuvres :
Robin Haider
Alexandre Mély
Robin HAIDER
Alexandre MELY
Nicolas Combelles
Jessica Cortes
Espion Dirigeable
Document de pré-conception
Promotion 2007
1
SOMMAIRE
I. Domaine d’application ......................................................................3
1.1 Objectifs du système ........................................................................................................ 3
1.2 Interfaces utilisateurs, logiciels et matériels .................................................................... 6
1.3 Contraintes générales de conception................................................................................ 7
II. Documents de Référence .................................................................9
III. Conception générale .....................................................................10
3.1 Système d’exploitation utilisé........................................................................................ 10
3.2 Langages utilisés ............................................................................................................ 10
3.3 Architecture générale et interfaces détaillées des modules............................................ 11
3.3.1 Architecture générale .............................................................................................. 11
3.3.2 Interfaces détaillées des modules ............................................................................ 14
Spy Screen : Interface Utilisateur................................................................................. 15
Module de communication Hertzienne ........................................................................ 18
Module de communication parallèle ............................................................................ 19
Module de réception vidéo........................................................................................... 23
Mini-caméra ................................................................................................................. 24
Moteurs......................................................................................................................... 25
Programmation des PICs.............................................................................................. 26
Synthèse du module Ballon.......................................................................................... 37
Synthèse du module Poste de commande .................................................................... 38
Synthèse du module PC................................................................................................ 39
Présentation des circuits électroniques......................................................................... 40
IV. Spécifications techniques de l’Espion Dirigeable........................41
Robin HAIDER
Alexandre MELY
Espion Dirigeable
Document de pré-conception
2
I. Domaine d’application
1.1 Objectifs du système
D’après la première version du cahier des charges, le système devrait être décomposé
en trois grandes parties :
- L’Espion Dirigeable lui-même
- Le poste de commande relié à un ordinateur
- L’interface utilisateur permettant de contrôler le dirigeable.
Tourner à droite
Commandes numérique
par port série
Tourner à gauche
Avancer
Reculer
Interface
utilisateur
Émission des données
de la boussole
Commandes analogique
par ondes hertziennes
Monter
« Module sol »
Émission des données
de la boussole
Descendre
Acquérir données
de la caméra
Carte
d'acquisition
Émission des données
de la caméra
« Module air »
Décomposition générale basée sur la première version du cahier des charges.
De ce fait, chaque partie du système (sous-système) possède alors un objectif propre.
L’Espion Dirigeable : il devra pouvoir recevoir des données du boîtier de commande
via les ondes hertziennes haute fréquence (433 Mhz), et les interpréter de façon à
réagir en conséquence. Il devra en parallèle transmettre à la carte d’acquisition
présente sur l’ordinateur le flux vidéo acquis grâce à la caméra embarquée. Cette
dernière est cependant indépendante du reste du circuit et utilisera sa propre
alimentation.
Grâce à ses 3 hélices montées chacune sur des moteurs (2 pour la direction, 1 pour
l’altitude), l’Espion Dirigeable sera capable de se déplacer dans les airs. Ces moteurs
seront donc commandés par le boîtier de contrôle.
Robin HAIDER
Alexandre MELY
Espion Dirigeable
Document de pré-conception
3
Ballon gonf lé d' hélium
Ondes radio
(com m andes)
Ondes radio
(boussole)
Nacelle
Mot eurs à propulsion
horizont ale et vert icale
Boussole
Ondes radio
(vidéo)
Cam éra em barqué
Représentation schématique du module Espion Dirigeable.
Le poste de commande : il sert de relais entre l’ordinateur (interface utilisateur) et
l’Espion Dirigeable. En effet, ce sous-système prend en entrée des commandes codées
via le port parallèle de l’ordinateur, et doit rendre en sortie ces mêmes commandes,
mais cette fois-ci sous la forme d’ondes hertziennes.
Ondes radio
(boussole)
Ant enne
Connect eur
série
Ondes radio
(com m andes)
Micro int égré
Alim ent at ion
Sé
rie
RS232
Carte d'
acquisition
Commandes
Vidé
o
Entrées et sorties du poste de commande et sa
place dans le système global.
Robin HAIDER
Alexandre MELY
Espion Dirigeable
Document de pré-conception
4
L’interface utilisateur : présentée sous forme d’un programme graphique, cette
interface permettra à l’utilisateur, par le biais de la souris, de piloter son espion. Une
zone de visualisation – présente dans une fenêtre adjacente – sera aussi consacrée au
flux vidéo reçu de la caméra embarquée. L’objectif de cette partie du système est donc
de faire le lien entre l’Homme et la Machine, plus précisément, entre l’utilisateur,
notre client, et l’Espion Dirigeable, via le boîtier de commande.
Une révision importante du cahier des charges nous a contraint à réviser le nombre et
les fonctions des modules :
L’Espion Dirigeable : Ce module conserve l’ensemble de ses propriétés par rapport à
la version initiale du cahier des charges. Les commandes de direction ne sont
cependant plus reçues à partir du poste de commande mais à partir de la télécommande
fournie par le client.
Le poste de commande : Il sert dorénavant de relais entre l’ordinateur (interface
utilisateur) et le poste de réception. Ce sous-système prend toujours en entrée des
commandes codées via le port parallèle de l’ordinateur, et doit rendre en sortie ces
mêmes commandes, mais cette fois-ci sous la forme d’ondes hertziennes.
Le poste de réception : Ce module rajouté par rapport à la première version du cahier
des charges permet de recevoir les signaux hertziens émis par le poste de commande et
de les transmettre à la télécommande fournie par le client. Un module intermédiaire
(non détaillé ici du fait de sa simplicité) composé de relais électriques permettra
d’enclencher les commandes de la télécommande à partir des informations émises par
le poste de réception.
L’interface utilisateur : L’objectif de cette partie du système est de faire le lien entre
l’Homme et la Machine, plus précisément, entre l’utilisateur, notre client, et l’Espion
Dirigeable, via le boîtier de commande. Deux versions de l’interface sont disponibles
(cf. § description détaillée du module interface utilisateur).
Robin HAIDER
Alexandre MELY
Espion Dirigeable
Document de pré-conception
5
1.2 Interfaces utilisateurs, logiciels et matériels
Notre système décrit précédemment, peut être fonctionnellement divisé de la manière
suivante :
Espion Dirigeable
Moteurs
Poste de réception
Microcontrôleur
Module de
communication
Radiofréquence
Ensemble de
relais
Poste de commande
Module de
communication
Radiofréquence
Télécommande
Module de
communication
Radiofréquence
Microcontrôleur
Module de
communication
parallèle
Module de
communication
parallèle
Clavier
Robin HAIDER
Alexandre MELY
Interface utilisateur
IHM
Souris
Espion Dirigeable
Document de pré-conception
Ecran
6
1.3 Contraintes générales de conception
Contraintes liées au ballon dirigeable
Notre base de l’Espion Dirigeable est un ballon dirigeable en kit. Plusieurs
contraintes doivent être prises en compte lors de la conception.
o Contraintes physiques :
Selon la qualité du « tissu » constituant le ballon, le gaz plus léger que l’air
(hélium) utilisé s’échappe plus ou moins rapidement du conteneur. Nous
devons prendre en compte cette composante afin d’évaluer d’une part
l’autonomie maximum du ballon, et d’autre part, l’écart qu’il faudra prévoir
pour que le moteur vertical reste efficace le plus longtemps possible.
Nous devons prendre aussi en considération la composante poids. La taille
du ballon initiale contenant l’hélium est pré-calculée en fonction du poids de
l’armature standard du ballon. Or, notre projet nous amènera à y fixer une
caméra miniature, une boussole électronique, un circuit électronique
comprenant le microcontrôleur et le module Radiofréquence, plus une source
d’alimentation probablement différente (plus lourde ?) que celle d’origine.
C’est pourquoi nous envisagerons, si besoin est, de modifier la toile existante
ou d’ajouter un ou plusieurs ballon d’hélium à la structure actuelle.
Les contraintes atmosphérique devront être nulles. Le moindre souffle ou le
moindre écart de pression pourrait mettre l’Espion Dirigeable en difficulté.
C’est pourquoi notre produit n’est destiné qu’à être utilisé en intérieur.
o Contraintes électroniques
Le courant qui servira à alimenter les moteurs des pales sera traité par le
micro-contrôleur. Ceci peut poser problème dans le sens où la puce utilisée
pourrait être dans l’impossibilité de produire/gérer un courant avec l’ampérage
requis par ces moteurs. Nous devrons donc adapter le circuit en rajouter des
composants électronique afin de résoudre le problème. Voici l’une des raisons
justifiant la modification du cahier des charges par le client. Ce dernier a en
effet préféré nous demander d’utiliser la télécommande qu’il nous a fourni afin
de conserver le design de référence du ballon dirigeable.
Autonomie électrique du Spy-bot : Premièrement, le dirigeable sera équipé
d'une alimentation autonome (pile, accus, ...) pour faire fonctionner toute
l'électronique (micro-contrôleur, transistor, caméra...) et la partie électrique
(moteurs). L'estimation de l'autonomie du mobile air est de 2h. Deuxièmement,
le « module sol » a, lui aussi, besoin d'une alimentation pour réaliser toutes les
tâches requises. Celle-ci se présente sous la forme de quatre piles LR6 1,5V
pour chaque module sol (poste de commande et poste de réception).
Perturbations hertziennes (bruit, interférences, ...) : Le projet sera mené en
parallèle avec d'autres binômes utilisant les mêmes bandes de fréquences (433
MHz). Nous pouvons être sûr que les interférences avec les autres
Robin HAIDER
Alexandre MELY
Espion Dirigeable
Document de pré-conception
7
émetteurs/récepteurs vont être nombreuses. Voilà pourquoi nous avons choisi
de définir un code spécifique à notre projet pour réduire toutes perturbations
extérieures (cf. § communication hertzienne).
Contraintes liées au boîtier de commandes
Le rôle de ce module est d’envoyer un certain nombre de commande au ballon via
une communication Hertzienne, et de recevoir les données correspondant à
l’orientation relevée par la boussole électronique.
o
Contraintes de distance de couverture
Il va sans dire qu’un tel engin téléguidé doit pouvoir être commandé à
« distance ». Mais quelle distance ? L’analyse des besoins ne nous informe pas
d’une distante minimale requise. La portée de l’Espion Dirigeable sera donc
directement liée à la puissance et à la qualité des émetteurs/récepteurs mis à
notre disposition.
Une autre contrainte à prendre en compte concerne les interférences. Bien
que nos tests soient effectués dans les meilleurs conditions, il se peut que du
« bruit » vienne interférer dans la communication entre l’espion et le poste de
commandes. Ces interférences pourront être corrigées à l’aide d’outils logiciels
et matériels présentés dans le paragraphe correspondant. Sinon, la commande
correspondante sera reconnue comme erronée et ignorée.
Enfin, il faut savoir que l’Espion Dirigeable peut être concurrencé (peu
raisonnable…). L’espace des communications risque d’être surchargé et les
données reçues peuvent provenir d’une autre source que le boîtier de
commande rattaché. Notre produit doit donc être capable de reconnaître les
ordres qui lui sont destinés.
Contraintes liées à l’interface utilisateur
Cette interface est composée de 2 principaux modules : l’IHM proprement dite, et
le module de communication via une connexion parallèle.
o Le langage de programmation
Il est évident que le choix du langage dans un projet doit dépendre des
spécifications de ce projet. Le langage C est bien connu pour être assez proche
de la machine, il est donc relativement aisé d’accéder à la couche matérielle,
pour par exemple communiquer via le port série avec un périphérique externe.
Il requiert d’autre part des bibliothèques supplémentaires dès qu’il est question
d’affichage graphique. Java est l’une des solutions graphiques les plus
agréables à utiliser à ce jour. Cependant, il est très délicat (mais pas
impossible) d’accéder au hardware comme on le ferait simplement avec le C.
Le Java a donc été retenu pour l’interface graphique. Cette dernière utilise un
module externe, codé en C, afin de réaliser les opérations d’écriture sur le port
parallèle.
Robin HAIDER
Alexandre MELY
Espion Dirigeable
Document de pré-conception
8
II. Documents de Référence
Voici la liste exhaustive des documents que nous utiliserons et auxquels nous nous
référerons dans les livrables.
Documents relatif aux cours de Génie Logiciel (W. BOHER-COY) :
- Initialisation au Génie Logiciel : Analyse des besoins
- Initialisation au Génie Logiciel : Cycles de développement
- Initialisation au Génie Logiciel : Conception
- Formation/Action : Gestion de Projet (cours de 2ème année).
Documents liés directement au projet d’architecture :
- Liste des projets d’architecture des systèmes 2004-2005
- Projet architecture des systèmes : Dirigeable espion télécommandé (A Le Van Suu)
Manuel de référence des Microcontrôleurs :
- PIC 16F84
- BasicStamp (abandonné au profit du PIC)
Le circuit qui devait commander la commande du spy-bot nécessitait l'intégration de
micro-contrôleurs. Le choix de PICs 16F84 était adapté à nos besoins. Cependant, étant
novice en matière de programmation de PICs, nous avons du beaucoup nous documenter et
apprendre à nous servir du logiciel d'environnement de programmation de ces PICs : «
MPLAB IDE ».
Pour la manipulation du logiciel MPLAB IDE, nous avons eu recours à la
documentation associée et notre professeur nous a montré comment commencer à l'utiliser
rapidement.
Pour ce qui est de la programmation des pics, nous avons surtout suivis les méthodes
de Bigonoff.
Source : http://www.abcelectronique.com/bigonoff
Nous avons ensuite commencé par effectuer des petits tests pour mettre en pratique
quelques notions élémentaires. Nous avons effectué des petits programmes permettant d'écrire
ou de lire des données déposées dans différents registres ou encore d'allumer des LEDs selon
certaines conditions. Ceci nous a permis de nous familiariser avec la programmation des
PICs.
Robin HAIDER
Alexandre MELY
Espion Dirigeable
Document de pré-conception
9
III. Conception générale
3.1 Système d’exploitation utilisé
Comme énoncé dans l’analyse des besoins, le système d’exploitation utilisé pour faire
fonctionner l’interface utilisateur ne revêt pas une importance particulière. Cependant, il est
admis que les systèmes Windows offrent un accès simplifié aux composants matériels, et en
particulier au port série qui nous intéresse ici, par rapport aux systèmes Unix. Voilà pourquoi
nous porterons notre choix sur Windows afin de rendre la phase de programmation la moins
fastidieuse possible. Le module de communication avec le port parallèle ne fonctionne en
outre que sous Windows, ces opérations de bas niveau étant différentes selon le système
d’exploitation.
3.2 Langages utilisés
Nous sommes confrontés à deux choix majeurs dans le phase de conception de notre
projet :
En premier lieu vient le choix du langage de programmation qui sera utilisé pour
développer l’interface d’utilisation (IHM), qui permettra de piloter l’Espion
Dirigeable. Deux composantes sont à prendre en compte afin de faire le bon choix.
Tout d’abord l’aspect graphique. Il va sans dire que l’interface développée devra
être à la fois simple et fonctionnelle. Or le langage le plus abordable pour
développer ce type d’interface est le langage JAVA. Ensuite, l’aspect
communication a aussi son importance, car elle est partiellement gérée par
l’interface utilisateur. Notre programme devra donc pouvoir aisément accéder à la
couche matérielle de l’ordinateur. Pour ce, le langage C s’avère le plus approprié.
Cependant, le C s’avère assez délicat à utiliser lorsqu’il s’agit de manipuler des
interfaces graphiques, ceci est d’autant plus vrai sur une plate-forme Windows. Il
faut savoir que la couche matérielle est accessible en JAVA, mais moins
facilement qu’avec un langage de « bas niveau ». Nous avons donc décidé de nous
tourner vers le langage de « haut niveau » qu’est le JAVA tout en utilisant le
langage C pour la communication avec le port parallèle.
En second lieu, nous devons choisir non pas directement entre deux autres
langages de programmation, mais entre deux modèles de microcontrôleurs. Or
chacune de ces puces devra être programmée avec un langage qui lui est propre. Il
s’agit dans notre cas du BASIC et de l’Assembleur. Nous nous sommes tournés
vers le PIC 16F84 programmable en Assembleur. Bien que programmable
uniquement en langage d’assemblage, celui-ci s’avère plus simple à exploiter et
mieux adapter à nos besoins.
Robin HAIDER
Alexandre MELY
Espion Dirigeable
Document de pré-conception
10
3.3 Architecture générale et interfaces détaillées des modules
3.3.1 Architecture générale
Dans le cahier des charges, nous avons déjà effectué un découpage du système en 3
modules :
- Conception des circuits
- Programmation des micro-contrôleurs
- Programmation logicielle PC et tests
Version définitive de la structure générale du produit. La partie grisée représente la partie
fournie par le client. Trois relais seront greffés à la télécommande afin de permettre le
contrôle de l’Espion Dirigeable à partir de l’IHM présente sur le PC.
Nous allons tenter une approche différente du système, de façon à le décomposer d’un
point de vue fonctionnel. De cette manière, le fonctionnement interne de l’Espion Dirigeable
peut s’apparenter à :
Robin HAIDER
Alexandre MELY
Espion Dirigeable
Document de pré-conception
11
Décomposition fonctionnelle
Ballon
Poste de commande
PC
Micro-contrôleur
Micro-contrôleur
Interface IHM
Boussole
numérique
Moteurs et
servos
Module de communication
Hertzienne
Module de
communication série
Module de
communication série
Module de réception vidéo
Mini-caméra
Module de communication
Hertzienne
N.B. : Le module de communication s’est vu remplacé, à la suite de la modification apportée
par le client au cahier des charges, par un module de communication parallèle, plus adapté
aux besoins du client. Cette révision du cahier des charges a en outre clairement précisé
l’annulation du développement des modules « Boussole numérique » et « Caméra
motorisée ». Cette dernière s’est vue remplacée par un module de caméra externe, plus simple
à mettre en œuvre et possédant sa propre alimentation.
Robin HAIDER
Alexandre MELY
Espion Dirigeable
Document de pré-conception
12
Alimentation
Alimentations
« module
« module
solair» et
éteinte
sol » éteintes
Interrupteur fermé
Interrupteur ouvert
Alimentations « module air et sol » allumées
En attente de réception d'une commande
Pression bouton « monter » /
Relâchement bouton « monter » /
Envoie en continu les données de la
caméra et de la boussole
« module air » monte
Pression bouton «descend» /
Relâchement bouton «descend» /
« module air » descend
Pression bouton «rotation vers la droite» /
Relâchement bouton «rotation vers la droite» /
« module air » en rotation vers la droite
Pression bouton «rotation vers la gauche» /
Relâchement bouton «rotation vers la gauche» /
« module air » en rotation vers la gauche
Pression bouton «translation avant» /
Relâchement bouton «translation avant» /
« module air » en translation avant
« module air » en translation arrière
Pression bouton «translation arrière» /
Relâchement bouton «translation arrière» /
Transition en gras
Transition en italique
Robin HAIDER
Alexandre MELY
Diagramme d'états / transition du module « air »
Espion Dirigeable
Document de pré-conception
13
3.3.2 Interfaces détaillées des modules
Dans cette partie, nous allons détailler les modules un par un, selon une approche
ascendante ou BOTTOM-UP (Modules élémentaires agrégés pour former des modules de
niveau supérieur). Voici la liste des modules dans l’ordre hiérarchique :
(NB : PDC ↔ Poste De Commande)
Modules de niveau 4
o Module de communication Hertzienne
o Module de communication parallèle
Modules de niveau 3
o Mini caméra indépendante
o Moteurs
Modules de niveau 2
o Micro-contrôleur Poste de commande
o Micro-contrôleur Poste de réception
o Interface IHM
Modules de niveau 1
o Ballon
o Poste de commande
o Poste de réception
o PC
Afin de faciliter la lecture et l’accès aux différentes spécifications de chacun des
modules, ces derniers seront présentés page par page.
Robin HAIDER
Alexandre MELY
Espion Dirigeable
Document de pré-conception
14
Spy Screen : Interface Utilisateur
Présentation du module
IHM signifie Interface Homme Machine, il s’agit donc de permettre à un utilisateur de
communiquer avec un logiciel. Dans notre cas, il doit être en mesure de pouvoir aisément
« piloter » le ballon dirigeable via des commandes simples comme « avancer », « tourner à
gauche », etc.
Par conséquent, nous avons développé une petite interface simple avec 7 boutons
correspondant chacun à un mouvement ou à une fonctionnalité du Spy. Afin de faciliter son
développement et de proposer à l’utilisateur une interface conviviale, nous avons choisi de le
programmer en langage JAVA. L’avantage de cette solution et que cette plate-forme met à la
disposition du développeur un nombre important de fonction graphique très agréable à
utiliser. Par contre, ses principaux inconvénients sont que d’une part l’exécution d’un
programme JAVA nécessite une machine virtuelle pour fonctionner, d’autre part ces
programmes sont souvent lents. De plus, le langage JAVA ne nous permet pas d’accéder aux
couches matérielles de la machine. Il est donc pas envisageable de développer la partie
communication parallèle en JAVA.
Nous avons donc décidé de créer un programme en langage C++ qui permet de
modifier les sorties du port parallèle. Cependant, à l’inverse du langage JAVA, avec le
langage C++ il est beaucoup plus difficile de créer une interface pour l’utilisateur. Nous avons
donc combiné l’utilisation du langage JAVA et du langage C++ pour réaliser notre logiciel
Spy Screen.
Présentation de l’interface
La première version de notre interface permettait de contrôler les différents moteurs du
ballon de manière indépendante. Voici un aperçu de ce qu’était notre interface :
Robin HAIDER
Alexandre MELY
Espion Dirigeable
Document de pré-conception
15
Le ballon dirigeable est doté de trois moteurs munis d’hélice lui permettant de se
déplacer dans les airs. La zone rouge de l’IHM permet de contrôler le moteur de gauche, le
zone verte le moteur de droite, et la zone grise le moteur du dessous, qui permet de faire
monter ou descendre le Spy. Pour chacun des moteurs, nous pouvons indiquer si le moteur
doit fonctionner en tournant dans un sens ou dans un autre (ceci permet de tourner à droite au
de tourner à gauche, d’avancer ou de reculer, de monter ou de descendre).
Cette première interface a été développée dans le but de pouvoir tester les moteurs
indépendamment. L’inconvénient majeur est qu’il fallait, pour tourner à gauche par exemple,
activer deux moteurs en simultané (moteur bâbord en arrière et moteur tribord en avant). Ce
qui impliquait l’activation de deux boutons en même temps.
Nous avons donc créé une seconde interface :
Cette interface est plus orientée « utilisateur ». Elle permet simplement d’effectuer
directement les commandes :
- Avancer
- Reculer
- Tourner à gauche
- Tourner à droite
- Monter
- Descendre
Selon les commandes demandées, les moteurs entrant en jeu seront activés.
De plus, comme vous avez pu le remarquer, nous avons implémenter une
fonctionnalité des plus utiles, un klaxon, car l’espion doit être en mesure, dans le cas ou ses
activités seraient découverte, de dissuader son ennemi…
Robin HAIDER
Alexandre MELY
Espion Dirigeable
Document de pré-conception
16
Principe de fonctionnement
L’Interface Homme Machine possède un tableau de correspondance entre chaque
action et sa valeur correspondante en entier non signé. Afin de suivre le même protocole, c’est
ce même tableau de correspondance qui est utilisé dans le micro-contrôleur du module de
réception chargé d’interpréter les données reçues.
Lorsqu’un bouton est cliqué sur l’interface (en JAVA), une valeur est passée en
argument du programme « driver » du poste émetteur. Voici le tableau de correspondance des
boutons – valeur de la data envoyée :
Bouton
Aucun
Avance
Recule
Gauche
Droite
Haut
Bas
Klaxon
Valeur envoyée
0
1
2
3
4
5
6
7
Représentation binaire
000
001
010
011
100
101
110
111
La valeur est envoyée par le driver sur le port parallèle sur les connecteurs (pins) 2, 3
et 4. Nous reviendrons plus en détail sur ce point dans la description du fonctionnement du
module de communication parallèle.
Une fois la commande émise, ce sera le module d’émission qui prendra en charge
l’émission de la commande au module réception. Ce dernier pourra déclencher les moteurs
adéquats.
Robin HAIDER
Alexandre MELY
Espion Dirigeable
Document de pré-conception
17
Module de communication Hertzienne
Module(s) utilisé(s) :
o Aucun
Module(s) parallèle(s) :
o Module de communication Hertzienne
Cette partie du système est composée d’un émetteur/récepteur d’ondes Hertziennes.
Attention, il n’est pas à la charge de se module de décoder les commandes reçues ou de coder
les éléments à envoyer, son rôle se limite à envoyer et recevoir des données par les ondes
hertziennes. Contrairement au module de communication série, ce système est le même pour
le poste de commande et le poste de réception.
Commandes codées sur ondes Hertziennes
Module de communication Hertzienne
Commandes codées reçues
envoyées au micro-contrôleur
Commandes codées à emettre
Robin HAIDER
Alexandre MELY
Espion Dirigeable
Document de pré-conception
18
Module de communication parallèle
Module(s) utilisé(s) :
o Aucun
Module(s) parallèle(s) :
o Micro-contrôleur
Présentation générale du module
Ce module est situé entre l’Interface Homme Machine (IHM) et la liaison parallèle
entre le poste de commande (module émetteur) et l’Ordinateur. Il permet d’envoyer les
commandes émises par l’utilisateur au module émetteur qui se chargera que les retransmettre
au Ballon Dirigeable. Ces commandes sont saisie grâce à une interface qui propose des
boutons lui permettant de choisir quelles actions doit effectuer le Spy. Ce module n’est pas
censé connaître la signification des données qu’il transmet, il se charge seulement d’envoyer
les data reçus sur le port parallèle. Il s’agit en fait d’un petit programme indépendant appelé
par l’interface. Ce dernier peut être assimilé au concept de Driver. Il offre en effet une
interface logiciel, dite middleware, permettant d’accéder aux registres du port parallèle.
Dans un premier temps, ce module aurait du être directement codé avec l’interface. Or
l’IHM étant codé en Java, nous avons rencontré plusieurs difficulté quant à la mise en place
du système, car le langage Java ne permet pas d’accéder facilement au matériel de
l’ordinateur. Nous avons du recourir à la langage de plus bas niveau, nous avons donc choisi
le C pour développer ce module.
Fonctionnement du port Parallèle
Le port parallèle est une fiche DB25 à 25 connecteurs (ou pins), dont chacun a un nom
et un rôle précis, comme indiqué sur le schémas ci-dessous :
Robin HAIDER
Alexandre MELY
Espion Dirigeable
Document de pré-conception
19
La plupart de ces pins correspondent à un registre. On trouve 3 types de registres :
- Les registres d’état (Status Register)
- Les registres de données (Data Register)
- Les registres de contrôle (Control Register)
Voici listés dans un tableau le rôle de chacun de ces connecteurs :
Connecteur n°
Signal
1
nStrobe
2
Data 0
3
Data 1
4
Data 2
5
Data 3
6
Data 4
7
Data 5
8
Data 6
9
Data 7
10
nAck
11
Busy
12
Paper-Out PaperEnd
13
Select
14
nAuto-Linefeed
15
nError / nFault
16
nInitialize
nSelect-Printer
17
nSelect-In
18-25
Ground
Direction
In/Out
Out
Out
Out
Out
Out
Out
Out
Out
In
In
In
In
In/Out
In
In/Out
Type de registre Inversé
Control
Yes
Data
Data
Data
Data
Data
Data
Data
Data
Status
Status
Yes
Status
Status
Control
Yes
Status
Control
In/Out
Control
Yes
Gnd
Il faut garder à l’esprit que le port parallèle est principalement utilisé pour les
imprimantes. C’est pour cela que l’on retrouve des connecteurs exclusivement dédiés à ce
type de matériel (Busy, Out of Paper, …).
Les connecteurs 18 à 25 sont reliés à la masse de l’ordinateur. Au niveau du câble,
entre tous les fils, on trouve un conducteur de masse supplémentaire, que nous avons combiné
avec le connecteur de masse 18 pour fermer le circuit de circulation des données entre
l’ordinateur et le module Émetteur.
Robin HAIDER
Alexandre MELY
Espion Dirigeable
Document de pré-conception
20
Codage des commandes
-
Nous avons 7 commandes en tout à faire passer :
Avancer
Reculer
Tourner à gauche
Tourner à droite
Monter
Descendre
Klaxon !
Nous avons donc besoin de 3 fils pour coder les commandes du SpyBot (23 = 8) . Nous
disposons de 8 connecteurs Data, et nous n’en utiliserons que 3, ce qui nous laisse la
possibilité d’implémenter des fonctionnalités supplémentaires.
Interface du module
Nous avons tenté d’interfacer du C avec le langage Java pour intégrer directement le
module de communication parallèle dans le module d’Interface Homme Machine. Pour des
raisons logicielles, nous n’y sommes pas parvenus. Nous avons donc procédé comme suit : le
programme de liaison doit être appelé avec un argument, en mode console. Cet argument
correspond en fait à la donnée qui doit être envoyé sur le port parallèle, en décimal.
Exemple d’utilisation :
Pour écrire l’entier 3 sur le port parallèle (commande tourner à gauche), l’IHM
programmé en JAVA fera appel à une commande système pour lancer le programme de
communication parallèle :
$> write_LPT 3
Entrées :
Une variable décimale prise en argument de l’appel du programme
Robin HAIDER
Alexandre MELY
Espion Dirigeable
Document de pré-conception
21
Sorties :
Cette variable est écrite sur le port parallèle sur les pins D0, D1 et D2 numérotés
respectivement 2, 3 et 4. D0 correspond au bit de poids le plus faible.
Notre module est compilé sur Windows et sera donc utilisable sur les plates-formes
Windows à partir sa la version NT 4. Il est très probable que l’utilisateur, friand des
technologies nouvelles soit équipé au goût du jour en matière d’informatique. Il y a donc fort
à parier qu’il possède une version de Windows au moins supérieure à NT. Or sur les
nouvelles versions de Windows, le port parallèle n’est plus accessible en écriture pour le
développeur, car il n’a pas les droits nécessaire (noyau) pour y écrire des données. Nous
avons donc besoins d’une bibliothèque DLL (Dynamic Link Library) : « inpout32.dll ». Ce
fichier n’étant pas forcément présent sur l’ordinateur du client, il sera systématiquement livré
avec le programme.
Cette bibliothèque propose deux fonctions qui nous intéresse : « Inp32 » et « Out32 »,
que nous avons chargé dans le code source, puis utiliser pour accéder au port parallèle.
Notre programme n’est censé qu’écrire sur le port parallèle, mais nous avons aussi pris
le soin d’implémenter une fonction permettant de lire sur ce port, en vue d’éventuels ajouts de
fonctionnalités ultérieurs au projet.
Robin HAIDER
Alexandre MELY
Espion Dirigeable
Document de pré-conception
22
Module de réception vidéo
Module(s) utilisé :
o Aucun
Module(s) parallèle(s) :
o Mini caméra
La mini caméra dont sera dotée notre Espion Dirigeable produira un flux vidéo qui
pourra être visualisable parallèlement à l’interface utilisateur à l’aide d’un visualiseur de flux
vidéo. Il faut se demander si le débit des différents canaux de communication seront à même
de transporter l’intégralité des données en temps réel. Pour se donner une idée :
Type de liaison
Liaison série (RS232)
Liaison Hertzienne utilisée par le ballon
Flux vidéo de la mini-caméra
Fréquence
De l’ordre du K-Hertz
433-868 M-Hertz
1 G-Hertz
On voit bien ici que la liaison série serait un « goulot d’étranglement » pour le flux
vidéo et qu’il n’y aurait donc pas assez de débit disponible pour faire transiter la donnée du
flux vidéo. Il faudra donc utiliser un autre protocole de communication.
La mini-caméra que nous utiliserons est livrée en standard avec un émetteur et une
antenne à brancher sur une carte d’acquisition vidéo (intégrée au PC) via l’entrée coaxiale.
Nous ne nous occuperons donc pas de l’encodage/décodage du flux vidéo. Par conséquent, le
module de réception vidéo s’apparentera à :
Module de réception vidéo
Récepteur vidéo
Données reçues à décoder
Carte d'acquisition vidéo
Flux vidéo à afficher
Interface IHM
Robin HAIDER
Alexandre MELY
Espion Dirigeable
Document de pré-conception
23
Mini-caméra
Module(s) utilisé(s) :
o Micro-contrôleur
Module(s) parallèle(s) :
o Aucun
Ce dispositif permet à l’utilisateur de visualiser l’environnement de l’Espion
Dirigeable afin de lui envoyer des commandes de déplacement en conséquence. C’est en
quelque sorte l’appareil oculaire du ballon. Ce module est connecté à un module d’émission
radioFréquence, fournit avec la mini-caméra. Voici un aperçu de son fonctionnement :
Mini-caméra orientable
Micro-contrôleur
Commandes de rotation de la passerelle
M
Servos pour orienter la mini-caméra
Emetteur radioFréquence
Mini-caméra
Flux vidéo à transmettre
Représentation schématique du module de la caméra dans le cas où des servos
pourraient être utilisés afin de la rendre mobile.
Robin HAIDER
Alexandre MELY
Espion Dirigeable
Document de pré-conception
24
Moteurs
Module(s) utilisé(s) :
o Micro-contrôleur
Module(s) parallèle(s) :
o Aucun
Un espion immobile ne serait pas très efficace, il faut pouvoir être en mesure de
contrôler son déplacement. C’est pourquoi le ballon dirigeable sera muni de mini moteurs
dotés d’hélices à double sens de fonctionnement. Cette option est particulièrement
intéressante dans la mesure où elle permettra à l’Espion Dirigeable de se déplacer en arrière,
et d’effectuer des rotations stationnaires. Ces moteurs sont alimentés en intensité directement
par le micro-contrôleur. C’est donc l’ampérage du circuit qui déterminera un fonctionnement
du moteur plus ou moins intense, et par conséquent un déplacement du ballon plus ou moins
rapide. Voici une représentation schématique du dispositif :
Moteurs à hélice
Micro-contrôleur
Moteur hélice gauche
M
M
M
Robin HAIDER
Alexandre MELY
Moteur hélice droite
Moteur hélice inférieure
Espion Dirigeable
Document de pré-conception
25
Programmation des PICs
Après avoir effectué plusieurs tests d'apprentissages des instructions
associées aux PICs, nous avons commencé à mettre en place un
système pour coder les différentes commandes à émettre et à
implémenter au fur et à mesure les trois fonctionnalités qui
correspondent respectivement à la gestion d'interruptions, à la gestion
de délai d'émission et de réception, au module émission et au module
réception.
Codages des commandes
Pour contrôler notre Spy-Bot, nous avions besoin de six commandes :
Avance
Recule
Rotation horizontale vers la gauche (Gauche)
Rotation horizontale vers la droite (Droite)
Translation verticale vers le haut (Haut)
Translation verticale vers le bas (Bas)
Pour coder ces différentes commandes, nous avons décidé d'associer à
chacune un numéro que nous avons codé en binaire. Soit le tableau
récapitulatif suivant:
Commande
Numéro de commande
Codage binaire
Avance
1
001
Recule
2
010
Gauche
3
011
Droite
4
100
Haut
5
101
Bas
6
110
Klaxon
7
111
Nous avons ajouté une septième commande qui permet de déclencher
un buzeur pour faire peur à l'ennemi...
Les interruptions : communication entre modules
Robin HAIDER
Alexandre MELY
Espion Dirigeable
Document de pré-conception
26
Lorsque certaines actions sont effectuées comme l'émission de
commande ou la réception par exemple, les PICs doivent pouvoir
réagir en conséquence. Nous avons donc besoin de générer une
interruption spécifique pour chaque type d'action.
Nous gérons les interruptions dans trois cas :
Robin HAIDER
Alexandre MELY
Espion Dirigeable
Document de pré-conception
27
Port parallèle – module émission :
Le module d'émission procède a une boucle infinie de lecture des
pattes RB5, RB6, RB7 du PIC. À chaque interruptions du timer (cf.
Détails du fonctionnement de l'interruption Timer). Un traitant de
gestion des commandes est appelé pour interpréter les commandes et
les envoyer. Le module émets un certain nombre d'impulsion
correspondant au numéro de la commande multiplié par 4 afin de
gérer des erreurs éventuelles de transmission. Les signaux électriques
sont envoyés à l'émetteur via la patte RA3 du PIC. Voici un tableau
qui récapitule le numéro de la commande, la commande associée et le
nombre d'impulsions émises (notons que la commande 0 correspond à
l'absence d'action associée).
Des interruptions sont générées par l'arrivée d'une commande
provenant du port parallèle de l'ordinateur sur le module émission.
Nous avons choisi de recevoir les sept commandes codées sur trois
bits sur les pattes RB5, RB6, RB7 du PIC (émission). À chaque
Lorsqu'une commande arrive sur ces pattes, le traitant d'interruption
spécifique est lancé et il faut traiter cette commande avant de pouvoir
en traiter une nouvelle. Celui ci déclenche une interruption « timer »
qui va initialiser un délai pendant lequel des impulsions vont être
émises. Après l'analyse de la commande, on va émettre un certain
nombre d'impulsion correspondant au numéro de la commande
multiplié par 4 afin de gérer des erreurs éventuelles de transmission.
Voici un tableau qui récapitule le numéro de la commande, la
commande associée et le nombre d'impulsion émises :
Numéro de commande
Robin HAIDER
Alexandre MELY
Commande
Nombre d'impulsion
1
Avance
4
2
Recule
8
3
Gauche
12
4
Droite
16
5
Haut
20
6
Bas
24
7
Klaxon
28
Espion Dirigeable
Document de pré-conception
28
Une fois que le nombre d'impulsions désiré est émis, le traitant
d'interruption est prêt à traiter une nouvelle commande.
Module émission / module réception (INT RB0) :
Les interruptions sont générées par l'arrivée d'une impulsion sur la
patte RB0 du PIC appartenant au module réception en provenance du
PIC appartenant au module émission. Dès qu'une impulsion est reçue,
le traitant d'interruption spécifique initialise un délai pendant lequel il
va compter le nombre d'impulsions qu'il reçoit. Une fois ce délai
écoulé, on peut déterminer le numéro de la commande si le taux
d'erreur de transmission ne dépasse pas 4 impulsions supplémentaires.
Voici un tableau qui indique entre quelles bornes d'impulsions sont
déterminées les commandes.
Robin HAIDER
Alexandre MELY
Espion Dirigeable
Document de pré-conception
29
Nombres d'impulsions
Numéro de commande
4à7
1
8 à 11
2
12 à 15
3
16 à 19
4
20 à 13
5
24 à 27
6
28 à 31
7
Une fois la commande détectée, les pattes permettant de contrôler en
sortie les moteurs du ballon sont activées. Voici un tableau
récapitulatif des pattes activées selon les commandes :
Moteur bâbord
Moteur tribord
Moteur Altitude
Commande
RB1
RB3
RB5
1
1
RB2
1
3
1
1
RB6
RB7
1
2
4
RB4
Buzeur
1
1
1
5
1
6
1
7
1
Détails du fonctionnement de l'interruption Timer (délai) :
Nous avons convenu que l'émission et la réception de données se
passeraient pendant un délai. Comme nous avons sept commandes
différentes, nous avons fixé ce délai à 40. C'est à dire que nous avons
40 coups de timers pour envoyer nos impulsions. Cela nous laisse une
marge pour l'ajout éventuel d'autre commande où d'éventuelles erreurs
liées au temps passé à traiter des instructions.
À chaque début d'émission ou de réception, un délai de 40 timers est
initialisé. A chaque coup de timer, une impulsion peut être émise. Une
fois que toutes les impulsions correspondant à une commande ont été
émises, le délai continu de s'écouler et s'arrête lorsque les 40 coups de
timers sont passés. Les coups de timers sont déclenchés tout les 32
Robin HAIDER
Alexandre MELY
Espion Dirigeable
Document de pré-conception
30
micro-secondes, soit un délai de 1280 micro-secondes pour émettre ou
recevoir une commande.
Lorsque aucune commande n'a besoin d'être traité, le compteur qui
initialise le délai est à nulle et les interruptions générées par le timer
ne font rien.
Robin HAIDER
Alexandre MELY
Espion Dirigeable
Document de pré-conception
31
Module émission
Ce module doit recevoir des commandes envoyées depuis le port
parallèle sur les pattes du PIC (émission) RB5, RB6 et RB7. Voici un
tableau résumant l'interprétation des commandes :
RB7
RB6
RB5
Numéro de commande
0
0
1
1
0
1
0
2
0
1
1
3
1
0
0
4
1
0
1
5
1
1
0
6
Les commandes sont gérées les unes après les autres au fur et à
mesure qu'elles sont reçues. Lorsque les pattes RB5, RB6, RB7 sont à
zéro, rien ne se passe. Si au moins une de ces pattes est à 1 (logique),
alors l'arrivée d'une commande est détectée. On appelle alors un
traitant d'interruption dont nous expliquerons le fonctionnement plus
loin.
Le principe de ce module consiste à envoyer pour une commande
i, i 4 pulsions pendant un délai de 40 timers (cf. Détails du
fonctionnement de l'interruption Timer).
Ci-dessous un schéma explicatif :
Robin HAIDER
Alexandre MELY
Espion Dirigeable
Document de pré-conception
32
Envoie d'une
com m ande sur
le port parallèle
Lect ure sur
les bit s
RB5, RB6, RB7
Int errupt ion Tim er
Analyse de la
com m ande
Envoie du
signal élect ique
à l'ém et t eur
Robin HAIDER
Alexandre MELY
Act ivat ion du
délai
Espion Dirigeable
Document de pré-conception
33
Module réception
Ce module permet de réceptionner des commandes et d'activer en
conséquence les moteurs associés. Lorsqu'une impulsion est détectée
sur la patte RB0 du PIC (réception), un traitant d'interruption
spécifique est appelé. Son principe est de déclencher un délai et de
compter le nombre d'impulsion reçue jusqu'à la fin du délai. En
fonction du nombre d'impulsions comptabilisés, il est possible de
retrouver la commande associée (cf. les interruptions).
Après réception de la commande, les moteurs du Spy-Bot sont
directement actionnés et permettent de le déplacer.
Problèmes rencontrés et solutions apportés
Changement de banques
Les banques dans le PIC 16F84 correspondent à des modes différents
de paramétrages des ports (A et B). Pour configurer certaines pattes
du PIC en entrées et d'autres en sorties il faut absolument passer en
banque 1 (positionnement du bit RP0 du registre STATUS à 1) pour
ensuite modifier les registres TRISA et TRISB comprenant le masque
d'entrée/sortie (1 pour entrée et 0 pour sortie). En fonctionnement
normal, il faut repasser en banque 0. Lorsque nous avons commencé à
utiliser et programmer le PIC, nous n'avons pas pensé directement à
passer en banque 0 pour paramétrer les ports.
Registre d'option (OPTIONREG)
Ce registre permet de paramétrer le fonctionnement du PIC (vitesse du
timer, gestion des interruptions, ...). Par défaut beaucoup d'options
sont désactivés dans le fonctionnement du PIC (par exemple gestion
du l'interruption RB0 ou TIMER). Il nous a fallu localiser le
problèmes et trouver les bonnes options pour utiliser correctement le
micro-contrôleur.
Modification des bits de configuration
L'environnement de développement MPLAB IDE offre avant la
programmation du PIC un paramétrage de certains bits du microcontrôlleur (type d'horloge, ...). Il nous a aussi fallu faire attention à la
configuration de ce bits pour bien spécifier le matériel environnant le
PIC.
Robin HAIDER
Alexandre MELY
Espion Dirigeable
Document de pré-conception
34
Niveau électrique des pattes d'entrées
Toutes les pattes du PIC configurées comme entrantes sont
positionnées à l'état 1 (logique) tant que l'on agit pas dessus
(connexion à la masse par exemple). Dans le cas de l'interruption
RB0, nous pensions qu'il fallait injecter du courant (+5V) sur la patte
pour provoquer un front montant. Or il fallait fait l'inverse c'est-à-dire
connecter la patte RB0 à la masse.
Robin HAIDER
Alexandre MELY
Espion Dirigeable
Document de pré-conception
35
Les interférences
Lorsque nous avons voulu tester nos différents modules, il était
difficile de savoir si les commandes étaient correctement envoyées car
il y avait beaucoup d'interférences qui faussaient nos signaux. Nous
avions remarqué que d'autre élèves émettaient en même temps. Après
quelques arrangements, nous avons remarqué que nous n'avions que
trois erreurs d'impulsions au maximum. Nous avons donc convenu
d'un code correcteur valable pour quatre erreurs éventuelles. Ce code
consiste à envoyer quatre fois plus d'impulsions que le numéro de la
commande demandée. Ainsi chaque commande est séparée de 4
impulsions et il est donc possible de récupérer la commande malgré
quelques petites interférences.
Nécessité d'un comparateur
Afin de limiter le nombre de pulsion erronée, nous avons intégré dans
notre circuit un comparateur (amplificateur opérationnel). Il ne laisse
passer que les impulsions supérieures à 2,5 volt. Nous obtenons ainsi
un signal plus propre (créneaux carrés).
Visualisation des commandes émises et reçues
Afin de visualiser, des LEDs qui nous permettaient de comptabiliser le
nombre de pulsions émises/reçues, nous avions augmenter le nombre
de micro-secondes entres chaque coup de timer. Cependant, avec cette
méthode nous avions plus de temps pour capturer des impulsions
parasites et faussait notre signal. Après avoir calculer un comparateur
permettant de filtrer les signaux, nous obtenions déjà un signal correct
dans le cas où d'autres élèves n'emmétaient pas en même temps.
Lorsque nous sommes passer en mode opérationnel, nous avons
diminué ce temps entre chaque impulsion. De cette manière, nous
avions encore moins de chance de capturer des pulsions parasites.
Robin HAIDER
Alexandre MELY
Espion Dirigeable
Document de pré-conception
36
Synthèse du module Ballon
A présent, maintenant que nous avons détaillé chacune des interfaces des sousmodules, nous pouvons construire le schéma fonctionnel du module Ballon dirigeable. Cette
représentation n’est pas à voir comme un circuit électrique, il s’agit simplement d’un schéma
explicatif permettant de comprendre comment les différents modules s’imbriquent et
s’utilisent les uns avec les autres.
Commandes codées sur ondes Hertziennes
Module de communication Hertzienne
Commandes codées à emettre
Commandes codées reçues
envoyées au micro-contrôleur
Micro-contrôleur
Commandes de rotation de la passerelle
Donnée orientation
M
Capteur d'orientation
M
Moteurs à hélice
Emetteur radioFréquence
Servos pour orienter la mini-caméra
Mini-caméra
Flux vidéo à transmettre
Il est à noter que ce schéma ne prend pas en compte la mise à jour du cahier des
charges demandée par le client. Celle-ci propose la suppression des servos de la mini caméra
ainsi que du capteur d’orientation.
Robin HAIDER
Alexandre MELY
Espion Dirigeable
Document de pré-conception
37
Synthèse du module Poste de commande
Le poste de commande n’a pas un rôle véritablement actif dans le fonctionnement du
système puisqu’il se contente de faire transiter les données (commandes + données
d’orientation) entre l’ordinateur sur lequel est lancé l’interface de pilotage, et le poste de
réception. Son interface générale est simple :
Dans le sens PC → poste de réception :
o Entrée : Commandes de direction codées sur liaison parallèle
o Sortie : Commandes de direction codées sur ondes Hertziennes
Dans le sens Ballon → PC :
o null
Commandes codées sur ondes Hertziennes
Module de communication Hertzienne
Commandes codées à emettre
Commandes codées reçues
envoyées au micro-contrôleur
Micro-contrôleur
Commandes codées reçues
envoyées au micro-contrôleur
Commandes codées à emettre
Module de communication Série
Robin HAIDER
Alexandre MELY
Espion Dirigeable
Document de pré-conception
38
Synthèse du module PC
Enfin, l’interface PC permettra à l’utilisateur de contrôler de manière simple et précise
l’Espion Dirigeable grâce à une interface sobre et fonctionnelle. Lors de l’analyse des
modules sous-jacents, nous avons pu déterminé la configuration matérielle minimale requise
afin de pouvoir faire fonctionner l’Espion Dirigeable correctement. Voici une liste nonexhaustive des éléments indispensables pour l’utilisation du produit :
Système d’exploitation Windows NT 4 ou supérieur
Port parallèle
Carte d’acquisition vidéo avec entrée Coaxiale (antenne de réception)
D’autres spécifications seront requises comme la mémoire, une espace disque suffisant
pour l’installation et l’utilisation du programme, un écran, un clavier, une souris, etc.
Câble Série
Données reçues à décoder
Interface IHM
Données à interpréter
Commandes codées à emettre
Commandes à coder
Module codeur/décodeur
Carte d'acquisition vidéo
Données reçues à décoder
Récepteur vidéo
Flux vidéo à afficher
Clavier
Robin HAIDER
Alexandre MELY
Espion Dirigeable
Document de pré-conception
Souris
39
Présentation des circuits électroniques
La présentation des différents modules nous permet maintenant de présenter les
circuits électroniques implémentant les fonctionnalités en question. Les deux circuits réalisés
correspondent au poste de commande et au poste de réception. Un troisième circuit, fourni par
le client, permet de faire le lien entre le poste de réception et la télécommande contrôlant le
ballon dirigeable.
Circuit du poste de commande
Robin HAIDER
Alexandre MELY
Espion Dirigeable
Document de pré-conception
Circuit du poste de réception
40
IV. Spécifications techniques de l’Espion Dirigeable
Voici le tableau regroupant les principales spécifications techniques du produit :
Elément
Vitesse
Autonomie
Temps de réponse
Distance de transmission maximale
Robin HAIDER
Alexandre MELY
Détail technique
Liée à la poussée due à la vitesse de rotation
des hélices du Ballon.
Piles de 9 volts + 4x1.5 Volts (rechargeables)
300 milli-secondes plus 1 seconde de marge
20 mètres dans un espace ouvert et sans
perturbations.
Espion Dirigeable
Document de pré-conception
41