ASURO emittelt Werte für Lib V2.70 myasuro.h selber

Hallo Leute,
ich habe mich mal dran gemacht, dass der Asuro die Parameter in der Datei myasuro.h aus der Asuro Lib V2.70 (Release Candidate 3) selber ermittelt.

Bis jetzt können mit dem angehängten Programm (V200) folgende Werte ermittelt werden:

-- Für die Tastenberechnung
MY_SWITCH_VALUE

-- Für die Odometrie
MY_ODO_LIGHT_VALUE_L
MY_ODO_DARK_VALUE_L
MY_ODO_LIGHT_VALUE_R
MY_ODO_DARK_VALUE_R

-- Für die Go()-Funktion
MY_GO_ENC_COUNT_VALUE

-- Für die Turn()-Funktion
MY_GO_ENC_COUNT_VALUE

[EDIT] Nun können auch die beiden Werte für die Funktionen Go() und Turn() ermittelt werden.
-- Somit fehlt nur noch der Wert für die Motordifferenz
MY_MOTOR_DIFF

Das 'Packet' besteht aus 2 Teilen:
1) Asuro-Programm
2) Windows-Programm (Installationsfunktion ist dabei)


Das Asuro-Programm besteht im Wesentlichen aus 3 Teilen:
1 a) Automatisches Erfassen aller Messwerte über Interrupt und senden an den PC
1 b) Hauptprogramm zum starten der einzelnen Testkomponenten und zur
'Beantwortung' der im PC-Porgramm gestellten 'Aufgaben' über die Tasten.
1 c) Ermittlungsfunktionen für MY_????_VALUE's


Das Windows-Programm teilt sich in 4 Teile:
2 a) Serielle Schnittstelle zur IR-Kommunikation einstellen.
2 b) Permanete Anzeige der Sensordaten vom Asuro
2 c) Bedienungsanleitung zur Ermittlung der Asuro-Parameter
2 d) Datenausgabe vom Asuro bei der Ermittlung

Da das Ganze bis jetzt noch in einem Beta(2)-Stadium ist, seit bitte etwas nachsichtig mit mir.
Unterstützt, durch hilfreiches Testen, hat mich immer m.a.r.v.i.n.
Deshalb hier ein ganz großes Danke an dich.


Da das Windows-Programm (mit Installer) als Attachment etwas zu groß ist, kann es hier gefunden werden:
Version 200 : PCSensorenV200.zip (ca. 2,1 MB)

Das Asuro-Programm ist als Attachment vorhanden.
[EDIT 21.01.2010] Ist unten an diesem Beitrag sichtbar/downlodbar, wenn man als User angemeldet ist.

[EDIT] Die Ausgabe vom Test 2 der MY_ODO_[LIGHT|DARK]_VALUE_[L|R] - Werte getauscht, da sie falschrum ausgegeben wurden.
Entfernen der alten Versionen.
[EDIT 31.12.2008] Link zum 'PCSensorenV200.zip'-Programm angepasst.


Grundsätzliche Bedienung:
- Windows-Programm installieren.
- Asuro-Programm flashen.
- Windows-Programm starten und die korrekte Schnittstelle auswählen.
- Asuro mit 'Sichtverbindung' einschalten. (KEINE TASTEN drücken)
- 'Test 1: Tastaturabfrage' im Windows-Programm mit Button 'Wie geht's' starten. Bedienungsanleitung im Windows-Programm LESEN und ausführen.
- 'Test 2: Odometrie / Encoder' ebenso bearbeiten.
- 'Test 3 und 4': dito

ACHTUNG:
Taste 6 (rechte Taste, wenn man von VORNE auf den Asuro schaut) fährt einen Nikolaus mit ca. 50cm Kantenlänge. Sind die Odometriewerte noch nicht korrekt, kann der ASURO VOM TISCH FALLEN. AUFPASSEN, ich übernehme keine Garantie.

(0602420022)

bin im moment etwas gehandicapt was das ausprobieren betrifft (problem mit flashen), aber finde so ein programm super...

seeehr schön, das ist wirklich eine ganz geute idee. so gibts keine probleme mehr mit rumprobiere-werten.

