Theorie Schwarmroboter

[i_make_it]

Hive-Mind ist eigentlich kein Schwarm, sondern ein hiraschisches Master-Slave System.
Fällt der Master aus, läuft nichts mehr.
Bei einem Schwarm gibt es einen Schwellwert bei der Anzahl wo das Verhalten der Individuen "kippt" ist die Anzahl in Reichweite kleiner wird sich als Individuum verhalten.
Ist sie größer schließt ma sich dem Schwarm an (Fische und Vögel).
Bei Staaten bildenden Systemen (wie Ameisen) wird durch die Königin die Gewichtung der Spezialisierungen in der Gesammtmenge vorgenommen (Arbeiter, Krieger, Drohnen, königingen).

Bei einem Roboterschwarm käme z.B. der Selbsterhalt an erster Stelle. (Stromquellen finden, ggf. Solarzellen dann Lichtquelle finden)
Abhängig vom Ladezustand wird dieser Task priorisiert.
Und im Schwarm Kommuniziert.
Damit ist Kartieren und Wegfinden eine Primäraufgabe und überlebenswichtig.
Zum Selbsterhalt gehört auch das Identifizieren von Gefahren und deren Vermeidung.
Also z.B. Treppenabsätze, ggf. Heizkörper, Backofen, Kamin, Fahrstrecken von Fahrzeugen die einen Roboter beschädigen oder zerstören können (je nach Umfeld).

Nachdem Narung (Energiequelle) und Gefahren identifiziert und verortet sind, kommt es darauf an welche Aufgabe der Schwarm hat.
Bei Staatenbildenden Insekten, kommt noch eine örtliche Bindung hinzu. Es gibt ein Revier dessen Areal das um das eigene Nest liegt.
Das könnte z.B. eine Ladestation sein.

Bei einem Schwarm könnten Aufgaben umverteilt werden.
Ist noch keine Energiequelle erschlossen, gilt es für alle diese zu suchen und dabei Gefahren zu lokalisieren.
Ist eine Energiequelle vorhanden, kann ggf. mit niedrigerer Priorität nach einer zweiten (Backup) gesucht werden.
Das kann auch als untergeordneter Task bei anderen Aufgaben erfolgen.
Somit kann erst der komplette Schwarm auf Suchen und Kartieren schalten und wenn eine gefunden ist, gibt der Finder diese Information weiter an jedes Schwarmmitglied das es trifft.
Die geben diese Information wiederum weiter. So werden dann auch mehrere Energiequellen an jedes Individuum vermittelt.
Z.B: wird zuerst die Koordinate der Energiequelle als Polarkoordinate bezogen zur eigenen Position übertragen.
Befindet sich der Empfänger an der selben Position kann er abgleichen, ob er die Quelle bereits kennt oder nicht.
Wenn nein, wird auch der Weg dorthin weitergegeben.

Übrigens ist im Floristen und Gartenbau Bereich Erde = Biomasse im Gegensatz zu Sand = mineralisch (z.B. Blumenrerde).

Für was benötigt es Kampfroboter?
Welches Szenario hast Du im Sinn, außer ein künstliches Battlebot spielchen.

[Kael]

Hallo make_it!
Jap, eventuell hab ich dahingehend etwas in die falsche Richtung gedacht.

Allerdings halte ich das Master-Slave System in dem Fall immer noch für eine sehr gute Ausgang

Für was benötigt es Kampfroboter?
Welches Szenario hast Du im Sinn, außer ein künstliches Battlebot spielchen.

Ja das war auch meine Idee dahinter - man muss natürlich auch etwas 'Spaß' an der Sache haben.

Die 'Schwarminterne Kommunikation' empfinde ich dahingehend auch als das größte Hindernis, vor allem das 'Erkennen' von etwas und die entsprechende Umsetzung.
Um das ganze, auch für mich als Hobby das ganze zu vereinfachen wollte ich beide Systeme miteinander kombinieren.
Hivemind = Planung
Kleinbot = Problemlösung vor Ort.

So war es zumindest in der Idee.

Damit ist Kartieren und Wegfinden eine Primäraufgabe und überlebenswichtig.
Zum Selbsterhalt gehört auch das Identifizieren von Gefahren und deren Vermeidung.
Also z.B. Treppenabsätze, ggf. Heizkörper, Backofen, Kamin, Fahrstrecken von Fahrzeugen die einen Roboter beschädigen oder zerstören können (je nach Umfeld).

Das habe ich noch gar nicht in dem System von mir bisher mit drin gehabt. Empfinde ich allerdings auch genauso wichtig.

