ericsenn/localisation_audio
2
1
Fork 0
Code Issues Pull requests Releases Wiki Activity
localisation_audio/daily_work.md

22 KiB
Raw Permalink Blame History

Ajout du 20 Mai:

Les premières recherches utiles sur le sujet: https://tel.archives-ouvertes.fr/tel-00148058/document http://www.isir.upmc.fr/UserFiles/File/argentieri/NSR33/Cours-court.pdf

https://openclassrooms.com/fr/courses/4500266-analysez-les-signaux-1d/4507476-lintercorrelation-une-premiere-approche

Ci-dessous, les travaux d'un homme sur la localisation sonore utilisant une Raspberry et deux microphones. L'orientation d'une "plaque" en fonction de l'origine du son se fait par un moteur. https://microcontroleurs.blogspot.com/2012/08/localisation-dune-source-sonore-avec-un.html https://microcontroleurs.blogspot.com/2012/08/localisation-optique-et-sonore.html?q=Localisation+d%27une+source+sonore+avec+un+ATmega328

Ici, un forum sur lequel une personne a essayé de mettre en application la solution précédente. https://forum.arduino.cc/index.php?topic=386996.0

N.B.: Utilisation de rosserial_arduino: permet d'utiliser ROS directement avec l'IDE Arduino

Une nouvelle solution proposée sur PotBot: https://pobot.org/La-localisation-des-sources-de-son.html?decoupe_recherche=MICRO&artpage=0-0#outil_sommaire_0 (Commentaire du 12/09/10 paraît pertinent) Test simulé sur pc, programme écrit en java (et un peu lourd) mais adaptable en c/c++ (permet de porter le module sur Raspberry Pi). Cela a été fait ici, notamment avec l'utilisation d'ALSA : https://pobot.org/La-localisation-des-sources-de-son,1099.html Cette solution nécessite deux microphones. Peut-être en essayer plus (4 par exemple) ?

Ajout du 21 Mai

Une première version de l'état de l'art concernant le sujet a été rédigé. https://gitcdr.univ-ubs.fr/ericsenn/localisation_audio/src/branch/master/Etat_Art_v1.pdf