allerdings sind die werte doch nur für den entsprechenden untergrund, oder?

was passiert bei einem asuro (wie meinem) der keine liniensensoren hat? kann man diesen schritt überspringen?

habe nur den kleinen rechner dabei, und unter linux windiws applikationen zu starten ist recht prozessorintensiv. teste es morgen an dem großen rechner.

Sternthaler super Lösung. Das werde ich meinen Schülern auch empfehlen.
Ich habe bisher keinen Fehler feststellen können, alle Werte entsprechen meinen selbstermittelten Einstellungen.

[Edit:] Nachtrag, bei mir sagt der Compiler < 74% also 6028Bytes, da könnten die restlichen Testprogramme doch noch hineinpassen. (Klar, der Bootloader geht auch noch von ab.)

Zitat:

---

Zitat von inka

... (problem mit flashen), aber finde so ein programm super...

---

Ich finde das super, dass du das super findest ;-) Danke.
Ich drücke die Daumen, dass das flashen bald wieder geht.

Zitat:

---

Zitat von damaltor

seeehr schön, ...

---

Danke

Zitat:

---

Zitat von damaltor

.. entsprechenden untergrund, oder?
was passiert bei einem asuro der keine liniensensoren hat?

---

Da mein Programm die Liniensensoren aktuell nur liesst und die Werte nur sendet (keine Auswertung), kann eigendlich nichts schief gehen. Hauptsache ist dann aber, dass vor allem am LED-Anschluß nichts angeschlossen ist was kaputt gehen könnte, wenn ich dort ständig den Strom an- und abschalte. -> Erweiterungen also lieber abmachen.

Zitat:

---

Zitat von damaltor

kann man diesen schritt überspringen?

---

Nein, aktuell kann man den Schritt (Linienensensoren lesen) nicht abschalten.

Zitat:

---

Zitat von damaltor

.. unter linux windiws ..

---

Da habe ich keine Alternative geplant. (Mir reicht es vollkommen mich mit XP rumzuärgern.)

Zitat:

---

Zitat von Volley

Sternthaler super Lösung.

---

Auch dir ein Dank für das Lob.

Zitat:

---

Zitat von Volley

.. meinen Schülern empfehlen.

---

Was empfiehlst du? So ein Programm mal selber zu schreiben, oder 'nur' zu nutzen? Kommt natürlich auf die/den Klasse/Jahrgang an, was da schon möglich ist.

Zitat:

---

Zitat von Volley

.. keinen Fehler feststellen können

---

Da geht das Lob vor allem an m.a.r.v.i.n, da er ein sehr geduldiger Beta-Tester war/ist.

Zitat:

---

Zitat von Volley

.. da könnten die restlichen Testprogramme doch noch hineinpassen.

---

Ja, da habe ich schon ein bisschen Platz schaffen können, aber wenn der 3.te Test nicht reinpasst, dann ist da nun mal im Moment Schluß.

Zitat:

---

Zitat von Sternthaler

...

Zitat:

---

Zitat von Volley

.. meinen Schülern empfehlen.

---

Was empfiehlst du? So ein Programm mal selber zu schreiben, oder 'nur' zu nutzen? Kommt natürlich auf die/den Klasse/Jahrgang an, was da schon möglich ist.
...

---

Im Moment haben 8 Kinder (5. -8. Klasse) meiner AG einen ASURO zu Weihnachten bekommen. Für sie war es hauptsächlich der Abschluss ihres Lötkurses. Einen kleinen C-Kurs habe ich auch mit ihnen und ihrem ASURO gemacht. Ich werde ihnen empfehlen dein Programm zu benutzen.
In der Robotik-AG bauen die Kinder ansonsten Roboter für FLL, IRC, RCJ und Roboking.

hi also ich hab des programm mal probiert und bei mir funktioniert nichts, d.h. mein asuro startet das programm das ich zuletzt geflasht habe. kann mir da jemand evtl. helfen?

du hast evtl die falsche .hex-datei geflasht. oder aber, es wurde überhaupt nicht grflasht. einfach nochmal probieren, und genau auf denm pfad zur datei achten.

