Steeldart automatisieren

  • Hallo zusammen,


    ich spiele gerne Steeldart, da mir aber die Punktezählerei auf die Nerven ging, habe ich angefangen mit ein Dartautomat zu bauen :)


    Der momentane Stand:


    Auf einem Raspberry 3 läuft eine MySql-Datenbank und ein Webserver... Die Berechnung der Punkte übernimmt php.
    Angezeigt wird das ganze auf einen alten 21 Zoll Monitor.


    Neben der Abwurflinie hängt eine kleine "Kiste" mit einigen Buttons um u.a. die geworfenen Punkte und das gewünschte Spiel
    auswählen zu können. In der Kiste sind 4x MCP23017 verbaut um genügend Buttons über I2C anschließen zu können.


    Um akustisch mitzubekommen, ob die gedrückte Taste auch ausgeführt wurde ertönen Töne aus einem am PI angeschlossen
    Lautsprecher, ebenso wenn man Triple 20, 19, 18, 17 geworfen hat.


    Insgesamt läuft es absolut super, bin wirklich Ultra zufrieden !!!



    Nun das i-Tüpfelchen... Automatische Dartpfeilerkennung...


    Im Internet habe ich einige Versuche und Ideen gefunden, um den Treffer des Pfeils zu lokalisieren. Aber was wirklich brauchbaren
    was gut funktioniert und dabei noch bezahlbar ist, habe ich nicht leider gefunden.


    Zum größten Teil waren die Beiträge aber auch schon einige Jahre alt.


    Hat vielleicht einer eine Idee wie man sowas umsetzten kann?



    Ich habe auch verschiedene Ideen im Kopf durchgearbeitet wie zB


    Erkennung durch 2 Utraschall-Sensoren um X und X Kordinaten zu bekommen.
    -> Die Sensoren messen nur einen sehr schmalen weg, der Pfeil müsste also sehr mittig vom Sensor aufkommen. Funktioniert bei der breite einer Dartscheibe leider nicht


    Erkennung durch Ton des Aufpralls...
    -> Soll angeblich sehr genau funktionieren, kostet aber wohl auch eine ganze Stande Geld und ist nicht einfach umzusetzten.


    Erkennung durch mehrere Erschütterungssensoren hinter der Scheibe
    -> Denke bei der Dicke einer Dartscheibe kommt da nicht viel, bzw. keine Punktgenauen Daten an.


    Erkennung durch Pixelauswertung eines Bildes.
    -> Kann ich mir gut vorstellen, dass zB eine Raspberry Kamera eine Foto schießt und dann Farbwerte ausgewertet werden.
    -> Was ich bisher gelesen habe, passiert dieses aber leider nicht in einer angemessenen Geschwindigkeit.



    Was ich ganz Interessant finde wäre die Verwendung eines XBox Kinect Sensors, leider habe ich damit gar keine Erfahrung
    Verbaut wurden unter anderem eine HD Webcam, ein Tiefenschärfen- und Farbsensor sowie ein Mikrofon, welches 3D-Sound erkennen kann.


    Und die ganze Geschichte soll auch auf einem Raspberry Pi laufen. Mit den ganzen Sensoren sollte doch was möglich sein.


    Hat jemand Erfahrung mit dem Kinect Sensor am Raspberry.


    Für jeden Denkanstoß wäre ich dankbar.


    Viele Grüße
    Markus

  • Hallo Markus,
    hast du schon mal daran gedacht, die Dartscheibe mit 2 Kameras zu versehen (z.B. eine von Oben mit Blick nach unten und eine Links mit Blick nach Rechts) und darüber die Position des Pfeiles zu rekonstruieren?


    Für die Idee mit den Ultraschallsensoren sehe ich keine Möglichkeit, die müssten erst mal das Echo des ziemlich schmalen Pfeiles erfassen.


    Wie soll die Erkennung per Ton funktionieren? Mit zwei/drei Mikrofonen und dann den Versatz beim Sound messen, um die Position zu bestimmen? Falls das der Ansatz ist, ist die Kunst das ganze absolut Zeitsynchron aufzunehmen, die Rechenleistung für die Kreuzkovarianz sollte der Pi gut schaffen.


    Die Idee mit der einen Kamera halt ich für machbar, indem du einmal das Feld vor dem Wurf speicherst und dann das Bild mit dem nach dem Wurf vergleichst, der Unterschied ist der geworfene Pfeil.


    Den Tiefensensor des Kinect (2) Sensors halte ich nach meiner Erfahrung für ungeeignet das so genau zu erkennen. Ich habe den an einem normalen PC schon Versuche gemacht und musste feststellen, dass er mit spiegelnden Oberflächen fast gar nicht klar kommt und die Genauigkeit häufig von der Farbe des Objektes abhängt, im Bereich von 200€ sollten da bessere Sensoren möglich sein, die so etwas erfassen können. (Vllt. Kapazitiver Sensor hinter der Scheibe, der die Spitze des Pfeiles erkennt, ähnlich eines Touchscreens beim Handy??)


    Viele Grüße
    Chris

  • Hallo Chris,


    Ja, die Idee mit zwei Kameras hatte ich als aller erstes im Kopf, die eine übernimmt die X- die andere die y-Achse. Leider kam ich an dem Punkt nicht weiter, wo es um die Erkennung der Pfeilspitze geht.


    Ultraschallsensoren fallen def wen... das funktioniert leider nicht.


    Ja genau, so in der Art mit mehren Micros sollte das funktionieren... nur was passiert mit dem Umgebungsgeräuschen? Ich kann mir auch nicht vorstellen, dass einfach USB-Micros dazu in der Lage sind.


    Die Variante mit der Kamera find ich immer noch gut, aber ich hab noch keinen Ansatz wie man zwei Bilder miteinander vergleicht. Die Kunst wird dann wohl sein, dass nur die Spitze des Pfeils und nicht
    der ganze Pfeil berücksichtigt oder ob der Trefferpunkt auch erkannt wird, wenn der Pfeil schief im Board steckt. Was ich bisher gelesen habe ist das ganze wohl recht arbeitsintensiv für den Rechner, bedeutet dass es wohl recht lange dauert bis ein Ergebnis raus kommt...


    Hmm, schade mit der Kinect, ich dachte, dass gerade der Dartpfeil recht gut erfasst werden könnte, da der Pfeil ja im Prinzip das einzige ist, was von der Scheibe "absteht".

  • Hallo Markus,
    dem "arbeitsintensiv" bei der Bildverarbeitung stimme ich zwar zu, aber ein Pi hat ja auch ganz gut Rechenleistung und wenn ich mir anschaue, was einige auf Youtube mit dem Pi und OpenCV schon geschafft haben (Link), sollte die Erkennung von Pfeilen möglich sein. Der Ansatz mit dem Vergleich Vorher/Nachher sollte auch nicht viel Rechenzeit beanspruchen, das ist ja nichts anderes als ziemlich viele Differenzen bilden mit ein bisschen Filterung.


    Wenn man davon ausgeht, dass der Aufprall lauter ist als die Umgebungsgeräusche sollte die akustische Trennung gut funktionieren. Das Hauptproblem bei der Audioaufnahme sehe ich darin, dass die Aufnahme zeitlich synchron sein muss, sonst wird das mit dem Zeitversatz nichts, wenn du ungenauigkeiten von mehreren ms bei der Audioaufnahme hast.


    Gruß
    Chris

    Edited once, last by ChrisvA ().

  • Hi Chris,


    ich glaube die Tonerkennung wird mir "günstigen" Mitteln nicht werden, zumindest nichts genaues.


    Ich muss mal schauen wie man zwei Bilder miteinander vergleicht, mit sowas habe ich mich noch nicht Beschäftigt.


    Vielleicht wäre es auch möglich in einem Bild einen bestimmen Farbwert (den der Spitze) zu suchen.

  • Ich halte die Bildverarbeitung zwar fuer theoretisch möglich, auch auf dem PI. Aber praktisch fuer kompliziert. So etwas unter wechselnden Lichtverhältnissen und den reflektierende, verschiedenartigen Pfeilen stabil zu bekommen ist eine Herausforderung. Wenn du möchtest, kannst du mal eine Serie von Fotos machen & hier hochladen, dann schaue ich mir das mal an. Wichtig dabei:


    - feste Kameraposition.
    - Aufnahmen ohne Pfeil.
    - Aufnahmen mit Pfeil(en) in verschiedenen Positionen und einer hohen Bandbreite von moeglichen Positionen.
    - Aufnahmen unter verschiedene Lichtverhältnissen (tag/nacht mit Beleuchtung etc). Ggf. kann man das auch ignorieren wenn die Scheibe stabil ausgeleuchtet ist.


    Zwei um 90 Grad versetzte Kameras, oder zumindest zwei Perspektiven wären später wahrscheinlich


    Gut waere ein laser range finder, ich habe mal einen von denen hier gehabt: http://www.roboparts.de/Hokuyo-URG-04LX-UG01/de - tolles Teil. Ob die sehr schmale Dartspitze erkennbar ist, ist aber fraglich, und auch die Griffstücke aus Metall machen den Job nicht unbedingt einfacher, ggf. reflektieren die.


    Du könntest aber mal mit einem der SHARP Sensoren wie dem hier spieler: https://eckstein-shop.de/Sharp…IS-zqysqNACFdTNGwodRpsCvg


    Der ist vielleicht etwas zu kurzsichtig, aber es gibt auch weiter schauende Varianten.


    Der hat zwar grundsaetlich das gleiche Problem wie der Ultraschallsensor - kann nur einen sehr schmalen Bereich abdecken. Aber dafür wuerde ich den auf ein Servo montieren, und selber "scannen". Denn du brauchst ja keine hohe zeitliche Auflösung. Dart weg, Dart da. Das kann auch ein paar Sekunden dauern.


    Ob du scannen musst oder nicht, kannst du ggf. mit einem Erschütterungssensor (einfache IMU) rausbekommen.
    Automatisch zusammengefügt:[hr]
    Nachtrag: eine Spitze hat keinen Farbwert - die ist metallisch, das ist leider farbtechnisch ein kompliziertes Ding. Du bekommst helle, ueberstrahlened Reflektoren, und eine ganze Reihe von Farbtönen, die schlimmstenfalls sogar die Umgebung spiegeln. Ich wuerde da eher mit foreground/background separation spielen.


    Du solltest mit Python + der OpenCV rumspielen, damit kann man am flexibelsten eine weite Anzahl an Ansätzen ausprobieren.


    Hier ein Beispiel von Problemen mit metallischen Oberflächen: http://dsp.stackexchange.com/q…84/metal-defect-detection

  • Hallo Markus,


    wie __deets__ schon angeeutet hat, ist die Farbinterpretation von metallisch glänzenden / reflektierenden Objekten nicht trivial - aber machbar.


    Eigentlich ist das auch nicht so wichtig. Jedes Dart-Feld stellt ein Kreissegment dar und ist charakterisiert durch 2 Winkel (gegeüber der Vertikalen & Horizontalen) und zwei Abstände.


    Ein machbarer Ablauf gestaltet sich dann so dar:


    • Bild vor dem Wurf
    • Bild nach dem Wurf
    • ggf. vorher Pixel auf Farbpalette reduzieren, die nur die Grundfarbe eines Dart-Brettes enthält
    • Bilder überlagern (es bleiben dann nur die Unterschiede = letzter geworfener Dart übrig)
    • Ermittlung der Stelle, an der der Dart-Pfeil im Dart-Brett eintaucht
    • Ermittlung des Dartfeldes (als Funktion von Winkel und Abstand)


    Wie __deets__ schon sagte - ohne beispielhafte Photographien kommen wir hier nicht weiter.


    Ich glaube allerdings, dass zwei Kameras nicht genügen werden. Wenn nämlich hinter einem Pfeil ein weiterer in übereinstimmendem Winkel gelandet ist, wird dieser vom vorderen Pfeil verdeckt. Dabei spielt es keine Rolle, in welcher Position / Ausrichtung sich die Kamera befindet. Und je mehr Kameras erforderlich sind, umso länger benötigt die Auswertung bzw. Ermittlung von mindestens zwei Aufnahmen, die zur Ermittlung des Dart-Feldes führen.

    Beste Grüße


    Andreas

    Ich bin wirklich nicht darauf aus, Microsoft zu zerstören. Das wird nur ein völlig unbeabsichtigter Nebeneffekt sein.
    Linus Torvalds - "Vater" von Linux

    • Icon-Tutorials (IDE: Geany) - GPIO-Library - µController-Programmierung in Icon! - ser. Devices - kein Support per PM / Konversation

    Linux is like a wigwam, no windows, no gates, but with an apache inside dancing samba, very hungry eating a yacc, a gnu and a bison.

    Edited once, last by Andreas ().

  • Hallo zusammen,


    ich werde später mal meine PI Cam verbauen und ein paar Testbilder machen, die ich hier poste.


    Andreas: Theoretisch müssten doch zwei Kameras ausreichen... ein Foto von oben, eins von der Seite... So sollten es eigentlich nicht möglich sein, dass ein Pfeil den anderen verdeckt.
    Ich weiß nicht ob ich dein Vorgehen richtig verstanden habe? du würdest also nicht versuchen den Eintauchpunkt zu lokalisieren, sondern schauen welche Felder sich verändert haben?


    Mir fehlt noch ein bisschen der Zusammenhang, wie ich unterschiede ermitteln kann. Lese mich gerade ein bisschen in OpenCV ein...


    Ich gehe gerade nur verschiedene Möglichkeiten im Kopf durch... Ich habe gesehen, dass man Bilder vergleichen kann und dann Übereinstimmungen in %-Werten angezeigt bekommt.
    Kann man evtl ein Raster über die Grafik legen in Form der einzelnen Felder und dann Feld für Feld vergleichen?


    Ich sehe hier vielleicht noch das Problem, dass das Flight als Veränderung erkannt wird und nicht die spitze...
    Wenn das Bild geraster werden könnte, könnte man vielleicht über die %-Angaben die Spitze und nicht das Flight oder den Schaft localisieren.


    Angenommen das 20er Feld... das Flight in einen Bild wird wohl eine niedrigere Übereinstimmung zum Original aufweisen als zb die Spitze... Treffer wäre dann das Raster mit einer Übereinstimmung zB zwischen 75% und 95%.
    und nicht das Flight welches nur 30% Übereinstimmung bringt...


    Aber ich weiß schon warum viele Leute sowas mal versuche haben zu bauen es aber eigentlich nichts gibt... es ist nämlich überhaupt gar nicht einfach :) :) :)

  • Hallo Markus,
    ein Bild in graustufen ist im Speicher nichts anderes als ein 2d-Array mit Zahlen (z.B. bei 8Bit mit Zahlen von 0 bis 255), wenn du jetzt 2 Bilder hast, erhältst du die Differenz (den Vergleich) indem du in beiden Bildern jeweils die Elemente voneinander abziehst. Für gleiche Pixel wird ein wert nahe 0 herauskommen, für unterschiedliche ein Wert, der sich deutlich von 0 unterscheidet. (Kann auch negativ sein!)


    Gruß
    Chris

    Edited once, last by ChrisvA ().

  • Hallo Markus,



    Andreas: Theoretisch müssten doch zwei Kameras ausreichen... ein Foto von oben, eins von der Seite... So sollten es eigentlich nicht möglich sein, dass ein Pfeil den anderen verdeckt.
    Ich weiß nicht ob ich dein Vorgehen richtig verstanden habe? du würdest also nicht versuchen den Eintauchpunkt zu lokalisieren, sondern schauen welche Felder sich verändert haben?


    Wenn zwei Pfeile in der Blickrichtung der Kamera eintreffen, dann ist der weiter entfernt nicht zu sehen.


    Experiment:
    Halte Dir einen Finger (Zeigefinger) direkt vors Auge. Dann nimmst Du den Zeigefinger der anderen Hand und bewegst ihn im Abstand von nur 10 cm dahinter. Bei mir entsteht ein Bereich von ca. 15 °, in dem ich den zweiten Zeigefinger bewegen kann, ohn dass ich ih sehe. Also reicht eine Kamera nicht.


    Wenn der dritte Pfeil rein zufällig auch hinter dem Pfeil eintrifft, in dem er von einem Pfeil auch von der 2. Kamera nicht gesehen wird, dann siehst Du ihn gar nicht.


    Also brauchst Du bei 3 Pfeilen schon mal 4 Kameras um ganz sicher ausschließen zu können, dass der 3. Pfeil auch garantiert von mindestens zwei Kameras gesehen wird.




    Mir fehlt noch ein bisschen der Zusammenhang, wie ich unterschiede ermitteln kann. Lese mich gerade ein bisschen in OpenCV ein...


    Ich würde es ohne OpenCV machen - eine Exklusiv-Oder-Verknüpfung der auf eine GRundfarben enthaltende Palette reicht, um unveränderte Pixel-Ihanlte auf 0 zu bringen. 1 XOR 1 = 0, 1 XOR 0 = 1



    Ich gehe gerade nur verschiedene Möglichkeiten im Kopf durch... Ich habe gesehen, dass man Bilder vergleichen kann und dann Übereinstimmungen in %-Werten angezeigt bekommt.


    Das bringt Dich vermutlich nicht weiter. Du willst ja ermitteln, wo genau die Spitze eintaucht. Theoretisch kann ja die Spitze am Rand eines Feldes so schräg einschlagen, dass nur die Spitze gerade so einschlägt und der Rest des Pfeiles über ganz anderen Feldern liegt. Das führt dann auch zur Annahme, das die Kameras in recht spitzem Winkel bzgl. der Dartscheibe platziert werden sollten.




    Kann man evtl ein Raster über die Grafik legen in Form der einzelnen Felder und dann Feld für Feld vergleichen?


    Kann man - ist doch aber durch die Felder und deren Begrenzung vorgegeben... die Begrenzung hat auch wieder ein Farbmuster, dass von den zu erkennenden Feldern unterschiedlich ist.




    Ich sehe hier vielleicht noch das Problem, dass das Flight als Veränderung erkannt wird und nicht die spitze...
    Wenn das Bild geraster werden könnte, könnte man vielleicht über die %-Angaben die Spitze und nicht das Flight oder den Schaft localisieren.


    Jeder Weg, der dazu führt, dass nicht die Spitze erkannt wird, führt Dich in eine Sackgasse.


    Beste Grüße


    Andreas

    Ich bin wirklich nicht darauf aus, Microsoft zu zerstören. Das wird nur ein völlig unbeabsichtigter Nebeneffekt sein.
    Linus Torvalds - "Vater" von Linux

    • Icon-Tutorials (IDE: Geany) - GPIO-Library - µController-Programmierung in Icon! - ser. Devices - kein Support per PM / Konversation

    Linux is like a wigwam, no windows, no gates, but with an apache inside dancing samba, very hungry eating a yacc, a gnu and a bison.

  • Das ist alles nicht so simpel - einfach ein paar Pixel subtrahieren hilft nicht. Ich habe mal ein bisschen gespielt:


    https://www.dropbox.com/s/obrc2yp14my2krb/dart.mp4?dl=0


    ist ein Video, das so aussieht, wie man das - in etwa - erwarten kann.


    Das lässt man durch folgenden Code laufen:



    Den habe ich dem Tutorial hier entnommen:


    http://opencv-python-tutroals.…on/py_bg_subtraction.html


    Der BackgroundSubtractorMOG ist ein ziemlich abgefahrenes Ding, das durch geschickte statistische Modellierung einen Hintergrund-Repräsentation aufbaut, die robust gegen Rauschen oder schleichende Schattenbildung ist.


    Das Ergebnis ist hier zu sehen:


    https://www.dropbox.com/s/44eo…hle9j/dart-fg-bg.mov?dl=0



    (das ist nicht ganz von Anfang, sondern die zweite Session)


    Und da sieht man schon, vor was vor Herausforderungen man da steht. Die FG/BG-Separation ist state of the art, aber zaubern kann die auch nicht: die Flights sind schwarz, das Brett auch - und da, wo sich das überlappt, kann der Algorithmus auch keinen Unterschied erkennen. Auch sieht man die Schlagschatten sofort.


    Da ist noch lange nicht Hopfen und Malz verloren - man kann zB senkrecht an der Scheibe vorbei auf einen strukturierten Boden oder einem Seitenschirm (ähnlich einer Ampel, die ja auch abgeschirmt ist) schauen. Da wird man andere Dinge sehen bzw nicht sehen. Dann kann man zB zusammenhängende Komponenten gewisser Mindestroessen extrahieren, und wiederum mit einem linearen Fitting deren Richtung bestimmen. Dadurch erreicht man dann zB das man die Richtung des Pfeils erkennt, und des Schattens - und kann eine aufgrund der Kenntnisse über die Geometrie eines von beiden verwerfen. Aus mehreren Perspektiven wiederum berechnet man dann die tatsächliche Postion.


    Das ist aber alles zieeeeemlich abgefahren. Spannend, wenn es mein Projekt waere, hätte ich Spass daran. Aber dafür muss man schon ein bisschen in die Programmier- und OpenCV-Trickkiste greifen. CV-Algorithmen sind etwas .... speziell :)

  • Hallöchen,


    Ja der __deets__ mal wieder! ;)


    Da hast Du schon viele Punkte erwähnt, die man berücksichtigen sollte. Z.B. Zusammenhangskomponenten. Tatsächlich läßt sich aus diesen einiges an Information ziehen. Allerdings besitzen sie auch Ihre Grenzen. Z.B. wenn sich Pfeile kreuzen oder anderweitige Verdeckungen stattfinden. Ebenso ist bei "Farbgleichheit" von Hintergrund und Vordergrund oft eine Lücke im ansich geschlossenen Objekt zu finden, was es dann als zwei kleinere jedoch getrennte Objekte erscheinen läßt. Ein weiterer wesentlicher Punkt ist der der Ausleuchtung. Weiter unten findet sich ein Bild, bei dem der Schatten ein ebengleiches Signal liefert, wie der eigentliche Pfeil. Das ist sehr schwer aufzulösen. Ich habe das Video mal auf die Schnelle durch meine Eigenbau-Videoüberwachungssoftware genudelt. Die Software ist eigentlich eher als Videodetektor für die Freilandüberwachung gedacht und dient der Unterdrückung von dort auftretenden Fehlalarmen. Die Filtereinstellungen habe ich nur grob an das Video angepaßt, um einfach die Probleme aufzuzeigen. Sie lagen dabei wie folgt:


    Die Parameter der Geschwindigkeitserkennung sind zunächst von untergeordneter Bedeutung, auch die der Helligkeitsnormalisierung und Voralarm- wie Nachalarmzeit.
    Mittels der Einstellung der Segmentierung läßt sich die Feinheit der Erkennung einstellen, Ober und Untergrenzen definieren die Anzahl der Segmente, die eine gültige Auslösung kennzeichnen. Liegt die Anzahl zu hoch, dann ist wohl jemand vor die Scheibe gelaufen, ist sie zu klein, dann war's wohl nix. Weiter unten finden sich die Parameter der Zusammenhangsanalyse. Ideal ist das folgende Bild:


    Der Pfeil wird ziemlich genau abgebildet. Dennoch erkennt man schon, daß der Federbereich viel besser abgebildet wird, als die Spitze.
    Eine Feder wirft aber auch Schatten und eng beieinander liegende Objekte (hier die Schatten zweier Pfeile) können miteinander verschmelzen (siehe nächstes Bild).


    Aber selbst wenn Objekte nicht miteinander verschmelzen würden, dann kann ein Schatten äußerst ärgerlich sein, wie man hier sieht:


    Der Schatten ist in etwa so dominant, wie der Pfeil selbst und erlaubt keine Separation der Spitze.


    Alles in allem ist es ein sehr ehrgeiziges Unterfangen, die Spitze eines Pfeils innerhalb einer Dartscheibe per Video erkennen zu wollen. Auch 2 Kameras orthogonal zueinander ausgerichtet haben ihre Schwächen, was man schnell erkennt, wenn man sich vorstellt, daß ein Pfeildirekt unter oder neben einem andern Pfeil zu stecken kommt. Dann ist er für eine Kamera "verborgen". Allenfalls könnte ich mir vorstellen, daß eine farbliche Markierung der Pfeilspitze und ein Anstrahlen z.B. mit IR-Licht geeignet wäre zum einen den Kontrast zwischen Umgebung und Pfeilspitze zu verstärrken und andererseits das Auffinden der Spitze auf dem Board zu vereinfachen. Ähnlich gelingt eine Kontrastverstärkung bei starker Grünanteilgewichtung, wenn man eine (grüne) Wiese überwachen will (mittels Grauwertbildung vergibt man sich Bildinformation). Bleiben allerdings immer noch viele Fragen ungeklärt - z.B. wie lange die Farbe am Pfeil kleben bleibt, nachdem dieser mehrfach in das Board eindrang...


    Im Anhang finden sich noch die restlichen Bilder welche der Detektor mit o.g. Einstellungen aus dem Video zog, inklusive der XML-Beschreibung der Objekte.


    Schöne Grüße


    schnasseldag



    Dart.zip

  • Guten Morgen zusammen,


    zuerst einmal vielen vielen Dank für eure Antworten !!


    Es interessant, aber die Geschichte mit der Bilderkennung übersteigt wohl etwas mein Können,
    da bin ich ganz ehrlich!!


    Ich habe gerade auf Youtube was gefunden, bin mir aber noch nicht sicher ob das vielleicht eine einfacherer
    Lösung sein könnte. Arduino Radar Project


    Ich habe noch einige HC-SR04 (Ultraschallsensoren) zu Hause rumfliegen und auch noch passende 2 Schrittmotoren.


    Das werde ich nachher mal ausprobieren... Meine Idee war nun zwei Motoren zu verbauen...
    einen über dem Board und einen an der Seite... zuerst mal mit zwei Sensoren... möglich wäre
    aber auch pro Motor zwei Sensoren, dass jeder Sensor nur einen Teil des Board erfasst. So sollte man schneller
    Treffer erfassen können


    Alternativ könnte man auch Sharp GP2Y0A21YK0F (Abstandmessung mit Infrarot) testen.
    Hat mit den Sharps schon einmal jemand gearbeitet?


    Theoretisch könnte man auch noch mehr Sensoren und Motoren nutzen. Oben, unten, links und rechts.



    Bin mir nur nicht sicher, ob die Pfeilspitze nicht zu dünn sind um erkannt zu werden, könnte ich mir gut vorstellen.



    Eine Frage hätte ich noch... Habt ihr eine Idee wie man den Treffer dann berechnen kann....
    Angenommen die beiden Senoren erfassen den Pfeil als Ergebnis bekommt man y =22,4cm x= 19,3cm...


    Wie hinterlege ich am besten, dass das die große "Single 20" ist und dann y =23,7cm x= 20,9cm es ebenfalls ist.


    Ich kann ja nicht für jeden Millimeter x und y festlegen in welchem Feld man sich befindet :huh:


    Viele Grüße


    Markus

  • Hallo Markus,
    die Wertigkeit kannst du relativ einfach erhalten, wenn du die x-/y-Position in Zylinderkoordinaten (bezogen auf den Feldmittelpunk) umrechnest. Die Reigenfolge der Zahlen musst du natürlich immer noch abspeichern.


    Gruß
    Chris

  • Hi Chris,
    heißt praktisch alles ausmessen... =(


    Vielleicht eigentlich nicht schwer, aber es sind dann halt Positionsdaten...


    Meine Idee wäre gerade, da es sich ja um einen Schrittmotor handelt, für jeden Schritt Entfernungen festzulegen in welchem Feld man sich gerade befindet.


    Jeder Schritt hätte wohl max. 16 Felder (kurz neben dem Bull) die durchlaufen werden können, weiter entfernt vom Bull werden es auch weniger Felder.
    So müsste man für jeden Schritt die Entfernungen festlegen...


    Also zum Beispiel nur theoretisch... muss natürlich genau ausgemessen werden


    Motorposition: 70, Distanz: 38mm


    0 - 10mm = Doppel 6
    11mm - 70mm = Einfach 6
    71mm - 81mm = Dreifach 6


    Ergebnis "Einfache 6"


    Liefert der 2. (und evtl. der 3. und 4.) Sensor am Ende auch die "Einfache 6" zurück, ist die Wahrscheinlichkeit
    wohl recht hoch, dass der Pfeil auch tatsächlich in der "Einfachen 6" steckt.


    Exakt diese Werte der Sensoren müsste man später beim zweiten Wurf ignorieren, damit der erste Pfeil nicht gewertet wird...


    Das es vielleicht nicht 1000% funktioniert ist mir klar !! Toleranzen in den Messungen sind natürlich vorhanden,
    aber wenn ein großer Teil der Treffer richtig erkannt wird bin ich schon sehr glücklich!!


    Ich habe gerade etwas von 15° gelesen, indem das Objekt auftauchen muss, dann sollte man wahrscheinlich noch nicht einmal für
    jeden Schritt des Motors Daten angeben, sondern vielleicht nur für jeden 5 Schritt


    Ist sicherlich viel Bastelarbeit Softwareseitig, aber das traue ich mir absolut zu.


    Hoffentlich wird auch der Pfeil erkannt!!


    Ich werde berichten!!




    PS: Hat jemand Erfahrung mit der Genauigkeit der verschiedenen Sensorarten? Ultraschall, Infrarot oder sogar Laser?
    Welchen Sensor würdet ihr Empfehlen?


    Preis/Leistung sollte natürlich stimmt!
    Zum Beispiel ein Laser für 200 Euro für ein kleines bisschen mehr Genauigkeit wäre übertrieben.

  • Du wirst ohne Kalibration nicht hinkommen. Dazu reicht es ggf. ein Modell der Scheibe zu hinterlegen, und dann einige bestimmte Punkte einzumessen, zB obere linke Kante von 3-20 etc. Daraus fällt dann letztlich nix anderes als eine affine Transformation, sprich eine Matrix, mit der du die Sensorergebnisse multiplizierst.


    Auch die Spitzen zu erkennen halte ich fuer eher schwierig bis unmöglich. Stattdessen eher auf die Griffstücke zu gehen, und dafür aber zwei Messebenen einzubauen, um einen Schrägstand Rückrechnen zu können.


    Fang erstmal klein an. Hol dir den SHARP-Sensor (habe ich ja schon weiter oben empfohlen), häng ein Oszi dran, leg die Dartscheibe waagerecht auf den Tisch. Pack dir einen Holzklotz oder Zeitschriftenstapel daneben, und beweg den Sensor mit einer Schwingbewegung rum. Dann siehst du schon recht gut, wie der reagiert.


    Auch deine Schrittmotoridee ist nicht so ohne weiteres umsetzbar. Eine Dartscheibe hat 45 cm Durchmesser, ein üblicher Schrittmotor 200 Schritte/Umdrehung, oder 1.8 Grad pro Schritt. Ein Sensor, der jetzt an einer Ecke der Scheibe direkt dran sitzt (und das ist der Optimalfall!) überstreicht also in 1.8-Grad schritten eine Fläche mit 45 cm Radius. Am Ende dieses Radius hast du *pro Schritt* bereits 1.4cm pro Abtastschritt!


    http://www.arndt-bruenner.de/mathe/scripts/kreissehnen.htm


    r=45
    alpha=1.8
    s -> 1,413658558064


    Damit tappst du also einmal rüber über deinen Dart, und siehst *nix*.


    Also in meinen Augen sind folgende Schritte zu tun:


    - erstmal Sensor ermitteln. Ich wuerde mit den Sharps anfangen. Testen wie oben beschrieben.
    - Sensoransteuerung entwerfen. Abtastgenauigkeit von etwa einem halben Grad anpeilen! Das kann auch ein Schrittmotor, muss dann aber mit Mikroschritten angesteuert werden - das hat Konsequenzen fuer die Ansteuerung.
    - Kalibrationsstrategie entwerfen.

  • Hi Deets,


    ja, ich fang klein an und teste erstmal die Ultraschall Sensoren... davon habe ich noch bestimmt 6 stück zuhause rumliegen und zwei
    Schrittmotoren ebenfalls.


    Die haben allerdings keine 200 sondern 512 Schritte pro Umdrehung. Somit sind wir ja rund übern Daumen schon bei 0.5cm


    Das der Pfeil vielleicht übersprungen wir kann sein, aber gemessen hat er ja trotzdem (Er sendet wohl 50x p. Sek.) es fehlt dann nur die Position da könnte man
    einfach die letzte bekannte Position nehmen, oder die letzte und die nächste und dann ein Mittelmaß finden.


    Wie gesagt, da muss ich viel testen, aber wenigstens teste ich Sachen die ich einigermaßen verstehe im Gegensatz OpenCV :D


    Wenn es grundsätzlich funktioniert, kann man ja immer noch Feintuning betreiben, mit andere Sensoren zum Beispiel.


    Ich werde auf jeden Fall berichten!!!!!!

  • Mit 512 Schritten reicht's zwar, du nennst gerade selbst einen guten Hinweis: wenn der Sensor eine Diskrete Abtastrate hat, darfst du den Motor natuerlich nicht schneller bewegen. Also bei 50Hz ungefähr 10 Sekunden pro Umdrehung. Das ist langsam, du brauchst aber auch nur ~90 Grad.


    Und interpolieren... schwierig. Die Entscheidung Trippel-20 oder nicht haengt ja an 3mm, da kann man nicht so allzu Großzügig sein. Aber das wird man dann sehen.

  • Ich bin gerade über etwas gestoßen das dir auf jeden Fall helfen wird und zwar: Pixy.


    Das ist eine Kamera mit eingebauter Objektekennung, Schau dir das hier mal an: http://5volt-junkie.net/pixy-cmucam5/


    Ich würde den Red dot einlesen zum Kalibrieren und dann kannst du auch bestimmen wo die Dart Pfeile gelandet sind. Ausserdem erkennt er dann auch automatisch wenn die Pfeile raus gezogen werden :)

  • Hast du dir mal diesen Thread und deine eigene Seite ernsthaft durchgelesen? Kann ich mir nicht vorstellen, denn sonst waere die Antwort "auf jeden Fall NICHT helfen wird". Das Ding erwartet ein klar farblich separiertes Objekt zum tracken. Was klar nicht der Fall ist fuer einen Pfeil, wie hier in Videos schon belegt wurde. Selbst *wenn* man einen Neonpfeil bastelt und verwendet - die Antwort "dessen Schwerpunkt ist bei x/y" hilft gerade mal gar nix. Man muss die Spitze erfassen bzw extrapolieren, und dazu braucht man die gesamten Kontourinformationen (und sogar Schatten), um den Schnittpunkt mit der Scheibe zu errechnen. Etc....


    Was das mit dem "red dot" (Bullsyeye?) zu tun haben soll erschliesst sich mir auch nicht.