Roboterzellen

[williwilli]

Hallo Leute,

ich verfolge seit einiger Zeit die Themen Roboterzellen und Roboterschwarm im Wiki und hier im Forum. Zum Beitrag im Wiki habe ich bereits eine kleine Diskussion begonnen, die ich hier nochmal wiedergebe:


Eine tolle Vision. Bei der praktischen Umsetzung würde ich gerne mitmachen...

Aber: Viel von dem bisher Beschriebenen sind nach meinem Verständnis keine Zellen mehr, sondern bereits zusammengesetzte Module! Um zellulare Bots zu bauen, muß daher meiner Meinung nach zwingend die Betrachtung/Entwicklung der Roboterelektronik von der Mechanik getrennt werden.

Beispiel: Eine Bewegungszelle (der Teil logischer Funktionalität, der für Bewegung zuständig ist) bekommt von der Gehirnzelle (der Teil logischer Funktionalität, der für die Erfüllung der gestellten Aufgabe zuständig ist) nur mitgeteilt "...bewege dich um 100 Einheiten vorwärts...".
Die Bewegungszelle führt nun diese Bewegung aus, und dabei muß es egal sein, ob ein Schrittmotor, ein Linearmotor, ein Winkelservo, ein Hydraulikzylinder oder was auch immer angesteuert wird... und hier liegt die größte Schwierigkeit: Die Bewegungszelle muß alle vorhandenen Antriebselemente steuern können, da ihr vorher nicht bekannt ist, was verwendet wird (ob sie Rad, Bein oder Kranarm ist...)!
Die Bewegungszelle weiß, wieviel Zeit ihr für die Ausführung dieser Bewegung bleibt. Ihre Rückmeldung an die Gehirnzelle besteht nur aus "OK" (Aufgabe in vorgegebener Zeit erledigt), "ERR" (Störung der gesamten Bewegungszelle) oder "NOxx" (Aufgabe aus verschiedenen Gründen nur teilweise erledigt, xx ist der Erfüllungsgrad in Prozent).

Auf diese Art bleiben nur wenige Roboterzellen übrig:
- Bewegungszelle (s.o.)
- Gehirnzelle (s.o.)
- Sensorzelle (zuständig für die Ansteuerung beliebiger (!) Sensoren sowie die Auswertung deren Ergebnisse)
- Stromversorgungszelle (zuständig für Batterien, Solarversorgung, externe Ladeströme etc.)
- Kommunikationszelle (Ermitteln und Erkennen der eigenen Position sowie Mensch-Roboter-Schnittstelle)

Der Rest ist (wenn auch mit viel Elektrik) für mich aber Mechanik. Muß zwar sein, ist aber nicht unbedingt zellularer Roboter... Auf diesem Weg kannst Du (sofern die Mechanik stimmt) mit
- zwei Bewegungszellen sowie je einer der anderen Zellen einen kettengetriebene Planierraupe,
daraus aber auch
- mit vier zusätzlichen Bewegungszellen einen Hexabot zur kameragestützten Geländeerkundung
bauen.

--Williwilli 13:27, 25. Jul 2008 (CEST)

(Hier komme ich leider mit dem Editor nicht so zurecht. Vielleicht sollten wir die Diskussion in das Forum verlegen)

Du schreibst: Eine tolle Vision. Bei der praktischen Umsetzung würde ich gerne mitmachen...

Ich fände es toll, wenn Du mithelfen würdest.

Du schreibst: Aber: Viel von dem bisher Beschriebenen sind nach meinem Verständnis keine Zellen mehr, sondern bereits zusammengesetzte Module!

Ja und nein: Jede Zelle hält die Schnittstellendefinition ein, hat aber ihre eigenen Stärken und Schwächen. So gibt es für die Stromversorgung eigene Zellen, für die Logil ebenfalls, für die Beweglichkeit, für ...

Du schreibst: Um zellulare Bots zu bauen, muß daher meiner Meinung nach zwingend die Betrachtung/Entwicklung der Roboterelektronik von der Mechanik getrennt werden.

Das hatte ich in dem anderen Forum (Roboterschwarm) ebenfalls noch nicht verstanden ...

