Absender: Timo Sandmann
Datum: Mi, 22.10.2008 13:44:48
In-reply-to:
<48C139945BA47F4DB4DE05DF62CD57AA03DA0AC938@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
References:
<20081021053641.66060@xxxxxxx> <92C7C0B7-7E53-4C60-A93D-64A53372A1C3@xxxxxxxxxxxxxxx> <48C139945BA47F4DB4DE05DF62CD57AA03DA0AC938@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Hi Frank, Am 22.10.2008 um 12:38 schrieb Menzel, Frank IT-OO4:
Hallo Timo,habe mal alle ToDo-Punkte aus dem Code hier reinkopiert und dazu nun meine Anmerkungen://TODO: ATmega32-Version ueberlegen //TODO: Groessere Karte auch fuer MCU waere wuenschenswertDie beiden Punkte kann man ja zusammen betrachten. Meine ersten Versuche waren die, mit dem vorhandenen Code der hochauflösenden Karte diese Planungskarte ebenfalls auf der SD-Karte zu halten. Wie bei der hochauflösenden gibt's dann im Ram nur der Puffer, wo eben die Bereiche der Karte bei Gebrauch dynamisch reingeladen werden. Habe ich leider nicht hinbekommen, rein compilerseitig war alles OK, auch im Simu lief es auf PC-Ebene prima, jedoch auf dem echten ging gar nichts mehr. Keine Ahnung warum, aber hätte dies funktioniert, wäre der Prozessor egal und auch größere Karten möglich.Lösung also hier: Auslagerung auf MMC
das größte Problem dabei ist IMHO, dass die MMC ja auch für die eigentliche Map benutzt wird. Da aber nur ein exklusiver Zugriff möglich ist, muss man sämtliche Zugriffe synchronisieren / serialisieren. Die einzig elegante Lösung wäre meiner Meinung nach, eine (logische) Schicht zwischen MMC-Treiber und Map-Code / Verhalten einzuziehen. Ein Ansatz dazu war der Speichermanager, der bereits im Framework ist. Allerdings verträgt der sich nicht mit dem Multithreading-Konzept, das wir beim Map-Code aber definitiv brauchen, weil der Bot sonst zu spät auf wichtige Ereignisse reagieren kann. Außerdem müsste man den Zugriff möglichst mit Prioritäten ausstatten können, damit eine sequenzielle Folge von Map-Teilen (= MMC- Blockadressen) nicht durch andere Zugriffe unterbrochen wird (nicht sequenzielle Schreibzugriffe auf Flash-Speicher sind extrem langsam). => Ich fürchte für diesen TODO-Punkt muss zunächst einiges am Grundsystem umgebaut werden. Jedenfalls fällt mir derzeit keine Alternative ein, was aber nicht unbedingt viel heißen muss...
//TODO: Lohnt der Overhead mit den Sections, wenn es (auf MCU) nur eine gibt? Siehe Punkt oben, ist so noch übernommen aus dem Code der hochauflösenden Map. Aber Frage: Die hochauflösende gibt's doch auch nur einmal auf MCU ?
Nein, ich meinte damit, dass es auf MCU nur genau eine Section gibt, der Zugriff erfolgt also nicht über einen Zeiger / Puffer, sondern über einen berechneten Array-Index, der letztlich immer 0 ist, weil das "Array" nur einen Eintrag (eine Section) hat.
//TODO: Sectiongroesse von 512 Byte waere besser, um auf MMC auslagern zu koennen. Kann sicher dann in den Auslagerroutinen entsprechend günstig für MMC-Zugriff, analog den jetzigen Routinen der hochauflösenden Map, angepasst werden. Wie gesagt, ich bin daran gescheitert...
Hast du irgendwas dafür getan, die Zugriffe auf die MMC mit den Map- Zugriffen zu synchronisieren? Das muss man auf jeden Fall tun. Leider fehlt zu diesem Thema noch massenhaft Dokumentation, von daher ist das vermutlich auch schwer zu überblicken.
//TODO: Warum Durchschnitt? Fuehrt bei kleinen "Loechern" in der Map zu Problemen Auf ein Feld der niedrigauflösenden Karte kommen viele der hochauflösenden. Wie sonst wenn nicht per Durchschnitt ? Den Wert habe ich experimentell ermittelt, der mir am günstigsten erschien. Kleine Hindernisstellen könnten ja auch Fehlinterpretationen sein, die damit dann wegfallen. Andererseits werden sicher erkannte Hindernisse mit dem Durchschnittswert gut erkannt. Wenn ich ohne Durchschnitt genau nur ein Feld der hochauflösenden in die niedrigauflösende übertragen will, würde ich da eher Probleme des nicht-erkennens von Löschern sehen (ohne dies jetzt getestet zu haben).
Ich würde eher so vorgehen, dass ein Feld der Rasterkarte (für Pfadplanung) höchstens X Felder der Map (Umgebungskarte) enthalten darf, deren Hinderniswahrscheinlichkeit über einem Schwellwert S liegt, wenn es dort als frei gelten soll und umgekehrt für Felder, die als belegt markiert werden sollen. Ähnlich wie map_way_free(), das bei einem Hindernis bereits abbricht und False liefert. Genau diese Funktionalität stellt ja map_get_ratio() zur Verfügung. Mit dem Durchschnitt von Wahrscheinlichkeiten ist das so eine Sache für sich.
//TODO: Ganze Zelle sollte als Hindernis eingetragen werden, sobald auch nur ein Feld der Map als belegt markiert ist! Erscheint ja in Zusammenhang zum Punkt oberhalb, ist mir aber nicht klar was gemeint ist
Angenommen ein Rasterfeld von 12 cm Kantenlänge ist auf einer Fläche von 11 * 12 cm^2 als frei markiert und auf 1 * 12 cm^2 als belegt, dann kann der Bot dort nicht fahren. Der Durchschnitt der Mapfelder dieses Rasterfeldes wird vermutlich aber trotzdem unterhalb des kritischen Schwellwerts liegen und das ganze Rasterfeld wird als frei angesehen. Darum erscheint mir der o.a. Ansatz besser zu sein.
Ein Problem ist außerdem noch, dass während der Fahrt nicht auf erkannte Hindernisse reagiert wird (Notfallverhalten wird ausgeschaltet), ich glaube das Thema hatte wir aber schon mal, wenn ich mich recht erinnere.
Grüße,Timo