Rnbfra Multi-Thread und Netzwerkfähig mit GUI im www, jetzt

[Johannes]

Tja, man muss wissen, was man will. Aber ehrlich gesgt verstehe ich dein Problem nicht.

Gruß
Johannes

[marvin42x]

Wenn ich das jetzt richtig interpretiere hängt die Latte im Moment sehr hoch.
Wäre es vielleicht hilfreich den Anspruch erstmal etwas zu verkleinern um eine erste Vorversion in Leben zu rufen.
Damit hätte dann die zweite Generation Gedanken die Chance zu entstehen.
Wenn wir mit Version 0. 1 beginnen würden, wären wir weiter als wenn wir jetzt aufhören.

Wenn wir erstmal was beispielsweise machen und nicht gleich beispielhaft. Microsoft hat mit FAT16 angefangen Linux hat auch schon das dritte oder vierte Dateisystem.

Falls ich falsch liege mögt Ihr mir das nachsehen da ich einfach nicht den vollen Überblick über alle Für-und Wieder habe.
Den Microkontroller vom Textparsen und String-Konvertierungen zu bewahren finde ich gut. Das spart Microcontroler-Rechenzeit und Datenverkehr.
@Johannes:Was schweb dir als PC-GUI vor? Also der Bereich wenn die seriellen Daten angekommen sind. *neugierig Hals reck* sind bald Semesterferien?

Quellenverweis:
Hier gibt es das Beispiel-Betriebssystem Back1.bas 1.0 für das rnbfra 1.2 welches ich gerne verwenden wollte.
https://www.roboternetz.de/phpBB2/dl...le&file_id=262

Netter Gruß aus der eisekalten Hauptstadt

[PicNick]

a..kalte Hauptstadt hab' ich selber *brrrr*
Bin ganz bei dir.
Was den PC-Aspekt betrifft, würde ich (werde ich) den Weg gehen, zumindest vom Design her eine spezialisierung auf irgendeine Plattform/Spache zu vermeiden. Hat zwar den Nachteil, daß man Goodies nicht sosehr ausnutzen kann, aber den Vorteil, daß man sie eben auch nicht braucht.
Das, was die Kommunikationssaftware betrifft, hat auch mit einer speziellen Gui nix zu tun. Ob ein PC Module seine Werte graphisch mit Zeiger, Balken oder sonstwie darstellt oder nur mitloggt, ist ja seine Sache.
Um eine Schnittstelle zu definieren, müssen die erforderlichen Daten und die Verhaltensweisen festgelegt werden, bevor auch nur eine Code-Zeile geschrieben wird.
Die besten Erfindungen sind immer noch wo abgeschrieben. Wenn man die ip-sockets als vorbild nimmt (und auch andere Netzwerke funktionieren ähnlich), sieht man ja, wie's läuft und was man etwa braucht.
Dann könnt' man analysieren, wieweit sich das (vernünftig) auf Controllern abbilden läßt.
Am Back1 hast du ja gesehen, daß relativ geradaus aus Comm-Messages eine interne Message gemacht werden kann.
Back1 ist ja schwer belastet durch die ANSI-Herumwurstelei, die ja sofort entfallen würde, wenn statt eines bescheuerten Terminals eine PC-Applikation draufhinge. (--> Marsrover)

[marvin42x]

@PicNick:
Kleine Anmerkung am Rande:
Das Terminalhandling ist mir extra aufgefallen, da hatte ich ein bisschen den Hut gezogen, dass du dem Programm in aufwendiger Kleinarbeit eine tricky , Plattform-Unabhängige beinahe GUI verpasst hast. Ich dachte das kann keiner mehr.
Da wird der Controller sich aber freuen wenn er das nicht mehr muss.

*grins* stimmt, du hast ja auch ne Hauptstadt

[PicNick]

Ich dachte das kann keiner mehr

Da wirst du wahrscheinlich sogar recht haben, das interessiert ja auch nurmehr alte Kracher wie unsrereiner.
Ich kann's ja auch nur, weil wir das früher eben machen mußten, um den alten bernstein-VT220 das Tanzen und den HP-Druckern eine Graphik beizubringen. Da haben wir noch Fonts geladen und geswitcht, haahaa.
Das können die gängigen Emulationen ja alle nicht mehr.

[Johannes]

> @Johannes:Was schweb dir als PC-GUI vor?
Die GUI ist selbst ein smirs Modul, in das Plugins eingebunden werden können. Diese werden als .NET-DLLs programmiert und per Late Binding eingebunden. So können die Plugins dann spezielle Aufgaben durchführen z.B. spezielle Sensorwerte anzeigen, die die GUI per smirs empfängt.

Die GUI selbst organisiert also die Anzeige-Plugins, ermöglicht einfache administrative Eingriffe (Remote) und schließlich das individuelle Anpassen der Benutzeroberfläche. Das Ding ist sagen wir mal halb fertig.

"Semesterferien" sind für mich ab Mitte Februar, da ich vorher noch Klausuren habe. Aber dann muss ich noch umziehen usw... Aber wird schon was

Gruß
Johannes

[marvin42x]

@Johannes: Dein Konzept ist, glaube ich, in etwa das, was in meinem Gehirn hinter vorgehaltener Hand heimlich als Favorit gehandelt wird. Wobei Du noch weiter gehst als ich und wirklich konsequent die Chance nutzt und per default eine Selbstorganisation in Auge fasst. (immer unter dem Aspekt, dass ich das jetzt richtig verstanden habe) .
Wäre das so, dass Robbi vorab z.B. erst sagt wie er heist, was er alles hat, und kann (so eine Art Config-String)und dann darauf referenziert entsprechend Daten sendet und die GUI stellt das dann dar.?

