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:
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....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.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.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().
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...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.
mein standpunkt dazu findest du meiner mail von 23:10.
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.06Die 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 _______________________________________________ ct-bot-entwickler Mailingliste ct-bot-entwickler@xxxxxxxxxxxxxxxxx http://www.heise.de/bin/newsletter/listinfo/ct-bot-entwickler