Du schreibst: Beispiel: Eine Bewegungszelle (der Teil logischer Funktionalität, der für Bewegung zuständig ist) bekommt von der Gehirnzelle (der Teil logischer Funktionalität, der für die Erfüllung der gestellten Aufgabe zuständig ist) nur mitgeteilt "...bewege dich um 100 Einheiten vorwärts...". Die Bewegungszelle führt nun diese Bewegung aus, und dabei muß es egal sein, ob ein Schrittmotor, ein Linearmotor, ein Winkelservo, ein Hydraulikzylinder oder was auch immer angesteuert wird...

Aber warum denn? Der logische Teil (Controller) ist mittlerweile so kostengünstig, dass ich ihn einfach zur Mechanik dazunehme. Dann kann man Mechanik, Motorik u.s.w. optimal aufeinander abstimmen und eine möglichst kostengünstige Zelle erstellen. Die hält jedoch ebenfalls die Schnittstellendefinition ein: die Gehirnzelle meldet der Bewegungszelle immer nur "...bewege dich um 100 Einheiten vorwärts...", egal ob die Bewegungszelle die Zelle für Schrittmotor, Linearmotor, Winkelservo, Hydraulikzylinder oder was auch immer ist. Es gibt einfach für jeden Typ eine andere Zelle, die auf Schnittstelleneben aber gleich aussehen ...

Du schreibst: und hier liegt die größte Schwierigkeit: Die Bewegungszelle muß alle vorhandenen Antriebselemente steuern können, da ihr vorher nicht bekannt ist, was verwendet wird (ob sie Rad, Bein oder Kranarm ist...)!

Die Bewegungszelle ist das Antriebselemente und kennt sich mit diesem bestends aus ... Andere Antriebselemente kennt sie jedoch nicht.

Du schreibst: Auf diese Art bleiben nur wenige Roboterzellen übrig

Ja, ja und nochmals ja!

Du schreibst: Der Rest ist (wenn auch mit viel Elektrik) für mich aber Mechanik. Muß zwar sein, ist aber nicht unbedingt zellularer Roboter...

Das kapiere ich mal wieder nicht. --ZellRobi 17:32, 26. Jul 2008 (CEST)


Das Thema interessiert mich brennend, aber ich habe so meine Probleme mit dem Verständnis... Ich hab' da zwar jede Menge (guter?) Ideen, aber ZellRobi (seiner Vision sei Dank) hat jetzt mit seinem Thread zur Verbindung von Zellen meine Verwirrung vervollständigt...

Wie versteht ihr dieses System denn? Möglichst wenig verschiedene Zellen heißt für mich Trennung von (Roboter-)Elektronik von (elektrischer) Mechanik, ein Zusammenfassen von Funktionalitäten erhöht die Anzahl möglicher Zellen.
Sollte man das System auf 5 fix definierte logische Zellen mit variabler Mechanik oder auf (geschätzt) 30 verschiedene mechanisch-logisch-integrierte Zellen auslegen?

[ZellRobi]

Sollte man das System auf 5 fix definierte logische Zellen mit variabler Mechanik oder auf (geschätzt) 30 verschiedene mechanisch-logisch-integrierte Zellen auslegen?
Sollte man bei Deinen 5 logischen Zellen nicht auch die "Zellen" für die Mechanik mitrechnen? :-k

Ich möchte bewusst die Anzahl von Zellen nach oben hin offen lassen. Aber welche Zelltypen benötigt man z.B. für ein Minimalsystem:

Fahrender Roboter: Stromversorgung, Logik, Rad, Drehgelenk (für Lenkräder), Stoßsensor, ggf. noch Leerzellen, um Lücken zu füllen
Hexobot: Knickgelenk, Drehgelenk, Stoßsensor, Stromversorgung, Logik(Bestimmt habe ich da noch irgendwas übersehen) So viele verschiedene Zelltypen sind es doch garnicht.

Irgendwie meine ich, sind wir garnicht so weit auseinander. Nur habe ich es noch nicht so ganz begriffen, worauf Du hinaus willst.