ne ich hab nix geflasht. welches programm muss ich flashen?

habs in griff bekommen, ich hab jetzt nur noch ein problem nämlich mein asuro fährt statt einen 90 grad winkel einen 120 grad winkel, welche einstellung muss ich da vornehmen?

keine. du hast die falschen odometrie-scheiben aufgeklebt. nimm die anderen, klebe sie auf dei zahnräder und probiere es nochmal.

Hallo Stop, Stopp, Stopp
der Asuro soll beim Test 2 nur CIRCA eine Umdrehung machen.
Dabei werden die Odometrie-Parameter erst VERMESSSEN.
Erst danach sind die korrekten ODO-Parameter bekannt und können für eine GERADEAUS-Fahrt bei Taste 6 (von vorn auf den Asuro gesehen die rechte Taste) benutzt werden!

Zitat:

---

Zitat von Volley

.. 8 Kinder (5. -8. Klasse) meiner AG ..
... In der Robotik-AG bauen die Kinder ansonsten Roboter für FLL, IRC, RCJ und Roboking.

---

Wow, ich habe mich mal etwas auf deiner, in der Fußzeile angegeben, Seite umgesehen. Schade, dass ich nicht mehr in so einer Klasse bin. Ich bin mir ziemlich sicher, dass die Motivation der Kiddis recht hoch ist.
Ich hoffe, dass ihr auch etwas mit Version V200 anfangen könnt.

Zitat:

---

Zitat von Sternthaler

Verfasst am: 06.06.2007, 02:05 Titel:

---

Nachtschwärmer. :-)

Zitat:

---

Zitat von Sternthaler

...
Wow, ich habe mich mal etwas auf deiner, in der Fußzeile angegeben, Seite umgesehen. Schade, dass ich nicht mehr in so einer Klasse bin. Ich bin mir ziemlich sicher, dass die Motivation der Kiddis recht hoch ist.
...

---

Ja, die sind sehr eifrig.

Zitat:

---

Zitat von Sternthaler

...
Ich hoffe, dass ihr auch etwas mit Version V200 anfangen könnt.

---

Danke für den Hinweis, heute wollen wir deine Software das erste mal in der AG testen. Da werde ich mal schnell noch die neue Version herunterladen.

Verfasst am: Heute um 08:57

Frühaufsteher... =)

Zitat:

---

Zitat von damaltor

Verfasst am: Heute um 08:57

Frühaufsteher... =)

---

Hihi, da war die erste Mathematikstunde schon rum ...

@Sternthaler: Die Test deiner Software haben auf 5 ASUROS super funktionert. Auf dreien gab es zu Anfang noch ein wenig Probleme. Ursache waren schlecht eingestellte Überträger.

Also, noch mal dickes Lob für deine Software!

Schön, dass es so gut bei diesem Massentest funktioniert hat.
Aber was soll eigendlich das 'Nachtschwärmer' bedeuten? Da fängt der Tag doch erst an ;-)

hat auch bei mir gut funktioniert, danke, beeindruckendes programm...

@inka
Freut mich, dass es auch bei dir geht.

ich habe noch ein bischen experimentiert:
- zunächst einmal die 18er odoscheiben mit den "tangentialen" dreiecken aufgeklebt
- die werte vom programm vermessen lassen, myasuro.h geändert

- unterschied der gemessenen werte:
bei go 12er - 20740 /18er - 14115
bei rurn 12er - 147 / 18er - 227

dass es da unterschiede geben muss, war mir klar. Auch kann man alles einstellen, kürzer/länger fahren und drehen lassen.
wenn ich die werte mit meinem minitestprogramm https://www.roboternetz.de/phpBB2/vi...d5b51f48aa11b9 teste, ist die gefahrene strecke aber kürzer und der winkel nicht 90, sondern ca.70 grad.
Woran kann das liegen? Werden die messungen nicht abhängig von den odo scheibe gemacht?

