Think Modular

[Holomino]

Bezüglich der Datenstruktur:
Als Europäer habe ich mein System (hier Fahrzeugdurchmesser, Radabstand, Raddurchmesser, an anderer Stelle Sensorauflösungen, ...) auf mm parametriert. Es könnten aber auch inch oder cm sein. Letztlich wichtig. Größen und resultierende Posenberechnungen sind aufgrund der unterschiedlichen Einheitengenauigkeit (Den Radabstand nur in ganzzahligen inch angeben zu können, schränkt die Freiheiten ein) Fließkomma.
Sicher nicht ganz offensichtlich, dass bei der Anzahl der Inkremente pro Umdrehung (WheelStepsPerRound) ein Inkrementalgeber mit 50 Steps/Round direkt am Motor mit anschließendem Getriebe 13:25 eben kein ganzzahliges Verhältnis ergibt. Also auch hier eine Fließkommaangabe.

Letztendlich die Frage: Macht das die Schnittstelle nicht unnötig fett? (White_Fox)
Meine Antwort: Bei mir nicht. Trotzdem das Bewegungsmodul bei mir gleichzeitig noch Durchreiche für Sensorik und Powermodul ist, also 4..6kB/s an Daten emittiert und 2..3kB/s eingehende Daten verarbeitet, langweilt sich mein Controller bei 60% Prozessorlast. Auch deshalb baue ich modular.

[Holomino]

Ist schon Advent? Darf ich schon "Zeit für ein neues Türchen" sagen?

Das Settings-Türchen
Gut, dass Moppi auf diese Struktur zurückgekommen ist. Sie wird vom Bewegungsmodul zur Posenberechnung verwendet. Vielleicht kann man sie als Betriebsparameter bezeichnen. Ähnliche Dinge sind bei mir Regelparameter für Antriebsmotoren, Kalibrierungsdaten im Powermodul, Einstellungen für den Lidarbetrieb,...
Kurz: Alles Parameter, die für die Inbetriebnahme eines Moduls wichtig sind und bei mir im EEPROM des jeweiligen Controller landen.

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.

Diese Unterteilung bezogen z.B. auf mein Powermodul:
Allgemein:
- Wir hatten weiter oben gesagt, eine Nachricht über den SOC ist allgemein wichtig, um die Restreichweite einbeziehen zu können.
- Rückmeldung "an Ladestation angedockt"
- Der Befehl Laden ein-/ausschalten
- Befehl "ganzes Teil abschalten" (z.B. für den Transport)

Spezifisch bei mir:
- Monitoring
- Ladeparameter
- Kalibrierungsdaten
- Andock- und Abschalteinstellungen


So sehen die spezifischen Einstellungen bei mir in der GUI aus. Das ist C#, also für den einen oder anderen hier eine Hürde. Das Protokoll dahinter ist Bytesch (Binärprotokoll über UART). Das sollte jede Programmiersprache und jede Hardwareplattform können. Damit fällt diese Hürde (hoffentlich).

[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