Think Modular

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

[Holomino]

Meine Güte, ich war schon bei Stephen King.

[Moppi]

Das ist eine interessante Frage, auf die ich auch noch keine Antwort gefunden habe.

Weist Du nicht, welche Größe? für drinnen vielleicht nicht mehr als 30x30cm in der Grundfläche, nach oben geht vielleicht etwas mehr. So zum Anfang. Größer dann für die, die zuhause oder gar draussen mehr Platz haben. Größer geht ja dann immer.

Den Zusammenhang zwischen korrektem Kartieren und Sensorsetup allerdings kann ich schon in 2D nur noch in der Simulation abschätzen.

Würde mich interessieren, was Du damit genau meinst.

Letztlich ist die Aufgabe vergleichbar mit der Funktion eines Blinden, der nur mit den Tastsinnen (Händen) eine fremde Wohnung erforscht.

Na ja, im Grunde ist ein Roboter das. Solange, bis die Technik irgendwann mal einwandfrei sehen und Objekte erkennen wird, wie ein Mensch, auch in der Geschwindigkeit.

MfG

[morob]

lach, sowas lese ich nicht mal, dann lieber Frank Schätzing

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

[Holomino]

...

Was wir mit unseren Lidars praktisch in der "Breite" (Datenmenge) mehr haben, ging beim Dead Reckoning in die Tiefe (die Korrelationen über den zeitlichen Ablauf). Das war quasi ein Dauer-Closed-Loop-Ansatz, in dem immer wieder die rudimentären "Scans" an ihren Aufnahmeorten im Rahmen einer Hypothese (den Odometriefehlern) korrigiert wurden.
Half aber auch nichts. Das praktische Fehlen einer detektierbaren Tiefenbegrenzung (man kann auch länger fahren) sowie der ganz ordinäre Blindflug über Flächen ohne Hindernisse hat schließlich noch in den Versuchen gemündet, die Odometrie zu verbessern (zu der Zeit kam z.B. auch der SynchroDrive auf).

Hindernisssensoren im Nahfeld, also Bumper oder US hatten die Teile damals auch schon. Später kamen dann Gyro und Kompass dazu, aber so richtig durchgesetzt hat sich das wohl jenseits der Laborebene nie.

Aber wo ich Dir mal wieder Löcher in den Bauch fragen darf: Was sind denn bei ROS die sensorischen Minimalanforderungen zum Kartieren? Ein Lidar ist ja auch nix anderes als der Ersatz für mehrere Abstandssensoren. Wie weit kann man in ROS Messgenauigkeit, Reichweite Winkelauflösung und Wiederholrate in Bezug auf Raster, Umgebungsgröße und Robotergeschwindigkeit herunterschrauben?

Weist Du nicht, welche Größe?

Rein funktional gebaut ist mein letztes Modell ca. 16x17x15cm. Zu groß für die Mini-Sumo-Klasse (10x10cm)

[Holomino]

Gefunden: https://hackaday.io/project/161085-phoebe-turtlebot
Ein an den TurtleBot angelehnter Nachbau mit ROS und SLAM für 250$ (ca. 200€).
Leider kein Powermanagement und scheinbar auch keine zusätzliche Hindernisdetektion, so richtig autark wird es also wohl nicht sein.
Mal (kommendes Jahr) sehen, ob es nicht etwas günstiger geht und die o.g. fehlenden Funktionen trotzdem drin sind.