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

[NumberFive]

Mal zu rück zur RS232 ich habe bei mir schon die Kommunikation zwischen MC und AVR relaiesiert. ich sende einfach 4 byte's A[wert][wert]E.

Das macht bei mir 254 Werte in 254 Varialben was in meinen Augen föllig ausreichen sollte. Hier für gibt es wie gesagt beide seiten den PC Teil und den AVR Teil.

Die Variablen werden bei Starten des Addons in der MC Anlegt so das sie mal da sind. Die bedeutung ist aber nicht hinterlegt. So das man damit mach kann was man will.

Die Kommpletten Simirs Befehle auf dem AVR zu verarbeiten fand ich auch nicht so gut. Deshalb hatte ich die Idee von triggern das Heist wenn ein eine Variable ein Bestimmten wert hat werden weiter Aktionen ausgeführt.

@Johannes
warum nicht mehr Kompatible ? Mal danvon ab gesehen das meine MC den MMC modus nicht kann ?

Wenn der MMC Modus wirklich gebraucht wird denke kann ich den Nach ziehen aber bis das so weit ist wird es noch ne weile dauern. wer hat den schon mehr als einen Robi zuhause ?


Gruß

[marvin42x]

Den Multiroboter-Modus im ersten Schritt zurückzustellen würde ich auch erstmal so sehen können.
Ich vermute, dass sich das gut nachholen lässt.

@NumberFive: Du sendest 4mal AAA, Datenstrom,E (wenn ich richtig verstanden habe). Die Datenstromlänge beträgt 255 Byte. Die Variablen sind in der MC angelegt aber nicht definiert.
Weis Dein AVR in welcher Reihenfolge, welchem Format(z.B. Byte, Integer) er was senden soll?
Weis Deine MC was, in welchem Format wo steht oder legt sie es nur byteweise ab?, erledigen die Module die Interpretation?
Geschieht das triggern auf dem AVR oder der MC oder erst auf einem Modul?
Ist der RS232-Teil bei Dir in der MC implementiert oder in einem Modul?
Ich hoffe die Fragen betreffen keine Betriebsgeheimnisse.

Was ich mal zu dem Umstand sagen will „kaum einer hat mehrere Roboter“:

Vor Äonen gab es mal ein 3D Ballerspiel namens Quake2. Das war netzwerkfähig.
Anfänglich spielten wenige, noch mit ISDN, über das Internet miteinander. Später füllten LAN-Spieler ganze Riesenhallen, jeder hatte auch nur einen Computer. Es gab Meisterschaften in diversen Spiele Modi.
Ich will sagen, wenn erstmal ein funktionierendes System besteht ist schwer abzuschätzen was das für Synergieeffekte hat.
Wie auf anderen Gebieten gibt es dann das Bergungsroboter-Meeting in Göttingen und Das Rasenmäherrobo- Formationsmähen in Berlin und das Manschafts-RoboStaubsaugen in Wien.
Wer kann sich denn schon rühmen ein open Source Roboter-LAN-System am laufen zu haben.
Um es mal vorweg zu nehmen, ja, ich weis, dass ich ein alter Träumer bin.

[NumberFive]

Ok das mit dem MMC kann man sicher nach ziehen.

Betriebsgeheimnisse gibt es fast keine wenn es nicht mehr anders geht rücke ich auch den Source raus keine frage.

Du Hast es nicht ganz verstanden.
Ein Telegaram sieht immer so aus AAEE oder ARTE oder AJKE

A => Anfang
A => Variable damit Wird die Vairable SENSOR65
E = > Auf den Wert 69 gesetzt
E => Ende

Der Seriale teil ist per com an gebunden wegen der vorgeschichte und
dem Applikations speed.

Die Module müssen immer Interpretieren das ist das Grundkonzept.
In meiner Test Ober fläsche sind aber schon so dinge möglich wie
Ein Schiebe regeln dem man ein Variable zuordnen kann dann rutscht er mit. Oder ein radar das mit dem Stepper und dem Sharp zusammen läuft.
Aber das radar ist relativ Hart programmiert weil es bis jetzt eh nicht weiter ging also habe ich nur das programmiert was ich brauchte.

Ich habe auch ein Addon/Module für den Joystick damit man damit steuern
kann.

Das einzig was fehlt ist ein frei programier bares Logi modul damit alles zu sammen spielt. Variablem sind viele da jetzt muß man die nur mit einander verkudeln. Ein (com) dll ist auch schon da mit dem auch VB anfängen sich per TCP connected können sollten.

Punkt um es gibt viel jetzt muß man nur was draus machen.
Achso ein Bild erkennungs teil welches den Helsten punkt an die MC melden gibt es auch schon. Abfall produckt von meinen Bild erkennungs versuchen.

