Roboterzellen

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