Contrôle de sonar, 2012/2013, TD2 : Différence entre versions

Version du 13 juin 2013 à 12:34 (voir la source) Nmartin1 (discussion | contributions) (→‎Mode d'emploi) ← Modification précédente		Version du 13 juin 2013 à 12:36 (voir la source) Nmartin1 (discussion | contributions) (→‎Mode d'emploi) Modification suivante →
Ligne 215 :		Ligne 215 :
	----		----
−	Système non-embarqué:	+	'''Sur Système non-embarqué'''
	On effectue, dans l'ordre, les manipulations suivantes afin de compiler et exécuter le projet final:		On effectue, dans l'ordre, les manipulations suivantes afin de compiler et exécuter le projet final:
Ligne 253 :		Ligne 253 :
−	Utilisation de la Foxboard:	+	'''Sur la Foxboard:'''
	On effectue, dans l'ordre, les manipulations suivantes afin de compiler et exécuter le projet final:		On effectue, dans l'ordre, les manipulations suivantes afin de compiler et exécuter le projet final:
Ligne 262 :		Ligne 262 :
	3 - Se connecter à la Foxboard en tapant root@172.26.79.7 suivi du mot de passe correspondant		3 - Se connecter à la Foxboard en tapant root@172.26.79.7 suivi du mot de passe correspondant
−		+
	4 - Compiler et exécuter le programme d'ouverture du port série		4 - Compiler et exécuter le programme d'ouverture du port série

---

Version du 13 juin 2013 à 12:36

Evaluation informatique et électronique

Gestion de projet / rédaction Wiki

• Informatique :
• Electronique :

Note .

Test fonctionnels

• Sous-système.
  • Sous-système informatique :
  • Sous-système électronique :

Qualité de la réalisation

• Informatique : Note .
  • procédure de test :
  • pages HTML et Javascript :
  • scripts PHP ou programmes C :
  • installation sur FoxBoard :
• Electronique : Note .
  • qualité de la réalisation :
  • tests autonomes :

Bilan

Note finale :

Rapports des élèves

DEMANDE DE RAJOUTER LE PACKAGE MATH POUR FORMULES LATEX S'IL VOUS PLAÎT

Projet SC – Système de contrôle sonar

Pose de la problématique

Voici l'énoncé du sujet :

« Le projet consiste à réaliser un sous-système de contrôle de sonar ultra-sons. L'interface Web associée permettra à l'utilisateur de faire tourner le sonar suivant un angle précis et d'afficher la mesure de distance correspondant à la direction choisie. »

Ainsi, le projet se décompose en deux sous-parties :

• La réalisation informatique

A laquelle Nathan MARTIN et Charlotte BRICOUT furent affectés et qui consiste en la réalisation d’une interface web permettant la gestion des servo-moteurs faisant tourner le sonar selon un angle précis et l’affichage de la distance retournée.

• La réalisation électronique

Sylvain FOSSAERT et Soufiane HADDAOUI s’occuperont quant à eux de la réalisation du sonar proprement dite via la puce FPGA intégré de la NanoBoard et d’un circuit analogique permettant l’adaptation des signaux d’émission et de réception.

Partie Informatique

Séance 1

---

Objectifs:

1) Commander en position le servomoteur

2) Récupérer la valeur du sonar du banc de simulation

Banc d'essai comprenant le servomoteur avec, fixé dessus, le sonar:

1) Asservissement du servomoteur du banc de simulation

Dans un premier temps, nous avons étudié le fichier AdvancedServo-simple.c de la librairie libphidget21 permettant de contrôler la position du moteur. Ensuite, nous avons crée un fichier commande_servo.c reprenant le code de AdvancedServo-simple.c. Nous l'avons adapté pour prendre en paramètre un angle compris entre 30 et 210 et asservir en position le servomoteur du banc de simulation.

Afin de tester ce programme sur le banc de simulation, on s'occupe tout d'abord de la configuration du port série entre notre machine ZABETH07 et le banc de simulation. On éxécute les deux fichiers serial_config.c et serial.c (situés à la racine 'root') ensemble:

gcc serial.c serial_config.c -o serial_config

