Java JavaCV Experten gesucht

[Wurschti]

Hallo liebe Forumuser,

ich arbeite mit meinem Projektteam gerade an einem vollautomatisierten Air-Hockey-Tisch. Es soll ein menschlicher Spieler gegen eine automatisch gesteuerte Linearachse spielen können. Damit die Linearachse weiß, wohin sie sich bewegen muss, braucht sie die Information wo sich der Puck gerade befindet. Dieses Problem will ich mit einer Videokamera lösen, die sich oberhalb des Spielfeldes befindet. Die Kamera soll die Bildaufnahmen dann an einen PC weiterleiten(auf dem JavaCV läuft), der diese dann auswertet und an eine SPS weiterschickt (zur Ansteuerung der Linearachse). Es soll Richtung, Position und Geschwindigkeit des Pucks bestimmt werden.

Das Ganze sollte relativ schnell arbeiten, da beim Airhockey generell schnelle Geschwindigkeiten erreicht werden können und die Linearachse möglichst in Echtzeit auf Schüsse reagieren soll. Nun wollte ich wissen ob, und falls ja, wie gut JavaCV für diese Aufgabe geeignet ist. Ich habe die Featureliste von JavaCV nur kurz überflogen und dachte mir deshalb, dass ich lieber hier einen erfahrenen User aus dem Forum frage. Falls JavaCV nicht geeignet wäre, könntet ihr mir dann auch noch andere Programme empfehlen, die Bilderkennung und Analyse erledigen könnten?

Vielen Dank.

 

[DefconDev]

Eine frage am rande, die weniger direkt mit deiner suche zu tun hat. Ist die kamera überhaupt in der lage so schnell informationen zu übertragen. Ist da nicht ein art touch-sensor im tisch sinnvoller?

 

[Wurschti]

Wir haben schon überlegt eine Art "Sensor-Matrix" unter dem Tisch aufzubauen, hat sich aber als zu kompliziert erwiesen. Die Kamera müsste so um die 60-100 Frames pro Sekunde übertragen, damit das Ganze vernünftig funktioniert.

 

[DefconDev]

Ich will dir wirklich nicht auf den keks gehen, aber bei 60-100frames musst die kamera richtig teuer sein und die datenraten die dazu verarbeiten sind, sind ja massig. Ich glaube 100mbit pro sek bei 100frames(vollbild)

Aber bitte nicht steinigen, ich bin nur ein laie. Ich finde dein projekt nur interessant.

 

[Wurschti]

Ich will dir wirklich nicht auf den keks gehen, aber bei 60-100frames musst die kamera richtig teuer sein und die datenraten die dazu verarbeiten sind, sind ja massig. Ich glaube 100mbit pro sek bei 100frames(vollbild)

Aber bitte nicht steinigen, ich bin nur ein laie. Ich finde dein projekt nur interessant.

So teuer sind diese Kameras gar nicht, da die Auflösung sehr gering sein kann. Es muss eigentlich nur ein schwarzer Puck auf weißer Fläche erkannt werden. Und wenn die Auflösung nicht so hoch ist, halten sich die zu bewältigenden Datenmengen auch in Grenzen. Hier zum beispiel eine dieser günstigeren Cams: http://sine.ni.com/nips/cds/view/p/lang/de/nid/210337

 

[XHotSniperX]

Hey Wurschti

Mit JavaCV kann man das machen ja aber du musst mal ausprobieren, ob die Reaktion genug schnell ist. Die Kamera und die Übertragung muss schnell sein, denn du brauchst immer die aktuellen Bilder, um den Puck zu orten. Die Bilder dürfen natürlich auch nicht verwaschen sein, wenn der Puck schnell unterwegs ist. Sonst ist es noch ein wenig schwieriger den Puck zu identifizieren.

Probier es mal einfach Woher kommst du eigentlich, wenn ich fragen darf?

 

[Tumbleweed]

Bei Air-Hockey kann man doch bestimmt ganz gut extrapolieren. Die Bewegungen sind doch sehr vorhersehbar, da es nicht ständig neue Richtungsänderungen geben kann, wie beim Kicker. Das könnte die Problematik etwas entschärfen. Eine gewisse Reaktionszeit macht die Reaktion auch etwas natürlicher.

