Hallo Zusammen,
ich habe nun schon eine weile die Idee im Kopf und auch schon etwas
recherchiert, aber leider noch keinen konkret passenden Hinweis
gefunden, ob sowas überhaupt mit derzeit erhältlichen Bauteilen im
Bastelbereich(!) machbar ist.
Was ich möchte:
- Einen s/w QR-Code in einfachster Form, also ohne mögliche "Schnörkel"
mit einem günstigen Kamera-Modul und einem ATMega oder STM32F1
Controller einlesen
- Die Informationsmenge im QR Code sollte so ca. 32 Zeichen sein, was in
meinem Beispiel (siehe Anhang) zu einem Bild mit 25x25 Pixel führt (Bild
im Anhang ist absichtlich mit mehr Pixel um es besser zu erkennen ;-) ).
Das ganze soll als Konfigurationshilfe für Spiele dienen, der QR-Code
bietet hier den Vorteil, dass er sich einfach erzeugen lässt und
entweder direkt auf Spiel-Bestandteile gedruckt wird, oder auf einen
Aufkleber und dann auf eine Plane Fläche einen Spiel-Bestandteils.
Ziel wäre dass die Hardware für das Einlesen des QR-Code bei den
einschlägigen EBay oder dt. Händlern für unter 20€ zu haben ist. Die
Erkennung des Qr-Codes sollte unter 3 Sekunden liegen
Das Gebiet der Kameramodule ist für mich noch sehr neu, weswegen ich
hier keine Erfahrung habe, worauf ich für mein Vorhaben achten sollte.
Wenn ich es richtig Verstanden habe bekomme ich von solch einem
Kameramodul die Pixel zeilenweise seriell oder in Pakteten zu einigen
Bit geliefert.
Beim einlesen der Pixel würde ich dann erst mal versuchen, zu erkennen
in welchem Bereich des Gesamtbildes der QR Code liegt (Vorgabe wäre
dazu, dass im gesamten Sichtbereich der Kamera nur der QR Code ist und
drumherum alles weis (ich weiß, dass es der Kamera als Grau erscheinen
wird).
Den Code selbst würde ich dann mit 100x100px in den Speicher legen und
dann diesen Speicher analysieren.
µC mäßig habe ich eigentlich die ganze Palette da, also vom Arduino Nano
über ATMega128A Development-Boards (Viel I/O) zum STM32F103 Blue-Pill
Board.
Nun die Frage, mit welchem Kamera-Modul fange ich am besten an?
Und hat jemand mit dem Thema schon Erfahrung oder ggf. Links?
Danke schon mal
spess53 schrieb:> Hast du kein Handy?
Ok sorry kam wohl nicht klar rüber, mir geht es nicht darum, den QR Code
"irgendwie" zu lesen, sondern mit dem µC, damit ich die Information im
QR Code für die Basteleien mit dem µC nutzen kann.
z.B. um einfach die Spielernamen einzulesen, ohne lange mit einem Rotary
Encoder die einzelnen Buchstaben einzustellen.
Das dekodieren des QR-Codes selbst ist nicht schwierig.
Schwierig ist die Bilderkennung. Dafür brauch man schon ein bisschen
mehr Rechenleistung. Häufig werden Neuronale Netze angewendet, die
darauf spezialisiert sind, QR-Codes im Bild zu erkennen.
Nachdem die Position und Ausrichtung des QR-Codes im Bild bekannt, wird
es extrahiert und in eine Bitfolge umgewandelt.
Die Google-Goggles-App kann jede menge Barcodes erkennen und dekodieren.
Christian K. schrieb:> Schwierig ist die Bilderkennung.
Es würde mir reichen, wenn ich zusätzlich noch einen Knopf drücken muss
um zu sagen, dass nun ein relativ(!) gut ausgerichteter QR Code vor der
Kamera ist, d.h. im Prinzip kann dann einmalig das Bild eingelesen
werden und dann verarbeitet. Ist zwar nicht gerade ergonomisch, aber für
meinen Einsatzbereich ausreichend.
Mir geht es auch drum erst mal zu wissen auf welche Eigenschaften ich
bei den Kameramodulen achten muss.
@pegel: Danke für das Video schaue es mir gleich an, auch wenn es
vermutlich oversized für meine Anwendung ist, kann ich vielleicht
Grundlagen-Infos rausziehen
Hier noch ein Bild, eines meiner Spiele, wofür ich es gerne einsetzen
würde. Ist ist eine Variante des Würfelspiels Kniffel und hier wäre es
toll, wenn immer dran steht welches Spieler als nächstes dran ist und
nicht nur Spieler 1, 2...
Für das STM32F4Discovery gibt es ein Extension Board mit Camera
Interface. Da kannst du dann z.B. so eine OVF mit ~1MP dranhängen. Hier
kann man dann diverse Auflösungen konfigurieren z.B. 120x160. Per DMA
lassen sich dann locker 30 FPS damit einlesen. Über Schwellwertbildung
lässt sich dann auch super so ein QR Code einlesen.
mfg
Ein 1D-Barcode ist deutlich einfacher zu lesen. Der muss ja nicht so
kurz sein wie ein typisches Warenetikett; wenn Du da einen
Papierstreifen in A4-Breite bedruckst, kannst Du einen einfachen
"Durchzugscanner" konstruieren, bei dem Dein Selbstbaugerät wenig mehr
als 'ne Reflexlichtschranke zum Scannen benötigt.
Wenn Du auf dem Papierstreifen parallel zum Barcode ein konstantes
schwarz/weiß-Muster anbringst, kannst Du mit einer zweiten
Reflexlichtschranke daraus sogar den Takt zurückgewinnen, um das
Auslesen des eigentlichen Barcodes zur Durchzugsgeschwindigkeit zu
synchronisieren.
Rufus Τ. F. schrieb:> Ein 1D-Barcode ist deutlich einfacher zu lesen.
volle Zustimmung.
> wenn Du da einen> Papierstreifen in A4-Breite bedruckst, kannst Du einen einfachen> "Durchzugscanner" konstruieren, bei dem Dein Selbstbaugerät wenig mehr> als 'ne Reflexlichtschranke zum Scannen benötigt.
vielleicht muss ja nicht alles komplett Selbstbau sein.
Einen gebrauchten 1D-Barcodescanner bekommt man bei ebay für unter 5 EUR
wenn man ein wenig die Augen aufmacht.
Die können meist entweder per RS232 oder als PS/2-Tastatur angeschlossen
werden, beides ist mit einem µC einfach zu realisieren.
Rufus Τ. F. schrieb:> Ein 1D-Barcode ist deutlich einfacher zu lesen.
Ich denke darauf wird es auch tatsächlich hinauslaufen.
Mir geht es vor allem drum, dass die "Lese-Einheit" möglichst kompakt
ist, weswegen auch die Standard-Hand-Barcodescanner ausscheiden.
Den QR-Code hatte ich deswegen ausgewählt, weil er eben schon von sich
aus kompakt ist durch seine Form und per Aufkleber an verschiedenen
"Spiel-Elementen" zu befestigen.
Aber auch der 1D Barcode mit Taktspur ist einfach zu drucken und kommt
dann eben auf längliche Aufkleber drauf und Du hast völlig recht, die
Auswertung ist dann schon sehr einfach. Ich muss dann nur mechanisch
schauen, wie ich sicherstelle, dass die richtige Spur an der richtigen
Stelle vorbeigezogen wird.
Naja, wenn schon PS/2 für den Barcode-Leser, dann kann man da auch eine
PC-Tastatur dranbasteln...
Zumal ich "Barcode ausdrucken" irgendwie unhandlich für Spielernamen
finde. :-)
Gerd E. schrieb:> vielleicht muss ja nicht alles komplett Selbstbau sein.>> Einen gebrauchten 1D-Barcodescanner
... wird man aber nicht beliebige Barcodes mit der eingangs erwähnten
Informationsmenge lesen lassen können.
Der QR-Code da am Anfang soll 32 Byte speichern können, welcher der
üblichen 1D-Barcodes kann das?
Der selbstgestrickte Lochstreifenlesernachbau kann das.
Ralf M. M. schrieb:> Mir geht es vor allem drum, dass die "Lese-Einheit" möglichst kompakt> ist, weswegen auch die Standard-Hand-Barcodescanner ausscheiden.
Es gibt auch Barcodescanner die für den Festeinbau gedacht sind, z.B. an
Förderbändern, Selbstbedienungsterminals etc.
Das sind meist kleine Kästen, so vielleicht 3x6x6cm.
Z.B. sowas hier:
http://www.ebay.de/itm/182598556235http://www.ebay.de/itm/332245918859
Da kann man dann den Barcode vorhalten und er wird gescannt.
Rufus Τ. F. schrieb:> Gerd E. schrieb:>> vielleicht muss ja nicht alles komplett Selbstbau sein.>>>> Einen gebrauchten 1D-Barcodescanner>> ... wird man aber nicht beliebige Barcodes mit der eingangs erwähnten> Informationsmenge lesen lassen können.
Ich habe mit Code-128 eigentlich ganz gute Erfahrungen gemacht.
> Der QR-Code da am Anfang soll 32 Byte speichern können, welcher der> üblichen 1D-Barcodes kann das?
Nein, 32 alphanumerische Zeichen. Das reduziert die Datenmenge schon auf
6 Bit pro Zeichen. Gute Barcode-Symbologien können das ausnutzen.
Außerdem sehe ich an der Stelle noch viel Optimierungspotential: man
könnte z.B. auf Groß- und Kleinschreibung verzichten, die Daten mit
üblichen Komprimieralgorithmen komprimieren oder sogar nur Indexnummern
im Barcode ablegen ("Spieler 17") und dann die Verknüpfung Indexnr. auf
vollständigen Namen im Flash des µC ablegen. Oder in einer SD-Karte, die
auf dem selben PC beschrieben wird, den man ja sowieso schon braucht um
die Barcodes zu erstellen.
Noch ne ganz andere Idee:
NFC-Karten oder -Token verwenden statt Barcodes.
Da ist die Technik zur Auswertung in noch deutlich kleiner machbar. Auch
können deutlich mehr Daten in den gängigen Karten gespeichert werden.
Aber die Karten sind natürlich etwas teurer als ein gedruckter Barcode.
Erst mal Danke für die vielen sehr produktiven Vorschläge, welche ich
mir in Ruhe noch anschauen werde!
Aber nochmals zu dem was ich eigentlich suche, es geht nicht darum einen
Spieler eindeutig zu identifizieren also kein ID-Tag, sondern es geht
darum, dass ich in den Programmcode des Spieles eben nicht alle
möglichen und unmöglichen Jungens und Mädels Namen aufnehmen möchte
sondern beim Spiel Start wird der Namen des Spielers als Barcode
eingelesen.
Ich habe eigentlich überall wo ich bisher meine "Spielsachen" einsetze
einen Drucker zur Verfügung. Den QR Code dachte ich mir, weil ich dann
sogar ein Smartphone als QR Code Ausdruck "missbrauchen" könnte, sprich
eine App nehmen welche mir auf dem Smartphone den QR Code anzeigt. Dies
geht jedoch nicht mit den Reflexionssystemen sondern nur mir
Lichteinfallmessenden Systemen.
Also nochmals Konkret, wenn ich nun weiß, dass die neue Freundin meines
Neffen Jacqueline heißt, dann kann ich schon vorab kurz eine Karte mit
QR oder eben einem noch zu findenden Code ausdrucken und muss nicht mein
Spielsystem anpassen. Und schon kann sie beim nächsten Spieleabend
namentlich mitspielen.
Ich hoffe das verdeutlicht die Aufgabenstellung nochmals
Ralf M. M. schrieb:> Aber nochmals zu dem was ich eigentlich suche, es geht nicht darum einen> Spieler eindeutig zu identifizieren also kein ID-Tag, sondern es geht> darum, dass ich in den Programmcode des Spieles eben nicht alle> möglichen und unmöglichen Jungens und Mädels Namen aufnehmen möchte> sondern beim Spiel Start wird der Namen des Spielers als Barcode> eingelesen.>> Ich habe eigentlich überall wo ich bisher meine "Spielsachen" einsetze> einen Drucker zur Verfügung.
Also wäre der Workflow:
- Proband tippt seinen Namen per Tastatur in den Computer ein
- Computer rechnet heftig und verbraucht dabei einen Haufen Strom
- Computer schickt das Ergebnis seiner Berechnungen als Bild an den
Drucker
- Drucker rechnet wiederum heftig und verbraucht dabei einen Haufen
Strom
- Drucker bringt das Ergebnis zu Papier und verbraucht dabei super
überteuerte Tinte oder gemäßigt überteuerten Toner
- Proband entnimmt das Ergebnis dem Drucker
- Proband fummelt den Ausdruck "passend" unter die Kamera
- Zielsystem betreibt relativ aufwendige Bildverarbeitung, um den Code
zu
erfassen
- Zielsystem entnimmt dem Code (mit etwas Glück) erfolgreich den
Spielernamen
- Zielsystem ordnet den Namen der nächsten freien Spieler-ID zu
Also wem das jetzt nicht völlig idiotisch vorkommt angesichts der
Möglichkeit:
- Proband tippt seinen Namen per Tastatur in's Zielsystem ein
- Zielsystem ordnet den Namen der nächsten freien Spieler-ID zu
dem ist wohl nicht zu helfen.
Ja klar, man muss dazu entweder eine Tastatur in's Zielsystem
integrieren oder zumindest eine Anschlussmöglichkeit für eine
handelsübliche Tastatur schaffen. Aber beides ist doch wohl um vieles
einfacher zu realisieren als der ganze Bullshit von oben und auf Dauer
im Betrieb auch sehr viel günstiger. Von der Entlastung des Probanden
mal ganz zu schweigen...
Also der Programmieraufwand zur 2d-codeerkennung aus einem
Kameradatenstrom dürfte die Möglichkeiten eines jeden 8-bit-AVR
sprengen. Ein 2D-Barcodeleser hat neben dem Kameramodul gleich die
Erkennungslogik als chip onBoard. Ich kann mich an ehemalige
motorola-Scanner erinnern, die zum Einbau in größere Anlagen
(förderbänder o.ä) gedacht waren, wo das Logic-board etwa das doppelte
des Preises der Kameraplatine kostete.
Bleibt nur der Fertigkauf eines 2d-scanners: hierbei wären
Scanner(-module) unter 100euro ein echtes Schnäppchen!
Ein Selbstbau auf einem STMF4 o.ä. könnte glatt die Grundlage einer
Doktorarbeit in Info sein ;)
Im 1D-Bereich siehts viel besser aus: wenn man altertümliches wie Code39
u.ä. weglässt und sich gleich auf Code128 bzw. vergleichbares stürzt,
bekommt man auch so recht kompakte Barcodes die noch immer mit
5-Eur-gebraucht-LED-CCD-Scannern aus der Grabbelkiste in einem Rutsch
gescannt werden können.
Wenn du ein besonders blindes Exemplar erwischt, tuts auch ein
zweizeilig geteilter Barcode der halt 2x scannen erfordert.
Zumindest 15 alhpanumm. Zeichen in Code128 gepackt scannen wir
problemlos mit 10 jahre alten PS/2-Scannern aus 5-35cm entfernung sehr
zielsicher (99,9%?) in einem Projekt.
Diese alten CCD-Scanner kannst du auseinandernehmen und deren kleines
Innenleben in eine Steichholzschachtel oder in dein Gerät mit hinein
umziehen.
Achja: in den meissten Fällen musst du einem gebrauchten Scanner erst
beibringen, Code128 zu lesen. Die Anleitung zu haben, ist also ein Muß.
c-hater schrieb:> Also wäre der Workflow:
[Ausführlicher Workflow, welcher in dieser Form in der Praxis in der
konkreten(!) Umgebung nicht auftritt]
Es geht darum, dass es mehrere sehr verschiedene Spiele gibt aber nur
wenige und selten wechselnde Spieler, d.h. die Codes (übrigens per
Thermodrucker) werden selten gedruckt aber häufig eingesetzt.
Beispiel: Spiel 1. Es entschließen sich 3 Spieler in der gewünschten
Reihenfolge ihre Codes vor die Erkennung zu halten, währenddessen sitzen
am Spiel 2 4 Spieler und machen das selbe mit Ihren Codes.
Die Namen dienen dazu anzuzeigen wer an der Reihe ist und wer wie viele
Punkte hat.
Eine Tastatur halte ich für Oversized nur um diese wenige Zeichen zu
erfassen, das einzige was ich derzeit evtl. als Alternative überlege ist
per Bluetooth die Eingabe zu machen von einem Smartphone aber dann ist
wieder eine Abhängigkeit mehr drin.
Wie wäre ein biologischer Scanner für verschiedene Spieler?
z.B. ebay 142059094819
Funktionieren erstaunlich gut. Wenn du allein spielst geht auch
Zeigefinger gegen Mittelfinger ;)
Andy schrieb:> Diese alten CCD-Scanner kannst du auseinandernehmen und deren kleines> Innenleben in eine Steichholzschachtel oder in dein Gerät mit hinein> umziehen.
Hört sich sehr interessant an, muss mich mal auf die Suche machen
pegel schrieb:> Wie wäre ein biologischer Scanner für verschiedene Spieler?
Nochmal, es geht nicht darum einen Spieler zu Identifizieren, das geht
auch per NFC, sondern ich will einfach nur den Namen das Spielers
anzeigen wenn er dran ist und auf der Punkte-Liste, mehr nicht.
Und suche eben ein System mit welchem ich auf einfache Art und Weise
diesen Namen ins System bekomme, möglichst in einer Form, dass die
Quelle des Namens mit Hausmitteln erstellt werden kann, wobei bei ich
einen Drucker nebst PC als Hausmittel ansehe in der Umgebung in welcher
die Spiele zum Einsatz kommen.
Ralf M. M. schrieb:> Nochmal, es geht nicht darum einen Spieler zu Identifizieren, das geht> auch per NFC, sondern ich will einfach nur den Namen das Spielers> anzeigen wenn er dran ist und auf der Punkte-Liste, mehr nicht.
ja, das habe ich schon so verstanden.
> Und suche eben ein System mit welchem ich auf einfache Art und Weise> diesen Namen ins System bekomme, möglichst in einer Form, dass die> Quelle des Namens mit Hausmitteln erstellt werden kann, wobei bei ich> einen Drucker nebst PC als Hausmittel ansehe in der Umgebung in welcher> die Spiele zum Einsatz kommen.
Ich behaupte mal wo ein PC mit Drucker "Hausmittel" ist, ist auch ein
SD-Card-Leser nicht weit.
Also bei neuem Mitspieler:
- SD-Karte in PC
- Texteditor auf
- Neuen Namen mit Zeilennummer davor in die Liste eintragen
- Speichern, Ordnungsgemäß unmounten
- SD-Karte ins Spiel stecken
Jetzt kannst Du verschiedene Varianten machen:
1. 1D-Barcodes der Spieler vor einen kleinen Barcodeleser halten. Die
Barcodes müssen jetzt nur noch die Spielernummern enthalten, also "12",
"4", "23" etc. und sind damit sehr klein
2. Die Nummern der Mitspieler im Spiel selbst einmal per Drehencoder
oder Nummernblock eingeben
3. Auf die Nummern ganz verzichten und im Spiel einfach alle Namen
anzeigen, Auswahl per Drehencoder. Wer mitspielt wird einmal per Druck
auf den Drehencoder ausgewählt.
Man kann natürlich auch einfach für jede Spielerposition einen (µ)SD
Kartenschlitz vorsehen.
Nach Abschluss des Spiels kann dann sogar jeder seine Statistik
mitnehmen.
Und so teuer sind die auch nicht mehr.
Ralf M. M. schrieb:> Es geht darum, dass es mehrere sehr verschiedene Spiele gibt aber nur> wenige und selten wechselnde Spieler, d.h. die Codes (übrigens per> Thermodrucker) werden selten gedruckt aber häufig eingesetzt.
Auch dann ist eine (wie auch immer realisierte) Tastatur für jedes
Zielsystem immer noch die mit weitem Abstand beste Lösung.
Unter den gegebenen Randbedingungen würde man nämlich einfach den
Zielsystemen einen Datenbank mit Nutzernamen verpassen, die (da es nach
deinen Angaben nur wenige sind und obendrein selten wechselnd)
problemlos lokal auf den Zielsystemen gehalten werden können.
Mit einer Tastatur könnte man nun sehr komfortabel aus den verfügbaren
Benutzernamen wählen und auch neue Benutzer ohne jegliche Umstände
anlegen.
Das einzig Böde wäre nur, das die Neuanlage eines Benutzers für jedes
Spiel wieder erneut erfolgen müßte. Aber auch das ließe sich sehr viel
effizienter lösen als nach der von dir angedachten "Lösung". Nämlich:
man schafft eine Möglichkeit um die "Spiele" untereinander zu verbinden,
so dass sie ihre neuen Erkenntnisse bezüglich der Benutzerdatenbank
einfach mal weiterreichen können.
Und lustigerweise muss man dazu nichtmal irgendein aufwendiges
Netzwerkprotokoll oder sowas beschäftigen. Man würde statt dessen
einfach jedem Spiel die Fähigkeit geben, virtuell die Tasten eines jeden
anderen Spiels zu drücken, sprich: ein replay der Anmeldung des
Benutzers abzuspielen.
Gerd E. schrieb:> Ich behaupte mal wo ein PC mit Drucker "Hausmittel" ist, ist auch ein> SD-Card-Leser nicht weit.
Hmm, das ist auf alle Fälle eine gute Alternative zumal ich einen USB
SD-Card-Leser ja immer mitnehmen kann und es diese sogar für USB OTG
gibt.
pegel schrieb:> Zum Beispiel einen Sack voll davon:>> ebay 162502787229
und dann sind die ja auch wirklich günstig und vor allem auch einfach
einzubinden.
Danke für diese weiteren Ideen
Ralf M. M. schrieb:> Nochmal, es geht nicht darum einen Spieler zu Identifizieren, das geht> auch per NFC, sondern ich will einfach nur den Namen das Spielers> anzeigen wenn er dran ist und auf der Punkte-Liste, mehr nicht.
Nimm ein Bluetooth Module und Programmiere eine kleine Smartphone App,
welche die Spielernamen deinem Spiel beibringt, die können dann ja
persistent in einem EEPROM abgelegt werden.
c-hater schrieb:> Unter den gegebenen Randbedingungen würde man nämlich einfach den> Zielsystemen einen Datenbank mit Nutzernamen verpassen
Ja, diesen Gedanken werde ich nun aufgreifen für meine weiteren
Überlegungen und diese Datenbank in Form einer SD Karte nutzen, bzw.
natürlich einer Textdatei auf dieser.
c-hater schrieb:> Auch dann ist eine (wie auch immer realisierte) Tastatur für jedes> Zielsystem immer noch die mit weitem Abstand beste Lösung.
Ja, diese gibt es tatsächlich eigentlich immer, meist als Rotary-Encoder
mit zusätzlich Druckschalter oder mind. 3 Tastern für ein Menü. Und da
in der Datenbank, dann nur noch wenige Namen sind, ist dies eine
Möglichkeit.
Ich hatte die nur zuerst verworfen, weil wenn ich sie in die Firmware
genommen hätte, dann hätte ich da einige zig Namen aufnehmen müssen und
dann wäre die Auswahl zu langwierig, aber an SD Karten hatte ich gar
nicht gedacht
Einen QR-Code zu lesen, auch wenn das Bild perfekt vorielgt, ist
nicht-trivial, da steckt ein ordentlicher Sack Mathematik drin. Das ist
vor Allem durch die eingebaute Fehlerkorrektur nach Reed-Solomon bedingt
...
Es gibt fertige OEM-Module, die per serieller Schnittstelle die
gelesenen Daten ausliefern.
Frank E. schrieb:> Einen QR-Code zu lesen, auch wenn das Bild perfekt vorielgt, ist> nicht-trivial
Ja ich denke, dass ich hier zu naiv an die Sache herangegangen bin, aber
dank' der Unterstützung hier im Forum werde ich es nun in Richtung SD
Card durchdenken
Also normale 1D Barcodes sind da generell aber trotzdem die
interessantere Wahl. Wenig aufwand, leicht auszulesen. Allerdings lohnt
es sich dann nich mehr so wirklich da was selbst zu bauen. Selbst
professionelle Modelle bekommst du für um die 30€:
https://www.michaelkrug.de/ccd-led-hand-barcodeleser-barcodescanner und
für deine zwecke sollte das wirklich völlig ausreichen.
Ralf M. M. schrieb:> den QR Code "irgendwie" zu lesen, sondern mit dem µC, damit ich die> Information im QR Code für die Basteleien mit dem µC nutzen kann.
Schließ einen passenden Barcodescanner an die serielle Schnitte des uC
an.
Lothar M. schrieb:> Schließ einen passenden Barcodescanner an die serielle Schnitte des uC> an
Leider habe ich noch keinen für meine Aussgangsfrage passenden
Barcodescanner gefunden, denn er sollte ja sehr klein sein ... und in
dem Moment als ich es aus meinem Post zitieren möchte fällt mir auf,
dass ich in die selbe Falle getappt bin wie viele andere TOs auch und
nicht alle Anforderungen aus dem Kopf in den Post gebracht habe.
Ich war mir sicher, dass ich geschrieben hatte, dass das ganze sehr
kompakt sein soll, deswegen ja die kompakten Kameramodule, also die
"Leseeinheit" max. 5x5x5cm³
Also ein Sorry an alle, welche nun Tipps geben haben, welche auf meinen
fehlenden Angaben beruhten :-/
Frank E. schrieb:> Einen QR-Code zu lesen, auch wenn das Bild perfekt vorielgt, ist> nicht-trivial, da steckt ein ordentlicher Sack Mathematik drin. Das ist> vor Allem durch die eingebaute Fehlerkorrektur nach Reed-Solomon bedingt> ...
Die Mathematik lässt sich reduzieren indem man RS einfach nicht nimmt.
Also Micro-QR-Code plus Kamera plus ATMega/STM32F1 -
Reed-Solomon-Codierung.
Wie wäre es mit Chip-Tan-ähnlicher Übertragung?
Also Zeit als 2. Dimension.
Ein paar Photodioden/Reflexlichtschranken parallel nebeneinander.
Die erste liest nur die 'Clock', also ständig an/aus. Auf den restlichen
Positionen wird synchron dazu der Datenstrom -passend codiert-
eingelesen.
Generierung des Codes entweder am Smartphone, dort als Folge von
schwarzen/weißen Balken, die sich mit der Zeit ändern. Oder am PC
ähnlich anzeigen, wenn du das Spiel vor den Monitor halten kannst. Oder
am PC generieren, ausdrucken (ein Muster pro Zeile) und den Streifen
dann am Sensor vorbeiziehen. Geschwindigkeit sollte dank der
'Clock'-Balken nicht so kritisch sein.
pegel schrieb:> Ich dachte die SD Variante ist schon beschlossen?
Ja ist sie und die Module zum Testen sind auch schon da, nur fehlt im
Moment die Zeit
Aber da sich hier noch einige die Mühe gemacht haben mir weitere Tipps
zu geben, werde ich natürlich gerne weiter Antworten, alles andere ist
in meiner Sicht unhöflich und as möchte ich nicht
Markus M. schrieb:> Wie wäre es mit Chip-Tan-ähnlicher Übertragung?> Also Zeit als 2. Dimension.
Es geht hier nicht darum Daten zu übertragen, sondern mehr ausgedruckte
konstante Werte (z.B. Spielernamen) ins System zu übertragen.
Es geht ausdrücklich um gedruckte Daten, also auch kein NFC etc.
Aber wie oben geschrieben ist die SD Card eine gute Alternative.
(Sobald mein "Spiele-System" etwas mehr Form angenommen hat, werde ich
es hier im Forum mal vorstellen, was aber sicherlich noch einige Wochen
dauern wird)
Ralf M. M. schrieb:> Markus M. schrieb:>> Wie wäre es mit Chip-Tan-ähnlicher Übertragung?>> Also Zeit als 2. Dimension.>> Es geht hier nicht darum Daten zu übertragen, sondern mehr ausgedruckte> konstante Werte (z.B. Spielernamen) ins System zu übertragen.> Es geht ausdrücklich um gedruckte Daten, also auch kein NFC etc.
Genau. Funktioniert ja wie ein QR-Code. Nur, dass du keine
zweidimensionale Grafik aus einem Foto identifizieren musst, sondern der
Code am Sensor (nur eine Zeile Fotozellen) vorbeigezogen wird. Oder eben
automatisch nacheinander abläuft, wenn ein Smartphone zur Verfügung
steht.
Vielleicht für das nächste Projekt :)
> Aber wie oben geschrieben ist die SD Card eine gute Alternative.
Das ist aber dann schon ein stück weg von 'gedruckt' ;)
> (Sobald mein "Spiele-System" etwas mehr Form angenommen hat, werde ich> es hier im Forum mal vorstellen, was aber sicherlich noch einige Wochen> dauern wird)
Ich bin gespannt :)
Markus M. schrieb:>> Aber wie oben geschrieben ist die SD Card eine gute Alternative.> Das ist aber dann schon ein stück weg von 'gedruckt' ;)
Ja das stimmt. Anfangs wollte ich es an allen Orten machen können, wo
ich die Systeme normalerweise einsetze und ich weiß dass dort immer ein
PC/Notebook vorhanden ist und bin altmodisch davon ausgegangen, dass da
auch ein Drucker ist, deswegen die Anforderung gedruckt.
Aber zum einen habe ich inzwischen bemerkt, dass Drucker gar nicht mehr
so verbreitet sind, deshalb fand ich dann die Idee mit der SD Card sehr
gut, da ich einfach einen Adapter SD auf USB mit dabei haben muss und
dann die Namensliste einfach in z.B. Notepad ergänzen kann und die SD
Card dann wieder ins Spiele System stecken
static_qr_code_without_logo.png
(415 Bytes)