Nur wäre dann die Frage wie man das mit der Koordinate und Orientierung entsprechend hinbekommt? - Da wäre für mich die Position des Leuchtfeuers z.B. wieder sehr wichtig.
Denn wenn die Roboter wissen wo das Leuchtfeuer ist, können sie davon ggf auch Daten abrufen?

NAtürlich wäre es letztlich keine 'echte klassische Schwarmintelligenz' wie man es sich vorstellt.

[i_make_it]

Was für Roboter hast Du denn bisher bereits gebaut?
Falls noch keine, empfehle ich erst mal kleine Brötchen zu backen.

Also 2-3 identische Roboter aufbauen.
z.B mit kleinen DC-Getriebemotoren und Radencodern (für Odometrie).

Dann Kollisionssensoren (Bumper).
Und Fernsensoren (IR und oder US).

Wenn die Roboter ohne ständige Kollision rumfahren können, kann man z.B eine Solarzelle und eine Ladeschaltung sowie eine Auswerteschaltung einbauen.

Der nächste Punkt wäre ein Ortsgedächtniss (Karte).
Da ist man dann bei SLAM (Simultaneous Localization and Mapping).
Bisher lässt sich alles noch mit einem Arduino realisieren.
(Suchbegriff: arduino slam)

Für eine Schwarm Kommunikation bietet sich z.B. XBee (ZigBee Modul) an.
Damit gehen 240 Schwarmmitglieder.

Neben einer Funkschnittstelle macht auch noch eine optische Schnittstelle für den Nahbereich Sinn.
Sollen Kartendaten untereinander ausgetauscht werden, kann zum einen die ID optisch ausgetauscht werden, was die Addressierung des Gegenüber durch Funk erleichtert.
Zum anderen kann die Ausrichtung der Kommunikationspartner zueinander ermittelt werden.
Werden Kartendaten als Polarkoordinaten übertragen, mit dem sendenen Roboter als Koordinatenursprung, dann ist neben der Position auch die Ausrichtung wichtig.

Beim Kommunikationsprotokoll bzw. dem Aufbau der Datagrame muß man sich halt vorher schon darüber im klaren sein was man alles übertragen will.
Es kann dann auch sinnvoll sein ein System mit mehreren µC oder µC und Kleincomputer wie z.B. Raspberry Pi aufzubauen um mehr Parallelverarbeitung zu erreichen.

Ob die Roboter als "Nutzlast" Beacons haben die Sie an bestimmten Positionen absetzen können, ist zwar eine Überlegung wert, aber diese müssen dann ja auch immer wieder versorgt werden (geladen). Da ist dann auch irgendwann der Punkt erreicht wo ständig Beacons entweder angefahren werden müssen um sie zu laden oder ausgetauscht werden müssen um sie zu einer Ladestation zu bringen. Sowohl von der notwendigen Kommunikation (Beacon X ersetzt jetzt Beacon Y an Position a,b) als auch von der Auslastung der Schwarmmitglieder für Transport oder das Laden vor Ort ist da schnell ein Punkt erreicht, an dem der Schwarm nicht mehr machen kann als nur seine Infrastruktur am laufen zu halten. Außer man greift ständig von außen ein und übernimmt diese Aufgaben.
Dann würden aber die Roboter dem Menschen diktieren was er wann zu tun hat.
Nicht grade sinnvoll.

[Kael]

Roboter selbst 'noch' keine.
Ich habe mich früher sehr stark mit R-Cars beschäftigt und auch selbst welche gebaut.
Deswegen möchte ich zuallererst mich auch eher mit den Kleinen-Bots beschäftigen oder es simulieren um dafür auch ein 'Händchen' zu kriegen.

Als Hauptsprache hatte ich mich nun für Python entschieden da man es mit Micropython gut ableiten kann und ich mich dann 'erstmal' nicht in C noch mal einlesen muss.

Dafür habe ich auch schon ein ESP26 . Eventuell kriege ich es auch hin den Arduino mit einem Formata zu bearbeiten das er die Befehle annehmen könnte.

Bild hier  

wäre dahingehend eine kleine 'Grundskizze' - noch ohne irgendwelche Längen- und Breitenangaben. Aufgebaut werden soll er nach oben und nicht in die Breite. Ist dahingehend denke ich auch einiges an Kabelmanagement nötig und auch die Möglichkeit alles 'modular' immer an und abschrauben zu können. Gerade im Bereich der Batterien muss ich noch überlegen welche ich dafür nehme - eventuell muss ich das ganze noch etwas umbauen.

[i_make_it]

