Moin,
das erste, was wir brauchen, ist ein Schema, dass keine Wünsche übrig lässt.

Ja, matren, das Grundlegende ist ein Bussystem und ich tendiere da zu TCP, da es von vielen Programmiersprachen verstanden wird und dann auch übers Netz Komponenten kommunizieren können, sogar mit unterschiedlichen Betriebsystemen.

Jede Komponente ist dann somit ein eigenständiges Programm, was auch sehr sicher ist und das System praktisch nicht durch eine Komponente aufgehängt werden kann.

Ich kann ja nochmal etwas meine Zeichnungen erläutern.

Aufbau der Software
Das grundlegende Element der Software ist die main control. Obwohl sie relativ simpel aufgebaut sein kann, hat sie grundlegende Aufgaben und muss schnell sein. Wichtig ist hier die Plattformunabhängigkeit, da dieses Modul auf allen Robotern oder Kontrollrechnern istalliert ist. Also, wir wiollen einen Roboter und einen Kontrollrechner vernetzen, dann muss auf beiden Geräten die main control installiert sein. (dazu weiter unten noch mehr)

Über den Gateway werden Informationen ausgetauscht. Deshalb sollte auch der Gateway plattformunabhängig sein.

So, dann kommen die Addons, und in ihnen unterscheidet sich der Roboter von dem Kontrollrechner. Addons können alle Aufgaben übernehmen.

Möglichkeiten
Der Roboter wird seine Motoren und Sensoren wahrscheinlich über einen Microcontroller ansteuern. Deshalb muss die Software mit einem Addon versehen werden, über das sie mit dem Controller kommunizieren kann. Schließlich kann der Controller mit großer Wahrscheinlichkeit nicht TCP, weshalb das Addon zwischen TCP und z.B. Serieller vermitteln muss. Dieses Interface hängt vom Controller ab, und natürlich muss auch auf dem Controller etwas programmiert sein, dass mit dem Addon kommuniziert. Wahrscheinlich muss hier jeder Anwender für seinen Anwendungszweck etwas programmieren, aber man könnte Beispielcode liefern. Das hängt natürlich etwas davon ab, wie bekannt und verbreitet unsere Software wird.

Jetzt muss aber irgendwo noch das Verhalten des Roboters geregelt werden. Das macht man ja normalerweise auf dem Controller. Wenn man allerdings einen Rechner auf dem Roboter hat, kann man das verhalten natürlich mit einer höheren Programmiersprache programmieren. Das ist ja dass, was Numberfive und ich vorhaben, unabhängig von diesem Projekt.
Die Verhaltenssteuerung kommuniziert auch per TCP mit dem Rest der Software und kommt so an Sensorwerte, kann Motoren ansteuern und auf andere Addons zugreifen. Zum Beispiel auf ein Kamera-Addon. Das schöne hieran ist natürlich, dass man das Verhalten ändern kann, ohne an den anderen Modulen rumfummeln zu müssen.

So, jetzt kommt etwas, was nicht unbedingt so sein muss, wie es in meiner Grafik ist. Nämlich das Kommunikations-Addon. Theoretisch könnte man, um eine WLan-Verbindung herzustellen, direkt an den Gateway rangehen, da Wland ja auch über TCP läuft. Das würde heißen, dass es nicht zwei Gateywas, also der vom Roboter und der vom Kontrollrechner, sondern nur einen gibt, den sich beide teilen und der teilweise über Funk läuft. Das gefällt mir eigentlich noch besser.

Aber dazu muss ich sagen, dass ich mich mit Netzwerkprogrammierung NOCH nicht gut auskenne und deshalb nicht weiß, wie gut das zu realisieren ist.

Die Kontrollsoftware hat natürlich andere Addons. Zum Beispiel eine GUI, mit der der User den Roboter steuern kann, also Befehle senden kann, etc.

Soweit zum Aufbau, jetzt kommt was zur main control.
Hier habe ich viele Ideen, schließlich ist es das Herz des ganzen Systems.

Wir haben ja den Gateway, durch den Nachrichten geschickt werden können. Hier müssen wir uns also ein System überlegen, über den zum Beispiel die Verhaltenssteuerung an die Daten des Kamera-Addons kommt. Hier würde ich vorschlagen, dass es ein onDemand-Prinzip wird. Die Verhaltenssteuerung sendet eine Anfrage, die Daten kommen zurück. Auch hier kann es natürlich Abwandlungen geben, zum Beispiel, dass es das Kameramodul der VErhaltenssteuerung oder einem anderen Addon im System ermöglichst, sich anzumelden, sodass automatisch die Daten zugeschickt werden. Wenn also alle 10 Sekunden etwas von der Kamera zur Verhaltenssteuerung (VS) übertragen werden soll, könnte sich die VS in einer Verteilerliste der Kamera eintragen. Damit würde man sich das Demand sparen und den Bis entlasten.

Was aber noch wichtiger ist, ist das Veröffnetlichen von Daten, und das übernimmt die main control. HIer können Variablen definiert werden, in die von überall etwas eingetragen werden kann. Ich werde, wenn wir das System irgendwann mal fertig haben, ein Addon programmieren, mit dem der Roboter Hinternisse in eine Karte einzeichnen kann und den Weg dadruch berechnen kann (das habe ich ja im Rahmen meiner Jufo-Arbeit schon programmiert).

Jetzt wäre es aber sehr praktisch, wenn die Karte global verwaltet wird, und auch andere Roboter etwas in die Karte einspeichern könnten. Somit könnten mehrere Roboter organisiert werden und zusammen ein Gebiet erkunden. Dafür ist es wichtig, dass sich alle Main-controls untereinander abgleichen. Wenn man also auf dem PC die Karte editiert, muss sie automatisch auf allen Robotern aktualisiert werden.

Auch wenn das schon relativ kompliziert ist, könnte unsere Software für sowas einen großen Beitrag leisten.

Soweit zu meinen Ideen, und sorry, dass es wieder so viel Text geworden ist ;-)

Gruß
Johannes