|
 |
 |
 |
|
|
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:38:53
In-reply-to:
<A1E61AA9-0BF2-4A89-B255-27EDD9BDECD2@xxxxxxxxxxxxxxx>
References:
<BCF016D5ED5AC34FBB655D109519ABCF083EBE@xxxxxxxxxxxxxxxxxxxx> <45ED3B46.4030400@xxxxxx> <A1E61AA9-0BF2-4A89-B255-27EDD9BDECD2@xxxxxxxxxxxxxxx>
hallo,
hier einige ich hoffe helfende antworten...
Timo Sandmann schrieb:
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.
stimmt, aber nur in dem fall, das der sensorwert kleiner als der des
grössten abstand in der tabelle ist. ansonsten bricht die schleife
vorher ab. über alternative verfahren kann man nachdenken und jeder kann
was besseres implementieren. der kode lebt ja nun mal, sonst wäre es
langweilig....
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().
ich weiss noch nichts über den bootloader, da ich mich damit noch nicht
beschäftigt habe. wenn ich ihn benutze zum prg aufspielen, wird dann
auch das eeprom gelöscht??? ich spiele meine prg noch mit ponyprog auf
und muss dann mit write data (eeprom) nach dem prg auch das eeprom neu
aufspielen. das eeprom ziehe ich nach dem kalibrieren natürlich ab (im
bin format) und kann diese datei dann auch im sim-bot benutzen. sie muss
nur in dem pfad stehen, der in parameter-low_pc.c steht.
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?
kanst probieren, keine ahnung. erfordert aber präzises positionieren des
bot, abstand bei der aufnahme 1cm zwischen den messpunkten. hat meines
sensor mit allen kondensatoren versehen, sollte das auch noch stabile
anzeigen liefern. sind die sensoren im orginalzustand des bauplans, so
rauschen sie ja mehr, dann kann es auch bei 10mm wieder mehr rauschen
trotz kalibrieren, aber die orginalwerte sind dann ja auch unruhiger...
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.
mein standpunkt dazu findest du meiner mail von 23:10.
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 :-)
ist schon spät nach der arbeit, deshalb versteh ich nicht ganz was du
meinst. nur soviel, die tabelle gibts natürlich für rechts und links
getrennt und die werte werden auch für beide in sensor_abstand getrennt
bestimmt... wenn du meinst, das man getrennte sensor_abstand fkt für
links und rechts schaffen sollte, das gabs ganz am anfang mal, als hr.
jonas die erste version schrieb. hr. benz fand aber eine lösung mit
einer fkt besser. siehe newsletter vom 7.4.06
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
_______________________________________________
ct-bot-entwickler Mailingliste
ct-bot-entwickler@xxxxxxxxxxxxxxxxx
http://www.heise.de/bin/newsletter/listinfo/ct-bot-entwickler
|
|
|