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

[marvin42x]

Ich kann Inhaltlich hier erstmal nur zustimmend nicken.
Die klare Strucktur macht mich optimistisch.
Das es Aufwädig wird hatte auch PicNick am Anfang schon Prognostiziert.
Aber das wird gut.
Netter Gruß

[PicNick]

@Ragnar: Sehr gut beschrieben. Ein kurzer Zusatz vielleicht zum Ackknowledgement:
Untere Schichten können durchaus auf Sicherungsmaßnahmen verzichten, wenn das eine Schicht drüber abdeckt:

Beispiel: Ob der Befehl, den Motor schneller zu drehen, angekommen ist, kann ich mit ACK's überprüfen lassen-
Ich kann's aber auch sein lassen, wenn ich die Durchführung über die Odometrie/Sensorik ohnehin überprüfe.

Sprich: man könnte reine Forward-Messages durchaus zulassen, vielleicht einfach durch unterdrückung der Backlink addresse.

[NumberFive]

Schön jetzt kenne ich eine Forums Funktion mehr.

Johannes das dokument werden ich überswochen ende durch arbeiten das so auf die schnelle geht nicht dafür ist es zu komplex.

Aber wir müssen auf passen hier vermische sich gerade zwei dinge ich will mal versuche das zu beschreiben was ich da gerade so sehe.

PicNick beschreibt Aktive Nacchrichten ver sendung und die MC so wie ich sie verschaden habe Stellt ein gemeisamen speicher zu verfügung was zwei Föllig unterschiedliche ding sind. Wobei ich weiß das wird warscheinlich
beides Implementieren müssen. Das sieht man daran das die smirs defintion schon dinge wie Broadcast und Tranfer anbietet.

Also Thema 1 Der gemeinsame Speicher:

Er liegt in der MC und wird durch Namen Organisiert. Z.b. SENSOR65
Der Gemeinsame Speicher hat den Vorteil das wir in Unserem schicht modellen eingendlich nur zwei Befehle Implementieren müssen GetVar und SetVar. Natürlich habe wir hier auch das Thema der Medien wechsel dir PicNick das schon ganz Richtig beschrieben hat aber es sind halt doch nur Zwei befehle und es Gibt keine Probleme mit Addressierung oder Sonst etwas. Hier Spiel jetzt das Thema WatchVar vielleicht mit rein Spricht das Automatische Melden von Änderungen Variablen Inhalten.


Also Thema 2 Aktive nachrichten die durchs System rennen:

Hier Kommt zu dem Medienwechsel noch so dinge hinzu wie Adressung
Aktive Überwachung das es bei Empfänger ankommt und richtig ankommt.
Einheitliche Sprache die Alle verstehen aber auch Seriales Interface auf grund der Datenmenge nicht überfrachen. String operationen auf einem AVR. Und so weiter. Sie haben aber auch ein Klaren Vorteil sie sind Schnell und wirken direckt.

Aber nicht desto Trotz bin ich der Meinung das wir erstmal uns auf drei Befehle und die Realiesierung dieser Konzentiren sollten. Nämlich SetVar GetVar WatchVar. Das Wird schwierig genung das über alle Median hin weg zu realiesieren. So lange wir in der Welt des PC's bleiben hat die Defintion mit TCP und dem rest woll keiner was dagegen oder ? Jetzt kommt der Medienwechsel aber wie richtig ?

Ich denke das hier zur zeit nur Zwei Medien wirklich von belang sind RS232 und/oder I²C. Funk im weitesten sinne also auch Blotooth sind nach mein Dücke eigenlich egal da ich hier auch nur eine Seriale schmal bandige über tragung habe. RS232 und I²C sind aber eingendlich auch das selbe da die Datenserial übertragen werden nur mit einem Unterschied einmal mit Adresse und einmal ohne.

Brauche ich wirklich eine Überwachung der Nachricht als solches ?
Oder recht es nicht einfach wenn ich definiere SENSOR65 ist die Variable
mit dem Sollwert für den Motor und SENSOR66 ist der Ist wert des Motors.
Wenn sich der Istwert nicht ändert Kann der Navigartor Alarmmelden.

Soweit die gedanken für diesen Morgen die Firma ruft

[PicNick]

Allgemein ist ein Nachrichten-Austausch niemals was anderes als der Transfer von Daten aus einem Sendebuffer in einen oder mehrere Empfangsbuffer. So gesehen gibt's eh nix anderes als Data-Mapping.