On veut que l’exécutable serial_config soit exécuté en tâche de fond ce qui va permettre de laisser le port série ouvert et de pouvoir lire les valeurs du sonar en permanence. On configure ensuite le banc de simulation en sélectionnant le mode 5. On compile ensuite notre fichier commande_servo.c:

gcc commande_servo.c -o servo -lphidget21

( -lphidget21 permet d'inclure la librairie phidget21 )

2) Récupération de la valeur du sonar

On s'occupe maintenant de rédiger un script en PHP nommé script.php permettant de récuperer la valeur mesurée par le sonar du banc de simulation. Ce script utilise la liaison série qui reste ouverte pour lire les valeurs dans le terminal à chaque éxécution du script: PHP script.php. Dans ce script, on lit le port série et on stocke la valeur récupérée dans la variable ord($byte[0]) ($byte est un pointeur sur la valeur mesurée) qui est affichée ensuite. Dans le cas ou $byte = NULL alors le programme boucle jusqu'à ce que la prochaine valeur du sonar soit disponible. Cela permet de lire les valeurs "fraiches".

Les deux objectifs ont été atteints avec succès. Cependant, nous constatons quelques contraintes:

1) Le servomoteur tourne au maximum de 180 degrés.

2) On doit convertir l'angle de consigne car le servomoteur est configuré pour des angles entre 30 et 210.

0° <-> 30

180° <-> 210

Séance 2

---

Objectifs :

1) Rédiger un fichier index.hmtl qui code notre interface WEB 2.0 visible sur localhost pour le moment.

2) Adapter notre fichier commande_servo.c afin qu'il prenne en paramètre la valeur récupérée par un script CGI-BIN commande_servomoteur.cgi via l'interface WEB.

1) Rédaction du fichier HTML pour l'interface de saisie

Dans un fichier index.html situé dans /var/www, on implémente un champs de saisie sous la forme d'une barre et l'angle entré par l'utilisateur est envoyé vers commande_servomoteur.cgi grâce à l'appui sur un bouton validé. Afin de relier l'interface WEB avec le script lecture.php et le fichier commande_servomoteur.cgi, on réalise deux fonctions :

- recuperation( ) : qui permet de récupérer la valeur du sonar grâce à l'inclusion du script lecture.php et affiche la valeur de la distance sur l'interface Web.

- commande_servo( ) : qui permet de récupérer l'angle saisi dans le champs de l'interface et exécute le fichier commande_servomoteur.cgi. Si l'éxécution est réussie, on fait appel à la fonction recuperation( ) afin de lire et d'afficher la distance mesurée par le sonar.

2) Réalisation du script CGI-BIN

On modifie notre fichier commande_servo.c afin qu'il récupère, grâce à un fichier .cgi, la valeur de l'angle entré par l'utilisateur via l'interface Web. Pour ce faire, on installera auparavant la librairie cgi.h. On génère un fichier commande_servomoteur.cgi placé dans le répertoire /usr/lib/cgi-bin. Cela nous permet alors d'effectuer la rotation du servomoteur en fonction de l'angle qu'a rentré l'utilisateur dans le champs de saisie et récupérer la valeur du sonar grâce au script lecture.php. Une fois la valeur du sonar récupérée, on l'envoie sur l'interface de saisie grâce à l'inclusion de lecture.php dans la fonction recuperation( ) de index.hmtl. On récupère ainsi la valeur du sonar en fonction de l'angle du servomoteur.

Séance 3

---

Objectifs:

1) Réalisation du projet embarqué sur la Foxboard

2) Assembler la partie électronique et informatique du projet

1) Réalisation du projet embarqué sur la Foxboard

Au début de la séance 3, notre système fonctionnait sur les ordinateurs fixes, présents en salle. Nous pouvions dès lors commander par le biais de l'interface web, la position du sonar ainsi que récupérer la distance perçue par celui par rapport à l'obstacle face à lui. L'enjeu était alors d'embarquer le système. Pour cela, une Foxboard nous était fournie, cette dernière jouerait le rôle de l'unité centrale de l'ordinateur. Ainsi le système composé du banc d'essai avec le sonar et de la foxboard pourrait se transporter et s'utiliser n'importe où.

Les étapes :

1) Paramétrage

