Go Down

Topic: [Conseil] Formation de voies, Sonar, traitement du signal et Arduino (Read 992 times) previous topic - next topic

gautierC

Mar 16, 2013, 05:04 pm Last Edit: Mar 16, 2013, 06:58 pm by gautierC Reason: 1
Bonjour à tous!!
Je fais appel à vos avis éclairés à propos d'un projet qui me trotte dans la tête:
Voila, il s'agit de réaliser un sonar (de préférence pour le milieu aquatique). Pour cela, certains bricoleurs se sont généralement tournés vers des solutions simplifiées:
 - usage de hautes fréquences (très directives)
 - emission et reception dans une seule direction, puis la meme chose en se tournant dans d'autres directions pour finalement former une vue d'ensemble.. (fastidieux!)

Bref, cela est déja bien mais ce n'est pas du tout ce que je veux.. je m'explique:
Je souhaite me concentrer sur la partie reception, pour (pourquoi pas) si la qualité est suffisante, en rester à un sonar passif dont l'exploitation (construction d'une situation tactique, positionnement des bruiteurs en distance..) est plus complexe mais passionnante.
Pour cela, le système se composerait d'une série de récepteurs (des micros en gros), en ligne ou en demi cercle (Cf les antennes cylindriques de sous marins), d'une chaine de traitement du signal permettant de faire de la formation de voie à partir des infos fournies par les senseurs:
plus précisément: imaginons une 40aine de micros, à partir desquels le traitement nous fournit une 100aine de voies (réparties sur 180 degrés par exemple)
Pour ceux qui ne comprenent pas du tout de quoi je veux parler, voici des mots clé qui peuvent vous éclairer: Phased array, beamforming, formation de voie
Bref vous imaginez bien la lourdeur du traitement!! (sans compter que l'on veuille rajouter une FFT par la suite pour avoir une analyse en fréquence..  :D mais c'est une autre histoire..)
Pour cela on pourrait imaginer paralelliser le calcul (plusieurs arduino qui se divisent les taches), mais avant cela, j'ai quelques doutes sur les limitations de l'arduino pour le traitement du signal... : j'ai lu ici et la que ces cartes ne seraient pas très adaptées à cause de la fréquence d'échantillonnage demandées par le traitement du son..
Voila j'aimerais avoir vos avis sur tout cela, je vais essayer de rajouter des schémas explicatifs car ne je suis pas sur d'avoir été très clair...  :smiley-sad-blue:
merci à tous!

voila ici on peut voir l'enchainement transducteur/dephaseur/sommateur:

bien sur moi je me restreindrait à une formation de voies en azimut et pas en site..

fdufnews

Projet ambitieux mais l'arduino est totalement inadapté à ce genre de projet. Ce genre de traitement nécessite la mesure de la phase entre les signaux afin de déterminer la direction par la mesure de la différence de chemin. Cela demande un échantillonnage à plusieurs dizaines de fois la fréquence du signal. Comme un sonar fonctionne de quelques kHz à quelques 100kHz tu vois que l'arduino n'est vraiment pas l'outil adapté. Ce type de traitement est généralement réalisé avec des batteries de DSP fonctionnant à des centaines de MHz.

gautierC

Merci pour ta réponse,
Je vois bien ce que tu veux dire, cependant non, pas de mesure de phase, juste plusieurs signaux en entrée, on retarde ceux ci plus ou moins selon la direction qu'on veut "regarder", et on somme le tout (on ne considère que l'amplitude en fait)... Apres pour ce qui est de la fréquence de l'opération, cette opération peut se faire à une fréquence très faible, ce n'est pas un problème.
Et quelqu'un s'y connait-il en FPGA (on sort un peu de l'arduino mais bon..) c'est sans doute plus efficace pour cela?
Cependant je persiste à croire que ce doit pouvoir se faire en Arduino.. non?

fdufnews

Quote
on retarde ceux ci plus ou moins

Quel est le pas souhaité?
Il faut être conscient que l'arduino n'a que très peu de mémoire donc pour faire des lignes à retard avec une résolution raisonnable c'est pas gagné.

Quote
Apres pour ce qui est de la fréquence de l'opération, cette opération peut se faire à une fréquence très faible,

C'est à dire?

Quote
Et quelqu'un s'y connait-il en FPGA (on sort un peu de l'arduino mais bon..) c'est sans doute plus efficace pour cela?

L'avantage du FPGA c'est que tu peux traiter plusieurs canaux en parallèle. Ou multiplexer plusieurs canaux sur une voie de traitement suivant la taille de la matrice que tu choisis et la fréquence de fonctionnement. Tu peux adjoindre de la mémoire pour faire les lignes à retard.

Quote
Cependant je persiste à croire que ce doit pouvoir se faire en Arduino.. non?

Personnellement j'ai un très gros doute. Le point de blocage c'est le stockage des échantillons pour gérer le retard entre les voies.
40 micros comme tu le proposes dans ta présentation c'est 40 lignes à retard. D'une profondeur à déterminer en fonction de ta fréquence d'échantillonnage et du delta de retard que tu dois tenir. La fréquence d'échantillonnage étant elle même conditionnée par la résolution du retard nécessaire pour tenir la précision angulaire que tu cherches à atteindre. Comme ça à la louche je dirais que, à minima, la profondeur mémoire doit se chiffrer en dizaines (voir centaines) de kilo-octets par voie.

skywodd

Bonjour,

Rien que pour l'échantillonnage audio en parallèle je suis même pas sur qu'un STM32F4 (ARM 32bits @168MHz) en utilisant le DSP interne et des chipsets audio I2S puisse gérer les traitements.
Alors un arduino (AVR 8 bits @20MHz) surement pas !
Des news, des tutos et plein de bonnes choses sur http://skyduino.wordpress.com !

gautierC


Quote
Apres pour ce qui est de la fréquence de l'opération, cette opération peut se faire à une fréquence très faible,

C'est à dire?


À la fréquence de rafraîchissement que l'on souhait avoir sur le waterfall, sur l'UI en fait.

Quote

L'avantage du FPGA c'est que tu peux traiter plusieurs canaux en parallèle. Ou multiplexer plusieurs canaux sur une voie de traitement suivant la taille de la matrice que tu choisis et la fréquence de fonctionnement. Tu peux adjoindre de la mémoire pour faire les lignes à retard.

Effectivement ça m'a l'air plus adapté..

fdufnews



Quote
Apres pour ce qui est de la fréquence de l'opération, cette opération peut se faire à une fréquence très faible,

C'est à dire?


À la fréquence de rafraîchissement que l'on souhait avoir sur le waterfall, sur l'UI en fait.

Je ne suis pas d'accord.
La fréquence du traitement est conditionnée par la bande de fréquence du signal à analyser. C'est cette bande de fréquence qui va conditionner la fréquence de l'horloge d'acquisition du signal. Après tu peux faire le calcul sur les données en temps différé mais il faut alors stocker le signal sur une période importante et donc il faut beaucoup de mémoire.

Go Up