Werbung
das hier
https://youtu.be/dAIdv0qamD8
ist z.b. - zumindest würde ich es als ein modul bezeichnen - welches aus meiner RP6 ära stammt. Es diente der hindernisüberwachung und der Suche nach der ladestation (in dem Aluröhrchen ist ein standard TSOP-IR empfänger). Es kann auch auf dem servo hin und her bewegt werden. Damit war es z.b. alleine mit dem IR-sensor möglich auf 5m entfernung die richtung zur ladestation zu finden...
wenn jemand tiefer einsteigen möchte ...
gruß inka
@Holomino
Ich denke, eine Zeichnung/Verdrahtungsplan, wie man was anschließt (Fritzing?), miteinander vebindet, sagt mehr als viel Geschriebenes. Ich habe Schwierigkeiten mich rein zu denken und ich glaube, dass mir noch Informationen fehlen, um das richtig zu erfassen. So ein Verdrahtungsplan wäre gut.
Aus dem Plan geht dann hervor, wie die Hardware beschaffen sein muss, um Deine Lösung einzubinden. Wie die Software auf das Gerät kommt, ist dann erst mal Nebensache. Als Erstes würde mich dann zunächst so ein Plan mit den Mindestanforderungen interessieren (also mindestens ein Mega..., mindestens das ... beides ist dann über diese und diese Pins so und so verbunden, Sensoren oder Aktoren werden an den und den Pins angeschlossen, welche Schnittstellen werden verwendet - digitale Pins oder RX/TX oder ...).
Jetzt ist mir noch was zur Software eingefallen, als ich drüber nach dachte. Die nächste Frage für mich wäre, welche Schnittstellen gibt es. Gibt es ein API, wenn, mit welchen Funktionen (Beschreibung). Daraus kann ich mir ein Bild machen, in welchem Umfang sich die Software nutzen lässt. Vielleicht stand es schon irgendwo, dann konnte ich es noch nicht richtig erfassen.
Um etwas rein zu kommen, hier von mir eine allgemeine Übersetzung der Struktur, der Datenblöcke, die übertragen werden sollen:
Nächste Frage dazu gleich: Warum immer 4 Byte? Ich hatte jetzt erst auf 2 Byte getippt, deswegen hatte ich es eben etwas falsch, weil ich dachte Werte von 0 bis 65535 müssten ausreichend sein?Code:Offset 0: (1 Byte) CmdID Offset 1: (4 Byte) Diameter Offset 5: (4 Byte) WheelDiameter Offset 9: (4 Byte) WheelStepsPerRound Offset 13: (4 Byte) WheelDistance
MfG
Geändert von Moppi (12.11.2020 um 18:33 Uhr) Grund: Irrtum bemerkt
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.
Geändert von Holomino (14.11.2020 um 11:11 Uhr)
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).
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.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.
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.(Binärprotokoll über UART). Das sollte jede Programmiersprache und jede Hardwareplattform können. Damit fällt diese Hürde (hoffentlich).
MfG
Ich verstehe das so.Zitat von Moppi
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.
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?
Berechtigungen
Zitieren
Lesezeichen