|
 |
 |
 |
|
|
c't Projekte - c't-Bot und c't-Sim -
Mailinglisten
[Voriger (Datum)]
[Nächster (Datum)]
[Voriger (Thread)]
[Nächster (Thread)]
[Nach Datum][Nach Thread]
Absender: Achim Pankalla
Datum: Mi, 07.03.2007 23:10:43
In-reply-to:
<45ED3B46.4030400@xxxxxx>
References:
<BCF016D5ED5AC34FBB655D109519ABCF083EBE@xxxxxxxxxxxxxxxxxxxx> <45ED3B46.4030400@xxxxxx>
hallo ct-bot'ler,
vielleicht da einiges nicht ganz sauber rübergekommen und ich möchte
hier nochmal licht in die sache bringen. ich war eine zeitlang nicht
online als ich folgendes schrieb deshalb ist einiges auch schon erwähnt
von anderen, trotzdem denke schaffe ich hiermit noch einige klarheiten
(hoffentlich). stelle es zur diskussion vielleicht sehe ich ja auch
einiges falsch...
1) das kalibrieren läuft nicht im framework / blockiert es.
richtig ist. wenn das kalibrieren mit den define CALIBRATE_SENSORS
aktiviert ist wird die kalibrierfunktion vor der endlosschleife
aufgerufen. das framework ist dann inaktiv und wird erst nach dem
verlassen des kalibriermenue aktiv. ist auch SENSOR_TABLE_AVAILABLE
gesetzt kann man mit den aktivierten behaviours gleich die kalibrierung
testen.
warum nicht so wie hr. benz das vorgeschlagen hat und die neue gui benutzen?
weil kalibrieren folgendes heisst. das menue gibt abstände vor, die der
bot zu einer wand einnehmen muss, dann drückt man die taste 2 und die
routine bildet aus 50 (konfigurierbar) messungen einen mittelwert. ist
man zufrieden, wird die taste 3 gedrückt und der bot auf die nächste
position gesetzt. dh. der bot muss stillstehen, darf sich nicht
irgendwie bewegen, die messung sollte durch keine andere aktion
verfälschen werden. warum stört es dann, das man nicht in andere menues
wechseln kann??? Im algemeinen braucht nur einmal und dann man nie
wieder kalibrieren, ausser man verändert die hw des bot (oder löscht
sich aus versehen seine daten oder vergisst sie abzuziehen ;-)).
wie gesagt, war es eine nettes gimmick in verbindung mit meinen sim
patch, das auch das kalibrieren im sim ging. sollte jemand einen
schwanken der sensor(en) auch wieder in den sim einbauen, so wird sich
sicher auch eine lösung dafür finden, wie man die timeout meldungen im
sim weg bekommt (durch ändern der routinen im bot!). aktuell ist ein
kalibrieren mit PC-define nicht möglich und wegen "ruhiger" sensoren
auch unnötig. ausserdem will man ja auch den realen bot auf den
simulator abbilden und nicht kalibrierwerte vom simulator auf den realen
bor aufbringen...
uebrings auch herr bents, sagte mir am anfang meiner arbeit an hr. jonas
patch, das es wünschenswert wäre, wenn auch die sensoren im sim, wie im
realen, schwanken. leider ist der anfang von mir im wettbewerbssim
verloren gegangen. :-(
wenn das kalibrieren im sim nicht geht ist deswegen doch nicht das ganze
verfahren unnötig!!! man möchte doch das der sim-bot genauso fährt wie
der reale, nutzt man das kalibrieren auf seinen realen bot, um ruhige
abstandswerte zu bekommen, so ist es doch sinnvoll dieses verhalten auch
im simulator zu haben oder???? wer hat den bitte ein bot der genau 120mm
meldet konstant und ohne wackler. durch die kalibrierung ist so etwas
möglich!
auch sollte man das nicht auf die abstands sensoren begrenzt sehen, auch
andere sensoren kann man kalibrieren oder die motoren abgleichen für den
geradeauslauf. so etwas sollte dann auch im sim zur verfügung stehen,
über ein simulierte eeprom?! :-)
2) eeprom nutzung kompliziert / neu
das problem liegt in der simulation des eeprom. ich bilde im moment die
eeprom-fkt des winavr auf den gcc durch eigene fkt ab. da es ja in
diesem keine gibt. da es dort im compiler keine zuweisungen von speicher
gibt musste ich einen weg finden, wie ich sicherstellen kann, das die
"variablen" die benutzt werden bei beiden compilern an der gleichen
stelle liege. deshalb bin ich auf die lösung mit der eeprom_map.h
verfallen. dadurch das der nutzer hier seine bereiche die er nutzen will
eintragen muss, sind diese auf beiden compiler identisch. mehr noch,
sollte mal ein verhalten, welches das eeprom nutzt, deaktiviert werden,
könnte es sein das die variablen nicht generiert werden und dadurch eine
verschiebung der adressen im eeprom entsteht. wird die fkt. wieder
eingebunden sind ihre werte überschrieben. also müssten die variablen
immer definiert werden und nicht mal ja und mal nein, der pc compiler
muss solche definitionen kennen und adressen vergeben!
ich bin übrings füer jeden vorschlag offen...
komplizierter finde ich die eeprom_map übrings nicht. eine eeprom
variable mit uint16 _atribute_("eeprom") err15; zu programmieren musste
ich auch erst nachschlagen....
es ist moment noch jede menge frei im eeprom, also finde ich ;-) meine
lösung nicht so schlecht oder...
abschliessend möchte ich darum bitte, den kode ein change zu geben, legt
doch mal einen neuen workspace in eclipse an und probiert den patch aus.....
viel spass weiter mit den bot....
achim pankalla
|
|
|