Schön! Nicht? Und Dein Vorschlag dazu?Zitat von Holomino
MfG
Mein Vorschlag: Wir kauen hier ganz simpel weiter Module und Schnittstellen anhand bereits realisierter Lösungen und zukünftigen Anforderungen (Ideen) durch. Der Ton ist respektvoll, also ist alles im grünen Bereich.
Ich sehe in meinem Job als TO auch nicht mehr, als ab und zu mal einen neuen Schnipsel einzuwerfen. Die Entscheidung, das Konzept zu prüfen und vielleicht etwas draus zu machen, liegt bei Euch.
Geändert von Holomino (12.11.2020 um 11:31 Uhr)
Ach, ich war schon verwundert!
Hmm ... weiß nicht. Ich hatte schon begonnen, mir Gedanken zu machen. Ich dachte schon dieser Beitrag sei weg. Dazu gab es keinen Anschluss. Ich fände es dann nicht schlecht, auf die einzelnen Dinge auch einzugehen.
MfG
-----------------
etwas ab vom Thema:
Ich habe mir die Struktur hier noch mal angesehen und mit dem verglichen, was schon geschrieben wurde.
Es gibt das Forum: Tausche Dich aus und Suche Unterstützung für deine Projekte!
Es gibt das Wiki: Lass dein Wissen und deine Schaltungen auch anderen zukommen.
Es gibt Mikrocontroller-Elektronik: Frei verfügbare Projekte, Schaltpläne, Stücklisten unter einer CC-Lizenz.
Ich versuche mich danach zu richten. Schaue aber auch, was sich woanders noch für Möglichkeiten auftun.
Den Teil mit den Programmierwerkzeugen/-sprachen mag ich Dir gerne kommentieren:Ach, ich war schon verwundert!
Hmm ... weiß nicht. Ich hatte schon begonnen, mir Gedanken zu machen. Ich dachte schon dieser Beitrag sei weg. Dazu gab es keinen Anschluss. Ich fände es dann nicht schlecht, auf die einzelnen Dinge auch einzugehen.
Wenn ich ein LidarLite einsetze, habe ich keine Ahnung vom internen Ablauf in FPGA und Controller. Nach außen bildet es eine Schnittstelle.
Wenn Du von mir ein Platinenlayout und ein HEX-File zum brennen des Controllers bekommst, kann es Dir egal sein, ob ich das Programm in C, C++, Basic oder Assembler geschrieben habe, solange Du Deine Anforderungen vollständig erfüllt siehst. I2C/UART oder andere Protokolle sprechen keine Programmiersprache. Sie sprechen Bytesch.
Dieser Thread bietet Dir in erster Linie die Möglichkeit, selber Anforderungen zu definieren, mit den Anforderungen anderer zu vergleichen, zu Strukturieren, Gemeinsamkeiten zu finden und Hürden zu überbrücken.
Eine Hürde ist die Programmiersprache. Eine mögliche Brücke ist eine Schnittstelle.
Geändert von Holomino (12.11.2020 um 13:21 Uhr)
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.
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.
Berechtigungen
Zitieren
Lesezeichen