Für mich ist eine Zelle eine beliebige Funktionalität (Beispiele s.o.), die sich an mechanische, elektrische und logische Schnittstellen hält. Sie hat gerade so viel von den Schnittstellen, wie sie selbst benötigt und für ein Miteinander erforderlich ist. ( :-s , das war jetzt anstrengend)

Was ist für Dich eine Zelle?

[williwilli]

Sollte man bei Deinen 5 logischen Zellen nicht auch die "Zellen" für die Mechanik mitrechnen?
Genau das ist meine Frage ...


Irgendwie meine ich, sind wir garnicht so weit auseinander. Nur habe ich es noch nicht so ganz begriffen, worauf Du hinaus willst.
Auf die eindeutige Aussage: "Eine Zelle ist ..."!


... die sich an mechanische, elektrische und logische Schnittstellen hält. Sie hat gerade so viel von den Schnittstellen, wie sie selbst benötigt und für ein Miteinander erforderlich ist ...
... und da ist mein Problem!

Diese Definition ist wahrscheinlich für die Zusammenarbeit der Zellen ausreichend, definitiv aber nicht für die Arbeit mehrerer Entwickler an so einem Projekt. Ich interpretiere Deine Aussage so, daß Du offen läßt, ob (abgesehen von der rein mechanischen Kompatibilität der Zellen) eine "mechanische" Funktion immer zu einer elektro-logischen Zelle gehört oder nicht. Und das klappt nicht!
Mit Deiner Definition kann eine Rad-Zelle die Steuerelektronik, das Getriebe, die Motortreiber, das dazugehörige Rad und die Odometrie enthalten; es kann aber auch bedeuten, daß diese fünf Teile fünf verschiedene Zellen sind!


Was ist für Dich eine Zelle?
Meine Definition: Eine Roboterzelle ist die kleinste mögliche Einheit, sie ist so ausgelegt, daß verschiedene Zellen nahezu beliebig miteinander kombinierbar sind. Eine mechanische Verbindung der Zellen untereinander ist einfach herzustellen. Die Definitionen der elektrischen und logischen Schnittstellen werden eingehalten, nicht benötigte Funktionen dieser Schnittstellen werden unverändert an benachbarte Zellen weitergegeben.
Eine Zelle stellt zudem immer (!) eine oder mehrere mechanische, elektrische oder logische Funktionalitäten bereit.

Damit ist klar: Steuerelektronik, Getriebe, Motortreiber, Odometrie und Rad sind "Bewegungzelle Rad"; Steuerelektronik und Servo wäre "Bewegungzelle Lenkung"; Steuerelektronik, mehrere Servos und Sensoren sowie Mechanik sind "Bewegungzelle Hexabot-Bein"; mit etwas verändertem mechanischem Aufbau aber auch "Bewegungzelle Greifarm"; etc. ..
Damit ist aber auch klar: Es gibt keine "nackte Mechanik". Keine Verbinder, keine Gelenkstücke, keine leeren Rahmenteile ... und nach dem Vorbild der Natur auch keine "Leerzellen" (hier könnten wir aber, wenn nötig, eine Ausnahme machen)...

... und mit solchen Vorgaben könnte ich auch leben (und arbeiten O:) )...

[ZellRobi]

... Diese Definition ist wahrscheinlich für die Zusammenarbeit der Zellen ausreichend, definitiv aber nicht für die Arbeit mehrerer Entwickler an so einem Projekt...