Tout d'abord, il a fallu configurer la Foxboard. Pour cela, nous nous y sommes connectés en série avec d'y rentrer quelques informations utiles comme, par exemple, son adresse IP. Comme nous avons à faire à un système embarqué, le système d'exploitation de la Foxboard ne contient que le minimum requis. Nous avons donc dû rentrer ces informations à l'aide du logiciel minicom.

2) Accès et installation

Une fois le paramétrage réalisé, nous nous sommes connectés en SSH à la Foxboard en tapant root@172.26.79.7 suivi de son mot de passe. Nous pouvions donc y avoir accès grâce au terminal d'un des PC de la salle. Ce qui nous a permis de faire l'installation des librairies et logiciels nécessaires afin de compiler nos programmes. Cette étape a demandé un temps important puisqu'un système embarqué comme celui ci est plus lent qu'un ordinateur fixe. Une fois les installations et la copie des fichiers de l'ordinateur à la Foxboard (dans les mêmes répertoires) terminés, nous avons compilé.

3) Tests

Vint ensuite la phase de tests. Nous avons effecté la même procédure que précédemment (Voir mode d'emploi). Dans un premier temps, nous ne recevions que la valeur du capteur à ultrasons du sonar mais le sonar restait immobile. Après réinstallation de certains logiciels mal installés, nous avons pu faire fonctionner le système complètement, en accédant à la page web d'adresse 172.26.79.7. Par conséquent, nous dialoguons et envoyons des consignes au sonar à distance.

2) Assembler la partie électronique et informatique du projet

Cette partie du projet n'a pu être mené à bien.

Mode d'emploi

---

Sur Système non-embarqué

On effectue, dans l'ordre, les manipulations suivantes afin de compiler et exécuter le projet final:

1 - A la racine: on écrase l’exécutable serial_config précédent s'il existe

killall serial_config

2 - A la racine: on compile le programme d'ouverture du Port Série

gcc serial.c serial_config.c -o serial_config ./serial_config

3 - Sur le banc de simulation: on sélectionne le mode 5

4 - A la racine : on exécute le script PHP

PHP script.php

( Facultatif mais permet cependant de vérifier que les distances envoyées sur le serveur sont égales à celles lues par le script PHP )

5 - Dans /var/www : on compile le programme de commande du servomoteur

gcc commande_servo.c -o commande_servomoteur.cgi -lcgi - lphidget21 chmod u+s /usr/lib/cgi-bin/commande_servomoteur.cgi

La ligne de commande "chmod u+s [...]" permet d'autoriser l’exécution de notre script CGI-BIN.

6 - Pour utiliser le programme, on se place dans l'interface et on saisie un angle en degrés entre 30 et 210 dans le champs prévu à cet effet. La mesure renvoyée est la valeur mesurée par le sonar en centimètres.

Sur la Foxboard:

On effectue, dans l'ordre, les manipulations suivantes afin de compiler et exécuter le projet final:

       1 - Brancher la Foxboard afin qu'elle soit alimentée en courant

       2 - La brancher au banc d'essai

       3 - Se connecter à la Foxboard en tapant root@172.26.79.7 suivi du mot de passe correspondant

       4 - Compiler et exécuter le programme d'ouverture du port série

       5 - Ouvrir la page d'adresse 172.26.79.7

       6 - Le système est prêt à être utiliser par le biais de la page web

Les deux objectifs ont été atteints avec succès. Des améliorations de l'interface de saisie sont possibles :

1) Afficher la valeur retournée de la distance sur un schéma ou sur une réglette

2) Remplacer le champs de saisi par une réglette permettant d'envoyer la valeur de l'angle souhaité

Partie Electronique

Prise de connaissance du problème

Nous allons dans cette partie, établir notre raisonnement et montrer le résultat obtenu lors de la réalisation du système de mesure de distance via la puce FPGA et d’un circuit d’adaptation de signaux.

Le module a pour but de mesurer la distance entre la carte et un obstacle. La mesure de distance se base sur la mesure du temps de parcours d'une onde ultrasonore émise puis reçue, après réflexion sur un obstacle.

Ce sous-projet est composé de deux parties :

Une partie implantée dans la carte FPGA de la NanoBoard et une partie analogique réalisée sur une plaque d'essais.

