[Machine Vision] Pooltafel analyseren

[Verwijderd]

Doel
Ballen op een pooltafel waarnemen en detecteren vanaf een stabiel ( desnoods afgesproken ideaal perspectief ) punt.

Problemen
In het algemeen, hoe pak je dit aan. Ik heb hier een aantal boeken die aan Machine Vision gerelateerd zijn ( Machine Vision, theory algorithms and practicalities en Computer vision & image processing ) maar vind het lastig de juiste technieken te kiezen, waarschijnlijk wegens gebrek aan ervaring. Nu ik natuurlijk zelf wekenlang kan gaan stoeien en allerlei combinaties kan implementeren van de voorgestelde algorithmen uit de literatuur, is mijn vraag of er mensen zijn die ervaring hebben met dergelijke projectjes als deze.

Zelf
Zoals ik net noemde heb ik een aantal dingen geprobeerd uit de genoemde boeken. Allereerst thresholding, maar dit werkte niet omdat de lichtomstandigheden bij het poolcentre (dag/nacht cyclus) nogal het beeld verstoren. De 9 (half dus) is met vervelende intensiteit van licht in de middag haast niet te onderscheiden van de cueball. Hoewel dit geen groot probleem hoeft te zijn ( fel licht komt weinig voor, meestal aardige verdeling van kleuren die je kan onderscheiden als je de kleur van het laken gebruikt als filter op de achtergrond.

Aan objectherkenning ben ik nog niet toegekomen omdat ik eerst een 'solide' manier wil hebben om de individuele ballen te herkennen ( markeren, beter gezegd ) op een afbeelding genomen via een webcam/hd camera/hoe dan ook ( snelheid is niet per se een issue, HD camera met een afbeelding verwerking iedere 5 seconden ) is ook acceptable voor nu.

Wat betreft de taal kies ik het liefst voor C# ( mooie taal ) maar ik voel me ook thuis in C++, Java of andere talen. Ik heb gekeken naar de library van Intel ( OpenCV ) maar de wrapper voor C# vond ik niet fijn werken omdat het halve implementaties waren ( OpenCV.net ) of er was wat anders mee. Tips in die richting zijn ook welkom, kan ook zijn dat ik wat fout doe

Dus nu komt mijn vraag neer op:

Zijn er mensen met ervaring in machine vision, die mij richting kunnen geven waar te zoeken?

[increddibelly]

tof project

je zou eens kunnen kijken naar Reactable.

Moet er wel bij zeggen dat die app is gebaseerd op stickers / labels met patronen die slechts om 1 as roteren, het is niet dat ze ronddraaien zoals de ballen op een pooltafel.
Het is dus niet direct bedoeld voor jouw onderwerp, maar kwalitatief erg ok en open source. Wellicht zijn (delen) inzetbaar voor jouw toepassing.

edit:
linkje ReacTIVIsion
Reactable op youtube

[ Voor 17% gewijzigd door increddibelly op 07-04-2010 17:39 . Reden: links ]

[Jaap-Jan]

Misschien kun je gebruik maken van een aantal van feiten bij pool:

1) De ballen hebben bij de start een vaste positie
2) Elke bal heeft een andere kleur en is heel of half
3) Er zijn maximaal 16 ballen op tafel (waarvan 1 cueball)

Je kunt:
4) Bijhouden waar elke bal heen is gegaan
5) Bijhouden welke ballen zijn weggespeeld

Als er twee ballen worden herkend als de cueball, analyseer beide nogmaals, maar nu met ander contrast/ brightness. Kan er geen verschil worden opgemerkt, dan is de camera niet geschikt voor dat doel.

De tips zijn praktisch en sommige specifiek voor pool, maar beeldherkenning is lastig en elke hulp die je kunt gebruiken om juist te analyseren is meegenomen. We hebben zelf meegedaan aan RoboChallenge en daarbij was het vooral zaak om het contrast flink op te schroeven (ballen krijgen een duidelijke kleur) om de beeldherkenning goed te laten verlopen). Bij die wedstrijd was de hoeveelheid licht in de zaal behoorlijk constant, dus hier moet je wat dynamischer te werk gaan.

