Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Eigenbewegungsschätzung #59

Open
Phibedy opened this issue Apr 15, 2016 · 1 comment
Open

Eigenbewegungsschätzung #59

Phibedy opened this issue Apr 15, 2016 · 1 comment

Comments

@Phibedy
Copy link
Member

Phibedy commented Apr 15, 2016

@mherb
Copy link
Contributor

mherb commented May 4, 2016

Hier mal so als Sammlung was in der Eigenbewegungsschätzung sinnvolle Arbeitsbereiche sind:

  • Modell
    • Aktuelles Modell ist nicht auf Vorder- und Hinterachslenkung ausgelegt
    • Das Modell müsste dahingehend angepasst werden um dies zu berücksichtigen
    • Von besonderer Wichtigkeit dürfte die Einspeisung des Soll-Winkels von beiden Achsen im Prediction-Step sein
    • Bei der Gelegenheit kann/sollte man sich auch Gedanken machen wie man weitere Sensorik (zb Maus-Sensoren) sinnvoll integrieren kann
  • Umstellung auf 2D Affine Poses
    • Häufig stellt man relative Poses durch Transformations-Matrizen mit einer Rotations-Matrix und einem Translations-Vektor dar
    • Das hat den Vorteil, dass diese leicht verknüpft werden können durch einfache Matrix-Multiplikation, das was aufintegrieren von relativen Bewegung erleichtert
    • Außerdem ist es damit einfach einen Punkt (oder Vektor) von einem Koordinatensystem in ein anderes zu transformieren
    • Eigen3 hat dabei bereits einen Datentypen AffineCompact2f, allerdings kann man das auch selber implementieren wenn man darauf unbedingt Lust hat
  • Service (eher untergeordnete Priorität)
    • Prinzipiell wäre es praktisch wenn man über einen Service aus jedem Modul heraus die Fahrzeugposition erhalten könnte
    • Interessant ist dabei sowohl die globale Position (das müsste dann mittelfristig mit der Globalen Karte+Lokalisierung verknüpft werden) als auch die relative Position zwischen zwei Zeitpunkten
    • Der Service sollte dabei in der Lage sein (linear) zwischen zwei Filter-Zuständen zu interpolieren
    • Über den Timestamp Interpolator Service gibt es die Möglichkeit zwischen verschiedenen Zeitstempeln zu konvertieren
    • Eine sinnvolle "Master-Zeit" für die Ego-Schätzung ist dabei vermutlich die Elektronik-Zeit
  • Covariance-Tuning (eher niedrige Prio, aber interessantes Projekt)
    • Die Kovarianzen sind für die aktuellen Sensoren recht sinnvoll eingestellt, allerdings kann es durchaus sein, dass man da noch mehr rausholen kann
    • Eine Idee, wie man das Tuning automatisieren könnte ist der Einsatz von "Hyperparameter Optimierern" wie hyperopt (http://hyperopt.github.io/hyperopt/)
    • Diese sind in der Lage den Parameter-Space "intelligent" nach optimalen Parametern zu durchsuchen
    • Dabei wählt hyperopt eine Parameter-Konfiguration und man muss diese Kombination dann über eine Cost-Function evaluieren
    • Diese Evaluation müsste man automatisieren, d.h. wir müssten (automatisch) bestimmen können wie gut die Ego-Schätzung ist
    • Das könnte man durch die aufnahme eines Referenz-Pfads (oder Punktes) und die anschließende Berechnung der Abweichung der Schätzung vom Referenzpunkt umsetzen
  • Umstellung auf neues Kalman-API (Low Prio)
    • Es wird (hoffentlich) bald ein überarbeitetes API für die Kalman-API geben, die noch toller und flexibler ist ;)
  • Überlegung: Ego-Estimation auf Elektronik (Low Prio)
    • Mit der neuen Kalman-API könnte man überlegen die Ego-Schätzung auch auf die Elektronik zu verlagern und dort gleich mit wesentlich höhrer Frequenz (~1kHz) zu filtern
    • Es würden dann nur die gefilterten Daten an die Software geschickt, allerdings muss dann das Filtering auf der Elektronik sehr gut funktionieren

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants