Think Modular

[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.

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]

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]

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]

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]

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]

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

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]

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?