Asuro und Barcodes [Archiv]

Archiv verlassen und diese Seite im Standarddesign anzeigen : Asuro und Barcodes

damaltor

26.07.2007, 21:25

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.ä.

stochri

26.07.2007, 22:11

und den asuro mit sehr exakter geschwindigkeit

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.

stochri

Sternthaler

27.07.2007, 02:16

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.

damaltor

29.07.2007, 20:24

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

# # ### # ### # ### # ###

Sternthaler

30.07.2007, 02:52

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.

damaltor

30.07.2007, 09:16

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.

Sternthaler

30.07.2007, 09:32

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

harry3

30.07.2007, 20:55

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:

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

radbruch

30.07.2007, 22:50

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

Sternthaler

31.07.2007, 02:05

@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 (https://www.roboternetz.de/phpBB2/zeigebeitrag.php?p=108945#108945) 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.

harry3

31.07.2007, 19:39

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

Sternthaler

31.07.2007, 20:48

Hallo harry3,
warum benutzt du nicht die von mir vorgeschlagenen Barcodes aus meinem Post? siehe oben (https://www.roboternetz.de/phpBB2/zeigebeitrag.php?p=301916#301916)
- 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.

harry3

01.08.2007, 18:57

Hallo harry3,
warum benutzt du nicht die von mir vorgeschlagenen Barcodes aus meinem Post?

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".

Scheint an unterschiedlichen Excelversionen zu liegen.
Ein Screenshot vom Excelblatt mit den gezeichneten Barcodes wäre nett.

Grüße,
Harri

Sternthaler

02.08.2007, 00:49

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

harry3

02.08.2007, 19:15

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

Sternthaler

02.08.2007, 19:54

Ähm harry3,
lies doch bitte nochmal den von mir geschriebenen Text zum Aufbau der Barcodes in Ruhe durch. Ja, sei so lieb.

harry3

02.08.2007, 20:05

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

Sternthaler

03.08.2007, 00:55

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, ;-)

harry3

03.08.2007, 15:10

Ok, ich sehe schon wir meinen beide das gleiche, nbur dass es halt jeder anders beschreibt :wink:

Alle Striche sind gleich breit, nur sind manche Striche einfach nicht zu sehen.

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:

Also ich werde heute mal mit der Umsetzung beginnen und mich dann sobald ich erste Ergebnisse erzielt habe mich wieder melden.

Grüße,
Harri

damaltor

03.08.2007, 16:48

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.

harry3

03.08.2007, 22:49

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

damaltor

03.08.2007, 23:19

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 =)

harry3

04.08.2007, 00:16

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.

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

damaltor

04.08.2007, 00:34

Thema geteilt - die diskussion um die barcodes wird immer interessanter, und das eigentliche thema ideen kommt zu kurz...

harry3

04.08.2007, 01:38

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

Sternthaler

04.08.2007, 02:09

stochri