Spannendes Projekt übrigens. Falls das klappt, stellt doch mal ein Video ins Netz.

 

[Darlis]

Es gibt ja schon den Computerkicker.

Weitere Performance-Faktoren sind natürlich wie gut ihr die Algorithmen zur Erkennung des Puks und dessen Richtung implementiert und welche Hardware euch zur Berechnung zur Verfügung steht.

 

[Krik]

Ich würde statt der Kamera eher ein paar Ultraschallsensoren in den Banden des Tisches einbauen und aus deren Messwerten die Position des Pucks errechnen. Anschließen kann man die Dinger zB an einem Arduino-Board.

Da ergibt eine Reihe von Vorteilen:
- Kamera = teuer, ein paar hundert € werden es wohl werden <-> Ultraschallsensoren = billig, 4-20€ das Stück
- Bildverarbeitung = aufwendig <-> Abstandsmessungen = über Triangulation sehr, sehr einfach
- Kamera nimmt mit 60-100 fps (= 60-100 Hz) auf <-> Ultraschallsensoren mit <=125 Hz. Vielleicht gibt es auch noch schnellere Sensoren zu kaufen.

So ein Arduino-Board kann man mit C, nem BASIC-Dialekt und Java programmieren.

Ein weiterer Vorteil des Ganzen wäre, dass man kein Gestell über dem Tisch aufbauen muss. Im Eifer des Gefechts wird das Teil nämlich reichlich vibrieren, und das kann bei der Kamera zu Problemen führen.


Edit:
Um das noch mal zu verdeutlichen:
Die Kamera nimmt mit 60 fps auf und spuckt dabei ein 320x200-Pixel-Bild in VGA aus. Das sind 64 KB pro Bild, und die müssen für die gewünschte Reaktionsgeschwindigkeit in weniger als 16 ms verarbeitet werden (1/60 fps = 16,67 ms zwischen den Bildaufnahmen). Das ist prinzipiell möglich, aber auch aufwendig. Bei 64 KB/Bild ist eine Bandbreite von ca. 3,7 MB/s nötig, also muss die Kamera mit mindestens USB 2.0 (schafft <= 30 MB/s und 1000 Hz) am Rechner angeschlossen sein.
Weiterhin muss das Bild verarbeitet werden, dafür habe ich 16 ms angesetzt. In diesen 16 ms muss auch das aktuelle Bild mit dem vorherigen verglichen werden, um den Puck, seine Richtung und seine Geschwindigkeit zu berechnen.

Das bedeutet genauer gesagt:
1. Bild filtern, um den Puck sichtbar zu machen. (S/W-Bild wäre praktisch.)
2. Erkennung des Pucks mit einem Algorithmus.
3. Vergleich der aktuellen Puckposition mit denen von vorherigen Bildern.
4. Daraus Richtung und Geschwindigkeit des Pucks errechnen.
5. Werte mehrere Millisekunden in die Zukunft extrapolieren (Bandenspiel dabei nicht übersehen), um den Zeitverlust durch die Berechnungen auszugleichen.
6. Mit den gewonnenen Werten die SPS füttern.

Dafür braucht es mindestens einen LowEnd-Computer, der mit ein paar hundert Euro zu Buche schlägt.


Vier Ultraschallsensoren hingegen liefern vier Abstandswerte. 60 mal in der Sekunde. Das schafft selbst ein kleiner Microcontroller wie der Arduino. Für mehr Komfort kann man auch einen Raspberry nehmen. Da muss man aber schauen noch, wie viele Sensoren man da anschließen kann.

Und dann:
1.) Abfrage aller Sensorendaten (ein Byte, Word oder DoubleWord pro Sensor)
2.) Triangulation zur Errechnung der Puckposition
3.) Durch Vergleich mit der(den) vorherigen Position(en) Richtung und Geschwindigkeit ableiten.
4.) Mit den gewonnenen Daten die SPS füttern.

Ein Microcontroller, wie er zB im Arduino steckt, packt das im Schlaf. Die Datenmengen sind auch nicht wirklich erwähnenswert. Interpolation ist nicht nötig, da der ganze Vorgang in <1 ms erledigt ist.

 