[Verwijderd]

increddibelly schreef op woensdag 07 april 2010 @ 17:35:
tof project

je zou eens kunnen kijken naar Reactable.

Moet er wel bij zeggen dat die app is gebaseerd op stickers / labels met patronen die slechts om 1 as roteren, het is niet dat ze ronddraaien zoals de ballen op een pooltafel.
Het is dus niet direct bedoeld voor jouw onderwerp, maar kwalitatief erg ok en open source. Wellicht zijn (delen) inzetbaar voor jouw toepassing.

edit:
linkje ReacTIVIsion
Reactable op youtube

Ik ken het project, heb het willen nabouwen op school maar dat duurde te lang en moest switchen naar ander project wegens animo te kort vanuit docenten en medestudenten. Heb toen een 'intelligent bierglas' gemaakt haha, die wist hoeveel er nog in zat en aangaf, qua gebruikspatronen, aan de bediening of ze nieuwe moesten brengen. Oftewel efficientere bediening. MAargoed, dat is ander project

Ik vind het lastig om een goede manier te vinden om de tafel te analyseren. Ik zat te denken om de meest aanwezige kleur in de afbeelding te zoeken en punten te geven aan de kleur als deze meer in het centre van de afbeelding zat. Hierdoor zou ik, mits de camera goed staat op de tafel, altijd de hoofdkleur kunnen vinden ( met kleine marge ) van het laken. Welke kleur het dan ook is. Die filter ik er dan uit en dan hb ik alleen de omgeving en de ballen nog over ( aangenomen dat de camera schuin staat en niet direct boven de tafel , zodat je geen omgeving ziet ( zoals bij snooker vaak ) ).

Probleem is echter dat ik dan nog de randen vande pooltafel moet kennen om later de pockets te herkennen en om false positives uit te sluiten als iemand met een poolbal langsloopt of andere tafels die zichtbaar zijn op de afbeelding ( dan wel deels, enkele ballen, hoe dan ook )

Jaap-Jan schreef op woensdag 07 april 2010 @ 17:41:
Misschien kun je gebruik maken van een aantal van feiten bij pool:

1) De ballen hebben bij de start een vaste positie
2) Elke bal heeft een andere kleur en is heel of half
3) Er zijn maximaal 16 ballen op tafel (waarvan 1 cueball)

Je kunt:
4) Bijhouden waar elke bal heen is gegaan
5) Bijhouden welke ballen zijn weggespeeld

Als er twee ballen worden herkend als de cueball, analyseer beide nogmaals, maar nu met ander contrast/ brightness. Kan er geen verschil worden opgemerkt, dan is de camera niet geschikt voor dat doel.

De tips zijn praktisch en sommige specifiek voor pool, maar beeldherkenning is lastig en elke hulp die je kunt gebruiken om juist te analyseren is meegenomen. We hebben zelf meegedaan aan RoboChallenge en daarbij was het vooral zaak om het contrast flink op te schroeven (ballen krijgen een duidelijke kleur) om de beeldherkenning goed te laten verlopen). Bij die wedstrijd was de hoeveelheid licht in de zaal behoorlijk constant, dus hier moet je wat dynamischer te werk gaan.

Klopt, maar ik zie 'bijhouden van positie, snelheid, etc' als fase 2. Ik moet eerst weten waar ze zijn, in de eerste plaats ( of het nou via het initiele rack is of via een willekeurige positie van ballen ). Als ik contrast ga gebruiken dan denk ik dat er problemen optreden met halve ballen ( tot nu toe zo geweest ).

Heb ook tijdje met zon standaard vision programmatje gewerkt ( naam even kwijt ) en die bevatte allerlei filters, camerasupport en je kon er ook extensies voor schrijven. Dat heb ik gebruikt voor een project om lichtbewegingen van objecten te gebruiken om te 'schilderen' door de te bewegen met licht. Je kent het wel.

