Perceptrons zum Erkennen einer Messkurve
-
Hio,
ich arbeite derzeit an der Verarbeitung von Messwerten (Beschleunigungssensor) auf einem Microcontroller. Ziel ist es, den Verlauf der Messwerte zu erkennen und dann entsprechend zu reagieren, falls der Verlauf bekannt ist. Konkret z.B. wenn ein Roboter auf die Seite kippt, so liefert der Beschleunigungssensor eine ganz eigene (charakteristische) Kurve, die ich gerne erkennen würde.
Hierzu habe ich den Verlauf des Signales bereits mit einem Tiefpass geglättet und kann nun zur eigentlichen Erkennung übergehen.Damit ich später auch weitere Signalverläufe einprogrammieren kann, würde ich das Ganze gerne mit einem neuronalen Netz bzw. konkret mit mehrstufigen Perceptrons programmieren. Hierzu war meine Idee folgende:
Ein Signal (d.h. z.B. eine vollständige Kippbewegung) stelle ich als einen n-Elementigen Vektor von Messewerten (z.B. Beschleunigung in X-Richtung) dar. Problematisch ist hierbei, dass sowohl die Abtastrate, als auch die Zeitpunkte wann die diskreten Messwerte gemessen werden, immer unterschiedlich sein können.Das bedeutet, ich kann nicht sagen, ich habe z.B. alle 20ms einen Messwert. Es kann durchaus nach 10ms schon ein "ausreichend" neuer Messwert vorliegen oder auch erst nach 50ms. Ich denke jedoch, dass ich die Abtastrate hinreichend gering wählen kann, sodass die Größe des Vektors konstant bleibt (evt. muss ich dann Datenpunkte interpolieren, mal sehen..). Als Vorraussetzung kann ich jedoch annehmen, dass jeder Messvektor gleich groß ist.
Jedoch kann ich nicht mit Sicherheit sagen, dass jeder Messpunkt im selben Bereich des Signales liegt (halt z.B. 5 Messwerte im Bereich von 100-200ms, aber nur 1 Messwert im Bereich von 300-500ms bei der nächsten Messung kann das wieder ganz anders aussehen)Zu Beginn mache ich dann z.B: 20 Testmessungen und nehme diese als postive Testdaten. Wenn ich den Aufbau des neuronalen Netzes nun richtig verstanden habe, mache ich nun folgendes:
Da die 20 Messungen durchaus disjunkt sein können (Ich will nicht jede Messreihe vorher im Einzelnen analysieren. Ziel ist es, beim Roboter einfach auf "lernen" zu drücken und dann 20x oder so die Bewegung zu simulieren), muss ich beliebige Mengen erkennen können, also brauche ich ein Netz der Tiefe 3. Dort hätte ich dann in der 1. Ebene meine Perceptrons (für jeden Testdatensatz genau 1) mit jeweils n gewichteten Eingangsgrößen (eben jeden Datenpunkt). Sobald eines von diesen Perceptrons feuert (2. Ebene), weiß ich, dass ich einen bekannten Signalverlauf gefunden habe, wenn keines feuert weiß ich, dass der Signalverlauf unbekannt / neu ist.
Die 3. Ebene brauche ich dafür, dass meine Datenpunkte nicht konvex / "zusammenhängend" sind - das Berücksichtige ich hier anscheinend nicht. Wo ist der Fehler?Und wie generiere ich mir negative Testdaten? Ich meinem Fall möchte ich erstmal nur sagen "Signalverlauf bekannt" oder eben "unbekannt". "Unbekannt" kann durchaus ein anderer, sinnvoller Signalverlauf sein, aber halt einer der momentan unbekannt ist, da er nicht gelernt wurde.
Meine Idee war einfach zufällige Testdaten zu generieren, aber die können ja durch den Zufall auch eigentlich passend sein.
Jemand eine Idee, wie ich an meine negativen Testdaten kommen?Viel Dank erstmal fürs Lesen der Textwand
Gruß
Pille456P.S: Wenn ihr nun der Meinung seit, dass das mit Perceptrons zu kompliziert ist, dann wäre ich um Gegenvorschläge froh. Aber irgendwie schreit das Problem der Wiedererkennung ja gerade nach einem neuronalen Netz...
-
Ich würde an Deiner Stelle zuerst etwas Einfacheres und Intuitiveres probieren. KNN werden imho häufig etwas überschätzt und leicht übertrainiert.
Schätzungsweise hast Du am Ende eine Reihe von Kurven die verschiedene Bewegungen darstellen: Kippen nach links, kinnen nach rechts, beschleunigen nach vorne, drehen um die Höhenachse, ...
Wie wäre es, aus den Abtastpunkten einfach die Summe der Fehlerquadrate zu allen bekannten Kurven nacheinander zu berechnen. Die Kurve, die die minimalste Fehlersumme ergab, repräsentiert dann die wahrscheinlichste Bewegung.
Danach kann das Verfahren immer noch verbessert werden.
-
Pille456 schrieb:
P.S: Wenn ihr nun der Meinung seit, dass das mit Perceptrons zu kompliziert ist, dann wäre ich um Gegenvorschläge froh. Aber irgendwie schreit das Problem der Wiedererkennung ja gerade nach einem neuronalen Netz...
µ schrieb:
Ich würde an Deiner Stelle zuerst etwas Einfacheres und Intuitiveres probieren. KNN werden imho häufig etwas überschätzt und leicht übertrainiert.
Ich schließe mich hier µ an. Künstliche Neuronale Netze werden oft als eine Art Wundermittel angesehen, dabei sollten sie eher als eine Art letztes Mittel angesehen werden.
Du solltest Dir klar machen, dass Du in ein KNN fast keine Modellierung des Anwendungsbereichs steckst. Das ist ein enormer Nachteil. Methoden, die mehr Informationen in Form von Modellen zur Verfügung haben, funktionieren besser.
Insofern sind KNNs DAS Mittel, wenn eine Modellierung des Anwendungsbereichs nicht möglich ist. Man überlässt die Modellierung damit praktisch dem Computer, der darin natürlich denkbar schlecht ist. Das musst Du so sehen: Bei einem KNN hast Du unglaublich viele Parameter (Gewichte), die Du durch den Lernvorgang bestimmen musst. Aber wenn Du den Problembereich gut modellierst, hast Du typischerweise wesentlich weniger Parameter. Dadurch gibt es weniger Probleme mit Overfitting und Underfitting und so weiter.
Klar, eine Modellierung der Mechanik eines Roboters ist aufwändig und man muss sicherlich einige Vereinfachungen machen. Aber ich würde davon ausgehen, dass Du damit besseres und verlässlicheres Verhalten des Roboters bekommen kannst.
Was für eine Art von Roboter ist das denn?
-
Du meinst einen nearest neighbour Algorithmus?
Daran hatte ich auch kurz gedacht, aber dabei war ich mir nicht sicher, wie gut der Algorithmus auf rauschen und das Problem mit den 5 Messpunkten innerhalb der ersten 10ms im 1. Verusch und dann später vielleicht nur 2 Messpunkte innerhalb der ersten 10 ms im 2. Versuch reagiert.
Generell wüsste ich hierbei nicht, wie die negativen Testdaten aussehen sollten. Soweit ich das sehe, könnte ich dabei wirklich nur z.B. 20 positive Testdaten nehmen und wenn der Abstand zu jedem diese 20 Testdaten größer als ein Grenzwert ist, ablehnen und ansonsten zustimmen.
Den Grenzwert müsste ich dann passend setzen z.B. aus der Streuung der positiven Testdaten.Edit:
Hi Gregor, hatte Deinen Post erst gerade gelesen, da sich unsere überschnitten hatten...
Also das Problem ist momentan folgendes:
Komponenten für einen Roboter sind recht teuer, daher nutze ich derzeit den Beschleunigungssensor meines Handys, sodass ich mich erstmal nur um die Programmierung kümmern muss und keinen Stress mit der Hardware habe. Daher kommt auch dieses realtiv unübersichtliche Verhalten der Messwerte, weil Android mir "igendwann" sagt, wenn der Sensor etwas gefunden hat.
Später geht es um eine allgemeinere Lageerkennung für fahrende Roboter. Die Idee war einfach nur anhand der Beschleunigungsmuster zu wissen, was dem Roboter gerade passiert ist und wo dieser sich befindet. Das heißt nicht nur seine Geschwindigkeit zu erfahren, sondern auch zu wissen, ob er irgendwo hängen geblieben ist, sich an seinem Fahrverhalten etwas geändert hat, ob er umgekippt ist usw...
Unter diesem Gesichtspunkt kann ich also relativ schwer eingrenzen wofür das nun genau benutzt wird.
Viele dieser Infos kann man sicherlich auch total anders abgreifen (und sollte man auch unbedingt! Es ist halt doof, die Wand erst dann zu erkennen, wenn man vor 2 Sek gegen sie gefahren ist..), aber die Idee ist ja gerade, eine maximale Menge an Informationen aus einer minimalen Anzahl an Sensoren herauszuziehen.
Vielleicht kann man das auch eher als ein proof of concept sehen, ich fand die Idee irgendwie cool zu sagen "hey ich habe erstmal nur 1 Sensor, finde damit aber schon X Dinge heraus", um dann später das Konzept auf mehrere Sensoren (evt. sogar kombinierten Daten) zu erweitern.Momentan arbeite ich daran mit dem Handy meine eigenen Schritte (sicher) zu erkennen. Das hat zwar nicht viel mit dem Roboter zu tun, aber war für mich erstmal die 1. Vereinfachung um mich an das Problem zu nähern und hat zumindest im Falle der Signalfilter gut geklappt
-
Pille456 schrieb:
Also das Problem ist momentan folgendes:
Komponenten für einen Roboter sind recht teuer, daher nutze ich derzeit den Beschleunigungssensor meines Handys, sodass ich mich erstmal nur um die Programmierung kümmern muss und keinen Stress mit der Hardware habe.1. Ja, weiß ich. Die Kosten für Komponenten können einem jeden Spaß an der Robotik nehmen.
Allerdings sind Beschleunigungssensoren durchaus noch im bezahlbaren Rahmen, finde ich. Guck mal da:...ok, aber der alleine ist es ja nicht. Das sehe ich ein.
2. Ich sehe nicht so ganz den Zusammenhang zu meinem Beitrag. Meinst Du, die Hardware ändert sich laufend, so dass eine physikalische Modellierung des Roboters sofort veraltet wäre?