|
 |
 |
 |
|
|
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, 01.08.2007 20:52:24
In-reply-to:
<000001c7d45c$d31d48e0$fe78a8c0@mexpnew>
References:
<000001c7d45c$d31d48e0$fe78a8c0@mexpnew>
Hallo,
Am 01.08.2007 um 18:55 schrieb Frank Menzel:
Hallo,
das Verhalten zum Erkennen des Hängenbleibens, welches bereits in
behaviour_map_go_destination implementiert war, habe ich mal
rausgezogen
und als globales Notfallverhalten laut angehängtem Patch definiert.
das ist sehr gut, so kann man das Verhalten unabhängig von Karte /
Pfadplanung benutzen :-)
Sobald also das Define gesetzt ist (wenn Maus verfügbar ist) und
der bot
an einer Ecke hängen bleibt, so wird durch den registrierten Handler
etwas rückwärts via bot_drive_distance gefahren. Da alle bei Notfall
registrierten Routinen durchlaufen werden, können diese
verhaltensabhängigen Handlerroutinen entsprechend reagieren je nach
Verhalten.
Sehe ich das richtig, dass der Ich-bin-hängengeblieben-Fall nur dann
eintritt, wenn beide Räder jeweils um mehr als 100 mm/s vom Mauswert
abweichen? Eigentlich könnte man das Hängenbleiben eines Rades doch
auch schon erkennen und müsste nicht erst abwarten, bis der Bot
völlig frontal gecrasht ist, oder? Und was ist, wenn der Bot nur mit
SLOW fährt, also 50 mm/s, dann kann die Bedingung so ja nie eintreten.
So richtig intuitiv ist die hang-on-Bedingung irgendwie nicht, müsste
nicht eher die vom Maussensor gelieferte Geschwindigkeit dann
ungefähr null sein und die vom Encoder Gemeldete > BOT_SPEED_SLOW / 2
oder so? Wenn der Maussensor 150 mm/s meldet und der Encoder 40 mm/s,
dann hängt der Bot wohl eher nicht fest, das Verhalten schlägt aber
trotzdem zu. Fiel mir nur gerade so auf.
Gruß Timo
|
|
|