Think Modular

[Moppi]

Ja, dann steht das wohl fest. SLAM ist vorhanden und soll verwendet werden. Wenn also ein Anforderungsprofil erstellt würde, sollte dann erster Stelle "SLAM" stehen. Das dafür Notwendige lässt sich daraus ableiten. Wie: zentrale Rechnereinheit (CPU/Board) und daraus folgend die Stromaufnahme. An der zweiten Stelle des Profils könnte stehen: Laufzeit xxx. Daraus kann man dann schon ganz grob zur notwendigen Akku/Batteriekapazität kommen und zum Gewicht des Akkus. Das Gesamtgewicht des Roboters sollte vielleicht dann schon an dritter Stelle des Anforderungsprofils stehen. Drum herum muss noch ein wenig Leistung für angeschlossene Peripherie eingeplant werden.

[Defiant]

Ja, dann steht das wohl fest. SLAM ist vorhanden und soll verwendet werden.

Hab ich vorher noch nicht gelesen, dass SLAM fest steht? Ich dachte die Idee wäre Modular?

(...) sollte dann erster Stelle "SLAM" stehen. Das dafür Notwendige lässt sich daraus ableiten. Wie: zentrale Rechnereinheit (CPU/Board) und daraus folgend die Stromaufnahme.

Ein ESP32 z.B. sollte reichen wenn der SLAM-Algorithmus per W-Lan angebunden wird. Muss ja kein Rpi4 mit 1A an Board sein.

An der zweiten Stelle des Profils könnte stehen: Laufzeit xxx. Daraus kann man dann schon ganz grob zur notwendigen Akku/Batteriekapazität kommen und zum Gewicht des Akkus. Das Gesamtgewicht des Roboters sollte vielleicht dann schon an dritter Stelle des Anforderungsprofils stehen. Drum herum muss noch ein wenig Leistung für angeschlossene Peripherie eingeplant werden.

Bedingt sich natürlich alles gegenseitig. Ich würde mit dem Antrieb anfangen, dann kommt die Laufzeit und damit die Akkukapazität. Aber nochmal: Ich dachte die Idee wäre Modular zu sein, also keine Festlegung von Akku, Gewicht etc weil austauschbar?

[Moppi]

Hab ich vorher noch nicht gelesen, dass SLAM fest steht? Ich dachte die Idee wäre Modular?

Die Diskussion geht doch darum dass es SLAM sein soll?

Ein ESP32 z.B. sollte reichen wenn der SLAM-Algorithmus per W-Lan angebunden wird. Muss ja kein Rpi4 mit 1A an Board sein.

Weiß ich nicht. Ich würde vollständige Geräte bevorzugen. Wegen der Ortsunabhängigkeit. So ist es sonst ortsgebunden, in der Reichweite des WLANs.

Ich dachte die Idee wäre Modular zu sein, also keine Festlegung von Akku, Gewicht etc weil austauschbar?

Irgendwo benötigt man doch eine Mindestanforderung, um entwicklungstechnisch darauf aufzubauen? Muss man erst mal durchspielen, so Pi*Daumen und sehen, was dabei heraus kommt. Dann erfährt man was über die Mindestgröße die das haben soll. Auch evtl. über die Baugröße der Module und deren Leistung (Akku/Batterie). Dann sieht man, ob das irgendwie unter einen Hut zu bringen ist. Wenn allein der Akku am Ende 500g wiegt, braucht man u.U. stärkere Motoren im Antrieb oder einen anderen Antrieb. Damit ändert sich evtl. die Größe des Antriebs und damit des Roboters und wieder das Gewicht. Modularität hat ja auch Grenzen. So passt eine Akkueinheit von Toyota auf einige Fahrzeugtypen mit Straßenzulassung, aber nicht auf einen Staubsaugroboter. Und der Akku vom Staubsaugroboter wird keinen Toyota-PKW antreiben können.Deshalb denke ich, so eine Grundvorstellung von der Größe muss vorhanden sein. Wel dann kann man Bereiche festlegen, wie Akkuleistung von .. bis .. mAh. Mal kleiner, mal größer. Aber ich glaube, ich mache mir da jetzt zu viele Gedanken. Mal sehen, wie Holomino das sieht.


MfG

[morob]

Ich will bei meinem Weihnachtsprojekt weg vom SLAM, sondern fahren nach Farben machen, das heißt mit Tiefenbild. Ich werde berichten wie es läuft, fest montierte Lidar Sensoren, will ich nur wegen der Kollision verwenden.
Wie gesagt ich werde berichten.

Ich hatte auch schon mal an ein ES gedacht, mit Einsatzparameter, bin da aber irgendwie abgekommen.

[Defiant]