[ Voor 31% gewijzigd door Verwijderd op 07-04-2010 17:47 ]

[NickThissen]

Als je het hele spel altijd van voor af aan kan zien, dan hoef je alleen de posities van ballen te kennen; je "weet" al welke bal het is omdat de ballen een vaste beginpositie hebben.
Met andere woorden, je hoeft alleen te weten dat er "een" bal ligt; je hoeft niet mbv de camera te kunnen 'zien' welke bal het daadwerkelijk is, omdat je die informatie kunt berekenen door de positie van die bal in de beginsituatie te bekijken.

Dit werkt natuurlijk niet als je midden in een spel begint met 'filmen', en ook niet als de camera slechts 1 keer per 5 seconde een afbeelding maakt, want dan krijg je situaties (vooral met botsingen tussen veel ballen, zoals de allereerste stoot) dat je dingen gaat missen. De camera moet snel genoeg zijn om na een botsing te kunnen weten welke bal welke kant op ging.

Dus het probleem van het onderscheiden van de ballen los je hier mee op, maar je krijgt er wel nieuwe problemen bij.

(Nou ja, in principe zou je dat ook nog kunnen doen door te interpoleren. Stel dat je twee ballen ziet op tijdstip t1. Op tijdstip t2 zijn de ballen iets dichter bij elkaar gekomen (je kunt nu de richting van de ballen bepalen). Op tijdstip t3 zijn de ballen al gebotst (de botsing heb je dus gemist), maar je kunt uit de vorige richting en de nieuwe richting opmaken welke bal welke moet zijn. Dan word het nog een stukje lastiger.)

[ Voor 44% gewijzigd door NickThissen op 07-04-2010 18:25 ]

[Verwijderd]

NickThissen schreef op woensdag 07 april 2010 @ 18:21:
Als je het hele spel altijd van voor af aan kan zien, dan hoef je alleen de posities van ballen te kennen; je "weet" al welke bal het is omdat de ballen een vaste beginpositie hebben.
Met andere woorden, je hoeft alleen te weten dat er "een" bal ligt, en niet welke.

Dit werkt natuurlijk niet als je midden in een spel begint met 'filmen', en ook niet als de camera slechts 1 keer per 5 seconde een afbeelding maakt, want dan krijg je situaties (vooral met botsingen tussen veel ballen, zoals de allereerste stoot) dat je dingen gaat missen.

Dit is niet waar. Je weet nooit welke bal welke is. De ballen hebben geen vaste positie in een rack, niet bij straight, niet bij 8ball, niet bij 9ball en ook niet bij 10ball. JE weet hoogstens de zwarte bal, blauwgestreepte bal of 9ball. Je kunt bij 8ball zeggen dat de 2 ballen in de hoeken van het rack half en heel zijn maar je weet dan nog niet welke. Daarnaast moet je, hoe dan ook, weten welke bal welke is ook al heb je die beginsituatie want je moet ze kunnen bijhouden, hoe weet je anders waar welke bal heen is gegaan na een break? Je kunt niet de verwachte richting voorspelling want die is afhankelijk van afstoot, je rack, de tafel, etc.

[NickThissen]

Huh? Voor zover ik weet beginnen de ballen in die driehoek toch altijd op dezelfde manier? Zo niet dan heb ik het altijd fout gespeeld (goed mogelijk hoor ).

En als je de ballen bijna in real-time kunt tracken, dan weet je dus van elke bal waar hij was op het begin, en dus ook welke bal het zou moeten zijn (aangenomen dat de ballen goed lagen op het begin, zo niet dan houd alles op). Als de camera te traag is kom je inderdaad in de problemen.

Ik zie het zo: stel dat je elke bal kunt bijhouden, maar je kunt niet zien welke kleur het is (stel dat de camera alle ballen als wit ziet). Op het begin weet je welke bal waar ligt (nou, dat neem ik dan maar even aan, als dat niet zo is dan houd het op). Dus, bij de eerste stoot kan je programma alle ballen tracken. Hij weet hoe de bal in de linkerbovenhoek (bijvoorbeeld) bewogen heeft, en hij weet natuurlijk dat het de bal in de linkerbovenhoek was, en dat is dan de .... bal (geen idee welke), omdat die in de linkerbovenhoek begint.


