Menü
Aktuelles
Von:
Filter

Ardumower goes ROS (robot operating system)

N

nero76

Moderator
Hello,

Ardumower is entering the world of ROS (robot operating system). ROS is a robotic platform for all kind of sensors, robots, localization and path finding algorithms. It's like LEGO for robots. If you don't know ROS, here's a start: http://www.ros.org/
Using the ROS driver I developed for the Ardumower (will publish it soon in Github) one can steer the robot (manually and via ROS path finding packages) and read it's sensors (odometry, battery, IMU, etc.) in ROS.

The (optional) ROS interface has been added in the current developer firmware (Azurit). Now the Ardumower can be used for your own experiments using the ROS platform.

Regards,
Alexander

https://www.youtube.com/watch?v=fp9pf2RoUYA
 
Hi Alexander.
Inside the mower, what kind of Platform did you use to run the ROS package or is it mandatory to have the WIFI access into all the mowing area and an external PC ?.
I try to install RVIZ into Raspberry PI 3 but can't make it run correctly , Maybe only a light ROS version ???
By.
 
Hello Bernard,
For my ROS prototyping, I'm using a laptop with i5 core on the mower (roscore, rviz, slam), and for accessing this machine remotely (only monitoring), I'm using x11vnc. I haven't looked into ROS for Raspberry yet (will do this on another day). There exist some Raspberry images with compiled ROS that others already made (example: https://github.com/ROSbots/rosbots_...bianrosopencv-image-after-youve-downloaded-it ). I'll let you know if I can find more.
Regards,
Alexander
 
Hallo Alexander,

ich habe es endlich geschafft, meinen Fork auf den aktuellen Stand zu bringen.
Ich kann den Hype um git echt nicht verstehen, das ist die mit Abstand besch... Source Code Verwaltung, die mir in den letzten Jahren untergekommen ist. Vermutlich stelle ich mich einfach zu doof an. Hast du hierzu ggf. eine schöne Anleitung für mich? Mit der Hilfe von git kommen mir nur immer noch mehr Fragen.

Jedenfalls bin ich nun up to date mit der letzten Ardumower Version und meine Anpassungen für das RMCS sind soweit drin.

Beim kompilieren meckert er aber immer, dass in der ros.h die Variable rosIdx redefiniert wird.


Code: 
// Linux ROS interface

static byte rosIdx = 0;
static String rosString;
static String rosProt;
static String rosCmd;
static String rosPar1;
static String rosPar2;
static String rosPar3;


exit status 1
redefinition of 'byte rosIdx'
Zum Vergrößern anklicken....

Ich habe alles durchsucht, kann aber keine weitere Deklaration von rosIdx finden. Woran kann das liegen? Welche Arduino Version nutzt ihr oder welche andere Entwicklungsumgebung (Eclipse?) Ich nutze Arduino 1.8.4

Muss ggf. eine weitere Bibliothek eingebunden werden? Wäre toll, wenn Du weiterhelfen kannst.

Nebenbei mal eine Frage in die Runde, wie halte ich meinen Fork am besten aktuell mit dem Master? Ich komme leider nur sporadisch dazu, weiter zu entwickeln und da dauert es schon mal ein paar Wochen, bis ich fertig bin. Bis dahin ist es aber im Master ordentlich weiter gegangen. Erstelle ich dann trotzdem einfach einen pull request von meinem Fork an Ardumower/master?
 
Hallo,
ich habe soeben noch ein paar Variablen verschoben, vielleicht hat das geholfen. Der github-Master-Zweig ist wie ein ungeschliffener Diamant (unser "Arbeitszweig"), daher wird dort nicht immer alles "rund" laufen. Ich verwende derzeit Arduino IDE 1.8.1 mit externen Editor (Notepad++). Ich bin auch kein großer Fan von "Git" und verwende das Windows Github Desktop Programm.

PS: Die ROS Launch Files / Skripte im neuen Ordner "ros" wandern noch in ein eigenes ROS-Package. Bis dahin muss ggf. noch manuell in eigene ROS Packages kopiert und angepasst werden.
Gruss,
Alexander
 
Hallo,

dann werde ich es nochmal versuchen.
Warum fließen denn alle aktuellen Entwicklungen in den Master? Wäre es nicht besser, die laufende Entwicklung in einem eigenen Branch abzuwickeln? So läuft man immer gefahr, eine nicht lauffähige Version herunter zu laden.

Noch eine Frage zum ROS und Ardumower. Wie hast Du denn die weitere Entwicklung angedacht? Soll mittelfristig die Firmware nur die elementaren Operationen ausführen und Dinge wie Navigation, Pfadplanung usw über ROS (was nach meinem Wissen nicht unüblich wäre)? Oder ist es eine nette Spielerei und Add-On, die Entwicklung geht aber an der aktuellen Firmware bzw. Sunray weiter?
Für diese Saison ist es für mich noch nicht wichtig, da habe ich noch genug an den bestehenden Mower zu tun. Für die nächste Saison könnte es aber relevant werden.

Gruß Patrick
 
Hallo Patrick,

die ROS-Schnittstelle ist optional (so ist das Ardumower PCB ausgelegt worden), nicht jeder wird die ROS-Schnittstelle nutzen wollen - es mag aber Leute geben die mehr machen wollen (RTK, LiDAR, SLAM, coverage planning, path planning, virtual fences) und für diese Leute kann so eine Experimentier-Schnittstelle bestimmt nicht Schaden :) ROS-Experimente die sich als sehr gut funktionierend erwiesen haben, lassen sich z.B. in den Ardumower Code einbauen.

