Bilderkennung-Programm

[Asurokiller]

Ich habe eine Webcam an meinen Bot aber kein Programm das die Bilder dieser Cam irgendwie auswerten oder bewegungen oder Helligkeitsunterschiede warnehmen könnte und dann befehle an den LPT Port des Pcs senden und die Relaiskarte schalten könnte.
Kennt jemand so ein programm oder wenn jemand eines schreiben würde wäre ich sehr dankbar.
Schon ma danke im voraus für eure Hilfreichen Beiträge.

[NumberFive]

Bilderkennung ist die Königsklasse der Programierung in Sachen Roboter.
Mir ist nicht bekannt das hier schon mal was richtig funktioniert hat.

Aber es viele auch ein paar Infos. Hast du den PC auf dem Bot ? wie kommen die Bilder auf den PC ? Wie viel Leistung steht zu Verfügung ? Ist es als Steuerung gedacht ?

Gucke mal hier:

https://www.roboternetz.de/phpBB2/zeigebeitrag.php?t=16884

Dieses Forum hat ein such Funktion.

[BeautyofBaud]

Naja, zurzeit planne ich selber auch an einer Bilderkennung

https://www.roboternetz.de/phpBB2/viewtopic.php?t=32843

der 1hdsquad hat mir nen netten link zu ner Diplomarbeit geschickt
https://www.roboternetz.de/phpBB2/dload.php?action=file&file_id=111

Sehr viele Infos drinne... Ich hab / hatte jetz am Anfang auch extreme Probleme was zu diesem Thema zu finden... man tastet sich da langsam ran und kommt Seite für Seite, Algo für Algo langsam weiter...

Aber da du Ja Was "fertiges" willst... Da brauchste entweder genug Kohle (diese Weicheware ist gerne mal ganz schön teuer) oder fragst mal ambesten die Leute, die damit schon gearbeitet haben ambesten direkt per PM an ob sie noch was rumliegen haben... Ich denk aber da führt nichts am Proggen herrum... Werd mich aber mal im Inet umschauen und das in meinem Topic / hier posten wenn ich was finde.

greEtz baud

[Longi]

Hi,

Panasonic hat ein Programm im Angebot, das zumindest Helligkeitsunterschiede und andere Merkmale (z. B. Markierungen, Kerben usw.) zuverlässig unterscheiden kann. Bewegende Sachen gehen damit aber glaube ich nicht...

Gruß Bernd

[MeckPommER]

Ich würde vielleicht einen ganz anderen Weg gehen.

Wenn ich etwas selber baue, dann will ich es auch ganz selber gebaut haben. Gut, vielleicht die eine oder andere Anregung anderer Bastler aufnehmen, aber eine komplette Bildverarbeitung einfach so übernehmen und dann sagen, man hätte seinen Roboter selbstgebaut - das ist für mich so, als würde ich auf meinen alten Kombi nen Aufkleber ranbappen und dann sagen, ich hätte das Auto selber entworfen...

Da ich in Zukunft für meinen Bot selbiges vorhabe, hier meinen geplanten Weg. Vielleicht ist ja eine Anregung dabei.
Als erstes soll die Bildverarbeitung von einem Atmel gemacht werden, also onboard. Das ist eine heftige Aufgabe, aber vielleicht nicht unmöglich. Dazu ist eine Webcam ungeeignet, da sie ein USB-Gerät ist. Ich werde eher eine normale Mini-Videocam für ein paar Euro nehmen, und dann sehen, ob ein Atmel da nicht vielleicht 1-2 fps digitalisieren kann.

Dann die Bildverarbeitung. Da gibt es viele Möglichkeiten, Informationen aus einem Bild zu gewinnen: Spalten und Zeilen nach Maxima Untersuchen, oder vom aktuellen Bild das Vorherige subtrahieren um Bewegungen deutlicher zu machen ...

Es ist doch grade dieses Experimentieren, was dieses Hobby so interessant macht. Oder wie jemand mal sagte: wer immer nur in die Fußstapfen eines Anderen tritt, der wird niemals voranschreiten.

Vielleicht findest ja grade DU einen Weg, den noch niemand vor dir gefunden hat, grade weil du vielleicht das ganze nicht bis ins Letzte studiert hast und vorgekaute Meinungen lernen musstest und bist so anderen weit voraus.

Versuch macht kluch, hast nix zu verlieren :)

Gruß MeckPommER