Réalisation de la partie FPGA

La Nanoboard est commandable directement à partir d’un PC contenant le logiciel Altium. Ainsi, en réalisant un montage FPGA sous Altium, celui-ci sera implémenter en VHDL après compilation et il sera alors possible de tester son bon fonctionnement.

Prise en main d’un projet FPGA sous Altium

Afin de comprendre le principe de réalisation sous Altium, nous suivîmes en premier lieu la réalisation effectuée dans l’aide donnée sous forme de PDF. Celle-ci nous a aidé sur la démarche à effectuer mais celle-ci nous a également permis de découvrir des « blocs » que nous pourrons réutiliser par la suite tel que les compteurs par exemple.

Une fois cette initiation réalisée et testée, nous avons commencé à discuter des solutions envisageables afin de répondre au cahier des charges : « La partie implantée dans le FPGA a pour fonction de générer un signal carré à la fréquence de résonance de l'émetteur d'ultrason afin de permettre l'émission du signal. Le début d'émission fera démarrer un compteur (12 bits), qui sera arrêté lors de la réception du signal ultrason sur le récepteur. Ainsi la valeur du compteur correspond à une représentation de la distance parcourue par l’onde ultrasonore. L’écriture de la valeur du compteur en mémoire sera permise grâce à un bit de permission d’écriture. »

Création de la partie émission

Création de l’horloge de résonance

Nous allons créer à partir de la puce FPGA une horloge de 40 kHz correspondant à la fréquence de résonance de notre émetteur ultrasons.

Cette horloge, permettra entre autres d'incrémenter le compteur 12 bits donnant une notion du temps entre l’émission et la réception du signal.

Ainsi, le temps de parcours sera donné par la formule suivante :

avec :

• Compteur : La valeur décimale du compteur à un instant donné.
• Fréquence : Fréquence d'horloge synchronisée sur la fréquence de résonance du FPGA.

Création du signal d’émission

Cependant, il faut pouvoir envoyer uniquement 10 périodes d’émission à la fréquence de 40 kHz en sortie de la Nanoboard afin de simuler une « slave » d’émission.

Ainsi, nous allons comparer la valeur du compteur 12 bits avec les valeurs 0 et 10 ; lorsque le compteur sera compris entre 0 et 10 un signal logique passera à 1. Ainsi, l’émission sera possible. Si le compteur est supérieur à 10, le signal sera à 0, l’émission sera impossible.

Pour résumer :

• Signal à 1 lorsque 0 ≤ compteur ≤ 10.
• Signal à 0 sinon.

Le compteur est remis à 0 lorsque l'intégralité de la slave est reçue par le récepteur.

La comparaison de ce signal logique avec la fréquence d’horloge permettra d'émettre ou non, d’où l’utilisation des deux portes AND, la première permettant la création du signal proprement dite, la deuxième permettant l’émission du signal à la fréquence de l’horloge (qui est aussi la fréquence de résonance) vers l’émetteur lorsque ce signal est à 1.

On utilise alors pour réaliser ce système deux comparateurs et deux portes « AND » :

La partie émission est ainsi réalisée. On peut résumer les actions de ce circuit grâce au chronogramme suivant :

Création de la partie réception

Comme dit précédemment, la partie émission attend que l’ensemble des 10 périodes émises soient reçues pour charger la valeur du registre représentant le temps parcouru par le signal pour faire un aller-retour avant de remettre le compteur à 0. Comme demandé dans le cahier des charges, un bit de lecture est mis en place afin que le registre puisse être lu lorsque celui-ci ne change pas d’état, c’est-à-dire qu’il ne doit pas être lu quand une nouvelle valeur est en train d’être écrite dans celui-ci.

Ainsi, le bit de lecture est à 0 pendant l’écriture dans le registre et à 1 sinon. Enfin, il nous faut préciser que le registre change d’état pour prendre la valeur du compteur lors de la première période de réception, et le compteur revient à 0 lorsque la dernière période de réception, la 10Modèle:Exp, est reçue.

Ainsi, on utilise deux comparateurs, l’un pour permettre l’écriture du registre lorsque l’on reçoit la première impulsion de réception, l’autre pour remettre le compteur à 0 lors de la 10Modèle:Exp réception.

