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.
Gut dass man mal ein paar Rohdaten zu dem Thema sieht. Das sieht ja wirklich grauenvoll aus.
Ich werd' am WE mal ein paar Versuche zu dem Thema anstellen und dann hier posten. Bei genügend großen Strichen seh' ich kein Problem sie zu erfassen.
Eine allzu große Datenmenge strebe ich nicht an.
Ich habe mir jetzt folgendes Barcode Schema vorgenommen:
-eine schwarze Linie als Start
-weiße Linien als Trennung
-breite schwarze Linien repräsentieren eine 1
-dünne schwarze Linien repräsentieren eine 0
-3 Datenbits, evtl. 1 Paritätsbit
-eine schwarze Linie als Stopp
Damit kommt man zumindest auf 2^3=8 Werte, womit man schon ein paar Informationen abspeichern kann.
Grüße,
Harri
Hallo harry3,
warum benutzt du nicht die von mir vorgeschlagenen Barcodes aus meinem Post? siehe oben
- Bei deinem Vorschlag kann man 'vorne' und 'hinten' nicht unterscheiden.
- Bei deinem Vorschlag hast du unterschiedlich breite Striche.
- Bei deinem Vorschlag hast du nur 3 Datenbits
P.S.: In meinem letzten Beitrag geht es nicht um die Datenmenge im Barcode, sondern um die Datenmenge der Sensoren, um überhaupt erst einmal einen Strich zu erkennen.
Ich kann die Excel Tabelle nicht richtig darstellen, Excel malt die Datenbits nicht an sondern zeigt nur eine Fehlermeldung für die Felder: "Ungültiger Name".Zitat:
Zitat von Sternthaler
Scheint an unterschiedlichen Excelversionen zu liegen.
Ein Screenshot vom Excelblatt mit den gezeichneten Barcodes wäre nett.
Grüße,
Harri
Hallo,
hier dann mal die Kunstwerke aus dem EXCEL-Blatt. (Version Excel 2000)
Es sollten alle Möglichkeiten, die ich mir ausgedacht habe, vorhanden sein.
(Bis auf Wert 0 und 9 bis 13)
Nochmal die Bit's (Dran denken, Es ist immer eine weiße Lücke zwischen den Bits):
01 Startbit 1
02 Startbit 2
03 Startbit 3
04 reserve
05 0=Wert | 1=Kommando
06 Datenbit 2^3
07 Datenbit 2^2
08 Datenbit 2^1
09 Datenbit 2^0
10 Stopbit
Die Breite der Striche und Lücken soll immer möglichst genau 2 Tik-Längen haben, wegen des NyS-Theorem's. Opps, ich glaube eine noch kürzere Abkürzung sollte man tunlichst lassen [-X
Danke.
Allerdings hast du auch hier unterschiedlich breite Lücken - bei mir waren es halt unterschiedlich breite Striche.
Ich werd' mir dann am WE - welches Gottseidank schon morgen beginnt :mrgreen: - alles ansehen bzgl. Strichcodes und mich dann wieder melden.
Grüße,
Harri
Ähm harry3,
lies doch bitte nochmal den von mir geschriebenen Text zum Aufbau der Barcodes in Ruhe durch. Ja, sei so lieb.
Meinst du die Synchronisation mit der Odometrie?Zitat:
Zitat von Sternthaler
Letztendlich muss man man immer irgendwie(und seis nun auch indirekt über die Synchronisation mit der Odometrie) die Breite analysieren, außer man will nur die Strichanzahl zählen.
Grüße,
Harri
Nein, ich meine dass es immer abwechselnd einen --> eventuell <-- vorhandene schwarzen Strich und einen --> immer <-- vorhandenen weißen Strich, ohne Information, gibt.
Der --> eventuell <-- vorhandene schwarzen Strich darf auch weiß sein, um anzuzeigen, das diese Bit gerde nicht gesetzt ist, Ist der --> eventuell <-- vorhandenne schwarzen Strich tatsächlich schwarz, dann soll er ein Bit mit dem Wert 1 anzeigen.
Alle Striche sind gleich breit, nur sind manche Striche einfach nicht zu sehen. ;-)
P.S.: Falls ich dich oder anderen Personen auf die Füße getreten haben sollte , beschere dich bei Trollinger aus Württemberger. (Steht so auf den Flaschen. Ha, ha, ha, ;-)
Ok, ich sehe schon wir meinen beide das gleiche, nbur dass es halt jeder anders beschreibt :wink:
Wenn manche Striche nicht zu sehen sind dann ist dieser Strich weiß und somit kann man dann den weißen Strich als "breiten" weißen Strich betrachten. So, jetzt wird's philosophisch :shock: ... lassen wir's lieber :mrgreen:Zitat:
Alle Striche sind gleich breit, nur sind manche Striche einfach nicht zu sehen.
Also ich werde heute mal mit der Umsetzung beginnen und mich dann sobald ich erste Ergebnisse erzielt habe mich wieder melden.
Grüße,
Harri
also ich halte es für unwesentlich, ob nun unterschiedlih breite striche oder unterschiedlich breite lücken werwendet werden...
die einfachste möglichkeit wäre vermutlich, einfach nur striche zu zählen (2 striche=linkskurve, 3 striche=rechtskurve, 4 striche= achtung sackgasse usw.) das wäre zumindest in der programmierung das allereinfachste.
So, es klappt tatsächlich. Die Funktion lässt Asuro über den Barcode fahren und gibt zum Schluß den entsprechenden Wert zurück. Den kann man dann für alles mögliche verwenden...
Ich habe mich da Schritt für Schritt durchgearbeitet, wer sehen will wie ich es gemacht habe siehe angehängte Excel Datei.
Ich habe nun den Barcode mit der Odometrie verknüpft, sobald das Startbit erkannt wurde, beginnt die Messung. Ein kompletter Barcod ist exakt 150mm lang und besitzt 5 schwarze Striche.
Jeder schwarze Strich wird von einem weißen Zwischenraum gefolgt. Der schwarze Strich kann vorhanden sein(="1") oder nicht vorhanden sein(="0").
Eine Strichbreite habe ich mit 15mm festgelegt, näheres dazu in der Exceltabelle.
Letztendlich erhält man einen Barcode mit 1 Startbit, 3 Datenbits(=8 Werte), und einem Prüfbit(prüft die 1er Anzahl). Dank des Prüfbits arbeitet das ganze sehr zuverlässig.
Ich werde den C Code jetzt noch etwas optimieren, und werde ihn dann posten.
Grüße,
Harri
na das klint doch nicht schlecht. der nächste schritt sollte evtl eine art optimierung sein, 3 bit auf 15 cm ist nicht die masse. da geht mit sicherheit noch was =)
Ich hab alles soweit wie möglich variabel gehalten mit #define's, man kann also wenn alles perfekt läuft schauen wie weit man runter kommt. Man darf halt nicht vergessen dass 1 tick bereits 3mm sind, um halbwegs auf der sicheren Seite zu sein sollte man mindestens den 2fachen Wert verwenden, also unter 6mm kommt man auf gar keinen Fall, wahrscheinlich wird 9mm der kleinstmögliche Wert sein.Zitat:
Zitat von damaltor
Derzeit bin ich noch dabei ein Stoppbit einzufügen, um eindeutig zu erkennen ob Asuro den Strichcode von der richtigen Seite her überfahren hat.
Grüße,
Harri
Thema geteilt - die diskussion um die barcodes wird immer interessanter, und das eigentliche thema ideen kommt zu kurz...
Hab nun das mit dem Stoppbit hinbekommen. Durch einmaliges Auslassen eines weißen Abstandes ganz am rechten Ende des Barcodes kann man eindeutig sagen aus welcher Richtung Asuro die Daten liest, und gibt bei falscher Richtung einen Fehlercode aus.
In weiterer Folge könnte man Asuro ja dazu veranlassen, 'umzudenken' und den Barcode verkehrt herum zu lesen.
Anbei eine Skizze wie der Barcode auszusehen hat(natürlich schwarz weiß für optimalen Kontrast). Die Länge ist wegen des Stoppbits leicht angestiegen, und beträgt jetzt 165mm.
Den Quellcode poste ich dann morgen.
Grüße,
Harri
Hallo harry3,
laut Beschreibung in deinem EXCEL-Blatt: 'Versuch2' wird, so wie ich es vorgeschlagen hatte, mit jedem Tik der ODO-Scheiben eine Messung gemacht. Diese Daten zeigst du uns und wir können die Bit's im Barcode 'sehen'.
Ich habe aber noch das Problem, dass ich im Moment nicht sehen kann, wie der Asuro die Bit's sehen kann. Bis jetzt bildest du im EXCEL-Blatt in den Zeilen 10, 21, 31, 41, 51 eine Summe über die 5 vorherigen Messwerte (ohne den in der jeweiligen Zeile (10,21,..) einzubeziehen, schaust ob der Wert größer 'irgendwas' ist und sagst dann, das ist das Bit.
Warum machst du diese Berechnung nicht bei jeder Messung, sondern nur alle 10 Messungen?
In Zeile 31 rechnest du '=wenn(summe(A26:A30)>2;1;0))'
In Zeile 21 rechnest du '=wenn(summe(A16:A20)>2;1;0))'
Was machst du mit den Messwerten aus den Zeilen 21 bis 25?
Auf den Code bin ich total gespannt!
Das Format deines Barcodes müsste hervorragend zu einer Aufgabenstellung von stochri passen: Hier nachzuschlagen.
Meine Idee war im gleichen Thread hier vorgestellt. Auf dem dortigen Bild gibt es noch keine Barcodes. Deshalb hier nochmal 2 Stück dazu (mittlerweile leicht zerknittert):
Hallo Harry3,
alle Achtung, wie weit Du das Thema Barcode-Erkennung schon gebracht hast.
Was mir gerade noch eingefallen ist: Wäre es nicht besser, die Bits über die Strichbreite zu kodieren? z.B.: schmaler Strich=0, breiter Strich=1 ( ob weiß oder schwarz ist egal )
Stichwort: RZ-Code
Die allgemein verwendeten Barcodes verwenden teilweise Ansätze aus diesem Gedankengang.
Wikipedia
Die Kodierung über die Strichbreite hat den Vorteil, dass man nicht so leicht die Synchronisation verliert und man unabhängig von der Zeitdauer der Signale wird, falls die Strichbreiten relativ zueinander verglichen werden.Zitat:
Zur Darstellung sind je 4 verschiedene Balken- und Lückenbreiten notwendig, die insgesamt 32 Symbole definieren: Für die Ziffern 0-9 gibt es jeweils 3 Symbole (Codierung A, B, C)
Wenn man z.B. schräg über den Barcode fährt, wird es schwierig, den Code mit den Encoderticks zu synchronisieren, da er ja in die Länge gezogen wird.
Gruß,
stochri
habe ich auch schon vorgeschlagen, siehe weiter oben. aber ich wurde nicht erhört =)
dadurch könnte man ausserdem ganz gut platz sparen, weil nicht nur mithilfe von auslassungen sondern auch mithilfe von strich und lückenbreiten bits kodiert werden könnten.
Hallo
Genau das meinte ich mit:Zitat:
Die Kodierung über die Strichbreite hat den Vorteil, dass man nicht so leicht die Synchronisation verliert und man unabhängig von der Zeitdauer der Signale wird, falls die Strichbreiten relativ zueinander verglichen werden.
(Beitrag zeigen)Zitat:
Der Rest ist ein bisschen Rechenarbeit: Erste und letzte Flanke suchen, Gesamtlänge des Codes auf die einzelnen Bits verteilen....
Gruß
mic
sagt mal, man könnte doch auch ein bissl platz sparen, indem man 2 barcode-"hälften", die man gleichzeitig mit den beiden sensoren einliest, verwendet. allerdings müsste der asuro dann schön grade fahren. evtl könnte man dann mithilfe des odo-interrupts die barcodes lesen.
Der Barcode besteht aus 6 Strichen: Startbit, 3 Datenbits, Prüfbit, Stoppbit.Zitat:
Zitat von Sternthaler
Jedes Datenbit ist 5 Odometrie-Ticks lang. Das erste Datenbit beginnt bei Tick #11 und endet bei Tick #15. Ich addiere also die Werte zwischen #11 und #15 um zu sehen wie oft ein 1 Wert gemessen wurde und wie oft ein 0 Wert. Es könnte ja sein dass einmal ein Wert falsch gemessen wird, daher bilde ich sozusagen den Durchschnitt über die 5 Werte. Wenn mehr als 3 einen 1 Wert darstellen, kann man davon ausgehen, dass hier eine 1 gemessen wurde.
Dass ich in der Excel Tabelle den Wert aus der eigenen Zeile nicht berücksichtigt habe und dafür eins zu weit nach oben gelesen habe ist ein Fehler. Sollte jetzt passen(Anhang aktualisiert).
Die weißen Teile werden nicht berücksichtigt, daher lese ich diese Abschnitte auch nicht.
Unterschiedliche Strichbreiten hat man ja sowieso, entweder man macht die scharzen Striche unterschiedlich lang oder man macht die weißen Lücken unterschiedlich lang. Bei mir ist zweiteres der Fall. Man könnte natürlich auch noch eine Unterscheidung machen zwischen schmal, mittel, breit, dann könnte man pro Strich 3 Zustände codieren. Ist aber alles wieder ein Stück komplizierter. Ich hab hier einfach nur mal die Minimalversion gemacht - welche dann natürlich gerne erweitert und verbessert werden kann.
Zwei Strichcodes nebeneinander halte ich für weniger gut da man Asuro aufgrund der ungenauen Odometrie schwer wirklich ganz perfekt geradeausfahren lassen kann. Weiters müsste man dann in die Strichcodelesen Funktion auch noch einen Regler einbauen, das bläht den code nur unnötig auf.
Nicht umsonst habe ich eine Strichlänge von 50mm gewählt.
Grüße,
Harri
@harry3
Danke für deine Erklärung. Hört sich erst mal gut an.
Kleine Folgefrage(n): Wie synchronisiert du auf schwarze Bits? Soll heissen woher weißt du, wann du die weißen Bits unberücksichtigt lassen mußt? Wie fährt dein Asuro über den Barcode? Feste Startposition, oder 'in freier Fahrt' und der Barcode taucht 'unverhofft' auf? Programmcode?
Asuro fährt in freier Fahrt über eine weiße(!) Fläche. Sobald der erste schwarze Strich gefunden wurde, wird er als Startbit interpretiert und nun startet die Synchronisation mit der Odometrie.Zitat:
Zitat von Sternthaler
Nun werden die auftauchenden Helligkeitswerte ausgewertet und als 1 oder 0 abgespeichert. Nach einer Länge von exakt 165mm=55ticks bleibt Asuro stehen. Nun werden die im Array gesamelten Daten ausgewertet. Da wird unter anderem das Prüfbit verglichen, und außerdem geschaut ob ein Stoppbit vorhanden ist. Wenn nicht, dann nimmt Asuro an dass der Code aus der falschen Richtung überfahren wurde und gibt einen Fehlercode aus.
Gleiches gilt für das Prüfbit.
Nur wenn beide Bedingungen erfüllt sind, gibt Asuro den berechneten Dezimalwert zurück.
Code kommt sofort, ich muss nur noch die Debug Zeilen rauslöschen und das ganze in eine Funktion packen.
Grüße,
Harri
Und noch ein Danke für die prompte Funktionsbeschreibung.
hmm... wenn du ohnehin den ganzen barcode in ein array packst, dann sollte es doch auch möglich sein, bei falschrum gelesenem barcode das array umzudrehen. ich nehme mal an, dass du das array aus unsigned chars baust, ansonsten entsprechend ändern. ich nenne das array daten[]. auch die länge des arrays ("laenge") sollte bekannt sein. folgendes sollte dann helfen, das array umzudrehen, dann nochmal auswerteversuch starten:
der zweck: bis zur hälfte des arrays werden die werte mit dem entsprechenden gegenstück vertauscht (dreieckstausch). der zweck der minus 1: in einem zehner-array würde wenn i=0 ist, das nullte mit dem 10-0-1, also dem 9. und somit letzten element vertauscht werden. wäre die -1 nicht da, würde das ärger geben, es gibt ja kein 10tes element.Code:void umdrehen(void){
int i;
unsigned char tausch;
for(i=0;i<laenge/2;++i){
tausch = daten[i];
daten[i] = daten[laenge-i-1]; //die -1 nicht vergessen!
daten[laenge-i] = tausch;
}
}
So, nun also zum Code.
Die Stoppbiterkennung hat auf einmal 'gezickt', dadurch hats ein paar kleine Änderungen gegeben und es hat noch ein bisschen gedauert.
Hier also die Links zu dem, was ihr braucht:
+hsbarcodes.h
+barcode.gif
+barcode.xls
WICHTIG: Die Funktion ist für die 8er Odometriescheiben ausgelegt.
Wer andere Odometriescheiben besitzt muss hier ein paar kleine Änderungen durchführen.
Also, ich hoffe mal dass es bei Euch genauso funktioniert wie bei mir. Lest Euch die kurze Beschreibung in der Headerdatei durch, dort steht drinnen, wie ihr die Funktion an Euren Asuro anpassen könnt!
Grüße,
Harri
was hältst du von der umdreh-idee von oben?
Nicht schlecht - werde ich in einer zukünftigen Version mal einbauen.Zitat:
Zitat von damaltor
Ich bin jetzt noch dabei einen einfachen Regler einzubauen der mir den Asuro gerade über den Barcode fahren lässt.
Grüße,
Harri
jo das wäre wichtig.
wenn nach der umdreh-funktion immer noch kein gültiger barcode erkannt wird, kannst du von einem fehler beim einlesen ausgehen.
dafür gibts aber eigentlich eh das parity bit.Zitat:
Zitat von damaltor