Gruss,
Alexander
 
Hallo Alexander,

ich muss nochmal auf das ROS zurück kommen. Im Wiki ist ja das RMCS beschrieben, welches ich gerade in meinem Fork implementiere. Ich habe mir nun die Teile vom ROS angesehen, die bereits implementiert sind und habe festgestellt, dass es ziemlich identisch ist.

Meine bisherige RMCS Schnittstelle ist ebenfalls optional und kann per Parameter ein/ausgeschaltet werden.

Nun meine Frage, sollen wir das RMCS fallen lassen und statt dessen auf die von Dir für das ROS implementierte Struktur zurückgreifen? Mit dem Ardumower Control Center auf Basis von Node-Red bin ich ziemlich weit gekommen. Ich lese hier ziemlich alle Sensordaten über die serielle Konsole aus. Der Aufwand, dies von den bisherigen RMCS Kommandos ($RMMOT, $RMSON usw) auf die $ROS-Infostruktur umzubauen ist nicht so wild.

Die Anzeige der Sensordaten ist soweit fertig, offen ist noch die Steuerung des Roboters direkt, also Fahrbefehle, Mähmotor an/aus, Home, Track, Off usw.
Damit wollte ich jetzt anfangen, habe aber gesehen, dass dies für ROS schon fertig ist(?). Damit fehlt letztlich nur noch ein schickes Canvas control zur Steuerung.
Zuden ist noch das Auslesen der Ardumower Konfiguration offen, also welche Sensoren sind verbaut. Im Control Center will ich nur die anzeigen, die auch verbaut sind. Hat jemand kein Sonar, brauche ich keinen Platz für die Sonarwerte zu verschwenden.

Hast du sowas für ROS vorgesehen? Gibt es ggf. eine Schnittstellendefinition ähnlich dem RMCS, auf das wir uns einigen können? Bernard ist auch an einem solchen Protokoll dran, es wäre ziemlich doof, wenn wir drei je parallel an der gleichen Ecke schrauben.

Gruß Patrick
 
I think one of the best reasons to use ROS is the ability to tie together multiple ardumowers in the same workspace. Another huge benefit I see is that you could generate collision models ahead of time (URDF) and have that visualized in Rviz as well as accessible to 2D planners. Finally I think the ability to collect and replay data using rosbag files would be amazing, especially when training classification algorithms in the future as well as the whole simulation aspect. It will speed up our collective development and attract new people to this project!

Thank you for porting to ROS! I havent had a chance to check out the repo, but what version are you supporting? Kinetic?
 
Hallo,

ich muss nochmal auf ROS zurück kommen. Das Thema interessiert mich wirklich und ich überlege, ob ich da nicht mal selbst ran gehe. Da gibt es für mich zwar irre viel zu lernen, aber das macht es ja auch interessant.

Ich habe mich nun ein wenig eingelesen und die erste Idee reift in mir. Bevor ich nun einfach drauf los lege und meine Zeit verschwende, möchte ich mal nach dem aktuellen Stand fragen.
Ich habe gesehen, dass es einen eigenen ROS Treiber für den Ardumower gibt und dass hier über ein separates Nachrichtenformat die Informationen ausgetauscht werden.

Gibt es dazu einen driftigen Grund? Ich hätte es mit dem rosserial Paket versucht und dann über publish/subscribe Nachrichten ausgetauscht. Das ist jedenfalls das Vorgehen, dass ich häufig gelesen habe. Alexander scheint aber einen anderen Weg gewählt zu haben und hat sicherlich auch einen guten Grund gehabt, mir aber nicht klar welchen.

Was kann die aktuelle ROS Schnittstelle bereits?

Meine Grundsätzliche Idee sieht etwa so aus:
- ROS auf RPI laufen lassen
- Kommunikation mit dem Mower über rosserial, entweder direkt über USB oder ggf. per WLAN.
- eigene Firmware für den Mower nutzen, dazu Azurit klonen und aufräumen
- neue Firmware führt nur elementare Operationen aus, etwa Sensoren lesen, Fahren, Perimeter tracken
- wird ein Sensor getriggert, hält der Mower selbstständig an und sendet das Ereignis an ROS. Hier wird dann entschieden, wie es weiter geht
- über eine Art Heartbeat (Message) zwischen den beiden wird sichergestellt, dass der jeweils andere noch da ist. Fällt einer aus, stoppt der Mower

Soweit die Theorie. Auf eure Kommentare freue ich mich, das Thema ist arg neu für mich und da bin ich schnell auf dem Holzweg.
 
Hallo nochmals von meiner Seite,

ich habe gesehen, dass die ROS Pakete im Git Repository vor nicht all zu langer Zeit geändert wurden. Was genau ist denn bereits mit dem ROS Treiber möglich, bzw. was wurde bereits realisiert? Ich beginne gerade erst, mich mit ROS zu beschäftigen. Zwei Dinge beschäftigen mich akut:

1. welche IDE verwendest Du? Eclipse, RoboWare, RDS oder was ganz anderes?
2. Du verwendest eine eigene Nachricht, die über die Serielle Konsole an den PC/RPI geht. Die Nachricht ist ein CSV String und enthält alle Sensorwerte. Alle Tutorials, die ich bisher gesehen habe, verwenden das rosserial Paket und senden vom Arduino direkt an das jeweilige Topic. Warum hast Du es anders gelöst? War der Grund nur, um wenig im Azurit zu ändern oder gibt es da andere Gründe?

Es wäre nett, wenn Du einen kurzen Zwischenstand aufzeigen könntest.

Grüße
Patrick
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Oben