@PicNick: Als mein Freund noch vor einem grünen Bildschirm saß hat er mir mal tanzende Buchstaben gezeigt, ist schon bisschen her Beim Versuch meinem Saikoscha Unihammer eine Grafik zu entlocken bin ich allerdings kläglich gescheitert. Obwohl man sagte das geht.

[Johannes]

Hi,
also die Selbstorganisation, ich schätze du hast beim Projekt SOSMAR reingeschaut, hat mit smirs direkt nicht viel zu tun. Mit smirs wird nur die Kommunikation geregelt, aber dabei wird einem schon viel abgenommen, wie zum Beispiel die Vernetzung mehrerer Roboter. Das System kümmert sich um die Synchronisation der Daten, ohne dass ein übergeordneter Rechner (Server) vorhanden sein muss.

In dem smirs Netzwerk senden die einzelnen Module Daten an andere Module, die diese weiterverarbeiten. Deshalb kann man auch von mehreren organisatorischen Ebenen der Module reden. Die einen übernehmen die Hardware ansteuerung, die anderen bestimmen das Verhalten des Roboters. Zum Testen des Roboter-verhaltens wäre es also theoretisch möglich, an die Stelle der Hardware-Module den Simulator zu stellen, ohne an der Verhaltenssteuerung was umzuprogrammieren. Schließlich spricht alles smirs.

Die GUI (Admin-Tool) ist ebenfalls ein Modul, wie die Verhaltensteuerung, wie die Hardwareansteuerung etc. Sie empfängt also auch die Daten, die alle anderen Module empfangen. Während alle normalen Module ja eine konkrete Aufgabe haben, ist das Admin-Tool zum Testen und Kontrollieren gedacht.

Denken wir uns mal ein Modul, das bestimmte Sensorwerte abruft und per smirs auf dem Roboter "broadcastet". Diese Daten werden dann beispielsweise von der Verhaltenssteuerung aufgeriffen und interpretiert. Parallel dazu kann das Admin-Tool auch diese Daten empfangen. Was damit passiert, muss der Benutzer ja entscheiden. Dieser kann jetzt ein Plugin für das Admin-Tool schreiben, dass ein Display zur Verfügung stellt, dass genau für die Sensorwerte gedacht ist.

Anderes Beispiel. Es gibt ein Hardware-Modul, dass die Motoren ansteuert. Die entsprechenden Befehle bekommt es von der Verhaltenssteuerung. Aber auch das Admin-Tool kann dort Befehle senden, womit eine Fernsteuerung möglich wird. Das tolle dabei ist, dass man sich selbst dabei nicht mehr darum kümmern muss, wie die Daten von dem Steuerrechner zum Roboter kommen.

Zur Selbstorganisation. Ich will ja smirs selbst auch auf meinem Roboter installieren, wenn er soweit ist, und dann Module programmieren, die eine Orientierung im Raum ermöglichen. Dies soll dann möglichst eigenständig geschehen. Das größte Problem dabei ist ja die Positionsbestimmung des Roboters. Da möchte ich mit der Auswertung von Kamerabildern und der Erkennung von Orientierungspunkten alias Landmarken arbeiten. (http://sosmar.mindrobots.com)

Natürlich habe ich schon viel zu viel gemacht. Ich werde wahrscheinlich nie mehrere Roboter kommunizieren lassen können, da schon einer teuer genug ist. Aber ich würde es gut finden, wenn auch andere an dem smirs System mitwirken wollen, sodass wir einen Software-Standard für Roboter erschaffen.

Wahrscheinlich ist das Ganze jedoch für relativ wenige interessant, da ja nicht alle einen ganzen Rechner auf dem Roboter transportieren.

Gruß
Johannes

[marvin42x]

@ Johannes:
Danke, dass du das noch mal so ausführlich gemacht hast, bin leider etwas GUI-süchtig,
Eine Softwareumgebung, in der Teillösungen nicht nur Teillösungen bleiben sondern Bestandteil eines Gesamtkonzepts werden können.
Auf der Softwareseite ist das im Moment trotz super Einzellösungen noch nicht auf Ballhöhe. Mit einem Benutzbaren System als Kristallisationspunkt könnte sich das ändern.
Die Frage ob man einen Rechner auf dem Robby mitschleppen muss kann man mit rn-Funkmodulen auch so beantworten, dass der Schreibtisch-PC den Job übernimmt und halt über Funk seriell mit dem Microcontroller verbunden ist. Das Marvin42x Schichtenmodell lässt das zu.
Netter Gruß

[Johannes]

> Die Frage ob man einen Rechner auf dem Robby mitschleppen muss kann man mit rn-Funkmodulen auch so beantworten, dass der Schreibtisch-PC den Job übernimmt und halt über Funk seriell mit dem Microcontroller verbunden ist. Das Marvin42x Schichtenmodell lässt das zu.

Natürlich. Auch foldgendes ist möglich: Der Roboter hat einen relativ leistungsschwachen Rechner an Bord, aber die rechenintensive Bildverarbeitung wird auf dem Festrechner durchgeführt. Dass manche Module auf anderen Rechnern laufen, ist ja egal.

Ich meinte nur, dass die Kommunikation mehrerer Roboter (MMC-Mode) für relativ wenig interessant sein wird. Aber macht ja nichts

Gruß
Johannes