Zugegeben, sie ist nicht vollständig ausgeführt. Erst wenn die Schnittstellen exakt beschrieben sind, wird es für die Arbeit mehrerer Entwickler ausreichen. Aber gerade die exakte Beschreibung der Schnittstellen versuche ich unter den Roboterzellen (https://www.roboternetz.de/wissen/index.php/Roboterzellen).

Dann kann jeder einen Zelltyp völlig losgelöst entwickeln. Er braucht sich nur an die Beschreibung der Schnittstellen zu halten. Ein Teil seiner Entwicklungsarbeit ist es, die Eigenschaften des Zelltyps aufzuzeigen (und wie man ihn am besten bauen kann). Das ist Schritt 1.

Erst im zweiten Schritt baut man nach dem Roboterzellenprinzip "man nehme ..." den konkreten Roboter aus fertigen Zellen. In dieser Phase müssen die Detaills z.B. vom Roboterschwarm, festgelegt sein: Welche Roboter werden benötigt? Funktion, vielleicht auch Aussehen, die auszutauschenden Daten etc. Mit dem Prinzip der Roboterzellen haben wir jetzt aber auch die Möglichkeiten, "mal schnell umzubauen". Viele der "kleinen Probleme" sind dabei im Schritt 1 bereits erledigt worden, man kann sich auf das Wesentliche für den Roboter konzetrieren.


... Ich interpretiere Deine Aussage so, daß Du offen läßt, ob (abgesehen von der rein mechanischen Kompatibilität der Zellen) eine "mechanische" Funktion immer zu einer elektro-logischen Zelle gehört oder nicht. Und das klappt nicht!
Mit Deiner Definition kann eine Rad-Zelle die Steuerelektronik, das Getriebe, die Motortreiber, das dazugehörige Rad und die Odometrie enthalten; es kann aber auch bedeuten, daß diese fünf Teile fünf verschiedene Zellen sind! ...
Ja, jetzt beginne ich zu verstehen :? . Das kann natürlich so nicht funktionieren. Deswegen s.o. Schritt 1 (Unterschritt 1): Man einigt sich vorab, welche konkreten Zelltypen man benötigt und grenzt deren Funktionalitäten klar voneinander ab. Erst dann hat jeder seine Vorgaben und kann die Realisierung seines Zelltyps so machen, wie er es will.

Das Ganze ist immer ein Wechselspiel zwischen gemeinsamer Abstimmung und eigenständiger Entwicklungsarbeit. :)


... Eine Roboterzelle ist die kleinste mögliche Einheit. Sie ist so ausgelegt, daß verschiedene Zellen nahezu beliebig miteinander kombinierbar sind. Eine mechanische Verbindung der Zellen untereinander ist einfach herzustellen. Die Definitionen der elektrischen und logischen Schnittstellen werden eingehalten, nicht benötigte Funktionen dieser Schnittstellen werden unverändert an benachbarte Zellen weitergegeben.
Eine Zelle stellt zudem immer (!) eine oder mehrere mechanische, elektrische oder logische Funktionalitäten bereit....

Hättest Du etwas gegen eine leicht Umformulierung einzuwenden?
Eine Roboterzelle ist die kleinste mögliche Einheit, sie ist so ausgelegt, dass mehrere Zellen möglichst beliebig miteinander kombinierbar sind. Eine mechanische Verbindung der Zellen untereinander ist einfach herzustellen und wieder zu lösen. Zusätzlich werden elektrische und logische Schnittstellen eingehalten. Nicht benötigte Funktionen dieser Schnittstellen werden unverändert an benachbarte Zellen weitergegeben.
Eine Zelle stellt zudem immer (!) eine oder mehrere mechanische, elektrische und logische Funktionalitäten bereit.


... und mit solchen Vorgaben könnte ich auch leben (und arbeiten O:) )...

Ich hoffe, es geht auch mit den Änderungen...

Dann wäre nämlich meine Frage, was als nächstes ansteht. Ich glaube, die Schnittstellendefinitionen müssten weiter vertieft werden. Ich war gerade dabei, mir Gedanken über die logische Schnittstelle zu machen, als mir auffiel, dass man diese intensiv praktisch erproben muss. Für die Platinen benötige ich aber die mechanische Schnittstelle. Also habe ich dort eine Diskussion angefangen und hoffe, dass auch so ein verblüffendes Ergebnis herauskommt, wie bei der I2C-Schnittstelle ...

[williwilli]

Erst wenn die Schnittstellen exakt beschrieben sind, wird es für die Arbeit mehrerer Entwickler ausreichen.
Stimmt schon, aber: Auch die Beschreibung der Möglichkeiten ist doch schon Entwicklungsarbeit. Deswegen habe ich auf eine eindeutige Definition gedrängt...


Hättest Du etwas gegen eine leicht Umformulierung einzuwenden?
Nichts einzuwenden: Zwischen "nahezu" und "möglichst" sehe ich keinen großen Unterschied. Ich wollte nur verhindern, daß einer auf die Idee kommt, zwei Logikzellen parallel zu verwenden oder an der Rad-Seite einer Zelle noch eine weitere Zelle anfügen zu wollen... O:)
"...verbinden und lösen..." Klar! Kleben ist nicht ...