[Wurschti]

@XHotSniperX: Ich komme aus Österreich, genauer gesagt aus der südlichen Steiermark.

@Tumbleweed: Falls alles problemlos funktionieren sollte und wir die nötigen finaziellen Mittel zu Verfügung gestellt bekommen sollten, dann wird sicher früher oder später ein Video davon im Netz landen.

@e-Laurin: Vielen Dank für die ausführlichen Tips und Beschreibungen. Über Ultraschallsensoren habe ich noch gar nicht nachgedacht. Ist eine sehr gute Idee, weil es, wie du schon gesagt hast, viel leichter zu verarbeiten ist. Der einzige Nachteil, der mir dabei spontan in den Sinn kommt, ist, dass die Sensoren wahrscheinlich störanfälliger sind als die Kamera (z.B. durch Bewegungen der Hand und des Schlägers des Spielers). Ich werde die Ultraschallsensoren aber auf jeden Fall bei der nächsten Team-Beprechung vorschlagen. Vielen Dank nochmal dafür

 

[Krik]

Wenn man die Sensoren geschickt positioniert, ist die Messung recht störungsunabhängig. Du kannst die Sensoren zudem nach Abstrahlwinkel und Reichweite auswählen. Darüber kann man recht genau bestimmen, welche Bereiche auf dem Tisch überwacht werden. Es ist klar, dass man das Ganze so anordnen sollte, das keine Bewegung vom Roboter und Spieler erfasst werden können.

Bei einer Kamera hat man viel mehr Probleme, da schon Helligkeitsveränderungen ausreichen (zB Licht anmachen, Sonne scheint ins Zimmer, etc.), dass er nichts mehr erkennt. Und wenn der Puck mal eine andere Farbe hat, fängt man an, den Erkennungsalgorithmus neu zu kalibrieren. Glaub' mir, damit willst du dich nicht abplagen. Man braucht schon sehr viel Geduld, das Ganze so einzustellen, dass es unter bestimmten Licht funktioniert.
Es gibt Leute, die schreiben ihre Doktorarbeit darüber, wie man eine Erkennung unter unterschiedlichen Lichtverhältnissen gewährleisten kann.

Edit:
In meiner Hochschule gibt es ein KI-Labor. Dort programmieren sie Roboter, die zB durch das Schulhaus navigieren, um im Nebenraum einen roten Ball zu holen. Klagelied der Kommilitonen, die das als Projekt hatten: Der Erkennungsalgorithmus für den roten Ball funktioniert nur mit den Lichtverhältnissen am Vormittag (vorwiegend blaues und weißes Licht). Nachmittags (vorwiegend oranges und rotes Licht) und abends (Deckenbeleuchtung, weißes Licht) versagt er einfach.

 

[Wurschti]

Man bräuchte einen Raum, der den ganzen Tag über gleich beleuchtet wird (dunkler Raum mit künstlicher Beleuchtung). Du hast aber Recht, der ganze Aufwand ist eigentlich unnötig, wenn es auch Möglichkeiten gibt das Problem leichter zu lösen. Ich werde mal schauen, ob ich auf die Schnelle irgendwo einen Ultraschallsensor in die Finger kriege, damit ich ein bisschen damit herumexperimentieren kann. Optische Verfahren mit Lichtschranken wären eventuell auch noch eine Alternative.

 

[Krik]

Lichtschranken sind auch eine gute Idee. Allerdings brauchst du dann recht viele davon, da du sie ringsherum anordnen musst, um ein Abtastungsgitter zu erzeugen. Diese Sensoren zeigen ja nur an, ob etwas den Lichtstrahl unterbricht oder nicht.
Wenn man zB zwei Infrarotquellen verwendet, die in den Banden gegenüberliegend eingebaut sind und eine Reihe von lichtempfindlichen Fotozellen verwendet, kann man auch darüber eine Erkennung basteln. Man braucht aber viele Fotozellen dafür. Je mehr, desto genauer kann man die Position des Pucks ermitteln. Ich vermute, es ist unpraktikabel, da man theoretisch hunderte Zellen braucht, um den Weg des Pucks hinreichend genau zu bestimmen.

