|
 |
 |
 |
|
|
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: Mi, 07.03.2007 12:50:00
In-reply-to:
<45ED3B46.4030400@xxxxxx>
References:
<BCF016D5ED5AC34FBB655D109519ABCF083EBE@xxxxxxxxxxxxxxxxxxxx> <45ED3B46.4030400@xxxxxx>
Hallo,
ich antworte mal auf die ursprüngliche eMail, weil sonst der Bezug
zum Eigentlichen etwas unklar ist, hoffe aber die inzwischen schon
angesprochenen Punkte trotzdem abzudecken. ;-)
Am 06.03.2007 um 10:58 schrieb Achim Pankalla:
hier nochmals die vorteile des patches.
- über tabellen im eeprom liefern die dist sensoren stabile werte.
So wie ich das sehe, wird aber bei jedem Aufruf von sensor_abstand()
die komplette Tabelle durchsucht. Wir wissen aber, dass die Funktion
Spannung -> Entfernung monoton ist, darum bietet sich doch die Ablage
in einer Baumstruktur an. Der Baum ist immer balanciert, man findet
die Einträge schneller und wie die Daten letztlich im Speicher /
EEPROM liegen, ist für den Anwender egal.
Ich hatte das vor einiger Zeit mal ausprobiert (allerdings nicht im
EEPROM, sondern im Flash, weil ich keine Zeit hatte ein
Kalibrierungsverhalten zu machen und so die Werte ganz einfach in
sensor_correction.h schreiben konnte). Die Auflösung war dabei 5 mm,
die auch super mit der realen Entfernung übereingestimmt hat (ich
fand die Map sehr schön :-) ). 5 mm, damit man weitestgehend in 8 Bit
rechnen kann und keine floats braucht. Ich hatte 15 Werte
gespeichert, das war genau genug für die Sensoren (übrigens sollte
man die Auflösung noch mit den Map-Routinen abgleichen) und in log(15)
=4 Vergleichen hat man die gesuchte Entfernung.
Vielleicht lassen sich ja beide Varianten kombinieren?
- beide sensoren sind nun angeglichen liefern gleiche wert
- eeprom ist nun auch im sim vorhanden, eeprom kann vom bot im sim
benutzt werden
- alle fkt. die das eeprom benutzen sind schon agepasst.
Wenn man die EEPROM-Adressen so statisch zuordnet, braucht man aber
IMHO noch ein Tool, welches daraus eine eep-Datei mit den
Initialisierungen erstellt, die per ISP oder Bootloader "geflasht"
werden kann, sonst wird die EEPROM-Benutzung dank falscher Init-Werte
zum Glücksspiel, z.B. bei bot_turn().
hier die nachteile oder besser einschränkungen
- eingeschränkte auslösung der distanzwerte (bei mir 10mm auflösung
noch super ruhig)
und bei < 10 mm?
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). die nutzung der kalibrierungstabelle geht
jedoch einwandfrei. meine bot hat mit meinen eepromwerten mehrer
parcours gemeistert. nun könnte ja jemand wieder schwankende sensor-
werte einbauen. mein patch ist ja nicht mehr mit den neuen sim
kompatible, vielleicht erbarmt sich ja jemand. :-)
Das Kalibrieren sollte IMHO auf jeden Fall in ein Verhalten, das ist
keine Initialisierung, die zu Beginn von main() ausgeführt wird. An-
und abschaltbar per available_behaviours.h. Insbesondere eine FB-
Tastenzuordnung / RC5_Code Auswertung in oder von ct-Bot.c sowie
Displayausgaben dort sind IMHO unbedingt zu vermeiden.
Die Auswertung der Distanzsensoren sollte für links und rechts
getrennt erfolgen, wenn man den ADC nämlich asynchron betreibt, kann
man, sobald der Wert für den linken Sensor bereitsteht, dessen
zugehörige Entfernung berechnen, während der ADC parallel dazu den
Wert für rechts konvertiert (das ist unabhängig von EEPROM & Co.) =>
kein busy-waiting => bessere Performance :-)
Zur EEPROM @ PC Diskussion: Ich denke, man sollte genau nachdenken,
wo man überhaupt ein emuliertes EEPROM auf dem PC braucht. Im
Wesentlichen sehe ich zwei Dinge bei solch einer Emulation: Zum Einen
um Code am PC testen / debuggen zu können (siehe MMC-Emulation am
PC), das spielt aber für das EEPROM IMHO nicht so eine große Rolle,
denn man speichert / liest einfach nur Bytes, Words oder kleinere
Blöcke (das fehlt glaube ich auch noch in der Patch-Lösung? Brauche
ich unbedingt ;-)) und keine großen Datenmengen.
Zum anderen, um denselben Code für MCU und PC zu haben. Hier macht
das schon Sinn, nur wo setzen wir letztlich das EEPROM ein? Die
Distanzsensorwerte im Sim sind immer identisch, hier könnte man die
Daten auch hardcoded in sensor_correction.h ablegen, so wie die Maus-
DPIs in bot-local.h. Ebenso verhält sich bot_turn() im Sim immer
gleich. Den FAT-Cache für die MMC braucht man am PC genauso wenig wie
die Daten der Motorregelung. Bleibt die Frage, was mehr Code ist, die
Emulation für den PC (inkl. der daraus resultierenden und in den
eMails zu diesem Thema genannten Einschränkungen) oder zweimal #ifdef.
Bitte nicht falsch verstehen, die Idee einer EEPROM-Emulation für den
PC ist super und wenn man eine einheitliche Schnittstelle für
Verhalten / Bot-Code hat, ist das ein eindeutiger Vorteil, man sollte
dadurch nur keine Nachteile schaffen, die man sonst nicht hätte.
Es gibt übrigens auch noch einen Vorteil der statischen EEPROM-
Adressenzuordnung: Macht man das per gcc-Attribut, muss man
aufpassen, dass der Code, der die Variablen deklariert (für MCU)
*immer* compiliert wird und nicht u.U. durch ein #ifdef
ausgeschlossen wird, dann ändert der Compiler nämlich alle Adressen
und man bekommt Chaos / überschreibt oder liest andere Werte.
Heute morgen hatte ich noch einen Punkt dau im Kopf, der mir jetzt
aber entfallen ist... :-/ Folgt später... ;-)
Viele Grüße,
Timo
|
|
|