Reconnaissance de forme dans un système temps réel

[Peterrr]

Bonjour à tous!

Je vous expose mon problème du moment. J'ai à disposition un microncontroleur qui va recevoir en permanence des signaux sur son entrée analogique. Comme il s'agit d'un micro 12 bits, ce signal est représenté entre 0 et 4096 en sortie du CAN.
Mon but est d'identifier des créneaux. L'image suivante va être plus parlante:



je veux réussir à détecter cette forme quand elle survient. J'allume une led par exemple ou je déclenche un petit buzzer pour que l'on sache en temps réel si la forme est apparue. J'ai codé une méthode s'appuyant sur l'analyse des dérivées, mais je suis convaincu que l'on peut mieux faire. Elle donne des résultats intéressants, mais ne répond pas juste assez souvent à mon goût. Mon créneau n'est pas parfait dans la réalité, et n'est jamais exactement le même forme. C'est pourquoi je cherche d'autres méthodes. Je me suis tourné vers les algorithmes d'apprentissages (style RDN, ou autre). Un avantage est que je suis capable de fournir autant d'exemples d'apprentissages que je veux. Mais je ne vois pas trop comment m'y prendre. Des personnes ici ont codé des algo d'apprentissages sur microcontroleur?
Bonne après-midi à vous.
Peter
-----

[antek]

Il s'agit donc d'extraire un signal du bruit de fond.
Bon courage !

[Peterrr]

C'est exactement ça. Et ce que je dois extraire est, bien que globalement de type créneau, soumis à une assez grande variabilité. Que du bonheur en perspective, donc!

Mais je le répète, je peux enregistrer autant de réponses que je le souhaite. Je dispose d'une base d'apprentissage infinie. Et c'est pourquoi je me suis dit que des méthodes à base d'apprentissage du style des réseaux de neurones ou autres pouvaient être adaptées.
A défaut de ton aide, merci de ton soutien!
Si quelqu'un avait déjà travailler sur ce genre de chose et avait l'expérience de ce genre des chose!

[Ludwig1]

Salut,
Durée minimale de l'échelon à prendre en considération ?
Largeur de l'échelon ?
L'amplitude minimale etc...
L'approche par la dérivée est OK
Tu peux faire un mix P.I.D. puis traiter le résultat en fonction d'un modèle (Comparateur)
N'oublie pas la période d'échantillonnage.
Regarde ce que donne la transformée en Z de ton signal en entrée.
Etc...
Cordialement

Ludwig

[A voir en vidéo sur Futura]

[pm42]

Et c'est pourquoi je me suis dit que des méthodes à base d'apprentissage du style des réseaux de neurones ou autres pouvaient être adaptées.

Si tu veux faire ça, l'approche serait plutôt d'avoir un gros échantillon de signaux avec un indicateur qui dit s'il y a un créneau ou non.
Ensuite, sur une machine puissante, pas ton micro-controlleur, tu fais faire l'apprentissage pour reconnaitre les créneaux à une réseau de neurones. C'est de l'apprentissage supervisé : https://fr.wikipedia.org/wiki/Appren...supervis%C3%A9

Une fois que ton réseau est entrainé et fonctionne bien, tu peux envisager le faire tourner sur ton micro-controlleur. La puissance est nécessaire pour l'apprentissage, beaucoup moins pour l'exécution.
Voir par ex : http://robotics.stackexchange.com/qu...icrocontroller

[bdom001]

Je n'ai que des connaissances très sommaires et générales en traitement du signal, mais si je devais résoudre ce problème, en supposant que la largeur de l'impulsion est connue et constante, je déplacerais une fenêtre carrée (arbitrairement unitaire) de même largeur que celle de l'impulsion et je la multiplierais par le signal. L'intégrale de ce produit sur l'intervalle de la fenêtre atteindrait alors un maximum lors du passage sur l'impulsion. Il suffirait ensuite de déterminer expérimentalement une valeur de seuil de cette intégrale pour éliminer les effets du bruit de fond.

À soumettre aux avis critiques ...

Cordialement

[lou_ibmix_xi]

Mais je le répète, je peux enregistrer autant de réponses que je le souhaite. Je dispose d'une base d'apprentissage infinie. Et c'est pourquoi je me suis dit que des méthodes à base d'apprentissage du style des réseaux de neurones ou autres pouvaient être adaptées.
A défaut de ton aide, merci de ton soutien!
Si quelqu'un avait déjà travailler sur ce genre de chose et avait l'expérience de ce genre des chose!

Ya plein de problématique se réduisant à ton problème... garde encore un peu tes réseaux de neurone au frais....
Tu peux t'inspirer de méthodes "statistiques":
-une simple moyenne glissante
-STA/LTA (utilisée en sismo), moyenne à court terme du signal redressé, divisé par la moyenne à long terme du signal redressé
-facteur de crête: écart du point à la moyenne, divisé par l'écart type
-...
Des trucs plus géométrique à base régression linéaire, et de distance de point au segment...

