|
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, 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 wuenschenswert
Die 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
|
|