Bei mir werden die durch Asuro gesendeten daten nicht von das Windows programm ausgewertet. Links wird nach wählen von der richtigen schnittstelle der text "Break empfangen 1" angegeben. Weiter passiert nichts im Sensoren bereich. Auch nicht wenn ich die tests probiere.
Im Hyperterminal sehe ich aber das daten empfangen werden.

Mache ich etwas falsch?

ich glaube den fehler gefunden zu haben:
auf der netzwerkfestplatte (NAS) stimmte die zeit nicht, weil wir heute mittag einen stromausfall hatten und ich habe die zeit nicht korrigiert.
Kann es sein, dass AVR-studio in so einem fall auch das neuere geändert file nicht nimmt, weil es glaubt bereits ein neueres zu haben (weil das auf dem netz nicht die richtige zeit hat)???

noch eine frage:
kann man in bei der turn() funktion auch winkelminuten angeben?
edit: (90+91)/2 =90,5??

Zitat:

---

Zitat von Petje

Links wird nach wählen von der richtigen schnittstelle der text "Break empfangen 1" angegeben.
Im Hyperterminal sehe ich aber das daten empfangen werden.
Mache ich etwas falsch?

---

Hallo Petje, eigendlich kann man nicht viel falsch machen. (War zumindest mein Wunsch bei dem Programm.)
Die von dir angegebene Fehlermeldung für das MSComm-Element heißt bei Microsoft Visual Basic (VB5 Copyright 1987-1997) wörtlich: "comBreak 1001 Es wurde ein Anhaltesignal (Break-Signal) empfangen.".
(Das Internet hilft mir da leider nicht weiter, was das denn nun eigendlich heissen soll.)
Die dahinterstehende 1 sagt nur, dass das Break-Signal auf der Schnittstelle COM 1 empfangen wurde.

Hast du die COM-Schnittstelle 1 ausgewählt?
An welcher Schnittstelle ist dein IR-Empfänger?
Welche der 10 möglichen COM1 bis COM10 sind bei dir aktiviert?
Ich suche bis zu 10 Schnittstellen ab, ob sie aktivierbar sind und lasse dann die letzte gefundene Schnittstelle aktiv. Ist bei dir COM 1 aktiv?

Da du das Hyperterminal erwähnst:
Es darf NICHT auf die Schnittstelle zum IR-Empfänger zugreifen, da das ASURO-Windows-Programm diese Schnittstelle dann NICHT benutzen kann.
(Hyperterminal offline oder beenden, danach erst das ASURO-Windows-Programm starten.)

Zitat:

---

Zitat von inka

- unterschied der gemessenen werte:
bei go 12er - 20740 /18er - 14115
bei rurn 12er - 147 / 18er - 227
... ist die gefahrene strecke aber kürzer und der winkel nicht 90, sondern ca.70 grad.

---

Hallo inka,
mir kommen deine angegeben Werte ganz ok vor.
Mit dem guten alten Dreisatz bei deinen go-Werten komme ich mit der Rechnung: 12 / 14115 * 20740 auf 17,63 was also recht nahe an 18 liegt.
Bei den turn-Werten gerechnet: 12 / 147 * 227 = 18,53 anstatt 18, also auch 'halbwegs' dicht dran.
Bei meinem Asuro mit den 16er-Scheiben rechnet sich das dann so:
go 16er - 15150 --> 12 / 15150 * 20740 = 16,42 (akzeptabel)
turn 16er - 212 --> 12 / 147 * 212 = 17,3 (würde ich ein bisschen in Frage stellen)

Du sagst sowohl bei der Strecke, als auch beim Winkel, das der Asuro zu wenig fährt. Wie geht das? Der Asuro hört ja auf die Räder zu drehen, wenn er 'meint' genügend Tik's gesehen zu haben.
Da wir bei Go() eine Division durch den ermittelten Wert machen, um die zu fahrende Tik-Anzahl zu berechnen, ist es also schon mal richtig, dass der Wert bei der 18er-Scheibe kleiner werden muss. Schließlich wird dadurch die zu fahrende Tik-Anzahl mathematisch größer, was ja auch zu erwarten ist bei mehr SW-Wechseln auf der Scheibe.