google pour "détection transitoire", ("transient" la littérature technique étant plus riche in english)

en supposant que la largeur de l'impulsion est connue et constante, je déplacerais une fenêtre carrée (arbitrairement unitaire) de même largeur que celle de l'impulsion et je la multiplierais par le signal. L'intégrale de ce produit sur l'intervalle de la fenêtre atteindrait alors un maximum lors du passage sur l'impulsion.

Brutalement c'est du filtrage adapté, ça marche bien en théorie, ou si tes signaux sont un peu plus compliqués... Ceci dit, dans ce cas particulier, faire du filtrage adapté pour un signal carré, c'est faire une moyenne glissante, donc la 1ère solution que je propose, et qui peut suffire, tout dépends du bruit...

[bdom001]

Bonjour,

Ceci dit, dans ce cas particulier, faire du filtrage adapté pour un signal carré, c'est faire une moyenne glissante, donc la 1ère solution que je propose, et qui peut suffire, tout dépends du bruit...

Oui, d'autant plus qu'il ne faut pas non plus perdre de vue la notion de temps réel. Cette technique de moyenne glissante est probablement la plus rapide.

[Peterrr]

Merci pour votre aide!
Le problème est que l'amplitude varie, et sa durée n'est pas fixe mais est contenu disons entre 1 et 3 secondes. C'est pourquoi mon approche sur les dérivées marche convenablement, mais pas encore assez à mon gout. Je vais creuser du côté de la transformée en Z, j'y avait pensé mais je ne l'ai pas encore appliquée.
Je reviendrai vers vous pour vous parler de mon avancement.
Bonne journée

[lou_ibmix_xi]

C'est pourquoi mon approche sur les dérivées marche convenablement,

C'est tellement évident que je n'y avais pas pensé !!! Effectivement en prenant le "diff" point à point tu devrais transformer ton créneau en 2 impulsions? et combiner avec une petite moyenne glissante éventuellement pour lisser le bruit.
La durée variable ne devrait pas tant poser de problème que ça, elle impose la (les) taille(s) de(s) fenêtre(s) utilisée(s).

[Peterrr]

C'est ça. Je transforme mon créneau en deux impulsions, et je lisse un peu le tout avec une moyenne glissante. La durée ne pose pas de problème en effet avec cette approche, j'observe juste que mes deux impulsions sont contenues dans une fenêtre temporelle de, globalement, [1s;3s].
je dois être à un bon 80% de réussite, mais je souhaiterais encore améliorer le tout. Comme je vous l'ai dit précédemment, je vais regarder du côté de la transformée en z. faut juste que je code ça en c, et je pourrais vous dire ce que j'obtiens.
Encore une fois, merci à tous pour vos idées et contributions!

[bdom001]

Bonjour,
j'allais vous demander d'expliciter en quoi consistait exactement votre approche par la(les) dérivée(s) ?
Lorsque vous dites transformer votre créneau en deux impulsions, vous parlez sans doute du front montant et du front descendant. Mais peut-être faut-il aussi considérer que la valeur de la dérivée du signal s'annule davantage pendant le créneau que partout ailleurs.

[Peterrr]

C'est ça.
J'ai également pris en compte le fait que la dérivée s'annule au milieu du créneau, et je compare la valeur réelle du signal juste après le début du créneau, et juste avant la fin. Ces deux valeurs doivent être globalement semblables. J'ai globalement tiré tout ce que je pouvais de cette méthode, donc je vais me pencher sur d'autres essais.

[bdom001]

Avez-vous pensé aussi à la dérivée seconde ? Sur le front montant, vous allez obtenir à une sorte de double impulsion, la première positive et la seconde juste après, négative, les deux étant "presque" identiques en valeur absolue.

[Peterrr]

Oui, j'ai également testé la dérivée seconde. Elle est légèrement moins intéressante que la dérivée première puisqu'elle est plus soumise aux petites variations. Au final, même sur mes paliers, elle "danse" plus que la dérivée première. Merci quand même pour cette proposition

[lou_ibmix_xi]

Je ferai la moyenne glissante avant la dérivée, pour filtrer le signal (moyenne glissante) avant de le passer dans le détecteur (dérivé). Ca sous-entends que l'échelon que tu cherches à détecter soit suffisament "décollé" du bruit, mais un rapport signal à bruit minimal, classique pour que le détecteur fonctionne 'correctement' (fausse alarme VS détection manquée). Plus tu a du bruit, plus il faut lisser (augmenter la taille de la moyenne), ta limite supérieure devant (amha) inférieure à la seconde que tu veux détecter.