Aber Daten-Replication in obgenannten Sinne ist eine Sache der Application-Schicht.
Denn:
Nach SetVar muß ja irgendeiner alle Subscriber (Watchval) durchrattern und dorthin irgendwas schicken, damit der aktuelle Value auch dort erscheint. und dort gibt's aber wieder eine Liste von irgendwem, der verständigt werden will, daß sich der Wert geändert hat.

Es hilft kein Zappeln, es gibt einen Level, auf dem eine spezifische Software mit einer anderen spezisfischen quatschen muß. Und bevor der nicht da ist, gibt's sonst auch nix.

Für die Kommunkation ist es irgendwie piepegal, ob eine Empfängeradresse einen Programm-Entry bezeichnet oder eine Memoryadresse. Die Mechanismen unterscheiden sich kaum

Darüber hinaus ist der Grund, "Messages" und nicht "Daten" zu verschicken der, daß die Message wesentlich komplexere (und platformspezifisch unterschiedlich gelöste) Mechanismen auslösen kann.
Im moment reden wird ja nur von Ports setzen und Pin abfragen. Das ist ja letzlich pipifax. Je autonomer irgendein NetzTeilnehmer wird, desto abstrakter die Anweisungen ("geradeaus fahren und mit der Odometrie überprüfen")

Noch ein Beispiel: Wenn der Host einen Motor in Betrieb nehmen will, dann muß er nicht wissen, welchen Pin man da hoch ziehen muß. Er sagt einfach "Gib Stoff".

[NumberFive]

Nur damit wir uns richtig verstehen.

wenn ich in der MC SENSOR00 bis SENSORFF habe.
im AVR ein array of byte mit genauso 255 werten.

die Halte ich per RS232 Gleich. dann ist es an der Applications Programmierung ob SENSOR20 mit dem Wert 20 20% Motorleistung bedeutet oder das der Ausgab A5 auf High geht.

Die versendete daten Menge ist gleich auch wenn die Ausgelösste Funktion kommplexer ist.

Man könnte sogar solche sachen machen:
SENSOR56 => Adresse I2C
SENSOR57 => Daten byte
SENSOR58 => Daten byte 2
SENSOR59 => DOIT

Jetzt kann der AVR das Senden gesendet kann erst wieder werden wenn das DOIT auf 0 Fällt.

Aber vielleicht verstehe ich auch nicht was du meinst's.
Gruß

[marvin42x]

Mal für mein Verständnis:
NumberFive sagt:
„die halte ich per RS232 Gleich.“

Dann sehe ich in diesem kleinen Satz,
auf der Mikro -Controller –Seite:

-----------Schicht 0-------------------------------------------------------
1 Serielle Schnittstelle empfängt byteweise was

----------Schicht 1 Übertragung------------------------------------------
2 einen Programmschnipsel entnimmt die Bytes aus dem Speicherbereich der Seriellen Schnittstelle.
3 Ein Programmschnipsel baut das nach einer Protokollregel zusammen.

----------Schicht 2 Routing-----------------------------------------------
4 Ein Programmschnipsel (Dispacher) Analysiert nach einer Protokollregel die zusammengesetzte Nachricht auf „wer bekommt das“
In Number Fives Fall ist der Empfänger ein Speicherbereich, entweder der ganze oder auch einzelne Felder darin, 255 Bytes groß mit definierter Struktur.
5 Der Dispacher liefert die Daten im Zielgebiet ab.

----------Schicht 3 Verbindung ------------------------------------------------
6 Ein Programmschnipsel überprüft auf Änderung im Speicherbereich und setzt Done nach Bedarf.

-------------Schicht 4 Dienste ----------------------------------------------------
Ein Teil des Hauptprogramms übernimmt die Interpretation der Daten.
Es vergleicht Pinzustände mit dem zugehörigen Wert im Speicherbereich und löst nach seinen Regeln Aktionen aus wie: Pin setzen oder Nachricht verschicken.

In der Umsetzung von NumberFive sind die Regularien in der Implementation ablesbar aber nicht extra außerhalb vereinbart. Was ja bei einem Einzelprojekt auch nicht nötig scheint.


Auf der PC –Seite: Ein ähnliches Prozedere.

Anmerkung: Das ist eine Übung um mich in das Schichtenmodell einzuarbeiten, weil ich denke: Das ist es. Es soll keinerlei Bewertungen darstellen. Ich brauche aber ein Beispiel und die Korrektur um das besser umsetzen zu können.
Netter Gruß

