ArdumowerTurtlebot

[paddy]

Hallo Allerseits,

kurz vorweg, hier sollte pro User nur ein Thread eröffnet werden, das habe ich gelesen. Mein Thread zum Arctic Hare ist schon so lang und das hier was neues, daher ein neuer Thread. Bitte kurze Info, falls das unerwünscht ist.

Nun zum Thema

seit langem möchte ich meinen Ardumower auf ein anderes Level heben und mit dem Robot Operating System (ROS) ausstatten. Das bedeutet eine irre steile Lernkurve für mich und die Notwendigkeit unzähliger Tests im kleinen, bevor es jemals raus auf den Rasen geht. Eine geeignete Testplattform musste folglich her. Wer sich mit ROS beschäftigt, kommt an den unzähligen Turtlebot Varianten nicht vorbei. Die haben mir alle nicht so recht gefallen (anderer Fokus), sind teuer und verwenden eine völlig andere Hardware. Der Ardumower Mini aus dem Shop gefällt mit ebenfalls nicht, die Platine sitzt da schlecht drauf, Odometrie hat wenige Ticks und alles sieht so gebastelt aus.
Zudem tummeln sich im Haushalt zwei neugierige Kinder, da müssen alle Kabel, Stecker usw. sicher sein.

Kurzum, ich entwerfe eine eigene Variante des Turtlebot, welcher mit der Ardumower Hardware (altes PCB1.2) arbeitet. Zunächst war die Überlegung, es komplett selbst zu drucken. Ich habe bei der Recherche nach einem schönen Design die Turtlebot3 Waffles für mich entdeckt. Die sind wie Lego und lassen sich in verschiedene Formen zusammen stecken. Außerdem gibt es unzählige Befestigungslöcher, für jeden was dabei. Bei 16€ für 8 Stück inkl. Schrauben lohnt es nicht, diese selbst zu drucken (was aber möglich ist, der Hersteller bietet ein CAD zum ausdrücklichen selbstdrucken an)

Hier nun die ersten Eindrücke und Bilder es ArdumowerTurtlebot

Das ist die Ansicht von vorne rechts. Die Antriebsräder sitzen wie bei den meisten Mowern und dem Arctic Hare hinten, vorne kommt ein Stützrad dran. Viele Teile fehlen noch.


Rein passt ein komplett bestücktes Ardumower PCB (1.2 oder 1.3)


Die Rückseite ist soweit fertig und druckt gerade. Dort ist Platz für ein Ladeanschluss, Hauptschalter und sicherlich einiges mehr


ROS soll später auf einem Raspberry PI laufen, der mit dem Roboter unterwegs ist. Der PI wird auf den Mower geschraubt und bekommt eine Schutzhaube.

Da das PCB länger ist als die 6 Turtlebot Waffles, habe ich eine kleine Verlängerung entworfen. Die passt super auf die gekauften Waffles


So sieht es mit PCB aus, rechts und links ist Platz für weitere Sensoren. Ebenfalls oben auf dem Mower und unten drunter.


Als Motoren kommen 24V Motoren mit Encoder aus Fernost für 12€ pro Stück rein. Für einen echten Mower sind die sicherlich viel zu schwach, aber der Roboter wird recht klein und leicht, da werden die genug Leistung bringen. Mähmotor entfällt natürlich.

Geplant sind außerdem:
- 3x US Sensoren vorne
- Bumper per Mikroschalter
- Kompass
- IMU
- 2x Perimeter Empfänger
- 24V Akku (7S1P)
- LM298N als Motortreiber

Mein Fahrplan für ROS sieht so aus:
1. zunächst bestehende Azurit mit ROS verwenden (danke Alexander für den ROS Treiber)
2. simple Fahrkommandos, manuelle Steuerung
3. autonome Fahrweise über Perimeter, chaotisches Muster (wie heute)
4. autonome Fahrweise mit Karte und Pfadplanung
5. OpenCV zur Hinderniserkennung
6. SLAM, wie auch immer das realisierbar ist