[toemchen]

Hallo MeckPommEr,

das Video-Digitalisieren mit Atmel habe ich auch vor, letztes Jahr habe ich mich dazu viel mit dem Macher der Webseite "kreatives-chaos.com" unterhalten, und er hat für mich eine pfiffige Schaltung entworfen. Die Platine ist geätzt und bestückt, allerdings kommen weder Fabian noch ich so recht dazu, das Ding in Betrieb zu nehmen.

Wenn Du Interesse hast, schreib mir ne PN, vielleicht gebe ich mir einen Ruck und dokumentiere den bisherigen Stand auf meiner Webseite oder als email.

Gruß
Tom

[Vitis]

Aaalso. Für Bilder in Atmelo bekommen kann ich wärmstens
die Kamera C-325 empfehlen. Die funktioniert echt prima
und 1-4 Frames/s gibt die auch locker aus je nach Auflösung
versteht sich, aber die Ziele sollten für den Anfang nicht zu hoch
gesteckt werden, weil ... naja, n AVR ist nicht gerade n Pentium
X-wasweisich mit 25 Terraherz Taktfrequenz.
Das nächste Problemchen ist das RAM. Selbst für n kleines
Bild in 4 oder 8 Bit Graustufe kommt Ihr schnell an die Grenzen des verfügbaren RAM, also auf alle Fälle ist die Erweiterung des RAM
vorzusehen. Man kann das entweder per X-RAM an den größeren AVRs machen oder halt in irgend einer anderen Form RAM anhängen.
Ich habe es so gelöst, dass ich extern nen alten EDO-RAM-Riegel
angepinselt hab. funktioniert soweit tadellos, aber das ist nur eine Möglichkeit von vielen.
Dann die Programmstruktur. Bei meiner Anwendung habe ich es so programmiert, dass während ein neues Bild eingelesen wird, das vorangegangene Bild verarbeitet wird und komme so auf 2-3 Frames je Sekunde. Meine Algorithmen basieren zunächst mal auf Sobel Kantenerkennung mit verschiedenen Matrizen und auf Differenzbildern. Ich kann behaupten, das die Geschichte schon ziemlich starker Tobak ist für nen AVR und der ist da mit nix Anderem Beschäftigt als Bilder verwursteln, sonstige Steueraufgaben oder so sind da fast nicht mehr drin, aber es geht.

[MeckPommER]

@toemchen, den Stand auf ner Website zu dokumentieren ist sicherlich das Sinnvollste, da so am meisten Leutz davon profitieren.

@vitis, ne C-325 sagt mir moentan grade nicht viel, was ist das für eine? google war hier auch nicht wirklich hilfreich.

Um extra-RAM kommt man hier wirklich nicht herum. Etwas größer als 40x30 Pixel wollte ich die Bilder schon verarbeiten.

Mein Bot arbeitet parallel mit derzeit neun Atmels. Der 10. Controller, der dann für die Bilderkennung zuständig sein wird, braucht keine anderen Aufgaben zu erfüllen. Problem wird beim Extra-RAM nur die Beschaltung werden, da zwei Ports komplett für den Datenverkehr zu den anderen Controllern draufgehen. Aber wenn McGuyver aus nem Kaugummipapier nen Taschenrechner bauen kann, dann werde ich da auch ne Lösung finden ;-)
Als Controller hatte ich erstmal nen 644-20 im Auge. Nen größerer TQFP144 läßt sich so schlecht auf Streifenraster löten ^^

[oratus sum]

Ich arbeite gerade an so einem Programm. Versuche gerade einiges aber irgendwie klappt es nicht recht.

Was willst du genau erkennen? Bewegungen oder z.b. Helligkeit?

Was ich bisher geschafft habe ist, dass er ein Foto macht und wenn sich etwas im Bild verändert dann gibt er bescheit. Dazu schaut er sich die einzelnen Farben der Pixel an und vergleicht sie mit dem Foto. Natürlich wird ein gewisser Spielraum gelassen und erst dann wenn z.b. 4px*5px, die nebeneinander liegen sich verändern schlägt er an.

Dadurch, dass ich dazu eine Funkkamera benutze und öfters Störungen auftauchen zeigt er oft nur quatsch an.

Das Ganze ist also noch lange nicht im Stande zur Objektverfolgung, was ich ursprünglich im Sinn hatte ;-)

MFG

[p_mork]

