Druckbare Version
barcodes kann man leider nicht direkt lesen. dafür braucht man einen entsprechendes lesegerät.
man könnte aber sehr große barcodes malen (zB schmaler strich = 1 cm, dicker strich = 3 cm). und den asuro mit sehr exakter geschwindigkeit darüberfahren lassen. dann könnte man mit hilfe von geschwindigkeit und zeit, die der liniensensor "dunkel" meldet, die dicke des striches etwa erfassen, und daraus dann einen bestimmten wert ziehen oder eine aktion ausführen o.ä.
Die Geschwindigkeit muss für so eine Funktion nicht exakt, sondern während des Überfahrens einigermaßen gleichmässig sein. Die Codierung kann man über die reilativen Zeitdauern erkennen.Zitat:
und den asuro mit sehr exakter geschwindigkeit
stochri
Hallo zusammen.
Ich hatte vor einiger Zeit schon mal einen Entwurf für Barcodes gemacht (nur so für mich)
damaltor hat als Vorschlag Strichbreiten von 1 bis 3 cm. Ich bin auch auf 'breite' Striche gekommen, aber im mm-Bereich. Meine Überlegung ging davon aus, dass ich die Strichbreite genau mit den ODO-Scheiben synchronisiere. Jeder Tik der Odo-Scheiben sollte einen Messwert an dem Linien-Sensor liefern.
Die Idee dahinter ist die, dass ich dann
1. unabhängig von der Geschwindigkeit bin. Auch ungleichmäßiges Fahren wäre damit abgedeckt.
2. die zu lesende und zu analysierende Datenmenge ist sehr klein.
Als weitere Randbedingung hatte ich mir vorgestellt, dass die Barcodes nur an einer vom Asuro abzufahrender Linie angebracht sind. (Nur auf der rechten Seite)
@stochri
Ich bin mir nicht sicher, aber ich glaube du hattest mal den Vorschlag gemacht, dass der Asuro frei im Raum fährt und Barcodes selber suchen soll. (Das war mir erst mal zu kompliziert.)
Bisher bin ich nur zum Entwurf eines Codes gekommen. Die erste Excel-Datei mit der man 'Barcode-Bildchen' erzeugen kann ist ja erst seit Dezember 2006 ;-) Ich poste die mal als Anhang.
Der Codeaufbau ist folgender:
- 10 mögliche schwarze Striche; somit maximal 9 weiße Lücken
- SWSWSW als Startcode
- WW ein noch unbenutztes Bit
- WW oder SW zur Unterscheidung von Zahlen oder Kommandos
- ?W?W?W?W 4 Bit entweder Zahl, oder Kommando
- S Endecode
Das Exelbaltt wird da eher Licht in's Dunkel werfen. Ich hatte damals sogar eine Anleitung da reingeschrieben, wie man das bedient. (Zum Glück, sonst hätte ich da nun auch schon Probleme das Zeug zu Verstehen)
Vielleicht kann man das ja als Anregung nutzen um tatsächlich mal Barcodes zu lesen.
aber ist ein tick der radsensoren nicht schon 3 mm wert? dass heisst aber, dass ich dicke und dünne striche auf jeden fall stark unterschiedlich machen würde, zB 3 ticks für dünn und 6 ticks für dick, was dann immerhin 1 und 2 cm bedeuten würde. dünne striche dürften dann 2-4 ticks lang sein, und dicke striche 5-7 ticks. so könnte man trotz der (für diesen zweck eingentlich wohl zu) geringengen aufösungen der encoder die striche halbwegs sicher erkennen.
bei deinen überlegungen gibts einen gravierenden fehler: es können niemals zwei weisse oder zwei schwarze striche aufeinanderfolgen ("WW oder SS).
vermutlich meinst du jedoch die abstände bzw breiten, und nicht die farben =)
folhgendes fällt mir ein um ein byte zu kodieren:
jede lücke und jeder strich kann schmal (S) und breit (B) sein.
ich nehme jetzt schmal als 0, und breit als 1 an.
für ein byte, also 8 bit braucht man also 4 striche und 4 lücken.
wenn man das ganze etwas sicherer machen will, könnte man so beginnen:
SBSB - startcode (zwei schmale striche und zwei breite lücken)
xxxxxxxx (4 striche und 4 lücken, ein byte kodiert nach obigem massstab)
a (ein strich für die befehlsart: 1=befehl, 0 = daten)
p (prüfsumme (eine lücke, kein strich! schön mitzählen =), 1 wenn anzahl der einsen ungerade, 0 wenn anzahl der einsen gerade)
SBB - endcode (schmaler strich-breite lücke-breiter strich. das letzte zeichen ist ein strich, denn eine lücke wäre ja unendlich lang... =)
start- und endcode sollten verschieden sein, damit der asuro merkt dass er in die falsche richtung drüber fährt, und den code dann entsprechend umrechnet oder es eben von der anderen seite versucht.
um also den befehl 11001100 zu kodieren würde das ganze so aussehen:
(großbuchstaben: strich, kleinbuchstabe: lücke
SbSbBbSsBbSsBbSbB
Code:# # ### # ### # ### # ###
Hallo Barcode-Interessierte.
Zu damaltors Anmerkungen: Ich habe die 8-er ODO-Scheiben am Asuro, und habe somit pro Tik dann nur einen Weg von ca. 1.5mm. Bei mir würden dann Strichbreiten von ca. 3mm ausreichen, um pro S oder W 2 Messungen machen zu können. Dies sollte nach irgend so einem Abtasttheorem ausreichen.
Meine Idee dazu war, dass ich immer DREI hintereinander gemachte Messungen einfach mittel. Komme ich auf weniger als 0,5 Mess-Einheiten, wird dies als W, sonst als S angenommen. (Dunkel-Messung = 1; Hell-Messung = 0; halb Hell/Dunkel = 0.5)
Ich bin nicht von unterschiedlich breiten S- und W-Strichen ausgegangen, da ich dann ja Zeiten zum Erkennen der Breite nutzen müsste. Genau dies aber würde dann ja doch zu gleichmäßiger Fahrt zwingen wie stochri schon anmerkt.
SS- oder WW-Kombinationen nutze ich nicht, dadurch dass ich in den W-Strichen keine Information hinterlege. Sie gelten, und müssen vorhanden sein, nur als Trenner für die entweder vorhandenen S-Striche, oder deren nichtvorhandensein, so dass ich sie als 1 wenn vorhanden, bzw. als 0 wenn nicht vorhanden interpretieren würde.
Im Moment habe ich auch kein Prüfbit in meinem Vorschlag, da ich bis jetzt davon ausgegangen bin, dass die W-Striche, die ja keine Information enthalten, zur Trennung der Informationsenthaltenden S-Striche ausreichen sollten. Das ist aber nur eine Vermutung von mir.
Zustimmen kann ich auf alle Fälle dem Gedanken, dass Start- und Ende-Kennung unterschiedlich sein sollten. Ich tendiere aber nicht zu einer 'Umrechnung' beim Überfahren in verkehrter Richtung. Das liegt bei meinem Vorschlag daran, dass ich z.B. bei dem Barcode für die Geschwindigkeitsangabe zwei Barcodes benutzen würde. Der erste kündigt einen weiteren Code erst an, in dem die Geschwindigkeit als Zahl angegeben wird. Rückwärts gerechnet ist mir da zu schwer. ;-)
So, ist wieder spät geworden. Bis nachher.
achso, das ist natürlich ne idee... allerdings denke ich kann man mithilfe der weissen striche gut etwas platz einsparen, oder?
das theorem was du meinst ist wohl dieses hier:
http://de.wikipedia.org/wiki/Abtasttheorem
um ein mit einer bestimmten frequenz auftretendes signal (schwarze striche) mit sicherheit vollständig zu erfassen, muss die abastfrequenz mindestens 2x so groß sein wie die frequenz des signals.
Genau das Ding da meinte ich.
Aber wer kann sich schon Nyquist-Shannon merken? Geschweige denn, die angegeben Formeln im Asuro berechnen lassen? (Klar, alle außer mir natürlich.)
Platz sparen bei/mit den weissen Strichen ist bestimmt möglich. Hatte ich aber in meinen Überlegungen eben nicht gewünscht/bedacht. Ausserdem dürfte dann das von dir ins Spiel gebrachte Problem mit den nebeneinander liegenden SS- und WW-Kombinationen auftreten.
Ich bin jetzt aber dafür, dass harry3 bald mal funktionierenden Code postet ;-)
Ja ne ist klar, mach ich doch sofort! Sonst noch irgendwelche Code Wünsche? :mrgreen: :mrgreen:Zitat:
Zitat von Sternthaler
Auch bei mir ist die Ferienzeit leider um, ich komme also vorerst mal nicht so viel zum Asuro Programmieren. Aber sollte ich das Barcode Problem einmal lösen können so werde ich es natürlich hier posten.
Ich hab zuletzt für die Abgrunderkennung die Linienfolger Transis verwendet und hatte selbst bei so einer einfachen Aufgabe wie der simplen Abgrunderkennung mit der starker Welligkeit des Signals zu kämpfen. Das führte letztendlich dazu dass ich die dynamische(welche die Änderung des Signawertes analysiert) Lösung gegen eine statische austauschte(welche einfach nur den Anfangssignalwert kontinuierlich mit dem aktuellen Wert vergleicht).
Am besten wäre es wohl den Asuro vor jedem Mal Barcodelesen zu kalibrieren, also dass er über eine Schwarz-Weiß Schwelle fährt und sich daraus den Grenzwert errechnet.
Ich würde den Asuro dann einfach vor den Strichcode stellen und ihn dann einschalten. Dann würde ich es so machen dass er einfach eine bestimmte vorgegebene Zeit über den Strichcode fährt(in der er den kompletten Code überfährt), und so ca. alle 10ms(muss man einen Mittelweg finden aus kleiner Speichermenge und genügend hoch aufgelösten Daten) eine Helligkeitsmessung durchführt und in ein Array abspeichert. Ins Array speichert man entweder eine 1(Helligkeits-Grenzwert überschritten) oder eine 0(HG unterschritten) ...das spart Speicherplatz(man braucht nur char statt int).
Der Barcode ist auf einem weißen Blatt Papier aufgedruckt, also ist der Anfangs und Endcode jeweils ein schwarzer Strich. Aus Anfangs und Endposition kann man die Datenmenge(also von welchem bis zu welchem Arrayindex der Barcode ansich liegt) der abgespeicherten Daten ausrechnen. Das ist nun der Teiler.
Dann rechnet man aus wielange jeweils die 0-er und 1-er Ketten(entsprechen den Strichen) im Array sind, und teilt sie durch den zuvor ausgerechneten Teiler mal einem Faktor. Da man dank des Teilers auf die tatsächliche Länge schließen kann, kann man recht einfach abfragen ob es sich um einen breiten oder schmalen Strich handelt.
Die analysierten Striche speichert man in ein weiteres Array welches man dann endgültig auswerten kann.
Sollte ich mal Zeit haben werde ich es so in der Art probieren. Das Hauptproblem ist die Ungenauigkeit von Asuro. Man kann nicht sagen ob die Geschwindigkeit gleichmäßig ist, man weiß nicht ob die Lichtsensoren genaue Daten liefern, usw...
Prinzipiell wäre es aber machbar.
Ich würde mich aber mit der Basisversion zufrieden geben: Barcode lesen und per IR Schnittstelle ausgeben. Fertig.
Grüße,
Harri
Hallo
Mit den Odosensoren könnte man einen Barcode ja auch einlesen, allerdings müßte man den dann als Streifen an den Sensoren vorbeiziehen.
Für die Line-Sensoren müßte man erst mal eine Schlitzblende bauen um den Lesebereich besser zu definieren. Dann würde ich den asuro mit Anlauf und halbwegs konstanter Geschwindigkeit über den selbstgemalten Code fahren lassen. Dabei werden dann die Werte eingelesen und gespeichert, ähnlich wie bei den Odo-Testprogrammen. Wenn man diese Werte dann als Balken-Diagramm darstellt, sollten die Streifen, und damit der gelesene Code, schon erkennbar sein. Der Rest ist ein bisschen Rechenarbeit: Erste und letzte Flanke suchen, Gesamtlänge des Codes auf die einzelnen Bits verteilen. Wenn man mit festen Bitlängen quasi einen Binärcode aufmalt, genügt es die Helligkeit ungefähr in der Mitte des Bits zu erkennen.
Echte Barcodes könnte man am Kopierer vergrößern bis sie zur Schlitzblende passen. Die sind allerdings etwas komplizierter, und teilweise fehlerkorrigierend, aufgebaut.
Beim Linienfolgen könnte man auch Querstreifen als Beschleunigungs-/Bremspunkte verwenden oder damit Abbiegeregeln für die nächsten Linienkreuzung übermitteln.
Gruß
mic
@harry3
Im Anhang mal ein 'abschreckendes' Beispiel für den 'viele Daten'-Ansatz.
Ich kann leider nicht mehr sagen, über wie viele Striche ich da gefahren bin. Und egal was ich mit den 'Rohdaten' mache, ich kann keine Striche wiederfinden. Dein Ansatz hört sich aber wesentlich besser an, als meine 'Datensammlung'.
Die Idee, die erste und die letzte Flanke zu suchen hatte ich nach meinen 'viele-Daten'-Test's komplett verworfen.
Den Ansatz zum Kalibrieren kann man evl. weglassen.
Ich hatte mal in diesem Beitrag dargelegt, dass man Schwarz und Weiß sehr gut auseinanderhalten kann, ohne dass man dem Asuro 'beibringen' muss wie Schwarz aussieht. Ich hoffe, dass das hilft. (In dem gesamten Thread geht es genau um das Thema: Was ist Schwarz?)
P.S.: Ich erinner mich auch wieder, warum ich die S- und W-Striche möglichst schmal haben wollte: Der Asuro sollte ja an der Linie entlang fahren. Wenn nun die S-Striche zu breit werden, dann kommt das Linienverfolgeprogramm aus dem 'Tritt' und der Asuro fuhr immer von der Linie weg.