Gruß

PS: Deine gedanken finde ich toll. Werde mein Teil so weit möglich leisten
aber glaube erst dran wenn irgend so wa statt findet sorry.

[ragnar]

Hallo, jetzt muss ich mich mal auch in diese Diskussion einschalten.

Meiner Meinung nach reden wir hier im Moment über drei Dinge:

- Nachrichten zwischen logischen Einheiten (Aufbau, Syntax)
- Übertragungsmedien für diese Nachrichten (Seriell, IP, ...)
- Bedeutung der Nachrichten (Semantik)

Diese drei Schichten kann und sollte man bei der Diskussion auseinanderhalten. Man kann jede Schicht getrennt entwerfen und sich damit viel Durcheinander ersparen. Ich möchte im folgenden zu den drei Schichten mal meine Meinung abgeben.

1. Nachrichten
Prinzipiell finde ich die Idee einer Nachricht zur Kommunikation in einem Robotersystem sehr gut. Mit Nachrichten lässt sich fast alles abbilden. Direkte Kommunikation, Dienste für gemeinsamen (synchronisierten) Speicher, etc.
Nachrichten sollten folgende Eigenschaften haben:

• einfach genug, um auf uCs verarbeitet werden zu können
  (kleiner Protokolloverhead)

• komplex/groß genug, um auch größere Daten zu tragen
  (50-100 Bytes sollten schon möglich sein)

• Leicht Maschinen und Menschenlesbar (Konflikt !)
  Leichte Maschinenlesbarkeit erhöht die Performanz bei uC Verarbeitung.
  Lesbarkeit für Menschen ist für das Debugging wünschenswert.

• Gute Addressierbarkeit, leichtes Routing
  Wie können Teilnehmer addressiert werden ?
  Wie finden addressierte Nachrichten ihren Weg über verschiedene Übertragungsmedien ?
  (IMHO die schwierigste Frage)

2. Übertragungsmedien
Hat man erstmal ein Datenformat definiert, ist es relativ leicht, verschiedene Übertragungsprotokolle für diese Nachrichten zu entwerfen. Hat man bei der Addressierbarkeit gut gearbeitet, kann man diese auch leicht zwischen verschiedenen Medien konvertieren (Bridging).

Dieselben Nachrichten können im Idealfall vom Rechner an einen anderen Rechner per LAN übertragen werden, dort dann über seriell an den uC weitergeschickt werden der die Nachricht dann über I2C an einen zweiten uC schickt.

3. Bedeutung der Nachrichten (Semantik)
In dieser Schicht ist es egal, wie die Nachricht zum Ziel kommt. Diese Schicht arbeitet nur auf der Syntax der Nachrichten und weist den Daten dieser Nachricht eine Bedeutung zu. So wird z.B. aus der Nachricht 'XX XX XX XX' die Bedeutung 'Sensor xx hat Wert yy'. Nachrichten mit festgelegter Bedeutung können nun allgemein verarbeitet werden, angezeigt werden usw.

Eine GUI setzt auf dieser Schicht auf und HW-Komponenten implementieren diese Schicht um Standard-Funktionalität zur Verfügung zu stellen. Auf dieser Schicht kann auch eine Automatische Beschreibung von Komponenten und Sensoren stattfinden.


Bei den Schichten 1+2 würde ich auf jeden Fall mithelfen.
Es kommen sicher noch mehr Beiträge von mir nur heute ists schon spät .

Georg

[NumberFive]

Hallo ragnar,

Schön formuliert leider kann ich das so nicht aber wenn ich dich richtig verstanden habe ist das MC Konzept eingendlich schon so.

Das Physiche Medium ist immer TCP mit Chr(10)chr(13) als abschluss.
Der Inhalt ist durch das simir's Protokoll vorgeben.

Nehmen wir mal die Zwei wohl wichtiges Befehle:
SET|<var>|<wert>
GET|<var>

Also mein RS232 Addon/Modul mach jetzt nix anders als aus dem Ankommen String des AVR AAEE den Befehl SET|SENSOR65|69
oder wenn die Variable in der MC geändert wird schreibt er den wert
per Schnittstelle raus an den AVR.

Damit ist aber die Bedeutung nicht Festgelegt. Was im AVR oder in einem Anderne Modul damit passiert. Damit ist auch ein Kompromiss in meine Augen eingegangen was die Lesbarkeit und verstehtbarkeit angeht.

Die Variablen liegen alle in der MC damit kann jeder auf jede Zugreifen.

So weit das MC Konzept.

