Standart PC Software für Mobile Roboter

[Johannes]

Moin matren,
du meinst, mit an unser Projekt dranhängen?

Also, meiner Vorstellung nach müsste auf dem Roboter selber gar kein PC installiert sein. Die Software kannst du auch nur auf dem PC verwenden. Sie könnte über ein Addon ein Funkmodul ansteuern, das mit deinem Mikrocontroller kommuniziert. Da könntest du dann immernoch viele Features nutzen.

Gruß
Johannes

[matren]

Na gut, wenns denn so angedacht ist, würde ich schon mitmachen.
Ich würde mich dann aber eher auf Linux und Java konzentrieren, da ich da momentan so gut wie keine Ahnung hab, da ich da bisher keine Verwendung hatte. (Ich brauch immer ein Ziel wenn ich mich irgendwo einarbeiten muss).

Momentan programmiere ich eigentlich nur mit PHP (früher mit Perl), da ich hauptsächlich Business-Anwendungen fürs Intranet schreibe (und ohne Datenbanken läuft da natürlich nichts: Oracle, MSSQL, MySQL). Zu früheren Zeiten habe ich hauptsächlich in VB programmiert, ist aber schon ne weile her.

Im Elektronik-Bereich bin ich ja eigentlich ein Anfänger, hab mein RNBFRA erst kürzlich gekauft. Aber das wird auch noch.

Also wenn Ihr etwas Unterstützung braucht, dann bin ich dabei.

[Johannes]

> (Ich brauch immer ein Ziel wenn ich mich irgendwo einarbeiten muss).

Genauso geht es mir, vielleicht können wir uns da gegenseitig helfen.

Aber auch allgemeine Mitarbeit bei der Planung würde helfen.

Gruß
Johannes

P.S. Dann gehe ich nun mal ins Bett (bin gerade von ner Fete wiedergekommen) und hoffe, dass ich morgen ein paar Kommentare zu meinem Ablaufplan von euch lesen werde.

[matren]

Wenn ich da richtig verstanden habe wills Du eigentlich ne Art Bussystem benutzen (oder sagen wir Protokoll) das auf ein oder mehrere bestehende Kommunikationsprotokolle (z.B. TCP) aufsetzt über den alle Komponenten kommunizieren können. So ganz klar ist mir das aber noch nicht.

Ich muss jetzt leider ins Büro, bin erst heute Abend wieder da, dann können wir das ja diskutieren.

Gruß

[NumberFive]

Hallo marten,

erst einmal will kommen im boot. schön das noch jemand mit programmieren möchte. Kenne ein firma in Frankfurt die zur zeit alte rechner verkauf für unter 100 Euro natürlich nix dolles aber. um die Maincontrol laufen zulassen
öhen viedeo sollte es wohl reichen. Aus deine Aussagen erkenn ich das für dich sql kein Thema ist. Schön. Werde jetzt die Angaben von Johannes mal
in mein Überlegungen einarbeiten un das ergebnis dann hier Posten.

Samstags Büro ?

PS: habe mir frei genommen von der freunden damit wir hier was schaffen können. Ich hoffe es lohnt sich

[Johannes]

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

[NumberFive]

Hallo,

der eintrag wurde offline verfasst also nicht wunder wenn es nicht 100% passt.

nun mein gedanken zu Thema. Leider muß ich eines Feststellen:

Ich habe kein Probelm damit wenn teile der Software in Java laufen wenn tun ist egal wo mit. Aber ich kann java im Moment nicht auch noch lernen kann Delphi und c++ ein bisschen Html und PL/ Sql unter Oracle. Im Moment habe ich zwei große Projekte am laufen aus diesem hier das packe ich zeitlich wirklich nicht. Noch dazu wo ich jetzt noch Bascom lernen muß für meinen AVR.

Bitte habt verständniss.

Aus diesem grund würde ich folgendes Vorschlagen:

Ziele Version 1:

MessageCatcher schreiben wir in C++ (VC 6.0) Windows platform
SensorCatcher C++ Windows Serial Input für MircoControler an bindung über COM
RoboCam C++ DirektX anbindung über COM
Karten erstellung in java anbindung über TCP
Konfiguration tool in ? Php ?
RemoteControl in ? Anbindung über TCP
MessageTransfer für den PDA in Java

Alle Konfig daten werde in INI Files abgelegt
MessageCatcher hat zu griff auf einem MySql Server für die Daten

Bitte nicht auf schreien werde es versuchen zu erklären.
Der Hauptgrund für mein Vorschlag ist der das bei dieser Lösung schon reativ viel Fertig ist und läuft und sich in meiner Arbeit große synergie effeckte erreichen lassen. Ich weiß ja nicht welche Projekte bei euch so anstehen deshalb kann ich das nicht ein schätzen und mache diesen Vorschlag. Bitte nich als gegen annehmen sondern als diskustion Grundlage.

Im MessageCatcher wird die COM Schnittstelle so weit wie möglich isoliert
damit sie für ander Betriebssystem entfernt werden kann. Der MessageCatcher ist auch
ohne die zwei standart Addon voll funktionsfähig.

Für mein nachfolgenden ausführungen gehe ich von folgende gebenheiten aus:

