heise online | · | c't | · | iX | · | Technology Review | · | Telepolis | · | mobil | · | Security | · | Netze | · | heise open | · | heise resale | · | Autos | · | c't-TV | · | Jobs | · | Kiosk

Aktuelles Heft #### Support Hotline & FAQ Tipps & Tricks Treiber & BIOS Firmenkontakte #### Download Software zu c't Software-Verzeichnis c't-Projekte Testbilder & Vorlagen #### Service Tipp-Datenbank c't-CD-Register Internettarife Telefontarife Virenschutz #### Magazin Heftarchiv c't specials English Pages Benchmarks Red. Stuff Leserforum c't-Bildmotive URLs aus c't Schlagseite #### Aktionen Browsercheck Krypto-Kampagne Schulen ans Netz Netz gegen Kinderporno TV/Radio-Termine #### Info Abo & Heft Veranstaltungen Mediadaten Kontakt Impressum Kleinanzeigen und Veranstaltungen
| c't Projekte - c't-Bot und c't-Sim - Mailinglisten ## c't-Bot und c't-Sim [Voriger (Datum)] [Nächster (Datum)] [Voriger (Thread)] [Nächster (Thread)] [Nach Datum][Nach Thread] ### Re: [ct-bot] Re: Kalibrierung der Distanzsensren mittels EEPROM-Tabelle 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
Antworten: Re: [ct-bot] Re: Kalibrierung der Distanzsensren mittels EEPROM-Tabelle From: Timo Sandmann Referenzen: [ct-bot] Kaibrierung From: Carsten Giesen [ct-bot] Re: Kalibrierung der Distanzsensren mittels EEPROM-Tabelle From: Achim Pankalla Re: [ct-bot] Re: Kalibrierung der Distanzsensren mittels EEPROM-Tabelle From: Timo Sandmann Voriger (Datum): Re: [ct-bot] Re: Kalibrierung der Distanzsensren mittels EEPROM-Tabelle, Achim Pankalla Nächster (Datum): Re: [ct-bot] Re: Kalibrierung der Distanzsensren mittels EEPROM-Tabelle, Achim Pankalla Voriger (Thread): Re: [ct-bot] Re: Kalibrierung der Distanzsensren mittels EEPROM-Tabelle, Achim Pankalla Nächster (Thread): Re: [ct-bot] Re: Kalibrierung der Distanzsensren mittels EEPROM-Tabelle, Timo Sandmann Indizes: Datum Thread |

Copyright © 2007 Heise Zeitschriften Verlag | Kritik, Anregungen bitte an c't-WWW | Datenschutzhinweis Impressum