|
 |
 |
 |
|
|
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: 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 / 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.
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
|
|
|