Think Modular

**Gerdchen** · 11.11.2020, 19:14

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** · 12.11.2020, 10:09

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.

**Moppi** · 12.11.2020, 10:41

Zitat von Holomino

Sehr schön, die Ideen fließen ja.

Schön! Nicht? Und Dein Vorschlag dazu?

MfG

**Holomino** · 12.11.2020, 10:55

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.

**Moppi** · 12.11.2020, 11:53

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.

**Holomino** · 12.11.2020, 12:53

Zitat von Moppi

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.

Den Teil mit den Programmierwerkzeugen/-sprachen mag ich Dir gerne kommentieren:
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.