04.08.2007, 08:11

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 (http://de.wikipedia.org/wiki/RZ-Code)

Die allgemein verwendeten Barcodes (http://de.wikipedia.org/wiki/Barcode) verwenden teilweise Ansätze aus diesem Gedankengang.

Wikipedia

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)

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.
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

damaltor

04.08.2007, 09:52

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.

radbruch

04.08.2007, 11:39

Hallo

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.

Genau das meinte ich mit:

Der Rest ist ein bisschen Rechenarbeit: Erste und letzte Flanke suchen, Gesamtlänge des Codes auf die einzelnen Bits verteilen....(Beitrag zeigen (https://www.roboternetz.de/phpBB2/viewtopic.php?p=302789#302789))

Gruß

mic

damaltor

04.08.2007, 13:24

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.

harry3

04.08.2007, 15:47

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

04.08.2007, 18:28

harry3

04.08.2007, 18:37

@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

04.08.2007, 19:52

Und noch ein Danke für die prompte Funktionsbeschreibung.

damaltor

04.08.2007, 20:14

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

04.08.2007, 21:04

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 (http://harry3.uttx.net/Daten/asuro/hsbarcode.html)
+barcode.gif (http://harry3.uttx.net/Daten/asuro/barcode.gif)
+barcode.xls (http://harry3.uttx.net/Daten/asuro/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

04.08.2007, 23:06

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

harry3

04.08.2007, 23:25

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

04.08.2007, 23:34

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

04.08.2007, 23:58

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.

harry3

05.08.2007, 00:58

So, Ziel ist erreicht. Ein Primitivst Regler hält Asuro die paar cm lang einigermaßen in Richtung. Weiters habe ich es jetzt so gemacht dass Asuro nur noch 10cm lang versucht einen Barcode zu finden. Wenn er bis dorthin keinen gefunden hat, bricht er ab.

Hier der aktualisierte Code:

/*Einstellungen um Asuro fit für die Barcode-Funktion zu machen.*/
/*Geschwindigkeit links/rechts definieren=>damit Asuro geradeausfährt*/
#define BC_SPEED 90
/*Hell/Dunkel Schwelle für Odometrie.
Linke Odometrie wird als Referenz verwendet*/
#define BC_OLSCHWELLE 600
#define BC_ORSCHWELLE 730
/*Hell/Dunkel Schwelle für Barcode*/
#define BC_LSCHWELLE 45

/*Einstellungen um das Barcode zu ändern.*/
/*ACHTUNG: Bei Veränderungen von BC_STRICH_ANZAHL müssen in der Funktion
2 Anpassungen vorgenommen werden! Näheres siehe in der Funktion!*/
/*Anzahl der Datenbits*/
#define BC_DATENBITS_ANZAHL 3
/*Anzahl der Striche(Startbit+Datenbits+Prüfbit inklusive Stoppbit)*/
#define BC_STRICH_ANZAHL 5
/*Wie oft pro Strich der Helligkeitswert gemessen werden soll
ACHTUNG: dafür muss die Strichbreite angepasst werden*/
#define BC_ABTASTUNGEN_PRO_STRICH 5
/*Um im bin_erg[] eine 1 auszulösen, müssen pro Strich mindestens
BC_ABTASTUNGEN_PRO_STRICH-2 Messwerte 1 sein. */
#define BC_LOGIKSCHWELLE 3
/*Anzahl der Werte im daten[] Array*/
#define BC_MAX_WERTE 55
/*Fehlercodes*/
#define BC_FEHLER_PARITY 255
#define BC_FEHLER_RICHTUNG 254

unsigned char fkt_barcode_lesen(void)
{
unsigned int ldata[2]={0},odata[2]={0};
unsigned int led_on[2]={0},led_off[2]={0};
unsigned int links=0,rechts=0,ges=0;

unsigned char flag_l=0,flag_r=0,n=0,startbit=0,summe=0,index=0,d ez_erg=0,richtung=0;
unsigned char odo_counter=0,counter_l=0,counter_r=0,speed_l=BC_S PEED,speed_r=BC_SPEED;
unsigned char daten[BC_MAX_WERTE]={0},bin_erg[BC_STRICH_ANZAHL-1]={0};
MotorDir(FWD,FWD);
MotorSpeed(BC_SPEED,BC_SPEED);
StatusLED(OFF);

/*Wegstrecke(odocounter) ab Startbit messen*/
while(odo_counter<BC_MAX_WERTE)
{

OdometrieData(odata);
MotorSpeed(speed_l,speed_r);

/*Bei jedem Tick daten[] Array auffüllen.*/
if( (flag_l==0 && odata[0]>BC_OLSCHWELLE) ||
(flag_l==1 && odata[0]<BC_OLSCHWELLE) )
{
counter_l++;
FrontLED(ON);
LineData(ldata);
led_on[0]=ldata[0];
led_on[1]=ldata[1];

FrontLED(OFF);
LineData(ldata);
led_off[0]=ldata[0];
led_off[1]=ldata[1];

links=led_on[0]-led_off[0];
rechts=led_on[1]-led_off[1];
ges=(links+rechts)/2;

if(ges<BC_LSCHWELLE)
{
daten[odo_counter]=1;
if(startbit==0)
{
StatusLED(GREEN);
startbit=1;
}
}

if(flag_l==0)
flag_l=1;

else
flag_l=0;

if(startbit!=0)
{
odo_counter++;
}
}

if( (flag_r==0 && odata[1]>BC_ORSCHWELLE) ||
(flag_r==1 && odata[1]<BC_ORSCHWELLE) )
{
counter_r++;

if(flag_r==0)
flag_r=1;

else
flag_r=0;
}

if(Gettime()%75==0 && (counter_l>3 || counter_r>3) )
{
if(counter_l<counter_r)
{
speed_l=speed_l+1;
}
else if(counter_l>counter_r)
{
speed_l=speed_l-1;
}
if( (counter_l>35 || counter_r>35) && startbit==0)
break;
}

}

MotorDir(BREAK,BREAK);
MotorSpeed(0,0);

/*Binärzahl aufbauen + Prüfbit*/
for(n=0;n<BC_MAX_WERTE;n++)
{

summe=summe+daten[n];

/*Wenn BC_STRICH_ANZAHL verändert wird,
muss hier ein entsprechender Eintrag erfolgen*/
if((n+1)%BC_ABTASTUNGEN_PRO_STRICH==0)
{
if((n+1)==(BC_ABTASTUNGEN_PRO_STRICH*3)
||
(n+1)==(BC_ABTASTUNGEN_PRO_STRICH*5)
||
(n+1)==(BC_ABTASTUNGEN_PRO_STRICH*7)
||
(n+1)==(BC_ABTASTUNGEN_PRO_STRICH*9))
{
if(summe>=BC_LOGIKSCHWELLE)
bin_erg[index]=1;
else
bin_erg[index]=0;

index++;

}

summe=0;
}

}

/*Richtung erkennen*/
/*Wenn BC_STRICH_ANZAHL verändert wird,
muss hier der Faktor angepasst werden.*/
summe=0;
for(n=(BC_ABTASTUNGEN_PRO_STRICH*9);n<(BC_ABTASTUNGEN_PRO_STRICH*11);n++)
{
summe=summe+daten[n];
}
if(summe>=(BC_ABTASTUNGEN_PRO_STRICH*2-BC_LOGIKSCHWELLE))
richtung=1;

/*Binärzahl umwandeln in Dezimalzahl oder Fehlercode zurückgeben*/

/*alles OK => Dezimalzahl zurückgeben*/
if((bin_erg[0]+bin_erg[1]+bin_erg[2])%2!=bin_erg[3] && richtung==1)
dez_erg=4*bin_erg[0]+2*bin_erg[1]+1*bin_erg[2];

/*Fehlercode BC_FEHLER_RICHTUNG->falsche Richtung*/
else if((bin_erg[0]+bin_erg[1]+bin_erg[2])%2!=bin_erg[3] && richtung==0)
dez_erg=BC_FEHLER_RICHTUNG;

/*Prüfbit falsch*/
else
dez_erg=BC_FEHLER_PARITY;

StatusLED(OFF);

return dez_erg;
}

Beispiel Anwendung der Funktion:

unsigned char fkt_taster(void);

int main(void)
{
unsigned char c=0,d=0;

Init();

while(1)
{
c=fkt_barcode_lesen();
SerPrint("\r\nBarcode=");
PrintInt(c);

if(c!=255 && c!=254)
{
for(d=0;d<c;d++)
{
Msleep(500);
StatusLED(GREEN);
Msleep(500);
StatusLED(OFF);
}
}
while(fkt_taster()==0);
}

return 0;
}

unsigned char fkt_taster(void)
{
unsigned char taster=0;

taster=PollSwitch();

if(taster==PollSwitch() && taster!=0)
return taster;
else
return 0;
}

harry3

06.08.2007, 20:38

Und hats schon jemand ausprobiert?
Wenn ja funktionierts bei Euch?

Grüße,
Harri

Sternthaler

07.08.2007, 00:12

Ja, gerade eben ausprobiert.

Ich musste erst noch eine andere Breite für die Barcode-Striche und -Lücken in EXCEL suchen, und so kann ich erst einmal alle Barcodes zu ca. 80% lesen, die GENAU EIN schwarzes Datenbit haben.
2 schwarze Datenbits werden eher nur zu 10% gelesen, und alls 3 Bits in schwarz habe ich bis jetzt noch nicht geschafft.

Versucht habe ich es mit 5 verschiedenen Breiten der Striche. Der erste Druckversuch mit der rein mathematisch berechneten Breite (8-er ODO => 1.5 mm/Tik) hatte eigendlich auch noch am besten funktioniert.

Alle nicht gelesenen Codes liefern nach einem 'Zufallssystem' die beiden Fehlermeldungen zurück. (Richtung, Prüfbit)

Trotzdem schon mal nicht schlecht Herr Specht.

P.S.: Liegt es am Stopcode-Bit?
Ich habe es wie im oberen Bild gedruckt, da es so aus der EXCEL-Tabelle herraus druckbar ist im Gegensatz zu dem Image, welches du da abgelegt hast. Das Image deutet aber eher ein Stop-Bit an, welches direkt ohne Lücke hinter dem Prüfbit zu malen wäre bei doppelter Breite. (Vielleicht hast du es ja schon beschrieben, aber im Moment finde ich dazu keine Angabe.)

harry3

07.08.2007, 20:17

Wenn du eine 8er ODO hast musst du BC_ABTASTUNGEN_PRO_STRICH von 5 auf 10 setzen. Weiters würde ich mit der BC_LOGIKSCHWELLE etwas raufgehen, so ein Wert um 7 sollte passen.

Asuro muss über eine weiße Fläche fahren, sobald er den ersten schwarzen Strich erkennt fährt er genau 165mm weit. Das kannst du ja ausmessen und damit vergleichen ob du die Werte richtig eingestellt hast.

Weiters solltest du darauf achten dass die Barcodes möglichst millimetergenau gedruckt werden.

Das Stoppbit(in der Breite von 2 Strich) verschmilzt mit dem eventuell vorhandenen Prüfbit(als ein max. 45mm breiter Strich kann entstehen im Extremfall).
Ich hab mal die Zahlen 4...7 im Anhang angehängt, da sollte man es schön erkennen.
Wenn du außerdem AutoCAD hast kannst du dir die Barcodes von dort ausdrucken(siehe Anhang), du musst nur das Rechteck um die Barcodes an die druckbare A4 Größe anpassen, und dann beim Plotten dies als "Fenster" wählen. Damit kann man dann auf den mm genau drucken.

Ich hoffe dass es nun bei dir funktioniert, sonst helf ich natürlich gern weiter(mich interessiert es ja schließlich auch wie "portabel" so ein Asuro Programm denn ist).

Dieses WE werde ich mal etwas angehen was mich schon seit Ewigkeiten nervt: Eine vernünftige Geradeausfahr-Regelung für Asuro. Ich hab zwar schon einen PI Regler mal gebaut aber diesmal probier ich es auf einen anderen Weg womit man hoffentlich noch bessere Resulate erzielt. Damit man Asuro auch mal perfekt gerade über Strichcodes fahren lassen kann.

Grüße,
Harri

Sternthaler

08.08.2007, 18:56

Hallo harry3,
den PID-Regler von waste, unter diesem Link (https://www.roboternetz.de/phpBB2/zeigebeitrag.php?t=11818) kann ich nur empfehlen. waste hat ihn zwar für die Linienverfolgung geschrieben, aber ein kleiner Umbau, und schon kann er auch geradeausfahren.
Ich habe eine Interrupt-Feste Version davon, soll heißen man kann geradeausfahren 'lassen' und sich dann um seine eigentliche Aufgabe (Barcodes?) kümmern. Interresse?

harry3

08.08.2007, 19:35

Ja zeig mal her den Code für die Interrupt Funktion.

Ich hab den Regler etwas anders in Planung, aber schaden kann es ja trotzdem nicht andere Ideen zu sehen.

Grüße,
Harri

Sternthaler

11.08.2007, 01:25

Hier kommt dann mal die Ersatz-Asuro-LIB von SternThaler.

Kleine Übersicht:

--- Timer-Interrupt:
Sorgt mit dem langen, aber schnellen Code für das 'anschieben' eines weiteren ADC-Wandlers.

--- main()-Funktion:
- Starten der gewünschte Wandlergruppe (Hier sinnvoll: ODO)
- Fahrstrecke vorgeben
- Loop-Schleife mit zeitgesteuertem Sheduler
- Alle 2ms den PID-Regler von waste aufrufen

--- waste-PID-Regler:
Je nach gewünschtem Regelverhalten ODO- oder LINIEN-Regler nutzen.

Timer-Interrupt und waste-PID-Regler sind in asuro_st.c/h
main() natürlich in test.c
Hinweise:
- Tik-Anzahl-Vorgabe bei den Tasten bezieht sich auf 8-er Scheiben.
- Infos zur Tastenbelegung in test.c. (Asuro von vorne ansehen: Taste 1 = links)
- ODO-Messungen benötigen Anpassungen für die Tik-Ermittlung.
In der Datei asuro_hw.h sind dafür die Defines HW_RAD_SCHWELLE_LINKS und HW_RAD_SCHWELLE_RECHTS

@harry3
Ich möchte nicht, dass du aus meinem Code die Kommentare entfernst, die Funktionsnamen änderst und dann in deinem Link "Meine erstellten Asuro Funktionen..." wieder auftauchen [-X .

harry3

11.08.2007, 01:43

Danke ich werds mir anschauen.
Hab aber inzwischen bereits eine gute Lösung hinbekommen mit Hilfe eines einfachen P Reglers(der I Anteil steckt eh schon in der gemessenen Wegstrecke drinnen).

@harry3
Ich möchte nicht, dass du aus meinem Code die Kommentare entfernst, die Funktionsnamen änderst und dann in deinem Link "Meine erstellten Asuro Funktionen..." wieder auftauchen [-X .

Wenn ich Codeteile von anderen verwendet habe habe ich diese immer namentlich erwähnt(und das ist im konkreten Fall nur der PID Linienfolger von waste). Die von mir ins Internet gestellte Headerdatei wird jetzt aber sowieso verschwinden weil ich meine ganzen Funktionen nun in eine Menge Einzeldateien geteilt habe um Speicherplatz zu sparen und um etwas mehr Übersicht in die Sache zu bringen.

Hier nun der aktuelle Code zum Barcodelesen mitsamt des Reglers:

hs_barcode.h (http://harry3.uttx.net/Daten/asuro/hsbarcode.html)

Sternthaler

11.08.2007, 02:24

Hallo harry3,
ich habe gerade in deine hs_barcode.h geschaut. (Warum eigendlich immer *.h?)
Ist auch eine schöne Lösung für die 'parallel' zu erledigenden Arbeiten. Da wirst du dich bestimmt wundern, wie kompliziert ich es gemacht habe.

Im Kommentar deiner Datei schreibst du folgendes:
WICHTIG: Die Funktion wurde für die 8er Odometriescheibe ausgelegt(1 Tick=3mm).Kann es sein, dass du die 6-er Scheiben meinst?
Bei meinen 8-er-Scheiben fahre ich nämlich 1,5 mm / Tik.
Aber warum sollte man dann bei einer 6-er-Scheibe auf 3 mm / Tik kommen?
Das Verhältnis 8 zu 6 entspricht ja nicht 3 zu 1,5. Gibt es beim Asuro eventuell noch andere Getriebeuntersetzungen / Raddurchmesser?
Meine beiden Zahnräder haben laut Anleitung jeweils eine Untersetzung von 50 zu 10. Der Raddurchmesser beträgt ca. 38.1 mm
Rad-Umfang also 119,7 mm
Umfang / eine Getriebestufe = 119,7 / 5 = 23,94 mm
Das durch 8 * 2 SW- bzw. WS-Wechsel = 23,94 / 16 = 1,496 also ca. 1,5 mm / Tik. (bei meinem Asuro)

P.S.: Mit der Anleitung, dass das Stop-Bit eine doppelte Breite hat, ist die Trefferquote bei mir auch eine 'Ecke' besser geworden.

damaltor

11.08.2007, 09:00

wenn man es genau betrachtet, hat die andere scheibe auch nicht 6 flächen, sondern 12 8schwarz und weiss).
raddurchmesser: ~38 mm
umfang: ~120 mm
nach getriebestufe: ~24 mm
durch ticks: ~2 mm.

gute frage woher dann die 3 mm kommen... wer hat das nur ausgerechnet...

Sternthaler

11.08.2007, 11:28

Eben, die Frage hatte ich mir auch gestellt.

Also auch hier mal mit deinen Angaben gerechnet:
Rad-Umfang somit 119,4 mm (Also gleich)
Umfang / eine Getriebestufe = 119,4 / 5 = 23,88 mm (auch gleich)
Das durch 6 * 2 SW- bzw. WS-Wechsel = 23,88 / 12 = 1,999 also glatt 2 mm / Tik. (Das muss dann ja mehr sein)

Jetzt passen auch die Verhältnisse 8 / 6 Tik und 1,5 / 2 mm perfekt zueinander.

@harry3
Wie hast du gerechnet? Bzw. wie groß sind deine Räder am Asuro?

harry3

11.08.2007, 14:16

Der Unterschied ergibt sich aus den Odo Scheiben.

Ich hab bei der Odoscheibe 4 weiße und 4 schwarze Flächen, also insgesamt 8 Übergänge(daher meine Bezeichnung "8er Odo"). Wenn sich die Scheibe einmal dreht hat man 8 ticks.
Das Rad hat die gleichen Abmessungen wie bei Euch. Bei einem Umfang von 120mm und einer Übersetzung von 5:1 ergibt das:
Wenn sich das Rad 1 mal dreht so dreht sich die Odoscheibe 5 mal. 5 Umdrehungen ergeben 8*5=40 ticks. Diese 40ticks entsprechen einer Wegstrecke von 120mm, folglich entspricht 1 tick=120mm/40ticks=3mm/tick.
Bei 12 Übergängen sind dann wie bereits erwähnt 2mm/tick.

Funktionierts bei dir jetzt?

Ich packe meine erstellten Funktionen immer in Headerdateien. So kann ich, je nach Bedarf, immer die jeweilig gebrauchten Funktionen in mein Hauptprogramm includen.

Sternthaler

12.08.2007, 03:21

Hallo harry3,
ja, mit einigen Anpassungen an den Defines (schön eingebaut!) klappt es nun recht gut. Nicht zu 100% und auch nicht so, dass der Asuro erst nach dem Erkennen des Startbits die Auswertung vornimmt. Ich habe aber just gerade den Define für BC_LSCHWELLE gesehen. Da werde ich nochmal dran schrauben.

Na, das mit dem h am Ende hat sich ja nun geklärt. Du darfst solche 'Funktionsblöcke' aber auch mit c enden lassen und kannst sie dann auch includen. (Weißt du aber bestimmt auch.) Kleiner Vorteil wäre es dann, wenn du, wie bei der jetzigen Asuro-LIB, mal eine echte LIB mit der a-Endung machen möchtest. c-Dateien werden vom gcc im Makefile übersetzt, h-Dateien nicht.

harry3

12.08.2007, 12:59

Anscheinend erkennt der Asuro zu früh einen schwarzen Strich wo noch gar keiner ist. Wie du richtig erkannt hast ist BC_LSCHWELLE da der Wert an dem du drehen musst.
Du müsstest ihn tiefer stellen(probier z.B. mal den Wert 40).

Eine lib wäre gar keine schlechte Idee. Soviel ich weiß spart man sich dadurch ja einiges an Programmspeicher!?

Grüße,
Harri