Theorie Schwarmroboter

[Kael]

Hallo!
Ich weiß es wurde hier schon öfter mal diskutiert. Allerdings war das 'früheste' was ich wirklich fand eher im Bereich 2014 anzusiedeln. Das ist ja mittlerweile schon 4 Jahre her!

Nun wollte ich auch mal Fragen was ihr davon kennt und falls ihr Ideen habt wie ihr euch das vorstellt?

Ich kenne dahingehend vor allem kilobots, zooids und noch 1-2 ähnliche Systeme. Diese Systeme beziehen sich meines Wissens allerdings hauptsächlich auf den Bereich der 'Formationsbildung' und 'Wegfindung'.
Was ich bisher hier im Forum aber gesehen habe ist dort selbst jetzt schon einiges mehr möglich.

Daher auch die Frage... Wie würdet ihr euch einen Roboter-Schwarm in einer Pseudo-Theorie/Pseudo-Code vorstellen?


Schwarm-Basis Theorie:
Für mich z.B. ist eine so genannte "Hive-Mind" Idee am erfolgsversprechendsten.

Das Hive-Mind Konzept sagt Grundlegend ja nur aus das es einen 'Hauptrechner' geben muss, der dann entsprechende Aufgaben an 'Kleinrechner' weitergibt.

So könnte man z.B. ein Beispiel nehmen:

Der Hivemind ist an 2 Waagen angeschlossen. Diese 2 Waagen sind im Moment unterschiedlich befüllt, sollen allerdings am Ende zu 80% befüllt werden.
Waage 1: Mit Erde
Waage 3: Mit Biomaterial

Natürlich müsste man programmieren wie diese Roboter erkennen 'was' denn 'was' ist.

Aber die Grundidee dahinter sieht wie folgt aus:

Das Hivemind hat 10 Kleinroboter welche den Befehl ausführen.
Das Hivemind wird wahrscheinlich am Anfang die Roboter in 2 Gruppen aufteilen. 5 Roboter für Bio und 5 Roboter für Erde.

So reisen also die Kleinroboter los und fangen mit ihren Schaufeln an die Erde und das Biomaterial zu sammeln.

Bei ihrer Rückkehr treten sie in Kontakt mit dem Hivemind und geben wieder 'was' sie dabei haben.
Daraufhin gibt das Hivemind den die Anweisung aus: Lade auf Waage A oder B.
Daraufhin kehrt der Kleinroboter zum Hivemind zurück - gibt den Befehl "Ladung leer" aus und bekommt eine neue Aufgabe.

So zumindest in der groben Theorie.

Nun zur 'versuchten' praktischen Anwendung:
Da ich mich mittlerweile mit Python 'relativ gut' auskenne, wollte ich so etwas mal anfangen zu programmieren.
Ich habe mir einen neuen Raspberry Pi3b bestellt und stehe nun vor der Frage... Wie setze ich das nun überhaupt vernünftig um?

Da fällt es mir als erster Schritt vor allem ein es zu visualisieren...
Und wie? Ein Spiel wäre eine Option.
Also im prinzip eine weiße Fläche mit kleinen farbigen Punkten die einen Weg suchen bis sie zu einem "Rohstoff" kommen - nur um dann den direkten Weg zurück zu nehmen.
Natürlich muss man entsprechende Sensoren in das einzelne Objekt einbauen mit realistischen Werten.

Später sollte dann auch noch die Option eingebaut werden das die Roboter bei Kontakt miteinander kommunizieren können.

Ich möchte es allerdings auch gern technisch realisieren...daher auch hier erstmal die Theorie...

Bei der Technik selbst stellt sich mir vor allem die Frage nach dem richtigen Development-Board

Welche Technik ich bisher vorgesehen hätte:

Raspberry Pi als Hivemind.
Priorität: A
Stationär
System: Raspberry
Energie: Batterie / Direktanschluss
Sensoren: Noch unklar
Module:
-Auflademodul für Kleinroboter(A)
-Auflademodul für Mediumroboter(C)
-Lagersystem
-Speichersystem

