Projekt Steuersoftware - Interesse?

Hallo, ich hab da gerade so eine fixe Idee: Ich bin z.Zt. dabei einen Bot zu bauen der u.a. auch per WLAN vom PC aus gesteuert werden soll. Eine erste Beta der Steuersoftware (vb.net - nicht hauen bitte) ist fertig, aber eben auf genau den einen Bot zugeschnitten. Die Idee: Warum nicht eine Software daraus machen, mit deren Hilfe man unterschiedlichste Bots steuern kann, und zwar einerseits ohne sich um die Basisprogrammierung kümmern zu müssen, andererseits aber mit der Möglichkeit, jederzeit Komponenten zu ändern bzw. zu ergänzen. Hier mal ein paar Gedanken dazu:

- Die Software müßte modular aufgebaut sein, so dass sich die benötigten Komponenten durch "zusammenklicken" eines Views anzeigen lassen

- Komponenten könnten sein: Fahrtsteuerung, Kamerasteuerung, Schaltfunktionen, Anzeige des Videobildes der OnBoard-Kamera, Odometrie-Auswertung, Nachrichtenaustausch vom und zum Bot etc.

- die Software müßte sich in hohem Maße konfigurieren lassen (verfügbare Eingabegeräte wie Joysticks, Tastenbelegungen etc),

- die Software müßte es ermöglichen, unterschiedliche und ebenfalls frei konfigurierbare Bots zu unterstützen (d.h. es müßte Modelle für unterschiedliche Antriebsvarianten und Zusatzausstattungen geben)

