Menü
Aktuelles
Von:
Filter

Robot Mower Communications Standard

N

nero76

Moderator
Gut!

Wir müssen uns noch ein "Robot Mower Communications Standard (RMCS)" ausdenken womit andere Geräte (Raspberry/Android/PC) einen Rasenroboter steuern können. Wir haben ja bisher nur das pfodApp Protokoll zur Fernsteuerung. Falls noch mehr Geräte gesteuert werden sollen müssten getrennte Leitungen verwendet werden. Die Hardware-Schnittstelle wird dafür in erster Linie seriell (bzw. seriell über USB) sein. Als Nachrichten-Format kämen z.B. Industriestandards wie NMEA 0183, SAE J1939 oder ein proprietäres Nachrichten-Format in Frage. Hat jemand Vorschläge für ein konkretes Nachrichten-Format? Bisher habe ich nur proprietäre Nachrichten (ähnlich NMEA 0183) prototypisch umgesetzt.

Anfrage-Nachrichten (REQUEST) sind z.B.:
-Konfiguration des Mähroboters abfragen (Welche Sensorik ist vorhanden)
-Fahrbefehl (Drehe um Grad x und fahre dabei Geschwindigkeit y RPM)

Antwort-Nachrichten (ANSWER) sind z.B.:
-Konfiguration des Roboters (Welche Sensorik ist vorhanden)
-Aktueller Status (Sensorik)

Die Nachrichten sollten möglichst abstrakt sein und die Anzahl kurz gehalten werden und sich nicht auf einen bestimmten Rasenroboter konzentrieren.
 
Gut!

Wir müssen uns noch ein "Robot Mower Communications Standard (RMCS)" ausdenken womit andere Geräte (Raspberry/Android/PC) einen Rasenroboter steuern können. Wir haben ja bisher nur das pfodApp Protokoll zur Fernsteuerung. Falls noch mehr Geräte gesteuert werden sollen müssten getrennte Leitungen verwendet werden. Die Hardware-Schnittstelle wird dafür in erster Linie seriell (bzw. seriell über USB) sein. Als Nachrichten-Format kämen z.B. Industriestandards wie NMEA 0183, SAE J1939 oder ein proprietäres Nachrichten-Format in Frage. Hat jemand Vorschläge für ein konkretes Nachrichten-Format? Bisher habe ich nur proprietäre Nachrichten (ähnlich NMEA 0183) prototypisch umgesetzt.

Anfrage-Nachrichten (REQUEST) sind z.B.:
-Konfiguration des Mähroboters abfragen (Welche Sensorik ist vorhanden)
-Fahrbefehl (Drehe um Grad x und fahre dabei Geschwindigkeit y RPM)

Antwort-Nachrichten (ANSWER) sind z.B.:
-Konfiguration des Roboters (Welche Sensorik ist vorhanden)
-Aktueller Status (Sensorik)

Die Nachrichten sollten möglichst abstrakt sein und die Anzahl kurz gehalten werden und sich nicht auf einen bestimmten Rasenroboter konzentrieren.
 
Hi,

ist denn das ROS Framework bekannt ?
Dort hat man sich zu dem Thema Messages für Bots schon sehr viel Gedanken gemacht http://wiki.ros.org/std_msgs
Hier verwendet man cmd_vel um eine Schildkröte zu steuern http://www.robopgmr.com/?tag=rostopic
ein Steuerkomand für die Bot Basis sieht dann so aus
l i n e a r :
x : 2.0
y : 0.0
z : 0.0
angular :
x : 0.0
y : 0.0
z : 0.0

Und hier eine Umsetzung über seriell auf arduino (ist vielleicht noch nicht super stabiel)
http://wiki.ros.org/ros_arduino_bridge?distro=indigo
 
Ja, danke - schau ich mir mal genau an - wir wollen hier aber kein Monster züchten sondern eine ganz einfache Schnittstelle die alle Belange eines Rasenmähers abdeckt denke ich (es muss mit ein paar Zeilen Code am Arduino umzusetzen sein?) :)

Hier ist mal ein ganz grober Entwurf:
http://wiki.ardumower.de/index.php?title=Robot_Mower_Communications_Standard
 
Wenn ihr mehrerer Geräte an die Serielle Schnittstelle anbringt, wie erfolgt dann die Steuerung. Gibt es einen Master und alles andere sind Slaves? Sagt der Master dem Slave, du darfst jetzt senden und der Slave sendet wohin er will oder nur zum Master? Wie sollen die einzelnen Komponenten diesbezüglich zusammenarbeiten?
 
Also die ROS-Arduino-Bridge scheint mir zu einfach gehalten für uns: https://github.com/hbrobotics/ros_a...braries/ROSArduinoBridge/ROSArduinoBridge.ino
Es wird dort nur eine Nachricht für den Motor umgesetzt (linker/rechter Motor: target ticks per frame). Diese habe ich übernommen. Weitere Nachrichten für die Sensorik habe ich ergänzt.