Ansonsten: Sieht bis hierhin doch schon gut aus!


Dann wäre nämlich meine Frage, was als nächstes ansteht ... Ich war gerade dabei, mir Gedanken über die logische Schnittstelle zu machen ...
Die elektrische Schnittstelle ist vorgegeben, wenn wir uns an die RN-Definitionen halten wollen. Über die Mechanik der Zellenverbindung würde ich mir Gedanken machen, wenn wir ein paar Zellen fertig haben und das Zusammenspiel testweise funktioniert (Zur Not wird alles an ein Brett geschraubt. Es schadet aber nicht, mal nachzufragen, vielleicht gibt es ja geniale Ideen).
Die Logik macht mir Probleme. Nach Deiner Beschreibung im RN-Wiki klingt das, als ob jede Zelle auch einige Speicherbereiche anderer Zellen aktualisieren darf. Wie soll das gehen? Auch die Möglichkeit/Notwendigkeit (?), verschiedene Zellen im Verbund von außen zu reprogrammieren, läßt mich ziemlich ratlos schauen... Du solltest diesen Teil dringend genauer spezifizieren!

[ZellRobi]

Ja, die Logik ist reizvoll. Bin gerade dabei, eine passende Syntax zu entwerfen, um das bei den Roboterzellen angekündigte Beispiel fertigstellen zu können.

Um das dann nach und nach in ein Programm (Betriebssystem) gießen zu können, benötige ich aber irgendwann einen Versuchsaufbau: eine Ein-/Ausgabezelle und eine oder zwei Logikzellen. Da hätte ich ganz gerne bereits die erforderliche passende Mechanik dazu gehabt ...

Natürlich haben die meisten Zellen eigene Speicherbereiche: jede sollte einen Controller haben, zumindest wenn sie eine elektrische Funktion ausführt (reine Mechanik benötigt das nicht). Denn die Kommunikation verläuft ausschließlich über die gemeinsamen Speicherbereiche. Ein paar Grundgedanken hatte ich ja bereits dargestellt (Roboterzellen), demnächst geht es weiter ...

[ikarus_177]

wenn ich mich da mal einmischen dürfte: soweit ich das jetzt mitbekommen habe, ist ja das Ganze so was wie ein Baukastensystem, mit dem man seinen eigenen Roboter "zusammensteckt".

Für meinen Bot (Hexa) hab ich so was in abgespeckter Form gedacht. Eine Reihe von Platinen, die jede eine bestimmte Aufgabe hat, werden beliebig auf einer Haupt/Trägerplatine montiert und kommunizieren untereinander. Bei mir gibt es da Platinen für die Steuerung der Füße, welche für die Ansteuerung der Sensoren usw. Ich will das Ganze System so auslegen, dass man die Anzahl der Platinen beliebig erhöhen kann, ein Hauptprozessor erkennt dann die neue Platine und fragt ab, von welchem Typ sie ist (Steuerung, Anzeige, Sensoren,...), welche Befehle sie versteht und was sie zu bedeuten haben. Diese Informationen soll der Master dann abspeichern, auf Ihnen soll dann die Kommunikation fußen.

Das wäre meine "Interpretation" der Zellen


Viele Grüße
ikarus_177

[ZellRobi]

Was heißt da denn "einmischen"? Beiträge sind doch willkommen!

Wie kommunizieren denn die Platinen mit dem Hauptprozessor?

[ikarus_177]

Hi,

ich hätte zuerst auch I2C gedacht (willst ja du auch für dein System verwenden?), bin dann aber auf parallel umgestiegen. Auch da gibt es Vor- und Nachteile. Ausschlaggebend für meinen Umstieg war, dass wenn ich ein eigenes Bussystem habe, ich viel mehr Freiheiten beim Protokoll usw. hab, wie wenn ich beim I2C die vorgefertigten Routinen nutzen muss. Außerdem ist die Übertragungsgeschwindigkeit fast ein wenig höher als beim I2C.