EDIT
Hm, volgens wikipedia heb je gelijk. Dan werkt mijn methode dus niet. Of je moet al voor elk spel gaan invoeren welke bal je waar hebt neergelegd, maar dat is natuurlijk niet ideaal.

[ Voor 45% gewijzigd door NickThissen op 07-04-2010 18:33 ]

[Hydra]

Gaaf project

NickThissen schreef op woensdag 07 april 2010 @ 18:26:
Huh? Voor zover ik weet beginnen de ballen in die driehoek toch altijd op dezelfde manier? Zo niet dan heb ik het altijd fout gespeeld (goed mogelijk hoor ).

Afgezien van de zwarte bal liggen de rest van de ballen min of meer random in het rack verdeeld. Of leggen jullie ze op numerieke volgorde ofzo?

@TS: Misschien zou je kunnen proberen de cueball te herkennen aan het begin. Omdat deze wit is kun je min of meer een witbalans vaststellen. Ook kun je overwegen om (tijdelijk) een stuk wit op de tafel te plakken om de witbalans te vinden.

[ Voor 21% gewijzigd door Hydra op 07-04-2010 18:48 ]

[Zoijar]

http://www.cgg.cvut.cz/members/sykorad/Sykora08-EGVE.pdf

http://www.google.com/#hl...rfai=&fp=a2bb30ecf4f91972

Eerst segmentatie / region detection, dan statistiek op je blobs om het middelpunt van ballen te berekenen, dan je camera calibratie etc gebruiken om echte posities op tafel te berekenen. Ik zou het 2D houden, dus aannemen dat een bal altijd op het tafelvlak ligt. Anders heb je niet genoeg aan alleen het middelpunt.

(dat eerste paper is een vrij simpele approach; die tweede is vrij geavanceerd vanwege "photometric invariance"; i.e., onafhankelijk van de belichting toch regions detecten, dus ook highlights en shadows etc. Ik dek dat je op het moment meer aan dat eerste paper hebt voor een idee. Later kan je het verbeteren...)

[ Voor 23% gewijzigd door Zoijar op 07-04-2010 18:54 ]

[Verwijderd]

NickThissen schreef op woensdag 07 april 2010 @ 18:26:
Hm, volgens wikipedia heb je gelijk. Dan werkt mijn methode dus niet. Of je moet al voor elk spel gaan invoeren welke bal je waar hebt neergelegd, maar dat is natuurlijk niet ideaal.

Haha, ik was vrij zeker van me zaak, gezien ik toch al jaren competitie en rankingtournooien speel Wat je vaak hoort is dat men alle ballen om en om ( half, heel, half, heel ) willen hebben in het rack, maar volgens de officiele 8ball regels is dit helemaal niet vereist. De buitenste 2 moeten verschillende zijn en zwart in het midden. Bij andere speltypen als 9-ball kun je nog zeggen dat de 1 op de voorste plek moet liggen. Verder kun helaas weinig afleiden aan de hand van de positie van de ballen.

Hydra's opmerking over vaste volgorde kun je zien als een specifieke versie die je best kan toepassen. Als daarbij de 2 ballen aan de zijkanten anders zijn en zwart in het midden,dan kun je altijd nog een vaste volgorde voor jezelf afspreken voor deze situatie. Dat kan helpen maar dan nog is het erg foutgevoelig want als je camera paar seconden het beeld kwijt is dan kan de hele tafel al anders liggen ( lompe spelers .. ) .

Dus state waarin alle ballen bekend zijn moet ook gemaakt kunnen worden vanuit nieuwe afbeelding. Beeld is telkens 'nieuw' en dit wordt dan met de huidige 'state/memory' vergeleken. Ik zou dan op dit laatste constraints plaatsen, als er aannamen te doen zijn uberhaupt

