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]

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

Absender: Benjamin Benz
Datum: Mi, 07.03.2007 11:51:44
In-reply-to: <45EE935C.5090706@xxxxxx>
References: <BCF016D5ED5AC34FBB655D109519ABCF083EBE@xxxxxxxxxxxxxxxxxxxx> <45ED3B46.4030400@xxxxxx> <45EE8554.4020601@xxxxxxxx> <45EE935C.5090706@xxxxxx>


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. Wenn man im Sim nicht Kalibrieren
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.

MfG Benjamin Benz
-- 
Benjamin Benz
Heise Zeitschriften Verlag
Redaktion c't
eMail: bbe@xxxxxxxx
WWW  : http://www.heise.de

Heise Zeitschriften Verlag GmbH & Co. KG
Registergericht: Amtsgericht Hannover HRA 26709

Persönlich haftende Gesellschafterin:
Heise Zeitschriften Verlag Geschäftsführung GmbH
Registergericht: Amtsgericht Hannover, HRB 60405
Geschäftsführer: Ansgar Heise, Steven P. Steinkraus, Dr. Alfons Schräder




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