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