Für I2C/TWI spricht allerdings das "schon hardwaremäßige Vorhadensein" auf den ATMegas (welche Controller willst du eigentlich Verwenden?)sowie die einfachere Verkabelung mit nur zwei Ports (gegenüber der 16 in meinem System ein ganz schöner Unterschied).


...zellulare Bots...

willst du da auch den Körper/die mechanischen Aspekte des Bots aus diesen Zellen aufbauen? Wenn ja, wie groß sollen diese werden und welche Form sollen sie haben? Wenn wir als Beispiel mal einen Hexa nehmen, willst du dann die für die Steuerung der Beine nötigen Zellen in die Beine integrieren oder gar die Beine aus solchen Zellen aufbauen? Oder sollen diese im Körper des Roboters ihren Platz finden?

Evtl. könnte man die Zellen im Körper wie beim LEGO übereinander stapeln, ebenso mit kleinen "Zapfen" für die elektrische und mechanische Verbindung.

Die softwareseitige Umsetzung ist meiner Meinung nach ein sehr spannendes Thema. Der Master fragt am Anfang alle vorhandenen Zellen ab, diese könnten ihrerseits auch einen "Selbsttest" der ihnen anvertrauten Komponenten machen. Alle Zellen bekommen eine Adresse zugewiesen, über die sie der Master ansprechen kann.

Alle diese Kommunikationsvorgänge könnte man zum Schluss in bequeme Routinen verpacken (vllt. auch eine eigene Lib erstellen), die es dem Endanwender ermöglichen, eigene Software für den Zellenbot zu schreiben, die dann nur noch am Hauptprozessor aufgespielt werden müsste. Kommen neue Funktionen hinzu, müsste natürlich auch ein Firmware-Update der einzelnen Zellen gemacht werden. Da muss man aber auch wieder darauf achten, dass das möglichst Benutzerfreundlich geschieht.

Ich finde, das ist ein sehr interessantes Thema!

Viele Grüße
ikarus_177

[ZellRobi]

... Ja, die Logik ist reizvoll. Bin gerade dabei, eine passende Syntax zu entwerfen, um das bei den Roboterzellen angekündigte Beispiel fertigstellen zu können ...

