Absender: Timo Sandmann
Datum: Do, 08.03.2007 02:19:29
In-reply-to:
<45EF385C.3080609@xxxxxx>
References:
<BCF016D5ED5AC34FBB655D109519ABCF083EBE@xxxxxxxxxxxxxxxxxxxx> <45ED3B46.4030400@xxxxxx> <45EF385C.3080609@xxxxxx>
Hallo, Am 07.03.2007 um 23:10 schrieb Achim Pankalla:
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.
das stimmt so nicht ganz, mindestens der Timer läuft bereits, es wird also alle 176 µs in die Timer-ISR gesprungen, ebenso ist das UART schon aktiv usw.
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 ;-)).
Richtig, was einmalig ist, gehört logisch sicher nicht in ct-Bot.c, sondern in eine extra Datei. Dort ist die Routine ja auch untergebracht und lässt sich wunderbar als Verhalten einbinden. Wird es aktiv, kann es problemlos dafür sorgen, dass andere Verhalten während dieser Zeit nicht stören können. Man kann von dem Verhaltenssystem denken was man möchte, solange sich alle anderen Verhalten daran orientieren, sollte es auch dieses tun. Außerdem ist so ein Aufruf wie "rc5_control(); // Abfrage der IR- Fernbedienung" sehr unschön. Eventuell ändert sich irgendwann mal die Abfragelogik der Fernbedienung und dann muss man hier nachbessern. Nutzt man die Funktionen, die allgemein im Framework benutzt werden, so kann man davon ausgehen, dass ihre Schnittstellen gleich bleiben (und wenn nicht, dann wird der Code mit angepasst).
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. :-(
Sim hin oder her, wieso schwanken die Sensorwerte beim realen Bot (bei konstanter Entfernung)? Und wenn sie das tun, warum sollte man dann eine Lookup-Table benutzen? Meinem Verständnis nach ist die Lookup-Table dazu da, eine Abbildung von Spannung nach Entfernung zu haben. Das eigentliche Problem hierbei ist, dass diese Abbildung keine lineare Funktion ist und sich außerdem nur recht aufwendig durch ein Polynom approximieren lässt, daher macht eine Lookup-Table hier Sinn, als Performancegewinn, nicht um Rauschen auszugleichen. Das Verfahren wäre meines Erachtens auch das beste für den Wettbewerb gewesen, obwohl man auf dem PC genauso gut auch mit Polynomen rechnen kann, weil dieser eine recht schnelle FPU hat.
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????
Sorry, "ruhige Abstandswerte" verstehe ich nicht. Der Simulator gibt doch Spannungswerte an den Bot weiter, die so sind, wie wenn sie ein realer Sensor ermittelt hätte, nur eben ohne Rauschen (zurzeit). Das ist auch sinnvoll, denn möchte man sein Verhalten im Sim testen, dann sollte das erstmal ohne Sensorrauschen funktionieren, in einer vereinfachten Umgebung sozusagen. Man könnte als Option ein Rauschen "zuschaltbar" machen im Sim, aber ich denke das ist ein anderes Thema und hier fehl am Platz.
wer hat den bitte ein bot der genau 120mm meldet konstant und ohne wackler. durch die kalibrierung ist so etwas möglich!
Ich. Man muss eben nur den Spannungswert in eine Entfernung (hier 120 mm) umrechnen. Wenn sein muss, kann ich gerne ein Video (nicht digital nachbearbeitet...) machen.
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?! :-)
Ja, es geht dabei wohl auch in erster Linie um die beste Lösung, darum die ganze Diskussion hier.
2) eeprom nutzung kompliziert / neudas 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.
Huch, verstehe ich schon wieder nicht :-/ Ich vermute mal, es ist gemeint, dass die Variablen auf beiden Systemen (PC und MCU) an derselben Adresse (im Speicher ?) liegen? Ich sehe keinen Grund, warum das der Fall sein müsste, einzig der Name muss eindeutig sein, das ist er aber ja automatisch, wenn der Quellcode gleich ist. *ratlos*
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.
Die Bereiche sind aber schon durch den Datentyp vorgegeben (außer man bügelt alles mit uint8 über oder so), das eigentliche Problem liegt eher woanders.
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!
Sie müssen lediglich immer deklariert sein, was aber völlig unproblematisch ist.
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....
Nun ja, ein gutes, strukturiertes und möglichst allgemeines Design zeichnet sich IMHO nicht durch den Zeitaufwand des Nachschlagens aus.
es ist moment noch jede menge frei im eeprom, also finde ich ;-) meine lösung nicht so schlecht oder...
Niemand sagt, dass hier etwas schlecht sei, es geht nur darum, Ideen zu sammeln und "das beste" daraus zu machen, so dass alle davon profitieren. Dazu sind sicher viele Zwischenschritte nötig, auch wenn man diese vielleicht später nicht mehr erkennen sollte. Wenn jemand A vorschlägt und es später nach Diskussion zu B kommt, dann ist B vermutlich besser, als wenn es A nie gegeben hätte (und was der Kunde wollte ist C... :D )
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.....
In dieser Mail ging es mir jetzt in erster Linie um das Konzept, nicht darum, dass mir die ein oder andere Codezeile nicht gefällt oder ich behaupte, sie funktionierte nicht korrekt! Ist nur meine Meinung, die uns vielleicht ein kleines Stückchen weiterbringen kann.
Viele Grüße, Timo