- die Buttons / Schalter in der Software müßten im Rahmen der Konfiguration frei beschriftbar sein (z.B. "Licht)

- es müßten unterschiedliche Kommunkationsvarianten unterstützt werden (RS232, Parallel,...)

- Der Befehlssatz müßte auch konfigurierbar sein

Hier mal ein kleines Szenario:

- Jemand hat einen Bot mit Kettenantrieb und möchte den per PC über eine irgendwie geartete Funkstrecke via RS232 steuern. Der Bot hat eine Kamera an Bord, ein LCD-Display, verschiedene Sensoren etc
- In der Steuersoftware legt sich dieser Jemand nun einen neuen Bot an, wählt als Antriebsvariante "Kettenantrieb", als Eingabegerät einen angeschlossenen Joystick und klickt sich im Rahmen eines Konfigurationswizards noch die weiteren Komponenten zusammen.

- Im nächsten Schritt ordnet der Jemand den einzelnen Komponenten die Befehle und Befehlsarten (ein/aus, numerischer Wert...) zu und wählt die entsprechenden Eingabegeräte (Joystick-Achse, Tastaturbefehl, Button in der Software)

- Dann baut sich der Jemand seinen View (also die Oberfläche) zusammen, indem er aus den vorher konfigurierten Modulen die auswählt, die er aktuell sehen möchte

- jetzt muss noch auf Bot-Seite die Verarbeitung der Befehle implementiert werden und los gehts.


Jetzt meine Frage: Könnt ihr Euch vorstellen dass sowas sinnvoll ist? Wenn ja, wer hat noch ideen dazu / wer hat Lust das ganze in einer Art OpenSource-Projekt mitzumachen?
Oder lohnt es sich am Ende nicht weil nur 2 Leute Interesse daran haben...Fragen über Fragen. Wenn Interesse besteht würde ich meine bisherige Idee im nächsten Schritt mal etwas weiter ausarbeiten und veröffentlichen, um die Machbarkeit und Sinnhaftigkeit etwas mehr im Detail abschätzen zu können.

Hi!

Interessante Projektidee.
Im Forum gibt es nun einige VB Programmierer (ich gehöre nicht dazu), daher ist diese Sprache vermutlich sogar die richtige Wahl wenn es darum geht so ein Projekt hier auf die Beine zu stellen.

So ein Programm richtig zu modularisieren das ist hier die Kunst.
Du müsstest nicht nur die Befehle variable machen, sondern auch die "Protokolle" mit denen sie übertragen werden (nicht jeder sendet einen 1 Byte großen Befehl).

Grundsätzlich wäre eine solche Software zumindest bei Einsteigern sicher beliebt. Ob man es schafft jeden "Spezialwunsch" den ein Roboterverrückter so hat beachten zu können das wage ich mal zu bezweifeln.

Aber nur Mut! Wäre garantiert eine feine Sache sowas mit Leuten außem Forum zu entwickeln.

mfg
Batti

Hi!

klingt interessant, ich versuch mich auch grad an so ner Steuersoftware, bin zwar kein so guter programmierer, aber ich würd schon mitmachen

Vielleicht hätte ich da was für Dich:
https://www.roboternetz.de/phpBB2/vi...=197512#197512

Das firmiert unter dem Titel:
Open Source Software Projekte » Rnbfra Multi-Thread und Netzwerkfähig mit GUI im www, jetzt

M.E. passt Deine Idee perfekt in die Landschaft. Würde mich freuen wenn Du den Thread mal überfliegst. Wir sind an verschiedenen Punkten schon recht weit.
Kann sein das Du da mitmachen willst, weil auf der VB-Seite echt noch was fehlt.

Netter Gruß

heyho, sehe ich da Interesse?? Schön. Also, zu den Fragen und Anregungen bis hierher:

@batti112: es jedem Recht zu machen ist sicherlich nicht möglich, aber eine modulares Konzept in das jeder nach belieben eigene Module einhängen kann wäre vielleicht zumindest eine Basis, bei der nicht jeder das Rad neu erfinden muss sondern sich auf die Themen konzentrieren kann die ihn aktuell beschäftigen.

@kalletronic: schön. was hast Du denn bisher schon fertig? Welche Prog.Sprache? Welche Funktionen?

@marvin42x: ich hab den thread mal überflogen...da habt ihr ja schon richtig Arbeit drinstecken. Mit smirs hatte ich noch nichts zu tun, klingt aber für das was ihr da vorhabt sehr vernünftig.

Ich hatte das Protokoll bisher einfacher geplant, so in der Art 1 Byte CommandType und je nach Commandtype n Bytes Daten, wobei die Umsetzung komplett Controllerseitig erfolgen würde (dem PC sind also keine I2C-Adressen o.ä. bekannt). Eine Nachrichtenübermittlung ans LCD-Display würde z.B. folgendermaßen aussehen: 1Byte CommandType (Message2LCD), 1Byte Message-Länge, nBytes Text.
Diese Variante ist sicherlich Fehleranfälliger (keine Prüfsumme etc), ist aber 1. für erste Erfolge gedacht und sollte sich 2. jederzeit ersetzen lassen. Damit wären wir beim Thema: Mein Vorschlag wäre, die PC-SW soweit Modular aufzuzbauen, dass auch das Protokoll konfigurierbar ist. Dadurch wäre es dann möglich, eine "einfache Variante" (s.o.) zu haben, die für Testzwecke, Experimente usw. ausreichend ist. Dann könnte man aber zusätzlich eine smirs-Implementierung einbauen und die SW auch in eurem Szenario verwenden.

Ich werde mal ein Systembild dazu malen wie ich mir das vorstelle, dann können wir ja mal sehen ob wir die Welten zusammenbekommen bzw. wo es Problemzonen gibt die es wegzumassieren gilt.

Gruss,

Hinrich

Anmerkung:
Der Thread, den ich genannt habe ist ein unübersichtlicher Riesentrumm. Deswegen die Info:

smir in der ursprünglichen Form haben wir nicht mehr im Mittelpunkt. Wesendliche Aspekte davon sind aber im Konzept erhalten geblieben.

Der grundsätzlicher Entwurf eines Multi-Thread Betriebssystem von PicNick für den Mega32 läuft bereits zu Testzwecken (kann man sich runterladen).

Die Serielle Kommunikation zwischen Mega32 und PC mit einem universellen Standartprotokoll ist verfügbar und läuft bereits. (kann man sich runterladen)

Ein Testserver der die serielle Schnittstelle handhabt und die Datensendungen per TCP/IP zur Verfügung stellt läuft bereits.(kann man sich runterladen)

Ein Testserver der die Daten über Broadcast zur Verfügung stellt existiert ebenfalls.(kann man sich auch runterladen)

z.Z entsteht gerade ein Multimaster I2C Netz, welches hauptsächlich die Kommunikation zwischen Micro-Controllern ermöglichen soll und sich nahtlos in das Gesamtnetzwerk integriert.

Eine grafische Benutzeroberflächen (GUI) fürs Internet ist im entstehen.
Eine grafische Benutzeroberflächen in VB für den Lokalen PC fehlt.

Die ganze Sache ist im Wiki-Bereich ausgiebig dokumentiert.

So, erstmal genug geschrieben, mehr auf Anfrage ;-)

Netter Gruß

Fortsetzung:

Ja, ein modularer Aufbau ist auch aus meiner Sicht die Lösung.
Auch die Option vom austauschbaren Protokoll für low-Level Versuche wäre schön.
PicNick hat in einem seiner Weisheitsanfälle bereits auf diesem Gebiet sehr modular programmiert. (Hoffendlich haut er mich nicht wenn er das liest ;-) ).
Gerade für Beginner wäre eine Einstiegsvariante die sie verstehen sinnvoller.
Besonders wenn diese stückweise aufgerüstet werden kann zu dem eleganten Fortgeschrittenen-Modell.


Netter Gruß