Asuro und Barcodes

[harry3]

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?

Der Barcode besteht aus 6 Strichen: Startbit, 3 Datenbits, Prüfbit, Stoppbit.
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

[Sternthaler]

@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?

[harry3]

@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 musst? 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.

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

[Sternthaler]

Und noch ein Danke für die prompte Funktionsbeschreibung.

[damaltor]

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:

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;
   }
}

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.

[harry3]

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

[damaltor]

was hältst du von der umdreh-idee von oben?

[harry3]

was hältst du von der umdreh-idee von oben?

Nicht schlecht - werde ich in einer zukünftigen Version mal einbauen.
Ich bin jetzt noch dabei einen einfachen Regler einzubauen der mir den Asuro gerade über den Barcode fahren lässt.


Grüße,
Harri

[damaltor]

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.

[harry3]

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.