[ragnar]

Aber wir müssen auf passen hier vermische sich gerade zwei dinge ich
will mal versuche das zu beschreiben was ich da gerade so sehe.

@NumberFive:
Nein, ganz im Gegenteil. Wir trennen hier gerade Dinge, die eigentlich
nichts miteinander zu tun haben. Wenn ich dich richtig verstanden habe,
dann willst du sagen, daß synchronisierte Variablen für einen Client
wesentlich einfacher zu verwenden sind als Nachrichten, Broadcasts, etc.
Der Client möchte sich nicht darum kümmern, wie die Variablen übertragen
und synchronisiert werden.

Was PicNick meiner Meinung nach erklären will, ist daß die Synchronisierung
von Variablen nur über Nachrichten geht. Diese können versteckt und unsichtbar
laufen, trotzdem existieren sie. Ein Beispiel in smirs: wenn ein Modul eine
Variable setzt, dann wird intern (innerhalb der MC) eine Nachricht an alle
anderen MCs generiert, die über diese Änderung informiert.

Die MCs von smirs sind also ein Dienst, bei dem ein Modul synchronisierte
Variablen anfragen kann. Die Client-Schnittstelle sind TCP/IP Nachrichten,
die interne Kommunikation sind (vmtl) auch TCP/IP Nachrichten.

Auf was ich hinauswill ist folgendes:
Die Synchronisation von Variablen erfordert Nachrichten, sowohl von den
Clients(Modulen) als auch zwischen den Servern(MCs). Man kann also eindeutig
zwei Schichten trennen.

• 1.) Der eigentliche Transport der Nachrichten
  Dieser beinhaltet die Adressierung der verschiedenen MCs sowie die
  verwendeten Kommunikationsprotokolle (in diesem Fall TCP/IP).
  
  2.) Der Inhalt der Nachrichten (Semantik)
  z.B. SetVar XXX YYY und der Synchronisationsalgorithmus

Konsequenterweise sollten alle Teilnehmer (also auch die MCs) untereinander
dasselbe Kommunikationsmodell verwenden und allseitig klar definierte
Schnittstellen verwenden. Erweitert man das Kommunikationsmodell, dann
wird erreichen diese Erweiterungen automatisch alle Teilnehmer, ohne daß
diese aufwändig umgeschrieben werden müssen. Man kann also z.B. das
Kommunikationsmodell (bisher bei smirs: TCP/IP) um eine serielle
Komponente erweitern, ohne daß die bisherigen Dienste ihr Funktion
einstellen.

In Ansätzen ist dieses Kommunikationsmodell bei smirs auch zu
erkennen. Knoten werden über MC->Modul adressiert. Nur leider ist
dieses Kommunikationsmodell eben nicht konsequent ausgeführt, denn
die MCs untereinander kommunizieren (Annahme meinerseits) nicht über
ihr internes Kommunikationsmodell (MC->Modul), sondern direkt über
TCP/IP. Damit kann die Kommunikation zwischen zwei MCs nicht einfach
durch eine Erweiterung des Kommunikationsmodells erreicht werden,
sondern nur durch aufwändige Erweiterung aller Einzelkomponenten.

Anmerkung dazu:
Bei smirs muss bei SetVar/GetVar keine Adressierung angegeben werden.
Das ist natürlich praktisch, schließlich will man mit genau einem
(dem nächsten, dem eigenen) MC kommunizieren. Im Prinzip ist das
ganze eine Kommunikation mit einen implizit vorgegebenem Teilnehmer.

Anmerkung 2:
Hat man dieses Kommunikationsmodell, dann kann man es auch direkt
zur Kommunikation zwischen den Komponenten nutzen. Bei smirs ist
die Nachrichtenübertragung sozusagen ja auch ein 'Dienst', nämlich
der Dienst 'BROADCAST' bzw. 'TRANSFER'.


So, ich hoffe ich habe dir jetzt klarmachen können, warum wir
unbedingt die Trennung zwischen Kommunikationsschicht(en) und
Diensteschicht brauchen. Ich will die synchronisieren Variablen
nicht abschaffen, ich will sie nur auf ein gutes (universelles)
Fundament stellen.

ciao,
Georg

BTW: Ich werde demnächst nochmal darauf zurückkommen, wie man
smirs in mein Schichtenmodell einordnen könnte. Ich kann nur
nicht alles auf einmal schreiben.

