Think Modular

**Defiant** · 18.11.2020, 12:55

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.

**Holomino** · 18.11.2020, 14:20

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?

**Defiant** · 18.11.2020, 18:53

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?

**Holomino** · 19.11.2020, 15:17

Zitat von Defiant

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.

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.

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?

**Defiant** · 19.11.2020, 18:49

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.

**Holomino** · 20.11.2020, 12:06

Zitat von Defiant

Nein, deine Hardware hat mit dem Pfad nichts zu tun, die soll nur die aktuelle Geschwindigkeit des local planners ausführen.

Bleibt mir also nur festzustellen, das ROS mit eigenständig lagegeregelten Fahrgestellen nicht kann.

Ist mir zwar völlig unklar, warum ich das zyklische Ausregeln der Lagedifferenz zu einem Bahnpunkt auf nem Linux vornehmen soll, aber ich habe ROS ja auch nie angewendet.

Letztlich auch kein Problem, wenn man in der allgemeinen Schnittstelle zu einem Bewegungsmodul zusätzlich zur DriveToPoint(dx,dy) noch entsprechend der ROS-Spec ein DriveSpeed(translate, rotate) einbaut (Ist nicht unüblich, die Lageregelung in der Schnittstelle überbrückbar zu gestalten, z.B. Servo Controller). Dann kann das Bewegungsmodul auch ROS.

**Defiant** · 20.11.2020, 13:14

Kleine Korrektur: ROS selbst dürfte alles können, nur das Navigation Stack kann eventuell nicht, was du möchtest. Ist mir allerdings auch nicht klar, wieso man das Anfahren einer Position seinem Fahrkontroller überlassen möchte, dieser hat zumindest bei mir keine Sensorinformationen. Warum du das auf alle "eigenständig lagegeregelten Fahrgestelle" verallgemeinerst ist mir auch nicht klar, https://robots.ros.org/category/ground/ hat jedenfalls Roboter dieser Kategorie, z.B. Seekur.

Zum Thema Linux: ROS 1 & 2 sollen angeblich auch unter Windows laufen.

**Holomino** · 21.11.2020, 15:21

Zitat von Defiant

Nein, deine Hardware hat mit dem Pfad nichts zu tun, die soll nur die aktuelle Geschwindigkeit des local planners ausführen.

Zitat von Defiant

Warum du das auf alle "eigenständig lagegeregelten Fahrgestelle" verallgemeinerst ist mir auch nicht klar, https://robots.ros.org/category/ground/ hat jedenfalls Roboter dieser Kategorie, z.B. Seekur.

Du solltest Dich nun einmal entscheiden.
Beim Seekur steht auch nur "velocity control and position integration". (position integration != position control ?!)

**Defiant** · 21.11.2020, 15:59

Zitat von Holomino

Du solltest Dich nun einmal entscheiden.

Ich kann dir gerade nicht folgen, wobei nicht entscheiden?

Seekur: Ich habe keine Ahnung was die Marketing-Abteilung von denen damit sagen will. Aber "velocity control" wär ja was ich oben sagte, das man für die Odometrie-Position die velocity aufintegriert macht man doch immer so?