[bdom001]

Une idée qui me vient comme ça : amplifier les valeurs négatives avec un coefficient alpha > 1 avant de procéder à la moyenne glissante^(*). Le créneau étant essentiellement positif, cela devrait accentuer la différence entre le bruit de fond et le signal utile.

^(*) On est d'accord pour dire que lorsqu'on parle de moyenne, on peut éventuellement se contenter de l'intégrale sur la fenêtre et donc faire l'économie de la division finale par la valeur de la période.

[Peterrr]

J'ai bien pensé à une sorte de coefficient, mais c'est assez dur à régler comme paramètre. Idem pour le lissage (i.e. sur combien d'échantillons le faire). J'aimerais faire quelque chose de propre quand même, et pas uniquement basé sur l'expérience. Il y a des méthodes pour optimiser un lissage, où trouver un coefficient qui convient?
Ou alors, c'est uniquement en testant des séries de paramètres que l'on peut réussir à trouver une combinaison idéale?

[bdom001]

J'ai bien pensé à une sorte de coefficient, mais c'est assez dur à régler comme paramètre. Idem pour le lissage (i.e. sur combien d'échantillons le faire).

En fait il peut s'agir d'un coefficient ou peut-être préférablement d'un offset à soustraire. Si vous ne savez pas par où commencer, vous pourriez essayer la valeur RMS du bruit hors créneau ... peut-être ... je n'ai pas suffisamment d'expérience pour en parler.

J'aimerais faire quelque chose de propre quand même, et pas uniquement basé sur l'expérience. Il y a des méthodes pour optimiser un lissage, où trouver un coefficient qui convient?
Ou alors, c'est uniquement en testant des séries de paramètres que l'on peut réussir à trouver une combinaison idéale?

Au début du fil, vous parliez d'un réseau de neurones, donc se basant sur l'expérience. L'ennui avec ces RDN, c'est que si ils finissent par "comprendre" ce qu'il faut faire, c'est une info qu'ils ont tendance à garder pour eux, et vous n'aurez toujours pas la garantie de 100% de fiabilité. L'idée peut être de se substituer à eux, mais toujours en passant par l'expérimentation du coup, pour déterminer une heuristique.

Je ne connais pas l'environnement dans lequel vous travaillez, mais il faudrait que vous puissiez visualiser les données que vous obtenez après le traitement du signal initial.

Pour les lecteurs de ce forums, il faudrait que vous montriez un ou plusieurs échantillons représentatifs de votre signal moins idéalistes (donc plus réaliste) que celui de votre premier message.

[Dlzlogic]

Bonjour,
Je pense à une autre approche que le calcul de la dérivée.
Si j'ai bien compris le but est de déterminer une "anomalie" dans le signal.
La loi normale est une bonne méthode pour résoudre cela.
Soit un certain nombre d'observations (votre courbe avant créneau), la moyenne arithmétique de ces observations est M, et E l'écart-type.
Si une valeur dépasse 3 écarts-types elle a moins d'une chance sur 100 d'être bonne. Si la suivante dépasse encore 3ET alors, c'est 1/10000.
Cette méthode a l'avantage d'être rapide en calcul.
Suivant le contexte (que je ne connais pas) l'écart-type peut être une valeur calculée une fois pour toutes et est directement lié à la fiabilité du détecteur, y compris son environnement etc. Par contre, il ne me semble pas qu'on puisse échapper au calcul d'une moyenne glissante.

[lou_ibmix_xi]

Si j'ai bien compris le but est de déterminer une "anomalie" dans le signal.
La loi normale est une bonne méthode pour résoudre cela.

C'est bien le facteur de crête dont je parlais un peu plus haut, tu vérifies l'atypicité (terme que j'ai croisé en math financière pour le même concept) de chaque échantillon par rapport à une loi gaussienne, donc que l'écart entre la valeur de l'échantillon et la moyenne (locale) ne dépasse pas x fois l'écart type (x étant bien souvent égal à 3), c'est également très utilisé pour virer des "outliers" d'une série d'acquisition.

Une idée qui me vient comme ça : amplifier les valeurs négatives avec un coefficient alpha > 1 avant de procéder à la moyenne glissante(*). Le créneau étant essentiellement positif, cela devrait accentuer la différence entre le bruit de fond et le signal utile.

(*) On est d'accord pour dire que lorsqu'on parle de moyenne, on peut éventuellement se contenter de l'intégrale sur la fenêtre et donc faire l'économie de la division finale par la valeur de la période.

Perso je ne partirais pas dans des traitements "bricolés" tant que l'idée générale n'est pas bien établie, tant que tu as besoin de raisonner mathématiquement avec ton détecteur. C'est le genre de magouilles que j'introduirai éventuellement lors de la mise-au-point.
(*) puisqu'on en est à grappiller sur les termes, je parlerai de sommation (pour que ce soit bien clair pour tout le monde), et attention c'est peut-être une fausse bonne idée si:
- la taille de la fenêtre glissante est importante (et calcul en entier) alors tu risque d'exploser rapidement ta dynamique (12bits c'est 2048 ou 4096 max...)
- si le coût logiciel d'une division(*) est pinuts par rapport à ta boucle de sommation, si tu sors la division de la boucle tu retrouves le problème ci-dessus, mais si tu choisis un nombre de point puissance de 2, tu peux utiliser du décalage de bits plutôt qu'une division, ou si la taille de la fenêtre est fixe et connu à la compilation...

En fait il peut s'agir d'un coefficient ou peut-être préférablement d'un offset à soustraire. Si vous ne savez pas par où commencer, vous pourriez essayer la valeur RMS du bruit hors créneau ... peut-être ... je n'ai pas suffisamment d'expérience pour en parler.

Pour la moyenne glissante / dérivation, je ne vois que 2 paramètres: la taille de la fenêtre (j'ai déjà donné les contraintes au-dessus), et la valeur de dépassement de seuil pour tes pics, à choisir en fonction de ton taux de fausse alarme / détection manquée...

En fait il peut s'agir d'un coefficient ou peut-être préférablement d'un offset à soustraire. Si vous ne savez pas par où commencer, vous pourriez essayer la valeur RMS du bruit hors créneau ... peut-être ... je n'ai pas suffisamment d'expérience pour en parler.

ça me fait penser à une autre méthode statistique: la normalisation à trou: tu as une fenêtre centrale entourée de deux fenêtres de tailles identiques (et à priori plus grande que ta fenêtre centrale), tu normalises ton signal à droite et à gauche (i.e. (signal - moyenne) / variance, ton signal ressort centré de variance unité), tu calculs la moyenne et la variance de ton signal dans la fenêtre centrale et puis... j'ai un trou... Je crois que tu normalises la fenêtre centrale avec la moyenne et variance de tes fenêtres droites et gauche puis tu compares à un seuil "normalisé". La logique la derrière est que la fenêtre centrale fait la taille de ton créneau, la normalisation à droite et à gauche te permettant de rendre ton seuil indépendant du bruit, si la moyenne (et/ou) la variance au centre dépasse le seuil, c'est qu'il se passe "quelque chose" dans ta fenêtre centrale "par rapport" à ce qu'il se passe dans tes fenêtres latérales.

D'ailleurs, il y a tout de même un détails qui mérites d'être souligné, j'imagine (j'espère) que par temps-réel tu veux dire "automatiquement et sans post traitement", car tout ces traitements impliquent des retards de la taille des fenêtres glissantes...

[Ludwig1]

Salut

Je vous expose mon problème du moment. J'ai à disposition un microncontroleur qui va recevoir en permanence des signaux sur son entrée analogique. Comme il s'agit d'un micro 12 bits, ce signal est représenté entre 0 et 4096 en sortie du CAN.
Mon but est d'identifier des créneaux. L'image suivante va être plus parlante:

J'ai encore une fois regardé ton affaire, il me semble que c'est un bête Trigger qu'il faut programmer. Elimine la composante continu sois par Hard ou par soft.
En tout état de cause, il faut éliminer la composante continue.


Cordialement

Ludwig

[Peterrr]

Bonjour à tous!

Je ne peux malheureusement pas vous fournir une trace. Je les ai, j'y ai accès, mais je ne suis pas autorisé à communiquer cela ici. Merci à tous en tout cas.
Je vais regarder la méthode de normalisation à trou alors et votre méthode basée sur la loi normale.

[lou_ibmix_xi]

votre méthode basée sur la loi normale.

Elle le sont toutes à partir du moment où tu raisonnes en moyenne / variance, tu ne fais que chercher le moment où tes données ne sont plus distribuées selon une loi normale -> il y a un transitoire.

[Peterrr]

Salut



J'ai encore une fois regardé ton affaire, il me semble que c'est un bête Trigger qu'il faut programmer. Elimine la composante continu sois par Hard ou par soft.
En tout état de cause, il faut éliminer la composante continue.


Cordialement

Ludwig

Je rebondie juste là dessus. Ça serait en effet trop simple si le niveau était constant, donc s'il suffisait d'éliminer une composante continue.

[Peterrr]

Une dernière fois, merci à tous pour vos propositions. J'ai de quoi avancer et pas mal de pistes à creuser. On peut noter le sujet comme résolu maintenant, car même si je n'ai pas encore implémenté tout cela, vos pistes vont me permettre d'améliorer la fiabilité de mon algorithme. Belle réactivité!