PS@marvin42x:
Danke für die Illustration zum Schichtenmodell, ist IMHO ein
gutes Beispiel.

[Johannes]

Hi!
> Nur leider ist
dieses Kommunikationsmodell eben nicht konsequent ausgeführt, denn
die MCs untereinander kommunizieren (Annahme meinerseits) nicht über
ihr internes Kommunikationsmodell (MC->Modul), sondern direkt über
TCP/IP.

Da kann ich mal was zu sagen. Das stimmt, die Kommunikation zwischen den MCs hat nichts mit der Kommunikation zwischen MC und Modul zu tun. Das liegt daran, dass zwischen MC und Modulen eine STEHENDE TCP/IP Verbindung herrscht, während zwischen den MCs das verbindungslose UDP verwendet wird, sowohl in der Server/Client-Variante als auch per Multicast. Würde man das umstellen, so ginge das auf Kosten der Performance.

Wollte man zwei MCs über ein alternatives System kommunizieren lassen, so müsste man ein Programm vorschalten, dass eine MC emuliert und die Daten dann beispielsweise per RS232 versendet.

Gruß
Johannes

P.S. Ich folge eurer Diskussion, muss mich jedoch auf ein paar Prüfungen vorbereiten, weshalb ich erst einmal relativ wenig posten werde.

[NumberFive]

Ich stimme johannes zu den Median wechsel als zweite MC zu sehen fände ich auch zu heftig ich finde es in Ordnung wenn es zwei welten gibt.

Wenn du die Befehle GETVAR SETVAR WATCHVAR VARGERÄNDERT so defineren willst das es über alle Median hin weg funktioniert wird es nie
Mensch lesbar bleiben den RS232 währe mit so langen string Ketten und der AVR einfach über frachtet. Das System muß in meinen Augen nicht die Eierlegende wohlmilchsau werden.

Es muß in Rahmen erweiterbar sein ein offne schnittstelle haben und auch für "normale" mensch zu verstehen. Ich habe es zu oft erlebt das Projekte scheitern weil es zu perfekt machen will. ODBC Borlands BDE und cobra liefen alle in diese richtung und sind kaum noch vertreten nach mein Kenniss stand.

Klar ist ODBC ein dolle sachen weil ich mit allen DB's der Welt reden kann und mir das was drunterliegt egal ist aber ich habe es noch nie schnell gesehen. Das ist doch mit Sql komandos genauso.

Ich denke hier sollte man ein kompromiss finden zwischen Perfekt und machbar. Und eine Trennung mach zwischen ein gelschossen System dem Roboter und der Schwarm steuerung (Mehre Robi's sprechen die gleich sprache).

Vielleicht male ich nachher noch ein bild damit es deutlicher wird was ich meine. Aber jetzt muß ich erstmal ein meinen Robi den nächste woche ist roboter challange (www.gs-roboter.de) und ich will nicht wieder ohne was hin.

Gruß

[Richard]

[quote="marvin42x"]@ 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.

Moin moin allerseits,

Damit befasse ich mich auch gerade um Wegstrecken vom Hand geschobenen "Rasenmäher" als x,y Werte an einen PC zu senden.
Dort sollen diese Daten dann als Polygone in einem Grafickprogramm erscheinen. Alle innen Polygone sollen gesperrte Fächen darstellen.
Dann mittels Fill Befehl das äußere Polygon füllen und das ganze als Hpgl Datei speichern.

Diese Datei dann so bearbeiten das die Plott Befehle sowie die Stiftbreite
halt der Schnittbreite des Mähers entsprechen und auf dem AVR dann den Mäher steuert.

Zum Testen habe ich mir bei http://www.sander-electronic.de ein Entwicklungs Board mit Beschleunigungssensor bestellt. Dieses Board speichert Bewegungen in 3 Achsen in ein eeprom und ist Batterie betrieben.
Kann also autonom arbeiten um später am PC ausgewertet zu werden.
Damit möchte ich dann auch die Reproduzierbarkeit der Wegpunkte testen sowie natürlich auch versuchen diese Daten in eine hpgl Datei zu bekommen.

Grüße Richard

Zu eurer Überlegung einen PC/Laptop auf dem Rob zu bauen, unter Oben genannter Adresse findet sich ein geniales und preisgünstiges Minniboard mit rund 70x80 mm Fläche!