Think Modular

[Moppi]

"Holomino? Du musst doch wissen, wann der Akku so weit leer ist, dass Du noch sicher die Ladestation erreichen kannst, wie machst Du das denn jetzt?"
Das kann man über die Akkuspannung messen. Das machen Ladegeräte auch so. Sie bestimmen über die Spannung den Ladezustand des Akkus.

Tatsächlich war meine Frage an Holomino gerichtet, um zu erfahren, wie er das zurzeit macht. Ohne mit irgendwelchen Ideen vorpreschen zu wollen. Ich verstehe das auch nicht so recht, ich kann mir nicht vorstellen, dass er fährt, ohne die Akkuspannung zu messen. Holomino, magst Du es beantworten?

MfG

[Defiant]

Sollte man solche Fragen nicht in andere Threads auslagern? Hier Teilprobleme zu besprechen macht das ganze irgendwie unübersichtlich.

[Holomino]

Sollte man solche Fragen nicht in andere Threads auslagern? Hier Teilprobleme zu besprechen macht das ganze irgendwie unübersichtlich.

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). Das respektvolle Gegenüberstellen der Lösungen können wir dann ja im neuen Thread machen.

Moppi: Details klären wir dann im neuen Thread, ok?

[Moppi]

Bevor wir jetzt das Rad neu erfinden, so oder so ähnlich wird es jeder machen: Berechnung Akku Laufzeit
Davon ausgehend kann jeder das finden, was er benötigt. Interessant ist, die verbrauchte Energie jederzeit auf eine bestimmte Strecke auszurechnen.
Man könnte eine Art Standardverbrauch, auf diese bestimmte Strecke, ansetzen. Man kann pro Elektronikbaustein und Aktor einen Verbrauchswert ermitteln und hinterlegen. Je nachdem, was an Elektronik dann zugeschaltet ist und welche Aktoren aktiv sind (und wie lange) könnte der Energiebedarf ganz gut berechnet werden, denke ich. Das Problem wird dann das Auffinden der Ladestation, dazu muss man immer wissen wo die sich befindet und wie weit weg sie sich befindet. Oder es ist bekannt, dass die Ladestation in einer bestimmten Zeit auf jeden Fall gefunden wird (in einer Wohnung gibt es ja so weite Strecken nicht). Dann ermitteln, wie lange der Roboter mit welchem Energieverbrauch unterwegs sein kann, bis die Akkuspannung eine festgelegte untere Grenze erreicht. Dann müsste man alles haben, um die Unbekannten berechnen zu können. Außerdem könnte man ermitteln, welche Elektronischen Teile oder Aktoren aktiv sein können, um die Ladestation noch zu erreichen. Einberechnen müsste man wohl auch immer eine Reserve.

Gruß

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

[Moppi]

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

Schön! Nicht? Und Dein Vorschlag dazu?

MfG

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