Beginnen werde ich mit der aktuellen Azurit, mittelfristig möchte ich die Firmware aber stark vereinfachen und auf ROS spezialisieren. Die Firmware soll später nur die Kommandos ausführen, Sensordaten senden sowie Ereignisse melden. Zur Sicherheit wird die Firmware bei Bumper oder verlassen des Perimeter immer stoppen, an ROS melden und die Entscheidung abwarten. Soweit der Plan

 

[lichte]

Interessantes Projekt. Viel Erfolg dabei. Bin auf Ergebnisse gespannt.

 

[der_kaputte]

Hi,
Schön zu sehen, dass sich noch mehr mit dem Ardumower und ROS beschäftigen! Ich bin auch auf dem "groben" Pfad, den Ardumower in die Richtung ROS zu bringen. Habe mich allerdings noch nicht mit dem Ardumower-ROS-Treiber auseinandergesetzt. Sondern eine eigene Arduino-FW geschrieben, welche mir die Encoder-Ticks ausgibt, und die Motor-CMDs umsetzt.
In meinem kleinen Blog kann man "wenig" davon sehen.

link: Mein Roboter - BLOG

 

[paddy]

Interessant, ich nehme die letzte Azurit auch nur als Basis. Den ROS Treiber der Firmware nutze ich nicht. Statt dessen schmeiße ich alles raus, was nicht gebraucht wird. Übrig bleibt nur das Auslesen der Sensoren, Teile der pfod Funktion und die Motorsteuerung. Ich schaue mir mal an, was du so gemacht hast. Vielleicht können wir uns zusammen tun.

 

[paddy]

Nach vielen Stunden konstruieren, drucken, erneut konstruieren und wieder drucken steht der Ardumower Turtlebot auf seinen eigenen Rädern und hat die ersten Meter per Ardumower Firmware und Bluetooth Steuerung zurückgelegt.

Als Motoren habe ich günstige 24V Motoren mit Encoder und Rad in Fernost gekauft.
https://www.aliexpress.com/item/32946445527.html?spm=a2g0s.9042311.0.0.73804c4dPLhk5U
Hier nun die ersten Eindrücke zu dem Turtlebot. Wie bereits beschrieben, besteht er neben den gedruckten Teilen aus Turtlebot Waffles Platten von Robotis, mit denen man sehr einfach verschiedene Arten von Roboter Plattformen bauen kann. Die Platten kann man für kleines Geld kaufen (16€ für 8 Stück inkl. Schrauben) oder selbst drucken. Ich habe meine bei diesem Händler gekauft, die Abwicklung ging irre schnell, daher meine Empfehlung.
Insgesamt besteht der Roboter aus 14 dieser Platten. Im großen Deck liegt die Ardumower Platine sowie alle Sensoren. Gesteuert werden soll der Roboter später mittels Robot Operating System (ROS), also musste ein Raspberry PI noch untergebracht werden. Dieser ist kurzerhand auf den Roboter gewandert und schaut über ein kleines Guckloch raus in die Welt. Am Heck gibt es noch einen kleinen Turm, der den Notaus und einen Button beherbergt. Mir gefällt an den Waffeln besonders, dass man sie so einfach kombinieren kann. Dank der unzähligen Löcher kann man Kabel und Schrauben sehr einfach befestigen. Wenn mal ein LIDAR dazu kommt, findet es einfach seinen Platz über den RPI.



Das mittlere Seitenteil hat leider nicht auf Anhieb gepasst. Ich habe die Konstruktion angepasst, aber nicht erneut gedruckt. Das kann passieren, wenn man dem CAD Modell des Herstellers traut, dieses aber von den tatsächlichen Teilen abweicht.

Hinten sind ein Schlüsselschalter als Hauptschalter sowie eine Ladebuchse angebracht. Der Not-Aus Schalter trennt nur die Motoren von dem Akku. Somit bleibt der Raspberry PI weiterhin mit Strom versorgt, auch wenn der Not-Aus betätigt wurde.