Somit müssen 'irgendwie' mehr Tik's gesehen werden, als eigendlich zu erwarten sind. Hätte ich jetzt irgendwie anders erwartet.
Allerdings hatte ich dieses Problem auch schon mal nachgewiesen beim 'Nikolausfahren'. Ich bin dort darauf gekommen, dass man nur 94% der zu erwartenden Tik's vorgeben darf. Also auch da schon: Es kommen mehr Tik's als erwartet!
Wie groß sind denn die Werte für MY_ODO_???_Value_[L|R] bei dir?
Ist der Unterschied klein? Das würde auf eine große Fehlerrate, und damit auf mehr Tik's schliessen lassen.

Es wäre aber echt interressant, mal das von ehenkes vorgeschlagen Programm von Arexx-Henk aus dem Beitrag zu testen und ein Bildchen aus den Messdaten machen.

Oder war es doch die Platte im Netz? [-o<

@inka
Ich sehe gerade deine Frage zu den Winkelminuten.
Nein, das geht nicht, da der Winkelwert ja nur als int-Variable an die Funktion weitergegeben wird.
Hochgenaue Präzisionsfahrten erwarten wir nur bei Mars-Robotern, und nicht bei Asuros ohne Raketenantrieb, die 18er-Scheiben drauf haben :-)

Hallo

Zitat:

---

dass man nur 94% der zu erwartenden Tik's vorgeben darf.

---

Ich verwende zwar nicht die Lib V2.7, aber mir ist schon mehrmals aufgefallen, dass, wenn ich mir Line- oder Ododaten senden lasse, in regelmäßigen Abständen offensichliche Fehllesungen auftreten. Dies passiert sowohl beim direkten Übertragen einzelner Daten sowie auch beim blockweisen Übertragen gespeicherter Werte. Ich vermute, hier spukt irgendein Interrupt rein, ich habe das aber bisher nicht näher untersucht. Vielleicht gibt es da einen Zusammenhang.

Gruß

mic

@radbruch
In diesem Beitrag ist im Anhang eine EXCEL-Tabelle, mit der Tik's für Bogenfahrten bei beliebigen Winkeln (auch 0 Grad) und Radien berechnet werden. Oben rechts im Blatt (grün hinterlegt) ist diese Prozentangabe. (sind im übrigen 96%).
Erst mit diesen 'Verlusten' konnte ich meinen Asuro dazu überreden die gewünschte Strecke zu fahren.
Auch im Anhang (2 Beiträge vorher), ist das 'Nikolaus'-Programm von mir, wobei dort komplett nur über Interrupts gearbeit wird. Ich bin mir ziemlich sicher, dass in dem Programm keine Probleme mit den Interrupts auftreten, da ich ca. 10 Monate so alles durchgetestet hatte was nur irgendwie geht. (Soll nicht heißen, dass da tatsächlich kein Bug mehr vorhanden ist.)
Von einem Arbeitskollegen, der privat viel mit Lasern und verstellbaren Spiegeln macht, habe ich das gleiche Phänomän gehört, dass seine Positionsgeber (ODO-Scheiben) auch mehr Daten liefern als erwartet. Er hatte mich erst auf die Idee gebracht den Prozentwert im EXCEL-Blatt einzubauen.

Zitat:

---

Zitat von Sternthaler

Die von dir angegebene Fehlermeldung für das MSComm-Element heißt bei Microsoft Visual Basic (VB5 Copyright 1987-1997) wörtlich: "comBreak 1001 Es wurde ein Anhaltesignal (Break-Signal) empfangen.".
(Das Internet hilft mir da leider nicht weiter, was das denn nun eigendlich heissen soll.)
Die dahinterstehende 1 sagt nur, dass das Break-Signal auf der Schnittstelle COM 1 empfangen wurde.

Hast du die COM-Schnittstelle 1 ausgewählt?

---

Ja. Im moment des anwählen von COM1 erscheint die Meldung. Also direkt.

Zitat:

---

Zitat von Sternthaler

An welcher Schnittstelle ist dein IR-Empfänger?

---

An COM1.

Zitat:

---

