Think Modular

[Gerdchen]

Eventuell wäre zum Akkuladen auch eine Konstruktion wie bei Oberleitungen mit Schleifkontakten und gespanntem Draht denkbar. Da könnte der Robi dann seitlich, oder wie auch immer ranfahren. Das würde auch die Positionierung vereinfachen, braucht nicht so exakt sein wie bei kleineren Kontakten. Edelstahldraht und kupferhaltige Kohlebürsten könnten eine denkbare Materialpaarung sein.

Oder die Kohlen sind federnd gelagert und das Gegenstück starr.

Gerdchen

[Holomino]

Sehr schön, die Ideen fließen ja. Bei den konkreten Realisierungen ist's noch nicht so prall, aber das kommt bestimmt noch.

Nichtsdestotrotz, nächstes Rätsel: Reflexe.

An Fahrzeuge baut man Bumper oder Whisker, vielleicht auch nach unten gerichtete Treppenabsturzsensoren. Ähnliche Mimiken (Drucksensoren, künstliche Haut) sind bei "Gliederfüßlern" denkbar. Allen gemeinsam: Sie lösen Reflexe im Bewegungsmodul aus. Stößt sich der Roboter das Schienbein, muss er mindestens anhalten oder sich sogar befreien, damit folgende Bewegungsanweisungen überhaupt ausführbar sind.

Wo also bauen wir die Reflexsensoren hin? Ins Sensormodul? Oder ins Bewegungsmodul?
Auch hier wieder: Bereits vorhandene Realisierungen, Ideen und respektvolle Diskussion - alles erwünscht.


Meine Meinung:
Ich habe ein quadratisches Kettenmodul, dass sich nach einer Kollision erst freifahren muss, um danach z.B. auf der Stelle wenden zu können. Bumper o.Ä. habe ich nicht, aber ich habe zwei zusätzliche Messräder mit Inkrementalgebern am Roboter, mit denen ich unabhängig vom Schlupf der Ketten die Odometrie mache.
Ob die Ketten nun vor der Wand durchdrehen oder blockieren ist egal, Kollisionen sehe ich daran, dass bei aufgedrehter Motorregelung keine Bewegung an den Messrädern erkannt wird.

Im Diskussionsansatz mit White_Fox hatte ich's ja schon angedeutet. Odometrie als innerer Regelkreis ist Sache des Bewegungsmodus. Insofern war es für mich auch keine Frage, in welches Modul die Reflexe zu implementieren sind.

[inka]

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 ...

[Moppi]

@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:

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

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?

MfG

[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