Archiv verlassen und diese Seite im Standarddesign anzeigen : Rnbfra Multi-Thread und Netzwerkfähig mit GUI im www, jetzt
marvin42x
22.01.2006, 15:06
Mein Vorschlag:
1. Einheitliches serielles Protokoll festlegen
Beispielsweise:
Anfang Sendung: ???? Byte
Unit Identität (Servo, Sensor, usw.) 1Byte
Befehl 1 Byte
Wert 2Byte
Oder wie auch immer.
Außer dem sendet Robi auf Anforderung:
eine Liste der Unit Namen mit Verweis auf die zugeordneten Unit ID
eine Liste der möglichen Befehle der Unit und deren Befehlsnummer
eine Liste der Einheit in der der Messwert kommt ist zB. cm Grad, Grad C, usw
2. Ein Multi-Thread Betriebssystem für rnbfra 1.2 , basierend z.B. auf dem System von Back1 V 1.0 (mein persönliches Lieblingssystem .-), Danke PicNick) welches auf das neue serielle Protokoll angepasst wird.
3. Erstellen eines PC-Programms mit Grafischer Oberfläche
in Microsoft Visual Basic 2005 Express Edition
(kostenlos und passt sich gut in das smirs-Projekt ein)
Was folgendes leistet:
a. die serielle Schnittstelle handhaben
(gibt es schon z.B. :RS232 von http://www.activevb.de Autor: Björn Kirsch 'Email: bjoern@activevb.de),
b. die Verbindung zum smirs-Projekt herstellt.
http://www.mindrobots.de/cgi-bin/read.cgi?section=algorithms&site=2-0&action=readsite
c. Eine Grafische Benutzeroberfläche mit einer typischen Konfiguration zur Verfügung stellen. Siehe Beispiel
Ich habe das mal beispielsweise angefangen. Möchte aber erst warten ob wir eine einheitliche Lösung finden können.
Das Roboternetz hätte mit einem Schlag ein Wahnsinns-System auf Lager.
Ein rnbfra - Board (https://www.roboternetz.de/phpBB2/viewtopic.php?t=1121) kaufen, Betriebssystem drauf, Sensoren rann und schon kann man einen Roboter über den PC und übers Internet verwalten. Das alles liegt hier lose rum, lasst es uns zusammenbauen.
Hört, hört ! Da hast du ja was vor.
Womit ich als beginnen würde: Bis zum Datalink-Layer für den PC eine .DLL, die kann fast jede Sprache brauchen, und für (AVR) Controller eine äquivalente Library (bascom u. GCC), die im Prinzip auch jeder theoretisch in jedes Konzept einpassen kann.
Dabei wäre es gut, die packages und Schnittstellen soweit möglich an die Usuancen von I2C, CAN, SPI, etc. anzupassen, daß also auch der physical Layer im gewissen Rahmen auswechselbar wäre.
Klingt mächtiger, als es dann ist. Wie du, glaub ich, richtig meinst, ist ja die Standardisierung der Übertragungsverfahren der eigentliche Knackpunkt.
Visal Basic ist grad nicht mein's, ich bin mehr auf C(++) u. MFC unterweges. Aber wenn ich wo helfen kann, gerne.
marvin42x
22.01.2006, 16:50
Zuerst muss ich mal sagen das ich im Verhältnis zu dem was hier im Forum geboten wird ein sehr unerfahrener Programmierer bin. Es ist so, dass ich von den Programmbeispielen anderer lerne und profitiere. Ich werde es also kaum über die Katalysatorrolle hinausschaffen.
@PicNick: Nu erschreck mich doch nicht gleich so :-)
Ja, Du hast recht das Protokoll ist es.
Wenn das festliegt können wieder Aktionen darauf aufbauen. Dazu braucht es aber Fachleute, die helfen Fehler zu vermeiden. Es kann ja mehrere Protokolle geben aber erstmal brauchen wir eines. Selbst wenn man später feststellt das man es anders machen sollte müsste einer hergehen und einfach sagen: So machen wir es erstmal. Punkt, aus, los.
Ideal wäre das Protokoll von smirs schon zu berücksichtigen weil das das Netzrückrad werden sollte.(Ich finde es ist ein geniales Teil, und schon fix und fertig) smirs bietet auch bereits eine dll zur Kommunikation im Netz an. Das Testmodul, was auf dem PC läuft, von smirs ist auch in vb geschrieben.
Zum rnbfra: Es würde erst mal langen wenn das Betriebssystem sich an das Protokoll hält. Das Back1 V1.0 hat intern eine wunderbar strukturierte Kommunikation mit Unit ID , Befehl und Wert, die meiner Vorstellung vom seriellem Protokoll entspricht. Ich habe inzwischen schon viel von dem Programm gelernt.
Wenn Jemand, verlegen grins, zum Beispiel ein Back2 beisteuern könntest was sich vom Back1 lediglich dadurch unterscheidet das es das neue Protokoll verwendet wäre das der Durchbruch auf der rnbfra-Seite. Da könnte dann schon jeder der will andocken.
Nun, der Vorläufer oder großer Bruder vom Back1 war/ist so beschaffen, daß er nicht mit einem Terminal, sondern mit so einem embedded PC zusammen einen "Marsrover" zu steuern hatte
http://195.128.164.40/rt_music/electronic/marsrover/mars.htm
https://www.roboternetz.de/phpBB2/zeigebeitrag.php?t=11313&highlight=marsrover
Da war natürlich die Kommunikation eher in deinem Sinne beschaffen.
Ich werd mir mal die smirs-Sache genauer anschauen.
marvin42x
22.01.2006, 18:31
Noch ein paar Quellen konkretisiert:
Hier bekommt man das smirs Protokoll:
http://www.mindrobots.de/cgi-bin/read.cgi?section=algorithms&site=2-2-0&id=&action=readsite&name=&session=
als PDF runter geladen.
Hier bekommt man das Visual Basic Testmodul mit Quellcode:
http://www.mindrobots.de/cgi-bin/read.cgi?section=algorithms&site=2-1&id=&action=readsite&name=&session=
dazu auch die Main-Unit, die den Netverkehr abwickelt.
Hier bekommt man ein Serielles Schnittstelenmodul in Visual Basic:
http://www.activevb.de/tutorials/tut_com/com.html
was man einfach in das geplante Projekt einhängen kann.
@PicNick: Wunderbar, der Link zum Marsrover, genau da will ich uns Anfänger hin beamen.
Es ist auch genau die Option die mir vorschwebt:
Entweder ein Noteboock auf dem Robi und weiter mit Wireless_LAN
oder zwei rn-Funkmodule an der seriellen Schnittstelle und PC am Schreibtisch mit Internet/LAN-Anschluss.
Das serielle Protokoll ist ja scheinbar mit einigen Tücken behaftet wenn es kompakt und damit schnell sein soll. Das Mainboard beim Marsroover kommuniziert mit dem rnbfra, wenn ich es richtig verstanden habe auch seriell?
Na, dann hab ich ja was zu lesen.
Ja, die Kommunikation beim Marsrover läuft mit der UART. Auf meiner HP hab' ich es ein wenig erläutert.
Aber an sich sollten ev. Standards nicht zwingend mit einer bestimmten Hardware verbandelt sein. Alles, was es für Controller gibt, fängt mit irgendeiner Art Startzeichen an, und dann kommt die Zieladresse und der Rest. Das geht ja auch nicht viel anders.
Die geringen Unterschiede sollten auf der Software-Schnittstelle nicht zu sehen sein, denn das geht die Schichten drüber laut OSI und Picnick nix an.
Naja, weit ist der Weg, und Nuß um Nuß sucht das Eichhorn die Nahrung für den kommenden Winter
bis morgen !
marvin42x
22.01.2006, 20:10
Das muss man runterladen
Visual Basic 2005 Express Edition
http://www.microsoft.com/germany/msdn/vstudio/express/default.mspx
um kostenlos in Visual Basic zu programmieren. Aber Achtung, die neue Version ist mit den älteren nicht ganz kompatibel. Wie das halt bei Office-Dokumenten auch oft ist.
Die Routine zum Einbinden der Kameras in Visual Basic habe ich hier aus dem Forum, habe leider den Link nicht mehr. Die Datei heißt: „webcam x.zip“
@PicNick:Schuldigung das ich dir den Abend versaut habe, aber wir sind halt die Mupped-Labors, wo die Zukunft schon heute gemacht wird.
Ich habe das bei Modems und den Funkmodulen auch gesehen z.B. +++, return, ATS, Registernummer. Eine Identifikation des Robi könnte man sich möglicherweise sparen oder nur einmal nach Aufforderung, weil ja nur einer an der Schnittstelle hängt, das muss man dann nicht jedes Mal wieder runterlaiern . Das weis die PC-Software ja dann. Und wie Du schon sagst, und Herr OSI, die Startzeichen verschwinden lustlos unterm Tisch. Ich habe immer etwas Befürchtung Zeitprobleme zu bekommen wenn die Daten zu üppig werden. Hast Du Erfahrungen vom Marsrover wie kritisch dieser Punkt ist?
..'Schuldigung das ich dir den Abend versaut
Keine Sorge. Da hast du keine Chance. Ich dreh' ja einfach ab. *g*
...die Zukunft schon heute....
Ich hab meine Zukunft schon hinter mir *hehe*
Üppige Daten: Man darf natürlich nicht unmäßig werden. Aber schon bei bescheuerten 9600 Baud gehen ja 1000 Byte in der Sekunde in jeder richtung über den Draht, das ist schon was. Man muß die Commands auch so gestalten, daß man nicht in die Bredouille kommt. Einzel-Steps für zwei Schrittmotoren is nix, klar, da stottert er.
Das "Hayes" Brimborium (+++, AT..., etc) ist beim Verbindungsaufbau natürlich langweilig. Funkmodule für Controller hatt' ich aber noch nicht, müßt man mal gucken.
Das mit der Kamera im Programm hab ich mit den div. Media-Modulen eigentlich schön in Schwung bringen können, is nicht so schlimm. Aber das geht dann ja auch über USB oder sowas.
NumberFive
23.01.2006, 08:26
Siehe da es passiert doch noch was.
Von mir ist die Windows version der MC.
Da habe ich heute Abend ja was zu lesen.
@PicNick
Muß es wirklich MFC sein ?
Grausselich
Gruß
Grausselich
praktisch.
Die switch -Orgien vom Win32 Interface sind mir zu nervig
Aber ich würd' das nie jemandem einreden wollen. Geschmack und Ohrfeigen sind nun mal verschieden.
Johannes
23.01.2006, 14:28
Hi,
das wäre schön, wenn smirs mal verwendet wird. Bald sind Semesterfereien und dann werde ich mich auch wieder an meinen Roboter setzten, auf dem dann auch smirs laufen soll. Bin dann natürlich auch bereit, die Main Control weiterzuentwicheln und Schwachstellen auszubessern. Das System ist ja relativ vollständig, wurde jedoch noch nicht so richtig auf Herz und Nieren getestet. Momentan sind die JAVA und Win-Versionen nicht kompatibel, da ich eigenständig den MMC-Mode entwickelt und in der Java Version implementiert habe, der die Vernetzung von mehreren Robotern ermöglicht.
Wie schon angedeutet, sind die Java-MC, eine .NET-DLL sowie ein VB.Net-Beispielprogramm auf http://smirs.mindrobots.com verfügbar. Dazu stehen einige Informationen über die Funktionsweise des Systems beschrieben.
Also wie gesagt, ich würde mich freuen, wenn wir was daraus machen, denn es war ne Menge Arbeit und es wäre schade, wenn sie nur für mich allein war.
Gruß
Johannes
Was ich noch nicht weiß (vielleicht auch schlecht gelesen :oops: ):
Was ist Controllerseitig schon da ?
Johannes
23.01.2006, 15:57
Controllerseitig hat Numberfive eventuell schon was gemacht. Allerdings hat das nichts mit smirs zu tun, da dieses nur von Rechner zu Rechner funktioniert. Wie auch sonst, die Controller sind ja alle verschieden.
Gruß
Johannes
Nu, ein Portfolio oder Specs kann man trotzdem anlegen.
Was man dann braucht, ist eine Bridge, Router oder möglich gar ein Gateway auf einem der Rechner, der IP auf "smirs232" umsetzt und vice versa.
Johannes
23.01.2006, 16:09
Na es muss so funktionieren. Man definiert, wie du schon sagst, ein "Telegramm" (so heißt es bei smirs) mit den Befehlen, die per RS232 an den Mikrocontroller gesendet werden können bzw. dieser sendet. Diese werden auf dem Rechner von einem smirs-Modul entgegengenommen.
Praktischerweise könnte man das Mikrocontroller-Rechner-Telegramm an das smirs-Telegramm anpassen. Denn dann könnte man vom Mikrocontroller aus z.B. den Befehl "GET|..." senden, und das RS232-Modul würde diesen String nur weiterleiten. Das Modul hätte also relativ wenig Arbeit.
Dieses RS232-Modul ist dann universell, aber die Implementierung auf dem Mikrocontroller muss jeder selbst machen. Natürlich können dann auch wieder Module für die verschiedenen Controller-Sprachen angeboten werden.
Gruß
Johannes
Nur, wenn das Protokoll tatsächlich auch am low-level auf ASCII beruht, müßte der Controller ziemlich viel konvertieren, um da mitspielen zu können. Transparente Übertragung sollte es schon sein.
Halt ich nicht für machbar (f.Controller) bzw. sinnvoll.
Johannes
23.01.2006, 16:22
Ja, könntest du recht haben. Aber wäre ja auch anders möglich, das RS232-Modul übersetzt dann eben.
Gruß
Johannes
Jetzt komm' ich mir so destruktiv vor:
Dann wiederum müßte das RS232 Modul mehr über die Daten wissen, als ihm gut tut. Wie sollte der vier Byte von einem Int32 unterscheiden können, ohne die Strukturen zu wissen ?
Jede Änderung würde alle Bestandteile treffen.
Man müßte sich bei einem Mikro/PC Netz mehr nach dem schwächsten Glied richten. Auch ein Tiny sollte irgendwie mitspielen können, sonst wird das nur eine RPC (Remote procedure call) -Middleware für PCs untereinander.
Ich will nicht Schwarzmalen und schlecht machen, aber ich seh da Probleme.
Johannes
23.01.2006, 18:56
Denkbar wäre auch eine Lösung, bei der mit Hilfe einer Konfigurationsdatei festgelegt wird, was wann passiert.
Gruß
Johannes
*seufz*
Datenkonversion, Config-Files, routing-, mapping-tables, ....
Das wird ein Portalprozess als Gateway zu den Mikros. Da hilft kein Zappeln.
Das is ja nicht unbedingt was Schlechtes, aber es muß euch klar sein.
Die homogene Kommunikationsschicht für Module aller Art auf jeder Platform ist es halt nicht mehr.
Johannes
24.01.2006, 13:32
Tja, man muss wissen, was man will. Aber ehrlich gesgt verstehe ich dein Problem nicht.
Gruß
Johannes
marvin42x
25.01.2006, 12:04
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/dload.php?action=file&file_id=262
Netter Gruß aus der eisekalten Hauptstadt
a..kalte Hauptstadt hab' ich selber :mrgreen: *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
25.01.2006, 13:48
@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
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
25.01.2006, 14:52
> @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
26.01.2006, 15:36
@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
26.01.2006, 15:58
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
26.01.2006, 23:56
@ 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
27.01.2006, 06:54
> 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
NumberFive
30.01.2006, 07:09
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
30.01.2006, 14:20
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
30.01.2006, 20:39
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.
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
31.01.2006, 08:13
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
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
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
31.01.2006, 22:52
> (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/algorithms/smirs/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
31.01.2006, 22:55
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
01.02.2006, 07:19
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
Johannes
01.02.2006, 07:31
Hi,
beim Durchlesen ist mir das mit dem ConnectionType aufgefallen. Ich bin am überlegen, ob wir das nicht wieder rausnehmen sollten, da es nicht viel Sinn macht. In so einem Fall nimmt man lieber eine MC auf demselben Rechner und kommuniziert dann über den MMC-Mode.
Gruß
Johannes
P.S. Irgendwie ist meine Website gerade down, hab schon an den Support gemailt.
NumberFive
01.02.2006, 07:56
Johhanes ich brauch den Connect Typ denn es gibt Teile wo der connect nicht ab gebaut werden soll auch wenn die Verbingung weg ist.
Das TCP modul für den AVR kann kein Stehenden Verbindungen.
Ausser dem in machen System wird es tölichsein wenn die Verbindung weg
ist hier sollte es die Möglichkeit geben drauf reagieren zu können.
Werde noch die Möglichkeit eines Trigger auf das Event bereitstellen damit man drauf reagieren kann.
Was machst du wenn der Navigator weg ist ?
ich lebe in der Welt der Hochverfügbarkeits systeme mit Oracle RAC und sonsitigen redundancen. So wie es im Bereich der BOS halt sein muß Lebenszeich und deren Überwachung sind mir heilig.
Gruß
Johannes
01.02.2006, 12:41
Genau deshalb sollten wir diesen Modus rausnehmen. Der Modus war dazu gedacht, dass der TCP-Server der MC in eine wartende Position geht, wenn ein Modul nicht mehr verfügbar ist. Anwendung: Eine GUI, die sich auf einem anderen Rechner befindet, zu dem teilweise keine Verbindung vorhanden sein kann. Normalerweise müsste sich das Modul dann ganz neu anmelden, was bei einer GUI nervig wäre, schließlich will man ja nur Daten abfragen.
Normale Module, die für die Steuerung des Roboters wichtig sind, befinden sich ja sowieso auf dem selben Rechner wie die MC selbst. Und wenn dort mal ein Modul nicht mehr reagiert, muss die MC Alarm schlagen und nicht einfach warten, bis es wieder kommt.
Verwendet man Module, verteilt auf mehrere Rechner, dann sollte man den MMC-Modus verwenden. Dieser sorgt dann auch dafür, dass nach einen Verbindungsausfall die auf der Strecke gebliebenen Daten wieder synchronisiert/nachgesendet werden.
Also, ist alles nur für die Sicherheit.
Gruß
Johannes
NumberFive
02.02.2006, 14:00
Warum nicht Module im Netzauf teilen da hat man richtige rechenpower (Cluster).
Für mich würde es schon Sin machen den Natigator nicht auf der Selben Maschine wie die GUI laufen zulassen.
Aber ich denke das wir uns eh schon wieder zu sehr abmühen passieren Tut hier eh nix mehr jetzt schreiben nur wir. und vom Thread erfasser ist nix mehr zu hören.
Gruß
... ich denke das wir uns eh schon wieder zu sehr abmühen passieren Tut hier eh nix mehr jetzt schreiben nur wir... ...bitte bitte weiter machen. Ich denke schon das ihr auf dem richtigen Weg seit.
Wenn ich nix dazu sage, soll das ja keine Ablehnung sein. Ich hab nur keine gute Idee dazu. :-k
Was mir prinzipiell durch den Kopf geht: Die beste Technik zur Planung, Arbeitsteilung, Überwachung und der dazu nötigen Kommunikation liefert die Natur. Ist ja auch kein Wunder - die experimentiert ja schon seit Millionen von Jahren.
Da kann man sicher auch Lösungsansätze für dieses Projekt finden. 8-[
Wenn es interessiert, ich hab ein paar Aspekte von Netzwerken hier beleuchtet. ohne irgendwelche Präjudizien für bestimmte Lösungen, soweit das möglich war
https://www.roboternetz.de/wissen/index.php/Network_MC/PC
marvin42x
02.02.2006, 16:30
@NumberFive
Wenn man den Thread offen hat ist oben und unten rechts eine Knopfleiste. Eines der Symbole stellt wahrscheinlich ein Auge dar. Ich meine die Funktion :“Zeige wer den Thread gesehen hat“.
Dort sind alle die mitlesen aufgelistet mit Datum letztes ansehen und Anzahl der Ansichten. Ich weis z.B. das der alte Vogone seit geraumer Zeit ein interessiertes Auge auf diesen Thread hat *grins*. Auch Frank behält das Thema im Auge.
Alle die an diesem Projekt Maßgebliches beisteuern sind überproportional oft am lesen. Es sind alle im Projekt die ich mir erträumt habe. Außerdem haben wir einen sehr konstruktiven und kompetenten Mitstreiter dazubekommen.
Dieser Thread ist sehr kompakt. Wenn jemand in dieses Thema einsteigt findet er hier die geballte Ladung.
Zur Zeit habt ihr das Thema viel strukturierter und kompetenter vorangetrieben als ich das könnte. Die Ausrichtung ist zur Zeit dermaßen in meinem Sinne das ich erstmal nur den Mund halte um den Fluss nicht zu stören.
Ich flatter zur Zeit dem Projekt fachlich hinterher wie der Fuchsschwanz an der Autoantenne. Nebenbei hat PicNick noch einen sehr schönen Artikel über die Problematik und die Zusammenhänge der PC-Microcontroller-Komunikation geschrieben. Das muss ich erstmal als Unkundiger verarbeiten.
Zusammenfassung:
Für mich ist seit Tagen Geburtstag alle sind dabei was ganz tolles zu zaubern wo ich was von abkriege.
Ich wollt mich eigentlich nicht lächerlich machen aber nun, mir liegt das Projekt sehr am Herzen und ich freu mich die ganze Zeit wie ein kleiner Junge, wie das hier abgeht.
Johannes
02.02.2006, 17:36
Ja, Frank hat mir eben ne PM geschrieben und gesagt, dass wir die Infos auch in den Download-Bereich stellen sollen. Ich habe leider im Moment mit meiner Website Probleme, ich weiß nicht, ob jemand von euch schon einen Blick in die längere Beschreibung werfen konnte. Ich habe die Datei noch auf einen anderen Server gepackt: http://mitglied.lycos.de/mindrobots/smirs/guide.pdf
> Warum nicht Module im Netzauf teilen da hat man richtige rechenpower (Cluster).
@Numberfive
Ich bin ein großer Freund von Modulen auf verschiedenen Rechnern. Aber dazu ist der MMC-Mode gedacht. Lies dir mal das Dokument durch und du wirst begeistert sein :-)
Gruß
Johannes
marvin42x
02.02.2006, 18:24
Sorry noch mal das meine Sprachlosigkeit für Unmut gesorgt hat.
NumberFive hat den momentanen Bedarf mE. richtig benannt.
„Wir müssen nur mehr Definieren um es zu einem Baukasten machen zu können“
Zum Multimodulbetrieb:
frage ich mich inzwischen, ob der nicht schon eher gebraucht wird als man denkt
Mal ein Blick auf die serielle Baustelle:
Nachdem ich mir den Artikel von PicNick zu Gemüte geführt habe stellte sich mir eine Frage: Sollten wir uns beim seriellen Protokoll die Einschränkung leisten und nur ein Protokoll haben?.
Die Telekom hat z.B. bei Ihren DSL-Anschlüssen bei guter Verbindung die Option „Fast Path“. Damit können Onlinespieler ihren Ping verkleinern, nehmen aber Fehler in der Datenübertragung in kauf weil die Telekom schlicht die Fehlerkorrektur abschaltet.
Wenn ich nun sehe das auch kleine Microcontroller mitmachen wollen wo das OSI-Modell eh nicht mehr so ausdifferenziert werden kann würde sich anbieten das die sich ein Protokoll wünschen dürfen.
Einen Faktor vielleicht noch. Man hat bei Onlinespielen bis zu einem Ping von ca. 250ms ein Gefühl von Echtzeit darüber wird es ätzend. 60ms sind dagegen volles Echtzeitgefühl. Bei 9600baud wird das schon eng wenn ich später mal mein selbst geschriebenes Verhaltensmodul am laufen habe.
Zum Thema Betriebsystem auf dem Microcontroller:
Es spricht m.E. nichts dagegen wenn es mehrere Betriebssysteme für dasselbe Board gibt, solange sie das Protokoll können. Da brauchten wir dann keine Glaubensfragen austragen. Und hätten Vielfalt die sich gegenseitig inspirieren kann.
Netter Gruß
Wenn es interessiert, ich hab ein paar Aspekte von Netzwerken hier beleuchtet. ohne irgendwelche Präjudizien für bestimmte Lösungen, soweit das möglich war
https://www.roboternetz.de/wissen/index.php/Network_MC/PC
Vielen Dank PicNick, dieser Artikel ist wirklich gut und er kommt im
wesentlichen zu den Ergebnissen, zu denen ich gestern auch gekommen
bin (hatte leider kein Netz).
Im wesentlichen denke ich, dass wir bei unseren Planungen
schichtorientiert denken müssen. Das ganze wird doch ein recht
umfangreiches System und Schichten werden uns helfen, das ganze
besser zu planen, besser zu verstehen und besser zu implementieren.
Klar definierte Schichten sind das A und O an der Geschichte.
PicNick hat schon einen Anlauf gemacht, diese Schichten zu definieren,
ich möchte es nochmal versuchen bzw. meine Meinung dazu sagen.
Ähnlichkeiten mit ISO/OSI sind nicht ausgeschlossen, ich will aber
keineswegs darauf rumreiten. Es geht mir außerdem erstmal nur darum,
welche Aufgaben diese Schichten haben sollen, nicht, wie sie konkret
implementiert werden können.
Schicht 1: Übertragung
- Definiert Protokolle für die Übertragung eines Frames über verschiedene Hardwaremedien.
- Inhalt des Frames (Sender, Empfänger) nicht wichtig
- verbindungslos (keine Antwort des Empfängers)
- nicht zwingend abgesichert (Nachrichten können verloren bzw. kaputt gehen)
- Schnittstelle zu Schicht 2: sendFrame(data, length)
Schicht 2: Routing
- Definiert Frames mit Adressen für Sender und Empfänger
- Jeder Teilnehmer ist ein Knoten und hat eine global eindeutige Adresse
- Alle Knoten sind gleichwertig.
- Die real vorhandene Topologie der Knoten wird versteckt.
- Eventuell erleichtert eine zweistufige Topologie (lokal/entfernt) die Implementierung.
- Routet die Frames zwischen verschiedenen devices
- Kennt alle verfügbaren Geräte der Schicht 1
- Entscheidet bei ausgehenden Nachrichten, welches device die Nachricht schickt
- Entscheidet bei eingehenden Nachrichten, ob der Frame an ein
anderes device geschickt an Schicht 3 weitergeben wird.
- eventuell eine automatische Vergabe von Adressen (bei PicNick: enumeration)
- Schnittstelle zu schicht 1: receiveFrame(data, length)
- Schnittstelle zu Schicht 3: sendFrame(sender, data, length)
Schicht 3: Verbindung
- Kann zusätzliche Verbindungseigenschaften realisieren (durch Steuerdaten)
Mögliche Eigenschaften:
- Datenintegrität (CRC)
- Empfangsbestätigung (Acknowledge)
- Verbindungsorientierter Nachrichtenaustausch (Acknowledge mit Wiederholung)
- ping
- Schnittstelle zu Schicht 2: receiveFrame(sender, data, length)
- Schnittstelle zu Schicht 4: sendFrame(connectionType, receiver, data, length)
Schicht 4: Dienste
- Weist den Daten eine Struktur und eine Bedeutung zu, z.B. Kommandos und Parameter
- Definiert Kommandos für gemeinsame Dienste
- Diese Dienste bilden die Essenz einer gemeinsamen Steuersoftware, GUI, etc
Mögliche Dienste sind z.B.
- Verzeichnisdienst/Discoverydienst
- Heartbeat/Ping
- Debuggingschnittstelle
- Schnittstelle zu Schicht 3: receiveFrame(sender, data, length
Anmerkung: Diese Architektur ist im wesentlichen darauf ausgelegt, einzelne
asynchrone Nachrichten zu übertragen. Ich möchte noch kurz begründen,
warum ich verbindungsorientierte 'Streams' nur stiefmütterlich
behandelt habe:
- Streams brauchen viel Rechenzeit und vergrößern das Datenvolumen
- Die korrekte Behandlung von Streams in uCs ohne Threads ist schwierig (Parallelität).
- Die meisten Dienste lassen sich problemlos auf verbindungslosen Nachrichten abbilden
- Teilnehmer können jederzeit wegfallen.
uCs werden ohne Neustart des Gesamtsystems neu programmiert, Programme neu
gestartet, etc. Streams können dies nicht verhindern sondern nur feststellen.
Der einzige Ausweg aus der Situation ist die Dienste darauf auszulegen,
störungsresistent zu arbeiten, z.B. den Betrieb nach Wiederverfügbarkeit
beider Kommunikationspartner automatisch wieder aufzunehmen.
Sind die Dienste aber sowieso störungsresistent ausgelegt, kann man auch
unsichere Verbindungen in Kauf nehmen.
Anmerkung 2:
Für mich zeichnet sich ab, dass wir das Projekt in zwei große Teile
zerlegen können. Zum einen die Implementierung eines Nachrichtensystems
(Schichten 1-3), zum anderen die Definition allgemeiner Dienst für
Roboterkomponenten (Schicht 4)
@NumberFive:
Wir arbeiten hier nicht für andere sondern für uns selbst. Zumindest
mir geistert diese Idee schon längere Zeit im Kopf herum und dies
hier ist nur der richtige Anlass. Ausserdem kommen wir gut voran
auch wenn man noch keinen Code sieht.
Das ganze ist jetzt erstmal ein Vorschlag. Ich bitte um Rückmeldung.
ciao,
Georg
marvin42x
03.02.2006, 00:58
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ß
@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
03.02.2006, 07:50
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
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
03.02.2006, 16:32
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
04.02.2006, 13:37
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ß
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
04.02.2006, 14:58
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
04.02.2006, 15:16
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ß
[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!
marvin42x
04.02.2006, 16:49
Überkomplexität:
Ich kann NumberFive’s Befürchtung es zu komplex und überfrachtet zu machen nachvollziehen.
Zur Zeit glaube ich aber, wir sollten im ersten Schritt den Grundentwurf ohne Einschränkung und konsequent machen.
Was nicht ausschließen soll das auch jetzt schon über forwarding oder ex/implizit festgelegte Gegenstellen, oder so was nachgedacht werden sollte.
Erst im zweiten Durchgang sollten wir schauen wo wir was vereinfachen/beschleunigen können oder gar das Modell aufweichen müssen (immer daran denken Marvin42x steht auf kleine Pings).
Einem schlanken Datenverkehr Mikro-PC wird das Schichtenmodell letztendlich nicht im Wege stehen (können).
Nutzen:
Ich bin inzwischen der Meinung, dass ein gut und universell ausgeführtes Schichtenmodell mit über die langfristige Zukunft und den Nutzen dieses Projektes Entscheiden wird.
Die geleistete Arbeit soll schließlich nicht in die Grüfte des Vergessens absinken sondern benutzter Bestandteil der Community werden (ich will es natürlich als erster benutzen :-) ). Damit dem so wird müssen einige Kriterien erfüllt werden und das ist eines davon.
MC-rs232:
Mir kommt es eher wie ein Missverständnis vor MC’s über die rs232 zu schicken. Das wäre nach dem Schichtenmodell zwar möglich aber das wird wohl keiner ernstlich anwenden. Rs232 gehört m.E. vorzugsweise zur Welt der Mikrocontroller( hmm….wobei das bei hohen Baudraten , ISDN Modem usw. auch nicht stimmt). Naja, das hat halt viele Aspekte.
Wir müssen ja vielleicht nicht alles gleich Implementieren aber Definieren schon.
Ob man manches vielleicht mal grafisch machen sollte?
Netter Gruß
marvin42x
04.02.2006, 17:10
@Richard:
Das sind ja Interessant Komponenten. Deine Ideen zu dem Rasenmäherprojekt wirst Du, sobald das hier besprochene Projekt laufen gelernt hat auf eine völlig neue Art umsetzen können.
Da fallen dir dann die Gläser aus der Brille :-) .
Die Rasenmähergemeinde wird Rasenstrategiemodule austauschen und auf der Arbeit in der Mittagspause über Internet den Rasenschnitt begutachten.
Unter der Hand werden dann Kantenerkennungdmodule gehandelt.
Bis dahin ist aber noch ein Moment, brauchste noch ein bissel Geduld.
Netter Gruß von meinem gefrorenen Rasen
marvin42x
04.02.2006, 17:32
@NumberFive:
Was hältst Du davon:
„Alle warten gespannt auf das allseits beliebte Rasenerkennungsmodul von NumberFive in der Fehlerbereinigten Version 2.6 . Die Version 2.5 hatte noch gewisse Schwierigkeiten mit der Erkennung der Tulpen vom Nachbarn, was in der Vergangenheit zu einigen missliche Situationen geführt hatte“
Ein schönes Wochenende noch für alle Beteiligten
@Richard:
Bis dahin ist aber noch ein Moment, brauchste noch ein bissel Geduld.
Netter Gruß von meinem gefrorenen Rasen
Moin moin Marvin,
Na ich bin ja auch noch am Sammeln, diese Jahr wird es wohl nicht mehr.
Angeblich kann der BS- Sensor je nach bitzahl des eingesetzten A/D Wandler bis zu 49 mm auflösen ehe sich größere Fehler einschleichen. Aus x,y Vektor sollte sich dann die momentane Position ermitteln lassen.
Momentan mache ich mir da eher Sorgen wie das Programmtechnisch "Rückwärts" = Motorsteuerung ablaufen soll und klar, der Rasenmäher braucht einen festgelegten Start Platz was Position und auch Richtung betrifft mit einem Reset .
Sehr interessant ist natürlich auch Bildauswertung und für Fußballrobs die Vernetzung untereinander zur Stategieabsprache. Dafür dürfte dann aber eine Kamera kaum ausreichen, eine müßte IMMER das Tor inklusive der jetzigen Position (auch des Torwards) überwachen und einen diereckten "Draht" zur Motorsteuerung haben.
Dann eine für die Balllokalisierung, eine die den "Feind" im Auge behält und eine welche eigene Spieler lokalisiert und wenn nötig auch zu Torgünstigen Ball Abgabepunkten dirigiert....Viiiiel Arbeit!
Ich bevorzuge da (Gedanklich) neinfach etliche Autonome Systeme (Prozessoren) in einem Bussystem. Jeder Acktor z.B. Radsteuerung, seine eigene Intelligenz die Autonom ihre Arbeit überwacht und vorgegebene Verhaltensmußter aus empfangenden Daten ausführen kann.
Aber auch möglichst jeder Sensor sollte entscheiden können ob eine Weiterleitung wirklich "Jetzt" nötig ist, halt eine gewisse Eigenintelligenz der einzelnen Systeme. Beispiel, wenn Du auf eine heiße Herdplatte greifst, entscheidet das Rückenmark, nicht das Hirn die Hand zurück zu ziehen.
Letztendlich geht es mir nicht einmal ums Rasenmähen, aber da ich diese Arbeit hasse...Ich möchte mich einfach mit den Möglichkeiten Autonomer Rob Systeme auseinander setzen und dazu gehört halt auch das diese Systeme eine Netz Struktur aufbauen bei der derjenige der Empfang zum Nachbarn hat als Router zum zu weit entferntem Ziel arbeitet..
Viiiel Arbeit. ;-)
Euer Projekt ist sehr interessant, übersteigt aber doch ein wenig meine Fähigkeiten. Ich werde mich jetzt besser nach "Rasenmäher" verkrümeln um euch nicht in die Quere zu kommen und euren Thread zu zerstückeln.
Grüße Richard
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.
@Johannes:
Genau darauf will ich ja hinaus. Hier liegt der Hund begraben. Das
Kommunikationmedium der MCs ist nicht losgelöst von den Nachrichten,
die darüber übertragen werden. Deshalb kann ich nicht einfach ein
neues Kommunikationsmedium einführen.
Selbst wenn ich jetzt eine MC schreibe, die das MC-Protokoll intern
auf RS232 ummodelt funktioniert dieser Proxy nur dann, wenn er alle
Funktionen einer MC implementiert und weiterleitet. Ändert sich also
irgendwas an der MC, muss ich meinen Proxy entsprechend ändern. Das
ist keine schöne Softwarearchitektur.
Unterm Strich sind die MCs damit praktisch auf Rechner mit IP festgelegt
und das ist für meine Ziele bei weitem nicht ausreichend.
Das Problem bei smirs ist aber IMHO auch, dass smirs sich eigentlich
auf die Dienste-Ebene beschränkt, wobei einer der beiden Dienste die
Übertragung von Nachrichten ist. Ich muss mich aber fragen: welchen
Nutzen habe ich von diesem Dienst, wenn alle Module sowieso IP sprechen ?
Warum kommunizieren meine Module dann nicht direkt miteinander, sondern
benutze das relativ aufwändige TRANSFER-System smirs ? Ich stimme zu
das es notwendig ist Dienste zu definieren. Ich stimme auch zu das
es notwendig ist ein 'abstraktes' Kommunikation/Adresssystem zu definieren
(Wie bei smirs über die Adressierung bei Transfer mit 'MC->Modulname').
Nur wenn schon dann sollte man es konsequent machen und die beiden
grundverschiedenen Dinge 'Kommunikationsinfrastruktur' und
'Variablensynchronisation' voneinander trennen. Wenn man dabei
die Variablensynchronisation als Schicht auf der Kommunikation
aufbaut, dann bekommt man nämlich ganz automatisch unabhängige,
modulare und flexible software.
ciao,
Georg
PS: Bitte sieh das ganze als konstruktive Kritik. Ich werde gerne jeden
Punkt noch weiter aufdröseln wenns sein muß. Nur leider sieht es für
mich im Moment nicht so aus, das smirs annähernd das erfüllt, was ich
für notwendig halte.
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 Problem das Menschenlesbarkeit immer die Performance drückt
existiert natürlich. Trotzdem denke ich sogar mein Schichtenmodell
ließe sich _einfach_ menschenlesbar gestalten. Und zwar ohne
unnötigen Overhead zu produzieren.
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.
Da muß ich dich korrigieren: CORBA mag nicht breit vertreten sein,
es ist aber absolut ausgereift und erleichtert so manche Dinge
ganz ungemein. Ich will auch kein so kompliziertes System wie
CORBA entwerfen, ich will nur Nachrichten hin- und herschicken.
Das ist doch mit Sql komandos genauso.
Warum verwendet dann jeder SQL-Kommandos ? Weil sie ausreichend
abstrakt sind um dein Problem zu lösen aber noch ausreichend einfach
um sie zu verstehen.
Ich will keine Eierlegende WollMilchSau und kein perfektes System.
Ich will allerdings ein System, mit dem ich von der Hardware
abstrahiert kommunizieren kann.
ciao,
Georg
PS@Richard, @marvin42: Hat euer Rasenmäherroboter eigentlich was
mit dem Thema zu tun ? Sonst macht doch bitte euren eigenen thread auf.
So, ich schon wieder. Nachdem ich nun die halbe Nacht über
gesicherte und ungesicherte Nachrichten nachgedacht habe,
möchte ich euch meine Gedanke nicht vorenthalten.
Dreh- und Angelpunkt der Überlegungen ist die Tatsache, das die
Nachricht auf verschiedenen Ebenen gesichert werden kann. Zum
einen in der Verbindungsschicht, zum anderen in der Übertragungs-
schicht. Interessant wird diese Tatsache jedoch erst bei
Nachrichten die geroutet werden. Hier kann die Übertragungsschicht
aus unterschiedlich gesicherten Segmenten bestehen. Ist die
Übertragungsschicht vollständig gesichert, dann ist die
Sicherung auf Verbindungsebene sehr viel einfacher. Sicherung
von Nachrichten kostet auf jeder Ebene Rechenleistung.
Wünschenswert wäre deshalb für jede Nachricht die Übertragung
mit der minimalsten(performantesten) Sicherung.
Diese Überlegungen sollen eine Entscheidungshilfe sein, ob
und auf welchen Schichten wir sichern.
Erstmal eine Übersicht, welche Arten von Nachrichten es gibt.
1.) Ungesicherte Nachrichten ohne Acknowledge
- Keine Wiederholung
- Kein Acknowledge (für den Absender)
- Broadcastfähig
- Kann jederzeit verlorengehen
2.) Gesicherte Nachrichten ohne Acknowledge
- Gesichert innerhalb der Übertragungsschicht (Wiederholung)
- Kein Acknowledge (für den Absender)
- nicht Broadcastfähig
- kann verlorengehen, jedoch unwahrscheinlich
3.) Nachrichten mit Acknowledge (gesichert und ungesichert)
- Gesichert innerhalb der Verbindungsschicht und der Übertragungsschicht
- Bei durchgehend gesicherter Übertragungsschicht: Wiederholung nur in der Ü-Schicht.
- (Bei nicht durchgehend gesicherter Ü-Schicht: Wiederholung auf beiden Schichten.)
- Acknowledge/Timeout für den Absender
- nicht Broadcastfähig
- kann verlorengehen, jedoch unwahrscheinlich + wird erkannt
Anmerkungen zu 3.)
Auch der Acknowledge ist im Prinzip eine eigene Nachricht, die
verlorengehen kann. Deshalb bietet es sich an, Nachrichten mit
Acknowledge als Kombination zweier Gesicherter Nachrichten ohne
Acknowledge zu übertragen. Das Acknowledge ist damit eine
'reguläre' Nachricht (auf Schicht 3), die z.B. auch Daten
enthalten kann. Je besser die Übertragungsschicht abgesichert
ist, desto schneller effizienter funktioniert die
Verbindungsschicht.
Fragen die wir uns stellen müssen:
1.) Ist es sinnvoll/notwendig die Übertragungsschicht durchgehen zu sichern
2.) Wenn ja: mit einer eigenen Zwischenschicht oder sichert sich die Ü-Schicht selbst ?
3.) Ist es sinnvoll/notwendig eine Verbindungsschicht zu haben ?
Bei den Fragen sind wohl die uCs der Entscheidende Faktor, denn für
größeren Rechner würde ich alle drei Fragen mit ja beantworten.
Anmerkungen:
Gesicherte Nachrichten und ungesicherte Nachrichten lassen sich (fast)
gleichgut empfangen (Ü-Schicht sendet ack, fertig)
Gesicherte Nachrichten zu senden ist aufwändiger als ungesicherte
Nachrichten, jedoch nicht unbedingt schwierig
(auf Ack warten oder wiederholen, timeout)
Hat der uC gesicherte Verbindungen ohne Acknowledge, sind die
Anworten auf Nachrichten mit Acknowledge einfach.
Initiieren von Nachrichten mit Acknowledge ist schwierig
(Asynchron, speichern, wiederholung, timeout)
Alle gesicherten Nachrichten bedeuten erstmal mehr Protokollaufwand.
In diesem Sinne würde ich folgendes vorschlagen:
1.) Erstmal nur ungesicherte, verbindungslose Nachrichten implementierten.
2.) Im zweiten Schritt kann dann die Übertragungsebene gesichert werden,
am besten ohne Zwischenschicht. Dann kann die Ü-Schicht selbst entscheiden,
ob und wie sie die Nachricht sichert. Auf uCs ist es nicht möglich,
gesicherte Verbindungen zu initiieren.
ciao,
Georg
Das ist ein Thread, wo fast jeder Post eine Doktorarbeit ist :-)
@Ragnars Vorschlag 1.) kann man, insbesonders wenn man an einer technischen Durchführung 'rumhirnt, auf jeden Fall als "condito sine qua non" betrachten, denn bevor man das nicht hat, geht was anderes auch nicht.
Es gibt auch gut Kundschaft dafür: Wenn ein Sensor am µC alle xx mS einen Meßwert liefert, kann er ihn ja wohl nur broadcasten, jede Fehlerbehandlung durch ev. Wiederholung pervertiert, denn dann ist der Meßwert ja schließlich schon obsolet und ein neuer fällig.
Fehlererkennung setzt voraus, daß darauf auch sinnvoll reagiert werden kann, sonst ist es Luxus.
D.h. aber konkret, daß bei einem µC / PC Netzwerk wahrscheinlich 90 % des Traffic in diese Kategorie fallen, was uns die Sache leichter machen könnte. Da brauchen die Empfänger nix als eine "Ausfall" Erkennung durch Timeout o.Ä.
anders bei Kommands PC --> µC, die sicher sensibler sind. Auch da brauchen untere Schichten nicht gar so viel Aufwand treiben, den sowas muß so schnell wie möglich der Applikation gesagt werden. Ellenlange Negotiations von wegen repeat etc. kosten nur Zeit.
@PicNick:
Danke für die Lorberen, ich habe mir wie gesagt ein paar Gedanken gemacht ;-)
Schön auch, das du mir inhaltlich zustimmst. Ich hoffe nur, ich kann auch
Johannes und NumberFive überzeugen an dem neuen Projekt mitzuarbeiten,
auch wenn von smirs dabei nur ein paar Algorithmen übrigbleiben.
Ich werde mich heute mal hinsetzen und eine konkrete Implementierung
vorschlagen, damit alle mal sehen wie schwer (bzw. eigentlich wie
leicht) sich das ganze umsetzen lässt.
ciao,
Georg
Ich hab das ganze ja mal durchgezogen gehabt für den Marsrover
http://www.oldformation.at/electronic/marsrover/mars.htm
und war recht zufrieden mit transparent-daten- übertragung (RS232) durch Byte-stuffing (mit ein paar einschränkungn wegen der Vorgaben).
https://www.roboternetz.de/wissen/index.php/Bascom_UART_Input#Byte-Stuffing
Man hört sich !
NumberFive
05.02.2006, 16:41
Na das ist aber ordenlich lese stoff da komme ich heute nicht mehr durch.
Aber ich werde dran bleiben.
Warte jetzt aber erstmal auf den Implemetierungs vorschlag.
Dann ist es nicht mehr so abstract.
Vieleicht kann man auch beides Implemetieren.
Gruß
Johannes
05.02.2006, 20:53
> Ich hoffe nur, ich kann auch Johannes und NumberFive überzeugen an dem neuen Projekt mitzuarbeiten, auch wenn von smirs dabei nur ein paar Algorithmen übrigbleiben.
Das kann ich so nicht sagen, ich werde auf jeden Fall für meinen Roboter smirs verwenden und es weiterentwickeln. Sollten wir wie gesagt gute und sinnvolle Änderungsvorschläge finden, dann würden ich es gut finden, wenn die in smirs einfließen.
Schauen wir mal, ich bin gespannt auf die Vorschläge.
Gruß
Johannes
Hallo Freunde der Softwarekunst,
ich habe jetzt auf drängen (*&%$X³) mal das im Forum gekostete PDF „smirs guide.pdf“ 546 Kb gelesen.
Meine Erwartungshaltung war ein System das eine Modularisierung der Softwareteile regelt bzw. erzwingt.
Ich habe aber die Beschreibung eins Properhitären Datenformats vorgefunden das mit den TCP Standards in Pere to Pere gehandelt wird.
Zudem war eine Art Styleguide zur Implementierung der Clients dabei.
Fehlen mir noch Dokumente?
Hier an dieser Stelle möchte ich auf dieses Dokument schon mal eingehen... ohne auf Details wie „wie packe ich | in einen Datenstring?“ eingehen sondern schon mal was elementares Fragen vielleicht auch Vorlegen.
Gibt es später/jetzt standardisierte Datentypen oder ist das Stringformat beliebig zu interpretieren?
Wird/Ist die die Möglichkeit (abgesehen von Streams) Binärdaten zu übermitteln und ist hierfür dann Base64 oder gleich das HTTP-Protokoll like RFC vorgesehen?
Ich bräuchte eine Standardisierung der Wegstrecken.
Meile <-> Kilometer <-> Meter um im GUI nicht von Gummimetern erzählen zu müssen.
Auch eine Standardisierung anderer Phys. Einheiten wäre nett.
Die Bildübermittlung solle mir dann auch verraten können um welches Datenformat es sich handelt und mit welcher Konvertierung es gerade durchs Netz rauscht.
Mit diesen Features könnte ich dann eine Software schreiben die annähernd kompatibel zu andern Systemen die genauso verfahren ist.
Diese Fragen sind relevant für mein geplantes Standard-Web-GUI für Roboter.
Ich habe bislang geplant für den Datentausch wie gewöhnlich SOAP zu verwenden und weitere Systemteile sofern notwendig mit CORBA zu verschabbeln.
Ist S²MIRS als etwas ähnliches angedacht oder ist das Layer zu tief?
Ich habe noch nach weiteren Dokumenten gesucht aber die Webseite selbst erscheint mir ziemlich ähnlich.
Postet mal die Links mit den Doks, die man kennen muss um über pragmatischere Dinge zu texten, ohne in hypothetisches gefaselt abzuwandern.
Ich würde auch im Zuge meines WEB-GUIs mitprogrammieren ... nur muss ich das ganze erstmal verstehen.
Gruß,
Chris
PS: An die Doktorarbeitschreibsler ...etwas pragmatischer wäre net schlecht, denn ich bin Informatiker und kein Theologe. Und der glaube an ein System das multi private, public semiperstent, private persistent, private kill... rollback public .. watch hangoff .. deadloop ... watch external, handeln kann ist bei mir und zudem Naturwissenschaftlich schon widerlegt.
Ihr lauft damit Gefahr durch Seiteneffekte die KI zu erfinden ;-)
DON`T PANIC
marvin42x
06.02.2006, 09:00
Hi UlrichC
Ich kann Dir nur ganz grob einige Sachen aufzeigen wie ich sie sehe.
Ragnar hat weiter vorne ein Schichtenmodell vorgeschlagen.
Schicht 1 Übertragung
Schicht 2 Routing
Schicht 3 Verbindung
Schicht 4 Dienste
Ragnar z.B.möchte bis Schicht 3 bei der Entwicklung helfen.
Nach diesem Modell sind
Deine geplante GUI Schicht 4 .
Deine angeregte Festlegung von Werten Schicht 4.
Zur Zeit liegt der Fokus auf den Schichten 1,2 und 3 um der Schicht 4 die Plattform-Unabhängigkeit zu schenken.
Bevor das nicht steht kann man der Schicht 4 nicht sagen was sie vom Datenverkehr erwarten darf und was sie erfüllen muss.
Die Datenübertragung wird im Bereich PC-Mikrocontroller aus Performancegründen vermutlich Transparent, also keine Strings.
PC-PC müssen wir abwarten wohin die Meinung sich verdichtet.
Netter Gruß
In Richtung UlrichC
Ich würde/werde den Weg gehen, daß beim Startup und auf Anforderung vom µC eine Liste/Portfolio der Geräte zur Registrierung verbreitet wird. dabei sollte u.a jedes Gerät auch (codiert) mitteilen, welche Datenformate /strukturen es verwendet. Also auch implizit oder explizit, welche Einheiten verwendet werden (Raw, gummimeter, Degree/rad, etc. oder auch strukturiert, wie z.b. GPS oder DCF77 daten.
Es gibt ja auch bei Floatzahlen Unterschiede. Und auch Byte -Order, usw., wenn man will.
Das klingt wilder, als es ist, denn die meisten Geräte sind ja durch eine Bezeichnung ("LM75") ausreichend definiert, und auf einem PC ist es ein Leichtes, ein passendes "Dictionary" a la XML zu den Geräten zu führen.
Ziel ist es, möglichst viel Konversionen und Mappings auf den PC zu verlagern, denn der hat Platz und Leistung.
@marvin42x
In meinem Beitrag bezog mich eher auf S²MIRS... das sollte ich mir durchackern.
Klar GUIs liegen immer auf der oberen Anwendungsebene nur ich dachte mir hier die eigene Implementation der darunterliegenden Ebenen sparen zu können.
Wenn ich warte mit meinen Beiträgen bis die Kiste soweit ist ... erzählt man mir dann vielleicht: "geht nett, mach was anders"
So etwas wurde ja schon manchmal erdacht ... das letzte mal war es eine Frau die die Laube hinterher BlueToth nannte .. wenn ich mich nicht irre.
Ja nun mal weiter
Für gewöhnlich hat man für die Programmierung Treiber und Schnittstellen... es gilt doch diese hier zu Standardisieren?
Ok, das mit den Layern klingt irgendwie wie Standard TCP/IP ...
Gar nicht so übel wenn man das wirklich in einen Contoller packen könnte.
Als ich den beginn des Thread verfolgte glaubte ich an eine Lösung wie den ODBC-Standard nur für Controller
-gepaart mit einem TCP/IP fähigen Applikationserver und einer Standard-Schnittstelle für Module
-die per Ableitung in C++/Java verwendet werden kann.
Die Protokollhackerei ist nicht wirklich prof. Einsatzfähig... jedenfalls nicht als Architektur... ich will mal erläutern was ich unter einer Standard Schnittstelle verstehe.
1. Ein Applikationsserver
-Der alle Module laden/entladen/verwalten kann.
-Mit einer Schnittstelle zu TCP/IP ... zum aufsetzen an andere Server
-Eine Schnittstellebibliothek für IC/2 und RS232 ... macht die Arbeit der Treiberprogrammierer einfacher
-Ein Master Bussines-Objekt das zur Einhaltung der Standards zwingt... hier setzen alle auf die ins System wollen
-Mit einer Oberfläche (für den händischen Eingriff) ... man will ja sehen was passiert.
2.Bussines-Objekt Styleguide
-Anleitung zur Implementation eigener Module. (Das können Treiber .. Oberflächen oder auch alg. Steuerungen sein)
Weiteres...
Zwischen den Modulen könnte reinstes XML über den Applikationserver gehandelt werden (ohne Sockets aufzureisen)
Die Module der Controller/Driver/AVR/PIC was auch immer Schicht könnten verfahren wie Sie wollten solange Sie im eigentlichen Modul (dem Treiber) kompartibel zum Appserver sind.
Für TCP/IP also von Rechner/Roboter zu Rechner/Roboter könnte SOAP (XML-Protokoll) eingesetzt werden ... aber über die Schnittstellen des Applikationservers.
Also im Grunde ein vorgefertigtes System .. das arbeit abnimmt und freiräume lässt.
In einer Hochsprache... mit Treibern zu den Controllern ... netten GUIs
Eine Art DEV Studio/Plattform/BDE für Roboter.
So hätte jeder eine Baustelle... Treiber , Server , Kommunikation, Protokolle , Oberflächen .
http://www.ulrichc.de/project/cu-www-gui/
@PicNick
Prima, ein + für die Kommunikation zwischen den Geräten.
Ein trivialer Variablenchat reicht eben nicht aus.
Im groben setze ich also doch richtig auf ... hab also nicht viel überlesen ;-)
Netter Gruß,
Chris @all
PS: Das mit der Prakmatik ist so ne Sache... Wenn man die Praxis kennt ist es einfacher im reversemode ein System zu schachteln...
Andersrum läuft man Gefahr ein System zu bastelln das hinterher keiner praktisch einsetzen möchte. (gibts ja oft)
So verwende ich Beispielsweise auch nur CORBA wenn ich muß ... und SOAP weil ichs mag und ODBC weil ichs kenn und brauch.
NumberFive
06.02.2006, 11:56
Also gegen xml über tcp habe ich was das ist zu viel Mühl pro telegramm.
Um 4 Byte rüber zu bekommen muß ich 20 schicken da mach ich net mit.
Für Konfig vielleicht noch aber ich für die Telegramme.
Gruß
Auf PC-Basis muss man denke ich keine Bytes zählen.
Zudem produziert jedes Protokoll ein gewisses maß an Müll ...
VAR|20
Oder
<VAR=20 />
?
Ok 7 Bytes Mehr.. ;-)
Man könnte SMIRS-Notationen in XML verbauen und beliebig erweitern... ohne alle anzuleiten einen neuen Parser zu schreiben.
Die Parser gäbs sogar schon fertig... die Notation wäre bekannt und die Regeln hierfür wären also schon geschrieben.
Um ein Properhitheeres Format soweit zu bringen, das es Objekte ... Strukturen und deren Verschachtelung bzw. Abhängigkeiten handeln kann ... ohne den Entwicklern einen Knoten in die Birne zu projektieren ist ein Haufen Arbeit bzw. Erklärungsbedarf notwendig.
Das was ich bisher von SMIRS gelesen habe ist nicht zu verachten, nur mit XML um vieles Ausbaufähiger. Und vor allem auch mächtiger – und vielleicht auch Kompatibler zu anderen Systemen.
Ich könnte Viewer, Parser, Validatoren, Analyzer etc. verwenden die es schon fertig frei gibt... Zudem könnte durch eine kleine SOAP-Packung die Roboter übers Internet vernetzen ... ohne neue Gateways Proxis NamingServices DNS und der gleichen selbst schreiben zu müssen.
Wie getextet ... auf Treiberebene wäre es fast egal wie angebunden wird... hier könnten dann Strings – Byteformate und Flags geschoben werden... ob die Variablen dann Public , private , persistent, transient , temporär oder internal sind wäre egal...
Wichtig wäre nur die Schnittstelle zu einem evtl. Server die bei allen Modulen gleich wäre.
Da könnte man/sollte man mit „A<1 Byte><1Byte>E“ verfahren und dies zum Standard erklären. Nur auf der PC-Seite muss man alle Feinheiten der Softwaretechnik bieten ... ein eigenes Format würde da zu sehr begrenzen.
Einem Entwickler (nich API Entwickler) ist das XML-Gemehre dann auch herzlich egal...solange die Schnittstelle funzt. Ermüsste nämlich selbst keine Sockets PufferdReader BinStreams .. QStreams , ByteArrays (wow so viele Sprachen) programmieren ... er hätte ja seine Schnittstelle die fern ab von Send und Recive wäre.
Schnittstelle:
Name
Description
Params
Status
Command
... wie auch immer.
Funktionen:
Int GetParam(„key“)
String GetParam(„key“)
bigEndian GetParam(„key“)
Image GetParam(„key“)
T<Class> GetParam(„key“)
Set...
Module * GetModule(“Name”)
u.s.w.
Ich will hier nicht die Funktionsweise eines ApplicationServers erläutern .
Wie gesagt nur so ne Vorstellung.
Will eigentlich auch nur ne Web-GUI ... wie meine Livecam nur mit Roboter-Fahrwerk ;-)
Netter Gruß,
Chris
EDIT: Die Schnittstelle ist nur proforma..also nicht hinterdacht.
EDIT II:Durch den kompiler geht se auch nich ... einer Programmiersprache entspricht se auch nich ... nur einer Intension ;-)
Insofern hat Chris natürlich recht: wenn man mal soweit ist, daß man derartiges andenkt, wird man den Teufel tun und was Neues zur Applikationsanbindung erfinden. Selbst wenn es in epische breiten geht ("XML") ist trotzdem der Standard an sich dann mehr wert als geniale Eigenkonstrukte.
Denn für Standard gibt's auch Standardprodukte aller Art.
Ich seh keine wirklichen Konflikt mit den Überlegungen über die diversen Layer drunter. Das ist ja mehr die Frage, wie man dann irgendwo oben PC-saftware anbinden will.
Richtig! Ich texte hier auf jeden Fall nicht von der eigentlichen Hardwareanbindung ;-) denn im Falle von XML texte ich ja von der Vernetzung über die Rechnergrenzen hinaus ... und nicht von der Vernetzung mit dem Rechner selbst... denn das will ich mir sparen.
Die Anbindung der unteren Layer über eine einheitliche Schnittstelle (zu diesem Layer).
Also die obere Schicht(en) Abgrenzen von dem was drunter kommen mag.
z.B.
Man packt die Hardwareanbindung in eine Treiber DLL (DynamicLinkLibary WÍN) oder SO(SharedObject LIN) diese dann durch einen/diesen/jenen ApplicationsServer geladen/entladen wird und die Anbindung zwischen zwei Programmteilen herstellt.
Die DLL-Schnittstelle muß fest vorgeschrieben sein um die Funktionszugriffe des ApplicationServers nicht in leere Laufen zu lassen.
Es können beliebige DLLs, ActiveX oder SO oder von diesem Programmteil (ApplicationServer ) geladen und miteinander verbunden werden.
Das Programmteilstück das alle lädt und verbindet hat schon einen festen Namen (sowie die Architektur) nennt sich ApplicationServer in der Softwaretechnik.
Das ist also alles nix neues ... nur bewährtes.
Die DLLs oder SOs vielleicht auch AktiveX
Die einzelnen Module (Treiber, Oberflächen, Auswertungen ...) können je nach Auslegung der Schnittstelle in verschiedenen Sprachen geschrieben sein.
Als Hilfe zur Programmierung gibt es dann Klassen von denen man ableiten kann bzw. muss um alle benötigten Schnittstellenfunktionen bedienen zu können ohne selbst welche bauen zu müssen.
Für C könnte man ähnliche Konstrukte mit Standard Bibliotheken anwenden.
Die Module (interne und externe) können sich untereinander über den ApplicationServers unterhalten.
...über Messagepoolin, Message-Stack, Message-Spooler, Datei, Messageque, SharedMemory-Handling oder Windows Messaging wie auch immer... das ist Bier des Applikationserverbauers ;-)
(Ich glaube NumberFive macht so etwas ähnliches in seiner Version).
Ob man dann wirklich XML einsetzt ist auch offen... er sollte jedenfalls eine Netzübergreifende standardisierte Geschichte wählen die auch Lösungen für Binärdaten und Strukturen sowie Objekte (serialize Geschichten) an Board hat.
Praktisches Beispiel WebGUI mit Roboter und CAM.
1.Roboter mit Cam (is klar)
<Kabelsalat>
2.Microprozellor (*XXX)
<RS232>
3.Treiber (Modul des Systems) (*XXX mit fester Schnittstelle)
<ApplikationServer>
4.GUI (Modul des Systems) <-> Messdatenerfassung <-> Steuerung
*XXX = Frei wählbare Auslegung der Programmierung ... in diesem Bereich möchte ich derzeit nicht mitquatschen.
Das ist so im groben die etwas anders beschriebene Fassung.
Das mit den Abgeleiteten Treibern gibt eben die meiste Freiheitsgrade und lenkt das richtige Ergebnis.
Eine Treiberbibliothek könnte vielleicht beim anhacken des Roboters über RS232, Parallel , USB, Infrarot ;BlueT...
helfen... nur sind die Möglichkeiten und Variationen sind mannigfaltig.
Netter Gruß,
Chris
PS: Ich werd mal eine Architektur malen... es ist nun alles a bisl verwirrend wenn man es nicht schon kennt... zudem will/muss ich ernsthaft so was basteln um Bilder und Strukturen übers Netz (WWW) zu bekommen.
marvin42x
06.02.2006, 16:29
@ NumberFive: Möglicherweise ist deine Befürchtung mit dem Müll senden nicht ganz so gravierend wie es im ersten Moment aussieht.
Ich sehe auf der einen Seite einen Mikrocontroller der sich mit 9600 bit/sec abmüht.
Ich sehe auf der anderen Seite mal ungünstig ein 10Mbit LAN mit 10 000 000 bit/sec.
Das ist 1000 mal mehr. Da könnte man das Verhältnis 4 zu 20 Bytes eher entspannt sehen
Ihr dürft mich schelten wenn ich mich mit den vielen Nullen vertan habe.
Netter Gruß
Edit: Sorry habe den letzten Beitrag nicht mitbekommen. Ihr seit schon weiter.
weiter so, sehr spannend.
NumberFive
06.02.2006, 18:39
Ok wenn ihr drauf besteht aber ich denke das die Menge nachher vielleicht och ein Prob wird aber lassen wir das erstmal.
Naja in meinen ComTCP dll Gibt es so was Fasst schon die hat eine MCConnect metode und eine Spilt metode. das würde dem der Progrmmieren
will ja schon fast reichen ok wir müssten an stand der Nummer (pos im string)
einfach nur einen Namen über geheben und dann währe wird schon nah dran.
Ist <var =20 \> wirklich xml konform ich kenne nur das <Name>Wert</Name> und das ist heftig mehr.
wegen der RS232:
Ich denke 9600 ist denke auch nicht das Maß 38000 sollten es schon werden was machen die funkt module ?
Oh ich muß auf passen das Thema reiß mich zu Stark ich muß noch ein robi zu laufen bringen.
Ist <var =20 \> wirklich xml konform ich kenne nur das <Name>Wert</Name> und das ist heftig mehr.
Jo klar fast *knirsch shit* :^o ,
is alles drin.
<var>20</var>
<var v=20 />
<var v=20></var>
...aber wie getextet das Zeug soll nicht über RS232 Funk oder ähnliches Schicken ... nur internes bzw. Netzwerkformat.
Denn man kanns durch die Leitungen jagen... und mit einem HTTP header versehen (als SOAP) durch jede Firewall auf P:80 durchs WWW jagen ;-)
Aber ich male nun erstmal ne Architektur... bis denn.
Mir geht nämlich der Text aus ;-)
Gruß,
Chris
Jetzt mal was konkretes
Nachdem ich es neulich schon mal angekündigt habe, kommt jetzt
ein Vorschlag, wie man meine Schichten in der Praxis implementieren
könnte.
Schicht 1 - Übertragung
Übertragen werden Datenblöcke mit einer bestimmten
Länge entweder direkt oder als Broadcast. Sollte als
serielle Variante problemlos auf einem uC implementierbar
sein.
Seriell:
Für seriell ist die direkte und die broadcast-übertragung gleich.
Es existieren verschiedene Möglichkeiten, das Datenpaket zu
übertragen. Meines Erachtens am besten wäre hier das von PicNick
genannte Byte Stuffing, bzw. eine ähnliche Form davon mit Escape-
sequenzen und Framing. Im Gegensatz zum ByteStuffing ist das
Kontrollzeichen hier absolut eindeutig im Datenstrom, was die
die Fehlertoleranz noch etwas verbessert.
LAN:
Am einfachsten und performantesten ist wohl die Übertragung durch
UDP-Pakete über einen festgelegten Port. Dabei können broadcasts
und direkte Nachrichten über die entsprechenden UDP-Äquivalente
verschickt werden. Interessant am LAN ist noch das 'Finden' der
anderen Teilnehmer. Dafür würde ich Lan Kontrollpakete vorschlagen,
mit denen neue Teilnehmer auf dem LAN sich bei den anderen
Teilnehmern bekanntmachen.
Schicht 2 - Adressierung/Routing
Adressierung:
Einzelne Knoten werden über zwei Bytes adressiert. Dabei ist
ein Byte die eigentliche Adresse, das andere Byte das Subnetz.
Zusammen bilden sie eine eindeutige Adresse für jeden Knoten.
Bei jedem der beiden Bytes gibt es zwei 'spezielle' Werte. Der
Wert 0 ist eine Broadcast-Adresse, der Wert 0xff die eigene
Adresse. Bei Broadcasts kann also nicht nur in das 'lokale'
Subnetz gebroadcastet werden. Wird für die Adresse ein konkreter
Wert eingetragen und für das Subnetz die Broadcastadresse, so
wird die Nachricht an die bestimmte Adresse in jedem Subnetz
übertragen. Dadurch kann man nahezu einen Multicast realisieren,
indem man z.B. alle Komponenten zur Variablensynchronisation
auf eine bestimmte Adresse legt.
Auch der Wert 0xff für die 'eigene Adresse' bedarf noch einer
Erläuterung. Setzt ein uC diesen Wert für sein Subnetz ein, so
kann er kommunizieren, ohne sein eigenes Subnetz kennen zu
müssen.
Auf der Adressierung baut nun der Router auf. Er muss entscheiden,
wohin eine eingehende Nachricht weitergeleitet wird. Der Router kennt
seine(n) lokale(n) Knoten und eine Menge an Übertragungs-HW (Segmente)
Im folgenden stelle ich zwei Möglichkeiten vor, wie es das tun könnte:
Statisches Routing (problemlos auf uCs verwendbar)
Besonders leicht, wenn nur ein Segment existiert (z.B. seriell)
Die Routen sind in diesem Fall statisch eingetragen. Der uC
weis also das er selbst (unveränderlich) der Knoten X ist
und das es einen 'Uplink' gibt, der für alles andere
zuständig ist. Das Routing beschränkt sich also darauf,
Nachrichten auf die eigene Adresse zu überprüfen und entweder
nach oben oder an das 'Default' Segment weiterzugeben.
Als Erweiterung kann er ein zweites Lokales Interface mit der
Adresse Y kennen, das z.B. am i2c Bus hängt. Auch dieses wird
statisch eingetragen und bedient.
Dynamisches Routing (aufwändiger)
Auf irgendeiner Ebene des Systems, meistens wohl auf den
Knoten mit LAN-interface wird die Sache aufwändiger. Jetzt
gibt es plötzlich sehr viel mehr direkte Kommunikationspartner.
Natürlich könnte man auch die alle statisch konfigurieren, das
ist jedoch nicht besonders Flexibel.
Für die 'Königslösung' müsste der Router nun für jede Adresse
herausfinden und speichern über welches Interface sie erreichbar ist.
Um das effizient zu tun brauchts entweder eine lookup-Table mit
64k Einträgen oder einen guten Hashalgorithmus. Das ganze ist imho
nicht so wahnsinnig praktikabel, auf uCs mit Ethernet vmtl. gar nicht
implementierbar.
Ein Zwischenlösung könnte sein, wenn der Router nicht alle Adressen
speichert, sondern lediglich nach Subnetzen routet. Nur innerhalb des1
'eigenen' Subnetzes wird nach Adressen geroutet. Adressen aus anderen
Subnetzen werden nur nach ihrem Subnetz einem Sebment zugeordnet. An
dieses Segment wird die Nachricht dann übertragen. Im Normalfall wird
die Gegenstelle dann die Nachricht entweder selbst korrekt zustellen
(wenn sie zur ihrem Subnetz gehört und existiert), weiterleiten (auf
anderes Segment) oder fallenlassen (richtiges Subnetz, nicht existierende
lokale Adresse).
Klingt kompliziert - ist es aber nicht. Vor allem hoffe ich genau
diesen Teil komplett in libraries verstecken zu können.
Schicht 3 - Verbindung/Sicherung
Im ersten Schritt will ich nur verbindungslose, unsichere Nachrichten.
Diese Schicht ist also quasi leer und hat (noch) nicht viel zu tun.
Schicht 4 - Dienste
Auf dieser Schicht kommt nur ein Datenpaket mit festgelegter Länge an.
Wie genau dieses verarbeitet wird, bleibt noch festzustellen. Da ihr
alle schon ganz fleissig über diese Schicht diskutiert und diese Schicht
wenig mit der eigentlichen Übertragung zu tun hat, werde ich ihr demnächst
einen eigenen Post widmen.
Anmerkung: Natürlich sind meine heutigen Vorschläge noch lange kein
hartes Interface. Ich hoffe ihr könnte euch trotzdem schon vorstellen,
worauf ich hinaus will. Ich werde in den nächsten Tagen mal eine
konkrete Definition schreiben, dann sollte es ganz klar werden.
ciao,
Georg
Ja nun Supi,
einige arbeiten sich von vorner nach hinten und ander andersrum...
.. nur was vorn und was hinten ist kann ich nicht mit bestimmtheit sagen.
Wenn wir uns in der Mitte treffen gibts ne Party ;-)
Ich habe mal versucht was aufzumalen.
Textlich hinterlegen kann ich es aus Zeitmangel momentan nicht.
Aber viele hier wissen vermutlich was ein Applikationsserver ist und wie er funktioniert oder gar implementiert wird ... so kann ich mir das vielleicht auch sparen.
Es ist schlussendlich ein Bild geworden... wenn jemand auch drin rummalen möchte ... es entstammt aus dem MS-Visio ... ich versuche mal die Quelle hinzuzuposten (*geht nicht).
Ja dann kleiner Dienstweg per Mail?
Bis bald,
Chris
So, jetzt mal einige Kommentare zur aktuellen Diskussion der
Diensteschicht (bzw. alle Schichten drüber)
Ich habe bislang geplant für den Datentausch wie gewöhnlich SOAP zu
verwenden und weitere Systemteile sofern notwendig mit CORBA zu
verschabbeln. Ist S²MIRS als etwas ähnliches angedacht oder ist das
Layer zu tief?
Wenn ich smirs richtig verstanden habe, dann könntest du SOAP
als 'Transfer' schicken. Problem: die Variablen in smirs sind
auf derselben Schicht wie 'Transfer'. Die kannst du also mit
XML nicht so erfassen. IMHO werden in smirs weder Bedeutung
noch Typ der Variablen festgelegt. Die Definition komplexer
Strukturen unter einem Namen ist jedoch möglich.
PS: An die Doktorarbeitschreibsler ...etwas pragmatischer wäre net
schlecht, denn ich bin Informatiker und kein Theologe. Und der glaube
an ein System das multi private, public semiperstent, private persistent,
private kill... rollback public .. watch hangoff .. deadloop ... watch
external, handeln kann ist bei mir und zudem Naturwissenschaftlich schon
widerlegt.
Allein mit diesem Satz kann ich jedes Boolshit Bingo mit
Pseudo-Informatik-Buzzwords gewinnen. Wenn du genau aufgepasst hättest,
dann wüsstest du, daß ich nur über die Sicherung der unteren Ebene
geschrieben habe. Mag sein, das dich das als Anwendungsentwickler nicht
interessiert. Mich als Hardwarenahen Entwickler interessiert es durchaus.
Genaugenommen steht es durchaus auf meiner Wunschliste (allerdings recht
weit hinten) und deshalb werde ich auch drüber nachdenken. Nur weils
dich nicht interessiert oder nicht betrifft, brauchst du nicht gleich
diskreditierende Kommentare dazu schreiben.
Ragnar hat weiter vorne ein Schichtenmodell vorgeschlagen.
Schicht 1 Übertragung
Schicht 2 Routing
Schicht 3 Verbindung
Schicht 4 Dienste
Ragnar z.B.möchte bis Schicht 3 bei der Entwicklung helfen.
Nach diesem Modell sind
Deine geplante GUI Schicht 4 .
Deine angeregte Festlegung von Werten Schicht 4.
Zur Zeit liegt der Fokus auf den Schichten 1,2 und 3 um der Schicht 4
die Plattform-Unabhängigkeit zu schenken. Bevor das nicht steht kann
man der Schicht 4 nicht sagen was sie vom Datenverkehr erwarten darf
und was sie erfüllen muss.
Ja Marvin, genau so habe ichs gemeint. SOAP auf Schicht 4 wäre durchaus
möglich. Aber in einem Punkt muss ich dich korrigieren. Man kann jetzt
durchaus schon über Dienste reden. Es ist sogar sinnvoll, das jetzt schon
zu tun, da die Dienste u.U. gewisse Ansprüche an die Schicht 3 haben.
Je früher man das erkennt und integriert, desto besser.
BTW: Über Schicht 4 habe ich auch so meine Vorstellungen, weis aber noch
nicht, ob die mit den euren Zusammenpassen.
Ok, das mit den Layern klingt irgendwie wie Standard TCP/IP ...
Gar nicht so übel wenn man das wirklich in einen Contoller packen könnte.
Ja, da ist viel bei IP abgeschaut und zwar nicht zufällig. Wenn IP auf
einem uC laufen würde, dann würde ich die eigentliche Software auch direkt
auf IP aufsetzen. Leider ist der Overhead dabei recht groß, weshalb ich
das ganze einfach runterbrechen will.
@UlrichC
Darf ich dich mal etwas zu deinen Posts fragen. Wenn ich das richtig
verstanden habe willst du eine allgemeine Roboter GUI programmieren.
Wie genau stellst du dir das vor ? Was soll die GUI alles können ?
Wie soll sie beliebige Roboterdaten allgemein darstellen können ?
Beispiel: Ich habe in den letzten Posts häufig von Variablen, Typisierung
und Einheiten(naja, auch nur Typisierung) gelesen. Wie soll das z.B.
ganz konkret aussehen ?
Macht doch mal bitte noch mehr Beispiele, mich würde interessieren
wie ihr euch eine GUI konkret vorstellt ...
Wenn ich das weiter richtig verstehe, soll es einen 'Application Server'
geben, der an das Robotersystem angebunden ist. Jetzt wirds etwas unklar.
Wenn du im folgenden von Drivern und Modulen und Softwarearchitektur redest,
dann nehme ich an, all dies bezieht sich auf den Application Server. Auch
nehme ich an, das du bei Schnittstellen immer die Schnittstellen des
Application Servers auf Schicht 4 meinst. Mit den uCs soll per SOAP
kommuniziert werden. Nicht klar ist mir, was für Standards da erzwungen
werden sollen.
Mal ein konkretes Beispiel ob ich deinen Applikationserver richtig
verstanden habe. Der Applikationserver lädt zur Laufzeit (vmtl. zum
Start) ihn vorher unbekannte Module. Diese Module können z.B.
Hardwaretreiber sein, interne Hilfsmodule für Datenaggregation
und -aufbereitung sowie Module die die Daten schliesslich graphisch
auf den Bildschirm bringen.
Dir geht es also nur um die interne Softwarearchitektur der GUI, richtig ?
Im Prinzip finde ich die Architektur der GUI so gut, allerdings auch
ganz schön allgemein. Andererseits sollte der Overhead durch XML, SOAP oder
CORBA auf dem Rechner mit der GUI kein Problem sein ...
Also im Grunde ein vorgefertigtes System .. das arbeit abnimmt und freiräume lässt.
In einer Hochsprache... mit Treibern zu den Controllern ... netten GUIs
Eine Art DEV Studio/Plattform/BDE für Roboter.
Dem würde ich jetzt voll zustimmen, allerdings ist das auch voll
unkonkret und schon fast Marketing-Gefasel ;-)
Noch zwei Dinge bevor für heute Schluss ist:
1.) Bisher haben wir noch (fast) gar nicht über die Schicht 4 auf den
uCs gesprochen. IMHO ist diese aber noch viel wichtiger als die
interne Struktur der GUI. Welche (allgemeinen) Dienste könnten
hier angeboten werden ?
2.) Vergesst bitte nicht, das ein Roboter aus wesentlich mehr als ein
paar Variablen besteht. Das ganze ist in erster Linie ein Nachrichtensystem,
kein synchronisierter Variablenpool. Ich beabsichtige das ganze auch
innerhalb der logischen Module meines Roboters zu verwenden. Ich will
Ereignisse abstrahieren und darauf reagieren. Variablenanzeige ist für
mich nur ein klitzekleiner Teilbereich.
ciao,
Georg
NumberFive
07.02.2006, 05:41
So langsam wird es mir zu Theoretisch das ist, da bin ich ehrlich, zu Abgehoben. Ok wir müssen zu erst mal die Schicht 1 definieren das ist ok.
Ich habe im Moment eigendlich keine zeit Trotzdem kann ich den Thread nicht ruhen lassen.
Ich bin gegen UDP das ist zu unsicher und erzeugt last im netz die nicht zu händeln ist. Jeder der mal ein größeres Netz betreut hat kann mich da glaube ich verstehen.
Nur So auf die Schnelle:
Warum nicht Multicast ist routing fähig und versaut nicht ganz so das Netz.
Ok die Adresse muß dann halt in Jedem Modul einstellbar sein das währe ja nicht gar so schlimm.
Die Zwei Connect möglichkeit Sollte in meinen Augen die MC bleiben um weiterhin eine Möglichkeit für die Zentralle daten haltung zu habe.
das was gesenden wird sieht so aus:
<Byte> 99 -> Kenner ist ein RN robo Telegram
<Byte> lobyte telegram länge
<byte> hibyte telegram länge
<ADRESSE AD='COM1:2'>
--to define---
</ADRESSE>
COM1 Ist das Modul ein I²C Converter 2 Die Adresse auf dem I²C Bus
<ADRESSE AD='COM1'>
So sehe das dann für RS232 oder ein anders Modul aus.
Was spricht gegen namen als addresse ?
Warum die Adresse berechnen ?
Mist ich muß weg
Warum die Adresse berechnen ?
berechnen kann man nicht sagen, das ist mapping
Auch im flottesten IP Netz wird aus
www.wtlbrnft-und-co-ag.de.vu.xyz.simsalabim
durch den DNS irgendsowas wie
77.34.11.212
und das binär in 4 bytes
@ragnar
Ich wollte nicht diskreditieren, schade das es so angekommen ist.
Im Gegenteil find ich gut das aus dem Layer-Gelayer dann doch eine Grundlegend verständliche Struktur (bzw. Erklärung) geworden ist.
(Das war ja nicht vorhersehbar)
Zudem war mir als Quer-Leser bzw. Quereinsteiger in diesem Thread nicht unbedingt gleich klar an welcher Ecke gerade definiert wird.
Layer 1 bis X gibt es nun mal an mehreren Stellen eines "verteilten" Systems.
Ansonsten wie Du schon gesagt hast und ich in späteren Beiträgen erwähnt habe... ich halt mich aus der Hardwareanbindung raus.
Für diese Aufgabe habe ich nicht den nötigen Background um gleich ein Standard daraus zu generieren.
Im Grunde hab ich ja auch nur Wünsche fürs Frontend bzw. die Schnittstellen
... passt schon.
Was soll die GUI alles können ?
Die GUI die ich mir vorstelle ist sehr schmal gehalten.
Und soll in erster Linie eine Software sein um einen Roboter durch das WWW zu steuern und die gängigsten Messdaten zu visualisieren.
Welche Messdaten? da bin ich mir noch nicht einig.
Die Steuerung soll mit Richtungspfeilen realisiert werden.
Das einzige was wirklich sicher ist, ist das eins bis vier Kameras visualisiert werden sollen.
Wie die genau aussehen soll wird die Praxis+Anforderungen entscheiden.
Die WWW-GUI soll aber "kein" Bestandteil der hier behandelten Standardisierung sein!
Es wäre zu weitgreifend hier über weitergehenden Technischen Schnickschnack zu plaudern.
Ich möchte nur irgendwo aufsetzen können (eine Schnittstelle) ... der Rest hat dann wieder mehr mit CGI + Content-Menagement-Systemen zu tun.
Es ist lediglich eins von X Anwendungsbeispielen.
Die internas/features der WEB-GUI könnte ich nun zwar noch aufdröseln, aber das würde nix zur Sache beitragen.
Es ist ja gerade kompliziert bis verwirrend genug wenn an zwei Enden diskutiert wird.
Ich beantworte aber im Rahmen meiner Entwicklung gerne Fragen im Detail ... Mail ... die keine Elementarerklärung zur folge haben.
Der erzwungene Standard durch den AppServer währe folgender.
Dei Module müssen vom AppServer geladen werden können um im System mit anderen Teilen zu Funktionieren.
...wird erzwungen durch eine DLL Schnittstelle die verwendet bzw. implementiert werden muss.
Weitergehend sollten die Businessobjekte (Module/treibe etc.) alle von einem Masterobjekt abgeleitet werden und dessen Funktionen verwenden.
(im Falle von C eine statische Lib)
...diese abgeleiteten/bzw. verwendbaren Funktionen beschreiben die interne Schnittstelle (programmiertechnisch).
Die Kommunikation erledigt der AppServer ... wenn alles so läuft wie ich es mir erdacht habe... wird der Programmierer des Treibers kein SMIRS oder XML zu Gesicht bekommen... sondern nur die vorhandenen Funktionen bedienen.
Der Appserver ist im weiten Sinne als LoginServer des SMIRS oder als Proxi/Router der Module zu verstehen.
Ich möchte das Ding auch nur bauen um eine Programmierschnittstelle und kein Protokoll zu haben.
...
Dieser (Teil) Standard ist dann nur die Programmierschnittstelle zum ganzen.
Wieder Beispiel Web-GUI (wie geh ich vor):
1.Ich installiere das System (Appserver + Module)
2.Lese die Schnittstellenbeschreibung
3.(Programmierbeginn) Ich leite das Masterobjekt ab und habe die Funktionen die ich für das anhacken der anderen Systemteile brauche.
4.Ich überlege mir von welchem Modul ich welche Daten brauche. ... ich brauch nur das Bild
5.Programmabel sage ich (durch die Funktionen) Modul "CAM" gib mir "BILD1"
6.Da ich auf dem System aufsetze und nicht auf der Hardware selbst bekomme ich ein Bildobjekt (das Format ist von Modul "CAM" bestimmt)
7.Das bild ist nun in meinem Modul und ich habe die Freiheit damit zu tun was ich möchte...
8.Ich schicke es über CGI an meinen Webserver wo schon ein Script darauf wartet.
9.Nun will ich Den Roboter Steuern (also ein anderes Modul mit Daten versorgen)
10.Ich Frage den Webserver ob einer die Steuerung bedient hat. (Fernab vom System den ich bin ja nur Nutzer wie alle Module anderen auch)
11.Der Webserver erzählt mir JA und zwar 10 cm vorfahren.
12.Programmabel sage ich nun wieder (durch die Funktionen) Modul "DUALMOTORSTEUERUNG" "POWER_ENGINE_A" "10"
13.Programmabel sage ich nun wieder (durch die Funktionen) Modul "DUALMOTORSTEUERUNG" "POWER_ENGINE_B" "10"
14.Programmabel sage ich nun wieder (durch die Funktionen) Modul "DUALMOTORSTEUERUNG" "WEGSTRECKE" "1000"
15.Programmabel sage ich nun wieder (durch die Funktionen) Modul "DUALMOTORSTEUERUNG" "RUN" "TRUE"
16.Programmabel erzählt mir (durch die Funktionen) Modul "MOTORSTEUERUNG" "SENSOR_ERROR" "SENSOR1"
...oder
12.Programmabel sage ich nun wieder (durch die Funktionen) Modul "EASY_NAVYGATOR" "FORWARD" "10000"
...oder
12.Programmabel sage ich nun wieder (durch die Funktionen) Modul "2D_NAVIGAROR" "ABS_POS_X" "121"
13.Programmabel sage ich nun wieder (durch die Funktionen) Modul "2D_NAVIGAROR" "ABS_POS_Y" "12"
14.Programmabel sage ich nun wieder (durch die Funktionen) Modul "2D_NAVIGAROR" "RUN" "TRUE"
...oder
12.Programmabel sage ich nun wieder (durch die Funktionen) Modul "WEBROBOTER" "FORWARD_10"
xx.Programmabel erzählt mir (durch die Funktionen) Modul "xxxxxxxxx" "SENSOR_ERROR" "SENSOR1"
xx. Ich schicke meinem Webserver das es ein netter Versuch war aber er sollte die nächste Version des Programms abwarten.
... so im groben.
Welche Befehle für die unkomplizierte Kommunikation unter den Modulen sinnvoll sind und welche nicht wird die Praxis zeigen.
(oben schon erzählt)
Die Datentypen bzw. Definitionen / Parameter / werden vom Modul selbst festgelegt...
...vielleicht in einem XML-Mapping direkt neben der vorgeschriebenen Config jedes Moduls.
...
Das ist ja nur der Begin und die Überlegung der Geschichte meinerseits.
Ob der AppServer dann auch SMIRS-Geschichten über einen SCHNITTSTELLEBMODUL_SMIRS macht oder gleich dies in erweiterter Form verwendet...
...
Das nach Marketing-Gefasel ist nur gewählt um Breitbandig ... Intensionen zu vermitteln ;-)
...
Ich hoffe das ich manches Beantwortet habe.
Ich bin leider erst nächste Woche wieder da...
Netter Gruß,
Chris
EDIT:
Gerade erst das Thema des Threads nochmal gelesen.
Diese Schnittstelle zum WWW hat dann nochmal 10 Seiten zur Folge...
...glatt überlesen.
Wenn ich das Ding (WWW-GUI) schreibe im RFC Standard und in Verbindung mit dem hier Beschrieben Standards für alle Layer aufsetze sollte es genügen. Denn darüber zu plaudern dauert fast länger als einen Prototype zu entwerfen ;-)
marvin42x
07.02.2006, 18:22
@UlrichC
Ja, steht da, www :-)
Schön das du auch die Visionen nicht zu kurz kommen lässt.
Es wird ein 3D Visualisierungsmodul geben welches sich der heute gebräuchlichen 3D Grafikkarten bedient.
Die ermittelten Karten werden samt Robi aus allen Blickwinkeln visualisiert werden können.
Es wird Module geben die Roboter verkörpern die noch nicht gebaut wurden aber schon in dieser Umgebung fahren und getestet werden können.
Die Daten im Netz müssen keine echten sein sowohl die Umgebung wie die Roboter können virtuell sein.
Wenn einer mit seinem noch nicht gebauten Roboter in einer virtuellen Umgebung agieren kann wird er vielleicht auch mehrere Roboter fahren lassen, kost ja nix.
Andere könnten die Idee haben da auch mit mitfahren zu wollen.
Kein Problem mal bisschen Schwarmverhalten zu forschen………
ja ich hör schon auf.
Aber ich denke die Bedeutung des Projektes ist viel größer als manche ahnen.
Netter Gruß
@UlrichC:
Ok, das mit der GUI klingt ja super so. Klingt zwar auch
nach viel Arbeit aber wenn du dich anbietest da ein
Grundgerüst zu schreiben ;-)
Eins möchte ich aber noch klarstellen:
Das System wie ich es hier geplant habe (nennen wir es mal
uCom) und smirs sind zwei verschiedene Paar Stiefel. Beide
haben zwar ähnliche Ziele (Kommunikation zwischen Roboter-
modulen) aber unterschiedliche Voraussetzungen, vor allem
in der Hardware. Smirs erfordert relativ große Rechner mit
IP-Anbindung. uCom hingegen soll bis hinunter zum kleinsten
uC skalieren. Der Nachteil von uCom ist natürlich, das das
System Beschränkungen hat, dafür kann man eben auch Roboter
die nur auf uCs aufbauen noch anschliessen (und das sollten
die meisten hier im RN sein).
Noch was: Beide Systeme sind dafür ausgelegt, mehrere Roboter-
komponenten und u.U. auch mehrere Roboter zu verbinden. Der
Plan ist, die GUI dann als einen Teil in diese Infrastruktur
einzuklinken. Es ist also nicht der Plan, hinter dem Application
Server bzw. der GUI noch weitere Applikationen/Roboter
anzuschliessen. Wenn man es gratis dazubekommt soll es mir
natürlich recht sein, aber es sicher kein Designziel.
Und jetzt noch ein Wort zu SOAP. Prinzipiell finde ich die
Idee mit SOAP/XML schon ziemlich reizvoll, insbesondere weil
man typisierte und selbstbeschreibende Daten/Funktionen verwenden
kann. Allerdings ist SOAP auch ein Protokoll, das nicht unbedingt
wenig Overhead erzeugt (in der Übertragung und in der Verarbeitung).
Auf einem PC mag das tragbar sein, auf einem uC mit zweikritischen
Aufgaben aber nicht. Ich hatte bisher immer ein Datenformat mit
einem Byte 'Command' im Auge, der dann implizit die Struktur der
restlichen Daten bestimmt. Wobei es natürlich auch möglich wäre,
das es ein Command 'SOAP' gibt, das nun mal nur die dickeren bzw.
die nicht zeitkritischen uCs implementieren.
ciao,
Georg
NumberFive
08.02.2006, 02:38
Hallo Leute,
es muß Kongretter werden sonst steige ich aus.
Ich habe schon mal wochen lange diskutiert nd dann wochen Programmiert und jetzt habe ich viel gelernt und das wars dann das wäre dann das dritte oder vier mal hier im forum.
Ich versuche das jetzt mal ein bisschen zu trennen UlrichC hätte gerne einen der für Ihn alles macht. Was sicher auch für die meinsten VB programmieren hier unter uns zu trifft. UlrichC zwar aus anderen gründe aber das ist ja mal egal.
Wir sind uns einig das echte textteile für RS232 und für AVR einfach zu heftig sind oder in der PC welt kein problem und schön weil sie lesen kann.
Drum bin ich der Meinung das wir das trennen müssen so weh wie das auch tut.
PicNick hat folgen auf bau beschrieben:
HEADER / SOURCE-ID / DESTINATION-ID / MsgNR / Action /DataLen / Data (optional).......
Den finde ich gar nicht mal schlecht.
Wir müssen nur ein Teil tauschen die MsgNR denn nummer eindeutig durch das sytem zu bekommen wird nix.
Ich würde daraus ein resposnummer machen mit der größe ein WORD das sollte hin passen.
Meine Defintion von der Message:
HEADER = 3 byte => immer RNM => RoboterNetzMessage
SOURCE = 2 Byte => WORD 0000 und FFFF dürfen nicht verwendet werden.
DESTINATION = 2 Byte => WORD 0000 und FFFF dürfen nicht verwendet werden.
resposnummer = 2 Byte => WORD
Action = 2 BYte => WORD => 65535 Aktionen
DataLen = 2 Byte => WORD wieviel Bytes kommen noch bis ende
Data = 0 Byte bis 65535
Aktionen im Bereich von 0 bis 4000 sind fest definiert und drüber darf jeder machen was er will
ich denke 4000 Sollte reiche die zahl ist aber nur aus gedacht.
Wird könnten so eine art DHCP machen:
wenn was online geht dann muß es grundsätzlich mal so eine Nachricht schicken:
RNM HEADER
<00><00> SOURCE
<FF><FF> DESTINATION
<00><00> resposnummer
<00><00> Action
<00><00> DataLen
Das ist jetzt die Broadcast anfrage nach einer eingener ID.
Kommt inerhalb von 5 sec keine Antwort war man wohl der Erste und darf sich was aussuchen.
Bekommt man die Antwort:
RNM<ID des Senden modules><00<00><00><00><00><01><00><01><Neue ID>
Gibt es einen der die Id's vergibt.
Bekommt man:
RNM<ID des Senden modules><00<00><00><00><00><02><00><00>
kann man sich zwar eine aus suchen aber diese ID's sind schon in verwendung.
Das baucht man natürlich nur wenn man unbedingt dynamiche adressen vergabe braucht.
Im internet muß auch einer die Ip's in den DNS reinkopfen.
Wie finden ich meinen Weg:
RNM<ID des Senden modules><FF><FF><00><01><00><03><00><00>
Wird jetz von dem modul gesendet. Trift es jetzt auf ein Teil welche weiß das es Procy spiel muß
wird einfach RNM<ID des Senden modules><FF><FF><00><01><00><03><00><01><ID des Proxy moduls>
daus und wenn ein zweite kommt kommt noch ein word dran.
Was ist ein Proxymodul:
ein AVR der zu Beispiel eine RS232 hat und auf der anderen seite ein IC2 Bus muß jetz sein ID anhängen.
und per RS232 weiter schicken so weiß der PC die ID'S die Hinter dem AVR am RS232 Port hängen.
Wenn jetzt ein PC modul an der AVR Hinter dem Proxy AVR was schicken will macht er einfach:
RNM<ID des Senden modules><id Procy><resposnummer><00><04><länge nachricht><nachricht>
wo bei die nachricht wieder ganz normal auf gebaut ist mit ausnahme des RNM vorne dran.
Bei PC => IC2 verbindung muß halt die ID und die Adresse des I²C Gleich sein.
So jetzt bin ich mal gespannt.
In den 4000 Actions könnte man dann auch nocht die smir's Telegramme verstecken.
gibt halt ein großes Dokument aber mit ein bisschen sorgfallt sollte es klappen.
Auf dem PC könnte man dann in der smirs welt nocht die ID's durch namen ersetzt dann wird es lesbarer.
so jetzt habe ich mir die halbe nach um die Ohren gehauen nur weil ich diesen text nicht lassen
konnte obwohl ich eineglich mal mein Robi zum laufen bringen sollte.
Gruß
So nochmal (ich sollte eigentlich was anders tun),
@marvin42x
Sorry...Die Visonen gehen bei mir immer so schnell aus.
Bei Roboterschwärmen denke ich eigentlich gleich an Online-Games *itsReal*
@ragnar
Ja ich werde mal einen Prototypen der GUI schreiben.
Das umliegende System der Webapplikation aber nicht vom scretch programmieren.
@NumberFive
Ich möchte nicht alles machen lassen, lediglich eine Standard Programmierschnittstelle.
Denn eine Protokollschnittstelle ist sehr erklärungsbedürftig somal der Standard-Roboter in weiter ferne liegt.
Mir ist klar daß ich die auch selber schreiben muß. Und ich habe schon x mal hier geschrieben das diese dann auch auf Smirs aufsetzen kann.
Aber solange keine Einigkeit gefunden ist ... und der SMIRS-Entwickler sich noch über erweiteungen am Protokoll verschweigt... dreh ich Daumen und schreibe WWW-GUI
... ob dann die Oberfläch nur mit eigem Zeug funzt oder auf einer Schnittstelle sitzt ... ist dann ein portierungsaufwand von wenigen Stunden für mich.
Und ich werde einen Teufel tun um hier erstmal fröhlich Prototypen (ferner www-GUI) zu schreiben um hinterher festzustellen das die SMIRS verwendet werden soll.
Denn die Teile die ich dann bereitwillig programmieren würde...
AppServer
Objekt zur Ableitung (schnittstellen)
Treiber für den ersten Roboter (Demo/Vorlage)
... schreiben sich nicht von selbst.
(Steht da alles schwarz auf Blau)
...jetzt muß ich aber wieder anderes tun.
Netter Gruß, SO LONG AND THX FOR ALL THE FISH,
Chris
EDIT:
Boa bin ich durchnächtigt... ich raf den Text nicht mehr.
Das beste ist wenn ich vorerst nur mit dem Modulen WWW-GUI und dem eigenen Robotermodul (auf tcp/ip basis) beginne..in zwei-drei Wochen muß mir dann einer sagen auf welchen Standard ich aufsetzen kann. (um mein gehack zu verschabeln) ... hierzu brauche ich erstmal keinen anderen Code (selbst ist die Frau)
Den Appserver habe ich schon bei einem weiteren bekannten programmierer angefragt... wenn muß dann wird.
@NumberFive
Ich schreib Dir eine Mail wenn ich wieder fit bin ;-)
Hallo nochmal (ich bin eigentlich gar nich da *pssst*),
ich hab nochmal in der Mittagspause den Kopf rauchen lassen.
Also meine Intension ist wirklich so ne Art VB-ActiveX Com+ für Module (Nur ohne Registrie) ... darum diese mini-plattform AppServer für Plattformunabhängige komunikation .. die ähnlich wie AktiveX bedient werden kann. ...über Aufruf der registrierten Funktionen... ohne Protokoll...sondern mit einer Programmierschnittstelle.
Dies muß aber auch nicht unbedingt ein Standard werden. Lediglich ein Feature/Bereicherung des Standarts. Denn ich könnte auch dieses Ding einem evtl. Standard anpassen. Intern könnte ich aufgrund der Trennung von Protokoll und Programmierung verfahren wie ich wollte.
Denkbare Architekturen von AppServer aus.
AppServer<->AppServer
..oder
AppServer<->LoginServer (SMIRS)
..oder
AppServer<->RN-VerbindungsLayerHandler
... dies kann dann später wenn der Standard funzt programmiert werden.
Auf den Teil der Architektur bin ich noch nicht eingegandgen daher ist dies was neues ;-) aber eine weitere Abgrenzung ... so könnte ich ja fröhlich beginnen.
Gruß,
Chris
@NumberFive
Zur Umsetzung von Binärdaten auf Menschenlesbare Daten:
Ja, menschenlesbare Daten wären schön, sind aber auf dem uC nicht
zu machen. Wenn ich dich richtig verstanden habe, willst du die
Binärdaten an irgendeiner Stelle _im_ Kommunikationssystem in
Menschenlesbare Daten umsetzen.
Für einen Teil der Daten (z.B. Adressen) ist das eine gute Idee.
Allerdings würde ich die Adressen erst direkt vor der Darstellung
(z.B. im Debuggingtool) umsetzen.
Bei den verbleibenden Daten ist dies noch schwieriger. Diese hängen
nämlich z.B. vom Kommando ab. Um die Daten umzusetzen muß der
Umsetzer also wissen wie er die Daten zu verstehen hat. Das ist
fehlerträchtig, denn es kann jederzeit neue Kommandos oder geänderte
Datenstrukturen geben. Um die Daten möglichst lokal zu halten, würde
ich auch hier die Daten erst direkt vor der Ausgabe umsetzen. Das
Schlimmste was dann passieren kann ist das die ausgegenen Daten nicht
gültig sind.
Wird könnten so eine art DHCP machen:
[...]
Was du beschreibst hat leider ein Problem:
Der "DHCP" Response kann nicht so ohne weiteres zurückgeschickt
werden denn der Anfragende hat ja noch keine Adresse.
Prinzipiell natürlich trotzdem möglich, es liegt dann aber in
der Routingschicht und ist eine spezielle Nachricht außerhalb
des Msg-Modells von dir (eine Schicht drunter)
Ein weiteres Problem dabei: Wie können die Module dann
untereinander kommunizieren? Woher erfahren sie die
(dynamisch vergebene) Adresse ihres Kommunikationspartners?
"DHCP" erfordert also auch eine Art "DNS" (bzw. eine Registry),
mit der man die Adresse seines Kommunikationspartners anhand
bestimmter Merkmale (Name, angeboteten Dienste, ...) heraus-
finden kann.
Zu deinen Ideen zum Routing:
Das ganz große Problem das ich bei dir sehe ist, daß die
Knoten hinter Proxys ihre eigene Adresse nicht kennen (denn
die wird ja vom Proxy 'mitbestimmt'). Außerdem sind mir die
unterschiedlich langen Adressen noch etwas suspekt und mir ist
nicht klar, wie Nachrichten zwischen verschiedenen Modulen
geroutet werden sollen. Außerdem muß bei deinem Ansatz IMHO
immer eine Oberste Ebene als Bezugspunkt existieren.
ciao,
Georg
Hallo, ihr da vom Thread der Doktoranden und Nachtarbeiter !
Ich leb' schon auch noch.
Immer wenn's kompliziert wird, geh' ich gern den Weg der "Ausserstreitstellung", d.h. ich schau mir einmal genau an, was nicht strittig ist und trotzdem unerlässlich. Das versuch ich mal zu lösen, auch um zu sehen, wo's hapert. Da nehm ich auch ein paar Leerkilometer in Kauf.
Wir haben nämlich dauernd die Stituation, daß vor diesem und jenem eigentlich vorher noch was anderes zu klären wäre, und das setzt sich fort und man kommt zu keinem Ende oder Anfang oder, schlimmer, was weiß nicht mehr was Ende oder Anfang ist.
Egal: da bei mir PCs und Midranges durch die berufliche Tätigkeit immer ein leichtes Grausen auslösen, schau ich mir einmal genauer die Umsetzungsmöglichkeiten auf AVRs an. Ein paar Versuche hab' ich ja schon gemacht, Marvin42 weiß das.
Ich halte es nämlich auch für wichtig, eine ZUMUTBARE Library dafür zu entwerfen. Wenn der µC nämlich nix anderes mehr kann als netzwerken, setzt sich das Ganze niemals durch.
Mal sehen
Hallo,
ich kann die Finger nicht raushalten.
Aber spezifizieren mag ich nun nicht...
Ich wollte nur mal einen Ansatz bzw. ein Punkt wo die Meinungen vielleicht noch Auseinanderlaufen untermalen
Und zwar ...
Ich halte es nämlich auch für wichtig, eine ZUMUTBARE Library dafür zu entwerfen. Wenn der µC nämlich nix anderes mehr kann als netzwerken, setzt sich das Ganze niemals durch.
Ja das sollte auf jeden Fall auch das Ziel sein und zwar an beiden Enden des Systems.
Und hierbei möchte ich noch zus. Intensionen loswerden.
Eine Kapselung des Protokolls in eine verständliche bis einfache Schnittstelle für den Verwender.
Jedenfalls habe ich die Fahne auf der PC-Seite des Systems hierfür auch schon gehalten.
..und das nicht aus Einfachheits- bis Faulheits- gründen...sondern
Eine Programmierschnittstelle (+Spezifikation) verbaut in einer Bibliothek (Lib) ist sozusagen die Lebensversicherung des Systems.
Das Protokoll + API selbst kann sich dann *ändern wenn es notwendig wird.
Der Verwender des Systems sollte einfach durch kompilieren seines Codes mit der "dann neuen Lib" Standardkonform bleiben ohne eigenen Code ändern zu müssen.
Jedenfalls ist man das als Programmierer/Anwender so gewohnt.
Falls sich wirklich Anwender für einen eventuellen *Standard finden sollten dann sollten diese über alle Versionen erhalten bleiben.
Ich würde als Normal-Modul-Programmierer (nicht API Schreiber) wahre Freudensprünge im Dreieck machen,
wenn ich alles wegen eines Denkfehlers oder einer Erweiterung die eine Änderung des Protokolls zu Folge hatten,
die Kommunikation umtexten müsste.
Diese Schnittstellenfunktionen werden so oder so geschrieben ... nur wenn die nicht in der Lib zur API liegen muß diese jeder für sich anpassen.
In einem Fall wären es [Support "+Punkte"] im anderen [Standard "-Punkte"].
*Änderungen ... gibt’s oft:
... neue Features neue Bugs *isKlar* Workarounds
... andre Encodings (Vielleicht wird mein Unicode nun doch anders Interpretiert)
... mehr Funktionalität (Vielleicht wird alles aufgebohrt ... und man muss explizit den verwendeten Standard im Protokoll mitschicken... um gewohnt verfahren zu können)
... anderes Handling des Protokolls (Vielleicht müssen Commands vorgeschoben oder bestätigt werden)
... schnellere Reglungen (vielleicht ändert sich die Kommunikation grundlegend um Connects/Syncs zu sparen)
... obsolet Commands (manche zuerst als sinnvoll erscheinenden Funktionen des Protokolls werden ersetz / oder erweisen sich als unsicher)
... mehr Sicherheit (vielleicht läuft in naher Zukunft alles Verschlüsselt durch die Leitung)
... weitere Interfaces (feileicht müssen die Adressräume geändert werden weil die vorgesehenen 2 Byte doch nicht reichen)
etc.
*Standard wird nur verwendet wenn es Vorteile bringt.. Vorteile sind verschieden geartet
... Kompatible Zusatzsoftware
... Zeit/Kostenersparnis
... KnowHow-Gewinn
... Funktionsgewinn
etc.
Ist schon wieder ein Roman geworden... *sorry*
Netter Gruß,
Chris
marvin42x
09.02.2006, 11:44
Aus meiner Berufspraxis, die nichts mit Programmieren zu tun hat, weis ich, dass ein Pendeln zwischen Überlegungen und Prototypen am fruchtbarsten für Entwicklungen war.
Ich würde daher vorschlagen diese Möglichkeit in Betracht zu ziehen.
Die Liste der Vorteile ist lang. Weder nur Überlegung noch nur Prototyping vermögen das zu leisten.
Wir müssen auch bedenken, dass die serielle Kommunikation eines Textes im Forum Schwierigkeiten hat mit der Darstellung mehrerer mehrdimensionaler Topologieentwürfe wie sie hier erörtert werden. UlrichC hat da mit seiner Grafik schon mal zur geeigneteren Waffe gegriffen. Prototypen erzwingt Festlegung und bildet gleichzeitig die Idee beispielhaft ab ohne Änderungen im Weg zu stehen. Er ist gleichzeitig von allen einsehbarer Stand der Dinge.
Frage:
Wäre es sinnvoll eine minimale Topologie aufzubauen die z.B. zwei Sachen kann. Get var und Put var um am Objekt weiter zu Entwickeln.
Das würde sich dann in etwa so anhören:
Auf der einen Seite haben wir bereits mindestens ein lauffähiges Betriebssystem für einen Mega32 wenn man das modifiziert, das es put und get für eine variable kann. Die lib dazu auch minimal auf diese zwei Funktionen beschränkt.
Wie die Lib das macht wäre erstmal egal
Wie das Prokoll aussieht wäre erstmal egal.
Der Apserver sollte zu Studienzwecken nur…….usw.
Ein Mega32 der, über einen Apserver, auf einer GUI in einem Textfeld seine Batterispannung ausgibt.
Auf dieser Basis ließe sich vortrefflich:
Erweitern
Verwerfen
Neu entwerfen
Erfahrungen einbauen
Probleme erkennen
Aufgabenbereiche abgrenzen
Schnittstellen erschaffen……..na ja usw.
Netter Gruß
... Ich hatte bisher immer ein Datenformat mit einem Byte 'Command' im Auge, der dann implizit die Struktur der restlichen Daten bestimmt. Wobei es natürlich auch möglich wäre, das es ein Command 'SOAP' gibt, das nun mal nur die dickeren bzw. die nicht zeitkritischen uCs implementieren ...
... das lässt mich an P-Code denken.
Ob ich jetzt unter einer virtuellen Maschine einen Prozessor oder einen Roboter verstehe. Ist doch auch nichts anderes.
NumberFive
10.02.2006, 07:57
In der Hoffung das Frank weiterhin mit liest.
Könnten wir im Download bereich eine Ordner haben ?
Ich würde mein SMIRS zeug gerne mal hoch laden aber mein HP
ist ein HP bei T-online privat page und da reicht werde Traffing noch Platz
auf die Dauer.
Zu rück zum Thema ich würde auch gerne ein alpha im plemetierung machen da wird es einfach leichter. Ich muß so was sehen / Programmieren dann wir es für mich einfach leichter und vor allem kann man mal messungen machen wie lange was wirklich dauert.
Desweiteren würde ich den Thread gerne Trennen aber wenn wann dann mehr lesen muß Application layer und Protokoll layer oder wir gewönnen uns an es Obentrüber zu schreiben um was es gerade geht. Bitte diesen Post nicht falsch verstehen es ist nicht mein Thread und es sind nur vorschläge.
Zur alpha im Plementierung:
Von mir kommt immer nur windows software (win2000) und wenn AVR dann c software.
Jeder der was für das Projekt programmier muß sich im klaren sein das sich das protokoll morgen komplett ändert bist die Defintion mal steht.
Zu Protolllayer:
Ich habe noch mal drüber nach gedacht und ein paar änderungs vorschläge.
ID's / Adresse sind vor erst mal per hand zu vergeben. das Dynamisch ver geben von ID's ist ein Option die wir erst später realiesieren. Also im source vorsehen aber zur Zeit würde uns das nur auf halten und wir haben genung andere Probs zu lösen.
Ich würde gerne das Protokoll teilen AVR Welt und PC Welt um es den PC Programierern einfachen zu machen und das Protoll notfalls auch lesen zu können. Zweiter vorteil man würde sich mit den 0 Bytes als C++ Programierer nicht so um bringen (Stringklassen). Aber auch Delphi oder VB hat glaube ich so ihr probs mit 0 Bytes im string. Bei java weiß ich es nicht wirklich.
Wie soll es laufen:
http://mine-robo.homepage.t-online.de/images/RNMThread1.jpg
Angehängtes Bild betrachten und jetzt geht es los.
RNM Low sollte so was Byte Oritiertes sein damit der AVR sich nicht einen Abbricht und das RNM Hight sollte doch ziemlich Text oritiert sein damit man es schnell lernen kann und wir viele schöne Module bekommen.
In meinen Bild sieht mal schon das wir dann beide Welten haben und man beides nutzen kann. die MC könnte erst mal so weiter leben und und die Eine änderung sollte sich realtiv schnell ein bauen lassen.
auf der LOW seite würde ich gerne das
RNM HEADER
<00><00> SOURCE
<FF><FF> DESTINATION
<00><00> resposnummer
<00><00> Action
<00><00> DataLen
Verwenden denn ich denke das geht schon in die richtige richtung.
Ich stelle mir die Frage warum wenn ich Über die RS232 an den AVR gehe den Dahinterliegen AVR von dem Motor Controller zum beispiel wirklich direckt er reichen muß. In meinen Augen eigendlich nicht. Wenn ich mehr als ein gerät direckt erreich will / muß baue ich den I²C bus dann habe ich da keine Probs die meinsten RN Borad können den Ja. Im PC I²C Adapter würde ich dann per Ini oder regestry ein Übersetzung tabelle von Name auf ID's Führen.
Wenn wir den Proxy weg lassen und dafür Feste befehle bauen wird das ganz nicht so komplex und wird erreichen schneller was verwendbares.
Um das was ich mein zu verdeutlichen:
RNM HEADER
<00><34> SOURCE
<00><99> DESTINATION
<00><54> resposnummer
<00><99> Action
<00><03> DataLen
<00><01> DataByte
<00><01> DataByte
<00><50> DataByte
Hier schickt das RS232 Modul (ID 34) and den AVR (ID 99) den Befehl 99 (Stellemotor leistung) des Motor's 1 in Richtung 1 (Vorwärts) auf 50 %.
Ob jetzt der PWM Generator auf dem AVR sitzt oder der AVR einem Andere AVR was mit teilt ist ja eineglich egal und das kann jeder mache wir er will.
Hat er eine RN Motorcontroller würde er das Selbe Telegramm ein fach über den I2C bus jagen und das Tut. Ok dafür muß man den Robi ein bisschen in logische Teile auf teilen aber ein standart ist immer auch ein Kompromiss.
Wie kommt jetzt der Navigator an den AVR, Ich gehe davon aus das der Navigator ein PC Programm ist, ganz einfach über die Multicast Adresse.
er jagt ein Telegramm raus das so aussieht (ist nur ein beispiel bin für vorschläge offen) <byte><byte><RNM><ADRESSE AD='RS232'><RESPOS ID = '54'/><ACTION ID = '99'/><DATALEN Value = '3'/><DATA01 Value='1'><DATA02 Value='1'><DATA03 Value='50'></ADRESSE></RNM>
Die Zwei Byt am anfang um bei Wlan sicher zu stellen das das Telegramm voll ständig war. nach dem an es nun hat und die ersten zwei byte's abschneidet sollte man es ein XML Parser zu fressen geben können wenn ich XML richtig verstanden habe. So hat man beides ein Telegramm was einem beim Coden auf dem AVR nich um bringt wo man auch ein klassen / lib für machen kann und ein PC Telegramm was man relativ gut lesen kann aber von prinzip sind sie gleich. Für die Fraktion die sich nicht mit dem Protokoll layer rum ändern wollen wurde ich ein dll machen die ein Com Objekt ist die der man nur die Multicast adresse gibt und die Einge adresse und dann kommen Event's wenn für einen was neues da ist dort Kann man dann mit Metoden die Aktion und die daten abfragen. So das einem das Protokoll egal sein kann. UlrichC mach bestimmt auch ein .so file für die Linux Jungs unter uns.
Was haltet Ihr von meiner Idee ? Ok ich habe mich sehr weit vor gewagt aber so kann ich mir das einfach besser Vorstellen. Achso auch ein simirs Client kommt natürlich an das Mutlicast es gibt ja den befehl Transfer damit kommt das Modul dann an die Multicast geschichte. Und die MC hat eine Adresse auf der Multicast seite.
Wenn wir uns auf den Nachrichtenauf bau einigen können könnte man anfangen die Action zu definieren. Das währe dann Applications layer 1.
Gruß
PS: ich hoffe es ist einiger massen zu verstehen
Schade ich darf keine Bilder mehr hoch laden sagt das forum zu mir
Deshalb habe ich das mal als link ein gefügtmal sehen wann die Telekom mir aufs dacht steigt.
marvin42x
10.02.2006, 12:10
@NumberFive:
Ich würde einer Aufteilung des Threads wenn es für euch Sinn macht in keiner Weise im Wege stehen. Müsstet Ihr aber machen. Ich kenne mich mit Forumstechnik nicht so gut aus. Oder Ihr sagt mir wie ich es machen soll. Mir ist nur das Projekt als solches wichtig.
Zur Downloadfrage, schick dem Frank doch lieber eine Nachricht. Da ist es dann nicht so dem Zufall überlassen.
In diesem Sinne:
Mut zur Lücke
... soll doch nix wegschmeißen. [-X
Ich habe gerade den USER'S GUIDE für CP/NET aus dem Jahr 1980 (Digital Research) in der Hand.
Ich schreibe mal einige Stellen ab:
.-----.-----.-----.-----.-----.--------- - - -.
| FMT | DID | SID | FNC | SIZ | MSG |
'-----'-----'-----'-----'-----'--------- - - -'
| | | | | |
| | | | | Actual Message, Size + 1 Bytes
| | | | Size, Data field lenght -1
| | | CP/M, MP/M Function code
| | Message souce processor ID
| Message destination processor ID
Message format code
Message Field Length Table
.-----.-----.-----.-----.-----.-----.
FMT | FMT | DID | SID | FNC | SIZ | MSG |
Code '-----'-----'-----'-----'-----'-----'
00 1 1 1 1 1 1-256 Preferred format
01 1 1 1 1 1 1-256 Returned result
02 1 1 1 1 2 1-65536
03 1 1 1 1 2 1-65536 Returned result
04 1 2 2 1 1 1-256
05 1 2 2 1 1 1-256 Returned result
06 1 2 2 1 2 1-65536
07 1 2 2 1 2 1-65536 Returned result
CP/NET Logical Message Specification
ss = Server ID
rr = Requestor ID
xx = Don't care byte
nn = Value specified
FMT DID SID FNC SIZ MSG / Function Name
.----.----.----.----.----.------------------------.
| | | | | | System Reset |
| 00 | ss | rr | 00 | 00 | 00-00 = xx |
| 01 | rr | ss | 00 | 00 | 00-00 = 00 |
|----+----+----+----+----+------------------------|
| | | | | | Console Input |
| 00 | ss | rr | 01 | 00 | 00-00 = xx |
| 01 | rr | ss | 01 | 00 | 00-00 = 00 |
|----+----+----+----+----+------------------------|
| | | | | | Console Output |
| 00 | ss | rr | 02 | 00 | 00-00 = xx |
| 01 | rr | ss | 02 | 00 | 00-00 = 00 |
|----+----+----+----+----+------------------------|
| | | | | | RAW Console Input |
| 00 | ss | rr | 03 | 00 | 00-00 = xx |
| 01 | rr | ss | 03 | 00 | 00-00 = 00 |
|----+----+----+----+----+------------------------|
| | | | | | RAW Console Output |
| 00 | ss | rr | 04 | 00 | 00-00 = xx |
| 01 | rr | ss | 04 | 00 | 00-00 = 00 |
|----+----+----+----+----+------------------------|
| | | | | | |
. . . . . . .
| | | | | | |
|----+----+----+----+----+------------------------|
| | | | | | Return Version Number |
| 00 | ss | rr | 0C | 00 | 00-00 = xx |
| 01 | rr | ss | 0C | 00 | 00-00 = 00 |
|----+----+----+----+----+------------------------|
. . . . . . .
| | | | | | |
'----'----'----'----'----'------------------------'
Recommend Server-Requester Handshake for RS-232C
.-----.-----.-----.-----.-----.-----.-----.-----.-----.-----.- -.-----.-----.-----.
| ENQ | SOH | FMT | DID | SID | FNC | SIZ | HCS | STX | MSG | ::: | ETX | CKS | EOT |
'-----'-----'-----'-----'-----'-----'-----'-----'-----'-----'- -'-----'-----'-----'
Messages format codes 00 & 01 are recommended
ENQ = Enquire, one byte, 05H
SOH = Start of Header, one byte, 01H
FMT,DID,SID,FNC,SIZ = as defined, onebyte per field
HCS = Header Checksum, one byte
STX = Start of Data, one byte, 02H
MSG = SIZ + 1 bytes long
ETX = End of Data, one byte, 03H
CKS = Checksum, one byte
EOT = End of Transmission, one byte, 04H
Source Destination Comment
5 - ENQ ------->
<------- ACK - 6
1 - SOH ------->
FMT ------->
DID ------->
SID ------->
FNC ------->
SIZ ------->
HCS -------> Modulo 256 sum from SOH to HCS = 0
<------- ACK -6
2 - STX ------->
DB0 -------> First data Byte
....
DBn ------->
3 - ETX ------->
CKS -------> Modulo 256 sum from STX to CKS = 0
4 - EOT ------->
<------- ACK -6
marvin42x
10.02.2006, 14:20
Da ist einer fleißig wie ein Eichhörnchen und trägt Nuss für Nuss zusammen. Im Wissensbereich gibt es ein neues Kapitel „Betriebssystem für Bascom“.
Oder hätte ich das jetzt nicht petzen sollen?
@PicNick:
Da hast Du mir ja Stoff gegeben.. Muss ich mir erst mal unters Kopfkissen legen. Das ist halt ein bildschönes System
Danke, dass Du das über so eine gute Dokumentation bereitstellst.
Netter Gruß
@Vogon: Schau mal unter "DDCMP" (is auch in der wikipedia).
Zum Abschauen isses gut , ansonst für µC etwas über-drüber.
@PicNik: Das ist aus dem Jahr 1984. Da ist noch weiter Ausgebaut.
Ja, so habe ich das auch gedacht. Zum Abschauen isses gut.
Das es etwas über-drüber ist - klar für ein MultiuserMultitask (mit 8080, Z80) war das sicher notwendig. Aber man kann sich ja an einem System das recht ordendlich funktioniert hat orientieren.
Und wenn man mal von einem AVR zu einem DSP mit FunkLan wechselt soll es ja auch noch gehen.
Wir haben damals mit DDCMP die PCs an VMS Maschinen gehängt und sind DecNet drüber gefahren, wenn Dir das was sagt.
Es ist ein gutes Beispiel, schlimmer kann's nämlich nicht werden.
Ähnlich isses mit SLIP (serial line IP)
In der Hoffung das Frank weiterhin mit liest.
Könnten wir im Download bereich eine Ordner haben ?
Ich würde mein SMIRS zeug gerne mal hoch laden aber mein HP
ist ein HP bei T-online privat page und da reicht werde Traffing noch Platz
auf die Dauer.
Hi,
ich schau nur sproatisch mal in diesen Thread, ich hab bislang aus Zeitmangel nicht alles genau verfolgt. Momentan steht bei mir in der Art auch nix an, so das ich mich da nicht beteilige, aber bin gespannt was ihr da auf die Beine stellt.
Wie umfangreich sind denn die SMIR Sachen. Wenn man alles zusammen in ein ZIP-File stecken könnte und das unter 3 MB groß ist, dann könnte man es z.B. unter einer neuen Rubrik "Open Source Projekte" ablegen. Eine ganz eigene Rubrik für Smir wäre glaube etwas zuviel. Da das aktuallisieren nicht so einfach im Downloadbereich ist, wäre es natürlich Vorteilhaft wenn man nur gewisse Endversionen oder stabilere Beta-Versionen dort ablegt. Oder man verlinkt dort eine Datei von Euren Server.
Gruß Frank
NumberFive
10.02.2006, 23:06
Als zip und kompiliert sind es zur Zeit 890 KB.
Ok ich stelle es mal bei Opensource rein. Damit wer will spielen bzw. Probieren kann.
EDIT:
Da es die Rubirk noc nicht gibt vorrest unter Andere dateien
Gruß
PS: Ich hoffe Frank verschiebt es dann die Rubrik könnte ja auch RN Projekte heissen.
Ich habe die Rubriken etwas umgestaltet. Es liegt nun unter weitere RN-Projekte:
https://www.roboternetz.de/phpBB2/dload.php?action=category&cat_id=15
marvin42x
11.02.2006, 11:53
@NumberFive:
Anmerkung zu Deiner Datei im Downloadbereich.
Wäre es möglich noch ein Minisystem für z.B. einen Mega32 dazuzulegen welches zwei Sensorwerte über die serielle nach deinem Protokoll kommuniziert? Oder ein gleichwertiges Pseudomodul?
Dann würde das System als Gesamtheit agieren.
Da Deine anderen Komponenten schon laufen wäre es dann eine komplette Funktionseinheit die gut vorführ- und verstehbar wäre (falls ich nichts übersehen habe)
Das wäre für alle die, die sich aus den vorgetragenen theoretischen Überlegungen noch kein Bild machen können.
Das wäre nicht unbedingt als ein Beitrag zur Entwicklung gemeint aber ein Beitrag zur Demonstration, Werbung und Motivation. Ein wesendlicher Teilaspekt mit dem wir verhindern können, dass das hier nur eine Diskussion bleibt.
Netter Gruß
NumberFive
12.02.2006, 10:15
Hallo die main.c ist doch dabei.
das ist das komplette Prg für die RN-Controll jede Taste sendet einen Anders Wert für eine Variable der MC. Ich glaube kompletter geht es nicht so hast du den kompletten weg vom AVR bis ins Modul. Ist aber für ein Mega16 mit 16 Mhz aber sollte schin jeder umschreiben könne oder ?
Vielleicht mach ja jemand noch eine Bascom version davon.
@Vogon meinst du nicht das der telegramm aufbau ein bisschen sehr heavi ist. Ich kenne solche Telgramme zu gut frage mich nur ob so viel sein muß.
@Alle
Wie machen wir jetzt weiter ?
Ohne Telegramm structure kann ich nicht los legen.
Gestern war Robotchallenge ( http://www.gs-roboter.de/ , http://www.robotest.de/ )
und im Herbst ist Roboliga ( http://www.robotliga.de/ ) und ich würde im Herbst gerne dabei sein und das mit Standart system den zwei systeme
zuwarten das schaffe ich nicht. Ab morgen beginne ich mit dem PC -> I²C adapter den ich habe jetzt die Hardware wobei wir wahrschelich noch eine erweiterung bauen damit mit das mit dem Int auch vom PC aus tut.
Gruß
marvin42x
12.02.2006, 10:32
@NumberFive:
Sorry hatte ich als Bascom Einsteiger nicht als das identifiziert. Muss mich in C auch noch etwas bilden.
Netter Gruß
... meinst du nicht das der telegramm aufbau ein bisschen sehr heavi ist. Ich kenne solche Telgramme zu gut frage mich nur ob so viel sein muß.
Ja, denke auch, das man auf die Sicherung durch "Recommend Server-Requester Handshake for RS-232C" verzichten kann. (3ter Teil)
Das Beispiel im 2ten Teil ist ja fast identisch mit deinem Vorschlag.
-- CP/Net Header
FMT DID SID FNC SIZ MSG / Function Name
-- RNM HEADER
<00><34> SOURCE
<00><99> DESTINATION
<00><54> resposnummer
<00><99> Action
<00><03> DataLen
<00><01> DataByte
<00><01> DataByte
<00><50> DataByte
--
An dem Beispiel vom CP/NET finde ich den "Message format code FMT" gut. So ist hat man die Möglichkeit noch weitere Protokolle zu definieren. (1ter Teil)
Auch "Size, Data field lenght -1" ist ich gut, damit kann man noch eine Message von 256 Zeichen in einem Byte beschreiben.
Schade das der Vor- und Quer-Denker, der sich schon vor 30 Jahren das erdacht und gemacht hat, uns viel zu früh alleine gelassen hat.
http://www.biocrawler.com/encyclopedia/Gary_Kildall
@Vogon:
Schönes Beispiel, aber relativ kompliziert. Das ganze ist
zwar recht universell, damit aber auch relativ aufwändig zu
implementieren. Insbesondere das variable Format von Adressen
und Datenlänge ist dabei denke ich ein Hindernis. Ob man das
RS232-Handshake implementiert, würde ich jetzt erstmal als
Teilproblem in die Übertragungsschicht schieben und da als
Option belassen. Sprich: erstmal nein, irgendwann kann mans
mal einbauen.
Ich möchte jetzt mal auch einen Vorschlag zum Format machen
und zwar jeweils zwischen den verschiedenen Schichten.
Anmerkung: Ich gehe davon aus, das die Länge eines Datenpaketes
implizit durch die Übertragungsschicht erkannt wird. Nachdem
jedes gesparte Byte bei der Übertragung ein gutes Byte ist,
ist die Länge deshalb auch nicht explizit Teil des Pakets.
In einer realen Implementierung wird die Länge vmtl immer in
der Datenstruktur stehen (als Zusatzinformation), nur taucht
sie in der Definition nicht auf und wird ergo auch nicht
explizit übertragen.
Anmerkung 2: Ich habe auch keinen speziellen Header vorgesehen.
Dieser ist in meinen Augen nur Overhead, da über das gewählte
Medium ja nur korrekte Nachrichten empfangen werden. Immerhin
ist das ganze fest verkabelt und man kennt die Gegenstelle. Wenn
ein device (aus welchen Gründen auch immer) wirklich einen Header
braucht, kann es diesen Header immer noch als Teil seines
Übertragungsprotokolls definieren.
Schicht 1 - Seriell
Auch Schicht 1 werden immer Datenpakete einer bestimmten
Länge ohne jede Bedeutung empfangen. Im folgenden mal
ein Beispiel, wie das seriell machbar ist.
Steuerzeichen
Zusätzlich zu den normalen Daten müssen Kontrollzeichen
übertragen werden. Da alle verfügbaren Zeichen (0..255)
schon belegt sind, werden einige davon als Kontrollzeichen
'abgezweigt'. Das ganze funktioniert ähnlich dem von PicNick
genannten 'Byte Stuffing':
Sei das '\0xff' das Kontrollzeichen, d.h. allen eingelesenen
Bytes mit dem Wert 0xff bzw. 255 folgt kein normales Datenbyte,
sondern ein Kontrollbyte. Im Gegensatz zum Byte Stuffing ist
dieses Zeichen aber eindeutig, d.h. das 'verschattete' Daten-
byte wird nicht durch sich selbst, sondern durch ein anderes
Zeichen übertragen.
Um also im obigen Beispiel ein Datenbyte 0xff zu übertragen,
wird das Kontrollbyte 0xff gefolgt von (z.B.) 0xfe übertragen.
Der Empfänger weis, das die Steuersequenz "0xff, 0xfe" dem
Datenzeichen 0xff entspricht und korrigiert den eingehenden
Datenstrom entsprechend.
Framing
Wie erkennt jetzt der Empfänger, wann eine Nachricht zu Ende
ist, bzw wie lange ein Datenpaket ist? Die Lösung ist Framing.
Dabei wird jede Nachricht von einer Anfangs- und einer End-
Kontrollsequenz begrenzt. Alle Datenbytes dazwischen gehören
zur Nachricht. wie lange die Nachricht genau ist, weis der
Empfänger erst, wenn er die Endsequenz empfangen hat.
Beispiel
Sei "0xff, 0xfe" ein Datenbyte mit dem Wert 0xff.
Sei "0xff, 0x00" die Startsequenz.
Sei "0xff, 0x01" die Endsequenz.
Der Sender will folgendes Paket übertragen:
<0, 0xff, 1>
Nach dem Framing und dem 'escaping' der Datenbyte mit 0xff
entsteht folgender Datenstrom:
<0xff, 0, 0, 0xff, 0xfe, 1, 0xff, 1>
Der Empfänger empfängt ein Startsequenz, erstellt einen leeren
Empfangspuffer und empfängt eine '0' die gespeichert wird. Dann
empfängt er eine Kontrollsequenz "0xff, 0xfe" und fügt dem
Empfangspuffer eine 0xff hinzu. Die folgende wird ganz normal
gespeichert. Dann empfängt er eine Endsequenz und gibt einen
Puffer mit der Länge 3 weiter.
Warum nicht Bytestuffing
Im Gegensatz zum Bytestuffing ist in diesem Verfahren das
Kontrollzeichen eindeutig. Das bietet einen Vorteil bei der
Wiederaufnahme unterbrochener Verbindungen. Wenn ich mein
Kabel aus- und wieder einstecke, dann bin ich beim Bytestuffing
nie sicher, ob ein empfangenes Kontrollzeichen wirklich ein
Kontrollzeichen oder ein Datenzeichen mit demselben Wert ist.
Warum Framing
Derselbe Grund wie oben: Wird ein Kabel im laufenden Betrieb
eingesteckt, dann können sich die Module anhand der eindeutigen
Start-Kontrollsequenz problemlos wieder synchronisieren.
Schicht 2+3 - Router+Verbindung
Empfangen/gesendet wird ein Datenpaket der Länge 'n', gebunden
an ein festgelegtes 'Segment' bzw. Übertragungs-device.
Byte 0: Message Type
Bestimmt die restliche Struktur der Nachricht
0x00 = User level msg, verbindungslos
0x01 = User level msg, verbindungsorientiert, request
0x02 = User level msg, verbindungsorientiert, response
0x03 = RouterMsg (z.B. dynamic Routing Information)
0x04 = RouterMsg (z.B. Adressvergabe)
... to be continued
Für Userlevel messages (Typ=00, 01, 02) gehts wie folgt weiter:
Byte 1: Receiver, subnet address
Byte 2: Receiver, node address
Byte 3: Sender, subnet address
Byte 4: Sender, node address
Byte 5: Session number, low byte (nur für verbindungsorientierte messages)
Byte 6: Session number, high byte (nur für verbindungsorientierte messages)
Byte 5/7..n: Daten
Schicht 4 - Diensteschicht
Empfangen wird ein Datenpaket mit Länge, Addresse und evtl. Session number.
Responsenachrichten (Typ 0x02) werden direkt der entsprechenden 'Session'
zugeordnet. uCs müssen Responsenachrichten nicht unterstützen, können aber.
Nachrichten vom Typ 00 bzw. Typ 01 haben immer folgendes Format für den
Datenteil:
Byte 0: Group (Dienst)
Byte 1: Command
Byte 2..n: Command specific Data
Ein Teil der Kommandogruppen ist vordefiniert und wird von der GUI
unterstützt, der Rest der Kommandogruppen kann vom User frei definiert
werden, z.B. für eigene Kommandos.
Denkbare allgemeine Dienste wäre z.B.
1.) Infrastructure
Definiert Kommandos zum Abfragen der Namen von Knoten, zum SW-Reset
eines Knotens, zur Hardware, usw. Diese Kommandogruppe sollte in jedem
(physikalischen) Knoten implementiert sein. Damit lässt sich z.B.
herausfinden, das es einen Knoten 'RNBFRA - Roboter 1' mit den logischen
Knoten 'Motorsteuerung', 'US-Sensorsteuerung' und 'Liniensensor' gibt.
Auch Kommandos zur Überwachung der Knoten (z.B. ping, heartbeat) wären
hier gut aufgehoben.
2.) Sensors
Definiert Kommandos zum Allgemeinen Abfragen einfacher Sensoren sowie
(evtl.) zur Selbstbeschreibung von Sensoren.
3.) Motor Control
Definiert Kommandos um Allgemein eine Motorsteuerung zu kontrollieren,
z.B. Vorwärts(100cm), Rechts drehen(50grad), usw.
4.) Debugging
Definiert Kommandos zum Entwickeln neuer Komponenten. Funktionen dieses
Dienstes könnten z.B. 'virtuelle Konsolen' für den jeweiligen Knoten sein.
Auch ein 'Notstop' bzw. 'Pause' Kommando würde hier gut passen, genauso
wie das auslesen bestimmter Speicherstellen, ...
5.) Synchronised Variables
Definiert Client- und Serverfunktionalität für Synchronisierte Variablen.
Client-Befehle z.B. GetVar, SetVar, CreateVar.
Ich hoffe das war jetzt einigermaßen gut beschrieben. Wenn irgendwo noch
Fragen offen sein sollten: stellt sie jetzt.
Wie gehts weiter:
Ich werde zum obigen Protokoll "mal schnell(tm)" einen Prototypen hacken,
der das ganze demonstriert und mit dem man auch Teilbereiche wie das
Adress-DHCP und das dynamische Routing ausprobieren kann.
Sobald wir uns auf ein Protokoll für Schicht 3 bzw. Schicht 4 geeinigt haben,
können wir konkrete Schnittstellen für z.B. Java, C, Bascom definieren und
dann die Schichten entsprechend implementieren.
ciao,
Georg
marvin42x
13.02.2006, 14:02
Ich möchte bei der Protokollfestlegung noch mal einen Gedanken aufgreifen.
Auf der Ebene der Mikrocontroller geht es sehr spezifisch und eng zu. Können wir im Entwurf,
nicht unbedingt in der ersten Implementierung,
optional mehrere Protokolle vorsehen aus welchen der Mikro sich eins aussucht und ansagt?
Das würde für Verbindungen gelten bei denen die Beteiligten bekannt sind z.B Seriell com1: oder I2C. Das hat PicNick meiner Meinung nach auch schon mal vorgeschlagen.
Die Festlegung würde in einem Eröffnungsdialog der Verbindungspartner stattfinden.
Ein Verbindungs-Eröffnungs-Dialog wo sich die Verbindungs-Partner bekannt machen, (auch z.B.Konfigurations-Veröffendlichung) und das Protokoll aushandeln.
Dieser Dialog ist auf Anforderung wiederholbar.
Danach Verbindung mit gewähltem Protokoll.
Wir könnten verschiedene Protokolle testen ohne uns jetzt schon festzumauern.
Bei der ersten Implementierung wären unterschiedliche Protokolle für die Mikros denkbar solange die Gegenstelle auf dem PC diese beherrscht.
Den Eröffnungsdialog bräuchte man fürs Erste nur ganz kärglich realisieren:
Mikro sagt: Protokoll 5
PC sagt: kann ich
Mikro sagt: Ok
Los geht’s…….
Netter Gruß
@ragnar (Stuffing), denk noch mal nach. im Prinzip isses wurst, ob du vor oder nach einem Zeichen was einfügst.
Deine Variation bedeutet, dass du vor JEDEM Steuerzeichen prefixen mußt.
Ich hab eben vorgeschlagen, daß jedes Zeichen immer das ist, was es scheint, ausser eben, es ist vorher prefixed. Also statistisch günstiger.
Fehler gibt's keine, glaub mir, ich hab das schon öfter angewendet.
@PickNick: Ja, du hast natürlich recht. Wenns nur ein Steuerzeichen gibt
ist das mit dem Bytestuffing gut. Eigentlich hindert einen auch niemand
daran, bei Bedarf ein zweites Kontrollbyte zu stuffen. Was mir aber noch
nicht ganz klar ist: Wie erkennst du das Ende einer Nachricht (ohne die
Länge explizit mitzuschicken)? Das geht in diesem Fall dann nicht, oder ?
@marvin42x: Nicht unmöglich das mit den verschiedenen Protokollen,
aber welche genau stellst du dir da vor? Irgendwo müssen wir uns
festlegen, sonst können wir nie anfangen. Und wenn man die 4. Schicht
richtig implementiert ist es ihr egal, welches Format die Addressen genau
haben und man kann die unteren Schichten problemlos austauschen.
ciao,
Ragnar
marvin42x
13.02.2006, 21:58
Mein Vorschlag soll die Einigung und den Fortgang nicht bremsen.
Punkt 1 ist Einigung auf ein Protokoll und los.
Ich bin mit fast allem einverstanden weil ich es eh nicht besser kann.
Der Vorschlag soll verhindern, dass das System am Ende zu properitär wird. Ich sehe andere Mikrocontroller-Welten und Projekte die ich optional gerne zu Gast hätte. Wie die am Ende aussehen mach ich mir noch keine Gedanke, ob das Legosysteme sind oder von irgendeiner Uni oder was aus Jugend forscht. Oder was anderes weis ich nicht.
Aber generell würde ich lieber auf diese Option verzichten als auf die Fertigstellung eines funktionierenden Kommunikationssystems.
Netter Gruß
NumberFive
14.02.2006, 06:46
@ragnar
Ich muß zu geben das ich ganz schlechte erfahrung mit Telegrammen ohne Längen information gemacht habe. Das Problem ist die er kennung von Müll.
OK an was ich nicht gedacht habe ist steuer Byte in halb der Daten.
Ich finde den Header des halb gut um den Anfang zu finden. gerade wegen dem Stecken und ziehen der verbindung. Was bei mir sicher nicht vo kommen kann aber wenn die RS232 über Funk geht währe das sicher öfter mal möglich (Funkschatten).
Zweites problem bei Übertragung ohne Längen Information auf einem AVR ist es sicher noch möglich ein Timeout zu bauen aber auf dem PC bringt man sich schier um wenn so ding sagt wie wenn das nächste Zeichen mehr als 5 msec braucht ist es ein neues Telegram.
Klar währe Framing auch eine Lösung die bei Funkübertragung vielleicht noch besser tut. Jedes Byte durch zwei zu ersetzen halte ich auch für zu aufwendig und zu daten intensiv.
Ich denke auch wenn man die Anwendung und das Protokoll durch gemeisam genutze Komponeten abgrenz sind Protokoll änderung nicht ganz so Probelmatisch. weil man "nur" so files oder dll tauschen muß dann tut es wieder oder beim avr ein header und ein c file.
Dabei stellt sich mir gerade die frage wie macht man so was bei Bascom ? Kann man da auch libs bauen ?
Freue mich schon auf die erste software.
Wie machen wie es auf der TCP/PC Seite das Selbe Protokoll ?
Oder was lesbares ?
Wenn nicht das Selbe würde ich dann den TCP/PC teil machen so bald ragnar das mal roh gehackt hat.
Off Topic:
Warum wurde ich nicht benachritig das es hier was neues gibt ?
Gruß
Wie erkennst du das Ende einer Nachricht (ohne die
Länge explizit mitzuschicken)? Das geht in diesem Fall dann nicht, oder ?
Klar, eine explizite oder implizite Endekennung muß es geben. Ich hab da zwei Variation am Laufen: Eben mit einer Länge gleich als zweites Byte nach HDR-Kennung
Die andere (für andere Zwecke) ist, a la EDI(FACT) Es gibt
Frame Start/Ende Ctrl Bytes UND
Element und sub-element Separators. (ÚND ein eigens Prefix-Zeichen)
Das ist dann sinnvoll, wenn man die Daten als völlig transparent und variabel-lange Fields & Folders übertragen will.
Für µC scheint mir entweder die Längenbyte Lösung ODER
ein EOB -Zeichen anwendbar.
Längenbyte ist beim Empfang praktisch, beim Senden muß ich aber erstmal das ganze Frame aufbauen und kann dann erst senden. (und µC haben nie viel Platz)
Ich würde für diesen Level aber einfach mal die erforderlichen Funktionen definieren (Init, RX, TX, ev CRC) und die Schnittstelle dazu.
Dann kann man das immer noch auf zehn Arten Lösen, je nach Laune. (von mir aus Brieftauben)
Wir müssen ja auch Half-duplex und andere HW-Specialities mögloich machen
NumberFive
16.02.2006, 08:02
wenn ich PicNick jetzt richtig verstehe Sieht er ein Problem wenn die länge im AVR codiert werden muß weil ich erstmal die nachricht zu sammen bauen muß damit er weis wie lang sie ist richtig ?
Also bleibt nur Frameing richtig ?
also doch wieder mein A und mein E ok das ist nicht schön aber das ist ja genau das.
So nun zu meinem Vorschlag:
Schicht 1:
ENQ chr(5)
<to define>
ETB = chr(23)
wenn 5 oder 23 oder FF in der nachricht ist muß ein FF vorran gestellt werden.
Das ist dann unters Level weiter runter gehts nicht.
Ok ist dem vorschlag von ragnar sehr änhlich nur eben anders rum
die Daten werden nur mehr wenn ich in den daten steuerbyte habe.
Währe das was auf das wir uns erstmal fest legen können und so die Schicht ein Beschliessen ?
Gruß
Klingt mal nicht so schlecht.
Bei der Auswahl der Zeichen sollte man aber schon mal überlegen: Es sollten Zeichen sein, die möglichst selten als Datenbytes vorkommen. Das ist bei transparentan binärdaten schwer zu gewährleisten
ABER: Ein bißchen was weiß man schon:
32 - 127 ist das ASCII Bereich, dem sollte man ausweichen
< 32 wird häufig in binärzahlen auftreten, FF ist bei negativen binärzahlen sogar SEHR häufig (denk dir ein 32-Bit Long mit dem Wert -1, das sind gleich 4 stück drin)
Am ehesten wohl Zeichen 128 - 175, das sind Muster, die nicht gar so zwangsläufig vorkommen.
Mögliche Steuerzeichen:
STX Framestart
ETX Frameend
PFX Prefix
Wenn Kontrollsumme, dann 8-Bit BCS mit einfachem XOR (exclusive Prefixes und STX/ETX)
Wenn wir sowas als Basis-Form festlegen, die jedes Level-0 Modul können muß, haben wir auch die Möglichkeit, auf diesem Level zu Beginn Negotiation-Messages auszutauschen ( a la TELNET) und damit Kommunikations-Varianten auszuhandeln.
Wenn es wer nicht weiß: Zu Beginn schickt einer eine Message mit der Protokoll-description, die er gerne anwenden würde. Darauf schickt der andere die Variante zurück, die er auch erfüllen kann (sozusagen der Mengendurchschnitt).
Dann geht's auf diese Art eben weiter.
Hat den Vorteil, daß man nicht irgendwas auf ewig in Stein meißeln muß, was uns später aus irgendeinem Grund dann auf den Senkel geht.
(Alte Designer-Weisheit: Keine Standard-entwicklung ohne gleich ein Escape festzulegen)
Ach ja: Ich würde noch festlegen, daß immer der µC der ist, der sie Verbindung aufbaut (der wird wohl auch öfter auf- und abgedreht werden)
D.h. der PC spielt immer den Host
marvin42x
16.02.2006, 09:58
Für mich sieht das gut aus. Die letzten Ergänzungen von PicNick halte ich für sehr sinnvoll.
Das macht auf mich einen tragfähigen Eindruck.
Netter Gruß
... die möglichst selten als Datenbytes vorkommen.
Dann lasst es uns doch so machen ?
... SLIP geht den einfachstmöglichen Weg einer solchen Verbindung, indem einfach die Oktets eines IP-Pakets über das serielle Kabel gesendet werden. Das Ende des Pakets wird mit dem speziellen END-Zeichen Nr. 192 (Oktalcode 300) gekennzeichnet. Falls dieses Zeichen innerhalb des zu sendenden Pakets auftritt, wird stattdessen die Sequenz 219/220 (Oktal 333+334) und für das Zeichen Nr. 219 selbst die Sequenz 219/221 (Oktal 333+335) übertragen. Das Zeichen Nr. 219 wird ESC-Zeichen genannt.
@Vogon: jaja, alle stuffen ein bißchen anders. Es ist für einen µC aber ungünstig, bereits gespeicherte Zeichen rückwirkend zu ändern. Vermutlich wird der Bursche ja in eine Ringbuffer speichern, und da ist das ein unnötiges gewurstel, womöglich am Wrap-Point.
Ist ja klar:
du kriegst ein 0xDB oder 0xDC , kann ja sein, also speichest du und machst einen Pointer-advance (ev. mit Wrap) Kommt jetzt ein 0xDC und vorher war ein 0xDB, mußt du 0xDB auf 0xC0 ausbessern und wirfst 0xDC weg. wenn nicht, gelten beide
war vorher aber KEIN 0xDB, ist das 0xDC vielleicht der Prefix von 0xDD, das aber erst dann kommt oder auch nicht
detto für 0xDD : war ein 0xDC, wird es ein 0xDB und 0xdd fällt weg.
Diese ganzen (meisten) neueren Protokolle sind aus dem Hochmut entstanden, daß alles vorher alter Schwachsinn von senilen Deppen sein muß, also muß was Neues her.
Noch ein Zusatz, betrifft nicht unbedingt Level-0:
Da wir ja nie direkt ins IP-Netz gehen, verzichten wir a priori auf die network-order bei >8Bit feldern. also immer im Intelformat (LSB-->MSB)
Floats immer im IEEE754 (?stimmt die Nummer), das ist das übliche PC-Format, etwas umständlich, aber verbreitet.
Frage an die älteren Herren: Wie ist denn das bei BCD ? Die sind ja MSB-->LSB , denk ich ? (is selten, hab' ich verdrängt). Was is denn da für ein Vorzeichen üblich ?
(Die Floats sin bei PIC's anders, deshalb der Hinweis)
Heute hab' ich meine Plauder-Tag:
Bei der ganzen Stufferei gibt's noch die Möglichkeit, ganze Kontroll-Zeichen-Gruppen zu stuffen. Also z.B
Kontrollzeichen sind potentiell ALLE Zeichen 0xA0-0xAF
d.h. jedes Zeichen mit "A" im high-Nibble muß gestuffed werden.
Der Vorteil liegt (läge) darin: Beim Programm code kann muß man nicht einzeln mit STX, ETX und PFX vergleichen, sondern nur einmal das obere Nibble checken (am µC besser für die Performance)
Frage 1: Framing oder Länge
Soll das Ende der Nachricht durch eine 'End of Frame' Kontrollzeichen
oder nach einer beim Beginn übertragenen Länge erkannt werden ? Meiner
Meinung nach total egal. In beiden Fällen kann die Nachricht dynamisch
und ohne puffern empfangen und gesendet werden (obwohl ich das nicht
empfehlen würde ...).
Mir persönlich gefällt der Framing-Ansatz besser.
Frage 2: Maximale Länge der Nachrichten
In beiden obigen Fällen (und bei uCs mit wenig Speicher sowieso) brauchen
wir eine maximal mögliche Nachrichtenlänge. Ich würde mal 128 Byte vorschlagen.
Frage 3: Codierung von Kontrollzeichen
Welche Möglichkeiten gibt es ?
Ein Kontrollzeichen mit Bytestuffing:
X => Kontrollzeichen, XX => Datenzeichen X
Problem: Nur Startzeichen kann eindeutig erkannt werden,
alle anderen Zeichen könnten mehrdeutig sein.
Escapezeichen für alles:
XY => Escapezeichen mit 'Parameterzeichen'
abhängig von Y ist XY entweder Daten- oder KOntrollzeichen
Immer eindeutig, aber Kontrollzeichen immer 2 Bytes lang.
Mischform:
A, B, C => direkte Kontrollzeichen
XY => Escapesequenz, entweder Daten (A, B, C oder Kontrollzeichen)
Genau ein Kontrollzeichen(Escapezeichen) zur Darstellung der
Datenbytes. Alle anderen Kontrollzeichen 1 Byte. Eindeutig.
Da wir im Vergleich zu den Steuerzeichen wohl eher kurze Nachrichten
haben fallen reine Escapezeichen wohl aus. Ich schlage deshalb die
Mischform vor. Ich glaube jetzt erstmal nicht, daß wir eine ganze
Gruppe an Kontrollzeichen definieren müssen, ist mir aber letztendlich
egal. In der Mischform ganz einfach (3 bit, 7 Kontrollzeichen, 1 Escapezeichen):
0xA0 - 0xA6 sind Kontrollzeichen
0xA7 ist ein Escapezeichen, vom nachfolgenden Datenbyte werden 0x08 abgezogen.
Datenbytes 0xA0 - 0XA7 werden als 0XA8 - 0XAF übertragen.
Am Anfang sollte eigentlich erstmal zwei Escapezeichen reichen:
0xA0=StartFrame und 0XA1=StopFrame.
Frage 4: Protokollinitiierung
Die Idee, das genaue Protokoll in einer Initiierungsphase festzulegen
finde ich eigentlich gut. Das ganze würde ich aber noch etwas schieben
bis wenigstens ein mögliches Protokoll implementiert ist. Dieses erste
Protokoll würde ich auch erstmal ganz einfach gestalten: ohne Handshake,
Acks, CRCs, bidirektional und ohne timeouts. Ausserdem würde ich bei
dem 'Handshake' nicht darauf vertrauen, daß es einen 'Slave' und einen
'Master' gibt, sondern beide können versuchen, die Verbindung aufzubauen.
Eventuell will ich ja auch mal zwei uCs oder zwei Rechner verbinden.
@NumberFive: Click unten auf die Uhr, dann wirst du wieder Benachrichtigt.
@PicNick: Little/Big Endian Probleme würde ich sie erstmal an den
Anwender (Schicht 4) weiterschieben. Dann können wir als Konvention
immer noch network order für große Zahlen verwenden.
ciao,
Ragnar
Ich habe noch keine richtige Vorstellung zum Timeout.
Wenn Zeichen verlorengehen, bei einer IR oder Funkverbindung ist damit zu rechnen.
Das sollte die Übertragung aber nicht aus dem Tritt bringen.
Beim Wikipedia-lesen zu SLIP habe ich das gefunden:
Eine Modifikation des Protokolls sendet das END-Zeichen auch zu Beginn jedes Pakets. Dies macht die Übertragung robuster gegenüber geringem Leitungsrauschen zwischen den Paketen.
Hallo Ragnar,
hier mal meine Ausführungen zu Deinen Fragen.
Frage 1
Eine übertragene Länge macht in höhere Schichten weniger Probleme als Framen
Beim Framen fühlt man sich als Programmierer in alte Zeiten versetzt und muß mit Timeouts auf Daten warten die vielleicht noch kommen werden (oder auch nicht.. mit Überraschungseffekt)
Man muß je nach dem für Speicher (Buffer) sorgen (alockieren und resizen wie bekloppt) ... nene
Lieber eine Lenght zu begin und ein Frame bzw. Endflag.
So merkt man den Müll in der Leitung besser solange es hierführ noch keine expliziten Checks (Checksumme etc.) gibt.
So ne art zweite Sicherung des Pakets
(Datenpacketlänge richtig kein Endzeichen ... Müll dabei)
(Datenpacketlänge zu kurz/ zu lang + Endzeichen ... wieder Müll)
(Datenpacketlänge richtig + Endzeichen ... könnte passen)
(Endzeichen fehlt ... Leitungsprobleme)
Das Endzeichen könnte hierbei auch eine Checksumme sein. So ne Art ECC für Datenpackete. (Kann auch unter ISBN-Checksumme nachgelesen werden)
Frage 2
Generel klingt 128 Byte ganz ordentlich... und könnte vielleicht sogar ausreichend sein. Als max. Paketgröße (right?)
Wie ist das eigentlich mit den Buffern ausgegeangen?
Auch hoffe ich immernoch auf schnelle Bilddaten.
d.H die Untere Ebene kann sich an diese 128 halten. Beim nächsten Layer aber bitte mehr Saft... Buffering etc.
(für verwöhnte programmierer )
Frage 3
Wie wärs mit regexp oder ähnlich:
A = Irgendein Ctrl char
\A = A
\\\A = \A
...ist etwas einfacher zu verstehen.
Frage 4
Das Protokoll zur Anmeldung sollte meiner Meinung auch erst beim SW-Entwurf dabei sein.
Bislang kann man noch nicht sagen welche Infos ausgetauscht werden müßen.
(An dieser Stelle würde ich auch die Byteorder einflicken, denn im Layer 4 ist es zu spät!
Das Layer 4 bedient sich aus Daten der unteren Layer... wenn die Unteren Layer dann nichts zur ByteOrder verraten, kann es von Layer 4 auch nicht gerochen werden. )
Ok man könnte es explizit zuweisen/konfigurieren usw. aber der ganze Konfigurationskram ist ziemlich Erklärungsbedürftig und pflegeintensiv.
Und wie uC <-> uC damit klar kommen soll würde dann auch ein Rätzel bleiben.
Netter Gruß @all
Chris
EDIT: Man sollte Nachts schlafen und nicht über geschriebenen Käse senieren ;-)
NumberFive
17.02.2006, 07:04
@ragnar wenn ich auf die Uhr klicke dann wird die Benachrichtung ab geschaltet ich schalte sie mal ab und wieder an mal sehen vielleicht klappt es dann wieder ist echt doof wenn man dauert gucken muß.
@Alle die Zeichen für das Framing sind mir egal sucht euch was aus.
Mir ist nur wichtig das wir mal level 1 hin bekommen damit wir weiter
machen können. Wie ich schon geschrieben habe möchte ich gerne bassiert auf diesem Protokoll meinen Roboter machen. Nachdem prinzip ich nutze auch das was ich verbrochen habe. So findet man Probleme schneller.
Ich halte mal folgendes Fest:
Wir machen Frameing
Daten die Frameing zeichen enthalten werden ein Escape zeichen vorran gestellt.
Längen Information währe schon aber ist auf dem AVR schwierig.
Es gibt eine Protokoll aushaldungs Phase am anfang.
Ich sehe mit dem Little/Big Endian Problem das sehe ich auch nicht in der schicht 1 den ich muß eh wissen von wem bzw. was es für ein tegram ist damit ich es decodieren kann damit ist auch dann die Übertragung von lsb/msb geregelt.
Gruß
Einwurf: Das mit der Network-Order ist solange eine Sache der oberen Fuzzies, solange wir da unten eh nur Bytes handeln. Gibt es aber Bestandteile , die mehr als 8 Bits haben (Adressen) müssen wir uns darum kümmern, bzw. eben einfach festlegen.
Das mit der Länge ist praktisch, wenn man beim Empfang einfach sagen könnte, in den nächsten x-Bytes kann kein Steuerzeichen sein.
ABER grad beim µC wird es vorkommen, daß er dieses oder jenes Zeichen einfach nicht mitkriegt. Es muß also trotzdem aufpassen, ob nicht mitten in seinem Frame vielleicht doch ein neues Frame beginnt.
D.h. IMHO, drüber gelegt muß auf jeden Fall eine STX /ETX Kontrolle sein. Ein Längenbyte könnt' aber durchaus das BCC ersetzen, da ja Länge & ETX zusammenpassen müssen.
Ein Länge vorne würde aber a priori einen Frame-build on-the-fly unmöglich machen.
Paketlänge: Die Zeit ist u berücksichtigen. Bei 9600 brauch er für hundert Byte ~0.1 SEKUNDEN. Das ist lange genug, wenn zwischendurch ein Alert auftritt.
Denkt an die Möglichkeit Flag:MORE, d.h. es wird gesagt, daß die Daten des nächsten Pakets zu diesem bei gleicher Adresse dazugehören. Das macht ja IP auch so.
Und für Bildbearbeitung ist UART sowieso eher sub-optimal.
Also eine Restriktion auf Framesize 127 scheint sinnvoll und eigentlich zumutbar.
Ein Atmega32 kann damit in 16 Frames seinen kompletten SRAM schicken. (samt dem Stack)
EDIT: DIe maximale Framesize ist aber typischerweise eines der Dinge, die bei den Negotiations auszuhandeln sind
@Marvin42: Da du ja meine Unit-Geschichte schon kennst, wärst du ein gutes Versuchs-Meerschweinchen für mich: (ist aber keiner ausgeschlossen)
Ich hab eine Bascom - LBX für die Netzwerk-Grundfunktionen gemacht (Beta natürlich)
Das beispiel tickert am Teminal nur sinnlos vor sich hin, aber man kann über die Tastatur sozusagen "Frames" eingeben, die an eines der Units adressiert werden können.
Das Proto-type Frame (muß man ohne Echo blind eingeben)
STX = "C"
Destination
Class = "A"
Ident = 1, 2
Data
irgendwas , wird nur angezeigt.
ETX = <ENTER> (d'13')
Backlink adresse und Ack's gibt's im Moment mal nicht mal nicht.
Also (ist aber nicht case-sensitiv)
CA1muhkuh<ENTER> ---> Unit 1
CA2saubaer<ENTER> ---> Unit 2
CA9 ....<ENTER>----> Fehlertext
Weniger als 3 Zeichen --> Fehlertext
Vielleicht hast du ja Lust
http://195.128.164.40/RT_MUSIC/electronic/download/down.htm
PS: Irgendein stuffing gibt's derweil nicht, wie gesagt->Prototype
marvin42x
17.02.2006, 11:56
@PicNick:
Immer für was zu haben, mache mich nach Feierabend, wenn ich zu Hause bin gleich mal drüber.
Netter Gruß
marvin42x
17.02.2006, 19:23
@PicNick:
Habe ich gemacht wie mir aufgetragen. Lib ins Bascom Verzeichniss, sys.bas kompiliert und in den Mega32 übertragen. Terminal angeworfen und CA1,2 ;-) eingegeben.
Ich konnte jede Unit einzeln ansprechen ihr was von unterschiedlicher Länge übergeben was sie zurückgab und sie hat mir auch brav ihre Parameter runtergebetet.
Das Unit-System gefällt mir richtig gut. Kann ja sein das es für Dich ein alter Hut ist, weis ich nicht. Aber ich freu mich halt dran.
Das mit der Lib in Bascom ist ja damit wohl auch demonstriert.
Nach so einer Phase von Überlegungen hat es auch was Erfrischendes wenn man mal so ein Alphatierchen laufen lässt. Das hatte mir auch bei NumberFive 's Sachen gefallen wenn irgendwas ein Lebenszeichen von sich gibt.
Netter Gruß
aus dem GPRC-SST
Guinea Pig Research Center - Section Softwar Test
@UlrichC:
Vom Anmeldeprotokoll und der Protokollaushandlung darf die 4. Schicht
nichts mitbekommen. Der sind die physischen Medien erstmal total
egal. Ich denke hier auch erstmal an ein unterschiedliches Protokoll
für die Frameübertragung auf der 1. Schicht (für seriell). Dann muß
dieses Protokoll auch dort sein.
@PicNick:
Übertragung von beliebig langen Frames durch Stückelung ist relativ
aufwändig. Das würde ich lieber in Schicht 3 schieben bzw. eventuell
sogar in Schicht 4.
@PickNick:
Ad-Hoc Frameaufbau mit Länge ist nicht weiter schwierig. Deine
Anwendungsschicht weis ja genau, wie lange ihre Daten werden.
Dazu kommt noch die Headerlänge - fertig. Die übertragene Länge
ist ja die Länge der realen Daten, nicht die der escapted oder
gestufften Daten.
@UlrichC:
Die Anwendungsschicht weis die Länge ihrer Daten immer genau.
Die Details des Framings, Escapings, etc werden ja durch die
unteren Schichten versteckt.
Ragnar
Deine Anwendungsschicht weis ja genau, wie lange ihre Daten werden.
Nun, in vielen (meisten) Fällen wird das so sein. Aber wenn du dir einen Register- Vorgang vorstellst, kann da schon mal Text drin vorkommen, "SF08-Special Vers 1.24" (auch wenn man bei µC das wohl eher vermeiden wird)
AAAAber:
Der Receiver muß auf jeden Fall trotzdem immer mit-tracken, mit der Länge allein ist die Sache einfach nicht wasserdicht, also was soll's dann ?
Technisch ist dadurch die Länge auch nicht mehr eingeschränkt, wenn einer sein komplettes logging / Video-Zeile in einem Frame übermitteln will, dann soll er. Habe ich eine Längenangabe, muß ich mir auch schon überlegen, wieviel bit die hat.
Also ich bin für STX/ETX/PFX, Steuerzeichen A0-AF , vor dem ETX ein einfacher XOR-BCC.
Anders geht's natürlich immer, aber wenn ich mir das Gefummel in den anderen Layern vorstellen, daß ja noch ausständig ist, würde ich auf dem Layer-0 mal Redaktions-schluß machen. Da is nix zum gewinnen dabei.
@Marvin42x: Meer-(Spree-)Schweinchen : Danke für die Tests. Du hast ja gesehen, daß das Receive-Modul sehr anspruchslos ist. Ich werd das als Nächstes in der Library verschwinden lassen. Leider setzt das dann schon einen PC-Partner voraus, der da auch mitspielt. (Und mir graut ja so vor dem PC-Programmieren, *kotz*)
Ich hab gedacht, das Comm-Zeugs in eine DLL zu stopfen (*würg*). Ein Arbeitskollege (VB-Spezialist) hat mir versichert, es wäre kein Problem, sowas dann auch mit VB zu benutzen.
Andere Überlegung ist, einen Stand-alone Server (Background-Programm) zu machen, der unsere Frames einfach auf IP umsetzt. Diesen Server dann über IP anzuquatschen geht eigentlich mit jeder x-beliebigen Sprache, auch gemischt (und übers Home-Network).
So eine Server-Programm sollt' dann auch gleich Sniffermäßig fürs Tracing und logging zuständig sein, denn grad am Anfang unserer Entwicklung wird beim Testen ein genaues Protokoll, wer wann was in welcher reihenfolge gesendet hat, bitter notwendig sein.
marvin42x
18.02.2006, 12:12
@PicNick:
Ich sehe hier schon den von UlrichC heraufbeschworenen Applikationsserver am Horizont. Einen Stand-alone Server (Background-Programm) egal in welcher Ausprägung wäre zur Zeit meine Wahl.
Beispielsweise eine VB-GUI auf der Seriellen wäre nicht mein Ziel.
Eine VB-Lib könnte ja später mal eine gewünschte Ergänzung sein.
Also so rasch wie möglich TCP/IP
Und danach die Möglichkeit auch VB-Programme anzudocken.
Der Server müsste dann, wie du schon sagst, einige Fähigkeiten drauf haben.
Die erste Version davon könnte aber auch erstmal minimal sein.
Die Kommunikation Mikro-Mikro ist m.E.. Ein spezieller Fall der auf der Ebene der Protokollaushandelung gelöst werden sollte.
@All
Erstmal einen Redaktionsschluss auf Level 0 hat, meiner Schätzung nach, wohl im Moment die Stimmenmehrheit?
Ich bin für ja, obwohl ich weis das es noch eine Menge dazu zu sagen gäbe
Sagt mal was dazu.
Netter Gruß
Also ich bin für STX/ETX/PFX, Steuerzeichen A0-AF , vor dem ETX ein einfacher XOR-BCC.
Anders geht's natürlich immer, aber wenn ich mir das Gefummel in den anderen Layern vorstellen, daß ja noch ausständig ist, würde ich auf dem Layer-0 mal Redaktions-schluß machen. Da is nix zum gewinnen dabei.
Soll mir im Prinzip recht sein so, allerdings würde ich nur 8 Spezialbytes (3 Bit statt 4 Bit) definieren.
Das sollte immer noch dicke reichen. Meinst du mit PFX das Präfix für Datenbytes? Ist es für euch
okay, die gepräfixten Datenbytes um 5 nach oben versetzt zu übertragen ? Und schlussendlich:
meinst du mit XOR-BCC ein kontinuierliches XOR auf den ungepräfixten Datenstrom ?
Damit können wir Level 1 "seriell" denke ich schliessen und uns über Level 1 "Lan" bzw die höheren
Schichten gedanken machen.
BTW: Hat einer Lust unseren Konsens für Level 1 "seriell" irgendwo (z.B. im wiki) abzulegen ?
Ragnar
NumberFive
18.02.2006, 20:34
@PicNick,
wenn du willst mache ich die Dll oder besser ein exe server (Com) für windows
den mache aber dann in c++ wenn ich so weit kann ich dann exe oder dll hoch laden mit source dann kann die VB frakition mal probieren.
Was hälst du davon ?
Gruß
PFX: ist das Zeichen, mit dem das folgendes Zeichen als NICHT Steuerzeichen, also als Datenbyte, gekennzeichnet wird.
XOR: ja. ich mein', eben beginnend mit NULL, alle Zeichen ZWISCHEN STX und ETX (exklusive Prefixes) aufzu-xor-en.
Es gibt da ein Verfahren, wenn das result < 32 ist, was raufzuaddieren. Da muß ich noch nachdenken, was das bringt. Wenn es beim Verarbeiten keinen unnötige Arbeit macht, würde ich es anwenden, eben weil es schon wo so definiert ist. Und unbedingt neu muß unseres ja nicht sein.
@ragnar: Prefixte char + 5 . Kannst den Hintergedanken erläutern ? Welchen Vorzug bringt das ?
@No-5 : Da jetzt schon die Rede von VB und C++ und nochwas ist, ist ein komplettes EXE wahrscheinlich das Beste, mindestens für's Erste.
Ich bin noch nicht sicher, was genau für Eigenschaften gebraucht werden.
Aber ein Prototype muß ja nicht gleich alles können.
Gut wär ein Protokoll-write in ASCII-CSV Format, dann hat man gleich ein paar Auswertungsmöglichkeiten umsonst dazu.
Parallel dazu vielleicht ein Raw-dump-format zur speziellen Analyse von verstümmelten und falsch gestufften Messages (kann ja vorkommen, hab ich gehört)
IP-mäßiges Verhalten: Irgendwann müssen wir überlegen, wieweit der Zugroff mehrerer PC-Applikation reglementiert werden soll /muß. Datenreceive vom µC kann ja beliebig verteilt werden. Nur bei Commands wären Konflikte denkbar. Dann mußte man doch eine art login machen mit session und so.
NumberFive
19.02.2006, 09:39
Hallo PicNick,
klar ist das was ich da schreibe erst mal zu probieren ist mir schon klar.
Das Protokol file ist bei mir Standart das brauchst bei nicht erwähnen das mit den Dumps muß ich mir mal überlegen aber da fällt mir was ein.
Ich mach ein Exe comserver das ist glaube ich erstmal die Beste lösung mal sehen wie Zeit ist dann mache ich auch ein beispiel wie mal da dann per VB zu greifen kann. Und wenn ich ganz gut drauf bin haue ich das empfange noch per Multicast raus dann kann man sich das auch mal an gucken. wie sieht jetzt genau dein Protokoll aus der lib aus ?
ETX ....... STX ? Soll ich das mal so Implemetieren der Rest kommt ?
@all habe wir hier nur VB und C++ oder auch delphi oder noch was anderes ?
Ich denke wir sollten es erst mal auf Multicast belassen da brauchen wir kein login und die Sicherung kann dann auf protokoll ebene machen.
Ports und login und so was sind code massig immer so auf wändig und seid dem ich weiß wie schnell Muticast ist halte ich das für das bessere als Punkt zu punkt verbindungen. das mit den Ports und anmelden war immer sehr komplex anderen zu vermitteln.
NumberFive
19.02.2006, 21:00
So habe mal schnell ein exe zusammen gehauen die emfangen und senden kann im STX ETX Frame. max frame größe sind 127 Bytes incl. EXT und STX
Da ich nicht weiß wie lange ich heute noch mache und wie die Exe dann ist habe jetzt mal hier hoch geladen. Der Rest kommt dann immer wenn was fertig ist.
Der Source ist jetzt erstmal nicht dabei bei weil überhaupt nicht kommentiert einfach runter geschrieben.
Gruß
@PicNick: Warum <char> mit <prefix><char+5> übertragen ?
Weil dann dein Kontrollzeichen mit dem Wert von char absolut eindeutig
im Datenstrom ist. Das erleichtert einige Dinge, z.B. kannst du immer
gleich feststellen, ob es sich wirklich um ein Steuerzeichen handelt.
Empfängst du ohne diese Bedingung einen char, hängt die Bedeutung immer
davon ab, ob davor eine Escapesequenz war oder nicht. Funktionell
letztendlich gleich, aber IMHO etwas flexibler zu handlen (Steuerzeichen
können vor Escapes gecheckt werden).
@PickNick:
Was ist das mit dem draufaddieren ?
@NumberFive:
Mit welchen STX/ETX/PFX hast du programmiert?
3bit oder 4 bit?
Und was nützt uns eine .exe die wir nicht haben ;-)
Und schreib doch kommentierten Source, dann hilfts uns gleich viel mehr.
@NumberFive:
Ganz wichtig: die Framegrösse muss für die Schnittstelle nach oben
gelten, 127 Bytes gelten also für die reinen Daten, ohne STX, ETX, PFX.
Wie gehts weiter ?
Tja, ich habe gerade javax.comm gedownloaded und werde damit wohl mal
die Schicht 1 für seriell implementieren. Mein Programm wird wohl erstmal
ein kruder 'Tester', der regelmässig Testframes sendet und alle empfangenen
Testframes und Debuginformationen auf der Konsole anzeigt. Wäre natürlich
prima, wenn das gleich mit euren seriellen Schicht-1en zusammenspielt.
Dann brauchen wir beizeit eine Schicht 1 für IP. Ich könnte mir hier
irgendwas wie UDP-Kommunikation auf festgelegten Ports vorstellen, mit
Rechnern die sich gegenseitig discovern. Alternativ dazu auch die
einfache Variante mit vorkonfigurierten TCP/IP Streams. Auf jeden Fall
muß da in der unteren Schicht viel automatisch gehen, die oberen
Schichten sollen ja von Kommunikationsmedium nichts mitbekommen.
Meinetwegen können wir LAN aber auch gerne erstmal schieben.
Und irgendwann brauchen wir dann eine Schicht 2+3. Da habe ich schon ein
paar ausgefeilte Ideen, die ich dann zu gegebener Zeit präsentieren werde.
Um auf PicNicks Frage mit den 'Sessions' bzw 'Login' einzugehen werde ich
schon mal ganz kurz vorgreifen:
- Eine Session wird vom Absender festgelegt und ist für den Absender eindeutig
- Eindeutig ist das Tupel (SenderAddress, SessionSequence)
- Es gibt Nachrichten ohne Session
- Es gibt Nachrichten für initiale Sessions
- Es gibt Nachrichten für Session 'follow-ups'
Eine Session baut der Absender auf, indem er eine initiale Sessionnachricht
schickt. Je nach Bedarf/Protokoll kann der Empfänger auf diese Session
einmal oder mehrfach antworten. Wann eine Session geschlossen wird, entscheiden
beide Kommunikationspartner eigenständig. Damit sind einfache Challenge-Response
Nachrichten möglich (mit Timeout für den Response) oder auch Registriermechanismen
bzw. dauerhafte Datenströme (virtuelle Debug-Konsolen)
Zur Sicherheit, bzw. 'login':
Auf Schicht 1 für LAN können wir gerne einen Login implementieren, auf den
höheren Schichten höchstens eine 'Firewall'. Das würde ich aber beides
erstmal schieben.
Ragnar
NumberFive
20.02.2006, 06:29
@ragnar
vielleicht habe ich ja was falsch verstanden aber für mich ist STX = chr(02) und ETX =chr(03) aber jeweils 8 Bit lang sprich ein Byte. PFX ist noch nicht implementiert weil ich noch nicht gesehen habe das ihr euch einig wart wie.
Wenn ihr euch einigseid ist das schnell drin. Die erweiterung für 127 Bytes daten kommt heute im laufe des Tages ist nur eine zahl im source.
Hast du Icq oder so entwas ? das könnten wir das Netz zusammen machen.
Leider hast du auch keine Mail adresse hier so könnte ich dir das per Mail schicken.
Du hast recht die exe ist nicht da aber hoch geladen habe ich sie kann sein das frank sie nicht nicht freigeben hat. Ich glaube das muß er immer machen.
Bitte nicht Upd warum nicht Multicast ist in java auch ganz einfach. Mir flipen hier die Firwarewals und sonstige sicherheits programme aus.
@all hat jemand noch platz auf seine HP ? PicNick ?
ich würde dann dem die exe schicken immer wenn es was neues gibt.
Gruß
@ragnar: char+5 : Alterserscheinung, ich steh' auf dem Schlauch. :oops:
Das nach dem Prefix ist ja dadurch genau KEIN Steuerzeichen. Und warum ist <char+5> eindeutiger als <char> ?
Ich laß es noch sickern, braucht uns nicht aufzuhalten.
Ich hab dzt. implementiert
#define ctl_base 0xa8
#define ctl_pfx ctl_base + 1
#define ctl_stx ctl_base + 2
#define ctl_etx ctl_base + 3
if ( (mychar & ctl_base) == ctl_base) then prefix it.
Über andere konkrete Werte können wir aber noch stundenlang diskutieren, mir ist alles recht
Ich hab noch Platz, denk ich. Gezippt schicken, aber zumindest *.Bas, *.VBS und .EXE umbenennen, der Spam-u. Viren filter frißt sonst das Mail.
robert.toegel@wienerborse.at
marvin42x
20.02.2006, 06:57
Frage zur Protokollwahl UDP TCP: www. TCP Port :80
Das soll am Ende gehen.
Ist das jetzt schon für die Überlegungen relevant?
Netter Gruß
Also würde port 80 / 8080 und die anderen festgelegten nicht nehmen, da macht sich jeder Webserver im Netz ins Hemd. Außer natürlich, man sprich http drauf.
Ich mach eigentlich nur STREAM, weil das meiste schließlich einen Backlink braucht (commands). Und ich will ja wissen, wenn einer stirbt.
Login mit User und Password brauchen wir ja nicht unbedingt, first come, first served.
Ich sag, wir nehmen als (parametrisierbares) Port # 42 (default) . Darüber hinaus ist das ja eine Hausnummer.
marvin42x
20.02.2006, 07:46
@PicNick:
Dieses http auf Port 80, was ja auch kleine Home-Web-Fileserver machen, sehe ich mehr als einen Endzweig. Nicht als Basisprotokoll. Mir geht es darum uns den Weg nicht zu arg zu verbauen.
Netter Gruß
Wär sicher auch reizvoll, eine Webserver zu basteln, der das Robonetz mit http zur Verfügung stellt. Sollte eigentlich auch nur Arbeit sein.
Was ich auf jeden Fall möchte, ohne Widerspruch zu unseren übrigen Gedanken, letztlich eine Fix-Foxi Anwendung, zugeschnitten auf bestimmte Boards (RB-Control, RNBFRA) anbieten zu können.
Es ist nicht jeder ein begnadeter PC Programmierer.
(Und nicht jeder will es *würg*)
NumberFive
20.02.2006, 08:25
Ich weiß garnicht was ihr immer mit der PC Programmierung habt die ist so Easy *g*.
Ich würde von den Ports deutlich nach oben gehen. da unten ist zu viel reserviert. Für web braucht man eh ein zwischen modul drum ist hier der Port ja egal.
Aber UlrichC wollte ja das web Interface machen und ich denke das macht er auch.
Was ich dringen Bräuchte währe die sachen mit dem escape und mit der Prüfsumme wenn ihr es den so wollt.
Habe Picknick das zip geschickt.
Gruß
Habe Picknick das zip geschickt.
jetz (um 9:30) hab ich noch nix. Hast die alle *.EXE und *.VBS umbenannt ?
Sonst muß ich unsere System-Fuzzies quälen, die Mail zu suchen und wieder auszuschaufeln.
Port-belegung: Seit ich mir die Belegungsliste mal geholt habe, hab ich keine Illusionen mehr. Ich hab gedacht, die sind definiert bis 500. Haaa-Haaa.
Das muß man parametrisieren können.
NumberFive
20.02.2006, 08:49
kann es sein das zip's zerlegt werden ?
Bei uns zerlegt er nix. Wenn da was drin ist, was ihm nicht paßt, frißt er alles.
Vergíß es, ich hab die Mail's (2 ?) ausschaufeln lassen.
Ich schau jetzt, ob alles da is, und rühr' mich gleich wieder
NumberFive
20.02.2006, 09:03
als wenn das umbennen der exe auch nicht funktioniert wie soll ich es dir dann schicken ?
Ja es war zwei mail's aber mit gleichem inhalt.
Gruß
So, ich hab das reingestellt, am besten probier's mal selbst
http://www.oldformation.at/electronic/download/down.htm
marvin42x
20.02.2006, 10:33
@NumberFive
welchen COM Port öffnet der Server?, bei mir ist das unterschiedlich welche mir zur Verfügung stehen, auf dem einen Rechner com1 auf dem anderen com3. Hatte sogar schon mal das Problem com16 wegen diverser Bluetuts
Netter Gruß
Edit: Mitloggen tut er ja auch schon, habe ich glatt übersehen
Edit: Und ein Initfile erstellt er auch. Ich sollte mir doch ein bisschen mehr Zeit nehmen bevor ich was frage.
Hallo,
hab heut mal frei und bin daher kurzweilig dabei.
(Supi das Reimt sich)
Ich möchte auf das Port 80:8080 bzw. HTTP mal eingehen.
Ich bin gerade dabei soetwas zu schreiben.
Jedenfalls habe ich mir hierfür bislang eine durchgängige Komunikation überlegt, die es momentan gilt zu implementieren.
Der Gedanke einen http-Server hierfür zu schreiben, wäre in dem Falle naheliegend nur dessen nutzen wäre fragwürdig.
Ich gehe davon aus das nicht jeder eine statische IP bzw. Domains im Internet hat auf denen er seinen RN-Appache auf Dauer laufen lassen könnte.
Die nächste Überlegung wäre ein Appache-Modul zu schreiben. Aber hier gilt ungefähr das selbe ... nicht jeder hat einen eigenen Server und kann sich Module nachinstallieren.
Und daher hatte ich als Zielsystem eine einfache Webseite im Visier die mit CGI-BIN Erweiterung ausgestattet fast in jedem Intranet bzw. Internet so vorzufinden ist.
Mein Ziel ist ein System zu schreiben das offene Schnittstellen an beiden Enden hat.
Die Konfiguration wir im eigentlichen Sinne so werden wie in einer Testumgebung...
Domain=jhsdjl.de
[ok]<-losgehts
Ich möchte auf dem Webserver dann auch keine Sockeds öffnen keine IP streamen , Tunneln, PtoP Verbindungen usw. nur eine CGI-Anwendung die auf der Rechnerseite einen/mehrere Werte bekommt und auf einer Oberfläche darstellt und im Gegenzug die Kommandos der Oberfläche zurückleitet.
Um eine Programmierung auf der Web oder PC-Seite kommt man ohnehin nicht rum. Softwaretechnisch macht es auch im endeffekt keinen unterschied ob es ein Webserver oder eine CGI-App (API) ist. Die Implementierungen sind fast identisch.
Nur das man im Falle eines eigenen Webservers zusätzlich zu den o.g. Punkten nur einen Kompromis zu einem "richtigen" Webserver hätte.
Die einfache Client-Serverchitektur (ohne HTTP RFC oleole) habe ich nicht in Erwägung gezogen, da diese hier bereits entsteht.
Ob der Login-Server später im WWW steht oder im Intanet auf einem Bot macht auch keinen Unterschied.
Wie getextet, ich möchte mit meiner Webprogrammierei nur die Anzahl derer erhöhen die soetwas dann auch im WWW Nutzen können.
Der Hack dabei ist das es wirklich überall funktionieren soll ... vorallem auch auf den verbreiteten Linux-Appache-Webservern oder dessen Win-Solution.
Ich habe hierzu eine Projektseite erstellt:
http://www.ulrichc.de/project/cu-www-gui/index_de.html
...um die Schnittstellengeschichte Layer0 bis X hier nicht noch weiter zu komplizieren ;-)
Die Sourcen, Systembeschreibungen etc. sind noch in der Mache.
(Bin nett so schnell, mangels Zeit, aber ich habe schon manches aus anderen Projekten zusammengetragen)
Freundlicher Gruß @All
Chris
PS: Ob ich Nutzer oder Mitwirkender des entstehenden Systems bin/werde kann ich aus heutiger Sicht noch nicht sagen.
Ich fang eben von einer Anderen Seite des Systems an und hoffe auf ein Treffen in der Mitte.
Bislang hab ich geplant nachdem der Prototype steht, bei NumberFives LayerX anzubinden (wie auch immer das dann RN-Technisch aussehen mag).
NumberFive
20.02.2006, 19:42
@PicNick da ist nicht eine Zeile MFC drin. Alles ATL und WTL.
@all
Wie marvin42x schon bemerkt hat ist das loggen und ein ini file dabei (erstellt sich bei ersten starten) in der Ini wird zur zeit der Com port und die Baud ein gestell der rest ist hard codiert aber ich denke das können wir auch so lassen nämlich 8n1.
werden als nächsten dann das send als Multicast machen und ein dll die man ein binden kann damit man von ein programm drauf zu greifen kann wie machen wir das pc protoll genauso ?
wenn wir uns auf die PC Adressierung schon mal eingigen können dann kann ich in die dll gliech ein filter funktion ein bauen.
Gruß
..nicht eine Zeile MFC drin
Ach so, ich hab gedacht wegen des Icons. Macht nix, den Text werd' ich morgen ausbessern
@ragnar: char+5 : Alterserscheinung, ich steh' auf dem Schlauch. Das nach dem Prefix ist ja dadurch genau KEIN Steuerzeichen. Und warum ist <char+5> eindeutiger als <char> ?
Also erstmal muß es natürlich <char+8> bzw. <char+16> sein (Asche über mein Haupt).
Ich werde das am besten mal an einem Beispiel erklären:
Bestehe die Nachricht aus den möglichen Buchstaben A-Z.
Seien ABCD die Kontrollzeichen, A=STX, B=ETX, C=PFX, D unbelegt. (vorerst ohne Verschiebung)
Der Sender sendet:
<ABCD EFGH>
Nach dem Prefixen + framen:
<A CACBCCCD EFGH B>
Durch eine Blöde Störung kommen die ersten beiden Zeichen nicht an:
<--><ACBCCCD EFGH B>
Dummerweise ist das, was ankommt immer noch eine korrekte Nachricht (allerdings falsch).
(Kann aber durch Checksumme abgefangen werden)
Jetzt mit Verschiebung:
Die Daten A, B, C, D werden auf CE, CF, CG, CH abgebildet.
<ABCD EFGH>
Nach dem Prefixen + framen:
<A CECFCGCH EFGH B>
Wenn hier ein Zeichen verlorengeht, ist das ganze kein Problem (Zeichen ausserhalb des Frames werden verworfen, Störung)
Ein weiterer Vorteil: In oberen Beispiel muß der Empfänger für jedes Empfangene Zeichen immer erst anhand des letzten Zeichens prüfen, ob das empfangene Zeichen wirklich ein Kontrollzeichen ist. Mit der Verschiebung kann er jedes eingehende Zeichen direkt überprüfen und nur bei Bedarf (nämlich im Falle eines Datenzeichens) schauen, ob das letzte Zeichen das Prefix war.
ciao,
Ragnar
Ich hab dzt. implementiert
#define ctl_base 0xa8
#define ctl_pfx ctl_base + 1
#define ctl_stx ctl_base + 2
#define ctl_etx ctl_base + 3
if ( (mychar & ctl_base) == ctl_base) then prefix it.
Und wo ich es gerade noch sehe: In der letzen Zeile müsste das if doch so heissen:
#define ctl_mask_3bit 0xF8
// oder
#define ctl_mask_4bit 0xF0
if ((mychar & ctl_mask_3bit) == ctl_base) { do_prefix() }
NumberFive
21.02.2006, 06:11
@ragnar dem post von 22:30 kann ich folgen und ihn verstehen aber den anderen verstehe ich nicht.
Gruß
@ragnar: Richtig, das mit dem If is falsch formuliert, eigentlich logo. Stammt aus der Zeit, wo noch Base == Maske war. *schäm*
+5 : Meinst du das so, selbst, wenn ich das Prefix versäume, kann ich trotzdem kein Steuerzeichen erkennen ?
NumberFive
21.02.2006, 07:51
So source ist an Picknick raus in der hoffung das er den bei die Exe packt.
Ich hoffe das mich die eingefleischten c++ programierer für den source nicht schlachten aber ich habe mir c halt selbst bei gebracht.
Gruß
So, drin' isser, gnä' Frau.
http://www.oldformation.at/electronic/download/down.htm
NumberFive
21.02.2006, 08:20
vielen herzlichen dank
Ich hab' mal begonnen, in unserer Wiki ein paar Dinge zusammenzufassen, soweit sie nicht strittig scheinen
https://www.roboternetz.de/wissen/index.php/Network_Controller/PC_Schichten
Bitte schaut mal, ob es bis dahin Widerspruch gibt.
Die Wiki-Page ist gut aufgebaut!
Kronologisch und Sauber erklärt.
Wenn das auf der Page stimmt hab ichs daraufhin durchgängig verstanden ohne den Thread durchzu"loop"en.
Gruß,
Chris
marvin42x
21.02.2006, 17:37
Sehr informativ und schön klar und strukturiert aufgebaut.
Klarer Punktevorsprung für die "Unstrittigkeits-Methode".
Freut mich das Du das so zusammengefasst hast.
Keinen Wiederspruch von mir.
Gruß aus der Stadt die mehr Brücken hat als Venedig
@marvin: Nicht gezählt die Zahnbrücken der älteren Damen und Herrn :mrgreen:
Anwesende und Betroffene sind natürlich ausgenommen
Ich bin nun dabei, im Verbund mit meiner "Betriebsystem"-Library diese unteren Level auf einem Atmega32 durchzuziehen. PC-seitig mach' ich mal nur das, was zum Testen dazu notwendig ist.
Die Auswahl, das für Bascom zu machen, ist der damit verbundene Zwang, das Zeugs auch in handsame Funktionen packen zu müssen, um einerseits den Freiraum der Anwender möglichst wenig einzuschränken und andererseit trotzdem von der Bitfummelei abzuschotten.
Gewissermaßen minimal-invasiv, wie die Chirurgen zu sagen pflegen.
Es soll halt den Mega-Anwender eher Arbeit abnehmen als machen.
Und wenn das mit Bascom geht, geht's mit C allemal, das is klar.
So könnten wir getrennt marschieren, aber vereint schlagen.
NumberFive
22.02.2006, 07:43
@PicNick
ich hatte das gefühl das du PC Seitig garnicht proggen willst soll wir es nicht so machen das ich an dem SerialServer den kram nach ziehen dann haben wir den gleich getestet ?
Kannst du das Projekt Compielieren oder wie wollen wir weiter machen ?
Schöne Wiki Seite !
Welches Zeichen nehmen wir als Escape /PFX Zeichen ?
wenn ich das weiß kann ich den SerialServer anpassen
Gruß
Dein Gefühl täuscht dich absolut nicht. Aber zum Testen und für ev. Eigenbedarf spezieller Art komm' ich ja auch nicht ganz d'rum 'rum.
Dzt. verwend' ich
#define CTL_M_MASK 0xF8
#define CTL_M_ADON 0x10
#define CTL_C_BASE 0xA8
#define CTL_C_STX CTL_C_BASE + 1
#define CTL_C_ETX CTL_C_BASE + 2
#define CTL_C_PFX CTL_C_BASE + 3
Senden stuffed:
if (bTxChar & CTL_M_MASK) == CTL_C_BASE)
{
bTxBcc ^= bTxChar;
transmit ( CTL_C_PFX) // prefix
transmit ( bTxChar | CTL_M_ADON)
}
else
{
TxBcc ^= bTxChar;
transmit ( bTxChar )
}
Anmerkung: Ich hab so diverse private Konventionen, bei #defines
aaa_C_aaa für feste Werte
aaa_V_aaa für Bit-Nummern /offsets
aaa_M_aaa für Bit-Masken
Alles, was #defined wird, immer in Uppercase
NumberFive
22.02.2006, 12:35
Gut wie du meinst ich habe es dir angeboten wenn du ICQ hättest dann könnte ich auch was auf zu ruf machen wenn ich am PC sitze.
So ganz komme ich mit dem Source nicht klar.
STX ist normaler weise 0x02 oder auch chr(2)
ETX ist normaler weise 0x03 oder auch chr(3)
So erwartet das mein prg im moment auch.
bTxChar ist nehmen ist an das Zeichen was gesendet werden soll richtig ?
bei dir sind aber ETX STX anders definiert sollten wir das nicht mal festlegen ?
Das Escape zeichen währe bei dir 171 das können wir gerne so machen aber irgend wo sollten wir das mal definieren.
Das TxBcc nehme ist das wo du dir die Prüfsumme merks das werde ich mal als nächstes ein bauen den ist denke hier herscht ja einigkeit das wir das so machen.
Gruß
PS: Wie könnte man dir ein exe schicken ohen das du graben mußt ?
Die ASCII- Steuerzeichen (0-31) können (wollen) wir nicht nehmen, da die viel zu häufig in den Daten selbst vorkommen werden (und ja dann "prefixed" werden müßten). Daher eben sowas exotisches.
Steuerzeichen sind alles von 168 - 175, derzeit verwendet:
STX = 169 = 0xA9
ETX = 170 = 0xAA
PFX = 171 = 0xAB
der rest ist nur, damit wir den Rücken frei haben für irgendwas Spezielles, was uns vielleicht noch einfällt.
BCC ist die checksum, richtig.
bTxChar ist das sendebyte, auch richtig.
NumberFive
22.02.2006, 14:23
Schreibst du das noch auf die Wicki seite ?
Vielleit sollen man da so eine rubrik machen RN Protokoll spezifikation (ich hoffe das ist jetzt richtig geschrieben).
Werden die Exe so schnell wie möglich umbauen wie bekomme ich sie zu dir hin zu testen ?
Gruß
Ich hab in der Wiki begonnen, das mal festzulegen
https://www.roboternetz.de/wissen/index.php/Network_Controller/PC_Spezifikationen
EDIT an alle: Bei Widerspruch bitte laut quietschen. Grad bei den Spezifikationen sollten möglichst keine Dinge stehen, über die kein Konsens herrscht.
NumberFive
22.02.2006, 15:11
sehr schön.
so was bringe ich nie hin kann nur programieren.
Die neue exe willst du wohl micht auch gut.
Gruß
No-5 : Ich geb' zu, ich hab erst begonnen, es mir anzusehen.
Leider kämpf ich ein bißchen zeitmäßig.
Aber schaut doch gut aus ? Was sollte mir nicht gefallen ?
Grad hab ich das Projekt rebuilden wollen . Er sucht
"atlres.h"
Ich steh auf dem Schlauch. Was will er ?
NumberFive
22.02.2006, 16:15
ist ein wtl projekt und dir fehlt wohl die WTL dort ist die datei dabei.
Ist per mail auf dem Weg weil es noch die Alte ist und ich nicht weiß ob man die noch runterladen kann irgendwo muß mal die neue auf dem rechner machen.
du hast in deinem Beispiel eine klammer vergessen nur so nebei
ich bin gerade an der Protokoll klasse bei mir sieht das jetzt so aus:
bool CRNProtokoll::SetByteData(BYTE* Buffer,BYTE Len)
{
BYTE x=0;
BYTE bLenAdd = 1;
m_bLowLevel[0] = CTL_C_STX;
for(x=0;x<Len;x++)
{
if((Buffer[x] & CTL_M_MASK) == CTL_C_BASE)
{
m_bLowLevel[x+bLenAdd] = CTL_C_PFX;
bLenAdd++;
m_bLowLevel[x+bLenAdd] = Buffer[x];
}
else
{
m_bLowLevel[x+bLenAdd] = Buffer[x];
}
m_bTxBcc ^= Buffer[x];
}
m_bLowLevel[x+bLenAdd] = m_bTxBcc;
m_bLowLevel[x+bLenAdd+1] = CTL_C_ETX;
m_bLength = Len+2+bLenAdd;
return true;
}
Gruß[/code]
Na, is ja schon !
da solltest du noch modifizieren:
m_bLowLevel[x+bLenAdd] = CTL_C_PFX;
bLenAdd++;
m_bLowLevel[x+bLenAdd] = Buffer[x] | CTL_M_ADON;
Ganz profimäßig könntest du noch mit der Maximal-größe des Lowlevel-Buffers vergleichen, abbrechen und mit false zurückkehren.
Durch das Stuffen ist nie ganz sicher, wie groß die Ausgabe wird.
NumberFive
22.02.2006, 21:12
Jo das wollte ich eh noch machen da aber Fasching (bin zum musik machen unterwegs) ist weiß ich noch nicht wann ich schicke dir den source dann ok ?
Ich hoffe du konntest es jetzt compilieren.
Wenn wir jetzt das mich der Adresse definieren kann ich die dll anfangen und dann könnte mal eine ein VB Teil machen zu testen.
Gruß
..zum musik machen unterwegs..
Ach ja ? Musiker ?
NumberFive
23.02.2006, 07:16
Musiker ?
CD-Player -> Notebook -> Michpult -> 2 x 1,5 KW
Alles Klar !?
bool CRNProtokoll::SetByteData(BYTE* Buffer,BYTE Len)
{
// Daten in den Stream schreiben und Maskieren
// Framen
BYTE x=0;
BYTE bLenAdd = 1;
m_bLowLevel[0] = CTL_C_STX;
for(x=0;x<Len;x++)
{
if((Buffer[x] & CTL_M_MASK) == CTL_C_BASE)
{
m_bLowLevel[x+bLenAdd] = CTL_C_PFX;
bLenAdd++;
m_bLowLevel[x+bLenAdd] = Buffer[x] | CTL_M_ADON;
}
else
{
m_bLowLevel[x+bLenAdd] = Buffer[x];
}
m_bTxBcc ^= Buffer[x];
if((x+bLenAdd+2) >= 1024)
{
//Mehr Buffer haben wir nicht
return false;
}
if(x == 127)
{
// Neuen Frame an fangen
// Das müssen wir noch prüfen
m_bLowLevel[x+bLenAdd] = m_bTxBcc;
m_bLowLevel[x+bLenAdd+1] = CTL_C_ETX;
m_bLowLevel[x+bLenAdd+2] = CTL_C_STX;
bLenAdd = bLenAdd+2;
m_bTxBcc = 0;
m_bFrameCount ++;
}
}
m_bLowLevel[x+bLenAdd] = m_bTxBcc;
m_bLowLevel[x+bLenAdd+1] = CTL_C_ETX;
m_bLength = Len+2+bLenAdd;
return true;
}
Und so sieht der aufruf dann aus
void CMain::SendBuffer(BYTE *buffer,int len)
{
// Daten zu sammenbauen und schicken
CRNProtokoll* pBuffer = new CRNProtokoll;
pBuffer->SetByteData(buffer,len);
// Wie lange ist das was wir senden müssen ?
len = pBuffer->GetLevel0(NULL);
BYTE* SendBuffer = new BYTE[len];
// Holen der daten ?
pBuffer->GetLevel0(SendBuffer);
CString csTrace;
csTrace.Format("Schreibe Daten %s",BinToTrace(SendBuffer,len));
TraceIt(csTrace);
m_clV24.WriteOut(SendBuffer,len);
delete SendBuffer;
delete pBuffer;
}
Gruß
..2 x 1,5 KW ..
Ja, das macht Krach.
Topic:
Schaut gut aus. Mit dem "Frame-Split" bei Überlängen kommen wir jetzt natürlich ein ein Terrain, wo wir noch nicht so recht durchdefiniert bzw. diskutiert haben.
Wenn du mich fragst, ich tät fürs Erste ganz einfach verweigern, wenn dir nettodaten > Max sind.
Das deckt den momentanen Bedarf sicher ohnehin ab.
Sind unsere anderen Kollegen eigentlich noch dabei ?
EDIT: Deine Mail ist grad angekommen.
Schau mal, vielleicht erspart es dir etwas Arbeit, so sieht meine Empfangsroutine aus (wird mit jedem über COM empfangenen Byte angesprungen)
Da kommen zwar ein paar Sachen vor, die kannst du so nicht anwenden, aber die Logik ist erkennbar
#define RXTX_M_MSG 1 // inside Frame
#define RXTX_M_PFX 2 // Prefix detected
//---------------------------------------------------------------------
int CSnifferDlg::SniffChan(ROV_RXTX* pRx, unsigned char bInChar)
{
if (!(pRx->iComFlg & RXTX_M_MSG))
{
if (bInChar == CTL_C_STX)
{
pRx->sBf.BufSet((char*)&pRx->sMsg, 0); // reset Buffer
pRx->iComFlg = RXTX_M_MSG;
pRx->iComBCC = 0;
}
}
else
{
if (pRx->iComFlg & RXTX_M_PFX)
{
pRx->sBf.BufWrChar(bInChar & ~CTL_M_ADON);
pRx->iComFlg &= ~RXTX_M_PFX;
pRx->iComBCC ^= (bInChar & ~CTL_M_ADON);
}
else
{
switch (bInChar)
{
case CTL_C_STX: // Start condition
pRx->sBf.BufSet((char*)&pRx->sMsg, 0);
pRx->iComFlg = RXTX_M_MSG;
pRx->iComBCC = 0;
break;
case CTL_C_PFX: // Prefix
pRx->iComFlg |= RXTX_M_PFX;
break;
case CTL_C_ETX: // End Condition
pRx->sBf.BufToRead(); // write -> to read
pRx->iComFlg &= ~RXTX_M_PFX;
pRx->iComFlg &= ~RXTX_M_MSG;
pRx->iComCnt++;
return(1); // Message present
break;
default:
pRx->sBf.BufWrChar(bInChar);
pRx->iComBCC ^= bInChar;
break;
}
}
}
return(0); // no message complete
}
Zum Testen kannst du übrigens einfach die RX-TX Leitungen des RS232 Kabels überbrücken, dann kriegst du deine eigenen Frames als Echo zurück, aber das weißt du ja
@Alle: Welche Arten von µC -Boards sind denn bei unserem Konsortium in Betrieb ?
Ich hab RNBFRA und was selbst gestricktes, auch mit mega32
...Sind unsere anderen Kollegen eigentlich noch dabei ? Na Klar !
Welche Arten von µC -Boards sind denn bei unserem Konsortium in Betrieb ?
1. RUG Warrior (68HC11)
2. ASURO
2. RN-Control
Sieh da, der Vogon !
µC Boards: Ich frag nämlich, um ev. Demos und Prototypes danach ausrichten zu können.
RN-Control bin ich ausreichend Informiert und hab Unterlagen, super.
ASURO Da sollt es auch ausreichend Info geben.
RUG Warrior ??? was ist das für ein Krieger ? Mal google-gucken nach 68HC11
EDIT: Na, haben wir ja schon. Welche Sprache sprichst du mit dem Gerät ?
Wegen meinem Museums Roboter von 1995 musst du nicht nachdenken.
Auf dem ist das RealTime-MultiTask-OS Interactive C. Das ist ein PCode Interpreter. Von den ersten Versionen konnte man noch den ASM-Source ziehen.
"Rug Warrior". The robot was originally developed at the Massachusetts Institute of Technology (MIT) for use in robotics courses.
Inspiration to Implementation was first published in 1993. It became an immediate best seller in the field of hobby robotics. In 1994 the Rug Warrior kits were made available to the public and they became the number one best selling kits ever.
Also, Geräte, die noch den Reichsadler aufgestempelt haben, haben schon geringere Priorität, denk ich
NumberFive
23.02.2006, 16:19
Also ich habe ein RN -Control und eine RN-Power.
Und ein epia aber da muß ich dann selbst programieren weil pc *g*
Das mit dem Zweiten telgramm ist in de hinsich drin das vom anweder ja jede meneg daten kommen können dann muß er das nicht auf teilen.
Kommt hal darauf an wie jetzt schicht zwei aus sieht dann baue ich das schon passend.
Mir währe das mit den adresse jetzt ganz recht dann könnte ich das tcp anfangen und die DLL.
0 Bytes per tcp wird lustig
@Picknik
Oh machts du doch selbst noch ein PC applikation ?
Meine gefällt dir wohl nicht.
Gruß
Dann denk ich, daß die Hauptzielgruppe wohl RN-Control und RNBFRA (marvin42x) sein könnte.
Wir brauchen ja bald irgendeinen Türken, mit dem auch die PC-Gurus testen können.
NumberFive
23.02.2006, 17:38
den letzeten post verstehe ich jetzt nicht ganz.
kannst du mein projekt eingendlich jetz compilieren ?
Source ist per Mail raus jetzt geht senden und empfangen.
Teste immer mit Hyperterminal auf ein anderen Rechner.
Mit text datei senden kann man viel machen nur 0 byte ist net so doll aber den rest kann gut testen. vor allem komm die bytes dann richtig geflogen als mit dampf.
Dann werde ich mal Multicast ein bauen.
Gruß
marvin42x
23.02.2006, 18:11
Ich leb hier in stiller Freude über das was passiert. Da ich den Thread nicht mit ah… und ohh… voll müllen will :-) halte ich gerne mal die Klappe wenn gerade die besseren am Werk sind.
Wenn man unten im Thread-Fenster das Auge anklickt (zeige Benutzer, die diesen Thread gesehen haben) ,NumberFive kennt das, ist unten im Fenster:
Sortierungs-Methode auswählen:
Dort wähle ich „zuletzt gesehen“
Und im daneben liegenden Feld:
Ordnung:
„absteigend“
Dann auf den Knopf daneben „sortieren“ drücken
Und ich weis wer wann zuletzt und wie oft am Thread teilnimmt.
„I’m allways near by“ würde mein alter ZEN-Meister sagen.
Netter Gruß aus der großen Stadt,
an alle die hier treu mitlesen
Ps.
wenn wir in Berlin die Alpen hätte wären die höher
NumberFive
23.02.2006, 18:33
Kleiner zwischen standt kann jetzt daten von PC1 an PC2 über RS232 und dann an PC3 per Multcast verschicken.
@marvin42x du programierst in VB richtig ?
wenn ja hast du schon mal ne com dll ein gebunden ?
Gruß
marvin42x
23.02.2006, 18:59
Nein, habe erst mit diesem Projekt damit begonnen, Würde aber gern schon mit probieren. Ich habe eine Familiäre Onlinehilfe zur Verfügung die mir über die Klippen hilft. Ich habe aber nichts zu bieten was Eurem Niveau entspricht.
Habe mein Mailkonto für Freunde sichtbar gemacht
Netter Gruß
Edit: Habe auch icq und Webseite sichtbar gemacht. Kannst Du mir sagen ob das Funktioniert hat?
Da werken ja alle wie die Bösen.
Ein "Türke" ist ein Programm, das so tut, als ob.
Ich zangle an der µC Seite auf quick & dirty eine Teststellung, die alle 1.5 sekunden einen "Broadcast" sendet (destination = 0)
auf der anderen seite läßt er sich ein paar Led's per kommando setzen. Dieses Kommando schickt ihm der PC jede sekunde mal.
Is mal für RNBFRA, muß mal sehen, welche Lämpchen man bei der RN-Control funkeln lassen kann.
Ich hab die comm-Rules und Definitionen genau eingehalten, sollte dann jeder als Spielpartner verwenden können.
Es tut schon, ein paar details, dann stell ich die SOurce & hex zur verfügung
So, mein Weib äußert Unmut, bis morgen dann, Kollegen !
(Den Opernball laß' ich heuer aus)
@PicNick:
Natürlich bin ich auch noch da, ich habe nur gerade nicht soviel Zeit, und coden will ich ja auch noch was ;-)
BTW: Danke für die Wiki-Seite, die ist eine wirklich gute Zusammenfassung.
Zwecks unterstützten Targets:
Ich würde mal Libraries in Bascom und C für die ATmega8 - ATmega32 anpeilen. Auf höherer Ebene dann Dienste speziell für RNBFRA und Asuro.
ciao,
Ragnar
NumberFive
25.02.2006, 15:17
Hallo,
ich muß wohl was verpasst haben wenn PicNick schon schreibe erschickt an detination 0 also broadcast ? Haben wir das schon gefiniert und ich habe es über lesen ?
Zur zeit versuche ich mich noch durch dieses Dokument zu qualen:
http://www.fgan.de/~elrob2006/29_11_05_elrob2006_rules.pdf
Spätestens Morgen komme ich wieder zum Programieren da ist meine Freudin länger im Stall und dann habe ich ein bisschen zeit.
@marvin42x
Ich sehen dein Icq nicht aber vielleicht bin ich auch nicht dein freund *g*
Gruß
..also broadcast ? Haben wir das schon..
Haben wird noch nicht ausdrücklich definiert, aber um zu testen, muß ich ja irgendwohin schicken. also laß ich destination frei/ (= NULL)
Ich denk' aber wenn wir nicht spezielle Frames definieren (könnten wir aber tun, da insbes. Sensoren recht gute Kundschaft für Broadcast wären, denn wem sollen sie schicken ?) ist NULL eine gute möglichkeit, gewissermaßen "wild-cards" zu setzen .
So, ich verschwind' wieder in der Bascom-Library
marvin42x
25.02.2006, 16:52
@NumberFive:
Mein lieber Freund *g*, er frisst keine Bindestriche, hatte die ICQ-NR original, mit Bindestrichen eingegeben. Jetzt müsste es gehen. Danke fürs Bescheid sagen.
Muss ich mich um einen Compiler für die Lib kümmern oder ist die dann von dir immer schon fertig kompiliert?
Netter Guß
NumberFive
25.02.2006, 18:12
Nein du kannst von mir auch alles kompiliert haben.
bei Picknick ist das nur ein problem weil die Firewall so scharf ein gestellt ist und exe frist weil ein Programm. wenn das bei dir nicht so ist kann. ich dir auch alles Compiliert schicken kein Thema.
Muß mir mal webspace suchen dann kann ich es auch hoch laden un jeder kann es sich selber ziehen.
gruß
... ein problem weil die Firewall so scharf ein gestellt ist und exe frist weil ein Programm. Ist bei Outlook mit ServiePack die Stadardeinstellung. Besser als ZIP senden oder die Extension .exe .com usw änder.
Muß mir mal webspace suchen .... Probier den doch mal: http://reg.imageshack.us/content.php?page=register
NumberFive
25.02.2006, 19:21
@Vogon käme nie auf die Idee ein ex un gepackt zu schicken aber zips werden bei Picknick aus gepackt und so er kann es kommt kann nicht bei im an spricht er sieht nicht mal die Mail.
das mit den anhängen kann auch ausschalten.
Mein freudin hat noch platz und traffic frei auf ihrer hp mal sehen ob das klappt. vielleicht schaffe ich es nach das noch zu checken.
@alle
Wohlen wir einfach mal definieren das die ersten 2 Bytes die Adresse sind ?
das macht dann 65000 adresse und 0 ist die Adresse an alle ?
Wenn wir das so machen hätte ich gleich ein filter das die dll nicht alles melden nur das für die eingene und die allegemein adresse.
WORD CRNProtokoll::GetAdresse()
{
// Adresse aus den daten fischen
WORD res = 0;
memcpy(&res,&m_bLowLevel[1],2);
}
Einfach so habe ich das gemeint
Gruß
Hallo, Männer. Hab jetzt die Bascom-Grundversion soweit, daß man damit was machen kann.
Es wird nun wirklich virulent, wie wir die Sache mit Empfangs- und Absendeadressen handhaben.
Es sind drei (logische) Komponenten unterzubringen:
Sys: Zielrechner (nicht zu verwechseln mit den adressen auf Level-0 bei Bus-verbindungen a la I2C) Mit diesem Sys kann ev. auch geroutet werden.
Ziel-Klasse: Welche Art Gerät
Ident-# eindeutig innerhalb der Klasse.
Desgleichen gilt für die Source- also Rücksendeadresse
Wie sind denn da die Meinungen im Moment ?
marvin42x
27.02.2006, 12:07
@ PicNick:
Zwischenfrage:
Wiso eventuell geroutet?
Ich hatte es so verstanden das ab Server TCP/IP.
Was für mein Verständnis bedeutet das selbst auf dem unmittelbaren PC "genetzwerkt" wird?
Ziel-Klasse und Ident habe ich nicht verstanden. Sind damit Einheiten auf PCs gemeint oder die Units innerhalb eines Robi-Betriebssystem?
Im Moment haben wir, glaube ich zu verstehen, noch nicht richtig über die Pflichtenverteilung der PC-Komponenten(Server, PC-Module, Webserver, Applicationsserver) gesprochen. Ich sehe zurzeit einen Server auf der seriellen sitzen, der „dann irgendwie was weitergibt“
Weitergeben wäre für mein Verständnis TCP/IP
Daraus folgt, der Server muss dem Robi eine Eindeutige Adresse verschaffen. Er muss sogar den Units auf dem Robi (zB. Kompass oder so) eine eindeutige Adresse verschaffen.
Er selbst muss auch eine eindeutige Adresse haben. Also eine diesmal komplette Absenderadresse.
Dann muss noch jemand entscheiden wer das bekommen soll. Jetzt erstmal Broadcast.
Wenn ich mich in meiner Unerfahrenheit hier verrannt habe möge man mir das nachsehen.
Netter Gruß
Nun, auch ein µC kann potentiell routen, wenn z.B. der adressierte Rechner nur über I2C oder einen anderen Bus zu erreichen ist. Oder denk an die RNBFRA mit dem CoProzessor.
Wie gesagt, da bewegen wir uns noch eine Ebene über dem Level-0, also der "vermittlungschicht". Egal, ob ein Frame von IP oder vom COM-Port kommt, es hat eine (applikations-) Ziel- und Absenderadresse.
Wenn die adressierte Applikation auf dem lokalen Rechner ist, dann macht diese weiter und tut den Teufel was. Wenn aber nicht, geht's über IP, I2C, RS232 oder Brieftauben weiter.
Klassen und Ident:
Klassen sind Geräte-Typen. Auf einem µC eben AD-Wandler, Kompaß, SF08, Stepper- oder DC Motoren.
Auf dem PC können das Slider, Progress-Bar, Radio-Buttons oder checkboxen oder was kompliziertes wie eine Radar-anzeige oder sonst ein graphisches Zeugs sein.
Die verhalten sich an sich gleich und werden von den gleichen Programmteilen behandelt, daher "Klasse"
Gibt es von einer Klasse mehrere Ausprägungen (µC:linker-rechter Stepper, PC: Graphische Anzeige 1-29) dann haben sie dieselbe Klasse, aber innerhalb dessen "Ident" 1-n)
Die PC-Klasse/Ident "Slider-4" wird ihren Wert an die µC-Klasse DC-Motor-1 schicken und "Slider-5" wird ihren Wert an die µC-Klasse DC-Motor-2
die µC Klasse/Ident ADC 1-8 werden auf einem PC Abnehmer finden z.B. Progress-bar 1-8.
Wie eben der Stellwert von so einem Slider seinen Motor findet, ist eben Aufgabe der Netzwerkes.
Das sind trivial-Beispiele, die aber z.B. bei einer Robby-Remote-Control absolut der Praxis entsprechen.
Komplexere Sachen, wie eine ODOMETRIE-Klasse, wirds dagen wohl nur einmal geben, dafür kriegt die aber daten von mehrern Sensoren und bedient auch mehrere Geräte.
Ob dazwischen die Daten über http dreimal auf ASCII und zurück konvertiert werden, ist dann eins drauf, ändert aber nix prinzipielles.
@alle:
Bei der Implementierung meiner Schicht 1 ist mir noch ein Fehler im Protokoll aufgefallen.
Unser BCC kann den Wert der Kontrollzeichen annehmen. Damit gibt es bestimmte Nachrichten,
die nicht übertragen werden können. Ich schlage deshalb vor, dem BCC auf die Ausgangsdaten
anzuwenden und dann erst zu prefixed. Damit wird der BCC bei Bedarf auch geprefixed.
Zur den Adressen:
@PicNick: Deine Idee mit den Zielklassen finde ich zwar relativ interessant, ich glaube
da vermischen sich aber Schicht 2 und Schicht 4. Meiner Meinung nach sollte die
Schicht 2 nur zwischen beliebigen Adressen vermitteln, unabhängig davon welche Klasse bzw.
welchen Typ diese Knoten haben.
Die Klasse eines Knotens würde ich erst auf Schicht 4 einführen, daran hängt schon relativ
viel highlevel-Bedeutung. Ich hatte da auch eher an 'Dienste' gedacht. z.B. könnte ein
Knoten mit einer bestimmten Adresse den Dienst "Motorcontrol" anbieten, während ein anderer
die Dienste "Bumper", "Infrarotsensoren" und "US-Sensoren" anbietet. Ein Knoten kann also
mehrere Dienste anbieten und die Dienste haben erstmal nichts mit den Adressen zu tun.
@NumberFive: Die Idee mit den 2 Bytes für die Adresse finde ich gut, 8-bit Adressen sind
zu wenig, 24-bit Adressen sind zu lang (schwieriger zu routen, länger zu übertragen). Ich
hatte hier schonmal einen Vorschlag gemacht, den ich jetzt nochmal aufgreifen will:
2 Bytes Adressen, davon 1 Byte "Netz#", 1 Byte "Knoten#"
Für beide Bytes gilt: 0=Broadcast, entweder "0.x" innerhalb des Netzes "x"
oder "0.0" an alle Knoten insgesamt. 255=reserviert.
Wie ist das jetzt mit dem Routing ?
Ich habe mal ein Bild gemalt, wie ich mir das vorstelle. Alles, was innerhalb der RNcom
Wolke ist, hat eine RNcom Adresse und wird als RNcom geroutet. Innerhalb von RNcom gibt
es verschiedene Medien. Eines davon ist LAN. Dabei werden über vorher konfigurierte
IP-Verbindungen RN-Frames übertragen. Geroutet wird dabei eigentlich zweimal - einmal
auf RNcom Ebene (auf die IP-Verbindung), ein zweites Mal das IP-Paket innerhalb des
IP-Netzes. Eventuell wird am Empfänger dann nochmal auf RNcom Ebene geroutet.
Ganz konkret bedeutet das: ein RN-Com Knoten kann nicht direkt mit einer
bestimmten IP-Adresse kommunizieren. Ein Programm kann aber z.B. auf einem bestimmten
Port lauschen und dort eine RNcom Verbindung anbieten. Um nun eine GUI mit diesem Rechner
zu verbinden konfiguriert der User seine GUI automatisch die IP-Verbindung aufzubauen.
Der RNcom Router stellt dann fest, welche RNcom Netze hinter der neuen Verbindung stehen
und routet dann automatisch.
Und zum Schluß noch was ganz anderes:
Lasst uns dem Kind doch noch einen Namen geben. Ich würde die Schichten 1-3 (den ganzen
Kommunikationskram) gerne unter einem Namen zusammenfassen (z.B. RNcom oder uCcom). Und
dann für die Schicht 4 einen Namen der mehr auf die Intelligenz bzw. die Softwaremodule
anspielt.
BTW: Ich würde erst gerne die Schichten 1-3 festzurren bevor wir über Schicht 4 spekulieren.
ciao,
Ragnar
NumberFive
28.02.2006, 06:28
Grund sätzlich finde ich das was ragnar geschrieben gut auch das bild gefällt mir. Nur warum auf Big Bots nur Linux laufen darf verstehe ich nicht auf mein wird windows laufen.
Reichen uns 253 Konten auf den Sub Systemen ? Auf einem PC (welches Betriebs system auch immer) Reichen sicher 253 Programme die auf das Netzzugreifen können aber am AVR ? kommt es sicher auf die Defintion an was man noch als Konten ansprechen kann. Den inhalt würde ich gerne auch noch etwas weiterhinten definieren. Wobei ich mich gerade fragen ob die defintion als Slider X oder so was wirklich die Richtige ist ich denke die Aufteilung nach was ist besser also Sharp mit entferungs angabe in cm Motorcontrol mit werten 0-255 für den Speed und ein byte für die Richtung.
Und so weiter. Ob die darstellung dann als Silder oder sonst was ist sollte der GUI überlassen bleiben.
Ich werde die dll und den exe server (SerialServer) noch so um bauen das es mit Multicast und windows tut muß leider noch ein zwischen schicht ein ziehen da windows nur eine programm erlaubt auf dem Multicaststream zu hören. Aber ich habe da schon eine Idee wie ich das löse. Kann mir jemand sagen ob das unter linux genauso ist ?
Leider bin ich durch eine Magendam grippe etwas geschächt zur zeit so das der Output nicht ganz so hoch wie ich das gerne hätte.
Ansonsten habe ich echt das gefühl es geht vorwärts und in die Richtige richtung. Hat durch zu fall jedmand das dokument gelesen von den ich den Link gepostet habe ?
Gehen ein Namen habe ich auch nix.
Werden nachher auch mal ein bild malen wie ich es Programmiert habe bzw. wie ich es bis jetzt relaisiert habe.
Soll ich in die exe so ein dauer sende Funktion einbauen die betimmte an zahl von telegramme immer im kreis sendet ?
Gruß
Unser BCC kann den Wert der Kontrollzeichen annehmen. Damit gibt es bestimmte Nachrichten, die nicht übertragen werden können.
??? war da nicht was mit bytestuffing ? Wieso sollte bcc eine Ausnahme sein ?
NumberFive
28.02.2006, 07:30
So jetzt habe ich mal ein bild gemalt
http://mine-robo.homepage.t-online.de/images/Generell.jpg
marvin42x
28.02.2006, 08:10
Einige Testfunktionalitäten im Server wäre sicher, besonders am Anfang, sehr nützlich.
253/253 Programme/Konten müssten aus meiner Sicht für den Großteil der Aufgaben ausreichen. Das unter dem Hintergrund das Dieses Protokoll nicht zwingend das einzige bleibt. Sprich: Zukunftsoption Protokollaushandelung.
Ich habe auch nichts gegen einen Namen für das Kind.
RN-com macht sich doch ganz gut.
Das Dokument habe ich quer gelesen. Für die Sache braucht man eine gute Software ;-)
ragnars Zeichnung trifft meine Vorstellung, soweit ich das im Moment sehen kann.
@NumberFive: Gute Besserung.
@ragnar: Ich war wahrscheinlich mißverständlich. Natürlich hat die Vermittlung keine Einsicht in die Bedeutung der Adressangaben, d.h. die weiß natürlich nix von Klassen und so Zeugs.
Unser BCC kann den Wert der Kontrollzeichen annehmen. Damit gibt es bestimmte Nachrichten, die nicht übertragen werden können.
??? war da nicht was mit bytestuffing ? Wieso sollte bcc eine Ausnahme sein ?
Stimmt natürlich. Ich hatte da noch was falsches in Erinnerung. Der BCC läuft also nur über die reinen Daten ohne jegliche Kontrollzeichen.
@PicNick:
BTW, ich habe mir gerade deinen Empfangscode von Seite 9 angeschaut und sehe da, dass du die Zeichen mit Prefix immer als "char &~ MASK" überträgst. Korrigier mich bitte wenn ich falsch liege: Das ist doch etwas anderes als eine Addition und wenn es geht ist es ein Spezialfall?
@NumberFive:
Noch eine Anmerkung zu deinem Bild: Die Netze müssen nicht zwingend an einzelne Rechner gebunden sein. Theoretisch kann eine Adresse überall liegen und ein Netz kann sich auch über mehrere Rechner verteilen. Genauso kann ein Rechner mehrere Netze beinhalten. Was praktisch alles möglich bzw. effizient ist, hängt nur von den Routern ab.
@PicNick:
Kannst du nicht mal deinen Schicht1 Code posten ? Ich würde meinen mal gerne testen.
ciao,
Ragnar
marvin42x
28.02.2006, 20:37
@PicNick: Danke für die neue Doku, mit den klaren Dokus im RN-Wissen kann man schön gezielt die Probleme angehen.
Da hat die Unstrittigkeitsbewegung wieder Terrain zur Besiedlung freigelegt.
https://www.roboternetz.de/wissen/index.php/Network_Controller/PC_Vermittlung
Netter Gruß aus der vorlauten Stadt
Gerade Publikumsfertig geworden: Eine Schicht 1 UART Echo Anwendung für den Mega8. Empfängt den eingehenden Frame nach unserem UART-Protokoll, packt ihn aus und wieder ein und schickt ihn wieder zurück.
Den passenden JavaCode auf PC-Seite gibts demnächst mal.
ciao,
Ragnar
"char &~ MASK"
Du hast recht, das ist keine direkte addition, sondern durch die relevanten Zeichen mit einen OR / bzw AND~ dargestellt.
Da es möglich war, wollte ich der decode-Subtraction ausweichen, da man sonst auf signed /unsigned aufpassen muss (A8x ist ja negativ)
dadurch ist es aber ggf. auch leichter, ein HW-Lösung zu machen.
Wie gesagt, solang die CTL-Zeichen sind, wie sie sind, geht es auch so.
NumberFive
01.03.2006, 12:36
Ich weiß interessiert nicht so brennen aber wer mal den mal Icons ?
Ich kann so was nicht wirklich gut.
Gruß
Bei den Sachen, die ich mit C++ mach, hab ich einfach mit Text in allen Icongrößen "RN" reingeschrieben. Einfach mal so, damit irgendwas zur Unterscheidung da is.
Aber nachgedacht hab' ich darüber noch nicht. In die paar Pixel wird wohl nix künstlerisch wertvolles reinpassen, fürcht' ich.
NumberFive
01.03.2006, 13:50
das bilchen was du neben mein Post's siehts ist das Icon meiner MC sachen.
Mal sehen vielleicht findet sich ja jemand der aus 32x32 Pixel was zaubern kann.
Gruß
@ragnar: als Initiator des "aufaddierens beim stuffen": Wir könnten statt OR oder addieren einfach ein XOR FF machen. Das hat den gleichen Effekt und weicht bei allen Steuerzeichen jeder möglichen Schwierigkeit weiträumig aus
marvin42x
02.03.2006, 12:09
Zwischenfrage:
Auf der Nutzerebene werden Datenbanken beteiligt sein. Im Intranet sowie im Internet. Der Anspruch an die Datenbanken kann beträchtliche Ausmaße annehmen.
Stellt dieser Punkt besondere Anforderungen die wir auf den unteren Ebenen der Kommunikation schon berücksichtigen müssen?
Mir fehlt leider der Überblick um das bewerten zu können.
Noch eine forumstechnische Frage am Rande:
Gibt es eine Möglichkeit, wenn ein Wissensbeitrag verändert wird, nur die Änderung zu sehen ohne alles noch mal zu lesen?
Netter Gruß
Wissensbeiträge:
Naja, theoretisch "letzte Änderung"---> "Unterschied"
Zwischen Datenbank und Netz liegt immer eine Applikation, die dann zuständig ist, auf welche Art die anderen Netzteilnehmer auf die Datenbank hinkönnen. Die datenbank selbst ist für die anderen transparent (nicht sichtbar).
Aus Sicht unseres RN-Netzes gibt' da einfach nur irgendeine Applikation, die furchtbar schlau ist und sich scheinbar sehr viel merken kann.
marvin42x
02.03.2006, 13:20
@PicNick:
zu Wissensbeiträge: Danke , da habe ich den Wald vor lauter Bäumen nicht gesehen.
Netter Gruß
NumberFive
02.03.2006, 13:52
@marvin42x
was für dein DB meinst du Mysql könnte ich auf die schnelle was bauen aber ohne weiter protokoll beschreibung witzlos.
@alle:
So ich habe es geschaft das Netzläuft bei mir. Klar sind noch nicht alle sachen die ich mir so vorstelle drin aber ich kann jede menge sachen machen.
Es gibt drei teile :
RNComNetworkLayer.exe Das teil kümmert sich darum das die daten verteilt werden. und wird per ini konfiguriert.
RNProtClient.dll : das ist der Highlevel zugang zu protokoll um so mehr schichten definiert sind um so einfach wird es dann hier kommt die abbildung dann rein.
SerialServer.exe: das Teil kümmert sich darum das die Daten an die Seriale gehen und von da gelesen werden.
Ich gehe davon aus das BYTE 1 oder BYTE 2 also das BYTE das nach den anfang kommt das Network ist und das dann folgende die Adresse ist.
Im SerialServer stellt man ein welches netz die Serial hat alles was für dieses netz kommt oder für das netz 0 wird raus geschickt.
Damit ist 0,0 die Broadcastadresse die an alle schickt.
Ein echter protokoll fehler ist noch drin das Prüfsummen byte wird nicht maskiert.
Man kann zur zeit keine Zwei gleichen telegramme hintereinander schicken. da ich hier im netz so denke ich noch ein problem habe und die doppelten nur so filter kann. (Viele rechner mit zwei netzwerkkarten).
der source geht an Picknick und ich hoffe das ich euch gleich noch ein link legen kann für die Binarys.
Ich hoffe es ist alles zu verstehen.
Gruß
marvin42x
02.03.2006, 15:26
@NumberFive: Danke Dir das Thema Datenbanken werde ich aber in diesem Thread nicht vertiefen. Das ist heftig genug für einen eigenen Thread. und wie Du schon sagst macht das erst Sinn wenn die anderen Sachen stehen.
Netter Gruß
NumberFive
02.03.2006, 16:47
so ich hoffe das die daten dann auch dem nächst im dowload bereicht zu sehen sind habe Frank mal ne PN geschickt des wegen
NumberFive
02.03.2006, 18:19
So jetzt habe ich mal ein Readme runter getippt damit
so hoffe ich es auch jeder zu laufen bringt:
Readme zu Numberfive's RNCom / RN-Protoll Sachen
Installation:
Alle Programmteile in ein Beliebiges VerZeichnis Packen.
RNComNetworkLayer Einmal mit Parameter -RegServer starten da sollte
dann ein MessageBox Kommen und er sich sofort wieder Beenden.
(Eintragen Regestry Windows).
die RNProtClient.dll mußt man mit dem programm regsvr32 (gehört zu windows)
in die regestry eintragen. Also regsvr32 RNProtClient.dll
Es werden nach dem Ersten Starten dann Ini Files erzeugt und die Muß
man dann anpassen.
Was macht was:
RNProtClient.dll Ist die Dll (Com-Objekt) Wo einem die Arbeit mit dem Protokoll
Abgenommen Wird. (Später)
Also Programme die das Protokoll Implementieren wollen müssen Hier drauf.
RNComNetworkLayer.exe das Programm händelt die Protokoll verschickung über
TCP Multicast. Com ExeServer SINGLETON
SerialServer.exe kümmert sich um die Daten/Protokoll umstetzung von TCP
nach Serial und umgekehrt.
Die RNComNetwork.ini
[RNComNetwork]
OwnIP=192.168.2.1 // Rechner IP wo das Programm läuft
MultiCastIP=224.0.0.0 // Die Multicast IP im Netz wenn man sich damit nicht aus kennt einfach so lassen den es gehen nicht alle adresse
MultiCastPort=44000 // Wenn der Port nicht für was anders gebraucht wir so lassen
Die SerialServer.ini
[SerialServer]
Comport=COM1 // Der port an dem der AVR Hängt
Baud=9600 // BAud rate der Rest ist Hard 8n1
ComNetwort=1 // Netz in dem der AVR Ist siehe RNCom definitionen
Das User Interface (RNProtClient.dll):
!! Achtung dieses Interface wir Sich noch Stark ändert den es soll Später das
bentzuen des Protokolls ganz einfach machen !!
Die Events:
[id(1), helpstring("Methode TraceIt")] HRESULT TraceIt(BSTR TraceTxt);
Ist eingendlich nicht so Wichtig aber hier sieht man was untendrunter so passiert
[id(2), helpstring("Methode NewData")] HRESULT NewData(LONG Network,LONG Adresse,LONG ID);
Wol das wichtigte Überhaupt ES sind neue daten da.
Netzwork und adresse wird hier mit geben damit man gleich weiß ist Broadcast oder für
mich
Die Proceduren:
[id(1), helpstring("Methode Init")] HRESULT Init();
das ist die Funktion um zu sagen nun kanns los gehen ich bin fertig
[id(3), helpstring("Methode SetOwnRNAdresse")] HRESULT SetOwnRNAdresse(LONG Adresse);
das ist meine Adresse es ist ein Long weil VB nix anders sauber erkennt
aber es sind nur werte zwischen 1 und 255 Zulässig
[id(4), helpstring("Methode GetDataAsString")] HRESULT GetDataAsString(LONG ID,[out, retval] BSTR *Data);
Hier kann man sich die daten holen als String daten die man normal nicht darstellen kann
werden in der Form <wert> übergeben also ein 0 byte sieht so aus <00>
[id(5), helpstring("Methode SetOwnRNNetwork")] HRESULT SetOwnRNNetwork(LONG Network);
das ist meine Netz zu dem ich gehöre es ist ein Long weil VB nix anders sauber erkennt
aber es sind nur werte zwischen 1 und 255 Zulässig
[id(6), helpstring("Methode SendString")] HRESULT SendString(LONG Network,LONG Adresse,BSTR bsData);
Hier mit Kann man daten Senden
Gleiches Spiel wie oben ein 0 Byte sendet man so <00> und ein < mit <<
Das habe ich so gemacht damit zur zeit mal alles testen kann Später muß man das Hofftlich nicht mehr benutzen
marvin42x
02.03.2006, 20:53
So, habe Das RN-Com System von NumberFive ausprobiert damit wir das auch mal auf einem fremden System überprüft haben.
1 PC
über Router
1Notebook
Außer das ich vergessen habe den Netzkabelstecker einzustecken, ähemm….läuft alles wie es soll, bin richtig begeistert. Broadcast vorwärts rückwärts, hin und her :-) .
Macht richtig Spaß.
Ich habe die DLL jetzt ins Window system32 Ordner kopiert, ich hoffe das war richtig.
Die MulticastIP habe ich nicht geändert, nur die jeweilige RechnerIP ins ini-file eingetragen.
Die gesamte Einrichtung ist für einen Ungeübten etwas fummelig aber mit NumberFives Anleitung geht das einwandfrei und wir wollen ja hier erstmal nur testen.
Ich habe beim Start die Reihenfolge: erst RNComNetworkLayer.exe dann Serialserver.exe und dazu dann noch RNProtVB.exe eingehalten.
Nettes Broadcasting
marvin42x
04.03.2006, 11:01
Frage:
Wie sind die Vorstellungen bei dem konkreten Beispiel-Komplett-System auf Mega32-Basis, generell.
Sind Werten die der Mikro schickt vom Mikro linearisiert, umgerechnet, mit offset, oder wie auch immer oder wird er nur nackt senden?
Können wir eine vorläufige Beschreibung der zu erwartenden Werte die gesendet oder empfangen werden erstellen?
Dann braucht z.B. UlrichC sich nicht zu langweilen und auch andere High-Level-Ansätze können schon mal ihre Startlöcher graben.
Und hier mal ein Vorschlag zur Vermittlung, der nur als Einstieg gemeint ist.
Routing/Dispatcher:
PicNick hat im Wissensbereich die Frage der Listen/Tabellen bereits Skizziert.
https://www.roboternetz.de/wissen/index.php/Network_Controller/PC_Vermittlung
Das was dort steht scheint mir sehr konstruktiv, folgerichtig und unstrittig.
Wenn sich dort noch,, oder hier im Thread, von irgend jemand, ein strittiges Beispielsweise config-file einfinden könnte?
Über den vorläufigen Aufbau und die Regeln der ini-files müsste aus meiner Sicht als nächstes Einigkeit herrschen.
Ich könnte mir vorstellen, dass wir dafür Textdateien nehmen.
Das hätte den Vorteil, dass dort von Hand als auch vom Programm jederzeit editiert werden kann.
Es müssten mindestens 2 ini-file Typen sein:
1 Adressen
2 Teilnehmer-Config (Robi,GUI, Logger, usw.)
Es sollten meiner Meinung nach Kommentarzeilen möglich sein die durch ein Sonderzeichen markiert sind z.B. (#)
Das würde ich mir für alle Dateien dieses Typs wünschen (hilft den Anfängern)
Adressen:
Die Robis haben im ini-file Klartextnamen und ein Äquivalent Binär?
Die Komponenten von Robi haben im ini-file Klartextnamen und ein Äquivalent Binär?
Teilnehmer-Config:
1 Komandobeschreibung:
Hier steht welche Kommandos Robi kann und in welcher Form er sie erwartet.
2 Werte:
Hier steht welche Werte Robi senden kann und wie die aussehen und was sie bedeuten.
Zusammengefasst:
Das ini-file hat einen Namen
Das ini-file ist eine Textdatei
Das ini-file hat Komentarzeilen
Das ini-file hat Rubriken:
Das ini-file muss ganz oder teilweise versand fähig sein.
Wie gesagt.
Dies hier ist nicht die Lösung sondern eine Provokation :-)
Netter Gruß
@PicNick:
Statt der Addition können wir gerne auch bitweise Negation (XOR 0xFF) verwenden. Du kannst
aber auch auf ein char (signed) jederzeit 8 addieren und auch bekommst trotzdem ein richtiges
Ergebnis (-128 + 1 = 0). Solange deine Variable 8 bit hat funktioniert die Addition unabhängig
von signed oder unsigned.
@PicNick:
Betreffend des von dir beschriebenen Routings einige Fragen:
1.) Wie wird das 'Nack' mit der verworfenen Nachricht assoziiert? Oder wird das Nack
einfach so an den Empfänger zurückgeschickt? Wenn ja, was kann der Empfänger mit dieser
Information anfangen wenn er sie nicht einer ausgegangenen Nachricht zuordnen kann?
Worauf ich hinauswill: 'Nack' macht meiner Meinung nach nur am lokalen Router sinn, wo der
Router direkt auf das Absenden reagieren kann. Schau dir mal IP an, da ists auch nicht anders.
Ein 'No Route to Host' bekommst du nur, wenn dein lokaler Router nicht weis wohin mit der
Nachricht. Ist die IP beim Ziel nicht bekannt, dann gehts stillschweigend schief.
2.) (aus Anforderungen/uController): Wie soll der uC eine Empfängeradresse für z.B. Sensordaten finden ?
Prinzipiell per Broadcast zu senden verschwendet IMHO Ressourcen, das Paket wird ja auch an jeden
anderen uC geschickt. Besser wäre eine Registrierung des Empfängers beim uC. Der Client registriert
also seine Adresse beim uC und jedesmal wenn der uC Daten generiert werden diese an alle registrierten
Adressen verschickt.
Prinzipiell ist das aber sowieso mal kein Problem der Routingschicht.
3.) DNS ist gute Idee, aber fürs Routing auch nicht wichtig.
4.) Wie sollen die Routingtabellen aufgebaut bzw. synchronisiert werden?
@NumberFive:
1.) Kannst du bitte mal genau beschreiben, was dein Programm alles kann? Am besten aus Sicht der
jeweiligen Schichten.
2.) Wie überträgst du die Nachrichten übers LAN?
3.) Gibts deine Programme auch als Binary? Ich habe gerade keinen Compiler greifbar und wills auch
mal ausprobieren.
4.) Welches Nachrichtenformat für Schicht2 verwendest du? Welche Adressen?
@Alle: Wer hat jetzt alles eine Implementierung der Schicht1-UART mit der ich meinen
Schicht1-UART testen kann?
@Alle:
Als nächstes sollten wir verbindlich festlegen, welche Nachrichten wir auf Level2 (Routing)
brauchen. (Adressformat, dynamisches Routing, ...)
@marvin42:
Ini-Files und anders sind implementierungsspezifisch und werden wohl nicht Standardisierbar sein.
Ragnar
Jetzt hab' ich grad' einen Roman geschrieben, da bin ich rausgeflogen, super.
Add/XOR Mit gefällt XOR FF schon sehr. Aber ich tät sagen, lassen wir es mal, wie's ist. ( + 16 / 0x10 )
NAK: klaro, Rücksende-adressen ohne unique Msg-Referenz geben nix her, wenn der Absender mehrer Nachrichten am Laufen hat. Manche haben aber nur einen Partner, da ist jedes NAK genauso eindeutig.
Sprich: über den genauen Aufbau von Sende-Rücksendeadressen sollten wir uns bald klar werden.
NAK lokal/router etc. : Im möcht IP als Transport-Büffel für die PCs in unserem Netzwerk haben. Wenn irgendwo ein I2C gerät krepiert, dann soll das jeder im RN-Netz auch wissen können.
TEST: Welche Plattform brauchst du ? PC ? µC ?
Tabellenaufbau: Wenn auf einem Rechner eine Applikation gestartet wird, muß sie sich ja zu unserem Netzwerk connecten, vorher kann er ja nich kriegen oder senden. Lokal entsteht so eine Tabelle also ziemlich automatisch/elektrisch. Dieser Rechner verteilt nun seine Zu- oder Abgänge von Applikationen (sprich adressen) an die anderen (Routing) Rechner.
Wenn es ohnehin nur einen Central-Routing-Node gibt, entfällt das Verteilen natürlich.
D.h. ("INI-File") Jeder Teilnehmer weiss, wer er ist. Jeder Rechner weiss, wo und wie er seine(n) Routing-Rechner erreichen kann. (IP, Port-#).
Im Prinzip ist jeder Router, der mehr als ein Level-0 Modul hat
Und noch ein's: Technisch gäbe es keinen Grund, Adressfelder unbedingt mit fixer Länge auszuführen. Ich weiß aber nicht, wie gut VB oder JAVA mit variablen Feldlängen zurechtkommen ?
PS: eine (optionale) Messagereferenz kann man der Absender-adresse zuordnen, aber man kann das auch als eigenständiges Attribut einer Message sehen.
NumberFive
05.03.2006, 16:05
www.i-do-more.de/mine-robo/download/RN-Protokoll.zip
hier gibts die Binarys wollte den Link zwar nicht so officell machen Frank scheint im Moment auch keine Zeit zu haben da im Downloadbereich mein Posting noch nicht auftaucht.
Ich finde schon das die Adresse ein Fixe Länge haben sollten sonst müssen wir wieder ein trennzeichen aus machen. Für VB und auch java würde jeweils ein DLL an bieten damit ersten schneller geht bei anbinden und wir normalfall im unter grund was ändern können ohne das gleich die Applikationen geändert werden müssen.
So wir müssen und glaube ich mal einig werden wo welche Schichten an fangen bzw aufhören und wo wir dan fangen zu zählen Level0 oder Level1.
Ein Level2 habe ich (noch nicht) in mein Programm integiert weil ich alles im nach hinein nicht wieder ändern wohlte. Bis auf die Defintion das Byte 1 und Byte 2 Netz und Adresse sind ist alles so wie es bis jetzt hier definiert worden ist.
Wie Funktioniert es:
SerialServer: Hört Ständig auf dem Eingestellten Comport und prüft die daten auf dem Level0 mit Prüsumme wurde ein Telegram als richtig erkannt wird es an die Netzschicht (RNComNetworkLayer.exe) weiter geben.
RNComNetworkLayer: macht nichts Anderes als Auf der ein stellten Multicast Adresse / Port zu hören und zu senden.
RNProtClient.dll: Verbindet sich mit dem
RNComNetworkLayer auf der Einen Seite und mit dem Client Programm auf der anderen Seite. Hier ist wie im Serial server das Protokoll dir wie es hier bis jetzt definiert wurde.
Ablauf :
Com X >> SerialServer >> Protokoll Prüfung auf anfang Ende Prüsumme >> NetzwerkLayer >> Clientdll >> Protokoll prüfung >>Suchen ist der Empfänger bei mir ? ja Melden und speicher des Telegrams >> Client kann sich die Daten holen.
Für die Prüfung ob der Client bei mir ist habe ich das mit der adresse und dem Netz Implemiert. damit nicht der Client entscheiden muß wann er was an nimmt und wann nicht.
Alles was für ein Bestimmtes Netzankommt (Inifile SerialServer) wird auf der Com Ausgeben. Ok bei mein Impelmetierung gibt es immer mindestens zwei Netze sonst besteht die Gefahr wenn PC Programm sehr viele telegramme Austauschnen das der AVR der per RS 232 an gebunden ist zu kochen beginnt. Es währe hier sich auch kein Thema entweder zu enstellen oder Dynamisch adresse auf der Com Seite auf zu bauen (Router) damit nicht alles rüber geht das ist dann sache der weiteren Definition.
wenn mal die Verbindung auf die RS232 nicht braucht funktioniert das ganze natürlich auch ohne der Serial server.
Man kann also mit der Software so wie sie jetzt ist Pratisch daten im Netz (PC Lan) wie auch an die Seriale Schicken die Seriale muß sich aber nicht auf dem rechner befinden wo man das Telegramm abschickt.
Ich habe das interface der DLL als Text oder String interface ausgelegt damit es keine Problem in der Sprachen gibt. Aber das habe ich ja weiter oben schon beschrieben.
Ich bin beim Programmieren darauf gekommen das wir das TCP nicht lesbar machen müssen den wenn die DLL da ist sollte es kein problem sein seine Anwendung anzu binden. Durch die verwendung von Multicast gehen ich auch einem Problem aus dem weg nämlich die Ganze Port konfigurtion und solche sachen. Da ist die Erfahrung von der MC/Simirs das mit den Ports und so ist für viele nicht so einfach zu verstehen. Ich brauche so auch keine Routing informationen zu mindestens nicht auf der PC Seite.
Ich weiß in der Linux welt gibt es kein dll aber hier gibt es so files die in meinen Augen genauso Funktionieren.
OK die Netzlast ist etwas höher da alle das Telegram bekommen auch wenn es auf dem PC keinen Abnehmer dafür gibt. Aber ich denke das wir im Nomal fall eh nicht mehr als vielleicht 3 PC's in dem Netz haben.
ich hätte gerne im Level1 oder level2 gerne ein Zahl (MSG ID) die immer erhöht wird dann könnte ich das Nack selbst bauen und die Applikation bekämme dann die Information konnte zu gestellt werden oder nicht und weiß auch noch welches Telegramm es war. Also 0 - 255 wenn wir oben sind fangen wir wieder bei 0 an. Das Sollte in meinen Augen reichen.
Oh mann jetzt habe ich aber ordenlich was getipp verteht man das Überhaupt ? Sind alle Fragen beseitigt ?
@No-5: Nach der Beschreibung würde ich den Serialserver mal als Level-0 bezeichnen. Eine Frage: wenn es ein zweites COm-Port mit µC gäbe, würdest du dann einfach einen zweiten Serialserver starten oder würdest du den einen aufblasen, damit er auch zwei Ports kann ?
Ich würde bei der Bezeichnung Level-0 bleiben, weil da braucht man nie erklären, daß da drunter nix mehr ist außer Kupfer und Strom.
Ich geb zu, daß mich das mit den Multicasts nicht so begeistert, ich würde da lieber Point-to-point IP Connections machen, So schlimm ist das socket gefummel ja auch nicht.
NumberFive
05.03.2006, 16:58
ich würde dann wohl eher dazu neigen im einen Start Parameter mit zu geben so das er mehr instance fähig ist. Aber wo her kommt die Fragen ? wenn es nicht der selbe PC ist tut es jetzt schon also ein
AVR ->PC -> Lan -> PC ->AVR geht jetzt schon ohne Software änderung.
Im Kopf habe ich schon die Idee das es auch einen IC2 Server gibt so wie dern Serial server jetzt nur das am Comport der I²C adapter hängt den es hier schon gibt. Der liegt hier auch schon rum.
Bin im moment noch am schwanken wie ich es auf meien robi machen soll.
Traue mich noch nicht so richtig den mal hier dran zu machen den ich habe angst was kaputt zu machen. ein halbe Implentierung habe ich schon. Habe zur zeit nur ein Timer problem auf dem PC wie baue ich ein takt für 400 Khz.
Mal ne frage wie genau muß der sein ?
Gruß
Startparameter ist gut.
Mit dem I2C Adapter hab' ich mich schon gespielt. Als Master geht der PC tadellos, als Slave weniger, eigentlich garnicht (zu langsam, wenn man über die Comm-Calls geht). Da müßte man mit dem SDK arbeiten und einen richtigen Device-treiber bauen. (auf dem alten DOS wär das noch ein Spaß gewesen)
Timer Muß garnicht genau sein, das ist ja der Witz bei I2C.
NumberFive
05.03.2006, 17:35
meine Implemetierung ist im DDK passiert also viel weiter runter kommst du im Windows nicht. wenn der Timer nicht so wichtig ist sollte ich schnell ein lösung hin bauen können. wir habe den Ring noch frei das wollte ich gerne für die Interupt geschicht nehmen wenn jemand die Hardware dafür baut.
jetzt weiß ich immer noch nicht warum du Zwei Com's brauchst ?
NumberFive
05.03.2006, 18:09
So jetzt steht ein version mit Startparameter zu verfügung hab das zip Updatet. Parameter für die Exe /Port:1-9
Vergessen zu schreiben die Port angabe hat nichst mit dem echten Port zu tun sondern gibt pratisch nur die Konfiguration an im Ini file die gelesen wird für den Comport so das auch Unterschiedlich baudrate und so möglich sind.
Gruß
marvin42x
05.03.2006, 19:42
Info:
Ich habe hier ganz frisch einen Link, von dem ich nicht weis ob er hilfreich, motivierend oder demotivierend ist , ich kannte den nicht. Kann sein das wir einiges neu bewerten müssen. Ich denke aber wir sollten das kennen.
Ich brauche hier mal eure Hilfe.
http://playerstage.sourceforge.net/
Vielleicht verstehe ich das auch falsch.
Netter Gruß
NumberFive
05.03.2006, 20:25
Ich für meinen Teil werde es als herraus foderung an sehen und hier weiter machen wenn das Interesse weiterhin bleibt.
Wenn es nicht bleibt kann ich es leider nicht ändern aber dann wars es auch das letzte Roboternetz Projekt von mir.
Gruß
marvin42x
05.03.2006, 20:52
Ich denke auch, das in dem Link ist eine Linux Applikation.
Die Aufgabenstellung hier ist etwas anders und bezieht sich stark auf die Bedürfnisse der RN-Community mit ihrer eigenen Hard- und -Software.
Aber als Inspiration ist es allemal gut.
Vielleicht bauen wir ja mal ne Bridge ;-)
Noch mal Netter Gruß
jetzt weiß ich immer noch nicht warum du Zwei Com's brauchst ?
Da wird noch das mindeste sein, daß ich alle RS232-fähigen AVR, die bei mir so rumkugeln, an das Netz anschließe, damit es dampft.
NumberFive
06.03.2006, 10:17
Na da bin ich ja mal gespannt. was die Logs so von sich geben wieviel Avr's hast du den da rum fahren ?
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.