Bei dem was marvin42x mach will muß man jetzt Variablen Festlegen und deren Bedeutung oder Man programmiert sich zu tode wenn alles Frei zu konfigurieren ist.

Das Prinzip ist also nicht ganz ein nachrichten System sonder eher ein gemeinsamer Hauptspeicher auf den Alle zu greifen können. Im MMC betrieb Sycronisiert er sich über alle MC hin weg so das jeder die Gleichen
daten hat.

Der Vorteil den ich hier sehe ist der das Jeder nur die Daten bekommt die erbraucht und haben will. Und keiner braucht was vom anderen zu wissen.

Keine Probleme mit der adressierung es gibt nur einen der Alles weiß die MC man muß nur einen Fragen.

Die Grösse der Nachricht ist jetzt kein Problem mehr den man braucht in meinen Augen keine Werte die man nicht mit 0-254 beschreiben könnte
Ausserdem gibt es diese Begrenzun ja "nur" bei den Variablen die zwischen AVR und MC ausgetauscht werden. (Bei dem von mir erstellen Serial Addon)


Noch eine Anmerkung zu Serial Addon:
das könnte man noch so erweitern das man wenn man das in den Funkmodulen anfragen kann das es Variablen für Empfangspegel und
so was gibt (Habe keine Erfahrung mit den Funkmodulen). Diese Daten braucht man man bei einer Draht RS232 ja nicht.

Gruß

PS: Ich hoffe ich habe mich einiger massen verständlich ausgedrückt.
So jetzt muß ich mal was Arbeiten

[ragnar]

Bestandsaufnahme smirs

Also wenn ich das richtig verstanden habe dann ist smirs im Moment folgendes:
(Bitte korrigiert mich, wenn ich falsch liegen sollte)

1.) "Fertige" MCs (in Java ?)
An diese MCs können sich über TCP/IP Module verbinden.
Die MCs kontrollieren die Vergabe von Modulnamen, den
Verbindungsaufbau und die Portzuweisung. Sie übernehmen
die Weiterleitung von Telegrammen an lokale und entfernte
Module anhand der Modul/MC Namen. Weiterhin bieten die
MCs einen Dienst für synchronisierte Variablen.

2.) Die Telegramme zwischen MC und Modul sind menschenlesbare
Strings mit Trennzeichen und Abschlusszeichen, die über
TCP/IP übertragen werden. (Frage: gilt dies auch für die
Kommunikation zwischen den MCs)

3.) Weder bestimmten Variablen noch bestimmten Nachrichten
(TRANSFER) ist bisher eine Semantik zugeordnet

4.) Die eigentliche Verbindung zur Roboterhardware bzw zum
uC ist bisher nirgendwo definiert. NumberFive hat eine Brücke
für bis zu 254 Variablen über eine serielle Leitung implementiert.

Frage an NumberFive: Welches Programm liest bei dir die Daten vom
seriellen Port und generiert die entsprechenden smirs
Telegramme ?

Frage an alle: Sind die Telegramme von smirs in "telegramm.pdf"
eigentlich alle definiert? IMHO fehlen da die Definitionen
für Login, Portvergabe und auch der Verbindungsaufbau ist
meiner Meinung nach nicht ausreichend beschrieben. Ohne diese
Informationen kann man kein eigenes Modul implementieren.
Auch wenn diese Details hoffentlich irgendwann in einer Library
versteckt sind, sollten sie sauber definiert sein.

ciao,
Georg

[ragnar]

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

[Johannes]

> (Frage: gilt dies auch für die Kommunikation zwischen den MCs)

Ja, aber dafür gibt es noch keine Dokumentation, da dieser Part noch nicht ausgereift ist und zweitens für die Entwicklung von Modulen uninteressant ist, da man dort nicht eingreift. Trotzdem werde ich die Kommunikation natürlich offenlegen. Aber ich will erst noch ein paar Dinge optimieren.

> IMHO fehlen da die Definitionen
für Login, Portvergabe und auch der Verbindungsaufbau ist
meiner Meinung nach nicht ausreichend beschrieben.

Natürlich existiert eine gut 30-seitige Dokumentation. War meine Abitur-Zusatzleistung. Habs mal online gestellt: http://www.mindrobots.de/public/algo...mirs/guide.pdf, oder bei Verbindungsproblemen
http://mitglied.lycos.de/mindrobots/smirs/guide.pdf

Da habe ich alles beschrieben, was ich selbst weiß

Gruß
Johannes

P.S. In dieser Doku steht auch alles über den MMC-Mode, wir mir gerade auffällt. Bei Gelegenheit kann ich auch nochmal erzählen, was dort optimiert werden kann.

[Johannes]