Das angekündigte Beispiel ist unter Roboterzellen: Syntax (https://www.roboternetz.de/wissen/index.php/Roboterzellen:_Syntax#Beispiel) fertiggestellt worden. Da steht zwar erst viel formaler Kram am Anfang, aber gegen Ende kommt ein kleines Beispiel. Dort wird aus logischer Sicht (Programmierung) dargestellt, wie ein Roboter zusammengebaut und programmiert werden kann.

[einballimwas]

Meine Vorstellung wäre:

-Gehirnzelle
-Aktorzelle (also für bewegung, greifen, alles was eine aktion erfordert)
-Sensorzelle(Aussenwelt wahrnehmen)
-Navigationszelle (GPS, kompassmodule, etc..)
-Kommunikationszelle(Sprachmodul, etc..)

[ZellRobi]

... Für I2C/TWI spricht allerdings das "schon hardwaremäßige Vorhadensein" auf den ATMegas (...) sowie die einfachere Verkabelung mit nur zwei Ports ...
Ja, das mit den Ports war der eigentliche Grund für I2C: Ein Würfel hat 6 Seiten und es werden wohl viele Würfel werden ... also sollten so wenig Verbindungsleitungen verwendet werden, wie möglich.

Welche ATMegas verwendet werden sollen? Ich dachte an den 32, vielleicht auch den 128, mal sehen, wieviel Speicher das Betriebsystem verbraucht. Für den zweiten Port soll auf jeder Logikzelle auch der 8 eingesetzt werden. Ziel ist jedoch: ausreichend Leistung für einen möglichst kleinen Preis.


... willst du da auch den Körper/die mechanischen Aspekte des Bots aus diesen Zellen aufbauen? Wenn ja, wie groß sollen diese werden und welche Form sollen sie haben? ...
Eigentlich soll der gesamte Bot nur aus Zellen bestehen. Um beim Aufbau der Zellen Klarheit zu gewinnen, habe ich die Diskussion unter Wie werden zwei Roboterzellen verbunden? (https://www.roboternetz.de/phpBB2/viewtopic.php?t=42009) angefangen.
Langsam zeichnet sich (zumindest für mich) da eine Lösung ab.
Die Größe richtet sich nach der Größe der Stecker und Buchsen für die elektrische Verbindung. Daraus wird ein möglichst kleiner Würfel erstellt, der die Basisgröße vorgibt. Die Zellen können dann so groß werden, wie es erforderlich ist. Sie müssen nur in das Raster der kleinen Würfel passen. Bei LEGO gibt es auch den kleinsten Stein (1-er Knopf). Die Anderen sind ein Vielfaches davon (z.B. 2 mal 4 Knöpfe).


... Wenn wir als Beispiel mal einen Hexa nehmen, willst du dann die für die Steuerung der Beine nötigen Zellen in die Beine integrieren oder gar die Beine aus solchen Zellen aufbauen? Oder sollen diese im Körper des Roboters ihren Platz finden? ...
Sagen wir mal so: ich will die Zellen bauen. Derjenige, der daraus Roboter bauen möchte, kann das nach seinen Anforderungen selbst bestimmen, wo was hin soll. Wenn Platz ist in der Beinlänge, weshalb soll er da nicht auch Logikzellen einbauen? Andernfalls halt im "Bauch". Sicherlich muss bei der Planung des Roboters auch das Kommunikationsaufkommen bzw. die Laufzeit der Informationen berücksichtigt werden. Irgendwo sind da Grenzen und es ist sicherlich ein Ziel, Informationen so früh wie möglich und nahe am Ort des Entstehens zu verarbeiten.

Für mich heißt das: Möglichst wenig Einschränkungen für den Zusammenbau der Zellen verursachen. Das ist bei der Entwicklung der Zelltypen zu berücksichtigen.


... Die softwareseitige Umsetzung ist meiner Meinung nach ein sehr spannendes Thema. Der Master fragt am Anfang alle vorhandenen Zellen ab, diese könnten ihrerseits auch einen "Selbsttest" der ihnen anvertrauten Komponenten machen. Alle Zellen bekommen eine Adresse zugewiesen, über die sie der Master ansprechen kann. ...
Für die Roboterzellen stelle ich mir das derzeit etwas anders vor: Die Zellen werden beim Zusammenbau in Ringe (I2C-Bus) zusammengefasst und es wird ein Master für jeden Ring festgelegt. Das entspricht der Zuordnung der Adressen. Aber es gibt grundsätzlich viele Ringe im Roboter und keinen klaren obersten Chef.

Wie könnte denn das Abfragen aller vorhandenen Zellen am Anfang aussehen? Die Slaves haben dann doch noch keine Adresse ...


... Alle diese Kommunikationsvorgänge könnte man zum Schluss in bequeme Routinen verpacken (vllt. auch eine eigene Lib erstellen), die es dem Endanwender ermöglichen, eigene Software für den Zellenbot zu schreiben, die dann nur noch am Hauptprozessor aufgespielt werden müsste. Kommen neue Funktionen hinzu, müsste natürlich auch ein Firmware-Update der einzelnen Zellen gemacht werden. Da muss man aber auch wieder darauf achten, dass das möglichst Benutzerfreundlich geschieht. ...
Hier gehe ich den Umweg über eine neue Programmiersprache. Der Anwender von Roboterzellen, also derjenige, der den Roboter zusammen baut, arbeitet nur mit dieser Programmiersprache. Die Entwickler von Zelltypen könnten so eine Lib bekommen und so arbeiten, wie Du es beschreibst.

Neue Funktionen heißen prinzipiell neue Zellen. Eine Zelle ist eine Einheit: Mechanik, Elektrik und Logik (Controller mit Programm) sind funktionsfähig und fest definiert. Der Controller kennt sich sozusagen bestens mit seiner Zelle aus. Für Andere Zellen sichtbar ist lediglich das Abbild der Sensoren und Motoren in Speicherbereiche vom Controller. Über die Programmiersprache werden dann diese Speicherbereiche miteinander verbunden und es werden Regeln für die Verarbeitung aufgestellt.

So sind zumindest meine Vorstellungen.