Mapping mit Dashcams

Nur mal zum Vergleich, welche ARbeit man sich “bei längerer Brennweite” vielleicht ersparen kann:
8mm zu 2,4mm Brennweite (auf den üblichen 1/4" Sensor wie in Gopro&Co verbaut)

8mm Brennweite, Uhrzeiten stimmen alle nicht…

gleiche Position mit der Standardoptik der PanoramaII (leicher Fokus-Fehler, gebe ich zu, muss ich justieren)

Oder ähnlicher Bildbeschnitt, also näher drangefahren:

Ich habe mal zur Abschätzung, was in Wohngebieten, in Kerngebieten, Gewerbegebieten und auf Schnellstraßen geht jeweils ca 15min-Segmente zu Youtube gebeamt. Und Aufnahmen simultan in 2,4mm (Weitwinkel) und 8mm(Tele) Brennweite.
Youtube rekodiert die Video und sorgt dabei für reichlich Artefakte. Originale (jeweils rund 1,5GB) kann ich gern per FTP/http zur Verfügung stellen.

Bei Tag, sonnig, teilweise Gegenlicht und schnelle Lichtwechsel.
Weitwinkel: http://youtu.be/dRh4FP7NR8I
Tele: http://youtu.be/OMiiujjgHw4

Bei Nacht, teils unbeleuchtete Straßen
Weitwinkel: http://youtu.be/vB1LC_ZAbN8
Tele: http://youtu.be/xqORBChWEHA

bei zunehmender Dämmerung inkl. gut beleuchteter Tiefgarage
Weitwinkel: http://youtu.be/fPViz6YPVTk
Tele: http://youtu.be/RtDT1YfSFzg

Hallo jha, was die Vorzüge von Normal- oder Teleobjektiven betrifft würde ich dir inzwischen völlig zustimmen. Fällt dir spontan ein Gerät mit integriertem GPS-Empfänger ein? Ich befürchte, dass beim händischen Zusammenführen von GPS- und Videodaten der Kreis an Menschen deutlich schrumpft, die zu Datenerhebung in Frage kommen. Eine Kalibrierung mit OpenCV habe ich mal probiert, aber bis jetzt keine brauchbaren Ergebnisse bekommen. Ich denke aber dass sich da noch etwas ergibt.

Ich lade zur Zeit ca. 80 GB / 10 h Videomaterial auf Amazon S3 hoch, um anschließend die Auswertung mit CUDA beschleunigt auf den GPU-Instanzen von AWS durchzuführen. Der Haken an der Sache ist derzeit, dass ich bis jetzt in Python entwickelt habe, die CUDA-beschleunigten Funktionen aber in der API fehlen. Wir versuchen das gerade zu ergänzen.

Es gibt inzwischen alle brauchbaren Kameras sowohl mit wie auch ohne GPS-Empfänger.

Was ärgerlich ist: Jeder Hersteller braut da derzeit noch einen eigenen Standard, wo sich die Koordinateninfos verstecken.
Also abgesehen davon, dass man die Koordinaten bei einem Teil der Kameras ins Videobild “einstempeln” lassen kann:
Die Koordinaten landen entweder als separates NMEA oder GPX im Verzeichnis, oder in einem anderen.
Oder als Textdatei in einem CSV-Derivat.
Gern auch mal mit Dateienamen ohne erkennbaren Zusammenhang zur Videodatei (Matching muss dann anhand des Dateidatum/Uhrzeit der Dateien gemacht werden. Was bie der Videodatei ja sowieso fällig ist, weil dort ja nur sonst keine Zeitinfo vorhanden ist.)
Ach ja, manche Dashcam setzen den Timestamp des Videofiles auf “Aufnahmebeginn”, andere auf “Ende”. Und natürlich immer mit 1-3 Sekunden Offset.
Und dann gibt es die Kameras, die die Koordinaten direkt ins Videofile (hinter das “Video-Dateiende”) schreiben, mehr oder minder Binary.

A propos Offset: Den gibt es natürlich zusätzlich auch selbst bei “GPS im Videobild”. Wahlweise ist der Empfänger langsamer. Teilweise ist der Videocodec “langsamer” dank diverser Fifo-Buffer…
Sprich: Wenn man nicht auf den “RegistratorViewer” von Datakam zurückgreift (der das alles mundfein in GPX/NMEA und .SRT(Video-Untertiteldateien für Youtube&Co)) wandelt: Man muss es für jede Kamera erstmal austüfteln. Und dann hoffen dass sich bei einer neuen Firmware nichts allzuviel ändert (was auch passiert, gerade bei den besseren Kameras, bei denen dann noch deutliche Verbesserungen erfolgen. Aber leider eben auch mit Seiteneffekten wie “jetzt nur noch 1s Offset”)

jha, nenn doch mal konkrete Beispiele mit Endlosaufnahme, Full-HD, GPS, und Unterstützung 128-GB-SD-Karten. (und kein Gebastel)

Die Situation mit den GPS-Daten ist unschön. Der RegistratorViewer für Automatisierung nicht brauchbar. Wir haben die GPS-Daten aber den Aufnahmen der Panorama II extrahieren können, ich denke wir werden das auch für andere Modelle hinbekommen.

Ich habe in den letzten Tagen die Auswertung zu Amazon Web Services portiert. Ich hatte ja oben schon erwähnt, dass die Auswertung auf meinem Notebook sehr langsam ist, ca. 5 Frames/s. Mit CUDA dauert die Auswertung eines 30-Minuten-Clips jetzt 15 Minuten, also 60 Frames/s. Dazu kommt, dass man mehrere Instanzen parallel starten kann. Das ist für’s erste akzeptabel.

Ich werde jetzt eine kleine Web-Anwendung schreiben, mit der man Videos hochladen und die Ergebnisse der Auswertung anschauen kann.

Psst…Datenschutz! Macht wenigstens die Autokennzeichen unkenntlich.

gormo: Jajaja.

Der Code liegt übrigens bei Github. Zur Zeit ist das eine ungeordnete Ansammlung an Dateien, bei denen selbst ich den Überblick verliere. Ich werde ihn aber vereinheitlichen, dokumentieren und unter der Apache License 2.0 veröffentlichen, die Aufnahmen voraussichtlich als CC BY 4.0.

https://github.com/christophe-de/osm-dashcam

Den Code würde ich gerne mal ausprobieren und auf meine Raspberry Pi Bilder loslassen. Was braucht man denn, um den zum laufen zu bringen? Hat der schon CUDA drin?

An Hardware könnte ich einen etwas älteren Laptop mit Intel Core i7 Q720 und Geforce GT240M und einen Rechner mit Xeon E31220 und Tesla C2075 nutzen, beide haben Ubuntu (ersterer 14.04, zweiterer noch 12.04) und CUDA.

Ach ja, ich schätze, man muss den Code auch trainieren, wenn man Verkehrsschilder finden möchte, auf die er noch nicht trainiert ist? Die Geschwindigkeitsbegrenzungen sehen ja in Estland genau so aus wie in Deutschland, aber jetzt habe ich z.B. auch Bilder in Finnland geschossen und da ist der “weiße” Teil gelb. Ein paar Höhenbeschränkungen sind auch dabei (gleiche Farbe), außerdem z.B. Straßennummern.

„Das BayLDA wird in Zukunft, wenn bekannt wird, dass Autofahrer die mit ihrer Dashcam aufgenommenen Videofilme an Polizei, Versicherung oder ähnliche weitergeben oder im Internet veröffentlichten, prüfen, ob im jeweils konkreten Fall der Erlass eines Bußgeldbescheides angezeigt ist. Der gesetzlich festgelegte Bußgeldrahmen für derartige Verstöße beläuft sich auf bis zu 300.000 EUR.“ Quelle

Ich habe hier auch einen echten Brief von 2009 von einem Forstamt in dem man mir mit “Prüfung” gedroht wurde.
http://i.imgur.com/EpwDj0K.png

GEO-Catching :smiley:

Das muß so ein neuer Trend sein - muß ich unbedingt auch mal versuchen.

Auf Seiten der Executive heißt das “geo-bashing” :smiley:

Das aktuelle, nicht rechtskräftige Dashcam-Urteil des VGH in Ansbach/Bayern sagt

Inzwischen bin ich mit den vom Raspberry Pi gemachten Bildern ganz zufrieden - so sieht das Ergebnis aus:
http://www.mapillary.com/profile/mhohmann
Zum automatischen Aufnehmen habe ich einen kleinen Python-Skript gebastelt:
http://wiki.openstreetmap.org/wiki/User:MHohmann/RPiCam

Hast du die Möglichkeit die Videos bei Amazon S3 hochzuladen? Hier am Fachbereich geht das mit ca. 10 MB/s, das ist ganz praktikabel.

Videos habe ich derzeit nicht, sondern Foto-Sequenzen mit einem Abstand von einer Sekunde zwischen zwei Photos (die ich aber natürlich per Software zu einer Videodatei konvertieren könnte, falls das von Vorteil ist). Ich habe mal einen Blick auf Amazon S3 geworfen, so weit ich das sehe sind da bis 5GB Speicher kostenlos? Meine Daten sind da etwas größer, eine Fahrt von Tartu nach Tallinn hat um die 17GB, man könnte es also erst einmal mit einem kleineren Teil versuchen. Registriert habe ich mich dort noch nicht - falls möglich würde ich es erst einmal lokal auf meinem Rechner testen (oder einem der GPU-Uni-Rechner), wenn die Installation von OpenCV nicht zu aufwändig ist. Ubuntu 14.04 hat OpenCV 2.4.8 in den Repositories, ich habe mich schon mal ein wenig in die Dokumentation eingelesen.

Upload-Speed wäre kein Problem, von zu Hause kann ich mit 5MB/s hochladen, vom Institut ungefähr 40-60MB/s (Gigabit-Anbindung).

Fotos sind prinzipiell kein Problem. Was die Performance betrifft wird das sogar deutlich schneller werden. Ich analysiere derzeit lediglich jedes Frame, weil die Schilder bei hohen Geschwindigkeiten nur sehr kurz gut zu erkennen sind. Das liegt aber am großen Bildwinkel der Dashcam. Ich überlege mir eine GoPro Hero 3+ silver oder black zu kaufen, da kann man den Bildwinkel verstellen und sie kann 2-10 Bilder/s aufnehmen. Aber das nur am Rande.

Wie schwer es ist meinen Code bei dir zum Laufen zu bringen, kann ihr ehrlich gesagt nicht einschätzen. Ich habe mich für OpenCV 3 entschieden und kompiliere aus git selbst. Weißt du, ob die Pakete aus dem Repository CUDA unterstützen? CUDA ist leider proprietär. Wie groß die Unterschiede zwischen den beiden OpenCV-Versionen sind, weiß ich auch nicht. Die “Anwendung” selbst ist eine Mischung aus Python und C++. Mit Python hatte ich angefangen, da funktioniert aber das CUDA nicht, dafür gibt es eine Bibliothek für die Dienste von Amazon. Mit C++ mache ich nur noch die Klassifizierung.

Für deine Daten kannst du aber auch einfach meinen S3-Bucket mitnutzen. Ich benutze das “Reduced Redundancy Storage”, das kostet 2 Euro pro 100 GB im Monat. Das ist wirklich kein Problem. Ich habe schon knapp 150 GB an Daten.

Ich werde mich am Wochenende mit einer Freundin um eine Oberfläche für die Auswertung und das Training des Klassifizierers kümmern. Ich hoffe ihr seid gespannt.

Gut, in Sachen Bildwinkel ist der bei der RPi-Cam eigentlich recht brauchbar, um auch bei einem Bild pro Sekunde und einer Autobahnfahrt noch 1-3 gute Bilder zu bekommen, auf denen man ein Verkehrsschild gut erkennen kann, zumindest manuell. Wie gut es OpenCV dann erkennt, werden wir sehen. Ich hatte dieses Aufnahmeintervall vor allem deshalb drin, weil die GPS-Positionen von gpsd im gleichen Takt kommen, so muss ich nicht interpolieren.

Die OpenCV-Pakete aus dem Ubuntu-Repository haben ein Paket libopencv-gpu2.4 dabei - ich nehme mal an, dass das der Teil der Bibliothek ist, der CUDA nutzt. Ausprobiert habe ich es allerdings noch nicht. Bisher habe ich CUDA (und OpenCL) nur für selbst programmierten GPU-Code benutzt, aber noch keine fertigen GPU-beschleunigten Bibliotheken.

Auf die Ergebnisse des Wochenendes bin ich tatsächlich schon gespannt :slight_smile: Wenn ich die Dokumentation richtig verstanden habe, braucht man zum Training einen Haufen Bilder (typische Fotos) ohne Verkehrsschilder sowie ein Bild (Zeichnung) von jedem Verkehrsschild, dass man erkennen will. Zum Training selbst erzeugt die Software dann positiv-Bilder, indem jedes Verkehrsschild in mehr oder weniger gedrehter oder verzerrter Weise in einen Hintergrund ohne Verkehrsschild eingebaut wird, und lässt dann den Classifier darauf los. Stimmt das so weit?

Also OpenCV wirst du dir wahrscheinlich selbst kompilieren müssen. Das Paket hat vermutlich keine volle Funktion:

WITH_CUDA=OFF
http://anonscm.debian.org/cgit/debian-science/packages/opencv.git/tree/debian/rules

To enable CUDA support, configure OpenCV using CMake with WITH_CUDA=ON . When the flag is set and if CUDA is installed, the full-featured OpenCV GPU module is built.
http://docs.opencv.org/modules/gpu/doc/introduction.html

Den Classifier habe ich direkt mit Samples trainiert. Das Freistellen wäre mehr Arbeit gewesen als einfach mehr Schilder zu markieren. Eine Webapp, mit der man das im Browser machen kann ist in Arbeit. Das generieren von Positiv-Samples ist für den Fall gedacht, in dem man beispielsweise nur ein Logo hat, das man in vielen (unbekannten) Aufnahmen erkennen möchte.