Bei dem Bumper habe ich auf bewährtes aus dem ersten Mimi Mower zurückgegriffen. Es sind einfache Druckteile, die beweglich sind. Diese drücken gegen einfache Rollentaster. Die gesamte Lösung arbeitet erstaunlich zuverlässig und deckt einen weiten Bereich ab.

Zu Beginn habe ich mich für einen einfachen Motortreiber entschieden, der noch im Fundus lag. Dieser ist einfach unter den Mower gewandert. In den Zwischenraum zwischen Antriebsräder und Stützrad findet ein 7S1P Akku mit Sony Konion VTC6 Zellen Platz. Es wird zwar eng, aber er passt da rein

Der Akku selbst muss noch mit Schrumpfschlauch eingepackt werden und eine Halterung fehlt dafür auch noch.


Nächste Schritte sind die weitere Verkabelung der restlichen Sensoren.

 

[amarok12]

Hallo paddy,
inzwischen ist fast schon ein Jahr rum. Läuft Dein Turtlebot schon unter ROS?
Würde mich freuen, wenn Du kurzes Update schreiben könntest.
Gruß
Wolfgang

 

[paddy]

Hallo paddy,
inzwischen ist fast schon ein Jahr rum. Läuft Dein Turtlebot schon unter ROS?
Würde mich freuen, wenn Du kurzes Update schreiben könntest.
Gruß
Wolfgang

Hallo,

leider bin ich in dem Forum nicht mehr so aktiv gewesen, ich gelobe Besserung. Daher entschuldige die späte Antwort.
Über das Jahr 2020 habe ich ein anderes Projekt verfolgt und dem meine ganze Aufmerksamkeit gewidmet. Es ist eine Alu CNC Portalfräse entstanden. Alles nach eigenem Plan, aber ähnlich zu dem hier https://fraeserbruch.de/fraese-bieber

Der Ardumower mit Arctic Hare Chassis und Azurit hat während dessen einfach seinen Dienst verrichtet. Da ist das Thema ROS hinten runter gefallen.
Vergessen habe ich den aber nicht und tatsächlich vor wenigen Tagen das ganze Projekt erneut angepackt.

Also zum aktuellen Stand:
- Firmware basierend auf Azurit aufgesetzt. Alles raus geschmissen, was mit der bisherigen State Machine zu tun hatte. Erfassen von Sensoren etc. sind natürlich drin geblieben. Läuft schließlich seit Jahren sehr gut
- Firmware um ROS Schnittstelle erweitert. Zunächst habe ich es mit rosserial versucht. Der Overhead ist aber zu viel und der Mega stößt schnell an seine Grenzen. Also habe ich ein simples eigenes Protokoll entwickelt, über das die Kommunikation zu ROS läuft.
- Passend dazu gibt es einen ROS Treiber für den Ardumower. Der Mower wird per USB direkt mit dem PC verbunden, der den ROS Treiber ausführt (PC, Raspberry PI, was auch immer). Hierüber werden die Kommandos von ROS in Ardumower Kommandos übersetzt und zurück. Der ROS Treiber nutzt Ardumower spezifische, einfache Nachrichten.

Die Firmware und der Treiber haben nun einen fortgeschrittenen Stand, es fehlen nur noch einige Kleinigkeiten. Das ganze ist auf safe-operation ausgelegt. Der Mower soll im Zweifelsfall immer halten (z.B. wenn keine ROS Nachrichten mehr erhalten werden).

Nächster Schritt ist ein ROS base_controller zu erstellen. Ich nenne das mal so. Die Idee davon ist, ROS Standard Nachrichten (Twist, Odom etc.) zu verarbeiten und an den Ardumower Treiber weiterzugeben.
So habe ich die Kommunikation zum Mower selbst abstrahiert und man kann den Mower auch als echten Turtlebot verwenden.

