c't

c't-Projekte - Mailinglisten


[Voriger (Datum)] [Nächster (Datum)] [Voriger (Thread)] [Nächster (Thread)]
[Nach Datum][Nach Thread]

Re: [ct-bot] Pfadplanung in area

Absender: Timo Sandmann
Datum: Fr, 21.11.2008 21:15:01
In-reply-to: <000001c94c07$556c9030$0200a8c0@mexpnew>
References: <000001c94c07$556c9030$0200a8c0@mexpnew>


Hi Frank,

Am 21.11.2008 um 19:31 schrieb Frank Menzel:
Hi Timo,
sorry, den Parcours am Ende hatte ich bei den vielen Logs übersehen.
Habe jetzt auch mal den bot durch den Parcours laufen lassen. Aber wenn ich gleich zu Beginn bot_turn -30 mache, dann dreht er sich nach rechts,
wo doch gar keine Wand ist!?

ja damit er nie parallel zu einer Wand fährt, sonst frisst er sich dort so leicht fest.

Also er startet ja in der Mitte, fährt nach links zur Wand, dreht sich
rechts zur Nebenbahn und fährt die rechte Nebenbahn zur rechten
Außenwand. Dort dreht er sich rechts und befährt die Bahn, die er bei
Start von der Mitte her nach links gefahren ist. Hmm, da war bei mir
noch nichts mit Pfadplanung und Weg versperrt (mehrfach versucht).

Ich glaub der Fall, wo die Pfadplanung ganz am Anfang aktiv wurde, war in einem anderem Parcours, hatte da einige durchprobiert.
Hier mal eine Karte, bis die erste Pfadplanung aufgerufen wird:
http://www.heise.de/ct/projekte/machmit/ctbot/wiki/MLAttachments#a21.11.2008-ct-botPfadplanunginarea

Das LOG dazu:
Connection to localhost established on Port: 10001
behaviour_drive_area.c(672)	- DEBUG -	Abstaende voraus: L/R: 995 995
behaviour_drive_area.c(916) - DEBUG - Stackholen P1: 1363 -900 P2: -45 -77
behaviour_drive_area.c(889)	- DEBUG -	Ausrichten auf -45 -77
behaviour_drive_area.c(672)	- DEBUG -	Abstaende voraus: L/R: 995 995
behaviour_drive_area.c(916) - DEBUG - Stackholen P1: -232 -63 P2: 1319 -970
behaviour_drive_area.c(889)	- DEBUG -	Ausrichten auf 1319 -970
behaviour_drive_area.c(672)	- DEBUG -	Abstaende voraus: L/R: 995 995
behaviour_drive_area.c(916) - DEBUG - Stackholen P1: 1358 -1114 P2: -272 -137
behaviour_drive_area.c(889)	- DEBUG -	Ausrichten auf -272 -137
behaviour_drive_area.c(672)	- DEBUG -	Abstaende voraus: L/R: 995 995
behaviour_drive_area.c(916) - DEBUG - Stackholen P1: -576 -63 P2: 1313 -1186
behaviour_drive_area.c(889)	- DEBUG -	Ausrichten auf 1313 -1186
behaviour_drive_area.c(672)	- DEBUG -	Abstaende voraus: L/R: 995 995
behaviour_drive_area.c(916) - DEBUG - Stackholen P1: 1172 -1233 P2: -618 -136 behaviour_drive_area.c(926) - DEBUG - Weg nicht frei, >> Pfadplanung << zu 1172 -1233 behaviour_drive_area.c(779) - DEBUG - zu Nah->Back L: 165 R: 135, ist < 144
behaviour_drive_area.c(889)	- DEBUG -	Ausrichten auf -618 -136
behaviour_drive_area.c(672)	- DEBUG -	Abstaende voraus: L/R: 995 995


Aber grundsätzlich kann es schon sein, das der Weg laut map_way_free
versperrt sein kann. Die Area-Obserververhalten beobachten die
Nebenbahnen rechts vom bot. Kommt er nun an eine Wand an, so erkennt er beispielsweise rechts daneben ist der Punkt laut Map frei und speichert diesen als nächsten Anfahrpunkt. Der Bot holt sich diesen vom Stack und
dreht sich dorthin. Dabei kann das Onlinescan erst jetzt eine Wand
daneben scannen und in die Map eintragen. Ist diese nah beim
Anfahrpunkt, sagt map_way_free geht nicht, weil ja wohl hier der
Botdurchmesser als Vergleich genommen wird und die Wand eben zu nah ist.

Du meinst, dass auf dem Stack eine Position liegt, an der der Bot eigentlich (zumindest zum Teil) in der Wand stände? Aber wie kann die Pfadplanung den Bot dann dorthin fahren? Dann müsste es ja einen Crash geben und die Position nie erreicht werden können, oder?

Wir haben übrigens vorhin überlegt, wie man eine (online) Anzeige der Map im Sim realisieren kann. Wenn das so klappt wie geplant, dann sollte es deutlich einfacher werden, Verhalten, die die Map benutzen, zu debuggen.

Gruß,
Timo