Hallo,

ich verwende bei meinem Bot die C3088 von roboter-teile.de . Die Bildverarbeitung läuft mit ca 10fps und kann beliebige schwarze Formen auf einem (am besten)weissen Blatt Papier erkennen. (also wie der POB-Bot). Linienverfolgung ist auch drin. Das ganze allerdings auf einem ARM (LPC2138) mit 59MHz. Später solls ein AVR32(AT32AP7000) mit 150MHz werden, da der schon ein Image Sensor Interface hat und so keine Zeit verbraucht, um das Bild zu empfangen.

MfG Mark

[minium :)]

Hi,

und was für ein Programm/software hast du ?

[p_mork]

Hallo minium,

die Software habe ich komplett selbst geschrieben. Um eine Figur zu finden, wird das aufgenommene Bild erstmal in ein binäres umgewandelt, alle Pixel, die unter einem Schwellwert liegen werden schwarz, die restlichen weiss. Dann wird nach einem schwarzen Pixel gesucht und ein Fenster um ihn so gebildet, dass dessen Rahmen kein einziges schwarzes Pixel berührt. Danach wird das Bild im Fenster zu einer 16*16-Matrix komprimiert und mit einem Bild der zu erkennenden Figur verglichen. Sollten mehr als 200 Pixel miteinander übereinstimmen, gilt die Figur als erkannt und wird in eine Liste eigetragen. Dann wird die Figur im Fenster mit weiss ausgefüllt und wieder nach einem schwarzen Punkt gesucht, Fenster gebildet, verglichen usw..., solange bis im Bild kein einziges schwarzes Pixel mehr ist. Dann wird die "größte" erkannte Figur in der Liste ermittelt und ja nach ihrer Position dreht sich der Roboter nach links oder nach rechts oder fährt von oder zu ihr. Sollte die Liste leer sein, stoppt der Bot.

Leider kann ich euch kein Video davon zeigen, da das Subsystem und die Harware des Roboters wegen grober Fehler bei der Planung im Moment komplett umdesignt wird. Ist aber in ca 2 Wochen fertig.

MfG Mark

[MeckPommER]

Interessanter Algo. Auf nem Atmega kommen wir da wohl locker auch auf 2-3 Frames pro Minute ;-)

Was mich interessieren würde, ist deine Entwicklungsumgebung, die Eingesetzte Hard- und Software dafür.

MfG MeckPommER

[p_mork]

Hallo MeckPommER,

als Entwicklungsumgebung benutzte ich WinARM mit dem arm-elf-gcc/g++.

Die Hardware besteht aus dem LPC2138-Modul http://cgi.ebay.de/ARM7-Philips-LPC2138-Stamp-Module-ARM-32-16-Bit_W0QQitemZ160144502868QQihZ006QQcategoryZ10662Q QrdZ1QQssPageNameZWD1VQQcmdZViewItem,
einem Subsystem aus einem AtMega32 für die Motorsteuerung(L298 und RB35-Motoren) und Servos und einem zweiten Mega32 für eine kleine Tastatur und für die Überwachung von Strom und Spannung.

Die Kamera wird direkt an den LPC2138 angeschlossen. Bei jedem HSync wird ein IRQ ausgelöst, in der ISR werden dann die Pixel eingelesen und gespeichert. Sobald ein Frame komplett übertragen wurde, wird der Frame-Zeiger verändert, sodass das Frame bearbeitet werden kann, wärend ein das nächste parallel dazu eingelesen wird.

Gerade das war eines der grösten Fehler bei der Planung. Der Controller verbrauchte einfach zu viel Zeit, um ein Frame zu empfangen, weil er ja während der ganzen HSync beschäftigt war. Irgendwann kam mir die Idee, zwei externe RAMs zu benutzen. Ein Frame wird in das eine RAM eingelesen, der µC verarbeitet inzwischen den Inhalt des zweiten. Dann werden die Daten- und Adreassbusse der beiden RAMs getauscht. Da ich dann aber über 20 Logig-ICs brauchen würde, hab ich mir überlegt, ein enzelnes externes RAM zu benutzen. Ein Frame wird von der Cam reingeschrieben und in der inaktiven Zeit(VSync) wird es vom LPC2138 in sein internes RAM übertragen. So könnte man die mögliche Zeit für die Verarbeitung eines Frames bis zu 10 mal erhöhen.