Grundidee:
Der Hivemind ist so gesehen der 'Aufgabenverteiler' des ganzen. Er 'sagt' den Kleinrobotern was sie tun sollen wenn sie zum Hivemind zurückkommen. Außerdem gäbe es die Möglichkeit den Hivemind auch als eine Art 'Karte' zu nutzen oder gar
zu realisieren. Es ist das größte Speichermedium im System und wenn 'Daten' von den Kleinrobotern reinkommen soll der Hivemind in der Lage sein Daten zu generieren welche z.B. auch in der Lage sein sollen eine Umgebung zu
Kartographieren oder auch 'Risikostellen' zu markieren. Diese Daten könnten dann z.B. an die Kleinroboter oder die Secondminds weitergegeben werden so dass diese die entsprechende Information nutzen können.


Arduino als 'Secondmind'
Priorität: C
Typ: Mediumroboter
Mobil
System: Arduino
Energie: Batterie(Akku)
Sensoren: Noch unklar
Fortbewegung: Reifen
Module:
-Aufladesystem für Kleinroboter

Grundidee:
Die Idee des Secondminds würde sich darauf fokussieren eine Art 'Gebietserweiterung' hinzu zu fügen. Soll bedeuten, falls eine 'Ressource' außerhalb der Reichweite
des Hiveminds liegt - diese aber von den Kleinrobotern 'entdeckt', kann der Befehl kommen das ein 'Secondmind' hinausgesandt wird, wodurch ein Kontakt durch den Secondmind zum Hivemind als Leuchtfeuer
geregelt wird. Dabei bietet der Secondmind ebenfalls eine temporäre Aufladestation (Optional)

Arbeitsbot:
Priorität: A
Typ: Kleinroboter
Mobil
System: Noch unklar
Energie: Batterie(Akku)
Sensoren: Noch unklar
Fortbewegung: Lenkrollen
Module:
-Aufnahmesystem
-kleines Lagersystem(Optional)
-Speichersystem

Grundidee:
Die Grundidee der Arbeitsbots ist das simple sammeln von Ressourcen. Ressourcen müssten im Beispielfall natürlich entsprechend 'anfällig' für die Sensoren der Arbeitsbots sein. Dies wäre z.B. durch Magnete oder Farben möglich.
Die Arbeitsbots bringen demnach die Ressourcen zum Hivemind und 'lagern' sie dort, bis das Hivemind 'beschließt' (oder vom Benutzer eingegeben) genügend Ressourcen gesammelt hat.
Der Arbeitsbot benötigt ein kleines 'Speichersystem' welches Unterteilt wird in 'Grundbereich', 'Bearbeitungsbereich' und Anweisungen.
Im Grundbereich steht der unveränderliche Code. Dieser hat die Teile für die Bewegung und Mechanik, wie z.B: "Batterie ist unter 10% - Nach dem Abladen auf die Aufladestation fahren". Der Bearbeitungsbereich muss der Speicherbereich sein der für die Umsetzung von Algorithmen verwendet wird und der Anweisungsbereich
soll die Anweisungen vom 'Hivemind' übergeben bekommen und diese dann ausführen.


Ressourcen
Priorität: B
Grundidee:
Die Ressourcen können kleine Bälle oder Würfel sein die man durch eine besonders hervorstehene Farbe oder ein anderes Mittel kennzeichnet, welche von den Robotern erkennbar wäre.

Kampfbot
Priorität: D

Grundidee:
Keine ausführliche Beschreibung. Die Idee dahinter war das man evtl 2 Hiveminds mit verschiedenen Identitäten aufsetzt. z.B: Hivemind Blau und Hivemind Rot. und sollten die Kampfbots auf einen vom anderen 'Team' treffen,
würden die Bots versuchen die anderen Bots davon abzuhalten ihrer Aufgabe nachzugehen.

Baubot
Priorität: E
Grundidee:
Auch noch nichts ausführliches. Im Prinzip war die Idee dahinter das man einem 'Baubot' eine Blaupause oder mehrere einspeichert, die dann entsprechend Ressourcen nutzen um daraus etwas zu 'errichten'.

Welche Fragen ich mir noch stelle:

Bergungsbot, Sammelbot, Signalbot usw usw... Gibt noch eeeeiniges was man hinzufügen könnte! Aber ich finde das reicht.

Welches System für die kleinen Roboter?
Eher ein System auf Arduino oder MicroPython-Basis?