Roboter selbst 'noch' keine.
Ich habe mich früher sehr stark mit R-Cars beschäftigt und auch selbst welche gebaut.
Deswegen möchte ich zuallererst mich auch eher mit den Kleinen-Bots beschäftigen oder es simulieren um dafür auch ein 'Händchen' zu kriegen.

Also ich rate vom Simulieren ab, wenn Du noch gar keine Bots gebaut hast.
Man kann alles Mögliche und auch viel Unmögliches simulieren.
Wenn man seine ersten Erfahrungnen damit gemacht hat was geht und vor allem wie einfach oder auch schwierig verschiedene Varianten sind. ist Simulation was schickes.
Für eine gute Simulation muß man halt meist auch wissen welche Paramter die richtigen sind.
Such alleine mal hier im Forum nur nach Parametern für Motorregelungen da wirst Du feststellen das ohne die richtigen Paramter auch gute Algotithmen nur Mist liefern.

Und einen Regler Simulieren um gute Parameter zu bekommen, geht auch nicht wenn die Parameter der simulierten Bauteile (z.B. Motor) nicht stimmen.
Oft ist es so das man empirisch (im realen Aufbau) Werte ermittel. damit seine Simulation füttert und dann dort die Suche nach einem Optimum verkürzen kann.
Dann mit den in der Simulation gefundenen Werte seinen realen Aufbau füttert und schaut, ob das Ergebniss der Simulation entspricht.

Bei kleinen Bots würde ich von dem 4 Rad Konzept erst mal weg gehen. Das brauchst Du eher wenn die Bots größer werden.
Ein Aufbau mit 2 angetriebenen Rädern und einem drehbaren Schlepprad/Gleiter ist fürs erste vollkommen ausreichend.
Ein mögliches Beispiel kannst Du z.B. in dem Thread von mir sehen.
https://www.roboternetz.de/community...l=1#post622218
Das Chassis sind GFK-Platinen im Euroformat (100x160mm) die ich noch da hatte (unter 2,50€ je Stück), Billige (5,-€) RC-Servos die ich gehackt habe (0,18€ für die Widerstände), die Metallwinkel gabs mal günstig im Abverkauf eines Metallbaukasten Systems das sich als Ladenhüter erwies.
Die Räder bestehen aus Bastelsperrholz und Dichtungen für Abflußrohren Was zusammen auch unter 4,-€ waren.
Ich habe halt eine Bohrmaschine und einen Bohrständer sowie Lochsägen womit die Teile schnell gemacht sind.

Alternativ kann man auch Chassis mit Motoren und die Radenkoder feritg kaufen:
Bsp.:
https://www.amazon.de/Automotive-Geh...C3%BCr+Roboter
https://www.amazon.de/gp/product/B07...?ie=UTF8&psc=1

Als Hauptsprache hatte ich mich nun für Python entschieden da man es mit Micropython gut ableiten kann und ich mich dann 'erstmal' nicht in C noch mal einlesen muss.

C und C++ werden Dich in dem Bereich ständig begleiten.
Es macht Sinn sich da gleich drauf ein zu lassen.
Sonst machst Du alles zwei mal. Einmal in Python bis zu dem Punkt wo Du in Python nicht mehr weiter kommst und dann noch mal alles in C/C++.
Oder wenn Du Dich ganz schwer von Python löst, machst Du den Weg Python -> Cython -> C -> C++.
Sei es Performance, verfügbare Zielsystem, größere Hardwarenähe oder noch was anderes, die Wahrscheinlichkeit ist sehr hoch das Du über kurz oder lang eine der Grenzen erreichst und wechseln wirst.
Wenn Du dir PID Regler suchst oder SLAM implementierungen hast Du den Bespielcode in der Regel in C oder C++.
Suchst Du in Foren und Wikis findest Du deutlich mehr in C/C++ als in Python.
Im Prinzip ist Python ja das was in den 1970ern/80ern BASIC war eine leicht erlernbare Anfängersprache die den Einstieg in die "richtigen" Hochsprachen erleichtern soll.

Dafür habe ich auch schon ein ESP26 . Eventuell kriege ich es auch hin den Arduino mit einem Formata zu bearbeiten das er die Befehle annehmen könnte.

Es gibt nicht "den" Arduino Arduino ist ein Projekt, das eine IDE hervorgebracht hat und eine Reihe von µC Boards mit verschiedenen µC's.
Du könntest mit Cython C-Code erzeugen, diesen Scriptgesteuert für die Arduino IDE aufbereiten und dort dann für das jeweilige Zielsystem Comilieren lassen.
Das ist aber umständlich.