Nous avons donc le schéma global suivant répondant à l’ensemble du cahier des charges partie FPGA :

Critique du système réalisé

Distance de détection limitée

Nous allons désormais regarder les limites du système que nous avons réalisé:

On estime que la vitesse du son dans l’air à une température de 25°C est de 346 m.sModèle:Exp.

Le temps maximum effectué par le son pour effectuer un aller-retour (de l’émetteur/objet/récepteur) devra donc être inférieur à la valeur ci-dessous afin d’être pris en compte pour le système mis en place :

On pourra donc détecter une distance maximale égale à :

Échec d'analyse (fonction inconnue « \itmes »): v=\dfrac{2\times d}{t} \Rightarrow d=\dfrac{v\itmes t}{2}

En prenant Échec d'analyse (fonction inconnue « \maths »): t=t_{max}>\maths> et <math>v=346 m.s^{-1}</maths>, on obtient: <math>d=\dfrac{346\times 0.102375}{2}=17.7 m

La distance maximale détectable par le système que nous allons réaliser sera donc de 17,7 mètres, ce qui cependant, ne semble pas possible vu le matériel que nous allons utiliser.

Remarque : Si on avait voulu détecter un objet à une distance plus importante, il aurait fallu réduire la fréquence d’incrémentation du compteur au détriment toutefois de la précision de la mesure.

Cas de mauvaise réception

Conformément aux explications que notre tuteur nous a octroyées, si l’on ne reçoit pas l’ensemble des périodes de réception, le compteur ne se remettra pas à 0. La saisie de la prochaine réception sera donc faussée. Nous allons donc vous proposer ci-après un nouveau schéma supprimant cette contrainte.

Amélioration du système

Afin de bien tenir compte des nouvelles remarques, et donc d'améliorer la stabilité du système, on modifie le circuit de réception puisque c’est bien lui qui pose problème.

Ainsi, désormais, lorsque qu’un signal est reçu, une bascule D passe à 1, le registre prend donc la valeur du compteur et le bit de permission passe à 0 interdisant ainsi la lecture du registre pendant son changement d’état. Enfin, précisons que le compteur se remet désormais à 0 de lui-même lorsqu’il arrive à 1023.

On a ainsi la partie de réception suivante :

Le schéma global devient donc :

Réalisation de la partie analogique

Nous allons désormais répondre à la deuxième partie du projet d’électronique, c’est-à-dire adapter le signal de sortie du FPGA pour qu’il soit compatible avec l’alimentation nécessaire à l’émetteur ultrasons.

Ensuite, nous créerons un circuit permettant d’amplifier le signal reçu par le récepteur afin qu’il soit correctement traité par la puce FPGA.

Adaptation du signal de transmission

L’émetteur doit être alimenté par une tension alternative de fréquence nominale 40 kHz. Nous choisissons donc ici de l’alimenter par une tension alternative de ± 5V. Le signal de sortie du FPGA étant déjà une tension rectangulaire de 0-5V, il nous suffit de créer un montage donnant une tension de sortie de +5V lorsque le signal est à l’état haut et une tension de -5V lorsque le signal du FPGA est à 0V.

D’où le tableau résumé suivant :

Tableau

Tension signal en sortie du FPGA	Tension aux bornes de l’émetteur
0V	-5V
+5V	+5V

Nous allons donc encore une fois réaliser ce montage à l’aide de portes « NAND » de la manière suivante :

Remarque : Les portes « Nand » sont placées en parallèles afin de doubler la puissance disponible aux bornes de l’émetteur. La capacité « Cap » de 10 nF permet d’éliminer la composante continue du signal de sortie.

Idée d’amélioration : Pour que l’émetteur fonctionnement à puissance maximum, on peut créer une tension sinusoïdale à ses bornes en effectuant un filtre passe-bande afin d’extraire l’harmonique de rang 1 du signal rectangulaire (Fourier). Ce filtre peut être créé à partir d’un circuit RLC ou de la manière suivante :

avec

Adaptation du signal de réception

La perte d'amplitude de notre signal est due à la distance que ce dernier a parcourue.