Entfernungsmessung per Laser ginge auch, aber da weiß ich nicht genau, ob die schnell genug von statten geht. Das müsste auch teurer sein als Ultraschallsensoren. Hier hat man aber unter Umständen dasselbe Problem wie mit der Kamera. Da ja eine Fotozelle verwendet wird, kann die Erkennung wieder durch die Lichtverhältnisse eingeschränkt werden.

Alternativ:
Man könnte auch einfache Näherungssensoren verwenden, zB auf Lichtbasis (Hell/Dunkel-Unterscheidung). Diese kann man in zwei Reihen auf dem Spielfeld einlassen. Wenn der Puck diese zwei Reihen passiert, wird er mindestens zwei Sensoren auslösen, und darüber kann man Position, Richtung und Geschwindigkeit ermitteln. Hier braucht man aber auch wieder viele Sensoren und diese werden eventuell wieder stark von den Lichtverhältnissen beeinflusst. Zumindest kann man hier eine einfache automatische Kalibrierung auf die Lichtverhältnisse zwischen zwei Spielen vornehmen lassen (Sensoren sind nicht bedeckt -> aktueller Helligkeitswert +/- 10% => Sensoren sind nicht bedeckt).


Dennoch halte ich Ultraschallsensoren immer noch für die beste Lösung. Mit nur drei Sensoren (besser vier) kann man ein Großteil des Spielfelds abdecken. Das ist billig und gegen Störungen recht sicher. Zudem kann man den gesamten Weg des Pucks im Sensorbereich ermitteln und das in einer sehr großen Genauigkeit (Millimeter- bis Zentimeterbereich).


Edit:
Noch eine Möglichkeit: Ausnutzung von magnetischen Feldern. Der Puck müsste irgendwie magnetisch gemacht werden (Magnete/Magnetstreifen aufkleben, magnetische Farbe?). Im Spielfeld müsste in den Banden oder unter dem Spielfeld Spulen integriert werden. Huscht der Puck vorbei, induziert er eine Spannung in den Spulen. Die kann man messen und so auf die Distanz schließen. Mit mehreren Spulen kann man so eine Ortung vornehmen. Man muss aber mal untersuchen, ob der Roboterspieler mit seiner Fahrschiene diese Art der Sensoren beeinflusst und ob man diese Beeinflussung herausfiltern kann.

Jedenfalls wäre das bautechnisch recht einfach zu realisieren, da man nur einen Magneten für den Puck und eine Reihe von Spulen mit Spannungsmessgeräten benötigt.

 

[kuddlmuddl]

Ich bin kein ETechniker sondern Informatiker und kann den Aufwand mit Ultraschallsensoren etc nicht einschätzen aber als Bildverarbeiter würde ich dieses Problem selbstverständlich mit einer Kamera lösen. Die von dir rausgesuchte Basler ace GigE ist sicher sehr gut geeignet. Die benutzen wir in Projekten auch oft.
Die wechselnden Lichtverhältnisse mögen in der Robotik nerven, wenn "alles mögliche" im Bild zu sehen ist. Aber bei einem einfarbigen Tisch und einem Puk der dazu einen farblichen Kontrast gibt (egal ob schwarz-weiß oder weiß-orange oder wasauchimmer) wird die reine Puk-Erkennung sicherlich das kleinste Problem an dem Projekt sein.

Der worst-case, der aber alle Probleme beseitigt wäre zB eine einfache semi-automatische Kalibrierung:
Der Benutzer sieht das aktuelle Kamera-Bild und klickt einmal auf den Puk und einmal auf den Tisch. Durch Pixelnachbarn der Klickposition hat deine Software so eine sehr genau Vorstellung davon, wie der Puk aussieht und wie der Tisch. Man könnte also sehr einfach die perfekte Helligkeitsschwelle (falls du nur mit einem Schwellwert arbeitest) bestimmen. Der größte zusammenhängende "Blob" im Bild ist dann halt der Puk.

Hier evtl auch allgemein der Tipp: Benutze nur Farbkameras, wenn du wirklich auf Farbe angewiesen bist. Dh wenn du zb einen grünen Puk auf Blauen Untergrund hast aber das grün und das blau sehr ähnliche Helligkeit aufweisen.
Sofern du nen schwarzen Tisch hast wirst du garantiert mit einer Schwarz-Weiß Kamera bessere Ergebnisse erreichen. Das liegt am Bayer-Pattern.

