heise online · c't · iX · Technology Review · Telepolis · mobil · Security · Netze · heise open · heise resale · Autos · c't-TV · Jobs · Kiosk
Zum Inhalt
c't

c't Projekte - c't-Bot und c't-Sim - Mailinglisten

c't-Bot und c't-Sim


[Voriger (Datum)] [Nächster (Datum)] [Voriger (Thread)] [Nächster (Thread)]
[Nach Datum][Nach Thread]

[ct-bot] Code-Ungereimtheiten/ Probleme...

Absender: Menzel, Frank IT-OO4
Datum: Do, 29.06.2006 11:17:20
In-reply-to: <812F86EC9E1A96489D5E83C2AB7D688638ABAF@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>


 
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.

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.

2.) Die Motorregelung hat sich komplett verändert, der Kd-Wert ist auch völlig unter den Tisch gefallen.

3.) In der motor.c gibt es das Define DISPLAY_REGELUNG_AVAILABLE zur Anzeige der Motorstellwerte, wenn der Definewert mit dem display_screen übereinstimmt. Doch dieses Define ist nirgendwoanders zu finden noch ein Verweis darauf, welcher Screen dafür herhalten soll.

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.

5.) Im SIM fängt der bot beim Mausklick auf die rote LED plötzlich an wie wild zu laufen, ein mir absolut unerklärliches Verhalten, da hiermit nur Screen 1 sichtbar werden sollte. 

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

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

8.) Verhalten bot_scan: Hier soll ja eigentlich eine Volldrehung erfolgen in 36 Schritten a 10 Grad durch Aufruf des bot_turn Verhaltens. Nur nach den 36 10 Gradschritten sind es jedoch noch keine 360 Grad, da ist es erst ca. eine 3/4 Drehung. Als Ursache dafür habe ich bei Mausverwendung ausgemacht, daß ja bereits Schluß ist mit Drehung bei <= 5 Grad. Bei Verwendung ohne Maus, also nur der Encoderwerte, ist wohl die Integer-Arithmetik Schuld, welche einen ganzzahligen Winkel berechnet und den gerade bei diesen Werten hohen Kommawert bei 36 10-Grad-Drehungen ignoriert...

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.

Soweit von meiner Seite,
Gruß, Frank Menzel




Copyright © 2007 Heise Zeitschriften Verlag Kritik, Anregungen bitte an c't-WWW Datenschutzhinweis   Impressum