## c't-Projekte - Mailinglisten

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

### Re: [ct-bot] Code-Ungereimtheiten/ Probleme...

Absender: Timo Sandmann
Datum: Do, 29.06.2006 23:52:00
In-reply-to: <812F86EC9E1A96489D5E83C2AB7D68863BD16B@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>

    Am 29.06.2006 11:17 Uhr 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.

    Hm, mal schauen, was wir da machen können ;)

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

    Ja, das ist immer sinnvoll :)

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

    Weil die printf-Funktion für floats übermäßig viel Speicher braucht, werden
    die Werte als Ganzzahl dargestellt (siehe auch Anmerkung und Erklärung von
    Torsten Evers), da die Ausgabe aber nur zum Ausgeben und nicht zum Rechnen
    dient, sollte die fehlende Genauigkeit eigentlich zu verschmerzen sein. Dass
    die angezeigten Werte nicht stimmen, kann ich nicht bestätigen, wenn man von
    den Nachkommastellen aus o.a. Grund absieht.

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

    Verändert ja, siehe changelog.txt.
    Zum Kd-Wert: Der komplette Differentialanteil des PID-Reglers wird derzeit
    nicht berechnet, es ist also zurzeit ein PI-Regler, weil die aus den
    Radencodern gewonnene Geschwindigkeit auf Grund der gegebenen Totzeiten
    keine stetige und folglich auch nicht db Funktion ist. Daher macht es wenig
    Sinn, daraus die Geschwindigkeitsänderung pro Zeiteinheit zu berechnen.

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

    Das genannte Define dient dazu, die Regelung zu überprüfen. Trägt man es wie
    üblich in ct-Bot.h ein und weist ihm einen Screen zu, z.B. Screen 0, dann
    erhält man diese Ausgaben. Das ist so nicht das non-plus-ultra, aber es wird
    auch dran gearbeitet, wobei es zurzeit in erster Linie um eine exakt
    geregelte Drehzahl und nicht um einen Designpreis für die Debugausgabe geht
    ;-)

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

    IMHO bereits sehr ausführlich beantwortet, danke dafür. :)

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

    Das hatte ich noch nie, kann ich jetzt aber leider auch nicht testen, da der
    Sim ja nur unter nativem Windows oder Linux läuft.

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

    Volldrehungen? Das einzig mir bekannte Problem ist, dass nach einem
    Not-Stopp / Abbruch das Verhalten nicht neu initialisiert wird. Überdrehen
    deutet nach den in letzter Zeit gewonnenen Informationen eher auf eine zu
    große Geschwindigkeit gegen Ende hin.

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

    Verstehe ich jetzt leider nicht so ganz, soweit ich mich erinnern kann,
    hatte ich damit nie Resets. Nach welcher Zeit treten die denn wie
    beschrieben auf?

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

    Naja, bei <= 5 Grad werden die Motoren gestoppt, deshalb ist allerdings
    nicht zeitgleich auch der Bot gestoppt.
    Bei den Encoder-Berechnungen ist aber auf jeden Fall zu beachten, dass ein
    Rad nur 60 Ticks liefern kann pro Umlauf, folglich lässt sich die maximale
    Genauigkeit (angenommen die Radencoder funktionierten ideal) leicht
    ausrechnen.

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

    Nachdem ich die Kalibrierung wirklich genau gemacht habe (bei Drehungen ist
    eine CD-Spindel - z.B. mit in den Boden geklebter Pappe - eine super Hilfe),
    stimmen Rotation und Translation aus den Mauswerten nahezu perfekt und sind
    bei mir geschwindigkeitsunabhängig.

    Ich hoffe die ein oder andere meiner Informationen hat etwas weitergeholfen.

    Viele Grüße,
    Timo Sandmann

- Antworten:
  - RE: [ct-bot] Code-Ungereimtheiten/ Probleme...
    - From: Menzel, Frank IT-OO4

- Referenzen:
  - [ct-bot] Code-Ungereimtheiten/ Probleme...
    - From: Menzel, Frank IT-OO4

- Voriger (Datum): Re: [ct-bot] Code-Ungereimtheiten/ Probleme..., Torsten Evers
- Nächster (Datum): RE: [ct-bot] Code-Ungereimtheiten/ Probleme..., Menzel, Frank IT-OO4
- Voriger (Thread): Re: [ct-bot] Code-Ungereimtheiten/ Probleme..., Torsten Evers
- Nächster (Thread): RE: [ct-bot] Code-Ungereimtheiten/ Probleme..., Menzel, Frank IT-OO4
- Indizes:
  - Datum
  - Thread