## c't-Projekte - Mailinglisten

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

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

Absender: Frank Menzel
Datum: Fr, 30.06.2006 21:43:32
In-reply-to: <812F86EC9E1A96489D5E83C2AB7D68863BD788@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>

    Ich noch mal,
    habe den akt. CVS-Code geholt, die Verhaltensanzeige und Sim-Log
    aktiviert und bot_scan auf die Taste 5 gelegt. Folgende erste
    Beobachtungen dazu im SIM:

    -erste Beobachtung ist wieder das Zuschütten des Log-Fensters mit der
    Meldung "sens not init" (hatte ich bei den Punkten unten noch
    vergessen), hab's auskommentiert
    -bot_Scan mit unterlagertem bot_turn gibt keine Scanwerte aus weil die
    Formatierung nicht korrekt ist->dazu hatte ich aber schon Patch
    geschickt (mit Grad-Anzeige anstatt der Stepanzeige)
    -und im SIM sind die eigentlichen 360 Grad nur eine 3/4 Drehung, siehe
    8.
    -dann lässt der Mausdruck auf die rote LED den bot losrennen

    Soweit für heute,
    Gruss, Frank Menzel

    Hallo,
    Ich werde noch mal konkret die Punkte nach den Antworten angehen und mir
    dazu noch mal die akt. CVS-Version holen, besten Dank erst mal.
    Von hier aus kann ich aber schon zu folgenden Punkten was sagen:
    1.) Es ist zwar ein int16 angegeben, es erfolgte aber keine Anzeige oder
    ein Müllwert damit. Ich wäre ja zufrieden mit fehlender Genauigkeit aber
    keiner oder Müllanzeige bin ich  nicht glücklich :-) Konkret stimmt die
    Anzeige mit der Formatierung %3.0f . Die ganze Rechnerei schluckt viel
    Rechenzeit, da kann doch bestimmt auch richtig formatiert angezeigt
    werden...

    2.) Sorry aber in der changelog kann ich nix dazu finden :-( Von welchem
    Datum denn, bei mir stammt der letzte Eintrag vom 13.6. ?

    3.) Um Designpreis geht's mir auch nicht. Aber was da ist, sollte auch
    nach dem jetzigen Standard nutzbar sein, also in der ct-bot.h existent
    sein. Will es jemand benutzen, werden die Kommentare weggenommen und
    schon wird's (irgendwo) sichtbar. Da sollten nicht noch viele andere
    Klimmzüge gemacht werden müssen. Aber gerade bei diesen Regelwerten ist
    mir relativ unklar (auch nach den vielen Experimenten), wie diese für
    meinen Bot aussehen müssen. Im Endeffekt habe ich diese regelung wieder
    deaktiviert.

    6.) auch im Sim ist es mir nicht erklärlich

    7.) Resets waren sofort da nach Defineaktivierung der Verkoppelung der
    Sensorwerte-teste ich aber alles noch mal.

    8) Beim Stoppen der Motoren kleiner 5 Grad sagt aber auch niemand, daß
    der Bot genau bis 0 Grad weiterdreht. Da macht es das turn-Verhalten
    ohne Maus besser, da wird ganz genau weitergedreht.

    9.) Den korrekten Drehwert habe ich auch mit Spindel ermittelt und
    dieser funktioniert tadellos. Habe langsam gedreht, geht ja auch nicht
    schnell, und drehen tut der bot ja auch relativ langsam. Aber der andere
    zu ermittelnde Wert soll ja nach 1m Schieben ermittelt werden-und genau
    hier ist das Problem. Sowohl Maus als auch Encoder liefern mir immer
    laut Anzeige kleinere Werte je größer die Geschwindigkeit nach 1m
    Endstand.

    Erfahrungen weiterer bot-Besitzer zu diesen Punkten wären sehr
    hilfreich...

    Gruß,
    Frank Menzel

    -----Original Message-----
    From: ct-bot-entwickler-bounces@xxxxxxxxxxxxxxxxx
    [mailto:ct-bot-entwickler-bounces@xxxxxxxxxxxxxxxxx] On Behalf Of Timo
    Sandmann
    Sent: Thursday, June 29, 2006 11:52 PM
    To: Mailingliste c't-Bot
    Subject: Re: [ct-bot] Code-Ungereimtheiten/ Probleme...

    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:
  - AW: [ct-bot] Code-Ungereimtheiten/ Probleme...
    - From: Frank Menzel
  - Re: AW: [ct-bot] Code-Ungereimtheiten/ Probleme...
    - From: Benjamin Benz

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

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