JavaCV ist sicher eine Möglichkeit aber beim Basler SDK sind soweit ich weiß nur C und C++ Codebeispiele bei, um Bilder von der Kamera zu bekommen. Da gibts dann zB OpenCV.
Welche Sprachen kannst du denn? Die Berechnungen mit 100fps hinzukriegen und für den Puk die Daten Position, Richtung, Geschwindigkeit zu ermitteln ist bei halbwegs vernünftiger Programmierung zB in C++ überhaupt kein Problem. (10ms sind sehr viel für PCs)

Objekt-Tracking in Bildfolgen kann aber tatsächlich ein sehr komplexes Thema sein. Es gibt hier mathematisch sehr komplizierte Ansätze (Kalmanfilter, Partikelfilter/MonteCarlo Methoden). Sowas wirst du aber für eine einfache Puk-Erkennung unter diesen netten Bedingungen nicht benötigen.

edit: Jetzt wo ich mir das Spiel wieder Vorstelle wird mir klar, dass du später evtl doch mehr Intelligenz in das Tracking stecken musst. Der menschliche Spieler wird mit seinem Arm und dem Plastik-Ding was er in der Hand hält den Puk manchmal verdecken. In diesen Momenten kann das Tracking extrem schwierig werden.

 

[Graf-Porno]

Ich würde die Kamera unter den Tisch packen und eine ähnliche Konstruktion wie den MS Surface basteln, mit Infrarot Kameras.
Den Puck an der Unterseite einfach mit einem einfach zu "erkennenden" Marker markieren, das eigentliche Erkennen ist dann ein Kinderspiel. Das Erkennen kannst du dann z.B. mit nem Haar Classifier lösen, in OPEN-CV mit wenig Aufwand zu schaffen http://achuwilson.wordpress.com/2011/07/01/create-your-own-haar-classifier-for-detecting-objects-in-opencv/. Noch einfacher ist wenn du als "Marker" so etwas wie die MS-Tags benutzt http://msdn.microsoft.com/en-us/library/ee804885(v=surface.10).aspx

 

[kuddlmuddl]

Haar Classifier

Ne.. sorry aber das nun wirklich nicht.
Sagt doch schon der Name: "Classifier".
Der Unterscheidet ein Blatt von einer Maus oder eine Hand von einem Fuß. Aber er erkennt nicht etwa einen Puk in einem Bild.
Das sagt auch sofort die von dir verlinkte Seite:
Die reden nur von positive und negative samples. Also von Bilder die das gesuchte Objekt zeigen und Bildern die etwas anderes als das gesuchte Objekt zeigen.

Und wenn eine normale Kamera unter dem Tisch hängt muss die Oberfläche Durchlässig sein.. allein so ein durchsichtiger, nicht verkratzender Tisch ist ein immenser Aufwand. (Luftdüsen...)
Bei einer Infrarot-Kamera (ich habe selbst schon welche benutzt) wirds nicht einfacher. In diesem Fall würde die nötige Geschwindigkeit nicht erreicht werden, da die "Wärme" des Puks ja erst durch die das Spielfeld hindurchmuss um gesehen werden zu können. Da so ein Puk locker mehrere m/s schnell wird ist das unmöglich. Ich bezweifel, dass man den Puk überhaupt mit dem Auge sehen könnte wenn die Infrarot-Kamera das Bild einfach nur darstellt.
Und: Woher bekommt der Puk die wärme? Und dann noch in einem bestimmten Muster?

 

[Krik]

An meiner Hochschule wurde mal ein Touch-Table ähnliches des Microsoft Surfaces gebaut. Für die Erkennung haben sie mit LEDs Infrarotlicht seitlich in das Glas leuchten lassen. Durch (beinah) Totalreflexion wanderte das Licht durch die ganze Scheibe. Berührt man das Glas an einer Stelle, ändert sich der Brechungsindex an genau dieser Stelle und ein Teil des Lichts wird nach unten gestrahlt, wo es von einer Kamera (EyeToy von einer Playstation ^^) aufgenommen wurde. Als Software hat man TuIO, Processing und Java verwendet.

