Think Modular

[Moppi]

Frage: Was hat das aber mit dem modularen Aufbau zu tun? Die o.g. Struktur kann man doch im Hexapoden nicht anwenden?!
Antwort: Kann man nicht. Wenn ich von jemand anderem ein Bewegungsmodul verwenden will, benötige ich eine allgemeingültige Bewegungsmodulschnittstelle, in der unter Anderem auch die Bahnverfolgungsfunktion sitzt und zusätzlich eine Schnittstelle zum parametrieren des spezifischen Moduls.

Dafür muss man einen passenden Wrapper haben. Vom Prinzip wird jeder Roboter irgendwie in die vier Himmelsrichtungen gesteuert. Dann kommt vielleicht noch "oben" und "unten" dazu, falls man das benötigt (der Roboter kann Hindernisse ja auch selber überwinden). Also bräuchte man einen teilautonomen Roboter, der dann noch Anweisungen benötigt, welche Richtung er wie weit gehen soll. Einfach ausgedrückt.

(Binärprotokoll über UART). Das sollte jede Programmiersprache und jede Hardwareplattform können. Damit fällt diese Hürde (hoffentlich).

Wenn die Datenpakte entsprechend beschrieben sind. Ich kenne das nur als Tabelle, zum Beispiel bei WAV-Dateien oder Byteblöcke, die an einen bestimmten Port übertragen werden müssen (Soundkarte). Und darin wird eben immer für jeden Parameter angegeben der Offset in den Daten, die Datengröße (Byte, Word etc.) und die Beschreibung, zum einzelnen Parameter. Das ist dann allgemein gülig. Wie man das dann in Assembler oder in C++ erstellt (früher auch viel Pascal), ist eine andere Frage.

MfG

[Gerdchen]

Dafür muss man einen passenden Wrapper haben. Vom Prinzip wird jeder Roboter irgendwie in die vier Himmelsrichtungen gesteuert. Dann kommt vielleicht noch "oben" und "unten" dazu, falls man das benötigt (der Roboter kann Hindernisse ja auch selber überwinden). Also bräuchte man einen teilautonomen Roboter, der dann noch Anweisungen benötigt, welche Richtung er wie weit gehen soll. Einfach ausgedrückt.

MfG

Ich verstehe das so.
So ähnlich, wie beim Fly-by-Wire. Da wird dem Flieger ja auch nur gesagt, wo er langfliegen soll. Wie er das macht und auf Störungen reagiert ist dann Sache der dahintersteckenden Technik.

[Holomino]

Zusammenfassung bis hierher:
- Ein Modul hat eine bytebasierte Schnittstelle und ist programmiersprachenunabhängig.
- Ein Modul muss unterschiedliche Datenblöcke (Telegramme) empfangen und versenden können. Inhalte und Länge eines "Telegramms" sind telegrammtypbezogen.
- Deshalb muss man ein Telegramm identifizieren können. Eine Kennung (CmdID) muss her.

Für Menschen, die noch nie eine Vernetzung zwischen zwei Controllern (oder Controller und PC) praktisch aufgebaut haben (das ist keine Bildungslücke, viele angewendete Protokolle schmeißen unvollständige Daten einfach weg, ohne den Grund zu nennen. Als Anwender hat man von XML bis Binär nur selten die Gelegenheit, in den APIs die Parse-Bedingungen nachzuvollziehen). Es gibt zusätzliche Anforderungen:
- Übertragbarkeit: Kann ich ein Protokoll zwischen zwei Controllern auswerten? Kann ich das auch z.B. zwischen Controller und PC?
- Störsicherheit: Was passiert bei einer Störung? Was passiert, wenn z.B. ein Sender sendet. während ich den Empfänger flashe oder neu starte? Wie synchronisiert sich ein Empfänger nach einer Störung anhand des Protokollrahmens neu?

Finger hoch: Wer hat so ein Protokoll? Wie sieht der Rahmen aus? Synchronisiert sich das Protokoll nach einer Störung automatisch?

[Defiant]

Finger hoch: Wer hat so ein Protokoll?

Darf ich die offensichtliche Antwort verlinken?

Bevor ich einen Thread à la "Think modular - Versorgung ohne Sorgen" eröffne, würde ich hier doch gerne noch erfahren, was Du (und andere) so an Plänen oder Realisierungen zu diesem Thema am Start hast (haben).

Meine Lösung ist relativ simple gehalten und hier beschrieben. Ist etwas von meinem Staubsaugerroboter abgeguckt.

[Moppi]

Übertragbarkeit: Kann ich ein Protokoll zwischen zwei Controllern auswerten? Kann ich das auch z.B. zwischen Controller und PC?