Sobald der base_controller steht, werden einfache Teleop Kommandos möglich sein. Durch die Odom Nachrichten mittels tf Transformation sollte man den Mower auch in RVIZ oder Gazeboo beobachten können (hoffe ich)

Dann wird es zeit, einen ersten Ardumower node aufzusetzen. Die Idee dabei ist, die ROS Standard Nachrichten zu verarbeiten und Entscheidungen darauf zu treffen. Zunächst wird der sehr einfach gehalten sein. Fahre bis Bumper oder Perimeter und drehe dann entsprechend ab. Wenn Akku leer, dann fahr heim.

Klingt zunächst vielleicht nicht spannend, das Verhalten entspricht ja dem bisherigen. Es wäre dann aber alles auf ROS und wir haben einen Basis um mehr daraus zu machen.

Für mich ist das vor allem ein nettes Projekt um mich mit dem Thema ROS auseinander zu setzen. Die meisten ROS Tutorials setzen immer auf Simulationen auf. Wir man von da an aber zum echten Roboter kommt, erklären die meist nicht. Ich gehe daher den umgekehrten Weg und bringe erst einmal einen echten Mower ans fahren. Simpel aber funktional. Wenn das verlässlich läuft, dann geht es in die Simulation und von dort bei Erfolg zurück auf den echten Rasen.

Das ganze ist ein weiter Weg. Ob das erfolgreich sein wird, kann ich nicht abschätzen. Mein Plan ist aber, bis Ende des Jahres '20 das elementare stehen zu haben.

Gruß Patrick

 

[amarok12]

Hallo Patrick,

danke für Deine Ausführungen. Ich habe erst vor kurzem angefangen, mich ROS zu beschäftigen. Habe mir dazu ein Buch gekauft, dass den Aufbau eines kompletten Roboters mit ROS-Steuerung erklärt. Nicht nur die Simulation, sondern auch wie man mit 3D-Programmen arbeitet für den Druck und die Simulation. Da bin ich jetzt erst mal bei den 3D-Programmen hängen geblieben rolleyes und versuche mir nun FreeCAD beizubringen. Aber ich will auf jeden Fall einen Robi mir ROS bauen.

Deine Fräse sieht übrigens gut aus.

Gruß
Wolfgang

 

[paddy]

Kleiner Zwischenstand von meiner Seite.
Ich habe ein ROS Paket soweit entwickelt, dass die Kommunikation mit dem Ardumower gut läuft. Das Paket besteht aus einem Treiber (Kommunikation mit dem Arduino), einem Base Controller (Übersetzen der Arduino Nachrichten in ROS Standard Nachrichten und zurück) sowie einem einfachen Ardumower node. Dieser kommuniziert mit dem Base Controller und übernimmt weitere Aufgaben, etwa das Auslesen der Sensoren.

An diesem Punkt habe ich die Entwicklung in ROS (Noetic) eingestellt und bin auf ROS2 (Foxy) gewechselt. Hauptgrund dafür war, ich habe einige interessante ROS2 Implementierungen (microROS auf ESP32) gesehen und wollte mir diese Option offen halten. Zudem ist ROS2 besser für Szenarien geeignet, in denen mehrere PCs oder MCUs zusammen arbeiten. Auch kooperatives Zusammenarbeiten mehrerer Roboter wird bei ROS2 unterstützt.

Daher habe ich die bisherigen Resultate auf ROS2 portiert und habe nun einen ähnlichen Stand wie zuvor.
- Ein Ardumower Treiber, der die Kommunikation mit dem Arduino übernimmt und Custom Messages erstellt
- ein Base Controller, der die Custom Nachrichten in ROS2 Nachrichten transferiert und darüber hinaus auch Frame Transformationen mit tf2 übernimmt (aktuell für odom realisiert)

In beiden Entwicklungszweigen ist eine tf für odom enthalten. ebenfalls sind cmd_vel Subscriber implementiert. Teleop ist also in beiden Versionen möglich.