De plus, la solution envisagée commence à se préciser: Adapté la solution présentée sur PotBot (https://pobot.org/La-localisation-des-sources-de-son.html?decoupe_recherche=MICRO&artpage=0-0#outil_sommaire_0) afin de l'utiliser en c++ sur un Raspberry Pi. Cela avec l'IDE Arduino (http://wiki.ros.org/rosserial_arduino/Tutorials/Arduino%20IDE%20Setup) permettant de communiqué avec ROS. Dans un premier temps essayer avec deux microphones, puis étudier l'impact sur la précision du système lorsque l'on rajoute des microphones.

Ajout du 22 Mai

Une première version des programmes permettant de communiquer avec la carte son, l'échantillonnage et la localisation ont été écrits. Ils sont disponibles respectivement aux adresses:

Si les deux premiers semblent fonctionner, le dernier n'est pas encore fonctionnel.

N.B: il est nécessaire d'utiliser ALSA via le header "asoundlib.h" pour le bon foctionnement des programmes.

Ajout du 25 Mai

L'objectif du jour était de faire fonctionner les programmes. Pour traiter les sons qui arrivent à la carte son, il existe deux possibilités:

  • hw:x;y
  • plughw:x;y L'utilisation de plughw:x;y (ou hw:x;y) sur mon pc doit se faire avec les paramètres suivants : x=1 (carte 1), y=0 (périphérique 0). Afin de connaitre ces paramètres, il est possible d'utiliser la commande "aplay -l" dans le terminal. Si hw:x;y est plus léger et permet d'accéder directement au hardware, plughw:x;y qui est plus "gourmand" semble pouvoir fonctionner sans problème sur une Raspberry Pi.

Une fois que les programmes ont bien fonctionnés, je les ai utilisés sur un autre pc (également sous linux) qui comportait un microphone interne stéréo (2 micros distants d'environ 5 cm). La détection fonctionne un peu mais il est cependant nécessaire de l'améliorer.

Programme en C++ permettant la localisation :https://gitcdr.univ-ubs.fr/ericsenn/localisation_audio/src/branch/master/sound-source-loc_v.1.0.3.cpp

Programme en Java permettant d'afficher la détection : https://gitcdr.univ-ubs.fr/ericsenn/localisation_audio/src/branch/master/SoundSourceDraw.java

Ubuntu Xenial et Raspbian (linux pour les raspberry pi) sont tous les deux basés sur la distribution Debian. ROS Kinetic pourra donc être aisément porter d'Ubuntu vers Raspbian. Lien vers des explications afin d'utiliser des microphones sur une carte rasperry pi: https://www.pofilo.fr/post/20181216-mic-raspberry-pi/

26 Mai

En première partie de journée j'ai commencé mes recherches sur la façon d'utiliser cmake et j'ai réalisé des premières tentatives. Dans l'après-midi l'alimentation de l'odinateur a coupé, j'ai donc essayé de trouver une solution pour la réparer/changer.

Ajout du 27 Mai

J'apprends a utiliser cmake. http://rachid.koucha.free.fr/tech_corner/cmake_manual_fr.html http://sirien.metz.supelec.fr/depot/SIR/TutorielCMake/index.html#principe https://alexandre-laurent.developpez.com/tutoriels/cmake/

Il y a un problème de "référence indéfinie" lors de la compilation avec cmake car le header "asoundlib.h" n'est pas trouvé.

Afin d'améliorer la précision du programme existant, j'essaie de trouver d'autres façons d'obtenir la direction notamment via l'intercorrélation: https://hal.archives-ouvertes.fr/hal-01146396/document https://hal.univ-lorraine.fr/tel-01749833/document

N.B: Des problèmes avec l'alimentation de mon pc m'ont ralentis.

Ajout du 28 Mai

Le fichier CMakeLists.txt permettant de compiler le programme de compilation en c++ a été terminé: https://gitcdr.univ-ubs.fr/ericsenn/localisation_audio/src/branch/master/CMakeLists.txt Dans le chemin du CMakeLists, où se situe le programme localisation.cpp il faut donc utiliser cmake (version 3.10) dans le terminal :

  1. cmake CmakeLists.txt
  2. make L'exécutable est alors créé avec toutes les dépndances nécessaires.

J'ai essayé d'optimiser le programme de localisation, mais pour le moment cela est infructueux. Pour le moment le progrmme ne peut localiser la source sonore que selon 180°. Pour avoir une "vision" de 360° il semble nécessaire d'utiliser plus de 2 microphones (cela se dirige vers une utilisation de 4 microphones).

Ajout du 29 Mai

Le dossier contenant le fichier cmake permettant la compilation du programme de localisation a été rajouté à cette adresse : ccf2806151 . Ce dernier a été réécrit plus proprement. Le fichier java permettant de visualiser la direction du son a été ajouté au dossier.

Plusieurs idées ont été pensées pour localiser les sons à 360° autour du sujet. Elles sont au nombre de deux et utilisent toutes quatre microphones: https://gitcdr.univ-ubs.fr/ericsenn/localisation_audio/src/branch/master/Utilisation%20de%204%20microphones.docx

Une machine virtuelle avec linux a été installée sur le pc fonctionnant sous windows. Ce dernier comportant plusieurs entrées microphones il pourrait être utile au moment de tester une solution avec plus de deux microphones. Sinon, le pc portable comportant un microphone interne stéréo a aussi une entrée pour un micro, peut-être que je pourrais l'utiliser. Il existe aussi des microphones USB, à voir si je peux m'en procurer.

Ajout du 02 Juin

Une nouvelle solution permettant de n'utiliser que trois microphones a été pensée pour une localisaion à 360° (partie III du document suivant): https://gitcdr.univ-ubs.fr/ericsenn/localisation_audio/src/branch/master/Localisation_360_degres.pdf

La décision a été prise d'utiliser ctte troisième solution, il a donc fallu adapter le code précédent (avec deux microphones) afin de prendre en compte et d'utiliser le troisième microphone. Plusieurs rajouts ont été écrits: https://gitcdr.univ-ubs.fr/ericsenn/localisation_audio/src/branch/master/Localisation_360

Un petit souciest survenu : lorsque le micro externe est branché sur le pc (par une prise jack), cela désactive automatiquement les micros internes. Cela empêche donc pour le moment d'utiliser plus de deux microphones. Il faut donc trouver un moyen de controler trois microphones sur un même pc (et sans table de mixage !). La carte son ne pouvant pas contrôler deux entrées directes en même temps, l'utilisation d'un microphone passant par un port USB (et donc n'utilisant pas la carte son) en complément des microphones internes pourrait fonctionner. Peut-être trouver un moyen d'utiliser mon smartphone comme microphone USB ?

Ajout du 03 Juin

Afin d'utiliser mon smartphone comme un microphone USB, j'ai essayé d'utiliser Wo Mic. Ce logiciel doit permettre de transmettre les sons captés par le téléphone via le port usb : https://wolicheng.com/womic/

Cela n'étant pas concluant, j'ai trouvé un moyen de connecter mon smartphone à mon pc en bluetooth, puis d'envoyer le son capté par le micro du téléphone au pc. Le problème est que le temps de latence est trop élevé et faussera donc les calculs (ces derniers étant basés sur le temps de parcours du son de la source jusqu'au microphone). Je pourrais alors utiliser trois téléphones connectés en bluetooth, mais il faudra modifier le code pour changer la voie d'acquisition du son (la bibliothèque hci_lib semble permettre cela).

