moin!
Danke für eure Beiträge!
also das Ziel ist ja, wenn z.B. alle ca. 20ms eine neue Gruppe von 3 Sensoren (oder 4,5,6 oder7) je 1 neuen Messwert poduziert, dass man aus den 3er- (4er, 5er,...)-Gruppen schnell einen brauchbaren Wert erhält,mit dem man eine Abschätzung der tatsächlichen Entfernung enhält, die wahrscheinlih näher am echten Wert liegt als jeder Einzelwert für sich betrachtet.
@Holomino
Wenn diese (beispielhaft) drei Werte jetzt im Messbereich über eine Distand von 30cm verteilt sind (oder mehr, oder weniger), dann macht es doch einen Riesen-Aufwand, hier in 1cm-Schritten e-Funktionen auf jedem Zwischenpunkt aufzusetzen, dort mit den Sensorwerten durchzurechnen (die Rechnung wurde ja leider noch gar nicht genannt) per "hypthetic Distance", um dann nachzusehen, um dann anschließend das Maximum dieser 30 Werte (oder mehr, oder weniger) für "Eq." zu suchen.
@Moppi:
dass der gesuchte Wert irgendwo im Intervall zwischen min und max liegen muss, ist ja klar, und zwar vermutlich auch näher am Wert des zuverlässigsten Sensors, aber wie programmierst du es, dass er das Optimum der Vorhersage, das irgendwo in der Nähe liegen mag, wirklich findet? Und wie machst du es, wenn du 2 oder 3 sehr zuverlässige Sensoren hast mit divergenten Werten, und noch 5 oder 6 weniger zuverlässige zusätzlich?
Die Fälle 1+2 im TOP Beispiel waren ja nur idealisierte, vereinfachte Anschauungsbeispiele. Tatsächlich sind solche Probleme aber statistisch lösbar, der Kalmanfilter oder die Monte-Carlo-Methode sind nur 2 Beispiele für Lösungsalgorithmen, allerdings rechnerisch recht aufwändig, andere wären Quadratur-Filter, Gaußsummenfilter oder Projektionsfilter. Um solche Filter (allerdings vereinfachte Algorithmen) geht es hier.
Schaut man sich jetzt das Ergebnis "93" von Holomino an, bin ich mir schon sehr sicher, dass es die Realität sehr gut treffen wird, denn ich arbeite hier ja wahrscheinlich mit den Gauss Glockenkurven (auch wenn in Holominos Post keine Formel genannt wurde) und nicht mit einfachen gewichteten arithmetischen Durchschnitten.
@Holomino: meinst du Dichtefunktion und Verteilungsfunktion und Fehlerfunktion hintereinander ausgeführt?
https://wikimedia.org/api/rest_v1/me...e029134a113f34
https://wikimedia.org/api/rest_v1/me...24dd4d174502d5
https://wikimedia.org/api/rest_v1/me...3400a445ca4e4f
Bei den gewichteten Durchschnitten, die ich oben nach manfs Link per einfacher Addition, Multiplikation und Division ausgerechnet habe, kam ich auf 97, das ist nach Holominos Tabelle nach 4 Rechen-Zeilen um ca. 4% schlechter.
https://www.roboternetz.de/community...l=1#post646322
@Holomino
Zunächst: Leider fehlt bei dir noch Fall 2 zum Vergleich, das könnte noch hilfreich sein.
Die Frage ist nun aber, lohnt sich der Aufwand, hier dutzende e-Funktionen an verschiedenen theoretischen Punkten aufzusetzen und durchzurechnen,
und das alle 20ms, also 50x pro Sekunde,
schafft das ein Arduino auch sicher, und hat er noch Zeit dann für andere Dinge, z.B. die Weiterverarbeitung dieser Daten und die Ortung und Navigation etc.?
Wie schätzt du selber den relativen Aufwand deiner Methode ein, lohnt sich der Aufwand deiner Meinung nach?
- Oder empfiehlt sich anstelle des "Kehrwerts der relat.Standardabweichung" ein anderer Faktor, um den gewichteten Durchschnitt anders und besser zu gewichten?
Du, Holomino, hattest ja einen anderen Kehrwert als diesen angesprochen, welchen meintest du denn seinerzeit? (Die Frage war ja noch offen)
- - - Aktualisiert - - -
nochmal @ moppi:
die Liste
1. Messung: 100cm, Fehler: +/-20%
2. Messung: 110cm, Fehler: +/-10%
3. Messung: 90cm, Fehler: +/-5%
heißt ja nicht, dass die Messwerte IMMER innerhalb dieser Grenzen liegen müssen, es ist nur ein gewisses Wahscheinlichkeitsniveau (68%), dass das so ist.
Jeder dritte Wert (32%) liegt statistisch also immer außerhalb dieser Standardabweichung, das sind bei 50 messungen pro Sekunde für jeden Sensor immerhin 15-20 Messungen, die regelmäßig, statistisch betrachtet, stärker abweichen (teilw. auch extremer), und das tun sie statistisch völlig regelrecht (Glockenkurve), das wären dann also noch nicht einmal statistische "Ausreißer" . Bei der statistischen Auswertung darf man sich daher nicht auf diesen nur scheinbar engen Fehlerbereich beschränken.