Nachdem die IMU nun auch angebunden ist und die Date in Quaternions für Standard IMU Nachrichten übersetzt sind, werde ich im nächsten Schritt die tf2 Transformation der IMU vornehmen. Aktuell arbeite ich noch mit dem GY-801, überlege aber auf den BNO055 umzusteigen. Es wird also Zeit, ein URDF Modell zu definieren.

Anschließend werde ich einen ROS2 Node erstellen, der zunächst einfach wie Azurit durch die Gegend fährt und agiert. Ist dies geschafft, werde ich Versuche unternehmen, eine Karte basierend auf den bisherigen Daten zu realisieren. Da mir RTK GPS gegenwärtig zu teuer ist, wird der Perimeter erhalten bleiben. Vor langer Zeit gab es mal Versuche mit Sunray, eine Karte basierend auf dem Perimeter zu erstellen. Ich werde zunächst in diese Richtung weiter machen und hoffe, eine Genauigkeit von 1m zu erhalten. Mal schauen, was es wird.

Mittelfristig werde ich Versuche unternehmen, Teile des Azurit Codes auf ESP32 zu verlagern und dazu eine Adapterplatine für die PCB 1.3 basteln. Ein ESP32 Modul mit Kamera (dafür ggf. einen dedizierten) vereinfacht aus meiner Sicht den Aufbau deutlich, da einige Dinge wegfallen können:
- Raspberry PI für ROS2 nodes nicht mehr notwendig. Entweder Daten direkt per WLAN an zentralen PC, oder Micro ROS auf ESP32
- Wegfall einer seriellen Kommunikation über USB
- keine zusätzlichen Adapter für WLAN oder Bluetooth
- kein Herunterfahren des Mowers mehr nötig (bedingt durch den RPI)

Auch wenn die Fortschritte kleiner sind als ich erhofft habe, aufgegeben habe ich das Projekt nicht.

 

[paddy]

Kurzes Update von meiner Seite zum Stand der Ardumower Turtle Bot Version.

Nachdem eine minimale ROS2 Implementierung fertig war (Ardumower <-USB-> RPI) habe ich mich länger mit micro-ros und dem ESP32 beschäftigt. Beides neue Welten für mich, da hat es etwas gedauert.
Der ESP32 hängt nun an der Stelle, wo früher das WLAN Modul auf dem PCB1.2 untergebracht war. Der Mower kommuniziert nun nicht mehr über den USB Port, sondern über eine andere serielle Schnittstelle. Dies hat den Vorteil, dass USB für Debugging und Konfiguration frei bleibt. Der ESP32 betreibt zwei Tasks, einer der UART überwacht und ankommende Daten in eine Queue schreibt. Ein zweiter Task führt micro-ros aus und sendet aktuell die Daten einfach als String Nachricht ins ROS2 Universum.

Auf dem Screenshot zu sehen, oben links die Konsole des ESP32, unten links die Nachrichten innerhalb der ROS2 Umgebung und rechts der micro-ros Agent, welcher ESP32 mit ROS2 verbindet.



Als nächstes werde ich die Nachrichten auf dem ESP32 direkt in die ROS2 Nachrichten überführen und diese publishen. Später hat man dann viele Optionen, wie man den Mower über ROS2 anbindet:
1. ESP und per WLAN an einen zentralen ROS2 PC (z.B. RPI)
2. RPI an UART und per WLAN an zentralen ROS2 PC (verteilte ROS2 nodes)
3. ESP und per USB/LAN/WLAN an RPI, welcher im Mower mit fährt (unwahrscheinlich aber machbar)
4. RPI an UART, ROS2 läuft auf RPI im Mower

Was da am besten klappt werde ich sehen. Ob WLAN Latenz viele Probleme machen wird, ebenfalls. In allen Fällen bedarf es eine Art Bridge zwischen Ardumower und ROS2. Diese bildet entweder der ESP32 mit micro-ros, oder ein RPI mit serieller Verbindung und den zuvor entwickelten ArdumowerROSDriver