Es gibt zwei PC's den PC an dem ein Mensch Sitzen kann (RemotePC) und den RobiServer der entweder im robi ist oder für die wo es zu groß (teuer) wird
ist er über TCP über WLAN oder Funk RS 232 mit dem robi verbunden.

Siehe dazu Bild 1

Also bis auf das Addon interface gibt es das ganz schon zwar nicht voll ausprogrammiert
aber ich könnte das Zeigen. Allerdings nur hier oder müsste jede menge rechner rum tragen.

Zum Ablauf:
Das RemoteInterface halt alle Recht und mehr befehle absetzten als der rest.

Die GobalControl immer alles Entgegen und Interpretier das ein kommen
Telegramm. Wenn das Telegram es vordert werde Variablen gestetzt
und der ProgrammInterpreter gestartet oder Die funktion im MessageCatcher
ausgeführt. Die Telegramme sehen immer so Aus TEXT|TEXT|TEXT...
es durfen keine 0 Bytes enthalten sein. Bei der Übertragung über
tcp wird nur noch die länge des Textes vorne angestellt. Damit die gegenseite weiß wann das telegramm voll ständig war (bei TCP kann zu verstückeling der telgramme kommen)
aber darum das kümmert sich das Addon interface oder das RemoteInterface.
Jedes Addon hat einen Eindeutingen Name über den es dann an gesprochen werden kann. Im Prinzig kann jedes Telegramm von Überall kommen oder Hin geschickt werde
ohne das eine zeile sourcecode geändert werden muß.

Bsp:

SensorCatcher Sendet :

MESSAGECATCHER|RUN|SET|ADDON|1|SET|DATA|DASISTEINT EST

Der MessageCatcher setz die Variablen:

ADDON = 1
DATA = DASISTEINTEST

Da nach wird der wird der programmInterpreter gestartet irgend wo in Script
steht:

IF ADDON = 1 THEN
Send ADDON VAR DATA
END IF

jetzt passiert folgendes der MessageCatcher bekomme den auftrag
an das device/addon mit dem ADDON den inhalt der Variable DATA
zu senden.

Ich denke viel freier kann es nicht gestallten wenn man es realiesierbar halten möchte.

In dieser Form hat der MessageCatcher nichts mit dem ablauf im roboter zu tun
sonder das verhalten wir allein über den script bestimmt. Und die leistungs fähigkeit
wird allein die Fähigkeiten des Interpretieres bestimmt un ist aus baubar.
Wenn man es über treib hääte man sogar ein eingene script sprache.

Es wird in ein Zyklus ein Tegramm an alle componet geschikt
damit man weiß das sie noch leben. Wenn da kein antwort mehr kommt
werden sie ab gemeldet. Was im in meinem Robi nach her machen werde
ist das bekommt der AVR kein lebenszeichen mehr restet er den ganzen PC
Hardware mässig. So sollte eine Dauer betrieb möglich seid so lange
es noch strom gibt.

So jetzt habe ich alle meine geheimnisse Preis gegeben nun macht was draus.

Gruß

[NumberFive]

So johannes

meiner ist auch nicht viel kürzer *g*

Gruß

[Johannes]

Nochmal was zu PDAs:
Man müsste auf dem PDA ja nur die main control und zum Beispiel eine Verhaltenssteuerung installieren. Kompliziertere Dinge wie Datenbanken oder Kameraverarbeitung sind natürlich nur auf rechenstärkeren Computern möglich.

Und zu normalen Controllern ohne Rechner auf dem Roboter (betrifft dich, matren):
Es ist natürlich auch möglich, die Software nur auf dem PC zu installieren und ein Addon zu programmieren, dass mit dem Controller kommunizieren kann. Da gibt es ja viele möglichkeiten fernab von WLan etc. Dann kann man immernoch die GUI nutzen, Daten anzeigen und ändern.

Gruß
Johannes

[Johannes]

So, hatte bei meinem Post deinen noch nicht gesehen.

Mein Standpunkt ist folgender, du musst JAVA ja nicht lernen, du schreibst die C++ Routinen und ich den Rest, vielleicht findet sich ja noch jemand außer matren. Nur ich möchte nun eine komplett durchdachte und zukunftssichere (im Sinne von Erweiterungsmöglichkeit und Portierbarkeit) Software programmieren. Du sagst zwar, dass du vieles schon fertig hast, aber ich habe schon eine lauffähige Software, die fast alles das kann, was ich oben beschrieben habe.

Allerdings läuft sie mit ActiveX-Komponenten, ist mit Visual Basic programmiert und damit auf Windows fixiert und kann noch nicht die Sachen, die mit einer plattformunabhängigen main control und einem universellen Gateway möglich wären. Und gerade so etwas möchte ich in Angriff nehmen.

Deshalb habe ich mir gedacht, dass wir im Moment noch gar nicht groß programmieren sondern ein Schema entwickeln, Lösungsansätze suchen, dann noch ein paar Leute zusammensuchen und dann programmieren, gleich dabei Fehler ausmerzen und die Funktionalität optimieren. Ich selber finde auch nicht, dass die Software möglichst schnell fertig sein muss, sondern möchte eher einen Greundstock entwickeln, auf den möglichst viele Leute verwenden und ihre Module dafür schreiben.

Gruß
Johannes