Plus la distance est grande, plus l'amplitude est faible. Il va donc falloir amplifier le signal reçu. Pour réaliser cette amplification, on utilise un montage à AOP (amplificateur opérationnel).

De plus, il est probable que le signal sera parasité, il faut donc dans un deuxième temps le filtrer.

Amplification du signal reçu

On utilise pour ce faire un AOP en régime linéaire :

On a donc les relations suivantes :

(AOP considéré comme idéal et en régime linéaire)

Ici :

Afin d’avoir un gain de 100, on prend comme valeur R1 = 200 &Omega et R2 = 20 k &Omega. Un tel gain n’est peut-être pas obtenable avec un seule AOP, dans ce cas, il suffit de placer deux AOPs en cascade afin d’obtenir le gain espéré.

Filtrage du signal reçu

Le signal sera filtré de la même manière que le filtrage réalisé sur l’émission, on réalise ainsi le circuit de filtrage suivant :

Échec d'analyse (erreur de syntaxe): G=G_1+G_2 = 20\log\right(\dfrac{1}{\sqrt{1+(R_1\times C_1\times\Omega}^{2}}\left) = 20\log\right(\dfrac{1}{\sqrt{1+\right(\dfrac{1}{R_1\times C_1\times\Omega}\left)^{2}}\left)

Il faut alors déterminer , , , afin d’avoir une bande passante de gain maximum à la fréquence .

Enfin, on vient placer un comparateur à seuil à la sortie du filtre, ainsi lors de le signal dépassera une certaine valeur, la sortie du comparateur passera à 1 signifiant qu’une réception a eu lieu.

Pour aller plus loin

La solution précédente n’est en réalité pas applicable vu le cout qu’elle représenterait à fabriquer.

Nous allons donc vous proposer une solution entièrement analogique qui ne nécessite pas l’intervention d’une puce FPGA.

Cette partie fut en partie réalisée, mais cependant, de part des problèmes survenus lors de son élaboration, l’intégralité ne fut réalisée.

Simulation de la Nanobord et partie émission

Afin d’établir une fréquence de 40 kHz, qui est normalement donné en sortie de la Nanobord, on utilise un circuit analogique.

Ainsi, à l’aide de deux portes « Nand », on va reproduire un oscillateur de 40 kHz et de rapport cyclique de 0.5. On réalise alors le schéma suivant :

Le FPGA (Nanoboard) prenant le relais par la suite, cette partie est alors terminée.

Dont la fréquence est définie par :

Ainsi, si l’on veut obtenir une fréquence de 40 kHz, on doit trouver les valeurs des composants de valeurs ci-dessous.

On est alors censé obtenir un oscillateur de rapport cyclique constant égal à 0.5 et de fréquence 40 kHz. Cependant lors de sa réalisation, seul du bruit est visible en sortie (nous sommes donc bloqué ici dans la réalisation).

Aussi, nous souhaitons émettre des « slaves » d’émission de 10 périodes toutes les 25,5 ms. Nous allons donc réaliser ce principe grâce à un circuit permettant de réaliser une horloge de fréquence et rapport cyclique variable : un NE555.

Ainsi, à l’aide des deux équations données dans la documentation constructeur et pour un rapport cyclique de 0.99 et une fréquence de 38 Hz, on obtient les valeurs des composants suivantes :

prenant pour valeur par défaut 470 nF.

Ces valeurs de composant n’étant pas forcement normalisées ou disponibles, on place sur le circuit les valeurs suivantes :

Les oscillogrammes capturés confirment le résultat attendu :

Afin de pouvoir générer 10 périodes à 40 kHz, on inverse le signal en sortie du NE555 (à l’aide d’une NAND), on obtient donc :

Ainsi, en établissant un ET logique entre cette tension et celle de l’oscillateur à 40 kHz, on permet l’envoie d’une slave (10 périodes à 40 kHz) à l’émetteur.

Nous sommes alors censés obtenir la tension désirée représentant la tension de sortie de la Nanobord qui est ensuite envoyé au montage permettant la création d’un signal alternatif de ±5V.

Partie réception

La partie réception quant à elle ne change pas par rapport à la solution impliquant la puce FPGA, c’est-à-dire que l’on effectue une amplification puis un filtre sur le signal reçu.

Conclusion