Dans l'optique d'avoir un microphone USB, je me suis renseigné sur la façon de gérer la lecture des port USB en C++. Voici quelques liens intéressants:

Ajout du 04 Juin

J'ai travaillé sur le début de mon rapport en début de journée. Ensuite installation de ROS Kinetic (desktop version et non desktop full version) sur la VM simulant Ubuntu Xenial: http://wiki.ros.org/kinetic/Installation/Ubuntu

La différence entre les deux versions réside dans la prise en compte de la perception et de la simulation 2D/3D ainsi que la navigation par la version "full".

Je me suis rendu compte que le son n'est pas géré correctement sur la VM:

  1. Dans un premier temps le son en entrée n'était pas activer...
  2. Ensuite, il a fallu changer le contrôleur audio de AC97 vers Intel Audio HD car la sortie ne foncionnait pas.

En revanche, les entrées microphones ne fonctionnait pas toutes sur la VM (seulement 1 sur les 3). En passant du contrôleur audio Intel Audio HD vers SoundBlaster 16 plus rien ne fonctionnait (ni les entrées, ni les sorties). Je suis donc repassé sur Intel Audio HD et là : plus de micro du tout. Au final, le contrôleur aduio de départ AC97 fonctionne pour la sortie audio.

Après avoir testé une VM avec Ubuntu 20.04 en guest, il s'avère que le meilleur compromis est d'utiliser le contrôleur audio Intel Audio HD. Cependant, pour que l'unique entrée microphone détectée fonctionne, le microphone doit être branché dès le lancement de la VM.

ajout du 05 Juin

Récapitulatif des besoins pour utiliser le programme sur ubuntu xenial:

  • Cmake version 3.5.1 : pas de mise à jour à faire
  • g++ version 9 pour utiliser (compiler) le code en C++ 11 : mise à jour nécessaire https://doc.ubuntu-fr.org/gcc
  • libasound2-dev pour avoir les headers Alsa nécessaires : installation nécessaire --> sudo apt-get install libasound2-dev

Apprentissage de l'utilisation de ROS Kinetic :

http://wiki.ros.org/ROS/Tutorials

http://wiki.ros.org/fr/ROS/Tutorials/UnderstandingNodes#:~:text=Un%20node%20n'est%20rien,fournir%20ou%20utiliser%20un%20Service.

https://niryo.com/fr/2017/03/comment-apprendre-la-robotique-avec-ros/

Il sera peut-être intéressant d'utiliser rqt_plot (package de ROS) afin de tracer la position angulaire de la source par rapport au robot.

Je travaille à présent sur la VM Ubuntu Xenial. Afin d'utiliser le microphone stéréo du petit pc portable, j'ai utilisé Audacity pour enregistrer le son et l'envoyer sur le pc "tour" (via leurs prises jack respectives, à l'aide d'un cordon jack mâle/mâle). La qualité audio ne semble pas trop impactée. L'utilisation du programme de localisation de source sonore avec ROS pourra au moins être testée pour une détection à 180°. Il serait toutefois intéressant de trouver le moyen d'utiliser 3 microphones.