Zoijar schreef op woensdag 07 april 2010 @ 18:51:
http://www.cgg.cvut.cz/members/sykorad/Sykora08-EGVE.pdf

http://www.google.com/#hl...rfai=&fp=a2bb30ecf4f91972

Tof, ga ze even uitprinten en lezen. Moet over 2 uur trainen, dus heb nog even Zal wel weer voor nerd uigemaakt worden als ik met cue-tas en laptop-tas aan kom zetten Ik heb de eerste even snel bekeken en een reactietijd van 11ms om 3d positie te bepalen is wel lekker snel, even lezen wat de constraints zijn.

[ Voor 16% gewijzigd door Verwijderd op 07-04-2010 18:55 ]

[G70boX]

Ik zou toch eens kijken naar de OpenCV C/C++ varianten (http://opencv.willowgarage.com/wiki/.) Ik heb zelf eigenlijk alleen met de C api gewerkt dus over de C++/C# varianten kan ik niet teveel zeggen. Het C gedeelte is overigens wel redelijk goed met C++ te combineren dus laat dat je niet afschrikken.

OpenCV heeft best een groot aantal nuttige computer vision/image processing algoritmen en datastructuren die je leven een stuk makkelijker kunnen maken. Er zijn op google zat tutorials te vinden om met OpenCV aan de slag te gaan.

[ Voor 7% gewijzigd door G70boX op 07-04-2010 19:02 ]

[NickThissen]

Hydra schreef op woensdag 07 april 2010 @ 18:46:
Gaaf project


[...]


Afgezien van de zwarte bal liggen de rest van de ballen min of meer random in het rack verdeeld. Of leggen jullie ze op numerieke volgorde ofzo?

Ik heb me altijd laten vertellen dat ze inderdaad op numerieke volgorde moeten, haha. Ik speel het dan ook zelden en ken de regels niet echt.

[Loy]

Voor een OpenCV-wrapper naar C# zou je misschien eens kunnen kijken naar Emgu.

Maar om te experimenteren met je beeld is om te beginnen VisionLab best handig. Je kunt stap voor stap nieuwe image processing-stappen loslaten op je gemaakte afbeeldingen.
Er zit een threshold Isodata-functie in, die je threshold bijstelt op basis van het histogram (o.i.d ).

Leuk project, ben benieuwd wat het wordt. Als dit lukt kun je straks ook de bingo bij je oma automagiseren

[Verwijderd]

Loy schreef op woensdag 07 april 2010 @ 19:49:
Voor een OpenCV-wrapper naar C# zou je misschien eens kunnen kijken naar Emgu.

Maar om te experimenteren met je beeld is om te beginnen VisionLab best handig. Je kunt stap voor stap nieuwe image processing-stappen loslaten op je gemaakte afbeeldingen.
Er zit een threshold Isodata-functie in, die je threshold bijstelt op basis van het histogram (o.i.d ).

Leuk project, ben benieuwd wat het wordt. Als dit lukt kun je straks ook de bingo bij je oma automagiseren

Ah kijk, tof. Ik ga dit even snel op me laptop zetten en dan richting HOB nijmegen Eens zien wat er te doen is vandaag

[HuHu]

Je kunt ook eens kijken naar de Hough Circle Transform. Je poolballen hebben altijd dezelfde grootte in je beeld, dus je zit met niet-overlappende cirkels met een vaste diameter. Dan moet een Hough niet al te lastig zijn denk ik.

Als je converteert naar een andere kleurruimte (van RGB naar LUV bijvoorbeeld), kun je belichtingseffecten redelijk ongedaan maken.

[nephilimcrt]

Misschien een wat late reply, maar onderstaande link legt op een begrijpelijke en duidelijke manier een paar mooie computer vision technieken uit, waaronder 'blob tracking'. Dit lijkt me voor kleurrijke poolballen op een groene achtergrond een mooie oplossing...

http://www.societyofrobot...vision_tutorial_pt3.shtml