Zitat von Sternthaler

Welche der 10 möglichen COM1 bis COM10 sind bei dir aktiviert?
Ich suche bis zu 10 Schnittstellen ab, ob sie aktivierbar sind und lasse dann die letzte gefundene Schnittstelle aktiv. Ist bei dir COM 1 aktiv?

---

Also COM1, 4, 7, 8 und 9 sind aktiv. Beim starten des ASURO-Windows-Programms ist COM9 selektiert. Im moment ich COM1 anwähle kommt auch die Meldung. Aber nur wenn auch der IR-Empfänger angeschlossen ist (logisch). Dabei kann ich auch ausschliessen das der ASURO dieses command sendet denn es passiert auch wenn der ASURO nicht sendet (ausgeschaltet)!

Zitat:

---

Zitat von Sternthaler

Da du das Hyperterminal erwähnst:
Es darf NICHT auf die Schnittstelle zum IR-Empfänger zugreifen, da das ASURO-Windows-Programm diese Schnittstelle dann NICHT benutzen kann.
(Hyperterminal offline oder beenden, danach erst das ASURO-Windows-Programm starten.)

---

Nee, nee, diesen test mit Hyperterminal habe ich gemacht ohne das das ASURO-Windows-Programm aktiv war. Also nur um den IR-Empfänger zu testen. Aber das Ding funktioniert gut weil ich ja ach die ASURO flashen kann ohne probleme.

Wie sieht es denn aus mit der Übertragungsgeschwindigkeit der COM1. Hyperterminal muss mann ja auf 2400 baud setzen. Das ASURO-Windows-Programm hat keine einstellungsmöglichkeiten.
Weil ich nie derartige Probleme mit COM1 habe denke ich doch das ASURO-Windows-Programm wertet etwas aus (comBreak) was nicht gesendet wurde.
Könnte es sein das das Programm auf eine spätere VB Runtime Module zugreift die etwas anders funktioniert?

@Sternthaler

Zitat:

---

Wie groß sind denn die Werte für MY_ODO_???_Value_[L|R] bei dir?
Ist der Unterschied klein? Das würde auf eine große Fehlerrate, und damit auf mehr Tik's schliessen lassen

---

die daten sind originalbelassen, absichtlich, weil der asuro (oder ich) anfangs irgendwie mit den werten nicht klarkam.

Zitat:

---

Oder war es doch die Platte im Netz?

---

definitiv ja. Nachdem ich dort die ortszeit gewählt habe und die zeit extern synchronisieren lasse ist alles wieder so wies sein soll, der asuro fährt sein quadrat...

Zitat:

---

Es wäre aber echt interressant, mal das von ehenkes vorgeschlagen Programm von Arexx-Henk aus dem Beitrag zu testen und ein Bildchen aus den Messdaten machen.

---

mache ich, wenn mich der bevorstehende umzug, alles was in einem 1,5 famileinhaus platz hat in eine - zwar sehr große - wohnung, von Tschechien nach Deutschland (Pirna) am 5/6. juli, dazu kommen lässt. Also werde ich mich vermutlich so in der 2ten dekade juli wieder melden...

Habe es jetzt auf meinem Desktop PC probiert und da funktionierte das Programm bis auf Test 5 der Motoausgleich/differenz. Bei diesem Test passiert nichts.
Muss sagen, ein tolles Programm.

Merkwürdig das es auf mein Laptop nicht funktioniert wegen den Combreak Empfang und damit stoppen des Auswerten der Daten.

Hallo Sternthaler,

Zitat:

---

Auch im Anhang (2 Beiträge vorher), ist das 'Nikolaus'-Programm von mir, wobei dort komplett nur über Interrupts gearbeit wird. Ich bin mir ziemlich sicher, dass in dem Programm keine Probleme mit den Interrupts auftreten, da ich ca. 10 Monate so alles durchgetestet hatte was nur irgendwie geht. (Soll nicht heißen, dass da tatsächlich kein Bug mehr vorhanden ist.)

---

