@UlrichC:
Ok, das mit der GUI klingt ja super so. Klingt zwar auch
nach viel Arbeit aber wenn du dich anbietest da ein
Grundgerüst zu schreiben

Eins möchte ich aber noch klarstellen:
Das System wie ich es hier geplant habe (nennen wir es mal
uCom) und smirs sind zwei verschiedene Paar Stiefel. Beide
haben zwar ähnliche Ziele (Kommunikation zwischen Roboter-
modulen) aber unterschiedliche Voraussetzungen, vor allem
in der Hardware. Smirs erfordert relativ große Rechner mit
IP-Anbindung. uCom hingegen soll bis hinunter zum kleinsten
uC skalieren. Der Nachteil von uCom ist natürlich, das das
System Beschränkungen hat, dafür kann man eben auch Roboter
die nur auf uCs aufbauen noch anschliessen (und das sollten
die meisten hier im RN sein).

Noch was: Beide Systeme sind dafür ausgelegt, mehrere Roboter-
komponenten und u.U. auch mehrere Roboter zu verbinden. Der
Plan ist, die GUI dann als einen Teil in diese Infrastruktur
einzuklinken. Es ist also nicht der Plan, hinter dem Application
Server bzw. der GUI noch weitere Applikationen/Roboter
anzuschliessen. Wenn man es gratis dazubekommt soll es mir
natürlich recht sein, aber es sicher kein Designziel.

Und jetzt noch ein Wort zu SOAP. Prinzipiell finde ich die
Idee mit SOAP/XML schon ziemlich reizvoll, insbesondere weil
man typisierte und selbstbeschreibende Daten/Funktionen verwenden
kann. Allerdings ist SOAP auch ein Protokoll, das nicht unbedingt
wenig Overhead erzeugt (in der Übertragung und in der Verarbeitung).
Auf einem PC mag das tragbar sein, auf einem uC mit zweikritischen
Aufgaben aber nicht. Ich hatte bisher immer ein Datenformat mit
einem Byte 'Command' im Auge, der dann implizit die Struktur der
restlichen Daten bestimmt. Wobei es natürlich auch möglich wäre,
das es ein Command 'SOAP' gibt, das nun mal nur die dickeren bzw.
die nicht zeitkritischen uCs implementieren.

ciao,
Georg