Absender: Torsten Evers
Datum: Do, 29.06.2006 22:50:59
In-reply-to:
<812F86EC9E1A96489D5E83C2AB7D68863BD16B@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
References:
<812F86EC9E1A96489D5E83C2AB7D68863BD16B@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Hallo, Am Donnerstag 29 Juni 2006 11:17 schrieb Menzel, Frank IT-OO4: > Hallo, > mir ist die letzten Tage aufgefallen bei der intensiven bot-Beschäftigung, > daß sich einiges im aktuellen CVS-Code geändert hatte bzw. mir nicht > unbedingt erklärlich ist. Hier will ich einfach mal nachfragen, vielleicht > habe ich auch irgendwo was überlesen. Weiterhin führe ich mal die Probleme > auf, auf die ich gestoßen bin. soweit ich dazu was sagen kann, tue ich das im Folgenden: > 1.) Die Variablentypen der Encoderwerte für Positionen X/Y und der > Geschwindigkeit (wohlgemerkt der Encoder, nicht von Maus) haben sich von > Int16 nach float geändert, daher stimmen auch die Displayanzeigen noch > nicht. Das ist so nicht korrekt, da hier jeweils ein Cast nach (int16) Verwendung findet: display_printf("v_l: %3d v_r: %3d ",(int16)v_enc_left,(int16)v_enc_right); Bei mir kann ich da auch keine Unstimmigkeit feststellen!? Würde mich interessieren, ob das Problem noch jemand beobachtet hat, damit ich dem mal nachgehen kann. > 4.) In der bot-local.h gibt es das Define STUCK_DIFF zur Erkennung, ab wann > wir denn durchdrehende Räder haben. Auch beschrieben in > http://www.heise.de/ct/06/13/226/, sogar mit Codeausschnitt. Jedoch im > ganzen Quellcode des bots taucht dieses Define nirgends auf. Das liegt einfach daran, dass kein Verhalten diese Möglichkeit zur Zeit nutzt. Man müsste dies in einem Verhalten wie z.b. bot_drive_distance() einbauen, indem vor dem Switch, das die Zustände steuert, folgendes einbringt: if (abs(v_enc_left - v_mou_left)>STUCK_DIFF) { ... } Es ist also eher als Angebot für weitere Verhalten oder zum Einbringen beim Überarbeiten von alten Verhalten. > 6.) Verhalten gotoxy: Hier wir scheinbar nur beim 1. Aufruf die Position > richtig angefahren, möglicherweise also nur dann, wenn x und y vorher 0 > waren. Bei Aufruf des Verhaltens mittendrin geschehen mit unerklärliche > Bewegungen (Volldrehungen...) Mit aktivierter oder deaktivierter Motorregelung? > 7.) Beim Setzen des Defines MEASURE_COUPLED_AVAILABLE, also beim Verknüpfen > der Maus- und Encoderwerte kam es beim realen Bot zu Resets und auch nur > dann. Hier sind wohl Bereiche übergelaufen... Übergelaufene Bereiche würden nicht zu Resets führen. Das wäre nur der Fall bei Zugriffen auf nicht definierte Adressen. Ich kann es leider auf meinen beiden Bots auch nicht nachvollziehen. Kann da noch jemand was zu sagen? > 9.) Positionsberechnung via Radencoder oder Maus: Diese Werte sind stark > von der Geschwindigkeit abhängig, d.h. wenn ich den bot sehr langsam > schiebe, erhalte ich hohe Werte, welche auch stimmen. Sobald ich aber > schneller schiebe (oder sich der bot bewegt) bei gleicher Strecke, werden > es immer kleinere Werte. Entweder werden diese verschluckt oder die > Codezeilen zur Berechnung der Werte nicht oft genug aufgerufen-da tappe ich > noch im Dunkeln. Wenn der Bot mit einer Geschwindigkeit geschoben wird, die auch nur leicht über der maximal vom Bot selbst zu schaffenden liegt, kann der Maussensor die Delta-X und Delta-Y Werte nicht mehr in seinen 8-Bit-Registern verarbeiten. Der Sensor selbst verpasst so dann Mouse-Counts. Darunter kann ich bei mir keine Probleme entdecken. Ich wäre froh, wenn da noch andere Listenteilnehmer ihre Erfahrungen schildern könnten. Schöne Grüße, Torsten Evers