Ajout du 08 Juin

Dans la matinée j'ai essayé de faire fonctionner mon programme avec ROS. J'ai donc:

  • Créé un environnement de travail
  • Créé un package localisation
  • Construit le package localisation
  • Paramétré le CMakeLists.txt pour la compilation du programme localisation.cpp avec catkin_make
  • Testé l'exécution du node loca_exe permettant la localisation du son.

Par la suite, j'ai rédigé une "notice" afin de me rappeler aisément comment refaire toutes ces opérations: https://gitcdr.univ-ubs.fr/ericsenn/localisation_audio/src/branch/master/Creation_package_v1.pdf

Ajout du 09 Juin

Le problème de source du setup.bash avant chaque exécution du programme a été résolu. Il fallait rajouter la ligne source ~/catkin_ws/devel/setup.bash à la fin du fichier .bashrc.

Afin d'utiliser les microphones USB et jack simultanéments, voici quelques pistes trouvées sur internet:

Ajout du 10 Juin

J'apprends comment utiliser plusieurs nodes ensemble. Notamment à l'aide de ces sites internet:

Le noeud de mon package localisation n'apparait pas lorsque j'utilise la commande "rosnode list". Je ne sais pas pourquoi.

Le microphone USB ne fonctionne toujours pas en simultané avec le microphone stéréo jack.

Ajout du 11 Juin

Pour lire un port usb : http://manpagesfr.free.fr/man/man2/open.2.html

Connaitre le chemin d'accés à l'appareil connecté : https://doc.ubuntu-fr.org/usb

J'ai fait un petit programme permettant de lire l'entrée usb. Les valeurs lues successivement vont de 3 à 1023 ( 2¹⁰ ?)

Je veux faire communiquer mon node de localisation avec le node turtlesim.

Ajout du 12 Juin

J'essaie de me familiariser avec ROS:

Il faut utiliser ros.h (puis ros::init dans le code après int main()) pour que mon node "localisation" apparaisse. (et std_msgs/string.h pour la communiation ?)

Pour utiliser un topic: ros::Subscriber subscriber_obj = nodehandle.subscribe ("topic_name", 1000, callbackfunctio)