In allen Fällen haben wir später echte ROS2 Nachrichten innerhalb des ROS2 Universums. Wie der Mower angebunden ist, remote per WLAN oder ROS2 im Mower, spielt dann keine Rolle.

 

[paddy]

Update meinerseits.

Nachdem ich unzählige Stunden mit micro-ros auf dem ESP32 verbracht habe, bin ich um einige Erkenntnisse reicher. Meine Idee war, viele Dinge direkt auf dem ESP32 erledigen zu lassen und einzelne Nachrichten an andere ROS 2 Nodes zu senden. Nach diversen Problemen mit dem Build System (gruselig) und nachdem ich endlich eigene Nachrichtendefinitionen ins micro-ros gebracht hatte, kam der nächste Rückschlag. Es werden im Standard nur sehr wenige publisher/subscriber ermöglicht (2). Man kann dies zwar in der Konfiguration des Build Systems anpassen, dies sind aber weitere Hürden, die nicht leicht zu erklären sind. Zudem ist die Dokumentation sehr lückenhaft und setzt viele Kenntnisse voraus, die mir fehlen.

Ich möchte die Arbeit aber nicht nur für mich erledigen. Ich möchte das ganze in einen Stand bringen, der auch andere in die Lage versetzt, den Ardumower als Turtlebot zu steuern. Dies aber bitte ohne tiefgehende Kenntnisse von micro-ros. Ich bin der Meinung, diese Hürde ist für viele zu groß und ich bin nicht in der Lage, dies aus einem einzigen Repository zu bedienen. Ich könnte nun mit Docker anfangen, mir fehlt aber die Lust, mich da auch noch rein zu finden.

Also zurück auf "LOS" und von vorne beginnen? Zum Glück nicht ganz. Dank der bisherigen Vorarbeiten in der Ardumower Turtlebot Firmware sowie der bisherigen Ardumower ROS 2 Nodes ist es recht einfach, verschiedene Szenarien abzudecken. Ich sehe diese Optionen und bin aktuell mit der Umsetzung dran:

1. alles läuft auf dem Mower. Ein RPI ist direkt per UART mit dem Ardumower verbunden
2. einige ROS 2 Nodes (Ardumower driver, base controller) auf dem Mower (RPI) und weitere Nodes (Path planning, opencv usw.) auf einem dedizierten stationären PC
3. Ardumower mit ESP32 per UART verbunden. micro-ros auf ESP32 überwacht UART und sendet/empfängt die Daten an ROS 2 mittels einer einfachen String message. Die weitere Verarbeitung findet dann auf einem stationären System statt

Anbei ein kleines Bildchen dazu



Der ROS 2 Node "Ardumower Driver" dient zur Übertragung der UART Daten (entweder durch direkte Anbindung oder über die String Messages auf Topic /ardumower_uart_rx/tx) in eigene Ardumower Nachrichten (Namespace ardumower_msgs).
Der ROS 2 Node "Base controller" hat eine Subscription zu einigen der Ardumower Messages und überträgt diese in Standard ROS 2 Nachrichten, etwa aus dem Namespace sensors_msgs oder nav_msgs. Außerdem übernimmt der Base Controller die tf Transformation für Odometrie und IMU.

Warum macht dies der Ardumower Driver nicht direkt? Ich denke über diesen Weg halte ich Möglichkeiten offen, die Rohdaten des Mowers in anderen Nodes weiterzuverarbeiten. Ob das erforderlich sein wird, kann ich aktuell nicht sagen. Der Weg ist aber vorhanden.