So, jetzt hab ich dein zweites Post gelesen. Bis auf die "Brücken" und die GUI, an der ich noch sitze(n werde in den Semesterferien), ist alles soweit möglich.

Gruß
Johannes

[NumberFive]

Hallo,

Es gibt zwei "fertig" MC eine in Java mit MMC und eine in C++ / WTL ohne MMC mit Sprache ausgabe (Mircosoft Speak SKD).

Die Umsetzung von simr's nach RS232 passiert im Modul/Addon.

Es gibt in meiner MC (Windows C++ version) einen Undokumentieren befehl SPEAK|<text>.

Was fehlt ?

Anmeldevorgang
     Modul sendet an MC über den Loginport:
     CONNECT|<modulename>|<moduletype>|<connectiontype>  
     Werte für <moduletype>:
          - GUI [Modul ist ein Grafic User Interface]
          - ELSE [Sonstiges]
          - Die Werte ALL sowie MC sind nicht erlaubt.
          - Ansonsten können beliebige Werte verwendet werden, sie sollten jedoch in Großbuchstaben geschrieben sein.
             Folgende Werte darf <modulename> nicht annehmen:
          - ALL, ELSE
          - Typ der verwendeten MC (MCJAVA, MCWIN)
          - Name der MC
          - Der Name muss eindeutig sein. Es können also an eine MC nicht zwei Module mit demselben Namen eingebunden werden.
            Der Parameter <connectiontype> stellt eine positive, ganze Zahl  ar und gibt in
            zunächst an, ob es sich bei der Verbindung zwischen MC und Modul um eine sichere
            (secure) oder lose (loose) Verbindung handelt. Ist der Wert „0“, so ist die Verbindung
secure. Andernfalls gibt der Wert das Intervall in Millisekunden an, mit dem die MC die
Verbindung testet. Das Intervall hat eine Mindestgröße von 100ms, alle Werte darunter
werden automatisch auf diesen Wer gesetzt. (siehe unten: Connection Type)
MC antwortet bei erfolgreicher Anmeldung:
CONNTECT|OK|<newport>
...ansonsten:
CONNTECT|NOTOK
Beendung der Verbindung am Loginport.
Modul sendet an MC über zugewiesenen Port <NewPort> innerhalb der nächsten 2 Sekunden:
ONLINE|<modulename>
MC antwortet mit eigener Beschreibung:
SMIRS|<mctype>|<mcname>|<mcversion>|<mcdescription>
Bedeutung der Parameter:
- mctype [Typ der MC, z.B. MCJAVA oder MCWIN]
- mcname [Name der MC, nur bei MultiMCMode von Bedeutung]
- mcversion [Version der Software]
- mcdescription [Info-String der Software]
Wenn der Login-Vorgang abgeschlossen ist, sich also alle Module angemeldet haben, sendet die
MC READY| an alle Module.

Leider kann ich den Text nicht schön formartiert

Wenn Lan bzw. WLAN auf den Robi zu vefügung steht kann man sich von da aus ja per TCP connected.

I²C würde ich anders Lösen wollen mit eine Modul für die MC und dem RS232 I²C adapter von Frank. An der Software für den Adapter Bastele ich eh gerade wegen Stupsi und einem Neuen Regel für die Motoren.

Im großen und ganzen sehe ich einglich kein Problem darin deine Vorstellungen zu realiesieren mit der MC.

Wir müssen nur mehr Definieren um es zu ein baukasten machen zu können Und damit auch ein weniger verständiger mensch es zu laufen bringt das heist aber auch das die Software im AVR zu mindestens zu Teil
vorgeben werden muß. Ein c Prg für den AVR und die RN-Control das mit meinen RS232 Modul läuft habe ich schon Fertig.

Ich sage es gleich für Dokumente bin ich der falsch die müssen leider andere schreiben.

@ragnar
Kurz der Ablauf wie bei mir die Daten an den AVR kommen:
Das Modul erzeugt bei Start die Varialben SENSOR00 bis SENSORFF
als public. Kommt vom AVR ein Telegram dann wird die Variable gesetzt.
Setzt jetzt ein Anders Modul die Variable wird das in ein RS232 um gesetzt und geschickt. Hier braucht man nix mehr machen ist Fertig.

Also nim die WinMC das RS232 Modul/Addon und meine Test GUI und du Soltest per SET|SENSOR34|67 und Sende Button ein Telegram auf deinem AVR haben.

PS: Mysql kann ich auch aus der MC ansprechen aber das ist noch nicht so richtig aus gereift da sollen später noch die Variablen und die Karten rein um ein wieder anlauf und dauerhafte speicherung zu ermöglichen.

So weit heute morgen