bei meinen Versuchen mit dem Bluetooth-ASURO bei dem die Encoderwerte über die Funkschnittstelle übertragen werden, konnte ich ein interessantes Phänomen beobachten: Wenn die Motoren ausgeschaltet waren und der ASURO stillstand, gab es trotzdem manchmal den Fall, dass ein Encoder hochgezählt hat. Dies kam nur selten, bei bestimmten Stellungen der Codescheiben vor.
Dieser Fehler würde Deine 94% Vorgabe erklären. Bei dem Zählvorgang werden wohl manchmal einige Ticks zuviel gezählt. Vielleicht gibt es doch in der Interruptauswerteroutine ein Problem.

Ein einfacher Test wäre vielleicht, bei jedem Encodertick einen Impuls auf einen Ausgangspin des Atmega8 zu geben und mit einem Speicheroszilloskop zu versuchen, den Ausreißer zu lokalisieren. Falls er regelmäßig kommt, könnte das ja auf einen Konflikt mit anderen Routinen hindeuten.

Immerhin läuft ja der 36Khz Interrupt und der 4Khz? Encoderinterrupt gleichzeitig.

Gruß,
robo

Ich habe hier nog mal meine Werte:

Test 1:
MY_SWITCH_VALUE = 63

Test 2:
MY_ODO_LIGHT_VALUE_L = 142
MY_ODO_DARK_VALUE_L = 160
MY_ODO_LIGHT_VALUE_R = 174
MY_ODO_DARK_VALUE_R = 185

Test 3:
MY_GO_ENC_COUNT_VALUE = 18740

Test 4:
MY_TURN_ENC_COUNT_VALUE = 147

Was auffällt ist das die ermittelten ODO werte sich nicht mit die Kriterien (Light hat grösseren Wert als Dark) verhalten. Ich habe mehrmals versucht und es kommen immer diese Werte heraus.

Wie gesagt Test 5 funktionniert nicht.

Wie sehen die Werte bei euch aus?

die werte bei mir sind so:
MY_ODO_LIGHT_VALUE_L = 128
MY_ODO_DARK_VALUE_L = 154
MY_ODO_LIGHT_VALUE_R = 95
MY_ODO_DARK_VALUE_R = 127

so viel ich mich erinner kann, ist der test der motoren (test5) noch nicht eingebaut...

@inka

Also bei dir sind die werte für LIGHT auch niederiger als für DARK.
In den Comments in MyAsuro.H steht es soll genau umgekehrt sein.
Merkwürdig.

http://www.henkessoft.de/Roboter/Bil...nks_Rechts.jpg

@ehenkes

Tolle Grafik. Aber wie verstehe ich das?
Ich verstehe das licht-dunkel-Verhalten des Odometers und der Underschied links und rechts.
Aber die Werte von Inka und mir sind Streitig mit der Angabe das Light einen höheren Wert haben soll als Dark.
Die Grafik zeigt das Dark und Light verschiedene Werte haben aber nicht ob die höhere Werte zu der Dark-parametern gehören oder zu den Light-parametern.

Das mit den verschiedenen Schnittstellen (Laptop, Desktop, USB, RS232, ...) scheint sich hier ja durchzuziehen.
Ich werde also erst einmal KEINE weitere Fehlersuche dahingehend machen. Sorry.

Zitat:

---

Zitat von robo.fr

Dieser Fehler würde Deine 94% Vorgabe erklären. Bei dem Zählvorgang werden wohl manchmal einige Ticks zuviel gezählt.

---

96% anstatt 94% hatte ich ermittelt. Ist aber egal, da das Prinzip scheinbar unerwartete Tik's erzeugt.
Mit deiner Beobachtung bestätigt sich diese Aussage ja auch.

Zitat:

---

Zitat von robo.fr

Ein einfacher Test wäre vielleicht, ... und mit einem Speicheroszilloskop ... Falls er regelmäßig kommt, könnte das ja auf einen Konflikt mit anderen Routinen hindeuten. ... Immerhin läuft ja der 36Khz Interrupt und der 4Khz? Encoderinterrupt gleichzeitig.

---

