Hallo, ich plane im Rahmen einer Diplomarbeit eine Verkehrsschilderkennung zu entwickeln. Da es da ja schon gibt wäre es aus meiner Sicht gut ein Gesamtsystem zusammenzustellen. Ich dachte an 2 Kamnera für Stereo-Vison, Einspeisung von Daten auf den CAN-Bus sowie die Möglichkeit zur guten Softwaremäßigen Erweiterung. Die Frage stellt sich nach dem Controller/DSP/Prozessor der für solche Anwendungen geeignet ist, da es sich ja teilweise um rechenintensive Aufgaben handelt. Das ganz sollte am Ende in einem Auto mitführbar sein. Ich bin mir nicht ganz sicher ob ich mich mit dem Thema übernehme und es zunächst alles auf dem PC, zB in Matlab, testen sollte. Wobei mir eine Programmierung gleich in C/C++ am liebten wäre. Am besten geeignet wäre dann sicher ein Evaluation Board. Für die Kameras brauche ich Ethernet oder USB. Bin auf die Reihe "Blackfin" von Analog Device gestoßen. Da gibt es zwar Boards für unter 300€, allerdings ist die Softwareumgebung mit 3500€ nicht gerade ein Schnäppchen. Was meint Ihr? Welche Erfahrungen habt Ihr? Grüße Johannes
Hallo Johannes, das geht alles auch viel billiger, wenn man gewillt ist, sich mit der GNU-Toolchain (gcc, binutils) abzugeben. Meiner Meinung nach ist diese fuer den Blackfin inzwischen die bessere Wahl, die uClinux-Division von Analog Devices hat in den letzten Jahren excellente Arbeit geleistet. Wir haben hier inzwischen einige Kameraprojekte mit dem Blackfin 537 erschlagen, teils auch unter uClinux, um bestehende Programme 1:1 uebernehmen zu koennen. Mit der Toolchain kann man allerdings auch prima "standalone"-Systeme entwickeln, allerdings ist es schon etwas mit Arbeit behaftet, von Bilderfassung ueber Verarbeitung bis Versand per TCP oder UDP alles selbst zu machen. Ich verrate mal meine potentielle 'shopping list': - GNU tools: blackfin.uclinux.org - Debugger/Flasher: www.section5.ch/icebear (dort gibt's auch DEBIAN pakete und Beispielcode fuer "standalone"-Anwendungen) - Stereo-Kameraboard von Bluetechnix (www.tinyboards.com) Fuer eine "Billigloesung" sind die Omnivision-Sensoren (auf dem Bluetechnix-Kit) ganz gut geeignet, bringen aber fuer ein echtes Produkt meistens nicht die erforderliche Qualitaet. Hoffe, das hilft dir weiter, Gruss, - Strubi
Guuut, da hast Du Dir ja ein mächtiges Thema ausgewählt! 1) Stereo Vision ist SEHR aufwändig und für eine Symbolerkennung eher sinnlos. 2) für Bildverarbeitung benötigtst Du einiges an Rechenleistung und etwas Speicher. Versuch's mal mit BMP (leicht auszulesen) und einer Hochspache Deiner Wahl. Ich bearbeite selbst ein selbstgewähltes Diplomarbeitsthema (mit Video & FPGA & Controller) - es artet eher aus. Mein Tipp: nimm eher ein Thema, das ein Institut Deiner Wahl vorschlägt, die haben dann auch mehr Interesse daran, Dir bei Problemen zu helfen. Vorallem ist dabei das Thema weitgehend abgesteckt und überschaubar. Sollte ich nochmal vor die Wahl eines Diplomarbeitsthemas gestellt werden, würd ich kein selbsterfundenes Thema mehr nehmen. ---------------------------------- wer Rechtschreibfehler findet, darf sie behalten, Inhaltliche Fehler nehme ich gerne zurück
Hi, ich kann auch nur den Blackfin empfehlen. Schau mal auf der Analog Devices Seite nach, bevor ich meine letzte Firma verlassen habe, hat ein Sales Ingeneur von denen uns eine Neue Variante gezeigt, die direkt einen schönen Video-Eingang und noch ein paar nette IO-Komponenten hat. Weiß leider den Typ nicht mehr genau. Vom Preis/Leistungsverhältnis sind die Blackfin derzeit unschlagbar wenns auf Rechenpower ankommt und die brauchst Du für Bildverarbeitung. Wir haben damit Gesichtsfindung gemacht. Gruß Thomas
@Strubi, danke für die Links und Hinweise. Werde ich mir ansehen. OpenSource wäre mir persönlich auch am liebsten. Ist es richtig dass es dann eine Freie Entwickluingsumgebung gibt, ich mir den Quellecode für den Blackfin kompilieren und ihn dann flashen kann? Oder gibt es gar eine Art Betriebssystem für den Blackfin. @GagoSoft: Das Thema was mir vorgeschlagen wurde war die Schilderkennung und eventuell eine Einspeisung der Ergebnisse in den CAN-Bus. Ich bin auf dem Feld der Bildverarbeitung noch nicht sehr weit, denke aber es gibt schon Lösungen für diese Probleme der Erkkenung, d.h. irgendwelche Bibliotheken. Deswegen dachte ich mach ich noch etwas drum herum. Das kann natürlich schnell ausarten, deswegen wollte ich mich hier mal informieren. Ich habe noch 1-2Monate Zeit um mich auf das Thema festzulegen und mich mit der ganzen Problematik zu beschäftigen. @ Thomas Burkhart: Ja, ich denke der Blackfin ist geeignet und auch recht günstig für die Uni im Erwerb. Es sollen ja eventuell ja auch weitere Projekte damit realisiert werden können. z.B. Fahrspurerkennung etc. Wie groß würdet Ihr zunächste den Aufwand einschätzen, Daten von einer Kamera (zB Webacm) auf den Blacfin zu bekommen um diese dann auszuwerten? Grüße
Nimm am besten keine Webcam, sonst musst Du dich noch mit USB rumschlagen. Nimm ne Analoge Videocamera (PAL, schwarz/weis) mehr Auflösung wirst Du nicht brauchen für Verkehrsschilder. Der Blackfinn den ich meine hat direkt einen Analogen Videoport, von dem die Daten per DMA in den Speicher befördert werden können. Falls Du an eine Digitalkamera (CMOS) kommst, bei der Du direkt das Sensorinterface rausgeführt bekommst, noch besser, da musst Du dann nur auf H- und V-SYNCS reagieren, damit due die reinkommenden Daten richtig im Speicher sortieren kannst. Der Blackfinn hat dazu übrigens ne ziemlich genial zweidimensionale DMA-Engine. Gruß Thomas
Hallo Ich hatte als Masterabschlussarbeit ein ähnliches Thema. Erkennung von Bewegungen mittels einer Videokamera Dies sollte auch auf einem DSP laufen (Blackfin). Wir haben aber dann erst mal ne simulation in C++ bzw. Matlab gemacht. Das würde ich dir auch empfehlen, da man sich dann nicht so stark mit Hardwareproblemen und so weiter rumschlagen muss. Auch kann man fertige Bibliotheken von Mathlab in C++ einzubinden um etwas zu testen. Ich kam dann nie dazu das in nen DSP umzusetzen, da es bis zum Ende nur bedingt auf dem PC mit Matlabfunktionen lief. Das größte Problem ist die Erkennung von Symbolen (Pattern) im Bild. Im Auto noch viel viel schwieriger als im Raum, wo die Lichtverhältnisse relativ konstant sind. An solchen Sachen arbeiten große Firmen und selbst die haben keine 100% Trefferquote. Also als Thema ist es recht interesant, da man viel über Bildverarbeitung lernt. Aber erwarte nicht zu viel von den Ergebnissen. Am Ende wirst du froh sein, wenn er zwischen Schildern und Menschen unterscheiden kann/könnte :-)
@ Daniel Freiberufler: Die Befürchtung, dass es zu vielen Problemen kommen wird, hatte ich auch schon. Ich bin auch ein absoluter Neuling in Sachen Bildverarbeitung. Dazu kommt, dass das Thema Bildverarbeitung hier am Lehrstuhl noch ziemlich neu ist und es eigentlich noch keine Arbeiten dazu gibt. Auch kann ich es zeitlich schwer abschätzen was ich alleine in 6Montaten (eventuell +2) schaffen kann. Ich hab zwar Erfahrung mit Matlab, C und Mikrocontrollern, aber das hilft mir bei der Bildverarbeitung auch erstmal nicht:) Ich lese jetzt schon nebenher Bücher zu dem Thema, um einen Einstieg zu bekommen. Wie lange hattest Du Zeit für Deinen Master und was hattest Du für Vorkenntnisse? Grüße Johannes
Hi Johannes, > OpenSource wäre > mir persönlich auch am liebsten. Ist es richtig dass es dann eine Freie > Entwickluingsumgebung gibt, ich mir den Quellecode für den Blackfin > kompilieren und ihn dann flashen kann? Oder gibt es gar eine Art > Betriebssystem für den Blackfin. Ja, da gibt es einige, haengt halt immer davon ab, was man machen will. Besagtes uClinux ist eine minimal abgespeckte Linux-Variante, die für den Blackfin von Haus aus schon Bilderfassung von diversen Digitalsensoren beinhaltet. Der sog. PPI kann, wie schon Thomas erwaehnt hat, Bilder von vielen Digitalsensoren ohne Zusatzlogik einziehen (getestet haben wir das mit Omnivision, Micron und einem Custom-Sensor), dabei nimmt einem die DMA-Engine den ganzen Overhead ab. Wenn's analoge CCD-Sensoren sein muessen, muss man halt noch einen Codec-Chip einbinden (wie auf den Blackfin-EZKITs vorhanden). Die Entwicklungsumgebung ist komplett frei, man kann sie bei section5.ch als Debian-Pakete runterladen oder sich von blackfin.uclinux.org selbst kompilieren. Es gibt dort auch eine Windows-Version, allerdings kann man mit dieser kein uClinux-Kernel compilieren (Windows-Dateinamen-Restriktionen). Da das Thema doch fuer eine 6monatige Arbeit verflucht komplex ist, wuerde ich moeglichst funktionierende Komponenten verwenden und das ganze unter einem Linux-System mit GCC entwickeln. Spaeter laesst sich das ganze dann, wenn die Algorithmen funktionieren, prima auf das Embedded System uebertragen - zumindest hatte ich damals das Glueck, dass der Algorithmus auf Anhieb lief. Fraglich, ob uClinux dann die erforderlichen Latenzzeiten abdeckt, dazu gibts aber wiederum Erweiterungen wie Xenomai, usw. Im Automotive-Bereich wird wohl auch RTEMS eingesetzt. Gruss, - Strubi
@Strubi: danke für die Infos und die realistische Einschätzung. Also wenn ich das richtig verstehe wäre es wohl das beste, sich ein paar Bilder herzunehmen (aus dem Verkehr). Dann wird die Hauptaufgabe sein eine Mustererkennung zu implementieren. Das alles unter Linux und mit GCC. Sollte das funktionieren und vielleicht schneller als erwartet, könnte man die Sache ja noch auf den DSP ausweiten. In Matlab gab es die schöne Funktion "imread()", mit der man aus einem Bild die entsprechende Matrix mit den Farbwerten in Matlab hatte. Sowas gibt ja bestimmt auch für den GCC, oder? Grüße
Bist du sicher dass das in eine Diplomarbeit passt, Entwicklung eines Algorithmus UND Implementierung in Hardware? Die Implementierung auf einem PC und einem Festkomma-DSP ist sehr unterschiedlich, mit neu kompilieren ist es nicht getan, eher mit neu schreiben: du hast andere Zahlenformate, DSP-Bibliotheken, IO-Anforderungen. Ich würde die Simulation deshalb erst mal so einfach wie möglich machen, d.h. mit Matlab.
@Johannes: Ich denke das ist die beste Herangehensweise. Erst mal auf dem PC zum Laufen zu bringen. Was die Portierung auf einen Fixkomma DSP angeht bin ich nicht ganz so pessimistisch. Wenn Du die Fließkommawerte in deinem Algorithmus zwischen -0.9999 und +1.0 halten kannst, was ofte der Fall ist, dann gibts beim Blackfin den praktischen Datentyp Fract, der kümmert sich um die richtige abarbeitung des Fließkommawertes ohne Performanceeinbußen. Aber wie gesagt, erst mal den Algorithmus zum Laufen bringen. An dieser Stelle sei mal auf den Lehrstuhl für Bildverarbeitung der Uni-Jena verwiesen, die haben eine ziemlich mächtige freie Bildverarbeitungsbibliothek, die Du einfach runterladen kannst. Gruß Thomas
Hi Johannes, > In Matlab gab es die schöne Funktion "imread()", mit der man aus einem > Bild die entsprechende Matrix mit den Farbwerten in Matlab hatte. Sowas > gibt ja bestimmt auch für den GCC, oder? Ich persoenlich bin kein Fan von Matlab, teste Algorithmen lieber in C aus, heisst aber, man muss eine gute Library zusammenhaben, wenn man nicht jedesmal das Rad neuerfinden will. Damit waeren wir beim Stichwort: sowas wie imread() gibt's nicht in den Standard-Libraries, man hat da viel mehr Freiheiten in der Wahl. Da gibts die libpng, die libjpeg, oder div. BMP reader, um Bilder einzulesen. Eine ganz tolle Alternative zu Matlab finde ich Python. Inzwischen gibts da eine Menge numerischer Bibliotheken (siehe auch Python Imaging Library 'PIL'), so dass man damit wunderbar maechtig prototypen kann. Wenn's einem dann noch zu langsam ist, kann man Python-Module in C portieren und hat damit die uebliche Geschwindigkeit, muss sich aber um die Verwaltung von Image-Objekten, usw. nicht kuemmern. Zum Thema Fliesskomma: Das ist naemlich ein grosser Knackpunkt bei den Blackfins: Keine Floating-Point-Unit. Der Grund ist, dass die Dinger auf Stromsparsamkeit und Bild/Audio-Verarbeitung ausgelegt sind, nicht unbedingt auf numerische Berechnungen. Darum wuerde ich nach Moeglichkeit versuchen, keine Float-Berechnungen zu machen, die sind zwar auf dem Linux-PC schnell und "easy", aber brauchen dafuer auf dem Blackfin richtig Zyklen - und sind meist unnoetig. Das heisst natuerlich, dass man seine Arithmetik genau unter Kontrolle haben muss, also Ueberlaeufe und Vorzeichenbehaftung im Griff hat. Gibt dazu aber wiederum eine ganz brauchbare DSP library (libbfdsp) - ist bei der GNU-Distribution zum blackfin mit dabei. Und der Blackfin-Assembler ist notfalls leicht zu lernen, wenns ans Optimieren ginge. Hoffe, das hilft dir bei dem komplexen Thema weiter. Gruss, - Strubi
Also ich hatte 6 Monate Zeit. Von Bildverarbeitung hatte ich fast keine Ahnung. Höchstens Grundkenntnisse. Eigentlich sollte ich auch nur ein bestehendes Projekt in einen DSP umsetzten. Es bestand schon eine Vorarbeit (Diplomarbeit meines Vorgängers). Allerdings war dieses Verfahren nicht brauchbar und so hat sich mein Thema geändert und ich musste den Algorithmus überarbeiten. Hätte ich neu begonnen, hätte es genauso lange gedauert Die Zeit war bei Weitem nicht ausreichend um den Algorithmus auch noch in nen DSP zu packen. Ich hatte zwar bei der Progammierung schon darauf geachtet mit Fixedpoint zu rechnen usw. Aber Kameraschnittstelle usw. denke ich ist auch einiges an Arbeit. Ich muss allerdings dazu sagen, das ich auch nur 3 Punkte im Bild finden musste und dann aus diesen 3 Punkten eine Bewegung berechnen musste. Das ist um einige Faktoren einfacher als das was du vorhast. Ich will dich nicht demotivieren, da ich nicht einschätzen kann, was du so drauf hast, aber das ist schon eine sehr sehr schwierige Aufgabe. In 6 Monaten eigentlich nicht zu schaffen. Größere Firmen arbeiten auch an diesen Themen. Aber wirklich brauchbare Systeme gibt es noch nicht. Und an diesen Systemen haben Spezialisten Jahre gearbeitet.
Na,, na, na, wer wird denn so persimistisch sein. Das bloße Auffinden der Schilder sollte nicht so schwer sein, sind ja ziemlich definierte Formen. Also eher Standardaufgabe der Bildverarbeitung. Was es noch nicht gibt und was wirklich schwer ist, diese in den Kontext eines fahrenden Autos zu setzen, d.h. für wen gelten die Schilder jetzt und ähnliches. Also lass Dich nicht entmutigen und such Dir am besten eine Bilbliothek, die schon viele passende Funktionen hat. Mit Python würde ich hier gar nicht erst anfangen. Wie gesagt Uni-Jena hat eine C++ Bibliothek. Alternativ kannst Du versuchen von der Firma MVTEC eine Studielizenz für deren Bildverabeitungssystem Halcon zu bekommen. Haben wir in unserer Firma eingesetzt, ist extrem mächtig und hat ein Scriptinterface mit dem man schnell mal Funktionen ausprobieren kann. Wenns damit läuft kannst DU die verwendeten Operationen immer noch in C implementieren. Wäre wohl der schnelllste Weg. Mathlab würde ich auch nur empfehlen wenn Du wirklich ganz neue Algorithmen entwickeln willst. Für klassiche Bildverarbeitung gibst besseres. gruß Thomas
Als Alternative zu der C++ Bibliothek aus Jena sei auch noch auf das OpenCV Projekt (http://sourceforge.net/projects/opencvlibrary/) von Intel hingewiesen. Intel stellt damit eine mächtige Sammlung von optimierten Algorithmen zur Signal- und Bildverarbeitung unter der GPL Lizenz zur Verfügung. In Kombination mit der Intel IPP ist das schon ein sehr mächtiges (und schnelles) Werkzeug. Vorteil von OpenCV ist, man findet im Netz ausreichend Dokumentation und beispiele, da es besonders an Universitäten recht verbreitet ist. Gruß Maik
"Kleiner" Nachteil der Intel Sachen, es gibt sie nur für Intel Architekturen :-(
Da hast du natürlich recht, ich dachte dabei auch eher an die schnelle Evaluation seines Algos auf einem x86 System um sich dann auf die Implementierung auf dem DSP zu konzentrieren.
Hallo, Danke für die vielen Antworten. Ein nicht ganz einfaches Thema:) Wahrscheinlich ist es wirklich das beste, die ganze Sache mit einer fertigen Bibliothek anzugehen. Und das am besten in C/C++. Von der OpenCV hab ich auch schon einiges gehört, die von der Uni Jena macht aber auch einen guten Eindruck. Am liebsten wäre mir natürlich ein eigener Algorithmus um Schilder zu erkennen. Ich weiß nur nicht um den Aufwand. Ich weiß halt nicht ob die Verwendung einer solchen Bibliothek zu einfach für ne "Diplomarbeit" wäre (ist es sicher nicht..) bzw. wie weit sich da Dinge optimieren lassen. Wie schnell hattet ihr denn mit OpenCV bzw. mit ICE (Uni Jena) erste Erfolge. Ich habe momentan etwa nur 10-15h pro Woche um mich mit der Thematik zu beschäftigen. Wichtig wäre halt, dass man den Algorithmus am Ende auf einen DSP/µC portieren könnte. Grüße
noch was: Was könnt Ihr für Literatur zur Mustererkennung empfehlen? Am besten mit praxisnahen Beispielen. Bis jetzt verwende ich: 1. Handbook of pattern recognition and computer vision - Chen, Chi-hau 2. Computer vision and image processing - Morris, Tim Das erste ist ein Überblick über viele Verfahren und Anwendungen ohne näher auf die Grundlagen einzugehen, das zweite behandelt grundlegende Bildverarbeitungsverfahren und geht teilweise auch auf die Mustererkennung ein. Grüße
Etwas offtopic aber ich fürchte mit 10-15 Stunden/Woche erreichst Du nicht mal das (kleinere) Ziel Algorithmus zu entwickeln, geschweige denn Implementierung. Für die Diplomarbeit wäre es auf jeden Fall viel zu groß. Ansonsten fürde ich Folgendes machen: wenn nur Standbilder analysiert werden müssten, dann würde ich ImageJ nehmen. Das ist Java und man kann schnell was machen (man muss sich nicht um "Laden", "Speichern" und so weiter kümmern. Wenn auch "Live" Bilder analysiert werden müssen, dann würde ich zu VirtualDub greifen -- einfacher geht es nun wirklich nicht, um Videos zu processieren. In beide Sachen musst Du Dich nicht einarbeiten, was spezielle Algorithmen angeht, es wird alles "per Hand" gemacht. Später kannst du dann alles in C umschreiben. Grüße, Kest
Das ganz soll erstmal nur für ein Standbild funktionieren. Dürfte ja nicht so schwer sein dass in C einzulesen und weiterzuverarbeiten, oder?! Was meinst Du mit Virtual Dub? Das ist doch eigentlich ein Tool im Videos zu bearbeiten. Mit den 10-15h will ich neben meinem Praktiukum jetzt nutzen um mich in die Thematik einzuarbeiten. Um den Aufwand für das Diplom wenigstens etwas abschätzen zu können. Grüße
zu VirtualDub: Man kann für VirtualDub eigene PlugIns schreiben. Dann lädt man ein belibiges Video und lässt es laufen.... Es können Video-Effekte sein aber auch Pattern-Matching oder wie auch immer. Man hat nur ein Array mit Pixelwerten und ab da ist ja nur Pixelschieberei ;-) Bei manchen Sachen reicht sogar die Geschwindigkeit aus, um Live-Preview anzuschauen. Ich mache viel Videoprocessing und hab die Erfahrung gemacht, dass wenn man später sowieso alles selber machen möchte (also keine vorgefertigetn Algos), sollte man auf MatLAB/OpenCV und Co verzichten um Überblick zu behalten. Dies aber nur meine eigene Meinung Grüße, Kest
Aha, ist natürlich auch ne interessante Idee um erstmal was zu probieren und ne Live-Ansicht zu haben. Benutzen die Plugins eine eigene Programmiersprache?
PlugIns können in VisualC++ programmiert werden. Ich habe ein Mal so ein Beispiel heruntergeladen und ab da ist dann einfach Kest
Ja mag sein, das ich etwas zu pesimistisch bin. Sind halt meine Erfahrungen gewesen und ich war schon ein bissel entäuscht, das ich nicht weiter kam. Aber muss ja bei dir nicht so laufen. OpenCV ist relativ einfach zu nutzen. Es gibt Module um Videos zu laden, Kameraschnittstellen und Bitmapreader. Die Bilder lassen sich also schnell bereitstellen. Desweiteren gibt es Module wie Greyscaler, Kantendetektoren aber auch kompliziertere Sachen wie Gesichtserkennung. Desweiteren gibt es Module die dir Verwaltung von Datentypen vereinfachen. Du musst dich einfach mal einlesen in OpenCV und ein paar Sachen probieren, dann wird das schon. Von Videobearbeitungssoftware würde ich abraten, da du die Software unbedingt auf den DSP portieren möchtest. Das ist von einem C Programm meiner Meinung wesentliche einfacher als aus irgenteinem Skript.
Hallo, moechte mich nochmal kurz den "Selbermachern" anschliessen: Der Punkt ist ja immer, dass es was zu Lernen gibt, man also irgendwann genau wissen muss, was die Algorithmen machen. Ist der Diskussion "Visual IDE" gegen "Gnu/Make" aehnlich: Anfangs ist mit den Klickibunti-Tools wie Matlab, Labview, etc. alles recht easy, wenn's dann aber an die Implementation und effizientes Programmieren geht, stellen sich ganz andere Huerden auf. Drum wuerde ich schon von Anfang an parallel entwickeln: Matlab, oder Python Imaging Library, oder was einem eben passt, kann man fuer's Ideen sammeln verwenden, und daneben schreibt man sich seinen eigenen Code per Library, oder eigenem Filter. Denn irgendwann rennt man in das Problem, dass die Library nicht genau das macht, was man will, und man kann es - sofern es geschlossener Code ist wie in Matlab, usw. - nicht mit vernuenftigem Aufwand debuggen. Grade wenn's auf dem DSP laufen muss, sind Handoptimierungen noetig, also wird meist die "inner loop" nochmal in Assembler gehackt. Die Lernkurve ist zwar anfangs steil, aber es lohnt sich. Letzte Worte aus dem Naehkaestchen: Fuer unsere Mustererkennung haben wir schlussendlich auf aufwendige Filter-Kernels (Sobel-Filter, usw.) und Vektorisierungsalgorithmen verzicht und schlussendlich alles von Hand geschrieben (in C und pur Integer). Konnte dann direkt von Linux auf Blackfin-uClinux portiert werden, nur die Bildacquisition wurde dann auf das video4linux-Interface umgestellt. Trotz Linux-Overhead sind wir da noch bei min. 10 frames/sec Verarbeitung. Gruss, - Strubi
So, nach einigen Recherchen werde ich das ganze von Anfang an versuchen in C/C++ zu machen. Zum einen habe ich eine gute Portierbarkeit, zum anderen den vollen Überblick (hoffe ich doch) was im Hintergrund passiert. Ausserdem gibt es ja für C gute Bibliotheken, um z.B. dieses SIFT (scale invariant feature transformation) zu verwenden. Die meisten Forschungsansätze beim Auswerten von Bildern nach Verkehrsschildern beginnen bei einer Farbsuche. Damit wird ein Bereich (Region of interest) eingegrenzt, in dem dann per Pattern Matching oder Formenanalyse auf die Art des Schildes geschlossen wird. Eventuell gibt es dann noch eine Schrifterkennung um die Geschwindigkeit auszuwerten (bei Temposchildern). Das mit dem DSP lasse ich erstmal aussen vor... Ich habe gesehen, dass Siemens/VDO solche Systeme schon recht weit entwickelt hat (http://www.vdo.de/products_solutions/cars/driver-assistance/road/, da gibt es auch ein Video). Jetzt stellt sich mir die Frage: lohnt es sich, Arbeit in ein solches Thema zu investieren. Es wird ja eine Diplomarbeit, also keine Forschung, so dass ich "nur" versuchen kann/werde, ein ähnliches System was hoffentlich etwas funktioniert, aufzubauen (also im wesentlichen Software). Interesse ist auf jeden Fall vorhanden. Das Thema ist halt neu hier am Lehrstuhl, so dass ja auch irgendwie angefangen werden muss. Wer hat Erfahrung mit solchen Sachen oder könnte mir da noch Tips in Richtung der Diplomarbeit geben ?! Viele Grüße und schönen Abend noch Johannes
Hi, wollte auch kurz was sagen da ich selbst mit industrieller Bildverarbeitung arbeite. Ich denke einen Rechner aufzubauen ist keine großes Problem. Sollte aber schon bei 800Mhz liegen. Da würde ich evt. Embedded Board nehmen. Sind aber ein wenig teurer. BV Bilbliotheken - fertige - gibts haufenweise. Cognex, Mil, Common Vision Blox, Halcon von MVtec. (wie schon erwähnt) Damit ist die Auswertung kein Akt. (Es sei denn - du mußt(willst es selbst machen) Zu jedem Gibt auch freie Testversionen. Meist mit begrenzter Laufzeit. Wenn man freundlich fragt bekommt man aber für 4 wochen eine Evaluierungslizens. Das sollte also nix kosten denke ich. Aber die Kameras bzw das Bild wird das teuerste. Wie willst du das Bild einziehen ? Was für ne Kamera ? Da liegt der Knackpunkt. Oder soll es rein theoretisch werden ? mfg Martin
Hallo, also mit der Auswahl der Kamera habe ich mich noch nicht beschäftigt. Wir haben hier einige Webcams von Axis die halbwegs brauchbare Bilder liefern, allerdings war ich damit noch nicht auf der Strasse unterwegs. Das Board von Blackfin hat ja z.B. einen analogen Videoeingang, so dass das eventuell auch eine Möglichkeit wäre. Schöne wäre wenn ich das ganze in C machen könnte um es später vielleicht wirklich auf einen DSP o.ä. zu portieren bzw. mein Nachfolger dies tun könnte. Mein Ansporn für die Diplomarbeit wäre es, eine solche Mustererkennung selbst, d.h. ohne Verwendung von Bibliotheken, zu realisieren. Ob das was wird weiß ich leider nocht nicht :) Bin noch am einarbeiten und die Zeit läuft zu Glück noch nicht. Gibt es freie Libraries um Matrizen in C vernüftig zu bearbeiten? Würde sonst die ganze Sache erstmal mit Matlab anfangen um mir zum probieren diesen Stress das alles selber machen zu müssen zu ersparen. Grüße Johannes
Hallo erstmal. Ich habe mir mal ein paar Gedanken zu Ihrem Vorhaben gemacht. Als erstes habe ich mal in die StVO geschaut und festgestellt, daß es ca. 200 Verkehrszeichen gibt. Zweitens habe ich mir überlegt, wie die Verkehrszeichen wohl auf die Sensoren der Kamera(s) abgebildet werden. Antwort: Ziemlich verzerrt, da die "Schilder" in den seltensten Fällen senkrechte Ebenen zur optischen Achse der Kamera bilden und von dieser in der Mitte des "Schildes" durchstoßen werden. Kreise werden zu Ellipsen, Rechtecke zu Rhomben und die dreieckigen "Schilder" bleiben zwar dreieckig, haben dann aber Symmetrien mehr. Der benötigte Suchalgorithmus muß diese Verzerrungen tollerieren können. Meine Idee wäre ein schon bekanntes Verfahren namens Kreuzkorreletion. In der Nachrichtentechnik und -verabeitung gerne angewendet um ein bekanntes Signal im Rauschen wieder zu finden. Ob sich allerdings schon jemals wer an einer zweidimensionalen Kreuzkorrelation probiert hat weiß ich nicht, müsste aber gehen. Der Rechenaufwand wird allerdings gewaltig: zum Erkennen nur eines einzigen "Schildes", dessen Musterfunktion in einer 64x64 Matrix liegt benötigt bei nur 640x480 Punkten Bildformat über 1,25e9 Multiplikationen und Additionen. Zum Erkennen aller "Schilder" wäre also ein Rechnerverbund von über 200 Prozessoren notwendig und schafft dann auch nicht einmal einen frame pro Sekunde. Und wozu die stereometrische Verarbeitung für dieses Problem gut sein soll ist mir im höchsten Maße schleierhaft. Trotz alledem find ich Sie sehr mutig. Solche Ingenieure braucht das Land. Viel Erfolg Georg Hannes Dipl.Ing.
@Georg Hannes: danke für Ihre Überlegungen. Das mit dem Steroervision war nur ne Schnapsidee um vielleicht Entfernungen schätzen zu können. Es bleibt aber bei einer Kamera. Das ganze Bild mit einer KKF zu bearbeiten ist natürlich unmöglich. Die meisten Ansätze gehen dahin, dass zunächst mit einer Farbsegemntierung begonnen wird. Es wird also z.B. Rot gefiltert. Anschließend werden daraus die interessanten Bereiche (ROI) ermittelt und dann mit verschiedenen Verfahren, also z.B. der von Ihnen vorgeschlagenen KKF, geometrischen Analysen oder ählichem nur in diesen kleinen Bereichen gesucht. Das sollte den Rechenaufwand schonmal ungemein reduzieren. Wie aufwendig dann die Implementierung ist weiß ich auch noch nicht. Auch mit der Kamera bin ich mir nicht im klaren. Ich soll mich schon bald festlegen was für eine Kamera und was für Hardware ich benötige. Dabei steht vor allem die Framerate und die Qualität des Bildes im Vordergrund. Wichtig wäre ja sicherlich auch eine hohe Scharfentiefe. Ich liebäugle ja noch mit dem Blackfin - in Kombination mit einer analogen Kamera. Hat jemand Empfehlungen für eime analoge Kamera in Verbindung mit einer Framegrabber-Karte bzw. dem Videomodul (von www.bluetechnix.at) für den Blackfin-DSP? Ich habe gesehen dass es auch CMOS-Module für den Blackfin gibt die sich über das PPI-Interface auslesen lassen, nur sind das die reinen Sensoren ohne Optik. Ich hätte aber schon gern was fertiges dami9t ich mich nicht auch noch darum kümmern muss. Das wird sonst nicht schaffbar. Wäre für Tips sehr dankbar Grüße Johannes
Hallo, zur 2D-Kreuzkorrelation haette ich folgende Bemerkung: Dank einiger netter Theoreme liesse sich diese per Multiplikation zweier Bilder im Fourier-Raum mit deutlich weniger Komplexitaet berechnen. ABER: In diesem Fall macht ein Problem die Loesungsidee zunichte: Die Schilder sind, wie schon erwaehnt, unter so einigen moeglichen Perspektiven sichtbar, also verzerrt, mal groesser, mal kleiner. Die KK bietet leider keine Projektions-Invarianz... Im allgemeinen kommt man bei Mustererkennung mit Vektorisierung oder Ecken-Detektion schneller zum Ziel, ich denke, der von Johannes skizzierte Loesungsweg klingt vernuenftig. Zur Kamera am Blackfin: Die analogen haette ich erst gar nich mehr angeschaut, das lohnt sich preislich nicht mehr, schon allein mit dem Aufwand der Ansteuerung des Codec. Es gibt von einer Hongkong-Firma (COMEDIA LTD) diverse Sensor-Module (Omnivision-Sensoren) mit Optik, wie z.B.: AA-9620 (1280x1024, "raw bayer" format) AA-9655 (1280x1024, YUYV-Format) und einige kleinere Sensoren Typ "Handykamera" (mit mieser Aufloesung), ich glaube, irgendwas mit 7660, oder aehnlich. Einfach mal googeln..und am besten mal die Datasheets angucken. Beim 9620 muss man zusaetzlich noch die Farben selbst (per Bayer-Pattern) umrechnen! Beim 9655 ist die Konversion etwas 'billiger'. In Deutschland fuehrt Intertec die Module, kosten um die 40 Euro als Einzel-Eval-Preis: www.intertec-components.de Falls dich die Omnivision-Dinger anfressen wuerden, haette ich auch einen Adapter von OV-Modul auf PPI-Stecker fuer die offiziellen BF537 STAMP(EZKIT) eval kits. Fuer die Tinyboards allerdings muesstest du nen Adapter selbst "frickeln", allerdings gibt es dort ein Board mit Adapter fuer die 76XX-Flexkabel-Minisensoren, wenn ich mich recht entsinne. Vorsicht: Der OV9655 ist ein 2.5V-Sensor. Ich bin mir nicht sicher, wie 3.3V-tolerant dessen I/Os sind, ich hab auf meinem Evalboard ein CPLD als "Glue". Bin eigentlich mit den Dingern ganz zufrieden, abgesehen davon, dass sie etwas bescheuert designt sind. Die Linsen sind natuerlich nicht das Ah und Oh, sind diese kleinen, direkt auf die Platine aufgeschrauben Mini-Mounts. Fuer das 9655 gibt es aber mehrere Linsen-Typen. Allerdings ist das Ansteuern der Sensoren per i2c etwas eine Krankheit gewesen, aber auf dem Code dazu bleib ich auch nicht sitzen wie auf einem Ei :-), sprich, der Source (standalone wie auch Linux) ist verfuegbar. Fuer akademische Zwecke sind die Teile von der Qualitaet her ganz ok, fuer ein (High-)Endprodukt natuerlich nicht zu gebrauchen, unter anderem, weil man keine Garantie fuer die Verfuegbarkeit eines solchen Moduls erhaelt. Gruss, - Strubi
Abesehen vom Aufwand der Bildverarbeitung frage ich mich, wie Ihr die optischen Linsen im Frontbereich tagtäglich frei von Fliegen, Schmutz, Regen und Schnee halten werdet. Da ist noch viel Stoff für Diplomarbeiten. Wahrscheinlich sind 2 Kameras für Kurvenfahrten schon zu wenig... Gruß Lutz
Allein die Kamerawahl ist nicht ohne.
Im Auto muss die ja mit stark unterschiedlichen Lichtsituationen
klarkommen (Entgegenkommendes Auto mit Fernlicht...) ohne geblendet zu
werden.
Mit CCD ist da nix zu reissen, es gibt aber CMOS-Kameras mit
entsprechenden Kennlinien ("HDR")...
Erster Google-Hit hierzu:
http://webvideo.uni-lueneburg.de/vd/pdf/070305-06.pdf
Übrigens, die 3D-Auswertung geht auch nur mit einer Kamera, wenn du die
Eigenbewegung des Autos mit einrechnest.
Ohne fuer den Sinn zu garantieren, wuerde ich vielleicht versuchen, das Verkehrsschild zu entzerren (Also eine frontoparallele Ansicht zu erzeugen) und in eine definierte Position zu rotieren bevor ich es zu erkennen versuche, da dies den Aufwand erheblich reduzieren sollte. Dies wird wohl auch so bei planaren Mustern fuer Augmented-Reality-Anwendungen so gemacht. (Einfach mal googlen.) Dafuer sollte man Eckpunkte des Schildes identifizieren (Natuerlich auch nicht einfach und ein Problem fuer sich), die grobe Schildform anhand der Anzahl ermitteln und aus vier Eckpunkten im Bild und den entsprechenden Punkten in der bekannten Schildform eine Homographie ermitteln, deren Inverse dann das Schild entzerrt. (Beispielsweise zu finden auf Seite 35 des Buches Multiple View Geometry von Hartley & Zisserman, in das reinzuschauen sich bei Deinem Problem sicherlich lohnt.) Damit haette man dann eine definierte Ansicht in der richtigen Rotation, die zu vergleichen mit deutlich geringerem Aufwand moeglich sein sollte. Ich weiss nicht, wie Deine Entzeitanforderungen sind, aber ich denke, dass es nicht ohne weiters auf einem Blackfin zu machen ist. http://thomaspfeifer.net/ (wirklich schoene Projekte) verwendet fuer Bilderkennung einen DM642-DSP, der deutlich mehr leistet. Ob damit Dein Problem in Echtzeit loesbar ist und wie man die umfangreichen Trainigsdaten fuer die verschiedenen Schilder (die sich durch den obigen Ansatz aber deutlich veringern sollten.) in so einer Applikation sinnvoll speichert, weiss ich aber auch nicht zu sagen. Gruss, Joern
Ach ja, schau Dir mal auf http://thomaspfeifer.net/ die Augmented Reality an. Thomas Pfeifer hat dort ein Video, was genau zeigt, was ich gemeint habe. Zu sehen ist, wie eine frontoparallele und richtig rotierte Ansicht des Quadrats erzeugt wird. (Sieht ziemlich nach Echtzeit aus.) Gruss, Joern
Danke für die vielen Ratschläge und die schöne Homepage von Thomas Pfeifer. Ich habe mal ein Video mit einer Axis-Webcam (W211M) während der Fahrt kurz vor Sonnenuntergang (es war noch hell genug) aufgenommen. Ich hatte ja die Hoffnung erstmal einen Farbfilter über das Bild zu schieben um dann .B. nur rötliche Bereiche zurückzulassen. Nur sind die eigentlich roten Schilder auf dem Video nicht mehr mehr rot, sondern braun-weiß-bläulich. Werde mal versuchen das noch in anderen Farbräumen ausser dem RGB (z.B. im HSV) auszuwerten. Aber hier geht das Problem schon los: Ich brauch halt erstmal ne gute Kamera, bei der die Farbtreue möglichst hoch ist und die einen möglichst "echtzeitnahen" Zugriff auf die Bilder erlaubt. Vom Rechenaufwand her denke ich immer noch dass am Anfang eine farbliche Trennung gemacht werden sollte. Anschließend werden diese Bereiche dann weiter verfeinert. Grüße Johannes
ich glaube Du solltest das erstmal im "Reinraum" machen - sprich: nicht draussen auf der Straße sondern drinnen mit guten Lichtverhältnissen damit es überhaupt erstmal prinzipiell läuft.
ich glaube das werde ich auch machen. Bei Fortschritten melde ich mich wieder. Macht denn jemand hier was ähnliches? Vielleicht könnte man sich da zusammentun bzw. Gedanken austauschen ?! Wäre schön Grüße Johannes
Hast Du Dir CUDA von nvidia mal angesehen? Damit kann man alle Berechnungen von der Grafikkarte berechnen lassen, Funktioniert sehr gut und vor allem um Faktor x100 schneller als auf der normalen CPU. Vieles ist schon "vorgefertig", wie fft. Programmieren lässt sich alles in C. Ich habe ja schon geschrieben, dass ich oft VirtualDub für Videos nehme, wenn ich was ausprobieren möchte. In VirtualDub rufe ich dann einfach CUDA-Funktion auf und processiere das Bild. Na ja, war nur so ein Einwurf, vielleicht wäre es was für Dich. Grüße, Kest
Hallo Johannes, ich bin auch gerade auf der Suche nach ähnlicher Hardware (falls du noch suchst...). Habe eben hier auch schon einen neuen Thread erstellt: Beitrag "Embedded-System mit Kamera und genügend Performance für Bildverarbeitung" ... vielleicht für dich auch ganz interessant. Gruß Hannes P.S: Zu deinem Farbproblem: Hast du es mal mit einem manuellen Weißabgleich versucht (ist z.B. auch mit Photoshop nachträglich möglich wenn die Kamera dies nicht erlaubt)?
Georg Hannes schrieb weiter oben: "Meine Idee wäre ein schon bekanntes Verfahren namens Kreuzkorreletion. In der Nachrichtentechnik und -verabeitung gerne angewendet um ein bekanntes Signal im Rauschen wieder zu finden. Ob sich allerdings schon jemals wer an einer zweidimensionalen Kreuzkorrelation probiert hat weiß ich nicht, müsste aber gehen." Und ob das in der Bildverarbeitung funktioniert! Wird standardmäßig zur Pattern identification angewandt, aber auch für Deformationsmessungen, motion analysis und Objektauthentifizierung. Ich arbeite im Bereich Standardsoftware für die 2D-Grauwertkorrelation. Damit kann man Bewegungen analysieren, Verformungen messen u.s.w. von nanowinzigen Objekten (Mikrosystemtechnik) bis zu riesigen geologischen und glaciologischen Forschungsgegenständen (Bergrutsche, Gletscher) Für die vorliegende Aufgabenstellung ist besonders nützlich, dass Beleuchtungsvariationen wegen der Normierung des korrelationskoeffiozienten unproblematisch bsind - in der BV an sich so sonst nicht üblich. Objektverzerrungen können bis zu ca 20 Wunkelgrad von der Senkrechten meist ignoriert werden (nach eigenen kürzlichen Messungen), bei Verkehrszeichen dürften aber größere Abweichungen zu bearbeiten sein. D.H. die Originalbilder müssten testweise auf Grund einer Winkel-Hypothese "verzerrt" werden, um die Verkehrszeichen im Originalformat abbilden zu können. Auch an eine Grössenkorrektur muss vor der Korrelation gedacht werden. Also von jedem Originalbild eine Schaar seitlich " gessehnter" bilderin verschiedenen Masstäben erzeugen und in denejn eine Korrelationssuche (zur Rechenzeitersparniss nach vorheriger Suche nach charakteristischen Formen mit konventioneller BV) audführen. Lerider ist die Korrelation, wie von Hannes schon bemerkt, fürchtelich langsam. In Echtzeit in einem embedded system halte ich sie daher für noch nicht geeignet. Mit der künftigen Entwicklung von multicoreProzessoren wird sich das aber ändern, zumal sich Korrelationsalgorithmen prima parallelisieren lassen.. Lohnt also u.U. schon entsprechende Vorlaufntwicklungen zu beginnen. Korelationssysteme für 2D- und 3D- Aufgaben werden u.a. angeboten durch: DANTEC ULM GOM GmbH Braunschweig LIMES gmbH und von uns (CWM Chemnitz). (2d-System VEDDAC, da wir davon ausgehen, dass mit der viel einfacheren, preisgünstigeren 2D- Technik wenigstens 85% aller technischen Aufgabenstellungen lösbar sind :-) Bei Interesse ist bei uns kostenfrei eine Startzahlbegrenzte Evaluationssoftware (PC, Windows XP) voriwegend für Deformations- und motion analysis (aber sicher auch bei ausreichendem Verständnis des Users für Experimente zur pattern recognition einsetzbar, Bildverzerrungen z.B. mit Atndardprogramen oder einfachen Eigenentwicklungen. ) unter www.cwm-chemnitz.de (Kontaktformular) zu beziehen. Ich hoffe, Ihr toleriert diese Firmenangaben als erforderlich zur Information und weniger als Werbung. Gruss Michael
>>Lerider ist die Korrelation, wie von Hannes schon bemerkt, fürchtelich >>langsam. Die Korrelation zweier Signale läßt sich über die FFT rechnen, das geht auch zweidimensional, also mit Bildern. Wenn man die FFT der Bilder auf dem embedded System rechnen kann, dann geht auch die Korrelation. BTW: Meine Lieblingstransformtion, die Hough Transformation, ist im Prinzip auch nen Korrelation . Cheers Detlef
"Die Korrelation zweier Signale läßt sich über die FFT rechnen, das geht auch zweidimensional, also mit Bildern. Wenn man die FFT der Bilder auf dem embedded System rechnen kann, dann geht auch die Korrelation." Das ist richtig allerdings lassen sich die Grundprinzipien, die zur Vereinfachung der FFT gegenüber der "einfachen§ DFT und zur schnelleren Berechnung führen, auch sinngemäß ähnlich zur Straffung der berechnung verwenden, wenn man den Korrelstionskoeffizienten berechnet. Einen wirklich entscheideneden Rechenzeitunterschied gibt es bei otimierten Algorithmen wohl nicht. Wenn man bedenkt, dass man für die vorliegende Aufgabe ja nicht einfach zwei Bilder korrelieren muss, sondern z.T. wegen der unterschiedlichen perspektivischen Abbildung und der 200 Zeichenmuster mit mehreren Referenzbildern arbeitet, erscheint mir das für embedded system doch etwas zeitkritisch. Ich hab mir mal den obuigen Hinweis auf CUDA von nvidia auf der Webseite angeschaut - das sieht ja wirklich aussichtsreich nach Echtzeit aus, wenn man 128 Parallelprozessoren geballt auf eine Bildkorrelatione losgehen lassen kann.. Muss mir mal die FFT-Algorithmen in dem Paket näher beschnerchen, wie die sich eignen. Allerdings besteht da das Problem, inwieweit das System für künftige Entwicklungen weiter unterstützt wird ? Gruss oreganogold
Ist ne olle Kamelle. Bei Opel gibt es das demnächst zu kaufen, bei BMW auch. Insofern nicht mehr interessant...
Hallo, danke nochmal im Nachhinein für die vielen Anregungen. Ich habe mich allerdings dann doch gegen dieses Thema entschieden, da das am Institut ganz neu war und ich bei Null hätte anfangen müssen. Aber gelernt haben wir hoffentlich alle etwas davon :) Grüße Johannes
Mal eine gewagte Frage: Gibt es Lasersysteme die ein Trichter ausstrahlen? Müsste, ich meine sowas hier: http://www.night-tronic.de/productssimple31.html aber nur halt auf die rechte Seite, wie ein gezielter Lichkegel. Wenn einer dieser Laserstrahl auf ein reflektierendes Objekt trifft (Verkehrsschild) kann man doch dieses Licht detektieren? Sinnvoll wäre irgendein Moduliertes Signal, um keine Streuquellen zu detektieren. IRLaser sendet -> trifft auf Schild -> Reflektionen -> IR Empfänger erkennt Reflektion Dann die Position bestimmen (max Leuchtkraft im CCD Bild). Anhand deren Position im Bild kann man den Rechenaufwand der weitern Bilderkennung vielleicht verringern, da die Position im Bild bekannt ist? nur ne Idee..
"Hallo, danke nochmal im Nachhinein für die vielen Anregungen. Ich habe mich allerdings dann doch gegen dieses Thema entschieden, da das am Institut ganz neu war und ich bei Null hätte anfangen müssen. Aber gelernt haben wir hoffentlich alle etwas davon :) Grüße Johannes" -> Weise entscheidung, es laufen bei Stereokameras (hier) im Automobilbereich Dinge ab, von denen du nur träumen wirst. Und auf jeden Fall mehr als eine "one man show"...ganz zu schweigen von dem finanziellen Aufwand, eine brauchbare (!) Lsg. hinzubekommen. Klaus.
Wieso sind Stereokammeras im Einsatz? Entfernungsmessung, bessere Berchenbarkeit des abzulesenden Schildes?? würde mich mal so interssieren.. mfg
Ist es nicht Besorgnis erregend, dass dieser Thread so kurz nach einem offensichtlichen Insider-Einwurf aus der Automobiltechnik-Branche plötzlich abbricht? Dabei wurde es gerade interessant...
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.