Bei dem base_local_planner den ich verwende nicht. Es gibt noch diverse andere Planner, die man stattdessen verwenden kann. Ob einer von denen vor der Kurve bremst kann ich nicht sagen - hatte das Problem noch nicht. Es gibt aber die max Beschleunigung für Translation und Rotation, d.h. der Planner wird kein Kommando von 0°/s auf 90°/s absetzen, sondern die Geschwindigkeit Schrittweise erhöhen.
Hmm, ich kann mir schwer vorstellen, einer Spinne, die sich über Hindernisse tastet, Geschwindigkeitsvorgaben zu machen. Ebensowenig kann ich mir vorstellen, einem Synchrodrive mit dAngle/s das seitwärts losfahren beizubringen.
Kann es sein, dass z.B. mit https://wiki.ros.org/follow_waypoints auch die Interpolation des Pfades über die Angabe von Zwischenpunkten (-posen) möglich ist? (Die könnten Spinne oder Synchrodrive-Roboter ja zumindest linear ansteuern).
Du kennst doch die min. und max. Geschwindigkeiten deines Laufroboters. Wenn dieser sich nur mit max. 10cm/s vortasten kann, dann ist das genau die Geschwindigkeit, die dem Localplanner vorgegeben wird. Die vom Localplanner vorgegebene Geschwindigkeit wird natürlich irgendwo von der Hardware abstrahiert, d.h. bei deinem Synchrodrive muss irgendwo ein Stück Software sitzen das sagt "Drehe Räder um seitlich zu fahren".
Nein, follow_waypoints kannte ich noch nicht, aber von der Beschreibung her wird nur eine Liste der Wegpunkte abgearbeitet:
- move_base ist der Zustandsautomat der versucht immer _genau eine_ Position anzufahren, z.B. einen Punkt in der Küche, der Roboter steht aber gerade im Wohnzimmer und ich muss mehrere Hindernisse umfahren um dahinzukommen.
- Der Globalplanner berechnet anhand der globalen Hinderniskarte (global costmap, die komplette bekannte Karte) dann mit einem A*-Algorithmus einen Pfad vom Wohnzimmer zur Küche
- Der Localplanner nimmt den Pfad des Global planners und ermittelt anhand der lokalen Hinderniskarte (local costmap, bei mir eine Fläche von 3x3m, enthält von den Sensoren erfasste und nicht auf der Karte vorhandene Hindernisse) die Geschwindigkeiten die der Roboter jetzt zu fahren hat.
- Will man den Roboter jetzt ein Viereck patrouillieren lassen hat man vier Punkte die nacheinander abzufahren sind, das ist dann der Job von follow_waypoints. Man hat dann aber keine Kontrolle über Zwischenpunkte, sofern man sie nicht als Ziel vorgibt.
Noch mal für die ältere Generation (mich):
Mein Bewegungsmodul hat als Befehl DriveToPoint(dx,dy). Wie es dabei Richtungswechsel, Strecke, Anfahren und Bremsen als fließende Bewegung löst, ist in der Regelung (im Controller) verknüpft.
Beim Pfadverfolgen zieht mein Pathfollower (extern, nicht im Controller, aber über eine Schnittstelle angebunden) durch die laufende Angabe von Punkten das Bewegungsmodul praktisch wie an einem Gummiband hinter sich her. Kommt der Roboter dem aktuellen Zielpunkt näher, entspannt sich das Gummiband und das Teil wird aufgrund der geringeren Regelabweichung langsamer. Also generiert mein Pathfollower sinnigerweise auf Geraden große dx/dy (er zieht am Gummiband) und lässt den Roboter beim Umfahren von Hindernissen an den Pfadecken die dx/dy Werte solange anstehen, bis der Roboter am Knick angekommen ist (das Gummiband entspannt sich).
Nu die Frage: Was müsste ich in ROS für diesen Befehl verwenden?
Geändert von Holomino (18.11.2020 um 14:29 Uhr)
Dein Bewegungsmodul ist relativ weit oben in der SW-Architektur nehme ich mal an? DriveToPoint(dx,dy) ist im Prinzip genau das, was move_base macht, siehe auch http://wiki.ros.org/navigation/Tutorials/RobotSetup.
Um mit dem ROS-Navigation Stack kompatibel zu sein muss deine Hardware
1. die Geschwindigkeitsbefehle verarbeiten können. Wenn der Localplanner sagt "fahr mit 1m/s vorwärts" oder "rotiere mit 30°/s" dann soll die Roboter-Hardware dies auch möglichst exakt ausführen.
2. Feedback als Odometry (aktuelle Position und Geschwindigkeit) geben
Das mit dem Gummiband habe ich ehrlich gesagt noch nicht ganz verstanden, aber es klingt ein wenig wie teb_local_planner.
Update: Geht es darum, dass der Roboter sanft anfahren und bremsen soll?
Wenn Du unter Wikipedia nach Kaskadenregelung schaust, ist die Angabe von Geschwindigkeiten aus ROS praktisch der grüne Block in der Zeichnung (die Drehzahl- oder Geschwindigkeitsregelung). DriveToPoint ist der blaue Block, also der Lageregler.Zitat von Defiant
Wenn Du jetzt mit dem Roboter einen Pfad um Hindernisse abfährst, oder eine CNC-Fräse schnurrt die Kontur eines Werkstückes ab: Beides basiert auf dem sequentiellen Abfahren einzelner Punkte (dem Übergeben von Zielpunkten an den Lageregler). Das kann auch unter ROS nicht anders sein.
Wo genau befindet sich in ROS der blaue Block der Lageregelung?
Und wie wird dieser Block auf unterschiedliche Bewegungsmodelle angepasst? Omniwheels und Synchrodrive kann man die y-Komponente der Translationsgeschwindigkeit übergeben. Bei Auto mit Lenkung oder Differentialantrieb ist das schwierig. Die können nicht schräg fahren.
- - - Aktualisiert - - -
Kann es sein, dass die Daten für die Lageregelung in ROS in global_plan/local_plan von base_local_planner sitzen (http://docs.ros.org/en/api/nav_msgs/html/msg/Path.html) und man sich auch daran mit der Hardware anbinden kann? Oder sind das nur geloggte Daten?
Geändert von Holomino (19.11.2020 um 15:28 Uhr)
Der "blaue Block" ist am ehesten der Local Planner. Er ist dafür da, dem Pfad des global Planners zu folgen, hat aber dabei einige Freiheiten um Hindernissen auszuweichen oder Unzulänglichkeiten (z.B. kein seitwärts oder rückwärtsfahren) der Hardware auszugleichen.
Ob eine Bewegung in der Y-Achse möglich ist macht beim base_local_planner der Parameter "holonomic_robot". Ackermann kann der base_local_planner nicht, dafür ist dann der teb besser geeignet.
-
Nein, deine Hardware hat mit dem Pfad nichts zu tun, die soll nur die aktuelle Geschwindigkeit des local planners ausführen. Der local planner folgt wiederum dem Pfad (dein Link) den der global planner berechnet hat.
Berechtigungen
Zitieren
Lesezeichen