Ich habe auch sehr lange an Turbo Pascal gehangen, bis ich mich alleine wegen der ganzen API Aufrufe für Windows sowieso mit C++ befassen musste.
Hinterher habe ich mich gefragt warum ich nicht viel früher gewechselt bin.

Aktuell mache ich recht viel mit Arduino C++, muß mich jetzt aber trotzdem mit den Registern vom atmega328 befassen, weil das was ich machen will so ohne weiteres nicht damit geht.

[Kael]

Also ich rate vom Simulieren ab, wenn Du noch gar keine Bots gebaut hast.
Man kann alles Mögliche und auch viel Unmögliches simulieren.
Wenn man seine ersten Erfahrungnen damit gemacht hat was geht und vor allem wie einfach oder auch schwierig verschiedene Varianten sind. ist Simulation was schickes.
Für eine gute Simulation muß man halt meist auch wissenwelche Paramter die richtigen sind.
Such alleine mal hier im Forum nur nach Parametern für Motorregelungen da wirst Du feststellen das ohne die richtigen Paramter auch gute Algotithmen nur Mist liefern.

Aaah gut ich verstehe. Also lieber direkt an die Technik ran.

Bei kleinen Bots würde ich von dem 4 Rad Konzept erst mal weg gehen. Das brauchst Du eher wenn die Bots größer werden.
Ein Auvbau mit 2 angetriebenen Rädern und einem drehbaren Schlepprad/Gleiter ist fürs erste vollkommen ausreichend.

Mmh... Nun, ich ging von einem stabileren Aufbau bei 4 Rädern aus ohne das etwas mit einer unnötigen Komplexität 'verschandelt' werden kann. Wobei es auch nicht soooo ein großer Unterschied ist - Ich ging nur davon aus das ich einfach mehr 'Platz' habe, da der Reifen hinten bei falscher Befestigung etwas im Weg steht.

Für den Raspberry-Bot wollte ich jedenfalls die 4 Reifen nehmen - im Schnitt bekommt man die Reifen als Set meistens so oder so als 4er Set.
Wobei ich auch gesehen habe das es so was hier sehr 'preiswert' gibt:
https://www.ebay.de/i/142439046354?c...r=441442989571

Ich werde mal darüber nachdenken. Ich persönlich bin aber eher ein freund vom 4er Rad System. ^^

C und C++ werden Dich in dem Bereich ständig begleiten.
Es macht Sinn sich da gleich drauf ein zu lassen.
Sonst machst Du alles zwei mal. Einmal in Python bis zu dem Punkt wo Du in Python nicht mehr weiter kommst und dann noch mal alles in C/C++.
Oder wenn Du Dich ganz schwer von Python löst, machst Du den Weg Python -> Cython -> C -> C++.

Ja, ich liebe Python. Um es mal wortwörtlich zu sagen. Weswegen ich mich wiiiiiiirklich schwer davon trenne. Auch wäre es ein Versuch so einen Roboter mit Python am laufen zu kriegen eine gute Sache für eine
Hausarbeit an meiner Uni (dort müssen wir auh mit Python programmieren - ist kein Informatik Studiengang). Aber das ich auf lange Sicht ohne C/C++ nicht weiter komme, ja das sehe ich auch als ein Problem an.
Gerade aber für die Programmierung nimmt Python auf einem RPi3 nun mal sehr viel ab.


An 'Material' was ich im Moment schon 'habe'

-RPi3
-Arduino Uno3 Set ( https://www.amazon.de/gp/product/B01...?ie=UTF8&psc=1 )
-ESP32
-Atmega Nano V3 ( ATmega328P)


Mein Hauptziel im Moment ist erstmal das simple 'fahren' hin zu bekommen und danach einen Sensor einzubauen der auf entsprechende Entfernungen läuft. Schritt für Schritt mit modularen hinzufügen. Aber ich würde es doch gern sehr minimalistisch halten.
Ich denke für den Bau werde ich auch eine kleine Projektvorstellung direktmachen (bezüglich der kleinen Roboter).

Im Bestenfall will ich nämlich nicht das der Bot größer als meine Handfläche wird.

Das nächste was ich mir dazu holen wollte waren entsprechend die Motoren + Reifen sowie die 'Hauptplatte'. Da versuch ich ggf eine grüne, blaue oder schwarze antistatische GFK Platte zu organisieren.

[HaWe]

was mich in diesem Zusammenhang noch interessieren würde: kann Python auf dem Pi und Micropython auf Arduino eigentlich Multithreading?

[HaWe]

wie ist es denn jetzt:
ist Python multithreading-fähig (auf Pi und Arduinos)?