Hierzu kommt mir sofort in den Sinn, Datenblöcke so einfach wie möglich zu gestalten, auch so, dass sie schnell verarbeitet werden können.
Hierzu zähle ich persönlich auch die Datentyp-Größe in Bit. 4 Byte große Fließkommawerte sind schon gewaltig. Ich handhabe das immer so, dass ich schaue, was wirklich benötigt wird (vielleicht noch etwas Reserve). Ein Controller, der einen Schrittmotor ansteuert oder einen Servo, benötigt kein Fließkomma. Das muss erst umgerechnet werden. Das wiederum kostet nicht nur Rechenzeit, sondern am Ende auch Energie. Solche Operationen sollten nur ein Mal an zentraler Stelle, erledigt werden. Bei Universaldaten, wo man nicht sicher ist, ob der Empfänger vielleicht doch zunächst mit Nachkomma arbeitet, ist die Frage immer, wieviele Nachkommastellen sind nötig um ein Ergebnis zu bekommen, dass genau genug ist. Heißt: wenn am Ende eine Nachkommastelle genügen würde, um ein Ergebnis zu bekommen, was genau genug ist (weil ich eine Motorsteuerung doch irgendwo nur mit Werten von 0 bis 255 füttere), warum soll ich dann mehr schicken? I.R. genügen 2 oder 3 Nachkommastellen. Bei 2 Byte / 16 Bit, kann ich Werte von -32767 bis +32767 abbilden. Das könnten auch sein: 3.2767, 32.767, 327.67, 3276.7 Bei 3 Byte sind das -8388607 bis + 8388607 (8.388607 bis 838860.7; bei 3 Nachkommastellen: +/-8388.607). Wie die Werte zu interpretieren wären, hängt dann von der Block-ID (CmdID) ab. So kann man auch unterschiedliche Datentypgrößen, für unterschiedliche Zwecke, verwenden. Ich will nur meine Sicht darstellen, vielleicht lohnt es sich drüber nachzudenken, ich will nicht nörgeln.

Störsicherheit: Was passiert bei einer Störung? Was passiert, wenn z.B. ein Sender sendet. während ich den Empfänger flashe oder neu starte? Wie synchronisiert sich ein Empfänger nach einer Störung anhand des Protokollrahmens neu?

Als Grundlage vielleicht: http://152.96.52.69/webMathematica/c...5/node183.html

Als Protokollrahmen nehme ich mal die Hardwarekommunikation (per serieller Schnittstelle oder I2C z.b.). Bei Sender und Empfänger verwende ich bisher immer einen Timeout. Ist vielleicht nicht unbedingt die zeitsparendste Variante, aber wenn keine Fehler bei der Übertragung auftreten sollten, durchaus rel. einfach umzusetzen: wenn eine Seite mit der Kommunikation nicht klar kommt, wartet die dann einfach eine bestimmte Zeit, bis die Gegenseite in einen definierten Zustand zurück fällt. Die Kommunikation kann dann neu begonnen werden.

Wer hat so ein Protokoll?

So weit ich das bei meinen Anwendungen sehe, ist dass immer von der jeweiligen Schnittstelle abhängig und wie dann die Kommunikation aufgebaut ist, also individuell.
Ich komme hier mit den Begriffen "Protokoll" und "Protokollrahmen" noch nicht zurecht. Universalprotokolle und -protokollrahmen kenne ich (auf Hardwareebene) nicht, das sind ja dann irgendwie immer Wrapper, die zusätzliche Rechenzeit benötigen. Wrapper auf niedrigen Ebenen führen zu erhöhten Hardwareanforderungen (schnellere CPUs, mehr Speicher, mehr Energiebedarf = "größere" Akkus und / oder geringere Laufzeit, bis zum Nachladen des Hauptenergiespeichers)

Bei dem oben verlinkten Text zu "ROS" steht es so ähnlich auch drin:
"Er skizziert die angestrebten Anwendungsfälle sowie deren Anforderungen und Einschränkungen. Darauf aufbauend wird die entwickelte Middleware-Schnittstelle erläutert."



MfG

[Holomino]

Darf ich die offensichtliche Antwort verlinken?

Natürlich darfst Du das. Und Du darfst auch weiterhin die Vorteile bezüglich ROS lobpreisen.

Der Link löst aber mein Problem nicht. Ich halte ein Stück selbstgebaute Hardware mit UART in der Hand. Da muss ich mich entscheiden, welchen Protokollrahmen ich verwende. Nehme ich vielleicht z.B. sowas (Seite 2)?
Synchronisiert sich dieses Protokoll bei Störungen? Ich sitze hier im Graben und fummel am Code meines Moduls rum. Ich progge den Controller ab und zu neu. Das unterbricht zwar die Daten, aber die Verbindung nicht. Ich hab auch keine Lust, nach jedem Neuproggen die Gegenstelle zu rebooten. Da muss also (auf beiden Seiten) was her, was unterbrochene Telegramme wegschmeißt. Je schlanker, desto besser. Meine Ressourcen auf dem Controller sind begrenzt.

[Defiant]

Das mit dem "darf" war jetzt nicht so wörtlich gemeint. Ich habe nur das Gefühl ich gehe euch ein wenig damit auf die Nerven.

Der Link löst aber mein Problem nicht. Ich halte ein Stück selbstgebaute Hardware mit UART in der Hand.

ok, klingt nach einem Job für rosserial (Nur ROS1). Wobei ich selber allerdings ein eigenes einfaches i2c-Protokoll zur Kommunikation mit meinem µC verwende. Der Neustart der ROS-Node die die I2C-Hardware an das ROS-Ecosystem anbindet muss ich dann zwar manuell neustarten, aber das stört mich nicht hinreichend genug um das zu ändern. Geht ja auch hinreichend schnell, da alle anderen Nodes weiter laufen können. Theoretisch könnte ich auch einen automatischen Restart bei Bus-Fehlern einbauen..
Mir persönlich war rosserial zuviel Overhead zum Einsatz auf einem 8-Bitter.


Der Vollständigkeit halber: Bei ROS2 wurde rosserial durch micro-ROS abgelöst. Das braucht aber wohl "größere" µC wie einen ESP32. Ich denke nicht, dass es auf einem AVR lauffähig ist. Ich habe keine Erfahrungen mit micro-ROS.

Update: Hier gibt es was mit micro-ROS auf Arduino: https://discourse.ros.org/t/micro-ros-on-arduino/17009