Es fehlt bestimmt noch einiges aber damit kommt man bestimmt schon weiter:
http://wiki.ardumower.de/index.php?title=Robot_Mower_Communications_Standard
 
Roland schrieb:
Wenn ihr mehrerer Geräte an die Serielle Schnittstelle anbringt, wie erfolgt dann die Steuerung. Gibt es einen Master und alles andere sind Slaves? Sagt der Master dem Slave, du darfst jetzt senden und der Slave sendet wohin er will oder nur zum Master? Wie sollen die einzelnen Komponenten diesbezüglich zusammenarbeiten?
Zum Vergrößern anklicken....

Mein Vorschlag: Um die Sache zu vereinfachen würde ich sagen für jeden Slave muss eine eigene Schnittstelle verwendet werden? Der Master weiss also mit wem er redet. Der Slave darf ohne Aufforderung senden. Dadurch dürfte sich die Latenzzeit für einige Echtzeit-Daten (z.B. Nachricht 'Robot state event' oder 'Robot sensor data event') verringern.

Es geht also primär um eine Steuerungsschnittstelle für den ganzen Roboter, nicht für die Einzelkomponenten.
 
Zuletzt bearbeitet von einem Moderator:
Das Protokoll ist dazu gedacht einen Rasenroboter zu steuern. Die Kommunikation sollte also zwischen Raspberry/Android/PC und dem Main PCB stattfinden. Wir haben ja bisher nur das pfodApp Protokoll zur Fernsteuerung. Falls noch mehr Geräte gesteuert werden sollen müssten getrennte Leitungen verwendet werden. Wäre das so sinnvoll?
 
ja ROS ist nicht immer zielführend aber man hätte eben gleich mal gratis Diverse Implementierungen für alles was man noch so an den Bot flanschen, simulieren berechnen will...

Dein Protokoll Vorschlag ist schon sehr weit. Ich würde nur hoffen der "Master" muss nicht wissen an welcher Schnittstelle (LAN, Seriell, Bluetooth, SPI ....) was genau welche Nachricht schickt. Spätestens bei zwei Clients müsste mindestens eine Kennnung rein welchen Type und am Besten eine UID der Client hat.
 
Ach so, das steht ja sogar in deinem ersten Satz :lol: Irgendwie hatte ich das anders interpretiert. Ich dachte, es geht um die Kommunikation der einzelnen Komponenten im Ardumower. Wie ich es nun verstehe ist, dass du eine höhere Logik (im folgenden mit PC tituliert) hast, die den Roboter dann steuert oder Daten von diesesm abruft?

Ich halte einen Telegramm-basierten Datenaustausch auch für Sinnvoll.

Was mir aktuell in http://wiki.ardumower.de/index.php?title=Robot_Mower_Communications_Standard fehlt ist,
wer sendet welches Telegramm und wie soll ein Senden dann initiiert werden? Ihr seid hier schon auf die Inhalte der Messages eingeganen, aber der globale Überblick fehlt mir um dies besser zu verstehen. Was ist trigger und data?

Beispiel:
Robot sensor data event (sensor values)
Unter der Annahme, dass hier der Master Sensordaten zum PC schicken soll, wie initiiert der PC dieses oder sollen ständig Daten geschickt werden?

Was ich aktuell auch nicht verstehe ist der Satz:
ID: device ID (the destination of a command message or source of an event message) - examples: RM (robot mower), DW (ranging beacons),
Sind die ranging beacons außerhalb des Mowers? Dann sind diese wie du beschrieben hast mit einer zweiten Leitung angeschlossen?


Wie ich es verstanden habe, verwendet der NMEA 0183 80 druckbare Zeichen. Das hat den Vorteil, das man die gesamte Übertragung mitlesen kann, was gut für das Debugging ist, zum anderen werden aber auch mehr Daten dadurch über die Leitung geschickt als wirklich notwendig.
Ich habe bei meinem PerimeterSensorboard noch eine 8bit Checksumme rangehängt, um zu überprüfen, ob die Daten auch wirklich integer sind.

Auf einer etwas höheren Ebene betrachtet müssten aus meiner Sicht mindestes folgende Möglichkeiten bestehen:

Telegramm/Message PC->Master:
BehaviourCommand //start,stop,dock
ChangeConfigurationData // Für Parametertuning und Zeitprogrammierung
DataRequestCommand // Schick mir bestimmte Daten einmal oder kontinuierlich. Z. B. PerimeterAmplitude, BatVoltage, EncoderCounts, ...
ActivateEvent // Hiermit kann ich Events einschalten, die der Master bei eintreten zum PC schicken soll. (Bumper, Perimeter, LowBat, ...)