Das könnte man hier auch verwenden, aber es stellt sich die Frage, ob das nicht etwas zu viel des Guten ist. Ich mein', man will ja keine komplexen Gesten erkennen.


@kuddlmuddl
Ultraschallsensoren sind recht einfach zu verwenden. Man steckt sie an einem IO-Port, zB GPIO, und dann kann man den gemessenen Abstandwert abfragen. Position, Richtung und Geschwindigkeit des Pucks muss man dann durch mehrere Sensoren und über Zeit ermitteln. Eigentlich ist das einfach und überschaubar. Ein Raspberry Pi bietet sich hier an. Das hat eine GPIO-Schnittstelle, für die es auch schon eine vorbereitete API gibt. Programmieren kann man hier dann mit C, C++, Python, Java und wahrscheinlich noch einige andere Programmiersprachen mehr.

 

[kuddlmuddl]

Das spiel ist übrigens ganz ähnlich unter dem Namen "Pong" bekannt.
Wenn man nach computer vision und pong googelt (youtubed) kommt auch einiges an interessanten Links

 

[Wurschti]

@kuddlmuddl: Bei den objekorientierten Sprachen habe ich bisher nur mit Java programmiert. Ansonsten kann ich C noch halbwegs gut und mit Assembler habe ich auch schon ein paar Erfahrungen gemacht. Als wie schwierig würdest du die Programmierarbeit bei solch einem Projekt einschätzen? Ich bin eigentlich kein Informatiker, sondern Automatisierungstechniker mit etwas Programmiererfahrung. Falls die Programmierung allzu komplex werden sollte, dann müsste ich einen EDV-Spezialisten ins Boot holen. Danke, dass du dich mit dem Thema etwas beschäftigt hast. Es ist immer gut, verschiedene Ansätze aus verschieden Bereichen zu hören.

@e-Laurin: Nachdem ich mich in letzter Zeit mit den Ultraschallsensoren auseinandergesetzt habe, bin ich dort auch auf ein paar Schwierigkeiten gestoßen. Ich habe bis jetzt keinen Sensor gefunden, der meinen Anforderungen entspricht. Der Sensor sollte einen Erfassungsabstand von ungefähr 1,2m besitzen, wenn er von einer zur anderen Bande reichen soll. Zusätzlich sollte er einen möglichst großen Erfassungswinkel haben. Das Problem dabei ist, dass die Sensoren, die ich bis jetzt gefunden habe, mit diesen Eigenschaften nur Schaltfrequenzen von ungefähr 5-10 Hz haben. 100 Hz und mehr werden nur bei Sensoren erreicht, die ca. 300mm weit reichen. Vielleicht habe ich aber auch nur falsch recherchiert. Sind dir Hersteller bekannt die Ultraschallsensoren mit den geforderten Eigenschaften verkaufen? Anforderungen: >=60 Hz, 1-1,3m Reichweite, Erfassungswinkel so groß wie möglich.

 

[Krik]

Ich habe geschaut und auch keine Sensoren mit deinen Anforderungen gefunden.
Es scheint zu gelten: Je größer der Erkennungsabstand, desto geringer die Schaltfrequenz.
Das ist mir noch nie aufgefallen. Ich hatte immer nur oberflächlich geschaut und was von <große Detektionsreichweite> und <schnelle Schaltfrequenz> gesehen. Dass das so nicht in Kombination auftritt, habe ich nicht erwartet.

Als Alternative: Radarsensor (Ich wusste bisher nicht, dass es solche Sensoren auch für Hobbybastler gibt.)
Die Schaltgeschwindigkeit kann man bis auf 1 ms runterdrücken, Reichweite liegt bei >10 Metern (begrenzbar). Das Ding hat zusätzlich noch den Vorteil, dass man aus den Messergebnissen die relative Geschwindigkeit ableiten kann.
Nachteilig ist, dass man ein Vorverstärker zusammenlöten muss und irgendwas mit dem Puck tun muss, damit er besser erkannt wird.
Schau dir mal an, ob das was für dich ist.