...die Eingesetzte ... Software dafür.
Was meinst Du mit Software? Für die Entwicklung benutze ich nur den Compiler, weitere Tools habe ich nicht.

MfG Mark

[oratus sum]

Das ich daran nicht gedacht habe... die Bilder Binär umzuwandeln!

Wie sieht bei dir der Schwellwert aus? Bzw könntest du das genauer erklären?

[Vitis]

man kann z.B. alle Grauwerte des Bildes addieren und durch 2 Teilen
aber das braucht halt lange. Ich hab bei einem Projekt einfach
die 2 Bilddiagonalen genommen und da die Grauwerte addiert, das ergebnis durch 2 dividiert. man kann auch gewichten, also beispielsweise nur den zentralen Bildbereich mitteln und daraus nen Schwellenwert errechnen oder oder oder

[p_mork]

Ich hab einen festen Schwellwert von 40, den ich experimentell ermittelt habe. Damit gab es bei fast jeden Lichtverhältnissen keine Probleme.

MfG Mark

[Herkulase]

Häufig arbeitet man bei der Bilderkennung ja mit Neuronalen Netzen, evtl. findest Du noch ein paar Ideen, wenn Du dich damit mal beschäftigst.

[p_mork]

Hallo Herkulase,

das habe ich auch vor, aber erst wenn ich das Board mit dem AP7000 besitze. Das Problem bei KNNs+Bilderkennung ist, dass man für die sehr vielen Gewichte extrem viel Speicher benötigt, den der LPC2138 nicht hat.

MfG Mark

[Herkulase]

Das hängt aber v.A. von der Architektur des Netzes ab! SOMs z.B. benötigen EIngabemuster (in Pixeln) x Ausgabemuster Gewichte, also im bereich von einigen 100 bis 1000. Natürlich reicht das nicht für eine komplexe optische Steuerung, aber um eine Linie abzufahren sollte das doch schon reichen.
Wieviel Speicher hat denn der AP7000? Hab es auf die SChnelle nicht rausgefunden.

Gruß

Gerald

[p_mork]

Hallo Herkulase,


Natürlich reicht das nicht für eine komplexe optische Steuerung, aber um eine Linie abzufahren sollte das doch schon reichen.

Eine Linie kann mein Roboter aber auch so ziemlich zuverlässig abfahren. Wenn ich schon ein KNN/SOM einsetzte, dann möchte ich auch eher fortgeschrittene Sachen haben, wie z.b. das Erkennen von beliebigen Hindernissen auf beliebigem Untergrund oder Positionsbestimmung usw.

Der AP7000 hat ein SDRAM-Interface. Ich möchte das NGW100 (http://shop.embedit.de/product__590.php) kaufen, dort sind schon 32MB RAM und 16+8MB Flash so wie diverse Peripherie drauf. Zudem hat der Controller eine VPU, die gerade für Bildverarbeitung sehr nützlich sein könnte.

MfG Mark

[-chris-]

ich glaub auch nicht, dass man mit nem knn an speichergrenzen stoßen wird, erst recht nicht mit 32MB RAM ^^ wenn ihr binarisiert, schaut euch mal adaptive binarisierung an, speziell den algorithmus von Niblack, wird gern verwendet und ist flexibler als ein fester Schwellwert.

[Vitis]

Der AVR32 ist schon ein Hammerteil ... willst Du da auf Systemebene arbeiten oder unter Linux ?

[tornado]

Hi,
hast du das hier schon gesehen?
https://www.roboternetz.de/phpBB2/viewtopic.php?t=34389
guss,
tornado

[p_mork]

Der AVR32 ist schon ein Hammerteil ... willst Du da auf Systemebene arbeiten oder unter Linux ?

Wahrscheinlich unter Linux wegen TCP/IP und Multithreading. Wär schon toll wenn der Roboter ausm Internet erreichbar wäre.

MfG Mark

[gast1234]

Hallo p_mork,

erstmal Glückwunsch zu Deinem tollen Roboter. Die Filme machen Lust auf mehr. Wie machst Du Deinen Mustererkennungsalgorithmus rotationsinvariant? Vergleichst Du mit Vorlagenmustern in verschiedenen Rotationswinkeln?

[p_mork]

Hallo gast1234,

ich vergleiche immer nur mit einem Muster, deswegen muss das Objekt auch immer möglichst gerade liegen, sonst wird es nicht erkannt.

MfG Mark