c't

c't-Projekte - Mailinglisten


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

Re: [ct-bot] Re: Kalibrierung der Distanzsensren mittels EEPROM-Tabelle

Absender: Achim Pankalla
Datum: Mi, 07.03.2007 11:58:21
In-reply-to: <45EE993F.6010402@xxxxxxxx>
References: <BCF016D5ED5AC34FBB655D109519ABCF083EBE@xxxxxxxxxxxxxxxxxxxx> <45ED3B46.4030400@xxxxxx> <45EE8554.4020601@xxxxxxxx> <45EE935C.5090706@xxxxxx> <45EE993F.6010402@xxxxxxxx>


hallo,
nur ganz kurz...
Benjamin Benz schrieb:
Hallo,


Kann man den einstellen, wie weit man bereit ist die Auflösung
einzuschränken?
das kann man natuerlich, steht in der docu. dafuer nutzt man die include
datei sensor_correction.h dort gibt es defines dafür. standart ist 4cm
erfassung, dh dann eine aufloesung von 2cm. ich habs bei mein bot auch
schon mit 2cm erfassung und damit 1cm auflösung probiert und das ging
auch super.

Ah, das klingt doch gut. Haben sie einmal probiert eine Map anzulegen
mit den kalibrierten Sensoren? Mich würde interessieren, wie gut die
dann aussieht.


- eeprom benutzung muss über eeprom_map.h erfolgen
Ich verstehe (noch) nicht so ganz, worin hier der Vorteil gegenüber der
Vergabe der EEPROM-Adressen durch den gcc liegt. Letztere hätte deutlich
weniger Einfluss auf andere Code-Bereiche und ist IMHO weniger
Fehlerträchtig.
der vorteil ist ganz einfach, das auch der ct-bot.exe für den sim ein
eeprom hat. dieses wird über eine datei simuliert (siehe docu). uebrings
die idee dafuer kam von* ihnen* als ich meine erste version einschickte
;-)
Das ist in der Tat ein handfester Vorteil.

... der weitere vorteil ist, das man das eeprom vom bot abziehen
kann (mit ponyprog als bin).
klingt ebenfalls gut.

ich habe die ganze sache in dieser version
auf die spitze getrieben und meine ursprünglichen fkt einfach benutzt,
um unter gcc die eprom-fkt des winavr zu simulieren. der kode ist also
für pc und mcu gleich. den "nachteil" haben nur neue routinen, da meine
pc routinen natürlich keine automatische speicherzuteilung haben, dafür
müsste man den compiler ergänzen oder so...
Was meinen denn die anderen auf dieser Liste dazu?
Die Optionen sehen IMHO so aus:
1. manuelle Speicherzuteilung ==> code läuft auf PC und MCU identisch
2. automatische Speicherzuteilung per avr-gcc ==> Code läuft nicht
sinnvoll auf PC
3. evtl. kann man mit ein paar geschickten Makros die Speicherzuteilung
auf dem PC nachstellen?

Nach den von Ihnen genannten Pros würde ich (wenn jemand weiß wie) für
Version 3 oder sonst 1 plädieren.

leider geht der eigentliche kalibriervorgang nicht mehr im neuen ct-sim
(ct-bot zu langsam meldung, wahrscheinlich muss da ein lebenszeichen vom
bot kommen, doch das kalibrieren erfolgt ja vor der endlosschleife).
Es ist NICHT sinnvoll den Bot vor der Hauptschleife in irgendwelche
eigenen lange laufenden Funktionen zu schicken. Das stört empfindlich
die Kommunikation mit dem Sim. Ich denke eine Kalibrierfunktion sollte
eher in ein Verhalten eingelagert werden, denn in eine Funktion, die das
restliche Framework sprengt. Das hätte außerdem dem folgende Vorteile:

1. Rekalibrierung durch FB-Tastendruck jederzeit möglich
2. Benutzung des Displays nach neuem UI-Konzept
3. Simuieren des Bots geht
4. Kalibrierung identisch im Sim und beim realen Bot
tut mir leid, das finde ich nicht sinvoll, der vorgang des kalibrieren,
also das erzeugen der eeprom-tabelle, ist eine einmalige sache. wenn man
beim bot das menue beendet ist der normale betrieb möglich und man kann
seine werte gleich testen. es war ein nettes gimmick, das man dieses
kalibrieren auch ct-sim machen konnte. damals hatte ich ja auch ein
patch geschaffen, um die werte im sim schwanken zu lassen, der geht ja
auch nicht mehr...
nichts desto trotz, ist der einsatz vom simulierten eeprom sinnvoll, um
sim und realen bot auf einen level zu halten, was sie mir damals auch
nahegelegt haben. ursprünglich sollte das kalibrieren nur auf dem bot
laufen...

Nun, um es ganz deutlich zu sagen: Wir halten es nicht für sinnvoll,
Code in das CVS aufzunehmen, der den Sim dazu bringt hängen zu bleiben,
weil er am Framework vorbei arbeitet.
der bot bleibt nicht hängen. das cal-menue startet vor den eigentlichen ablauf. das calibrieren geht im moment nur im realen bot. ist das cali. beendet, so läuft der reale bot normal weiter...
Wenn man im Sim nicht Kalibrierenst kann, dann bringt auch die obige Argumentation, man könne dann ja auch
die EEPROM-Routinen dort nutzen nichts, denn wie soll man sie dann (ohne
Workarounds wie feste Werte im Code oder manuelles Unterschieben von
Config-Files) erstellen.
versteh ich nicht, sorry. was wollen sie damit sagen???
MfG Benjamin Benz