Weiß ich nicht. Ich würde vollständige Geräte bevorzugen. Wegen der Ortsunabhängigkeit. So ist es sonst ortsgebunden, in der Reichweite des WLANs.

Manchmal frage ich mich in welchen Dimensionen du denkst. Du kannst natürlich auch LTE anstatt W-Lan verwenden oder den W-Lan AP mit einem Ethernetkabel mit dem Rest der Welt verbinden. Du musst ja nicht den ESP32 per Wlan anbinden, du kannst gerne einen Core I7 verbauen für Slam, ich glaube niemand hält dich dabei auf. Aber wenn andere einen ESP32 verwenden wollen und SLAM dann irgendwo in der Cloud rechnen wollen, wieso nicht?

So passt eine Akkueinheit von Toyota auf einige Fahrzeugtypen mit Straßenzulassung, aber nicht auf einen Staubsaugroboter.

Das ist der zweite Satz weswegen ich mich frage in welchen Dimensionen du denkst.

Deshalb denke ich, so eine Grundvorstellung von der Größe muss vorhanden sein.

Nein, wichtig ist nur wie ich den Akku anschließe. Ob der Akku 1000kg wiegt und damit 500kW Motoren antreiben soll oder 500g wiegt und 1kW antreibt ist egal wenn du in deinem Moduldesign des Akkus spezifizierst "Spannung wird per I2C in Register 0 ausgelesen" dann kann dein Mikrocontroller ohne Änderung beide Akkutypen auslesen.

[Moppi]

Du kannst natürlich auch LTE anstatt W-Lan verwenden oder den W-Lan AP mit einem Ethernetkabel mit dem Rest der Welt verbinden.

Nichts von dem, wozu auch? Kannst gerne "Cloud Computing" machen, ich habe dagegen nichts einzuwenden.

[Holomino]

Ich hatte auch schon mal an ein ES gedacht, mit Einsatzparameter, bin da aber irgendwie abgekommen.

Was ist ein ES?

Irgendwo benötigt man doch eine Mindestanforderung, um entwicklungstechnisch darauf aufzubauen?

Das ist eine interessante Frage, auf die ich auch noch keine Antwort gefunden habe. In einigen Modulen ist es einfach (im Powermodul z.B. geht nicht weniger als eine Zelle. Rechengeschwindigkeiten, Zyklen oder Datenprotokolle lassen sich eindeutig quantifizieren). Den Zusammenhang zwischen korrektem Kartieren und Sensorsetup allerdings kann ich schon in 2D nur noch in der Simulation abschätzen.
Es hat im letzten Jahrtausend einige Navigationsansätze mittels "deduced reckoning" alleine über Odometrie und Hindernissensoren im Nahfeld gegeben. Später wurde das dann liebevoll in "dead reckoning" umbenannt. Letztlich ist die Aufgabe vergleichbar mit der Funktion eines Blinden, der nur mit den Tastsinnen (Händen) eine fremde Wohnung erforscht. Das schraubt halt die Hardwareanforderungen herunter, legt aber gleichzeitig die Softwareanforderungen (auch der Blinde geht mit dem grundlegenden Wohnungs-Vorwissen "Ecken, Wände, Räume" los und stellt unterwegs verschiedene Hypothesen auf, die er ggf. im Verlauf verifiziert oder verwirft) gewaltig hoch.

[morob]

ES = Expertensystem

eigentlich nur eine Python Software, die verschiedene Dinge abfragt und Dir ein Vorschlag macht.

[Defiant]

Es hat im letzten Jahrtausend einige Navigationsansätze mittels "deduced reckoning" alleine über Odometrie und Hindernissensoren im Nahfeld gegeben. Später wurde das dann liebevoll in "dead reckoning" umbenannt.

Bitte Begriff nochmal erklären: "dead reckoning". Für mich war das bisher im Falle von Bodenrobotern z.B. die Positionsbestimmung mittels Odometrie. Wo da Hindernissensoren reinspielen verstehe ich nicht.

Letztlich ist die Aufgabe vergleichbar mit der Funktion eines Blinden, der nur mit den Tastsinnen (Händen) eine fremde Wohnung erforscht. Das schraubt halt die Hardwareanforderungen herunter, legt aber gleichzeitig die Softwareanforderungen (...) gewaltig hoch.

Kannst du den Punkt bitte auch erläutern? Ich lege doch die Hindernisse immer in eine Costmap ab, ob die Hindernisse durch ein Lidar, IR/US/ToF-Sensoren oder Taster kommen ist doch erstmal egal. Für mich bedeutet das quasi identische SW-Anforderungen, bzw im Falle von Lidar muss ich mehr Daten verarbeiten, also höhere SW-Anforderungen.