Eine weitere, tiefgreifende Entscheidung ist getroffen. Ursprünglich wollte ich so viel wie möglich aus der Firmware raus nehmen. So sollten auch das Perimeter Tracking, PID Controller und Kurskorrekturen Anhand der IMU und Odometrie Daten ins ROS 2 wandern. Dies geht aus meiner Sicht aber nur, wenn die Dinge entweder auf dem lokalen RPI im Mower oder im micro-ros erledigt werden. Die Latenz über WLAN ist einfach zu groß, besonders wenn die Abdeckung im Garten lückenhaft ist. Zudem hätte das alles neu implementiert werden müssen.
Glücklicherweise kann die Azurit Firmware das ja seit Jahren und sehr stabil. Also wandern diese Dinge wieder zurück in die Turtlebot Firmware. Die Häufigkeit der ROS 2 Nachrichten kann reduziert werden (Perimeter alle 50ms vs. alle 100ms) und der Aufwand in ROS 2 beschränkt sich "nur" auf SLAM (das Thema ist komplex genug).
Damit ROS 2 den Mower zum Perimeter Tracking bekommt, wird eine ROS 2 Action erstellt. ROS 2 sendet dann die Anforderung "Tracking" und Azurit legt los. Dank IMU, ODOM und Perimeterdaten alle 100ms kann eine Cost Map des Gartens erstellt werden, welche fürs path planning dient. Eine weitere Action stoppt das Tracking wieder.

Aktuell ist es auch so, dass /cmd_vel Nachrichten (lineare- und Winkelgeschwindigkeit) vom base controller in PWM Werte übersetzt werden. Hierüber ist aus meiner Sicht keine Kurskorrektur über Azurit möglich. Dies erfolgt nach meiner Erkenntnis bisher über die Ziel -RPM der Räder. Daher werde ich dies ändern und die Ziel Geschwindigkeiten an Azurit übergeben. Das Berechnen der PWM Werte erfolgt dann hier inkl. Beschleunigungsrampen, die ich zuvor in ROS2 hatte.

Das klingt vielleicht nicht sehr spannend, es bleibt ja vieles beim Alten. Ich bin aber froh, dies für mich sortiert zu haben und eine klare Trennung zwischen Azurit und ROS 2 zu haben. Bei der Recherche ist mir glücklicherweise aufgegangen, dass andere (Kobuki also der ursprüngliche Turtlebot, Roomba, Neato) das ebenfalls so handhaben. Es gibt immer einen MCU der MEHR als nur elementarste Operationen übernimmt und eine darauf aufsetzende Software, welche den Rest übernimmt. Die einschlägigen Tutorials zu ROS und ROS 2 greifen hier einfach zu kurz und führen (aus gutem Grund), nie über Teleoperation hinaus. Ich habe mich immer gewundert, warum SLAM, path planning etc. immer nur in der Simulation, nie am realen Robot gezeigt werden. Jetzt weiß ich es.

 

[amarok12]

Hallo Patrick,

vielen Dank für Deine ausführlichen Beschreibungen. Genau das fehlt hier oft.

Ich würde Dich schon jetzt gerne unterstützen, muss aber zugeben, dass ich hier der Erstklässler bin, während Du schon das Abitur machst. Großen Respekt!

Aber ich werde versuchen, aufzuholen...

Wenn ich das richtig verstanden habe, ist Micro-Ros auf dem Arduino installiert und ist die Schnittstelle zu ROS auf dem RPI. Übrigens wäre ein NUC vielleicht (bin aber anhungslos) auch ein leistungsstärkere Alternative.

Meine Vorstellung war (ohne Vorwissen über ROS), das Mainboard 1.3 an einen RPI4 anzuschließen, welcher (RPI4) als direkte Schnittstelle zum Fahren läuft und ein NUC, ebenfalls auf dem Mower/Bot, als Subscriber die Daten mitliest und im Falle Automatikbetrieb die entsprechenden Daten ausführt und an den RPI weitergibt.

Eine Trennung zwischen einem an sich autarkem Bot und einem stationärem Rechner, der sagt, wo es lang gehen soll, macht für mich keinen Sinn. Aber das ist wohl das kleinste Problem.

Danke nochmals,
Gruß Wolfgang