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-a..., 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

Google nach BLAS

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