Telegramm/Message Master->PC:
Event // Ein Ereignis tritt im Ardumower auf und wenn mit ActivateEvent konfiguriert, wird es zum PC gesendet.
RequestedData // Angefragte Daten werden zum PC gesendet. Einmal oder kontinuierlich.
Error // Es ist ein Fehler aufgetreten oder Daten wurden bei Übermittlung verfälscht.
ACK // Acknowledge
 
Danke Euch beiden - ich werde die Vorschläge versuchen umzusetzen und den Entwurf dahingehend verbessern. Wäre doch Klasse wenn wir ein Protokoll hinbekommen welches später viele verwenden können.
 
-Checksum hinzugefügt
-hinzugefügt: "There are command and event messages. Command messages are received by the robot, event messages are sent by the robot. ID: device ID (the destination of a command message or source of an event message"
-UID: verstehe ich als Session-Nummer, Beispiel: Benutzer A (Android) verbindet sich und dann kommt noch Benutzer B hinzu (Raspberry) und beide wollen den Roboter überwachen oder steuern. Muss man sich überlegen inwieweit das sinnvoll ist. Bei vielen Implementierungen wird der erste Benutzer "rausgeworfen"
-Beacons: Können vom Mower (Main PCB) zur Ortung empfangen werden (optional) - ID korrigiert (RMBEA) da ja ebenfalls vom Mower versendet
-Sensor data: Zusammenfassung aktueller Sensorwerte
-Trigger data: Zusammenfassung aktueller Triggerwerte (Trigger-Zähler)
-Frequenz für "Sensor data" bzw. Aktivierung/Deaktivierung von "Trigger data" ist sinnvoll. Nachrichten zusammenfassen denke ich ist ebenfalls sinnvoll? Oder für jeden Sensor einzelne Nachrichten. Da man in der Regel alle Sensoren abfragen möchte dachte ich mir alle zusammenfassen zu einer Nachricht
 
-"ChangeConfigurationData": bin ich mir nicht sicher ob wir das alles mit dem Protokoll erschlagen können/wollen, da die Roboter teilweise sehr unterschiedlich eingestellt werden (allein schon der Ardumower von Version zu Version) - wünschenswert wäre es, aber nicht mal beim GPS haben sie dafür ein gemeinsames Protokoll hinbekommen? Vielleicht lieber offen lassen als "propriertäre Nachrichten"?
 
Hi,

Mit UUID meinte ich einfach eine Zufallszahl, die sich nicht mehr ändert um z.B. zwischen mehreren Bumper Sensoren unterscheiden zu können, die alle nur Bumper heissen


Und hier noch ein Framework

Johnny-Five API

schon bekannt ?
...bin da wegen der Control Center Sachen drauf gestoßen...

Finde es immer schön nicht ganz so from Scratch an zu fangen, auf der anderen Seite ist das Protokoll von Alexander schön schlank

Gruß,
Volker
 
Hallo,

MQTT würde sich anbieten. Sehr einfache aber flexible Syntax und für ESP8266 gibt es bereits Bibliotheken. Ist als Protokoll für Systeme wie Arduino oder ESP gedacht. Lässt sich in Systeme wie openhab problemlos einbinden.
Ich könnte mir vorstellen das man die Syntax aus dem Ardumower ohne grosse Änderungen fast 1:1 in MQTT-Messages übernehmen könnte.

Gruß
Peter
 
Beispiel wie das im MQTT-Format aussehen könnte:
/ID/MSG als MQTT-Topic und data in den Message-Teil.
ID und MSG wie in http://wiki.ardumower.de/index.php?title=Robot_Mower_Communications_Standard angegeben.
ID könnte z.B. die letzte Stelle der IP-Adresse des ESP-Moduls sein.

Da MQTT durch "/" getrennte, einfache Hierarchien erlaubt könnte man die Commands und Events voneinander trennen, wenn man will.
"data" können Zahlen oder Strings sein.

Paralleler Empfang und Senden (Notifications) ist vorgesehen.

Einziger Nachteil: Punkt-zu-Punkt-Kommunkation könnte schwer sein. MQTT setzt einen "Broker" voraus, z.B. Mosquitto auf Raspberry.
Dafür sind die Clients (Ardumower) wirklich einfach zu realisieren,.

Gruß

Peter
 
CANOpen hätte schon was aber ich glaube die Komponenten sind teilweise recht teuer.
MQTT erfordert wohl immer ein Netzwerk um über einen Broker sprechen zu können und hat keinen Standard für Datenformate
Ich nehme mal an es geht nur drum z.B. über einen RaspBerry auf Arduino(bisher nur einer) zugreifen zu können.

da werfe ich doch noch mal firmata ins rennen. Ist ein an Midi angelehntes Protokoll, daß es als lib für den Arduino und auf Hostseite für fast alle Programmiersprachen gibt
https://www.arduino.cc/en/reference/firmata
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Oben