Le dernier lien donne pas mal d'indications sur l'utilisation (l'incorporation) de ros dans un code c++.

Ajout du 15 Juin

Liens pour comprendre comment modifier un programme en C++ pour une utilisation avec ROS:

Problème de nom du noeud utilisé avec ros::init:

Le nom "_loca_exe" utilisé pour l'exécutable (et donc le nom du noeud) posait problème. En le remplaçant par localisationv2, ros::init() fonctionne correctement. En revanche, pour voir apparaitre le noeud avec la commande rosnode list, il faut ajouté la ligne "ros::Nodehandle nh;" après "ros::init(argc, argv, "localisation_v2");"

Les commandes ctrl+c ou rosnode kill ne permettent plus d'arrêter le programme.

Comprendre la communication des nodes:

En regardant dans les scripts pythons de turtlesim (à l'adresse : opt/ros/kinetic/lib/python2.7/dist-packages/msg/turtlesim/_Pose.py) j'ai pu constater que les données échangées sur les topics sont du type float32. Cela m'indique donc que je dois utiliser le format Float32 pour publier les informations à turtlesim sur le topic.

Ajout du 16 Juin

J'ai réussi à faire un sorte que le node localisation publie sur le topic de commande de vélocité de turtlesim. Cependant, turtlesim attend un message de type geometry_msg/Twist pendant que le noeud de localisation publie un message de type std_msg/Float32.

En effet après avoir utilisé le noeud turtlesim_node avec le noeud turtlesim_teleop_key (ce dernier envoyant des commandes de vélocité) j'ai regardé avec la commande rostopic echo /turtle1/cmd_vel les informations transmises sur le topic /turtle1/cmd_vel. Deux vectors sont transmis :

  • Vecteur linéaire (x;y;z)
  • Vecteur angulaire (x;y;z)

Chacun des deux vecteurs ne publie que selon x. (Avant/arrière et pivote sur gauche/droite)

Afin de permettre la publication de l'angle en continu sur le topic, il a fallu supprimer la boucle "while(true)" de la fonction run() exécutant le traitement du son sans arrêt. Elle a été remplacée par une boucle "while(ros::ok())" dans la fonction principale main(). Cela permet d'émettre en continu sur le topic ET d'arrêter le fonctionnement du programme avec un simple ctrl+c dans le terminal.

Ajout du 17 Juin

Le noeud publiait bien sur le topic mais cela n'affectait pas le déplacement de turtlesim. En effet il fallait envoyé une information de rotation selon le vecteur angulaire z et non x comme je le pensais au début. La tortue de turtlesim pivote maintenant selon l'origine du son ! Il reste un petit problème: le noeud de localisation semble parfois publier sur le topic deux voire trois fois le même angle alors qu'il ne devrait l'envoyer qu'une seule fois. Cela n'arrive cependant que quelques fois.

N.B: Le noeud de localisation envoie un angle en radian et le noeud de turtlesim utilise les angles en radian

Il faudrait idéalement trouver une solution pour une détection à 360° avec trois (ou quatre) microphones.

RDV médicale l'après-midi.

Ajout du 18 Juin

Afin de trouver une solution pour dépasser le nombre de deux microphones simultanés, j'essaie de mieux comprendre le fonctionnement d'un carte son:

A priori, le chipset utilisé sur la VM (AC 97) est plutôt ancien. L'utilisation du chipset INTEL High Definition audio serait préférable.

Possible solution: Sous windows: HP audio switch -> paramètres du contrôle audio -> Réglages avancés -> Activer la lecture de plusieurs sources en continu.

Ajout du 19 Juin

Le problème de lecture du port USB sur lequel est branché est logique: Je n'essayais pas de lire les données transmises mais d'ouvrir un fichier "imaginaire".

Il y a un poblème d'affichage sur turtlesim : lorsque la commande de vélocité est envoyée, la tortue disparait parfois (au bout d'un temps variable). Je vais essayer de comprendre d'où vient le problème pour être sûr qu'il s'agit bien exclusivement d'un problème d'affichage.

Ajout du 22 Juin

La cause de la disparition de la tortue est finalement simple : lorsqu'il y a un bruit de fond, le programme envoie un angle "nan" (Not A Number). Cela n'étant pas un nombre, la tortue disparait. Lorsqu'un son est trop faible, il n'est pas pris en compte afin de ne garder que les sons "exploitables". En ajoutant une condition (vérifiant si la variable est bien un nombre) lors de l'envoie de la commande, la tortue ne disparait plus.

Ajout du 23 Juin

Le code final pour une localisation à 180° est disponible ici:

Le dossier comprend:

  • Le fichier Localisation180.cpp, programme C++ permettant la localisation du son pour ROS.
  • Le fichier CMakeLists.txt, celui qui est nécessaire pour la compilation avec catkin_make.

Pour plus d'informations pour les utiliser, se référer à la notice suivante : https://gitcdr.univ-ubs.fr/ericsenn/localisation_audio/src/branch/master/Creation_package_v1.pdf

La lecture des deux cartes son (celle du pc et celle du microphone usb) fonctionne enfin. Le code pour une localisation à 360° semble donc enfin fonctionner ! Il utilise donc le son du microphone USB et les deux microphones intégrés au pc :

Ajout du 24 Juin

Le programme a été amélioré afin de traiter correctement les angles. A présent la position des microphones est prise en compte:

De plus, une version a été écrite pour fonctionner avec ROS:

Le programme fonctionne bien sur le pc portable ubuntu, mais ne semble pas fonctionner avec la VM.

Lien intéressant pour la gestion de turtlesim: https://linklab-uva.github.io/autonomousracing/assets/files/ros-turtlesim.pdf

Ajout du 25 Juin

La VM ne fonctionnait pas avec l'USB 3.0 ce qui explique pourquoi la carte son du microphone USB n'était pas reconnue (alors que le microphone fonctionnait). A présent les deux cartes son sont bien reconnues. Le problème de conflit entre les deux cartes son a été résolu en passant du contrôleur audio AC97 à INTEL audio HD.