Den Vorschlag für den Test mit Speicher-Oska halte ich für brauchbar. Leider habe ich so ein Ding nicht. Kann hier jemand helfen? (ehenkes vielleicht?)
Allerdings bin ich immer noch (nach nochmaligem 'Codeanstarren') relativ sicher, das da nichts her kommt. Zum einen deshalb, da die Interrupts nicht verschachtelt aufgerufen werden, und zum anderen weil der Timer nichts mit der Ermittlung der Tik's zu tun hat. Ich sehe einfach keinen Zusammenhang. (Wahrscheinlich betriebsblind)

Zitat:

---

Zitat von Petje + inka

MY_ODO_LIGHT_VALUE_L = 142
MY_ODO_DARK_VALUE_L = 160
MY_ODO_LIGHT_VALUE_R = 174
MY_ODO_DARK_VALUE_R = 185
Was auffällt ist das die ermittelten ODO werte sich nicht mit die Kriterien (Light hat grösseren Wert als Dark) verhalten. Ich habe mehrmals versucht und es kommen immer diese Werte heraus.

---

Das ist in der Tat sehr merkwürdig. Die Beschreibung in myasuro.h ist korrekt.
Es gibt allerdings eine Situation in den Daten, die ich im Asuro-Testprogramm sammel, bei denen ich LIGHT und DARK bewust 'umdrehe'.
Wenn zu viel seitliches Licht vorhanden ist, dann erkennt das Programm dies. Dann sind die erfassten Duchschnittswerte bei der Drehung vom Asuro so, dass der mittlere Duchschnitt der hellen Werte kleiner ist als der mittlere Durchschnitt der dunklen Werte.
Ich werde dies nochmal prüfen, ob da ein Fehler in meinem Programm ist.

Zitat:

---

Zitat von Petje

Wie gesagt Test 5 funktionniert nicht.

---

inka hat Recht. Der Test 5 ist noch nicht vorhanden. Allerdings auch noch nicht wichtig, da dieser Wert in der LIB aktuell nicht benutzt wird.

Zitat:

---

Zitat von Sternthaler

Das ist in der Tat sehr merkwürdig.

---

Nicht merkwürdig, sondern tatsächlich falsch.
Ich habe die Texte MY_ODO_DARK_VAULE_[L|R] und MY_ODO_LIGHT_VAULE_[L|R] im Windows-Programm allerdings 'nur' vertauscht.

Ich stelle im ersten Beitrag eine korrigierte Version des ASURO-Programms zur Verfügung als Version V205.
Asuro-Programm deshalb, weil es kleiner ist. Dort werden die Werte dann nur vertauscht gesendet.

Toll, dass ihr dies gefunden habt. Ich hatte einfach immer nur die kleineren Werte hinter DARK eingetragen. (Ist ja schliesslich so richtig ](*,) )

P.S.: Da fällt mir so ein, dass ich noch nichts von einem auftauchenden Button neben den ODO-Values erzählt habe, wenn ein Problem oder eine Warnung festgestellt wurde.
Haltet mal eine helle Lampe seitlich neben den drehenden Asuro wenn der Test 2 gemacht wird.

Heisst dies das ich nur die gemessene Werte Light und Dark wechseln soll.
Oder muss ich die messung neu durchFühren?

Hallo Petje,
es ist nicht notwendig neu zu messen.
Wenn du in deiner myasuro.h die höheren Werte bei den _LIGHT_-Defines eingesetzt hast, ist alles OK.
Wenn du dir aber das ASURO-Programm Version V205 von der ersten Seite aus diesem Thread holst, dann werden die Werte nun richtig im Windows-Programm ausgegeben, und die Verwirrung ist wenigstens weg.

hi allerseits,
folgende frage:
ist die taster-erkennung wirklich so empfindlich dass bei 2 asuros, der eine mit R25=2,01k und der andere mit R25= 1,97 schon nicht mehr mit dem gleichen parameter in der myasuro.h erkannt werden, sondern mit 63 und 64 arbeiten = die K1 taste erkennen?
Es ist sicher kein problem bei dem einem ein widerstand mit 4 ohm dazuzuhängen, aber es ist eben die frage, ob ich damit das problem löse?