Wie sollen die KLeinroboter mit dem Hivemind kommunizieren und untereinander kommunizieren?
Über Bluetooth? (Was dann doch recht teuer wäre) oder doch am ehesten über eine Art 'Drahtverbindung' die bei Kontakt mit dem anderen eingeschaltet wird?

Sollte der Hivemind als eine Art Leuchtfeuer fungieren
Als 'Grundorientierungspunkt' der bis zu einer entsprechenden Reichweite ausreicht und falls die Roboter diese Reichweite überschreiten automatisch die letzten 100 Sekunden 'zurückfahren' um in Reichweite zu kommen?
Sollte also die Möglichkeit eingebaut werden für 'Außenposten' welche durch den Hivemind genutzt werden könnten und sich automatisch an eine 'stark befahrene Grenze' setzt? Siehe Arduino als Secondmind.

Schwarmintelligenz!
Ein für mich eher großes Thema. Nämlich wenn die Bots untereinander 'kommunizieren' - wie gehen sie eine Problemlösung an? Meine Grundidee dahinter ist nämlich das man, bei Kontakt mit einem anderen Bot, für eine gewisse Zeit die 'Rechnerleistung teilt' und dadurch eine größere Menge an möglicher Rechenleistung produziert. Soll z.B. bedeuten: "Mehr Bots an einem Platz, desto schnellere Problemlösefähigkeit wird generiert".
Idee dahinter ist z.B. das wenn man einen kleinen Holzstab zwischen Ressourcen und Weg legt, ob die Bots in der Lage wären diesen automatisch selbst zu umgehen oder aber diesen sogar mit 'gemeinsamer Kraft' wegzuschieben.

Welche Sensoren und Module für die Bots?
Soll ich am besten sofort mit Kamerasensoren anfangen oder doch eher mit Sonarsensoren? Oder am Ende doch sogar beides? Immerhin sollen die Bots nicht miteinander kräftig kollidieren.


Mein Ziel:
Also mein 'erstes Ziel' wäre natürlich einen Raspberry als 'Hivemind' zu programmieren der in der Lage wäre mit 1-2 Bots zu kommunizieren. Die Bots selbstständig zum 'Hivemind' fahren und dort 'Daten abliefern'.
Das kann eine simple Information sein wie: "Bot #002 angedockt" - um mal ein Beispiel zu nennen. Allgemein werde ich noch viel recherchieren müssen, vor allem bezüglich Spannung und Datenverarbeitung

Dabei sollten die Bots natürlich auch möglichst günstig sein!

Was ich noch nicht will:
Viele Dinge, wie z.B. den Secondmind oder einen 'Kampfbot' habe ich überhaupt noch nicht im Blick. Es steht zwar dort, bedeutet aber nicht das sie umgesetzt werden sollten.



Und nun ja! Wie ist eure Lieblingstheorie am ehesten? Und meint ihr das wäre auch so umsetzbar?

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

[i_make_it]

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

Das sind die selben Motoren und Reifen wie bei diesem Chassis:
https://www.amazon.de/Automotive-Geh...C3%BCr+Roboter

Zum ansteuern kann man da z.B. diese Dual H-Brücke nehmen.
https://www.amazon.de/gp/product/B01...?ie=UTF8&psc=1

Dazu passen würde dann dieser Arduino Code: (mit genau diese Motoren und dieser doppel H-Brücke getestet)
(letzter Code in dem Post)
https://www.roboternetz.de/community...l=1#post642738
Der Code läuft so auf einem Arduino Due und Mega 2560.
Für einen Uno oder Nano müsste man die PWM Pins im Code entsprechend ändern.

Dieser Code ist noch mal etwas optimiert
https://www.roboternetz.de/community...l=1#post642754
Ggf. mal den ganzen Thread durchlesen da dort auch das Thema Stromaufnahme der Motoren und Reset des µC durch dieselbe behandelt wird.

Für garantierte Gradeausfahrt, braucht man allerdings eine Regelung und dafür als Istwertaufnehmer die entsprechenden Radencoder.
Z.B.:
https://www.amazon.de/gp/product/B07...?ie=UTF8&psc=1
Die sind für diese Motoren und passen in das Chassis.

Die Kombination wäre also ein "mehr Geld gegen schnellen Erfolg" tausch.

[HaWe]

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