Idealvorstellung smirs

Ich habe mir natürlich auch ein paar Gedanken zum Thema
gemacht, wie es später aussehen könnte. Diese möchte ich euch
nicht vorenthalten denn darauf bauen alle meine Überlegungen.

Feststellungen vorab:
1.) das Projekt ist für RN-User gedacht
2.) im RN gibt es bisher keine Ethernetfähige Hardware
3.) die verbreitetste Kommunikationsform im RN ist
seriell über Kabel und seriell über RN-Funk,
teilweise seriell über das Bluetooth SSP
4.) WLAN-Verbindungen direkt zum Roboter sind selten
(Embedded Linux oder Laptop auf Roboter)
5.) PCs auf denen die GUI bzw. die Logik läuft
sind meistens Desktops.
6.) Die GUI des PCs sollte möglichst einfach mit
der existierenden HW kommunizieren können.

Meine Vorstellungen. Ein Beispiel für die Flexibilität von
smirs. Um nicht allzusehr auszuufern, konzentriert sich dieses
Beispiel erstmal auf die niedrigen Ebenen.

Am Anfang hat User X nur ein RN-Control. Dieses verbindet
er über die serielle Schnittstelle mit dem Rechner. Auf
dem uC läuft ein Motormodul, das über eine smirs-GUI auf
dem PC gesteuert werden kann.

Jetzt kauft User X ein serielles Funkmodul und einen
weiteren Motortreiber der über I2C mit dem RN-Control
verbunden wird. Auf der RN-Control läuft eine kleine
smirs-Brücke von I2C nach RS232. Für seinen PC schreibt er einen
Kartographierungsalgorithmus. Ohne Änderungen der Software
können mit smirs jetzt der Motortreiber, das RN-Control,
der Kartograph und die GUI kommunizieren.

Schlussendlich legt sich User X einen Laptop mit WLAN
zu. Der Kartograph läuft nun auf dem Laptop, der
Motortreiber und RN-Control sind über je eine serielle
Schnittstelle am Laptop angeschlossen. Die GUI läuft
weiterhin auf dem Rechner. Und das alles dank smirs
ohne Softwareänderungen.

ciao,
Georg